让 AI 在三十万行代码里干活：上下文工程不是玄学，是流程

先说那个让人不舒服的结论

斯坦福一项关于 AI 对开发者生产力影响的研究给出两个发现：AI 工具产出的大量 "额外代码"，最后只是把上周生成的半成品再返工一遍；编码智能体对新项目和小改动很好用，但在大型成熟代码库里，它们常常让开发者更不高效。

听到这个结论，常见的反应是 "等模型再聪明点就好了"。但有人给出了另一种回应：问题不在模型，而在我们喂给模型的东西。

一套叫"频繁有意压缩"的做法

HumanLayer 的作者把这套方法命名为频繁、有意的上下文压缩（frequent intentional compaction）：不追求一次把整个代码库塞给模型，而是在开发过程的每一步，刻意地重新组织上下文——现在要解决什么问题、相关的代码在哪、约束条件是什么、验收标准是什么。让模型每一次推理都站在一个被精心修剪过的信息窗口上。

他用一个具体案例证明这不是空谈：在一套三十万行 Rust 代码库上，作为一个 "最多算业余" 的 Rust 开发者，他大约一小时提了一个修 bug 的 PR，第二天被维护者合并；几周后，他和作者结对，用约七个小时交出了两个草稿 PR——取消支持与 WASM 编译，团队原本估计每项需要资深工程师三到五天。

规格才是源码

这套流程背后有一个观点支撑：如果和人聊了两个小时的需求，最后只提交代码、把提示词和规格全扔掉，那相当于编译完就把源码删了，只留下二进制。真正该进版本库的，是那份能被反复执行的规格。

这也解释了很多团队 "AI 用不起来" 的真实原因：不是模型不行，而是从来没有把 "要什么" 写清楚过。人是靠口头默契协作的，模型不行——它只能看到写下来的东西。

能落地的三步

对做交付的小团队，这套方法不必照搬工具链，但顺序可以借鉴：先写清目标与验收标准（能被检验的那种），再让 AI 在任务层循环执行，最后定期回头审一遍 "我们定义的目标还对不对"。第三步最容易被忽略，却是防止自动化加速熵增的关键。