AI 主导开发为什么会放大规约维护成本

上周我第一次尝试让 AI 主导一个相对独立模块的开发，最大的感受不是代码写不出来，而是心智负担很高。

这个心智负担并不主要来自编码复杂度，而是来自持续维护三件事的一致性：人的理解、规约文档、AI 上下文。

如果只是人自己开发，很多变化可以在局部认知里自然消化。需求理解变了，状态机优先级变了，某个边界条件需要调整，人会在脑子里把相关判断顺手修正，然后继续往前走。这个过程并不严格，但它很自然，因为人的世界模型有大量隐式补全能力。

AI 介入以后，问题变得完全不同。AI 的推理高度依赖显式上下文。一旦规约文件错了，后面的 IR、spec、backlog、coverage、测试计划都会沿着错误规约继续推导。错误不再只是局部偏差，而会变成系统性偏移。

这也是我这次开发里最强烈的体感：AI 不怕写代码，AI 怕世界模型失真。

AI 版瀑布的问题

我的流程大概是这样：先拿到需求，分析设计出第一版详设；详设内部定稿后，交给 AI 拆成 IR；我再人工看一遍 IR，修改和纠偏；然后让 AI 根据 IR 拆成 spec；再补 spec 遗漏；再让 AI 根据 spec 生成 backlog；最后让 AI 按 backlog 一项项施工。每完成一项都要 review，全部完成后再让 AI 写全量理解报告，再生成权威 coverage-spec，最后基于 coverage-spec 做一致性审计和交付前测试。

这套流程看起来很工程化，实际上有一个隐含假设：规约是稳定的。

但真实软件开发里，需求漂移和设计修正才是常态。尤其是复杂业务模块，很多规则只有在实现过程中才会暴露。比如状态机里某个竞态优先级，前期设计时看起来合理，真正落到代码和测试里才发现需要调整。

在人类主导的开发流程里，这类调整往往是局部修正。可在 AI 主导的流程里，调整会击穿整条链路：详设要改，IR 要改，spec 要改，backlog 要改，coverage 要改，AI 当前上下文也要重建。

于是所有中间产物都被当成了长期资产维护，变化成本被指数级放大。

这就是 AI 版瀑布的问题：它用很多看似严谨的文档，把一个本来应该持续演化的模块冻结成了一个假定稳定的世界模型。

真正权威的东西应该更少

这次复盘后，我更倾向于认为：AI 开发流程里，长期权威资产不能太多。

如果 IR、spec、backlog、coverage、理解报告都拥有解释权，那它们之间的一致性就会变成人要维护的负担。文档越多，越像是在给 AI 维护一个脆弱的外部大脑。任何一处过期，都会污染后续推理。

更合理的方式是只保留少数权威源。

第一类是模块契约。它应该描述这个模块的目标、非目标、状态机、接口、数据模型、异常行为和验收标准。它不是越长越好，而是要稳定、清晰、可引用。

第二类是自动化验证。包括单元测试、集成测试、状态机表驱动测试、契约测试、属性测试、lint、typecheck 和 CI。自然语言规约会漂移，测试才是 AI 最容易对齐的硬约束。

第三类是变更记录。只要核心规则发生变化，就不要假装它只是一次普通修改，而应该显式记录：旧规则是什么，新规则是什么，为什么变，影响哪些测试和实现，哪些派生产物需要废弃。

除此之外，IR、backlog、coverage 草案、全量理解报告都应该被视为派生产物，而不是长期资产。它们可以生成，可以审查，也可以在契约变化后直接废弃重来。

AI 工作流最怕的不是中间产物不够多，而是中间产物都被当成权威。

从上下文维护转向契约编译

我现在更愿意把 AI 开发理解成一种“契约编译”过程。

人负责维护少量高价值契约，AI 负责把契约编译成计划、代码、测试和审计报告。派生产物的价值在于服务当前迭代，而不是长期保存。

如果模块契约发生变化，正确动作不是人工逐个修补所有下游文档，而是重新从契约生成 backlog、coverage 和测试建议。人的工作重点应该是审查契约变化是否正确，以及自动化验证是否覆盖了变化，而不是维护一堆自然语言文档之间的同步。

这和传统软件工程里的一个原则很像：不要提交编译产物作为权威源。

在 AI 开发里，很多 spec、plan、coverage report 本质上也是编译产物。它们可以存在，但不能反过来成为世界模型的根。

状态机应该显式化

这次让我印象最深的是状态机竞态优先级的修改。

状态机特别适合暴露 AI 开发的问题。因为状态机不是简单的 if else，它包含状态、事件、guard、优先级、副作用、非法转移和并发语义。只要其中一个维度没写清楚，AI 就可能生成一个表面可运行、但语义错误的实现。

所以状态机规则不应该只写在自然语言详设里，而应该变成显式表格：current_state、event、guard、priority、next_state、side_effect、forbidden_case。

AI 施工前，只允许基于这张表推导逻辑。review 时，也检查代码是否和这张表一致。优先级一旦变化，就必须同步修改状态机表和对应测试。

这样变化发生时，失效的是下游 backlog，而不是整个开发世界模型。

AI 可交付工程的关键不是更重的规约

很多人遇到 AI 写坏代码后的第一反应，是写更多文档、更多规则、更多提示词。但这可能会把问题变得更糟。

因为真正的问题不是规约不够多，而是规约没有分层。长期稳定的契约、当前迭代的计划、一次性的理解报告，被混在一起维护。最后人类承担的不是架构判断，而是文档同步。

AI 可交付工程应该反过来做：减少权威文档数量，提高验证密度，让变化有显式入口。

可以把流程改成这样：先写模块契约；再让 AI 基于契约生成测试草案；人先审测试是否表达真实意图；再生成一次性 backlog；每个 backlog 只做一个小 diff；每个 diff 必须带测试结果和风险说明；最后用独立上下文 review contract、diff 和 test output，而不是让同一个长会话自证正确。

这个流程的核心不是让 AI 记住更多，而是让 AI 每一步都能被重新约束、重新验证、重新生成。

人的角色会更靠前

AI 主导开发并不意味着人退出开发。恰恰相反，人的角色会更靠前。

人不应该主要做“AI 写完后帮它擦屁股”的 review，而应该在更早阶段确定模块边界、状态归属、异常语义、不可变约束和验收方式。AI 可以负责执行，但不能负责最终解释业务世界。

如果人的架构判断没有提前显式化，AI 会用代码把所有模糊性固化下来。它可能写得很快，也可能写得很完整，但完整不等于正确。

所以 AI 时代的软件工程能力，不是把需求丢给 Agent 然后等它生成结果，而是设计一条可恢复的知识流：需求如何进入契约，契约如何生成任务，任务如何生成代码，代码如何被测试证明，变化如何回写到契约。

总结

这次经历让我意识到，AI 主导开发最大的成本不是生成代码，而是维护世界模型一致性。

如果把 IR、spec、backlog、coverage 都当成长期有效资产，AI 会把传统软件工程里“规约稳定”的假设推到极致。一旦现实中的需求漂移发生，整个上下文链路都会变得昂贵而脆弱。

更可行的方向不是 AI 版重文档瀑布，而是最小权威契约、可丢弃派生产物、自动化验证和显式变更记录。

AI 不应该让软件开发变成更大的上下文维护工程，而应该迫使我们把真正重要的契约、边界和验证讲清楚。

相关：AI 编程时代的软件工程原则、AI 时代我如何理解软件交付流程、如何让 Agent 不把代码库写烂、从 Vibe Coding 到 Spec Coding：如何用 TDD 解决 AI 带来的“架构崩坏”、大代码库里如何管理上下文