Agent 让每个人都有了翻译器，但团队不再说同一种语言
前阵子，我准备给一个旧项目加个小功能。点进三个月前写的模块后，我才发现：代码能跑，测试也在，我却说不出其中一层抽象为什么存在。
命名没问题，结构也不乱，Agent 留下的注释甚至比我平时写得周到。我缺的是当初做选择时的上下文：为什么用了现在这套方案，另外两套究竟卡在哪里。
我只好去翻 session。三个月前，我和 Agent 花了二十分钟比较三种方案，取舍都记在对话里。今天再读，我像在看另一个人的设计评审。当时的我只留下了一句“Agent 说得对，就这样”，没有把理由再说一遍。
代码库里只有我一个人。三个月后，我成了自己项目的接手人。
代码留下了，选择没有
Armin Ronacher 在《The Tower Keeps Rising》中用巴别塔解释 Agent 时代的协作问题：人们仍然会造砖、砌墙，却失去了让工程得以协作的共同语言。在软件项目里，这门语言是大家对模块边界、约束和设计理由的共同理解。
我遇到的，是这个问题缩小到一个人后的样子。Agent 很擅长根据现有代码补出解释。你问它某个函数做什么，它能逐行说明；你让它修改旧模块，它也能给出一套自洽的理由。
有些信息无法从成品里完整推回来：当时排除了什么，哪块复杂度是故意留下的，什么条件变化后应该重新选型。它们属于做决定时的处境。session 一关，这部分信息就开始丢失；换个新 session 再问，Agent 可能推导出另一条同样说得通的路。
放到团队里，影响会更隐蔽。一个人按吞吐量目标改缓存，另一个人按一致性目标改存储，各自的 Agent 都能把局部代码写通。两次改动甚至不会产生冲突，但两个人依赖的前提已经不同。直到下一次需求同时碰到这两块，代价才会冒出来。
测试通过时，共识还会继续流失
编译错误会立刻暴露，共同理解的流失不会。测试检查的是团队已经写下来的预期，无法检查人脑里是否还留着同一套系统模型。只要局部行为符合断言，代码就可以继续合并，功能也可以继续上线。
最先消失的是对系统的直觉：改这里会波及哪些模块，哪条边界曾经出过事、不能顺手跨过去。它很少写在某个函数里，却决定了人能不能安全地改动整个系统。
等一个小改动引发连锁反应，大家才会发现：每个模块单独看都合理，放在一起却没有人能解释全局。代码评审也很难补救，因为 Agent 随时能生成一份工整的改动说明。说明看起来完整，不代表提交者真的掌握了里面的判断。
我只给判断增加成本
这次之后，我不打算少用 Agent。格式化和查 API，本来就不值得用人脑硬扛。我只想在发生设计取舍的地方，把一点摩擦加回来。
只要 Agent 参与了方案选择，我会在关掉 session 前留下一条短记录：最后选了什么，放弃了什么，什么条件变化后需要重做决定。小改动写进 commit message，跨模块的选择放进项目文档；篇幅不重要，关键是这几句话由我自己写。
代码准备合并时，我也要能脱离 Agent 讲清楚改动意图。个人项目就讲给三个月后的自己，团队项目则讲给会被这次改动影响的人。讲不清楚，就先别让 Agent 代写总结；我还没有完成理解。
它增加的是几分钟的表达成本，无须让人重新手写实现。判断从 session 进入代码库时，多拦这一下，理由才有机会被下一个人接住。
留给三个月后的接手人
那次改动最后花了我大半天。时间主要耗在翻 session、重走三种方案的取舍上。更详细的代码注释解决不了这个问题，因为我真正缺的只有一句：“选 A 是因为 X；B 在 Y 条件下不成立。”
Agent 可以加快实现，做决定的理由却得经过人，再留在代码库里。否则三个月后接手这段代码的，可能还是你自己。