提到顶级软件工程实践中的各种 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
