摘要在 AI 协作项目中Agent 能够生成合理且测试通过的代码但项目可能在大量正确修改中逐渐走向腐败。腐败的根因是需求中未被验证的假设直接固化为系统事实而 AI 缺乏人类的体感与判断力。本文从 What-Why-How 三个层面分析这一现象并提出编码前认识系统架构、编码后系统性检视的具体方案最终说明人在其中起决定性作用。一、AI 协作项目是如何走向腐败的AI 协作项目真正危险的并不仅仅是生成错误代码而是它可能在大量合理、正确、测试全绿的修改中一步步走向腐败。1.1 说出来的、没说出来的、不知道的当开发者向 Agent 描述需求时信息分为三类你告诉它的“用户登录后显示首页”你没说的但它需要知道的• 登录失败怎么办• 新用户和老用户的首页是否一样• Session 过期后如何处理你根本没想到要说的• 并发登录时如何处理• 用户在多个设备登录时是否互踢• 紧急情况下能否强制下线用户第一类是开发者有意识传达的。第二类是开发者知道有问题但懒得解释的。第三类是开发者自己都没意识到的空白。第三类最危险。开发者不觉得这是个问题Agent 也不会追问。它会自己选一个最合理的解释然后继续往下写。1.2 一个假设的腐蚀过程举一个常见场景开发者告诉 Agent“外部服务偶尔超时增加自动重试提高请求成功率。”需求看起来很清楚但 Agent 不知道• 超时是否代表服务端没有执行• 哪些接口可以安全重试• 请求是否具备幂等性• 重试可能产生哪些重复操作为了继续工作Agent 作了假设请求失败就代表操作没有成功因此可以重试。这个判断并不愚蠢。自动重试配合指数退避是处理临时网络故障的常见方案。问题是客户端没有收到响应并不代表服务端没有完成操作。这个未经确认的假设直接进入了公共请求客户端。1.3 测试制造的虚假确定性完成实现后Agent 生成测试• 第一次请求超时第二次请求成功 ✓• 达到最大次数后返回失败 ✓• 认证错误不触发重试 ✓所有测试都通过了。但这些测试只能证明代码符合 Agent 的假设不能证明假设符合真实需求。如果需求解释、代码实现和测试用例都来自同一个未经验证的前提测试全绿只是一种闭环自证。它没有消除不确定性只是把不确定性藏进了代码。1.4 假设逐渐成为系统事实后来支付、订单、库存和消息模块都开始复用这个请求客户端。此时自动重试已经不再是一段局部容错逻辑而成为系统的隐含前提请求超时就等于操作没有执行。想改变它不再是调整一个重试参数而是必须逐一确认所有外部接口的幂等性、失败语义和补偿方式。一个从未确认的假设获得了架构级影响力。1.5 人类逐渐失去系统理解终于有一天线上出现重复扣款支付服务已完成扣款但响应在返回途中丢失客户端重试后再次发起支付。最初的假设被证明是错的但系统已经高度依赖统一重试。彻底移除成本太高于是 Agent 给出一个兼容方案• 支付请求增加幂等键• 部分接口加入禁止重试名单• 订单和库存增加补偿任务• 无法自动判断的异常进入人工对账从局部看这又是一个合理方案。但它没有解决最初的问题只是在假设与现实之间增加了一层补丁。随着例外增加每个接口都有了不同的重试次数、幂等策略、失败分类和补偿流程。此时的复杂度已经不完全来自业务而是来自维护最初假设所需要的补偿。项目可能仍然架构优雅、文档完善、测试全绿但已经没人能完整解释• 哪些请求可以安全重试• 超时后服务端是否已经执行• 哪些规则来自真实业务哪些只是历史补丁• 哪些测试验证了需求哪些测试只是在保护旧实现最终系统仍然运行功能仍在快速交付代码甚至精巧而自洽——仿佛一座秩序森严的远古神殿。只是再也没人能读懂神殿里的铭文也没人知道祭坛之下封存着什么。二、为什么 AI 协作项目必然走向腐败腐败的原因分为两个层面人的层面和 AI 的层面。2.1 人的层面缺失的架构视角AI 协作的核心问题在于很多开发者没有架构师与管理者的视角却因为 AI 协作成为了模块或系统的架构师而不自知。原本的技术决策链条是架构师人→ 模块开发者人引入 AI 后变成了架构师人→ 模块架构师人→ 模块开发者AI问题是这个模块架构师往往还站在开发者的角度去看待问题——关注局部实现而非全局约束。底层开发者不管是人还是 AI必然会站在局部最优的角度看待问题。局部最优往往不会带来全局最优而后者正是顶层设计需要做的事情架构边界的划分、数据模型的统一抽象、跨模块约束的定义、公共组件的沉淀。AI 协作让很多缺失架构设计与项目管理能力的人被迫承担了相应的职责而不自知。当开发者只是给 Agent 描述需求时实际上在进行的是架构决策、接口设计、约束定义——这些本应由具备架构视角的人来完成的职责。2.2 人的层面认知债务的正反馈人类越难理解系统就越依赖 Agent 继续修改越依赖 Agent新的隐含假设就越容易进入系统。隐含假设增加 → 系统复杂度上升 → 人类理解下降 → 更加依赖 Agent这是一个自我强化的正反馈循环加速项目的腐败。2.3 AI 的层面缺乏人类的体感我们以为自己做判断是靠知识。但仔细想想大部分时候不是。你不需要学过物理就知道从高处跳下来会摔疼。你不需要任何训练就能看出一个人是在认真还是在敷衍。这些知识从来没有被写进任何教科书。但它们真实存在而且权重极高——因为它们直接关系生存。我们把这种东西叫做常识或者更准确地说叫做体感。AI 没有这种东西。AI 只有 Token——文字的统计规律。所以 AI 看到数学家就联想定理看到离婚就提相关情节。不是它不听话是它真的不理解这些行为在真实世界里意味着什么。这才是 AI 最根本的局限。不是算力不是数据是它没有穿衣服出门的经验。2.4 AI 的层面知道梨子的滋味唯一的方法是亲口尝一尝毛主席在《实践论》中说过你要知道梨子的滋味你就得变革梨子亲口吃一吃。这话放到 AI 协作的时代特别应景。AI 可以读完全世界关于梨子滋味的描述维基百科说梨子汁多味甜清脆爽口美食博客说咬一口满嘴汁水有淡淡的清香营养学论文分析梨子的糖分和维生素用户评论说很好吃或太酸了。AI 可以把这些描述组合得天衣无缝写出一篇完美的梨子品鉴报告。但 AI 不知道梨子咬下去是什么感觉——汁水迸发的触感清脆的声响酸甜在舌尖散开的层次。因为 AI 没有嘴巴。人写代码时的判断同样如此。一个经验丰富的程序员看到一个接口设计会有感觉不对的直觉。这种直觉来自踩过的坑、犯过的错、深夜 debug 的疲惫。一个从未踩过生产事故的 AI不会有这种直觉——它只能根据文字描述来推断什么是对什么是错。这就是为什么 AI 写的代码功能正确但结构常常差点意思。差点的那点意思不是知识是体验。是只有亲口尝过梨子的人才能说出来的东西。2.5 AI 的层面逻辑推理的不可逾越边界逻辑推理的本质是穷举。假设你在设计一个系统有 10 个模块每个模块有 10 种可能的状态。你要验证系统的正确性需要检查 10^10 100 亿种组合。这不是 AI 还是人的问题这是数学上的客观边界。人怎么解决这个问题人靠分类。我们不会真的去穷举 100 亿种组合。我们会说这两类情况其实可以合并或者说这个场景现实中几乎不会出现。我们靠对真实世界的理解把推理空间压缩到可以接受的范围。AI 不会这种压缩。它看到可能就要处理。它不知道哪些可能性是真实的哪些只是逻辑上的可能。上下文再大也解决不了这个问题。上下文解决的是记住多少不是算得出多少。2.6 更聪明的模型和 Harness 都解决不了这个问题模型能力不够加模型能解决吗弱模型可能留下明显错误强模型却能把错误前提实现得更加完整、更难推翻。更强的模型不会自然阻止项目腐败反而可能加速假设的传播。模型能力解决的是如何更好地实现一种解释而项目治理需要解决的是如何确认这种解释值得成为系统事实。二者不是同一个问题。那加 Harness 呢很多人会说给 AI 加上各种规范、约束、checklist让它不乱来不就行了这是一种误解。Harness 只能约束行为不能约束需求。假设你给 AI 添加了一条约束“所有外部调用必须考虑幂等性”。这条约束本身就有问题什么算外部调用HTTP 接口算数据库算吗Redis 算吗消息队列呢约束不能告诉你对不对Agent 会加幂等键但可能加错了位置。更重要的是如果开发者根本没想过幂等性约束不会帮他想到这一点。再看一个例子。你给 AI 添加了一条详细的规范“支付接口的幂等键必须包含用户 ID 订单 ID 时间戳”。这条规范仍然假设了一个前提时间戳能区分两次请求。如果分布式环境下多台机器的时间不同步呢约束越多假设埋得越深。当规范越来越多每条规范背后都有一个假设。这些假设可能相互矛盾可能被后来者遗忘。更糟糕的是当问题出现时开发者会倾向于再加一条约束来修补而不是追溯最初没说清楚的假设。这正是项目腐败的路径——不是缺乏规范而是规范掩盖了假设。问题的本质不是 AI 行为不当。AI 其实很听话它只是在忠实地执行它理解的指令。问题是指令本身就包含了没说清楚的假设。Harness 能让 AI 更好地执行指令但不能让 AI 替人类想清楚指令。再完善的规范也需要一个人来判断这份规范本身对不对。AI 协作最大的风险不是 Agent 写错代码而是它写出了完全正确的代码却实现了一个从未被验证过的世界。三、我们该怎么做3.1 编码前清晰地认识系统架构在给 Agent 下达任何指令之前开发者必须首先清晰地认识系统架构。具体来说要清楚四个问题• 边界在哪里这个模块负责什么不负责什么• 依赖关系是什么哪些组件依赖这个模块这个模块又依赖哪些组件• 已有哪些约定现有的接口规范、错误处理方式、数据模型• 潜在的影响范围修改会影响到哪些地方Agent 执行得越快人类尚未表达的假设就越快进入系统。当开发者自己都不清楚系统架构时给 Agent 的指令必然充满隐含假设。这些假设会随着 Agent 的执行直接固化为代码。3.2 编码后系统地检视 AI 生成的代码AI 生成的代码必须经过系统性的检视而非简单的看起来没问题。检视的核心不是验证代码能不能跑而是验证四点• 假设是否被显式表达代码基于哪些假设这些假设是否与需求一致• 影响是否被完整评估修改影响了哪些模块是否有隐式依赖被引入• 抽象是否合理是否有重复代码是否有更好的抽象方式• 边界是否清晰错误处理是否完备异常流程是否被考虑检视的价值不在于发现错误——那是测试的事。检视的价值在于迫使人类重新理解自己下达的指令。当人类无法清楚地解释一段代码时这段代码就不应该被合入。检视不是为了证明 AI 做得对而是为了确保人类理解 AI 做了什么。3.3 建立架构意识AI 协作开发者需要意识到你正在做的是架构工作而非单纯的实现工作。每个需求描述都是一次架构决策每个接口设计都定义了系统边界。在按下发送键之前应该问自己四个问题3.4 建立顶层设计对于足够大的业务系统需要显式建立四样东西• 架构原则定义跨模块的技术约束• 数据模型统一核心实体的抽象和关系• 接口契约明确模块间的协议和依赖• 公共组件沉淀可复用的基础设施这不是一次性的工作而是持续的对齐过程。3.5 培养判断力而非与 AI 比记忆AI 取代的是靠记忆和检索就能完成的工作。AI 不取代的是需要对物理世界有真实感知的工作需要在混乱中找到关键点的工作。一个靠背 API 文档写代码的程序员危险了。但一个程序员能看懂复杂系统的行为模式能在 bug 中找到关键点AI 取代不了。判断需要体感判断需要常识判断需要在 100 亿种可能性中找到真正重要的那几类。这些都是 AI 无法提供的东西。不要和 AI 比记忆。发展 AI 没有的东西对世界的感知和判断力。这才是 AI 协作时代开发者最值得培养的能力。结语模型决定项目构建得多快Harness 决定 Agent 能走多远。而人类是否持续理解并检视这些改变决定项目最终走向哪里。判断力来自亲口尝过的梨子不来自读过的梨子描述。