一个没有常识、活在自己世界中的中二病人(话痨)的自留地。

该频道不专注于 Daily 或 News,而是一个记录我当前关注和思考内容的地方。

1. 随机事项:每月为自己安排一些有趣的活动。(大概率🐦🤣
2. 同步内容:我会收集在其他平台上发布的内容。
3. 私人笔记:没经大脑的学习笔记以及一些个人随想。
4. ACG 内容:浓度高的部份还是挪到 另外一个频道 @tomoko_acg
5. 内容转发:在这个频道上转发的内容并不必然代表我个人的立场。
SOP 在 Vibe Engineering 时代的必然性

提到顶级软件工程实践中的各种 SOP,如「100% 测试覆盖率」「语义化类型名称」「代码风格统一」「MAX Linter」「静态类型检查」「PRD/设计文档/TDD」「持续集成/部署」。

在以前的话,总感觉这些对于小团队的需求有「大炮打小蚊子」的嫌疑,想起前司 BOSS 说这些不过是「自欺欺人的减慢速度的玩意」。只是今年在 LLM 擦了一年的屁股后 ,我已经意识到不得不那么做了。以前可能会说「这个流程要放到大公司的团队才管用」,但现在,很自然地就在小团队、甚至是个人开发也很有必然性了。

以前写这些 SOP,最大的问题是人很难遵守。Deadline 一紧,代码风格就先放一放;Review 一忙,测试覆盖就睁一只眼闭一只眼;这个项目的实现方案很可能下个月就会弃用了,用半个月来探索「如何正确地搭建项目」不是浪费时间吗?更别提各种 CICD 的 WorkFlow 校验和严格 TDD、PRD 了;MAX Linter更是让人痛苦得没脾气。

但现在再不定好这些 SOP,你可能会得到:每一轮提问都是全新的代码风格、充满 debug 遗留下来的 log 语句、每一轮都要不断强调的设计思路、一不小心写出来的 shit 被无限放大、实际上不能 work 的代码、以及完全没有必要的冗余流程。

以前小团队靠「默契」「脑子里的规矩」就够了,但 LLM 不吃这套。如果你不把规范写下来,你就要无限重复。这就是为什么 SOP 变得必要了。不是为了「流程正规化」,而是为了让 LLM 每次都能正确地工作,也为了在代码量暴增时减轻 review 负担。(与 HA 的超繁琐 PR 流程达成和解)

正如 Simon Willison 在 Vibe Engineering 中提到的: 「 顶级工程实践在 LLM 时代会获得更大的回报 (LLMs actively reward existing top tier software engineering practices)」

PS. 最近有在给公司内部写一个 AI Programming 方面的 PPT,中间我觉得最为重要的一页就是讲到 Context Engineering 之后的「Proposal <-> Apply 循环最终提炼成 Skill」。我今天才发现,这 Skill 不就是传统意义上的 SOP 么,本质上就是把踩过的坑固化成规范,让下次不用再踩。

#llm
🔖 Vibe engineering #pinboard #llm

当 AI 承担了 90% 的 "打字" 工作后,剩下的 10% 人类工作(架构设计、代码审查、质量把控、问责)反而变得更重要、更难、要求更高。

我也逐渐理解 HA reviewer 那边为什么设置这么多道机器人 check,linter 都基本开满,每一个都是为了减少 reviewer 的负担

https://simonwillison.net/2025/Oct/7/vibe-engineering/
🔖 AI 对这段代码的工作原理有深入的理解 | AI has a deep understanding of how this code works | Hacker News #pinboard #llm

关于「情绪超级稳定的社群 Reviewer 遇到热情的外行用户在 LLM 的协助下给你创建了一个 13K 行的 PR 」时产生出来的化学反应。真让人哭笑不得😂

想想我 HA 插件的 4000 行代码,我给的预期是半年分 20 个 PR 来提交,真的是… (但凡有一行代码 Reviewer 有点疑惑都要解释半天什么的)

感觉是一个非常里程碑的事件,而且类似事情估计还会越来越多,甚至各种各样的场景下都会发生。LLM 不会带来平权是真的,能力不足的话,甚至没法意识到「这是一件很糟糕的事情」。

不过这句评论也是够灵魂拷问的:

If a manager says they provided oversight of their developer employees, and the code was not as good as the manager thought, would you say "the manager has had their brain broken by the existence of employees"?

如果一位经理声称他们监督了开发员工的工作,而代码质量并不像经理所想的那样好,你会说 "这位经理因为员工的存在而脑子坏了" 吗?


https://news.ycombinator.com/item?id=46039274
🔖 一个半月高强度 Claude Code 使用后感受 | OneV's Den #pinboard #llm #claude

一般不是非常确定的需求我也是更倾向于「小步迭代」的方案,不然「放飞自我」之后的代码要 review 到吐。


我见过的使用方式大致分两派。一派是 “小步快跑”:每次只让 AI 完成一个小功能,验证没问题后再进行下一步。另一派是 “一步到位”:直接把整个需求扔给 AI,让它一次性生成所有代码。更极端的,还有人会开启 --dangerously-skip-permissions 模式(也就是所谓的 yolo 模式),让 AI 可以不经确认就执行任何操作。


感觉可以作为简单的安利文,身边太多朋友都是那种「啊,这个要钱啊,那就不用了。等有需要再开」。What can I say ?

四舍五入,我去建一个 skill 仓库趴。

https://onevcat.com/2025/08/claude-code/
🔖 借助 Skills 提升前端设计 | Claude | 宝玉的分享 #pinboard #llm

你可能注意到了,如果你让一个大语言模型 (LLM) 随便搭个网页(行话叫“落地页”),它十有八九会给你一套“标配”:Inter 字体、白底配紫色渐变,外加一点点可有可无的动画。


https://baoyu.io/translations/improving-frontend-design-through-skills 借助 Skills 提升前端设计 | Claude
🔖 软件工程的“纯”与“不纯” | 宝玉的分享 #pinboard #llm

非常有趣的观点,借由提出 纯粹工程 (pure engineering)不纯粹工程 (impure engineering) 两个概念来分析大模型是否能对工作有更多的帮助。

PS. 我做的应该就算是不纯粹工程了。



想一想纯粹工程是什么样的。你在处理一个你非常了解的问题(因为你已经研究它很久了),而这个问题在整个开发者社区中却并不为人所熟知(否则它就不值得你去研究了)。你总是在自己技术专长的极限边缘工作。而且,你有无限的时间来做出正确的决定。可以理解,大语言模型在这样的场景下帮不上什么忙。对于你做的每一个决定,你都比大语言模型聪明得多。

不纯粹的工程则不同。你通常在处理一个你只有粗浅理解的问题(因为公司需要它来交付某个项目)。这个问题通常并不新颖,只是对你来说是新的。你很少有机会能去处理一个你拥有透彻技术理解的问题,而且你通常都在紧迫的截止日期下工作。因此,对于你做的某些决定,大语言模型可能和你一样聪明,甚至比你更聪明,向它请教或让它审查代码会给你带来很大价值。




https://baoyu.io/translations/pure-and-impure-engineering 软件工程的“纯”与“不纯”
🔖 LLM Agents are simply Graph — Tutorial For Dummies #pinboard #llm #agent

一个简易的 Research Agent 的实现原理介绍。不过我觉得这类 agent 可以加一步「 Decide if it need to ask user more context」。

https://zacharyhuang.substack.com/p/llm-agent-internal-as-a-graph-tutorial?subscribe_prompt=free LLM Agents are simply Graph — Tutorial For Dummies
🔖 科技爱好者周刊(第 332 期):西蒙·威利森的年终总结,梁文锋的访谈 - 阮一峰的网络日志 #pinboard #llm

一开始,我还以为 DeepSeek 是一家国内套壳代理接口的公司。后来,看到连 Hacker News 的评论区经常提到它,我一度以为它是美国公司。今天仔细了解后才发现,原来它通过技术手段大幅降低了成本,而且确实是一家国内公司,实在令人惊叹。

https://www.ruanyifeng.com/blog/2025/01/weekly-issue-332.html
 
 
Back to Top