2023年微软一项研究搅动了整个开发者圈子：用GitHub Copilot完成编码任务的速度比对照组快55.8%。这个数字在厂商PPT和招聘计划里飞快传播，迅速成了AI改写软件开发的通行标签。两年后，METR对一群在自己熟悉的大型代码库里工作的资深开发者做了随机对照试验，结果是：经济学家的预测提速39%、机器学习专家的预测提速38%，而试验发现，用了AI工具的开发者实际多花了19%的时间。同一批开发者自评感觉变快了20%，主观感知和客观测量的差距整整39个百分点。

这份差距有个一眼就能认出的形状。AI让一个功能的头80%变得出奇地快：脚手架、可编译的代码、测试生成、跑起来的Demo，一气呵成。难搞的总是最后那20%。和现有系统的集成、行为边界上的诡谲案例、没人记得是谁写下的老测试桩、没人记录的性能约束、前一个版本为何做了那些取舍的机构记忆。头80%是AI真的在提效，后20%才是架构栖身之处。而整个流程里跑得最快的那一段，正好把最慢也最关键的一段藏了起来，藏到你发现时往往已经来不及换条路了。

打开网易新闻 查看精彩图片

问题不是AI辅助开发该不该更快。智能体高速度生成代码确确实实提升了生产力，那不是需要解决的那道题。真正需要面对的是代码周围组织不断流失的上下文——设计意图、行为逻辑、架构推理，以及工程体系从未被要求以这种速度去追踪的一切。AI辅助开发正在干一件比生产率之争更奇怪的事：它把本来一并发生的两件事拆开了——写代码，和理解这段代码为什么长成这样。AI出现之前，程序员在写的过程中就把理解也构建出来了，写这个动作本身就是学习的强制环节。AI抽走了这个强制环节，代码现在源源不断地涌出，但理解没有跟上。

补上缺口的方法是一个“上下文存储”。它不是上线前的制品守则，而是针对设计意图与行为合规性的版本化记录，人和AI代理都能查询。上线之前，它对AI代理做简报，为代码审查提供事实锚点；上线之后，它支撑排错、架构规划。在一个特性上，你可以试着做三件事：提交代码的同时提交配套规格说明，在接受AI生成的代码前先写一条失败测试，再针对最高风险的三个关键属性编码三道会阻断CI流水线的适应性函数。这样，速度快起来的那部分，不会再悄悄拐跑你的架构。