跨模块修复先做架构规划是否更有效

跨文件修 Bug 时，AI 最贵的部分，可能是改完一个文件后才发现另一个文件的约束。在作者的支付结算实验中，先给执行模型一份 1,143 字符的跨模块蓝图，两个方案都通过了 20 项测试，但有蓝图的方案将输入 token 减少了 84.9%，API 成本降低了 71.5%。

这组结果值得看，但不能直接理解成「多加一个架构师就能省钱」。实验同时改变了规划方式、失败日志累积和代码提交路径。对日常 AI 编程更有用的问题是：第一次修改之前，应该让模型明确哪些约束，又该避免哪些重复劳动？

同样修好三个文件，为什么账单差这么多

这次实验编号为 E18，候选编号 C014，在作者的 41 种模式中排名第 7。任务是修复由 validator.py、settlement.py、statement.py 组成的支付结算流水线，使用的模型是 gemini-3.8-flash，配置为 thinkingLevel: LOW。

Mode A 使用 SoloExecutorLoopRunner，不咨询 Advisor，advisor_calls = 0。执行模型先调用 run_solo_trial，第二轮通过 stage_executor_patch 修改 validator.py，第三轮修改 settlement.py，第四轮调用 submit_settlement_bundle 提交全部三个模块。累计 4 次 LLM 调用、5 次文件编辑。

Mode B 使用 AdvisorExecutorRoutingRunner，第一轮调用 consult_advisor，advisor_calls = 1，获得名为 one_shot_execution_blueprint 的五点执行蓝图；第二轮一次实现并提交三个模块。累计 2 次 LLM 调用、3 次文件编辑。

两种方式都通过了 labjudge18 的 20 / 20 项隐藏单元测试和端到端测试，区别集中在完成过程：

指标	Mode A	Mode B
累计输入 token	27,699	4,172
累计输出 token	2,897	1,568
API 成本	$0.0316	$0.0090
执行时间	33.45s	18.78s
未计划的局部补丁重试	2	0

按作者统计，输入效率提高了 6.64 倍，输出 token 减少 45.9%，执行提速 1.78 倍。这里的「一次完成」指一次实现并提交三个模块，仍然需要测试验证。

蓝图省下的，是重复读日志和重复写代码

作者从 usage.json 和 execution-traces.json 中指出了两笔额外开销。

第一笔是失败诊断不断进入对话历史。Mode A 的试跑诊断每次追加约 7,500 字符，后续调用又要重新读取这些内容。四轮输入分别为 1,909、5,000、8,527、12,263 token。任务还没结束，上下文已经越来越重。

第二笔是代码重复生成。Mode A 第二轮生成 validator.py，消耗 488 个输出 token；第三轮生成 settlement.py，消耗 795 个；最终提交三个文件时，又输出了 1,604 个。它一共生成 2,897 个输出 token，比 Mode B 的 1,568 个多出 84.8%。

作者还提到，输出 token 的单价通常是输入的 3 至 5 倍。不过原文没有列出具体计价表，不能把这个比例当成所有模型的固定规则。

蓝图的作用，是提前把三个文件必须共同遵守的条件摆出来。比如数据类型要一致，边界判断究竟使用 > 还是 >=，最终格式有哪些不能改变的要求。原文建议把这些内容压缩成五条、少于 1,500 字符的检查表，在开放文件编辑工具之前提供给执行模型。

先明确文件之间的约束，才能减少改完一个文件后再追着下游补洞。

这不是要求模型写一份长篇设计文档。它更接近一张施工前检查表：哪些地方必须一起改，哪些细节不能各自决定。

为什么这次规划有效，角色交接却曾经更慢

作者拿 E18 与此前的 E05 作了比较。E05 按 Architect、Coder、QA 拆分角色，结果慢了 2.66 倍；E18 加入 Advisor 后却更快。

作者认为，差别在于执行者是否始终掌握原始上下文。

E05 的 Architect 在独立上下文中工作，再把自然语言摘要交给 Coder。摘要会丢失细节，原文举的例子是带符号的零 -0。如果下游只能依赖转述，就可能不知道某个看似可忽略的数值细节其实属于任务规则。

E18 中，Executor 仍然可以直接查看真实源码，Advisor 只补充一份简短的跨模块约束清单。执行者可以对照源文件理解建议，不必完全依赖另一个角色的概括。

这对团队搭建 AI 工作流有启发：规划可以交给独立步骤，但应让负责修改代码的模型保留查阅源码和原始要求的能力。

不过，E05 和 E18 是不同实验，原文没有提供足以证明它们条件等价的材料。因此，这个比较能解释作者的设计思路，还不能证明 Advisor 路由普遍优于角色子代理。

我的判断

我认同把跨模块约束放到第一次编辑之前。对于涉及多个调用方、共享数据类型或格式规则的修改，提前检查接口关系，比只盯着当前报错位置更合理。

但这组数字支持的结论应当收窄到实验条件内。

首先，Mode A 的流程会追加大量诊断，还要求最终重新输出完整代码包。这两项机制直接放大了成本差距。若执行器只接收精简错误、使用增量补丁提交，收益可能不同。原文没有提供「独立执行器先规划」「压缩日志后再试跑」等对照组，无法分离蓝图、日志管理和提交方式各自的贡献。

其次，蓝图本身如何产生没有说清。虽然 Mode B 报告了 2 次 LLM 调用和 $0.0090 成本，但 consult_advisor 背后是否另有模型推理、如何计费，以及生成蓝图时看到了哪些材料，原文没有展开。标题强调 Claude Code /advisor，实际列出的模型却是 gemini-3.8-flash，所以更适合把它看作对这种模式的模拟测试。

最后，作者使用了网络隔离的 Proxmox VM222，配置包括 0 NICs、virtio-serial QGA relay 和 systemd UID 分离。这些措施有助于约束实验环境，却不能替代重复测量。原文只给出了一个 Run ID，也没有列出 20 项测试的具体断言、重复次数或结果波动。

可以采纳「先列约束」的做法，暂时不要把 71.5% 当成可复用的节省比例。

至于作者提出的「绝不允许执行器先改第一个文件」，我认为更像经验性规则。单文件且边界清楚的小修复，未必需要额外咨询；是否值得规划，应看模块之间的依赖有多强。

能拿来做什么

• 遇到前端请求层、Node 接口和格式化逻辑需要联动修改时，先让 AI 列出五条跨文件约束，写清字段类型、边界条件和输出格式，再开始编辑。
• 使用 Claude Code /advisor、Antigravity /plan 或自定义规划步骤时，让执行模型继续访问源码和原始需求，并要求它核对蓝图中的约束。
• 自建 agent harness 时，检查失败日志是否被整段反复加入历史，以及提交工具是否要求重复生成已修改文件，分别记录这些环节的 token 开销。
• 用团队真实的跨文件任务做小规模对照，同时记录测试通过率、调用次数、总费用和耗时，再决定是否默认启用 Advisor；一次通过应当是测量结果，不能成为跳过验证的理由。