大型代码库里的 AI，真正先放大的不是写代码，而是“理解代码”

这篇分享最有价值的地方，不是又一次鼓吹 AI 写代码，而是把一个更容易被忽略的事实说透了：在大型代码库里，真正提升产出的常常不是生成能力，而是理解能力。

本文整理自 Sentry 工程师 Priscila Andre de Oliveira 在 AI Engineer 活动上的一场分享。她讲的不是“如何用 AI 一把梭地生成代码”，而是另一个更接近真实工程现场的问题：当代码库已经有 15 年历史、每天合入约 100 个 PR、上百个工程师持续改动时，AI 最先改变的到底是什么？她给出的答案很直接：不是生成，而是理解。原视频：https://www.youtube.com/watch?v=li0SaBt9RDM

过去一段时间，行业里最热闹的话题是 agent、自动编程、vibe coding，很多演示也都围绕“几分钟做出一个应用”展开。但只要你离开 demo 环境，进入真实公司的主仓库、遗留系统、多人协作链路、上线责任和回滚压力，问题就会立刻变样。真正消耗团队时间的，往往不是“怎么把代码写出来”，而是“先把这个系统理解对”。

Priscila 的这场分享可贵就在这里。她没有把 AI 描述成一个替代工程师的写代码机器，而是把它定位成一个永远不会嫌你问题多的理解伙伴。这个定位一旦成立，很多关于 AI 编程的讨论，重点就会跟着移动：从生成速度，转向认知对齐；从 prompt 技巧，转向持续上下文；从“能不能做”，转向“做之前到底有没有想明白”。

她真正描述的，不是“AI 写代码”，而是“工程师变成 agent manager”

分享开头很轻松。Priscila 自嘲自己虽然职称还是 senior software engineer，但已经给自己升职成了 “agent manager”。没有加薪，但至少“下属”不会抱怨。这个玩笑背后，其实点中了一个正在发生的身份变化：在 AI 原生工作流里，人的价值正在从“亲手写每一行代码”转向“组织、约束、校正和验证一组 agent 的工作”。

这和你知识库里强调的那个判断是同一条线：创始人也好，工程师也好，瓶颈越来越不是工作量，而是系统化程度。人不再只是单点产出者，而更像是编排者。问题不在于你能不能让 agent 开工，而在于你是否给了它稳定上下文、边界条件和验收标准。没有这些，agent 只会把局部正确不断堆成整体混乱。

Priscila 在 Sentry 的环境尤其能说明这一点。Sentry 不是一个可以随便“vibe 一下”的小项目，而是一个有 15 年代码积累、约 400 名员工、10 万组织依赖的复杂平台。每天大约 100 个 PR 合入，组件、规范、lint 规则、功能边界都在移动。这样的仓库里，任何“我先让模型改改看”的轻率操作，最后都可能变成冲突、回归、技术债，甚至直接影响发薪水的系统稳定性。

所以她反复强调一句非常现实的话：不要把 slop code 发进那个给你发工资的代码库里。这句话听起来像段子，其实是大型工程团队引入 AI 时最核心的底线。

大仓库里的第一生产力，不是生成，而是 comprehension

这场分享最值得记住的数据只有一组：Priscila 让 Claude 分析了自己 116 个日常工作 session，结果发现 67% 的使用都属于 comprehension，真正的 code generation 只有 2%。这个结论很重要，因为它把很多人对 AI 编程的想象彻底翻了过来。

主流叙事总是把 AI 的价值放在“替你写”。但在复杂系统里，最先产生杠杆的常常是“替你找、替你解释、替你补上下文”。比如一次线上事故，过去她需要自己翻 GitHub、跑 git blame、找回归点，再顺着提交链理解是谁在什么上下文里改坏了；现在她先问 AI，几秒内先拿到一版可讨论的解释。又比如某个产品决策为什么变了，以前可能要去 Slack 里追问另一个时区的同事，第二天才有答案；现在她先从 AI 那里拿到一个高概率正确的背景框架，再决定还要不要继续追人。

这里真正被压缩掉的，不只是查资料时间，而是认知切换成本。大型代码库最贵的东西，从来不是打字，而是“重新进入上下文”。你每次从一个子系统跳到另一个子系统，从某个 PR 跳到一段历史决策，从当前 bug 跳到旧架构约束，本质上都在支付巨额的理解税。AI 如果能先把这笔税降下来，工程效率自然就上去了。

这也和你知识库里那条“shared mental model”的原则高度一致。没有共享心智模型，每次会话都像重新推导一次架构，局部看上去都对，整体却拼不起来。Priscila 的实测数据，本质上是在给这个判断补实证：AI 最先改善的不是产出动作，而是心智模型建立速度。

她做的“Catch Me Up” skill，本质上是在把高频理解动作产品化

因为这些 comprehension 型 prompt 一直重复，Priscila 最后没有继续把它们散落在一条条临时对话里，而是做成了一个叫 “Catch Me Up” 的本地 skill。这个 skill 把高频理解任务拆成六种探索模式：architecture、convention、feature trace、syntax、testing、history。

这一步特别关键。它意味着她已经不再把 AI 当搜索框，而是在把自己的理解流程固化成可复用能力。这和“skills 正在替代 prompting”的趋势是一回事：普通 prompt 是一次性的，session 结束就蒸发；skill 则把目标、流程、输出结构和质量标准提前装进去，让模型在真正开工前就进入正确工作姿态。

如果把这个动作翻译成更工程化的语言，它其实是在给 agent 增加一层认知脚手架。你不是问一句“帮我看看这个仓库”，而是明确规定：先看架构、再看约定、再追功能链路、再补测试面和历史演化。这样做的价值，不只是答案更完整，而是它能持续产出稳定格式，让人更快判断结果是否可信、哪里还缺口、下一步该深入哪一层。

