任务后设计反思

用上下文路由（context routing）解决 AI 编程的可靠性问题。

1. 担忧：「AI 会把我的代码库搞乱吗？」

智能体工程正从演示走进真实代码库，一个担忧也反复出现：

AI 会不会慢慢把我的代码库搞成一团乱麻？

这个担忧已经很具体了。不少团队在自己的仓库里认出了这种模式：功能上线更快了，bug 修得更快了，测试也变绿了，眼前的任务看起来已经完成。可几周之后，代码库里多了一个别扭的辅助函数，多了一个近乎重复的分支，多了一个特例，又多了一条绕过架构本想守住的边界的路径。单看每一次改动都说得过去，伤害来自累积。

近期的证据给出了一个有保留的肯定回答。

2026 年的一项大规模研究追踪了 6,275 个 GitHub 仓库中 304,362 个经过验证的 AI 生成提交，覆盖 Copilot、Claude、Cursor、Gemini 和 Devin。研究发现，每一款助手都有超过 15% 的提交引入了至少一个可检测的问题。其中大多是代码坏味道，但也出现了运行时 bug 和安全问题。更重要的是，被追踪的 AI 引入问题中有 24.2% 在仓库最新版本里依然存在；截至 2026 年 2 月，未解决的问题累计已超过 110,000 个。

这足以回答实际问题：当智能体改动进入代码库的速度，超过代码库吸收、评审和修复它们的速度时，代码库确实会变得更乱。

这并不是说 2026 年的智能体不好。它们越来越有用、越来越自主，也越来越深地嵌入真实工作流。正因如此，这个风险才更值得重视。DORA 2025 年的判断是对的：AI 放大的是它周围的工程体系。如果代码库本来就局部性弱、边界不清、缺少归属规则，更强的智能体并不会神奇地守住设计，只会让更多代码沿着这些薄弱路径流动。

这就是 vibe coding 的阴暗面。开头感觉行云流水，结尾却可能变成 vibe sloping：系统从惯性滑向一堆烂摊子（slop）。速度是即时的，债务却在复利增长。

所以这个担忧值得一个直接的回答。

是的，AI 确实可能让代码库随时间变得更乱。

2. 现有解释仍然是零散的

关于智能体编程为什么会带来可靠性问题，目前没有一个公认的统一解释。现有文献和业界文章指向了几个相邻的失败面。

Anthropic 2025 年关于上下文工程的工作把问题解释为上下文可靠性：智能体需要一个小而高信号的工作上下文，因为长上下文仍可能变得嘈杂、被污染，或难以跨越推理。针对软件工程智能体的轨迹级研究把问题解释为工作流可靠性：成功的智能体能在探索、生成修复和测试之间取得平衡，失败的运行则陷入重复循环、缺乏验证的修复，或者没能用好工具反馈。针对编程智能体失败模式的研究把问题解释为代码库感知：随着应用规模增长，智能体难以把握业务规则、共享状态、已有辅助函数、重构义务和错误处理。

业界报告又补充了两个角度。代码评审和质量控制方面的讨论聚焦于评审过载：智能体编程让大规模 diff 变得廉价，团队必须决定人应该评审什么，而不是逐一检查每个实现细节。关于「vibe architecting」的架构研究则聚焦于治理：智能体如今会做出框架、分解、集成和边界方面的决策，而这些决策常常藏在一个能跑通的补丁里，没有经过显式的设计评审。

这些解释都有价值，因为它们揭示了同一个问题的不同侧面：上下文、轨迹、代码库感知、评审负担和架构治理。它们并不是互不相干的格子。轨迹失败和治理失败之所以出现，往往正是因为智能体没有获得在系统设计之内行事所需的代码库感知。CMP 提供了一种更紧凑的方式把它们串起来：智能体的可靠性是一个上下文路由问题。

问题不只是模型够不够强，还在于代码库及其周边工程体系能否帮助智能体找到正确的信息、修改正确的位置、遵守正确的约束，并从正确的反馈中学习。

3. 为什么这是一个上下文路由问题

智能体从来不是拿着一张完整地图去修改代码库的。它从一个请求出发，收集上下文，顺着名字和文件往下找，选定补丁位置，运行检查，解读反馈，在任务看似完成时停下。每一步都取决于代码库让什么可见、把什么藏起来。

如果正确的文件、测试、文档和约定都容易发现，智能体就能在一个小而高信号的上下文中工作。如果它们分散各处或只是隐含存在，智能体要么漏掉关键信息，要么靠加载过多内容来弥补。这就是上下文问题。

