通过 Qoder 的认知地基、Ultra Spec 与专家团协同，10 人 3 周将 50 万行 Agent 代码稳定合入 400 万行存量工程
V1.0 上线前，我合上笔记本的时候，最后一组 PR 刚走完所有验证流程，准备合入主分支。控制台上的状态条全是绿色。
迭代到了 v1.4.0 的时候。这 50 万行 Agent 写的代码上线至今没出过线上问题，并且每天还在持续被新需求改动。
3 周交付上线，99% 由 Agent 生成，跑在一个 400 万行的存量工程上。
如果只是在空项目上写 50 万行，说实话没什么好聊的。空白项目里 Agent 可以自由发挥，架构自己定，接口自己设计，没有人会跟你说"那个模块不能碰"。
难的是这 50 万行代码，用 Qoder 写进了 Qoder 自己的工程里。用自己的产品开发自己的产品，相当于把方法和产品同时放在同一杠杆上：方法成立，产品才成立。
我们组日常写代码也是用 Qoder 自己的 Agent，过去 9 个月一直这么跑。V1.0 要回答的问题只有一个：这套干活方式在 3 周要新增数十万行这个量级上是否还成立。
启动前一天晚上，我把两个仓库的模块依赖图摊到三块屏幕上，左边前端，中间后端，右边知识图谱。这次不是日常改几个模块，是 50 万行新代码要铺到 400 万行存量上。每一处可能的接缝都得在动手前看清。
Qoder 从去年 8 月 v0.1 上线到现在，9 个月膨胀到 400 万行左右：前端是 VS Code 扩展，后端是 Go 写的 Agent 调度、知识引擎、多模型调用，分两个仓库。迭代极快，之前也出过小事故，接口上也堆了不少历史包袱。Repo Wiki 和知识图谱覆盖了大部分模块间的依赖关系，但有些看起来多余的中间层背后是十几个调用方，有些兼容逻辑只有写它的人知道当时为什么这么绕。日常迭代改几个模块没问题，但几十个 Agent 要同时在上面写代码，要求不一样。
要在这上面新增 4 个核心大模块：Quest 独立视窗、知识引擎、多工作区并行、专家团协同。上线日期已经定了，3 周时间。
团队 10 个人，3 个人做前端客户端扩展，4 个人做 agent harness，3 个人做知识引擎。每个新模块都要跨组协同。
这个工作量在传统模式下，正常排期至少要翻几倍。这次全新升级也可以一起验证 Agent 在这个量级上的真实产能边界。
量上去之后怎么办？怎么保证几十个 Agent 同时写出来的东西，还能在存量系统里稳定跑下去？
这是接下来三周要解决的问题。
事情到了第三天早上，我们还没让 Agent 写一行新代码。
你也许会觉得这不合理：为什么不让 Agent 先跑起来再说？
因为这两天做的工作，事后证明是整个三周里 ROI 最高的投入。我们先把知识层刷新到最新：
两天，零行代码。全在建地基。
第三天才开始动模块。但动的不是代码，是 Spec。
整个过程里人参与最深的一步，也是复盘时候发现收益最高的一步。
普通的 Spec 写“这个功能要做什么”。Ultra Spec 不一样：先让多个 Agent 并行做广泛调研和深度调研，确保不遗漏，再把结果合并收敛成一份完整的执行方案。Agent 跑得很快，但产出的每一份调研还是需要人来读、来质疑、来拍板取舍。最终这份 Spec 要写到 Agent 可以直接照着跑的程度。
存量工程里做事还多一层考虑：每一项都要从老系统的角度再审查一遍。新功能会影响哪些老模块？新接口跟哪些老接口要兼容？有什么从来没写下来但大家默认在守的规矩？
以团队共享知识引擎中的记忆模块为例，Ultra Spec 需要澄清：什么类型的对话会被提炼、提炼的触发时机、记忆的存储和检索结构、与现有代码索引系统的接口契约、记忆库过大时的降级策略、不同工作区之间记忆隔离的边界。
另一个模块也一样。多 workspace 并行，普通 Spec 写”每个 workspace 独立维护 Quest session，互不干扰” 即可。Ultra Spec 会继续追问：存量系统里有定时任务会短暂锁表，跨夜长跑的 Agent 写入撞上了怎么办？workspace 路径在 IDE 里有目录、.code-workspace 文件、URI 三种格式，新代码兼容了哪几种？Worktree 场景下路径又不一样，考虑到没有？这些问题 Agent 不会主动替你想，不在 Spec 阶段问出来，上线后就是一连串紧急 hotfix。
写完还没完。我们同时起多个 Agent 从不同角度审同一份 Spec：架构师看模块边界，安全专家看权限漏洞，性能专家预判瓶颈，存量系统专家（挂着知识图谱）看兼容性。另外有一个验证者 Agent 专门做反向推导，把 Agent 幻觉导致的假问题挑出来。最后人拍板，重点看 SLO 定义和不可逆操作。
有人会觉得这一步太重了，前期花这么多精力写 Spec 是不是本末倒置？我的体会是，这笔账反过来算：Spec 多花一天，后面省一周。Agent 一旦开始写代码，纠错成本成倍上涨。你不在 Spec 阶段把问题理清，会在联调时乘以十倍地回来找你。
Ultra Spec 写完了，该交给 Qoder 来跑了。知识引擎模块要横跨我们三个组，前端的 IDE 扩展层、Go 后端的 Agent 调度、知识引擎组负责的核心检索逻辑都要动，改动量接近一万行。让一个 Agent 从头串到尾，我们见过会怎样：跑到后半程它会"忘记"前面定的约定。即便 Qoder Desktop 已经支持 1M context window，上下文一长，注意力稀释和上下文腐烂还是会发生。窗口大了不代表每个 token 都能被同等关注。
所以我们启动了 Experts Mode（专家团模式）。
一个 Team Lead 专家不写代码，它只管看 Ultra Spec 的任务清单，理清依赖关系，按 DAG 拆成子任务往下派。有前后依赖的不并行，可能改同一个文件的不同时跑。后端专家、前端专家、测试专家、审查专家各领各的，每个跑在独立上下文里。
那个下午我打开 Quest 任务看板，11 个不同的专家团任务同时在滚。每个专家团任务中，前端专家在做记忆展示组件，后端专家在写存储和检索接口，测试专家在基于 Spec 生成回归用例，调研专家在扫描存量模块的兼容边界。每一个专家都在自己的独立上下文里执行。
以前单 Agent 模式下，Agent 遇到任何选择（A 方案还是 B 方案？加密算法用哪个？）都要停下来问人。现在 Team Lead 来统筹全局，大量中间决策它直接做了，只有不可逆的选择才会主动弹出问题卡片由人来决策。我那个下午几乎没被打断过。
但关键不是快（虽然的确是快）。
是这一个模块里 11 个专家团模式写出来的代码风格、命名、分层方式互相一致；放到全局也一样，4 个模块各自跑多个专家团任务，跨模块的代码也符合团队项目规范。靠的是都刚刷新过的团队共享知识引擎，遵守同一份决策原文。
旁边的同事凑过来看了看我的屏幕，说：“比我们组写的还要优雅。”
这套模式带来的最大变化是执行效率和判断力。
同样一个任务，让单 Agent 从头跑到尾可能要很久，中间还不停问人。换成专家团，能并行的直接并行，Team Lead 替人处理大量中间决策，人只需要在关键节点确认。10 个同事分成三个小组，每组各自跑自己模块的专家团，组与组之间靠知识图谱和 Ultra Spec 对齐边界。三周跑下来上千个子任务（大概每人每天带领 20 几个专家团执行任务，每个专家内部再并行拆），整体执行效率比单 Agent 模式高出一个量级。
另外一个收获：Qoder 的记忆系统在这轮高强度使用中跑出了真正的飞轮效应。专家 Agent 跑完一轮，经验会自动沉淀成 Expert Skill（某个模块的测试环境怎么起、某个接口有哪些历史坑），关键决策会进入知识引擎，过时的信息会被自动遗忘和覆盖。三周里这个效应越往后是越明显的。
第三周结束，50 万行新代码全部进了主分支。Quest 独立视窗、知识引擎、多工作区并行、专家团协同，四个模块集成进 Qoder V1.0。
交付前一晚，四个模块全部就绪。10 个人，3 周，50 万行，这是这套方法跑出来的产能。
人在三周里参与最深的是前面写 Ultra Spec。Agent 并行跑代码的时候，三个组各自在推进下一轮次的：前端组准备下一个模块的交互草图，Agent 组处理 Team Lead 上抛的跨模块决策，知识引擎组配合调研 Agent 校准存量边界。每个人都在做自己最高价值的环节。
Brooks 在《人月神话》里写过：往一个延期的项目里加人，只会让它更晚交付。”不加人，加 Agent“大家也都在积极实践用于生产，但真正跑通的前提不是有 Coding Agent 可用，而是 Agent 能被正确地跑在合适的环境系统里，受约束、守规矩、出了问题能定位回溯。这一步没做好，加 Agent 和加人一样，交付周转周期不会缩短。
复盘项目 1.0 的时候，我们做对了什么：
到这里上篇就讲完了。
但你可能也注意到了一个问题：50 万行 Agent 写的代码，从分支到上线，中间这段我跳过了。Ultra Spec 把方向定准、专家团模式把代码交付后，离"敢合进主分支、敢推上线"还隔着一道护栏。
护栏由两部分组成：写完之后合入之前的 Ultra Review，合入之后人下班机器接班的 Computer Use + Nightly Auto-Heal。Agent 生成代码的速度远远超过人工 Review 的速度，前者是用多 Agent 并行 Review 跟上写代码的速度；后者是让机器自己跑发现-修复-验证的循环，把人挪出 bug 流水线。
这两部分我们叫 Autonomous Engineering。从“人指挥多个 Agent”到“机器自己跑闭环”，方法形态变了。
更多企业解决方案请咨询 ➔
项目启动前夕
我们组日常写代码也是用 Qoder 自己的 Agent，过去 9 个月一直这么跑。V1.0 要回答的问题只有一个：这套干活方式在 3 周要新增数十万行这个量级上是否还成立。
启动前一天晚上，我把两个仓库的模块依赖图摊到三块屏幕上，左边前端，中间后端，右边知识图谱。这次不是日常改几个模块，是 50 万行新代码要铺到 400 万行存量上。每一处可能的接缝都得在动手前看清。
第三天，还没写一行代码
事情到了第三天早上，我们还没让 Agent 写一行新代码。
你也许会觉得这不合理：为什么不让 Agent 先跑起来再说？
因为这两天做的工作，事后证明是整个三周里 ROI 最高的投入。我们先把知识层刷新到最新：
- Repo Wiki 跑了一遍全量更新。这是 Qoder 的产品能力，基于代码、注释、文档、commit history 自动生成仓库级文档，不需要人工干预。这次几十个 Agent 要并行读同一份全局视图，触发了一次全量刷新。
- 代码知识图谱做了一轮深度补全。也是产品能力，自动建模模块依赖、接口契约、数据流向。重点沉淀的是最近一个月新加的模块和接口变更。
- 把历史 Spec 和决策原文补进仓库。commit history 里能看到代码怎么变的，但看不到当时为什么这么设计。有些接口为什么废弃、兼容层怎么来的，只在几个同事脑子里，这次统一整理成文档让 Agent 也能参考。
“Spec 多花一天，后面省一周”
整个过程里人参与最深的一步，也是复盘时候发现收益最高的一步。
普通的 Spec 写“这个功能要做什么”。Ultra Spec 不一样：先让多个 Agent 并行做广泛调研和深度调研，确保不遗漏，再把结果合并收敛成一份完整的执行方案。Agent 跑得很快，但产出的每一份调研还是需要人来读、来质疑、来拍板取舍。最终这份 Spec 要写到 Agent 可以直接照着跑的程度。
存量工程里做事还多一层考虑：每一项都要从老系统的角度再审查一遍。新功能会影响哪些老模块？新接口跟哪些老接口要兼容？有什么从来没写下来但大家默认在守的规矩？
以团队共享知识引擎中的记忆模块为例，Ultra Spec 需要澄清：什么类型的对话会被提炼、提炼的触发时机、记忆的存储和检索结构、与现有代码索引系统的接口契约、记忆库过大时的降级策略、不同工作区之间记忆隔离的边界。
另一个模块也一样。多 workspace 并行，普通 Spec 写”每个 workspace 独立维护 Quest session，互不干扰” 即可。Ultra Spec 会继续追问：存量系统里有定时任务会短暂锁表，跨夜长跑的 Agent 写入撞上了怎么办？workspace 路径在 IDE 里有目录、.code-workspace 文件、URI 三种格式，新代码兼容了哪几种？Worktree 场景下路径又不一样，考虑到没有？这些问题 Agent 不会主动替你想，不在 Spec 阶段问出来，上线后就是一连串紧急 hotfix。
写完还没完。我们同时起多个 Agent 从不同角度审同一份 Spec：架构师看模块边界，安全专家看权限漏洞，性能专家预判瓶颈，存量系统专家（挂着知识图谱）看兼容性。另外有一个验证者 Agent 专门做反向推导，把 Agent 幻觉导致的假问题挑出来。最后人拍板，重点看 SLO 定义和不可逆操作。
有人会觉得这一步太重了，前期花这么多精力写 Spec 是不是本末倒置？我的体会是，这笔账反过来算：Spec 多花一天，后面省一周。Agent 一旦开始写代码，纠错成本成倍上涨。你不在 Spec 阶段把问题理清，会在联调时乘以十倍地回来找你。
“比我们组写的还要优雅”
Ultra Spec 写完了，该交给 Qoder 来跑了。知识引擎模块要横跨我们三个组，前端的 IDE 扩展层、Go 后端的 Agent 调度、知识引擎组负责的核心检索逻辑都要动，改动量接近一万行。让一个 Agent 从头串到尾，我们见过会怎样：跑到后半程它会"忘记"前面定的约定。即便 Qoder Desktop 已经支持 1M context window，上下文一长，注意力稀释和上下文腐烂还是会发生。窗口大了不代表每个 token 都能被同等关注。
所以我们启动了 Experts Mode（专家团模式）。
一个 Team Lead 专家不写代码，它只管看 Ultra Spec 的任务清单，理清依赖关系，按 DAG 拆成子任务往下派。有前后依赖的不并行，可能改同一个文件的不同时跑。后端专家、前端专家、测试专家、审查专家各领各的，每个跑在独立上下文里。
那个下午我打开 Quest 任务看板，11 个不同的专家团任务同时在滚。每个专家团任务中，前端专家在做记忆展示组件，后端专家在写存储和检索接口，测试专家在基于 Spec 生成回归用例，调研专家在扫描存量模块的兼容边界。每一个专家都在自己的独立上下文里执行。
以前单 Agent 模式下，Agent 遇到任何选择（A 方案还是 B 方案？加密算法用哪个？）都要停下来问人。现在 Team Lead 来统筹全局，大量中间决策它直接做了，只有不可逆的选择才会主动弹出问题卡片由人来决策。我那个下午几乎没被打断过。
但关键不是快（虽然的确是快）。
是这一个模块里 11 个专家团模式写出来的代码风格、命名、分层方式互相一致；放到全局也一样，4 个模块各自跑多个专家团任务，跨模块的代码也符合团队项目规范。靠的是都刚刷新过的团队共享知识引擎，遵守同一份决策原文。
旁边的同事凑过来看了看我的屏幕，说：“比我们组写的还要优雅。”
上千个子任务，10 个人
这套模式带来的最大变化是执行效率和判断力。
同样一个任务，让单 Agent 从头跑到尾可能要很久，中间还不停问人。换成专家团，能并行的直接并行，Team Lead 替人处理大量中间决策，人只需要在关键节点确认。10 个同事分成三个小组，每组各自跑自己模块的专家团，组与组之间靠知识图谱和 Ultra Spec 对齐边界。三周跑下来上千个子任务（大概每人每天带领 20 几个专家团执行任务，每个专家内部再并行拆），整体执行效率比单 Agent 模式高出一个量级。
另外一个收获：Qoder 的记忆系统在这轮高强度使用中跑出了真正的飞轮效应。专家 Agent 跑完一轮，经验会自动沉淀成 Expert Skill（某个模块的测试环境怎么起、某个接口有哪些历史坑），关键决策会进入知识引擎，过时的信息会被自动遗忘和覆盖。三周里这个效应越往后是越明显的。
三周结束
第三周结束，50 万行新代码全部进了主分支。Quest 独立视窗、知识引擎、多工作区并行、专家团协同，四个模块集成进 Qoder V1.0。
交付前一晚，四个模块全部就绪。10 个人，3 周，50 万行，这是这套方法跑出来的产能。
人在三周里参与最深的是前面写 Ultra Spec。Agent 并行跑代码的时候，三个组各自在推进下一轮次的：前端组准备下一个模块的交互草图，Agent 组处理 Team Lead 上抛的跨模块决策，知识引擎组配合调研 Agent 校准存量边界。每个人都在做自己最高价值的环节。
Brooks 在《人月神话》里写过：往一个延期的项目里加人，只会让它更晚交付。”不加人，加 Agent“大家也都在积极实践用于生产，但真正跑通的前提不是有 Coding Agent 可用，而是 Agent 能被正确地跑在合适的环境系统里，受约束、守规矩、出了问题能定位回溯。这一步没做好，加 Agent 和加人一样，交付周转周期不会缩短。
复盘项目 1.0 的时候，我们做对了什么：
- 认知地基（Repo Wiki + 代码知识图谱 + 历史 Spec）：让 Agent 读懂存量代码的现状和来龙去脉，不用反复对齐上下文
- Ultra Spec（先发散后收敛的 Spec + 多 Agent 交叉审查）：动手之前把歧义和返工风险摊开，省掉联调时互相推翻
- 专家团协同（Team Lead + 专项 Agent 并行）：大任务拆成可并行的子任务跑出去，不卡在单线程
故事还没结束
到这里上篇就讲完了。
但你可能也注意到了一个问题：50 万行 Agent 写的代码，从分支到上线，中间这段我跳过了。Ultra Spec 把方向定准、专家团模式把代码交付后，离"敢合进主分支、敢推上线"还隔着一道护栏。
护栏由两部分组成：写完之后合入之前的 Ultra Review，合入之后人下班机器接班的 Computer Use + Nightly Auto-Heal。Agent 生成代码的速度远远超过人工 Review 的速度，前者是用多 Agent 并行 Review 跟上写代码的速度；后者是让机器自己跑发现-修复-验证的循环，把人挪出 bug 流水线。