Priscila 还提到自己是一个偏视觉的人，所以这个 skill 会尽量输出结构图、表格、流程化解释，帮助自己更快建立整体认知。这一点也值得注意：好 skill 不是抽象地“让模型更聪明”，而是让模型按你的认知习惯交付可用结果。换句话说，skill 不只是知识模板，还是工作界面的个性化配置。

真正缺的不是 research/planning/implementation，而是“理解研究结果”这一层

演讲后半段，她拿 Jack Morris 关于 vibe coding 的讨论做了一个很好的补充。很多人现在都接受了一个三段式流程：research、planning、implementation。看起来很完整，但 Priscila 认为这还少了一步：你必须先理解 agent 研究出来的东西，再决定要不要继续计划和实施。

这是一个非常容易被忽略、但后果很重的判断。因为 agent 的 research 结果并不天然等于你的 understanding。模型可能已经替你扫了一遍仓库、列出了一堆组件、总结了一套实现路径，但如果你自己没有真正消化这些结论，就无法判断它有没有走偏，也无法在关键节点及时修方向。最后常见的结果就是：计划很流畅，实现也很快，可一旦落到真实系统里，才发现前提理解错了。

这正是很多 agentic 开发事故的源头。不是模型不会写，而是人类把“模型已经研究过”误当成“我已经理解了”。前者只是外包了一轮探索，后者才是你能承担决策责任的起点。

从这个角度看，Priscila 这场分享其实是在给当下的 AI 编程热潮补一条很重要的刹车线：研究、计划、实现都可以越来越自动，但“认知对齐”这一步不能直接跳过。你至少要能回答三件事：问题空间是什么，系统约束是什么，模型现在的路径为什么成立。如果这三件事没过，人就不该把实现权彻底放出去。

这背后不是保守，而是对技术债的重新定义

Priscila 还提到 Sentry 去年专门做过一个持续三个月的 quality quarter，用来清理 any type、TODO、无用 feature flag 和其他技术债。这段内容看似与 AI 无关，其实关系很大。

因为 AI 放大产出速度之后，技术债的形成方式也变了。传统技术债通常是有意识的：团队知道先欠一笔，以后再还。而 agentic 技术债更危险的地方在于，它经常是无意识漂移。每次 session 都在没有稳定 spec、没有统一上下文、没有共享 mental model 的前提下重新推导一遍系统，于是每次都能做出“能运行的局部正确”，最后却累积出完全没有整体设计感的系统。

你知识库里把这件事说得很透：AI 生成的技术债不是普通欠账，而是架构假设持续 drift。Priscila 的经验则给了一个工程一线版本的佐证：如果你不先把理解这一步做好，AI 不会只帮你加速交付，也会帮你加速污染代码库。

所以她的结论并不反 AI，恰恰相反，她是非常激进的 AI 使用者。但她的激进，不是“什么都交给模型”，而是“把模型用在最能降低复杂度的地方”。这就是成熟团队和 demo 思维之间的差别。

这场分享对中文工程团队最有启发的，可能是工作流设计而不是某个工具名字

很多人看这种演讲，第一反应会是：她用的是 Claude，我是不是也要照搬一个同款 skill？其实没那么重要。真正值得抄作业的，不是具体模型，也不是那六个 mode 的字面分类，而是她对工作流的切分方式。

第一，先承认 comprehension 本身就是高价值工作，而不是生成前的附属动作。只要你在大仓库里工作，这一步就不是可有可无的铺垫，而是主生产环节。

第二，把高频理解动作从临时 prompt 升级成稳定 skill。这样才能减少上下文重建，持续积累属于你自己的提问框架和输出规范。

第三，把“我让 agent 研究过”与“我真的理解了”明确分开。任何 plan 和 implementation 之前，都要先过一次自己的 mental model 校准。

第四，把 AI 引入代码库这件事，和质量治理放在同一个系统里看，而不是拆成两个话题。否则你会一边享受加速，一边悄悄吞下更大的熵增。

对国内很多团队来说，这比“选 Claude 还是 Gemini，选哪个 CLI，开几个 agent 并发”更重要。工具层每个月都在变，但工作流里对 comprehension 的优先级、对 shared mental model 的要求、对技术债漂移的警惕，才是能长期复用的部分。

最后一句话其实最实在：先把脑子对齐，代码自然会流出来

Priscila 最后的收束很漂亮。她说，AI 在大型代码库里最大的 unlock 不是 generation，而是 comprehension；AI 是那个永远不会嫌你问题蠢的队友；而在你开始 prompt 之前，先把自己的 mental model 对齐，后面的代码会自然流出来。

这句话之所以成立，不是因为它听上去正确，而是因为它抓住了一个真实的软件工程事实：在复杂系统里，代码往往不是最难的部分，理解才是。你一旦把理解做对，代码只是把已经想清楚的结构写出来；但如果理解没对，再强的生成能力也只是在更快地产生偏航结果。

所以如果要把这场分享压成一句适合贴在团队墙上的话，大概就是：在大仓库时代，AI 最先替你放大的不是手速，而是认知带宽。

这也是为什么真正成熟的 AI 工程实践，最后都会回到同一个方向：不是追求“让模型替我做更多”，而是先建立“我怎么更快、更稳地把系统理解对”。

附录：视频里的关键信息点

• 演讲标题：Comprehend First, Code Later: The AI Skill I Rely On Daily
• 演讲者：Priscila Andre de Oliveira，Sentry
• 视频时长：约 17 分钟
• 关键数据：她自测的 116 个 session 里，67% 属于 comprehension，2% 属于 code generation
• 核心 skill：Catch Me Up
• 六种探索模式：architecture、convention、feature trace、syntax、testing、history
• 原视频频道：AI Engineer