Jules 在你看到代码之前，先让评论者审一遍

认识 Jules 最尖锐的评论者，也是最有用的盟友

2025-08-12

Kathy Korevec，Google Labs 产品总监。

Mehadi Hassen，研究工程师。

Yiguang (Amanda) Zhang，研究工程师。

像 Jules（https://jules.google/）这样的 AI 编码智能体可以在你做别的事时构建、重构和搭脚手架。这种方便有时也意味着细微的缺陷、漏掉的边界情况和未经检验的假设。因此作者在 Jules 里加入一种新能力：在你看到代码之前，先审阅并批评它。

评论者增强生成

角色简单但有力：Jules 在构建时，评论者功能在质疑。每一处提议的改动在完成前都要经过对抗式审阅。把评论者功能想成 Jules 的同行评审：深谙代码质量原则，并且不怕指出你重新发明了一个有风险的轮子。

评论者直接嵌进代码生成过程，这叫做评论者增强生成（critic-augmented generation，生成的同时就有一个评论者在看）。第一版是一次完成（one-shot，对最终输出只过一遍）的过程，一次看完最终输出并评估。后面的里程碑打算把它做成真正的多步智能体，能使用工具调用，或在子任务之后、计划之前触发；目前它一次审阅完整的生成结果。这会用到多步研究里的做法：评论者用外部工具（例如代码解释器或搜索引擎）核验输出，并从这些结果里学习。

评论者做什么

评论者不修代码。它标出问题，再交回给 Jules 去改。例如：

• 一个补丁通过了全部测试，却引入细微的逻辑错误：“输出符合预期用例，但在没见过的输入上失败。”
• 一处改动能编译，却静默丢掉了必填字段：“函数签名更新了，却没有处理全部参数。”
• 代码能工作，但方法低效：“算法结果正确，却带有不必要的 O(n²) 复杂度。”

因为这发生在补丁生成之后、提交之前（如果仍被标出，可能重复多次），Jules 可以实时重新计划。目标是更少敷衍的拉取请求、更好的测试覆盖、更强的安全性。

不只是另一种检查器或测试

检查器（linter，按固定浅规则扫代码风格和明显错误的工具）遵循浅的、固定的规则；测试核验具体断言。评论者能力理解代码背后的意图和上下文。它更接近一种无参照（reference-free，不需要一份金标准实现）的评测方法，判断正确性和稳健性，而不需要一份标准实现。

它也借用用大语言模型当裁判（LLM-as-a-judge，让一个模型按质量和正确性评估另一个模型的工作）的研究。这种自动评判在和生成扣得很紧时特别有用，把审阅变成实时反馈环。

它怎样工作

1. 你提示 Jules 开始一项任务。
2. 评论者功能一次看完候选补丁和它的说明，做出总体判断。
3. Jules 在结束前回应反馈。之后评论者可以再审更新后的补丁，并继续标出它认为必要的问题，直到没有进一步的问题。
4. 你收到的代码已经在内部被审过。

这借鉴演员-评论者强化学习（actor-critic，一个角色生成、另一个角色评估，再按学习信号更新两者）。在作者的大语言模型评论者设置里，模式相似：先提议，再评估。不过反馈不更新学习参数，而是影响当前状态和下一步。同一原则也支撑用大语言模型当裁判的研究：评论者的评估引导质量，而不重新训练。

为什么要紧

在快速迭代的世界里，评论者把审阅挪到过程更早的地方，并放进生成这个动作本身。这意味着你审的代码已经被追问、打磨和加压测试过。当然，使用前仍应仔细审阅生成的代码（https://g.co/legal/generative-code）。

好的开发者不只是写代码，他们追问代码。现在 Jules（http://jules.google/）也这样做。

出处：Kathy Korevec，Mehadi Hassen，Yiguang (Amanda) Zhang，Meet Jules’ sharpest critic and most valuable ally，2025-08-12，https://developers.googleblog.com/meet-jules-sharpest-critic-and-most-valuable-ally，CC BY 4.0。Portions of this page are modifications based on work created and shared by Google and used according to terms described in the Creative Commons 4.0 Attribution License.