Qodo CEO详解AI代码审查：当「智慧」比代码本身更值钱

在OpenAI DevDay 2026的现场访谈中，Qodo（原CodiumAI）创始人兼CEO Itamar Friedman分享了一个颇具野心的愿景——打造「最后一次人类代码审查」。他们的客户把Qodo形容为「Codex的最佳搭档」：一边收集工程团队的隐性知识喂给Codex，一边在Codex写代码时对其进行审查，目标是从源头生成干净、清晰的PR。

这场对话不只是产品宣传，更触及了AI编程时代一个核心命题：当模型越来越聪明，人类工程师在软件工厂里到底扮演什么角色？

从提示工程到「群体工程」的三次跃迁

Itamar回顾了Qodo技术路线的三个阶段。2023年前后，行业还把「提示工程（prompt engineering）」当成一门专门职业，用来构建简单的问答能力，这也是当时模型参与编程竞赛的方式。

2024年，Qodo发表了名为 Alpha Codium 的论文，提出不应把模型使用停留在来回问答上，而应该把开发者的完整工作方式「下载」下来，作为一个整体流程来设计——这就是「流程工程（flow engineering）」。

到了今天，模型已经能自己构建工作流，但真正有价值的环节变成了「群体工程（swarm engineering）」：设计多个agent，明确定义各自的目标、工具、护栏和策略。Itamar特别提醒，让agent自行派生子agent、自定义工具目前仍然很早期，而且可能非常浪费资源。他援引OpenAI一位演讲者的警告指出，对于一个以「建立信任」为核心的产品来说，输出必须有数据支撑，swarm必须为自己的工作提供证据。

Alpha Codium 是Qodo于2024年发表的研究成果，核心思路是通过「测试驱动的迭代流程」替代单次提示生成代码的方式。具体而言，模型不再一次性输出完整代码，而是先理解问题规格，生成公开与私有测试用例，再对代码进行反复迭代修正，直至通过所有测试。在代码竞赛基准 HumanEval 和 CodeContests 上，这一方法相比直接提示（zero-shot）的正确率提升幅度显著。这篇论文将「流程设计」的重要性提升到了与模型本身同等的地位，也奠定了Qodo后续向agent化方向演进的理论基础。

「智慧」与「智能」的分野

访谈中最有启发性的部分，是Itamar对intelligence（智能）和wisdom（智慧）的区分。他用一条递进链条来解释：原始数据 → 信息 → 知识 → 智能，而通往「智慧」的那一跃，关键在于经验。

智能可以类比为大脑本身，而经验只有通过一个完整的系统、完整的身体才能获得。专业开发者的独特之处，正是通过经验理解软件如何运作。

这正是Qodo试图「编码化（codify）」的东西。如果你想搭建一个端到端的软件工厂，让人类更多地处理策略、管理swarm，就必须把这种经验、这种智慧沉淀下来。Qodo把这套机制称为 wisdom base（智慧库），并坦言在某些情况下，这些智慧比代码本身更有价值。

本地看起来没问题，整体却可能崩

Itamar举了一个真实客户案例来说明审查agent的价值。这家公司服务数百万中小企业，允许它们高度灵活地构建应用，甚至能近乎直接访问数据库。因此大量代码改动都在触碰数据库。

问题在于：一处改动在局部看起来完全正常，没有语义错误，但放到整个软件系统里考量，却可能在下游触发巨大的服务中断。这种跨组件的下游影响，对很多编程agent来说极难发现，对人类审查者同样困难。

Itamar打了个精妙的比方：如果让他和Google比「理解单个页面」，他能做得更好；但如果比「扫描整个库」，他必输无疑。而这恰恰是人类审查最薄弱的地方。Qodo的解法是让审查agent在后台持续运行「睡眠时计算（sleep time compute）」，不断更新软件地图（software map / software graph），编程agent则在其上做即时审查。

「睡眠时计算（sleep time compute）」是指在没有实时用户请求的空闲时段，让模型或系统持续进行后台推理与索引更新的机制。区别于每次代码提交才触发的即时分析，sleep time compute允许审查agent在低峰期遍历代码库、更新软件依赖图谱（software map/graph），从而在开发者提交PR的瞬间，可以直接调用已经预热的上下文进行深度审查，而非从零开始扫描。这一机制对于理解跨服务的隐蔽数据流依赖尤其关键，因为这类依赖往往无法通过静态分析在单个文件层面发现，必须依赖全局视图的持续维护。

当agent开始反过来提示人类

关于「如何判断审查agent真的改善了结果」，Itamar给出了一个很接地气的衡量指标。在早期阶段，代码审查工具只是在PR页面上堆砌findings，他直言「到2027年再回头看会觉得很荒谬」，因为这带来了巨大的心智负担。

