用 Qoder 开发 Qoder——在 400 万行存量工程上新增 50 万行代码，3 周交付的完整方法论
这不是从零开始
今年我们对外发布过一个案例：5 人团队用 7 天，用 Qoder 开发出 QoderWork，传统方式得 20 人花数周才能交付。
那个案例是从零到一的新项目——干净的代码库，规则自己定，架构自己设计，AI 在白纸上写代码，没有历史包袱。
这篇文章要讲的是另一个故事——这次 AI 面对的不是白纸，而是一个跑了多年、横跨多个仓库、几百万行代码堆起来的存量工程。
我们要升级的是 Qoder 自身。Qoder 的工程是一个真实运转中的复杂系统：前端是 VS Code IDE 扩展代码，后端是 Go 编写的 Agent 调度、知识引擎和多模型调用系统，前后端独立仓库，总代码量约 400 万行。历史架构决策散落在代码各处，模块间的隐性依赖从未被完整文档化，任何大改动都可能引发连锁反应。
我们要在这个系统上新增一个 50 万行级别的全新功能模块——Qoder V1.0 的 Quest 全面升级，包含：
- 全新 Quest 独立视窗：像派活一样指挥 AI，彻底重新设计的交互范式
- Editor 全面焕新：编码体验的系统性升级
- 知识引擎：代码沉淀为知识，对话中提炼记忆，让智能体越用越聪明
- 多工作区多任务并行：跨项目协同，多任务并行交付
- 专家团协同 + 自定义专家：并行分工，灵活配置
地基先行：让 AI 真正读懂 400 万行代码
把 AI 引入存量工程，第一个拦路虎不是"AI 不够聪明"，而是 AI 根本不知道这个系统里发生过什么。
LLM 的 context window 是有限的，400 万行代码不可能全部喂进去。更难的问题是，即使能喂进去，AI 也不知道哪些是重要的架构约定，哪些是历史遗留的妥协，哪些接口看起来可以改但实际上有十几个调用方在依赖它。
一个对存量工程一无所知的 AI，写出来的新代码就是"外来物"——风格不统一，接口不兼容，悄悄违反了几条从未写在文档里的潜规则，然后在联调时爆炸。
我们的解法是在动手写代码之前，先把"AI 的认知基础设施"搭起来。一共三层：前两层是 Qoder 自带的产品能力——Repo Wiki 给宏观架构视图，代码知识图谱给精确的调用关系。第三层是我们自己补的工程实践——把每次重大变更的 Spec 和决策原文留在仓库里，让 AI 不只能看到现在长什么样，还能往回查为什么变成这样。我们用 Qoder 开发 Qoder，正好把这三层做透了。
第一层：Repo Wiki（Qoder 内置能力）
基于代码自动生成、会跟着代码变更一起更新的仓库级文档，覆盖项目整体架构、模块边界、核心数据流以及跨模块的引用关系图谱。它把分散在 400 万行代码里那些散落的结构关系整理成一份能直接读的项目文档——代码本身能告诉你单个文件在做什么，但说不清系统整体是怎么组织的，Repo Wiki 正是补上这一层全景视图。
Repo Wiki 相当于给 AI 配了一份"项目地图"。新来的 AI 不需要逐文件爬取去拼装系统结构，直接读这份地图就能上手，知道模块怎么划分、依赖怎么走、关键路径在哪里。
第二层：代码知识图谱（Qoder 内置能力）
通过静态分析结合 AI 理解，对整个代码库做结构化建模：模块依赖关系、接口契约、数据流向、核心数据结构的读写路径。这不是简单的调用关系图，而是一个可查询的知识库。
AI 在生成新代码时，可以实时查询："这个接口目前有哪些调用方？"、"这个数据结构在哪些地方会被修改？"、"新的 Quest 视窗如果要复用这个组件，会影响哪些已有功能？"
Repo Wiki 让 AI 看到项目大致是个什么样子，知识图谱让 AI 能查到具体每个接口的调用情况。一粗一细，是 Qoder 自带的两面。
第三层：历史 Spec 档案（工程实践沉淀）
前两层都来自 Qoder 自身的产品能力，能让 AI 看清"系统现在长什么样"。但还缺一层——这套架构是怎么演化到今天这样的。某个接口为什么被废弃、某个看似多余的兼容层是在应对哪次线上事故，这些决策的来龙去脉往往只存在于当事人的记忆里。人一走就彻底失联，下一波重构只能凭代码反推意图，把当年踩过的坑再踩一遍。
这一层不是产品功能能直接给的，得靠工程纪律把它沉淀下来。我们在仓库里把每次重大变更的 Spec 和决策原文一并留下来。AI 修 bug 或加新功能时，不只能看到"现在长什么样"，还能回溯"为什么会变成这样"。仓库不只是当下代码的快照，还多了一份能往回查的工程档案。
两层产品能力加一层工程实践，地基才算齐。少了任何一层，AI 写的代码都是在沙地上盖房。
Ultra Spec：动手之前，先把 Spec 写透
地基打好之后，我们不急着写代码。QoderWork 那一波的第一步就是"不写代码、只写 Spec"，放到存量工程里，这条原则要执行得更彻底——一旦 AI 开始生成代码，纠错的成本会急剧上升。我们把这个阶段叫做 Ultra Spec。
普通 Spec 描述功能是什么，Ultra Spec 描述功能的每一个维度，精确到 AI 能直接照着做，把会导致返工的问题在 Spec 阶段就摊开。它有一套固定维度：功能目标、I/O 契约、业务规则、边界 Case、安全边界、测试计划等。每一维都要写到机器可读——I/O 用 JSON Schema 而不是描述性文字，业务规则每条对应具体输入输出，安全边界用"必须做 / 先询问 / 严禁做"三级权限。
放到存量工程里，每一项还要再叠一层"存量视角"：功能目标说明影响哪些存量模块，I/O 契约对齐既有接口、明确向前兼容，业务规则把存量系统的隐性规则显式写出来、不能靠 AI 猜，边界 Case 覆盖历史脏数据，安全边界列出不能碰的代码区，测试计划必带对存量功能的回归。少了这层视角，AI 写出来的就是外来物。
以知识引擎模块为例，它的 Spec 不只是"对话中提炼记忆"这句话，而是要精确定义：什么类型的对话会被提炼、提炼的触发时机、记忆的存储与检索结构、与现有代码索引系统的接口契约、记忆库过大时的降级策略、不同工作区之间记忆隔离的边界规则。每一条都要有具体的输入输出定义，不允许出现"视情况而定"。
Spec 写完不是终点，而是进入多 Agent 交叉 Review 阶段。我们会同时启动多个不同视角的子 Agent 独立审查同一份 Spec：架构师视角检查模块边界和接口设计，安全专家视角排查权限漏洞和数据泄露风险，性能专家视角预判慢查询和高频调用瓶颈，存量系统专家视角（基于知识图谱）检查与现有代码的兼容性。之后再走一轮验证：独立的验证者 Agent 对所有识别出的缺陷做反向推导，剔除幻觉产生的虚假问题。最终由人做决策授权，重点集中在涉及 SLO 定义和不可逆操作的部分。
Ultra Spec 阶段投入的时间是有杠杆的。这边多花一天，后面调试和返工能省下好几倍。
专家团协同：把 Spec 跑成可并行的工程
Ultra Spec 把一个模块的需求拆成了依赖清晰的结构化计划，但落地时还有一道关。像知识引擎、多工作区并行这样的单个模块就横跨前端 IDE 扩展、Go 后端、Agent 调度、模型调用链路几千到上万行的改动，如果仍然让一个 Agent 从头串到尾，Ultra Spec 花力气识别出来的可并行任务会被硬生生拉成单线程，长上下文下的注意力稀释还会让前期定下的约定在后半段悄悄丢掉。Qoder 早期版本里就出现过这种尴尬：一个 Agent 任务跑到后半程，明显感觉它已经"不记得"开头。
专家团模式（Experts Mode）就是为了补这一段做的。它由一个 Team Lead 和若干专项 Agent 组成。Team Lead 不写代码，只读懂 Ultra Spec 的任务清单、识别依赖、按 DAG 顺序把活派给后端、前端、测试、审查、调研等专家，每个专家跑在独立上下文里互相不挤占。这跟"同时开几个 Agent 窗口"的本质区别在于后者没有协调，专家团把 Ultra Spec 识别出的 DAG 直接翻译成执行计划，前后端能同时推进。遇到执行中的模糊选择（加密算法用哪个、兼容策略是降级还是报错），Team Lead 会抛候选项让人拍板再派工，不让 AI 按猜测闷头跑。
专家团也不强制所有专家都用同一款顶级模型。调研员、初始化通用工程师这类轻角色跑便宜快模型，架构关键决策的 Reviewer、复杂重构工程师跑顶配模型，整体成本降到全员用顶配的 1/2 到 1/5，而关键路径的智能水位没掉下来。三周跨度里跑了成百上千个子任务，每个都调最贵的模型账单会爆炸，全用便宜的关键节点质量没有保障，异构调度正好落在这条预算曲线上。
专家团还会把这次积累的经验留下来：每个专家沉淀 Expert Skill（某个模块的测试环境怎么起、某个接口有哪些历史坑），团队层面沉淀 Team Skill（哪类任务用哪种派工顺序最顺）。下一轮遇到同类活，这些经验可以直接接上。
Ultra Review：替人挖出 AI 代码里的细节问题
新矛盾随之而来：AI 生成代码的速度远远超过人工 Review 的速度。
Qoder 同时运行多个 Quest 并行执行任务——知识引擎、多工作区并行、专家团协同，这些模块可以同时推进，每个模块每天可能产出数千行代码。Review 如果还是线性的、单人的，立刻就是整条流水线的瓶颈，AI 跑得再快也被抵消掉。
我们的解法是 Ultra Review，把代码审查从单线程改成多 Agent 并行。
具体做法是给每个 PR 同时派一组 Agent 并行 Review。这些 Agent 从不同的代码起始位置开始扫描，采用不同的路径和上下文载入顺序，用来抵消 LLM 的 context window 偏置——单个 Agent 从头到尾读代码，容易在后半段注意力"稀释"，漏掉问题。并行扫完之后再做一轮 Verify 和 Dedup：剔除幻觉产生的误报，把多个 Agent 重复发现的同一问题合并。
Review 聚焦几个核心维度：正确性、安全性、性能、架构一致性、可维护性等。其中架构一致性在这个项目里特别要命——50 万行新代码如果跟存量系统的架构风格脱节，技术债会指数级长。每一次 AI 生成的代码都要检查：命名是否符合存量约定？分层是否与现有模块一致？有没有绕过存量抽象层直接操作底层？
Ultra Review 就一条原则：盯逻辑错误，别纠结样式。样式交给 Linter 和格式化工具，AI 的 Review 算力留给真正重要的事。
Computer Use 自动化验证：AI 长出了眼睛和手
代码写完、Review 通过，还需要验证功能是否真的正确。
传统自动化测试的问题是：写测试脚本本身就是大量工作，而且脚本往往只覆盖 Happy Path，边界 case 需要额外编写，维护成本随着代码量线性增长。
Computer Use 让这个环节换了思路。
Qoder 直接接管本地开发环境，通过截屏、坐标定位、模拟键盘鼠标，像真人一样操作。你不需要写测试脚本，只需要描述要验证的功能，剩下的交给 AI：
- 自动拉起 IDE，确认代码状态
- 运行项目，等待服务启动
- 打开浏览器或 IDE 界面，执行完整的业务流程
- 验证结果是否符合 Spec 中定义的预期输出
- 覆盖边界 case：空输入、权限边界、并发场景、存量数据兼容性
Nightly Auto-Heal：让机器在你睡觉时工作
到这一节，方法的形态变了。前面那几节 AI 始终是协作者，人在环里把关——这是 Agentic Engineering。Nightly Auto-Heal 把人挪出闭环，让机器自己跑发现-修复-验证的循环，正式进入 Autonomous Engineering 的阶段。
验证发现的问题、人工测试发现的 bug、CI 失败、日志报警——所有这些 issue 会进入一个统一的处理队列。
晚上收工之后，Nightly Auto-Heal 流程自动启动。
三周之后
三周，50 万行新代码，99% 由 AI 生成。
Quest 独立视窗、知识引擎、多工作区并行、专家团协同——这些功能全部集成进 Qoder V1.0 并对外发布。
但这篇文章真正想说的，不是这个数字。
数字背后更重要的是：我们跑通了两套相互衔接的方法——Agentic Engineering 让 AI 在人监督下高质量协作，Autonomous Engineering 让机器在人离场之后继续跑闭环。
存量巨型工程跟空白项目的区别，在于认知负担。空白项目的 AI 可以自由发挥，存量工程的 AI 必须先被"驯化"——它需要知道这个系统经历过什么，约定过什么，不能碰什么。
这套方法的五层结构，对应五个不同的作用：
| 层次 | 工具 | 作用 |
|---|---|---|
| 地基 | Repo Wiki + 代码知识图谱 + 历史 Spec 沉淀 | 让 AI 看懂 400 万行存量代码的现状与演化 |
| 杠杆 | Ultra Spec + 多 Agent 交叉 Review | 在写代码之前，把会导致返工的问题先摊开 |
| 执行 | 专家团协同（Leader + 专项 Agent + 工程知识引擎） | 把 Spec 的依赖图跑成可并行的工程交付 |
| 护栏 | Ultra Review 多 Agent 并行 | 跟上 AI 的生成速度，挖出代码里的细节问题 |
| 飞轮 | Computer Use 验证 + Nightly Auto-Heal | 把发现-修复-验证跑成自动闭环 |