Jules 教程:谷歌异步 AI 编程 agent 上手(2026)
现在的 AI 编程工具基本都是「你盯着它干活」的模式:Claude Code、Codex CLI、Cursor,都要你开着终端或编辑器,看它一步步改,随时打断纠正。Jules 走的是另一条路——它是谷歌的异步编程 agent,你把任务丢过去就可以关掉页面去干别的,它在云端虚拟机里克隆你的仓库、写计划、改多个文件、跑测试,完事之后直接开一个 Pull Request,你回来只需要看 diff、决定合不合。这篇 Jules 教程从开通、网页端派第一个任务,讲到 Jules Tools 命令行、免费额度的真实限制,以及最关键的一点:什么任务适合丢给它,什么任务丢过去纯属浪费额度。
Jules 是什么:异步 agent 和本地 CLI 的根本区别
Jules 于 2025 年 5 月开放公测,定位是「任务导向的异步编程 agent」。它的完整流程是 计划 → 执行 → 审查:你用自然语言描述任务,Jules 先产出一份分步计划让你确认(你可以改、也可以直接拒绝重来),确认后它在一台安全的云端 VM 里克隆仓库,做跨文件改动、运行已有测试,最后提交一个 PR。整个过程不占用你本机资源,也不需要你在旁边盯着。
| 维度 | Jules(异步云端) | Claude Code / Codex CLI(同步本地) |
|---|---|---|
| 运行位置 | 谷歌云端 VM | 你自己的机器 |
| 交互方式 | 派任务 → 走开 → 回来审 PR | 全程对话,实时打断纠正 |
| 产出形式 | GitHub Pull Request | 直接改本地工作区文件 |
| 能否并行 | 能,多个任务同时跑(免费版 3 个并发) | 受限于你开几个终端和本机性能 |
| 适合的任务 | 边界清楚、能自动验证的中小任务 | 需要反复讨论、边做边改的复杂开发 |
| 前置依赖 | Google 账号 + GitHub 授权 + 可用网络 | 装个 CLI,可接国产模型 |
所以 Jules 不是来替代 Claude Code 的,它填的是另一个位置:那些你明知道该做、但不想为它中断当前工作的杂活——补测试、升依赖、修一个描述清楚的 bug、把某个模块的日志全换成新的 logger。这类任务丢给 Jules,你继续在本地写你的核心功能,两边并行。
国内使用的前置条件
Jules 是谷歌服务,需要 Google 账号并且要能正常访问 Google 域名,国内直连是打不开的,请自备可用网络环境。另外它强依赖 GitHub——代码必须托管在 GitHub 上并授权给 Jules,纯内网仓库、Gitee、自建 GitLab 目前都用不了。如果这两条不满足,可以直接看我们写过的国产终端 AI 编程 CLI 那几篇。
开通:三步接上你的仓库
- 1打开 jules.google,用 Google 账号登录。
- 2点「Connect to GitHub account」授权 GitHub,然后选择要开放给 Jules 的仓库。这一步建议只勾选你确实需要它动的仓库,别一把梭全授权。
- 3回到 Jules 界面选中仓库和分支,就可以开始派任务了。
权限这块值得多说一句:Jules 拿到的是能读代码、能推分支、能开 PR 的权限。它不会直接往主分支合,产出永远是 PR,最终合并动作还是你自己点。但既然它能推分支,最小授权原则该守还是要守——尤其是公司仓库,先在个人项目上跑熟了再说。
第一个任务:网页端怎么派
在 Jules 界面选好仓库和分支,用自然语言写清楚你要什么,然后提交。创建任务时还有个可选项:添加环境设置脚本(environment setup scripts),用来告诉 Jules 这个项目怎么装依赖、怎么跑测试。如果你的项目不是 npm install 就能跑起来的标准结构,这一步基本是必填——否则它跑不起测试,改完也没法自我验证。
任务提交后 Jules 会先给一份计划。这一步别急着点通过,认真读:绝大多数翻车都能在计划阶段看出来。计划里如果出现了你没预期的文件、或者它准备「顺手重构一下」,直接改计划或者驳回重写提示词,比等它做完再收拾便宜得多。
任务描述写得越具体,产出越可用。对比一下:
| 写法 | 示例 | 结果 |
|---|---|---|
| 太模糊 | 「优化一下这个项目」 | 改动范围失控,PR 大到没法审 |
| 刚刚好 | 「给 src/lib/membership.ts 里的三个导出函数补单元测试,用项目已有的测试框架,覆盖过期、永久、无会员三种情况」 | 边界清楚,diff 可读,能直接合 |
| 也很好 | 「把 package.json 里所有依赖升到最新的次版本,跑通测试,不要升大版本」 | 典型的适合异步跑的杂活 |
Jules Tools:把 Jules 搬进终端
只用网页端有个不方便的地方:你得来回切浏览器。谷歌为此出了 Jules Tools,一个轻量命令行工具,安装很简单:
npm install -g @google/jules
# 登录 Google 账号
jules login
# 查看版本
jules version装好后直接敲 jules(不带任何参数)会进入一个 TUI 面板,能看所有会话列表、并排 diff 查看器,也能在里面直接创建新任务。想加主题可以带 --theme dark 或 --theme light。
如果你更习惯一行命令搞定,核心是 remote 这组子命令——它是操作云端会话的主入口:
# 新建一个任务
jules remote new --repo <owner/repo> --session "给 utils 目录补单元测试"
# 同一个任务并行跑多个方案,挑最好的
jules remote new --repo <owner/repo> --session "重构这个模块" --parallel 3
# 列出仓库 / 会话
jules remote list --repo
jules remote list --session
# 把某个会话的改动拉到本地
jules remote pull --session <session_id>
# 生成 shell 补全
jules completion bash--parallel 是被低估的一个参数
同一个提示词让 Jules 并行跑 N 个方案,然后你挑最合适的那份。对于「有多种合理实现方式」的任务(比如重构、选型验证),这比反复调提示词高效得多。代价是每个方案各算一次任务额度,免费版一天 15 次,用之前先算算账。
另外提醒一点:网上有些 2026 年上半年的文章教你通过 Gemini CLI 扩展来编排 Jules。Gemini CLI 已经在 2026 年 6 月 18 日停止为 Google AI Pro/Ultra 和免费用户提供服务,官方引导迁移到 Antigravity CLI,所以那条路径现在多半不通了。直接用 Jules Tools 就好。
免费额度够用吗:官方限制一览
| 套餐 | 每日任务数(滚动 24 小时) | 并发任务 | 模型 |
|---|---|---|---|
| 免费版 | 15 | 3 | Gemini 2.5 Pro |
| Google AI Pro | 100 | 15 | Gemini 3 Pro(更高访问额度) |
| Google AI Ultra | 300 | 60 | Gemini 3 Pro(优先访问) |
免费版一天 15 个任务、3 个并发,说实话对个人开发者相当够用了——毕竟一天里真正值得丢给异步 agent 的任务,通常也就三五个。要注意的是免费版跑的是 Gemini 2.5 Pro,付费版才上 Gemini 3 Pro,复杂任务上两者的差距是实打实的。Jules 的付费不是单独买,而是捆绑在 Google AI Pro / Ultra 订阅里,也就是说你订阅之后拿到的不止是 Jules。
让 Jules 干得更好:AGENTS.md
Jules 会自动在仓库根目录找 AGENTS.md 文件,用它来理解你的代码库、生成更贴谱的计划。这是投入产出比最高的一步优化:花十分钟写一份 AGENTS.md,之后每一个任务的质量都会受益。
# 项目说明
技术栈:Next.js 15 App Router + TypeScript strict + Prisma + PostgreSQL
包管理器:pnpm(不要用 npm/yarn)
## 常用命令
- 安装依赖:pnpm install
- 跑测试:pnpm test
- 类型检查:pnpm tsc --noEmit
- 生成 Prisma 客户端:pnpm db:generate
## 约定
- 一律具名导出,不用 default export
- 数据库访问走 src/lib/prisma.ts 的单例
- 提交前必须通过类型检查和测试
- 不要改 src/generated/ 下的任何文件(自动生成)
## 不要碰
- prisma/migrations/ 下的历史迁移文件
- 任何 .env 文件好消息是 AGENTS.md 是跨工具的开放标准,Codex、Cursor、Copilot 等一大批工具都读它。也就是说你为 Jules 写的这份说明,换到别的工具上照样生效,不是一次性投入。
什么任务适合丢给 Jules
判断标准就一条:这个任务的对错,能不能靠跑测试或者看 diff 快速验证。能,就适合异步;不能,就老老实实在本地同步做。
- 适合:给已有模块补单元测试(有明确的验证标准)
- 适合:升级依赖版本并跑通测试(机械、耗时、结果可验证)
- 适合:修一个能稳定复现、描述清楚的 bug
- 适合:全局性的机械替换(换日志库、统一错误处理、批量改 API 调用)
- 适合:给缺注释的模块补文档和类型定义
- 不适合:需求本身还没想清楚的新功能(计划阶段就会跑偏)
- 不适合:牵扯核心架构决策的改动(这种要人来拍板)
- 不适合:需要跑起真实服务、连真实数据库才能验证的任务
- 不适合:涉及密钥、支付、权限校验等敏感逻辑(应当人工写、人工审)
PR 该怎么审
Jules 开出来的 PR 一定要当成外部贡献者的 PR 来审,而不是「AI 写的应该没问题」。重点看三处:有没有动到计划外的文件、测试是不是真的在测东西(而不是写了个必然通过的空壳)、有没有为了让测试过而修改测试本身。异步的代价就是你没在现场,审查这一关必须补回来。
怎么和现有工具搭配
比较顺手的组合是这样:早上开工前,把攒下来的杂活(补测试、升依赖、修小 bug)批量丢给 Jules,让它在云端并行跑;然后自己在本地用 Claude Code 或 Codex CLI 专心写当天的核心功能;中午和下班前各回来审一次 PR。相当于花零成本雇了个只干杂活的实习生,而且它不会打断你。
如果你的项目在 GitHub 之外,或者网络条件不允许,那 Jules 这条路暂时走不通——可以退而求其次,用本地 CLI 工具开多个终端窗口并行跑任务,效果打折但方向一致。国产模型接终端 agent 的具体配法,我们在 Claude Code 接入国产模型那篇里写得很细。
Jules 代表的其实是一个更大的趋势:AI 编程正在从「陪着我写」变成「替我跑」,人的角色从敲代码逐渐挪到定义任务和验收结果。这意味着两件事的价值在涨——把需求描述清楚的能力,以及审查 AI 产出的能力。想系统练这两件事,把 AI 工具真正用成生产力而不是玩具,欢迎来 IMAI 看看我们的体系化实战课程。
想系统学会用 AI 编程,从入门到做出真实产品?
查看系统课程