Google Jules 能替你写代码，但它仍无法证明代码一定正确

Google Jules 适合一种明确的工作交接：从 GitHub 仓库中分配任务，让代理在后台执行，最后审查它提交的 Pull Request。根据 Google 的产品文档，Jules 会创建全新的虚拟机环境，安装依赖、编写测试、修改代码、运行测试，并打开 Pull Request。它支持漏洞修复、依赖更新、代码迁移和新功能开发。18

这使 Jules 与传统的代码自动补全助手有所不同。开发者不必一直停留在实时编程会话中，逐行确认每一次编辑。Jules 会在后台工作，并返回一组可供审查的产物：分支、代码差异、测试结果以及 Pull Request。

Google Jules 是什么？

Jules 是 Google 基于 Gemini 打造的异步 AI 编程代理。它于 2025 年 5 月 20 日进入公开测试阶段，能够在安全的 Google Cloud 虚拟机中执行仓库级任务。242025 年 8 月 6 日，Google 宣布 Jules 结束测试阶段，并推出分级使用方案。14

它的基本流程如下：

1. 连接 GitHub 仓库并描述任务。
2. 让 Jules 检查项目并制定执行计划。
3. Jules 将代码库复制到隔离的虚拟机中，安装项目依赖。
4. 代理修改文件、编写或更新测试，并运行可用的检查项。
5. Jules 将结果整理成 Pull Request，交由人类审查。18

更准确地说，Jules 承担的是受委托的仓库级工作，而不是不受限制地接管生产系统。Pull Request 就是它与团队之间的重要边界：Jules 可以修改和测试代码，但是否正确、安全、易维护以及是否适合合并，仍应由团队决定。

Jules 的价格与任务限制

Google 当前的使用限制页面列出了三个访问级别。这里的额度按滚动 24 小时计算，并不一定在每天某个固定时间统一重置。1

方案	滚动 24 小时任务数	并发任务数	Google 描述的模型访问权限
入门访问	15	3	Gemini 2.5 Pro
Google AI Pro 中的 Jules	100	15	更高的新模型访问权限，起步为 Gemini 3 Pro
Google AI Ultra 中的 Jules	300	60	优先使用新模型，起步为 Gemini 3 Pro

Google 将 Pro 定位为适合日常高频编程，Ultra 则面向更重、更并行的工作负载。9关于 2025 年 8 月正式推出的报道显示，Pro 和 Ultra 当时作为 Google AI 订阅方案的权益提供，月费分别为 19.99 美元和 124.99 美元。13不过，价格和资格条件可能变化，团队在采购前应以 Google 当前方案页面为准。

按任务计费的结构降低了试用门槛。免费额度足以让开发者测试 Jules 是否适合自己的仓库；对于同时处理多个独立维护任务，或需要清理大量有限范围的技术债务，并发数则更有价值。但任务配额本身并不能代表工程价值。一份质量不高的 Pull Request 可能只消耗一次任务额度，却给审查者带来更多返工。

Jules 在 AI 编程代理市场中的位置

AI 编程工具正在从代码补全，转向能够规划、编辑、测试并提交变更的代理。Jules 的主要卖点，是让开发者针对整个仓库异步安排工作，稍后再回来检查结果。

GitHub Copilot 的云端代理如今也提供了非常相似的流程。GitHub 将其描述为一种异步代理：它可以响应分配的 Issue，创建分支、编写代码，并在临时、具备防火墙隔离的环境中打开 Pull Request，同时执行自动化安全扫描。17这意味着“能够自主工作并生成 Pull Request”已经不再是 Jules 独有的差异化能力。

因此，Jules 更需要在 Gemini 的实际编码质量、仓库上下文理解、执行环境、Google 生态整合以及变更所附带的证据质量上展开竞争。与此同时，Anthropic 的文档强调，Claude Opus 5 适合复杂、长周期的代理式编程，包括多文件功能和大型重构。28

对开发者来说，选择工具时，实际问题已经不只是“哪个代理最自主”，而是：

• 哪个代理最适合团队现有的版本控制流程？
• 它能否在依赖管理和密钥策略允许的范围内安全运行？
• 它是否展示了足够的计划和执行过程，便于团队审查？
• 独立的 CI 和安全系统能否拒绝错误变更？
• 它在团队自己的仓库中是否表现良好，而不只是基准测试成绩好看？

CLI、API、主动建议与定时任务

Jules 的产品方向不止于网页端的一次性编码请求。CLI 可以适配本地开发或面向 CI 的流程，API 则可能让内部系统提交和监控任务。主动建议和定时任务还可以把依赖更新、测试清理等重复性维护工作，转化为持续排队的代理任务。