如果智能体能把代码库当作一个系统来理解——行为在哪里定义、状态如何流动、哪些业务规则约束着这次修改、已有哪些抽象、哪些文件必须一起演进、哪些边界在保护设计、代码库期待什么约定——它就能做出与周边系统契合的修改。这就是广义的代码库感知问题。

如果边界、契约、测试、类型、静态分析和评审意见都指回设计意图，它们就会加深这种感知，并引导下一步行动。如果这些信号被隐藏、充满噪声或彼此脱节，智能体仍然可能写出看似合理的代码，却漏掉了让修改正确的那层系统关系：它可能跨越分层，在错误的修复上打转，压制错误，过早停下，或者只为「变绿」而优化，却没有守住架构。

如果架构把做什么和怎么做分开，人就可以评审行为、契约、边界和设计意图，而智能体用 TDD 去磨实现细节。如果这种分离很弱，每个 AI 生成的 diff 都要求评审者同时检查意图和机制。这就是评审过载问题。

因此，「上下文路由」并不是在清单上再加一类问题。它点出的是这些问题底下共同的结构：可靠性取决于代码库能否把智能体引向做出正确修改所需的上下文。

4. 读懂智能体刚刚采取的行动

每一次代码修改都会产生一个 diff，同时也会留下一条真实的上下文路由轨迹。

为了完成任务，智能体必须在代码库中为自己规划路线。它搜索入口点，打开文件，顺着名字、测试、导入、注释、错误、类型和约定往下走，然后在多个位置中选定一个打补丁。这条路线不是抽象概念，而是智能体发现上下文、选择修改点、解读反馈并判定任务完成的实际路径。

任务刚完成时，这条路由轨迹还是新鲜的。智能体手里仍有一张高分辨率的地图，记录着路由在实践中如何运作：哪些信号帮它找到了正确的文件，哪些名字或测试指对了方向，哪些约定让下一步显而易见，哪些路径走进了死胡同，哪条边界难以看清，代码放在哪里、归谁所有又在哪里显得模糊。

这让任务后反思格外有价值。趁证据还在，它可以问三个具体问题：

• 代码库是否为这次修改提供了清晰的路由信息？
• 上下文收集是否从名字、测试、文档、类型、错误和局部结构中得到了足够的帮助？
• 模型和智能体框架（harness）是否注意到并利用了这些路由信号，还是四处游荡、读得过多、读得过少，或者走了捷径？

人的开发流程通常保留 diff，丢掉这条路线。一个 pull request 展示改了什么，却很少展示修改者如何找到修改位置、探索过哪些误导性路径、哪些抽象难以发现、遵守哪些边界代价高昂。

智能体带来了一个机会：在这条上下文路由轨迹消散之前把它留下来。

这个机会并不依赖于某种特定的模型缺陷。更强的模型仍然需要发现上下文，更好的智能体框架仍然需要可以利用的路由信号。真正值得关注的，是代码库、模型和智能体框架之间的交互：代码结构、命名、测试、文档、归属规则、模块边界、工具设计和检索行为，共同塑造了这条路线。

当反思修复了这些路由问题，下一次修改就会受益。更清晰的局部性帮助下一个智能体更快找到相关上下文；更清晰的边界帮助它避开捷径；更清晰的归属帮助它把新能力放到设计期望的位置。正因如此，智能体收集上下文时的挣扎本身就是遥测数据：它揭示了代码库怎样才能让未来的智能体更容易理解、更可靠地修改。

5. 任务后设计反思检查什么

任务后设计反思可以保持很小。第 4 节已经确立了核心思想：每个完成的任务都会留下一条上下文路由轨迹。反思读取这条轨迹，检查三件具体的事。

5.1. 缺失路径（Missing Path）

智能体是否费力才找到本应很容易到达的上下文？

这是一个局部性信号。正确的文件、测试、注册表、辅助函数或配套修改可能早已存在，但代码库没有足够清晰地把智能体引过去。结果是遗漏风险：相关修改彼此脱节，已有能力被重新实现，本应引导这次修改的测试与工作脱钩。

修复方式是局部性修复（Locality Repair）：加上最小但有用的路由信号，让下一个修改者能找到已有的目的地。它可能是一条注释、一个注册表条目、一个契约测试、一段 README 说明、一次命名调整、更合理的文件位置，或者在附近放一个指向规范实现的指针。

5.2. 越权捷径（Unauthorized Shortcut）

智能体是否通过跨越架构本想守住的边界来完成任务？

这是一个边界信号。补丁也许在局部能工作，却开辟了一条新的访问路径，穿过内部实现、私有状态、实现细节或错误的分层。结果是边界侵蚀：系统又多了一条未来修改可以照抄的捷径。

