百万行代码项目的 AI Native 实战：从踩坑到落地

网上刷到一条帖子，一个团队在维护百万行代码的超大项目——8 个 repo，前后端加起来代码量过百万。他们分享了从 AI Native 化摸索到落地的全过程，踩了不少坑，最后找到一条可行的路。我整理了一下关键点。

很多人直觉觉得"上下文越多越准"，实际测下来完全相反。他们团队跑了很多轮实验，发现上下文用到 40-50% 的时候幻觉率最低。过了这个点，幻觉率开始往上走。跟人的情况差不多——信息太多的时候，反而容易胡扯。

这条经验直接打翻了"知识库越丰富越好"的直觉。

他们第一版方案看着挺合理：每个 repo 单独产出 wiki，模块级 RAG 检索，代码级 spec 构建。但实际跑起来发现，知识检索层的上下文膨胀是指数级的。wiki 越详细，上下文越炸，最后不得不把整套废弃。

既然完整知识图谱走不通，那就剪枝。他们改成了另一套思路：不是给 AI 更多知识，而是严格控制每次给 AI 的上下文边界。走最短路径找依赖。

具体怎么做？三层检索，每层都做剪枝。

第一层只做路由定位，不深入。用俗称或路由快速定位到具体的 repo 和主要调用内容。别让 AI 去"理解"项目结构，直接给最短的路。这一步是避免 agent 对项目深思考、被非标称呼误导。

第二层锁定改动范围，不追到底。确定 repo 之后，只检索主要入口和文件调用链，把需求改动会波及的范围划出来，够了就停，不继续下钻。

第三层以代码本身为 spec。核心文件确认后，不再靠 wiki 描述，直接用代码挖细节调用和依赖关系。组件、API 的实现细节有专门的 skill 或 CLI 支撑。

说到底，这套逻辑的本质是控制上下文边界。知道什么不该给，比知道该给什么更难。

前后端协作上他们也踩了坑。最初想用一次 agent task 完成前后端开发，模型吃不消。teams 的反馈汇总到 main agent，上下文还是炸。最后改成拆两个 session：一个做 server，一个做 fe。

怎么保持连贯性？用 spec 做中间件。先一轮需求澄清加代码图谱产出，留存 spec 对抗冲突后压缩一次，compact 上下文加方案 spec 分别给到两个 session，各跑各的，通过留存 spec 和多轮执行保持任务连续性。说白就是别在一个 session 里硬扛整个任务的上下文。

并发执行也有好处：速度快，上下文风险分摊。每个 subagent 只管自己那部分的上下文，不会出现单个 agent 窗口爆炸。

这套方案跑下来，他们测出一个数字：0 人工介入的情况下，代码有效率在 95 分位。百万行代码的项目，两个人配合 AI 维护迭代，已经不是理论了，是正在跑的现实。

还有两件事值得说。路径图谱的上下文膨胀是指数级的，不管用什么工具，只要项目量级起来了，这个问题都绕不过去，所以检索层必须做剪枝。另外 thinking model 有边界——优化到一定程度后再继续优化，反而出现负优化。核心原因还是上下文：给 LLM 的上下文越多，期望产出越精细，但详细知识占用的窗口会导致幻觉率上升。这跟"大力出奇迹"的直觉相反，但符合实际工程经验。

这套方法论的核心说到底就是四件事：控制上下文边界、剪枝检索、spec 做中间件、分摊上下文风险。

整理自网友分享