理想状态是：编程agent和审查agent先在彼此之间达成一致，只有当它们无法达成一致时，才把问题抛给人类开发者。于是角色发生了反转——不再是开发者提示agent，而是agent在提示人类。最朴素的度量方式，就是看「开发者需要被提示多少次才能完成任务」。

主持人Danielle补充了一个来自OpenAI内部API开发者的说法，与此不谋而合：「我不再提示Codex了，是Codex在提示我。」

分歧、犯错与「永不重犯」的机制

当两个agent意见不一致时，什么该上报人类？Itamar引用了一个理论：拥有相同信息、且都讲道理的两个主体（无论人类还是AI），最终应当得出相同结论。agent之所以会和对抗性审查agent得出不同结论，根源在于**上下文（context）**的差异。因此，只要一切都有据可依（grounded），它们最终应该趋于一致。

更棘手的情况是：两个agent达成一致，但都错了，最终进了生产环境并引发事故。Itamar的核心主张是——不要犯同样的错误两次。一旦出现incident或bug，必须以聪明的方式记录进知识库和wisdom base。他认为这正是AI时代相较于前AI时代的独特潜力：隐性知识过去靠人积累，人一离职就带走了；而现在错误可以被永久编码化，进入开发者的「记忆」，直到它不再相关时再被修剪掉。

一家大型金融机构客户的案例很有代表性：数百个代码仓库、多个微服务，大量关于「什么在规模下有效、什么无效」的知识只掌握在少数资深开发者手里，其中一些人已经离职。Qodo的做法是回溯扫描GitHub、GitLab、Bitbucket以及Slack、Teams上多年的开发者讨论，把这些隐性知识编码进软件地图，理解一个服务的改动对另一个服务意味着什么——尤其是那些通过数据流而非代码显式连接的隐蔽依赖。

这里所说的「隐性知识（tacit knowledge）」是知识管理领域的经典概念，由哲学家迈克尔·波兰尼（Michael Polanyi）提出，指那些难以被明确表达、编码或传授的经验性知识——例如资深工程师凭直觉判断某个数据库查询在高并发下会出问题，但却说不清楚具体规则。与之对应的「显性知识（explicit knowledge）」则可以被文档化。传统软件工程的痛点在于，大量架构决策的历史背景、踩坑经验都以隐性知识形式留存在人的记忆中，人员流动时随之消失。Qodo通过回溯扫描代码提交历史、PR评论及即时通讯记录，试图将这些隐性知识系统性地转化为可被agent检索和引用的显性知识库。

重新定义「任务」：从PR到端到端能力

面向未来，Itamar抛出一个值得所有开发者思考的观点：今天的模型是它们将来最笨的时候。 随着agent能完成越来越长的任务，我们需要重新想象「任务」的单位。

如今，仅仅因为工具和能力的限制，我们把「任务」定义为一个pull request。但谁真正关心那个PR呢？你真正在意的是端到端完成一个新能力或新功能——而这往往涉及同一仓库乃至多个仓库里的5到15个PR。这些PR作为整体才构成一个「任务」，却无法在单个GitHub PR页面上讨论。

为此Qodo预告将发布 work package triage 功能，帮助理解多个PR之间如何关联以共同完成一个任务，并对其进行整体审查。

「Work package（工作包）」是项目管理中的术语，指为交付某一完整成果而需要协同完成的一组相关工作单元。在软件工程语境下，一个功能特性往往需要跨多个代码仓库、涉及前端、后端、数据库迁移脚本、配置变更等多个维度的PR才能完整落地。当前GitHub等平台的审查机制以单个PR为原子单位，缺乏将这些PR作为整体评审的原生支持——这意味着审查者无法在同一界面看到「这五个PR合在一起是否真正实现了预期功能、是否引入了跨仓库的一致性风险」。Qodo预告的work package triage功能正是试图在PR层之上建立一个任务级视图，使agent和人类能够对一次完整的功能交付进行端到端的质量评估。

给开发者的实操建议

对于正在用OpenAI模型构建审查系统的开发者，Itamar给出了几条可以立即尝试的方向：

• 关注新的 Decision API——他此前曾在一家做embedding模型的公司工作，深知快速决策的潜力，并透露业界一些知名的决策模型正是基于他们当年开发的模型。
• 把任务拆解为workloads（工作负载）。
• 为每个workload设计所需的swarm，可能是两到五个你自己开发的agent。
• 为棋盘上的每个「玩家」选择合适的模型，兼顾成本效率——因为一旦这套系统真的能帮你完成任务，你会大量使用它，成本控制就成了关键。

Itamar将这套「按工作负载设计swarm、用合适模型优化成本」的方法论，视为未来相当一段时间内的「游戏棋盘」。访谈结尾，他半开玩笑地留下一句提醒：即便你真的实现了「最后一次人类代码审查」，也别忘了——你仍然需要为开发者提供培训。