修复方式是边界守护（Boundary Guard）：把修改移回预期的契约上，并让这份契约更容易被看见。具体可能是澄清一个接口、添加一个契约测试、指定归属者、记录一条禁止的依赖，或者把补丁挪到恰当的分层。

5.3. 无主能力（Unowned Capability）

这个任务是否暴露出一项没有明确归宿的能力？

这是一个放置与归属信号。智能体可能需要一个横切的辅助函数、转换、策略或集成点，但架构没有明确回答它该放在哪里。结果是重复和漂移：之后的每个任务都可能把同一项能力就地放置一份。

应对方式是检测并上报。反思应当标记这项归属不明的能力，并把设计决策摆到台面上：它应该放在哪里，归谁所有，未来的修改应该走哪条路径？

6. 为什么反思必须保持小规模

任务后设计反思是刻意受限的。它保证执行忠实于现有设计，而不是替团队设计系统。

这个限制恰恰是关键所在。

许多由 AI 引起的可靠性问题，来自那些被隐式做出的决策。一个补丁引入了新抽象；一个辅助函数意外有了归属者；一条边界因为直接修改更省事而移动了；一项横切能力落在了当前任务恰好所在的地方。代码能跑，但一个设计决策已经在没有被点名的情况下做出了。

反思应该阻止这种权力的悄然转移。它只给智能体一个狭窄的职责：识别这次任务是否遵循了已有的设计，并把真正需要设计决策的地方暴露出来。

这也是第 5 节的三项检查刻意保持简单的原因：

• 缺失路径：目的地已经存在时，修复可发现性。
• 越权捷径：补丁跨越了已有边界时，守护这条边界。
• 无主能力：目的地尚未定义时，上报归属缺口。

前两项往往可以产出一个小修复，第三项通常应该产出一次清晰的升级上报。反思可以说「这项能力需要一个归宿」，但不应该把放置位置当成又一个实现细节，自行发明一个归宿。

这样就守住了做什么 / 怎么做的边界。人继续对行为、契约、边界、归属和设计意图负责。智能体可以在这些约束之内处理怎么做：实现、测试、打磨，并用 TDD 磨完那些机械性细节。

可靠的协作依赖于这种分工。智能体必须学会识别自己的实现工作在哪里结束、人的设计权威从哪里开始。任务后反思这一实践，让这条边界在每次修改之后都清晰可见。

7. 为什么这回应了那个担忧

担忧在于 AI 会把代码库搞乱。补丁通过了测试，diff 看起来合理，眼前的任务完成了。但随着时间推移，下一次修改变得更难，因为相关上下文更难找到：正确的文件不再那么明显，正确的边界不再那么可见，已有能力更难复用，人类评审者在信任一个修改之前要重建更多的系统认知。这正是 CMP 要应对的可维护性失败：代码库不再把未来的修改者引向他们需要的全部上下文。

任务后设计反思的回应，是把每一次修改都变成一次小型的上下文路由评审。

它让反馈循环与风险处于同一尺度。缺失路径的修复，降低了找到下一个相关文件、测试、辅助函数或配套修改的上下文成本。边界守护让既有的设计约束在修改发生处保持可见，使未来的智能体能沿着预期的契约进行修改。无主能力的上报把模糊的放置问题变成明确的设计工作，让未来的修改有一个稳定的落脚点，避免重复代码。

这同样守住了做什么 / 怎么做的边界。智能体仍然可以在实现上快速推进：写代码、跑测试、打磨、处理机械性细节。反思则把行为、契约、边界、归属和设计意图留在人类评审的层面，那里才是可维护性决策该在的地方。

最关键的是节奏。代码库的可维护性是一次修改一次修改地被侵蚀的，修复循环也应该一次修改一次修改地运行。把反思放在每个智能体任务的末尾，趁上下文路由轨迹还新鲜，系统就能在下一个任务沿同一条薄弱路径走下去之前降低上下文成本。

这就是它的承诺：让代码库保持可修改，守住人的设计权威，让下一次智能体修改更容易被正确路由。

结语：智能体时代的设计

智能体工程改变了软件设计的基本单位。

过去评判设计，主要看它能多好地帮助人理解和修改系统。现在还必须看它能多好地帮助智能体发现正确的上下文、遵循正确的约束，并在每次修改之后让系统更容易修改。

这让任务后反思不只是一种清理习惯，而是 AI 维护的代码库中一条新的设计反馈回路。智能体穿过代码库的路径成为证据，它遇到的阻力成为信号，它的不确定揭示出系统在哪些地方还没有让自身的设计足够清晰可读。

任务后设计反思，一次修改一次修改地闭合这条回路。