Itamar Friedman 谈 AI 代码审阅与工程上下文

OpenAI 开发者体验团队成员 Danielle 采访 Qodo 首席执行官 Itamar Friedman，讨论审阅 AI 生成代码。Friedman 在 2026 年 DevDay 介绍自己公司的产品与愿景；这些主张不是对审阅质量的独立评估。

Friedman 说 Qodo 收集工程上下文，既用于帮助编程智能体，也用于审阅其更改。他描述了一张记录软件关系及其随时间变化的软件地图。

他区分提示词工程、工作流工程和协调多个专门智能体。他认为审阅产品需要针对任务的工作流、工具和约束，而不只是通用指令。

主持人问组织中的审阅者除了代码还需要什么。Friedman 将积累的经验称为“智慧”，并认为先前决策和运行行为的信息应被记录，供未来工作使用。

他举出客户案例：局部看似合理的数据库更改可能影响下游服务。他说更广泛的软件地图可以帮助发现依赖，但这个例子来自公司讲述，而非公开的受控测试。

Friedman 回顾从单个提示词到工程化工作流、再到智能体群组的变化。他说若不加约束，智能体委派和工具选择可能浪费资源，并主张让发现有证据支持。

被问到如何知道审阅是否改善结果时，他提出在产出高质量变更的同时减少对开发者的打断。单凭这一指标无法衡量漏掉的缺陷，因此审阅质量仍需要独立评估。

两人讨论编程智能体、对抗式审阅者与人之间的分歧。Friedman 认为上下文差异可以解释部分分歧，并建议主张附带证据。

Danielle 问如果智能体意见一致却都错了会怎样。Friedman 承认故障会发生，并提议把事件及教训记录在共享知识库中；意见一致不能证明正确，从一次事件学习也不能保证问题不再发生。

他介绍从过去的代码仓库讨论和沟通中重建组织知识，尤其是在资深开发者离开时。构建这类记录需要考虑访问权限、隐私和推断依赖的准确性。

Friedman 预测工程任务将越来越多地跨越多个拉取请求和代码仓库。他认为审阅应考虑端到端能力，而不只检查每个单独更改。

他预告一项旨在把拉取请求关联到更大工作包的 Qodo 功能。这是公司产品发布内容，采访没有在演示之外确立其可用性或效果。

对构建审阅者的开发者，他建议将任务拆成工作负载，为每个角色选择工具和模型，并考虑成本。适当的自动化程度取决于任务及失败后果。

访谈最后指出，即使审阅工作流变化，开发者仍需要培训。标题中“最后一次人工审阅”的说法是一种愿景，并非人工监督已经过时的证据。