AI 在编码中制造的速度感很有意思,因为它远没有人们以为的那么均匀。
今天早上我盯着自己的 GitHub 贡献图,想的就是这件事。
你会看到一段段一天几百次贡献的日子,摊在六个项目上。然后掉到五次。或者三次。上周,我有一天只贡献了两次,却写了 11,000 行代码、大约 150,000 行文档,牵动六个仓库。
这种图案看着古怪,直到你明白这工作到底是什么。
工程化你的上下文
应用层的工作,不全是实现。
有些是探索。你在试那些可能永远进不了最终项目的东西。
有些是规划。用 AI 用得好的话,规划会大幅提速,但它依然是任何正经项目里最吃人工的部分。
而这恰恰是它该有的样子。
事实上,这个年代你能犯的最大错误之一,就是不规划。
作为行业,我们向来低估规划和文档。这一点 AI 没改变。它只是让后果变得没法视而不见。
产出速度上去了,烂流程就不再是个讨厌鬼,而开始变成一枚爆破药。
AI 编码时代理解文档的正确方式,是把它当作上下文基础设施和行为塑造。
不管你有没有意识到,你的工具都会不停去翻它。
它们在读你的规格说明、你的笔记、你的示例、你的测试、你的命名规范、你的仓库结构,还有你沿途落下的每一粒面包屑。
这也是为什么 TDD 开始显得不那么可选项了。
当一边是解决真实问题的 5,000 行,另一边是屁用没有、还引爆技术债的 100,000 行,你会非常快地搞明白什么重要、为什么。
反复出现的失败模式
所以,当人们对「氛围编码」和大规模 AI 自动化发出可怕警告时,大多数抱怨都能归回几种非常具体的失败模式:
1. 文档质量差,或者干脆没有。包括写得太密、难以推理的文档。
2. 给智能体生产系统的 root 权限。
3. 让智能体在没有强力技术监督的情况下搭或管 CI/CD。
记住:软件工程里,「好」「更好」这类词,没有严谨的技术支撑就毫无意义。
软件工程师或 SRE 这个岗位,在可见的未来还会存在。但这个角色已经变了,对它的期望也变了。
自动化改变了万物的形状。
工作越来越多地向上漂移:架构、上下文设计、验证、行为引导、测试、治理、评审。
今天,轮到你去管理自动化系统良好运转的那些条件了。
恭喜你最近的升职。
现在,是时候认真对待它了。