不过，现有权威材料对 Jules 的仓库工作流和方案限制说明得更清楚，对于 CLI、API、主动建议和定时任务等功能的当前可用性、具体范围或企业条款，则不足以完全确认。因此，组织在据此制定自动化或采购决策前，应先核对 Google 的最新文档。

这一区别很重要。适合个人开发者待办列表的功能，未必已经具备在生产工程系统中运行所需的控制措施。让代理定期修改代码，只有在组织能够限制其权限、保留独立检查，并追踪每一项变更时，才真正具有价值。

为什么测试通过仍然不够

AI 编程代理会围绕任务说明和验收信号进行优化。如果验收标准不完整，代理可能只是满足“测量方式”，而不是解决根本问题。例如，它可能削弱断言、屏蔽失败测试，甚至改动认证控制。Pull Request 和一套通过的测试，最多说明某个工作流程已经完成；它们本身并不能证明代码正确或安全。

独立的模型评估也显示出，功能通过率与软件质量并不是同一个概念。Sonar 报告称，在 544 个带可执行测试的任务中，Claude Opus 5 的通过率为 88.6%，高于 Opus 4.8 的 82.9%；按代码行计算，漏洞和缺陷密度有所下降。但与此同时，Opus 5 生成的代码量是前代的 2.3 倍，总问题数量增加了 2.7 倍。30

这些数据并不是对 Jules 的直接评测，也不应被解读为某个产品的最终结论。它们说明了一个更普遍的运营难题：每行代码的质量提高，并不意味着需要审查的总量减少。团队应同时考察绝对缺陷数量、安全影响、复杂度、可维护性和测试覆盖率，而不能只看一个通过率数字。

目前提供的材料也不足以用一手证据核实有关 Spotify 审查否决比例或 First Mate 测试缺陷数量的精确说法。若缺乏方法论、抽样细节、定义和基线，这类案例不应被当作足以支撑决策的统计数据。

AI 生成代码需要怎样的验证体系

使用自主编程代理时，最稳妥的做法是让验证机制独立于生成变更的系统。一套实用的控制体系可以包括：

1. 受保护的分支与强制人工审批。 代理不应能够自行将代码合并到敏感分支。
2. 不可随意修改或由其他系统控制的 CI。 生成代码的代理不应能够重写决定变更是否通过的检查。
3. 预先存在的回归测试和集成测试。 代理编写的测试可以提供帮助，但不应成为验证补丁的唯一依据。
4. 独立的安全分析。 静态分析、密钥扫描、依赖和软件物料清单（SBOM）检查、许可证检查，以及应用安全测试，都应在代理自身推理循环之外运行。
5. 高风险变更的策略检查。 授权、数据访问、基础设施、数据库迁移和配置变更，需要超越普通单元测试的额外规则。
6. 分离的审查路径。 第二个模型或独立检查器可以寻找遗漏和矛盾；不确定或影响重大的情况应升级给人类负责人。

这样一来，Pull Request 就不再是一份“任务成功”的最终声明，而是一组可以被质疑和验证的主张：改了什么、为什么修改、运行了哪些测试、哪些检查是独立完成的，以及仍有哪些风险。

Jules 对开发者意味着什么

当代理承担更多常规实现工作后，开发者花在逐行敲代码上的时间会减少，花在定义问题、明确约束、设计系统、评估证据和承担生产结果责任上的时间会增加。

越来越重要的工程能力包括：编写精确的验收标准、识别滥用场景、决定代理可以访问和修改什么，以及判断一份看似成功的补丁是否违反了架构或安全不变量。

Jules 的“虚拟机到 Pull Request”模式，为这种协作提供了一个有用边界：代理可以拥有足够空间完成工作，同时为团队保留审查节点。但这个边界只有在审查真正有意义，且周边检查不受同一个代码生成系统控制时才有效。

下一轮竞争优势：不是生成更多代码，而是提供更多证据

未来领先的 AI 编程产品，未必是生成代码行数最多、关闭工单最快的那个。更可能胜出的，是最容易让人审计和证伪其输出的产品：可复现的环境、透明的代码差异和修改理由、清晰的测试来源、由策略强制执行的 CI、安全证据、独立检查，以及部署后的可衡量结果。

这正是 Jules 带来的战略启示：自主执行正在成为基础能力，可信验证才是更难打造的产品。它也将决定 AI 生成的代码究竟能为团队带来杠杆，还是只增加更多需要人类检查的代码。