6. 云端任务与 GitHub 自动化
用 Codex 做真实项目时，所有任务都塞在本机跑，很快会遇到两个问题：你得一直守着它推进，多个互不相关的任务也没法轻松并行。Codex Cloud 和 GitHub 自动化，解决的就是把一部分边界清楚的工程任务交出去，让它在远程环境里独立执行，再把结果交回给你审。
Codex Cloud 的价值很直接：把一个边界清楚的任务交出去，让它在云端独立环境里克隆仓库、安装依赖、改代码、跑验证，最后把结果以 Diff 或 PR 的形式交回来。GitHub 集成再往前补一刀：你可以让 Codex 参与 PR 审查，用 @codex review 触发，也可以开启自动代码审查，让它在 PR 流程里先帮你扫一遍高风险问题。
但云端不是万能按钮。它适合能放手、能验证、能异步完成的任务；不适合需求还没想清楚、需要你频繁判断、或者必须贴着本机环境调试的任务。这篇就把这条边界讲清楚：Cloud 怎么跑、环境怎么配、GitHub 怎么接、代码审查怎么开，以及什么时候该留在本地。
1. Cloud 任务是什么
先把 Codex Cloud 想成一个远程执行面，而不是另一个聊天框。你在页面里描述任务，它会在云端给这个任务准备一个隔离容器，从你授权的 GitHub 仓库检出指定分支或提交，按环境配置跑 setup script，再让 agent 在这个环境里读代码、改代码、执行测试，直到产出一个可审查的结果。
这个过程和本地 App 的差别在于：本地 App 贴着你的当前工作区、当前终端、当前窗口，适合边看边调；Cloud 则更像异步派单，适合你把一件事讲清楚之后交给它自己跑。官方 Cloud 流程里，任务完成后会给出回答和代码差异，你可以继续追问，也可以把结果整理成 PR 进入 GitHub 流程。
入口页面长这样。进入 Codex Cloud 之后，页面中心就是任务输入框，下面能看到「任务」「代码审查」「归档」这几个入口。第一次使用时，它还会给你几张新手任务卡，帮助你从代码库讲解、定位 bug、修小问题这类低风险任务开始。
我建议第一次不要上来就扔一个大而空的需求，比如「把系统重构一下」。更稳的开局是让它先读项目、解释结构、找一个明确问题，或者补一组测试。Cloud 的优势是异步和隔离，不是替你猜需求。
2. 云端环境怎么准备
Cloud 任务能不能跑好，关键不只在 prompt，还在环境。因为 agent 不是在你这台电脑里执行，它需要知道代码从哪里来、依赖怎么装、测试怎么跑、哪些网络访问允许、哪些密钥只能用于安装依赖。
官方的 Cloud environment 大致可以理解成一份远程工作区模板。Codex 会按这份模板创建容器、检出仓库、运行 setup script 和维护脚本，然后再进入 agent 工作阶段。这里有几个点要特别注意。
第一，setup script 要尽量把项目变成可验证状态。Node 项目就安装依赖，Go 项目就拉模块，Python 项目就建虚拟环境或装依赖。不要把验证命令只写在文章或 README 里，Cloud 真正需要的是能被执行的命令。
第二，密钥和普通环境变量要分开看。适合放进 setup 阶段的密钥，比如私有包仓库 token，可以用来完成依赖安装；但不要把生产数据库密码、线上长期 token 当成 agent 可以随便读的上下文。官方机制里 secret 会在 setup 后从 agent 阶段移除，这个设计就是为了减少泄露面。
第三，网络权限不要一开了之。Cloud 的 setup 阶段通常需要联网拉依赖，但 agent 工作阶段的网络访问默认更保守。确实需要联网时，再按域名和 HTTP 方法放行。能只允许 GET、HEAD、OPTIONS，就不要给更大的权限；能只放某几个包源或 API 域名，就不要给全网。
Codex Cloud 的环境设置页会集中管理远程执行环境。当前账号还没有创建环境时，页面会显示「无环境」和右上角「创建环境」按钮。正式使用时，你就是从这里给 Codex 准备可复现的远程工作区。
环境页最好在正式派任务之前配好。一个简单但好用的检查清单是：这个环境能不能干净安装依赖，能不能跑最小验证命令，失败时日志是不是足够清楚，网络权限是不是只放了必要域名。Cloud 任务如果总在安装依赖阶段失败，十有八九不是 agent 不会写代码，而是环境还没准备好。
3. 什么任务适合上云
适合 Cloud 的任务有三个共同点：边界清楚、能客观验证、不需要你持续反馈。
比如这些任务就很适合：补一批单元测试，把某个工具从旧版本迁到新版本，修一个有复现步骤的 bug，按现有风格补文档，处理一批机械重构，或者让 Codex 先读仓库后给迁移建议。它们都有明确输入，也能用测试、构建、类型检查、lint、文档 diff 之类的方式验收。
不适合 Cloud 的任务也很明显：需求还在变、架构方向没定、需要你不停看 UI 调审美、需要连你本机某个临时服务、或者要碰高风险生产数据。这样的任务不是不能用 Codex，而是应该留在本地 App、IDE 或 CLI 里，让你边看边收敛。
Cloud 的另一个优势是并行。每个任务都可以在独立环境里跑，你可以同时派几个互不冲突的任务：一个补测试，一个查 bug，一个写迁移说明，一个尝试小范围重构。最后不要急着全合并，像审普通 PR 一样逐个看 Diff、跑验证、合入。
写 Cloud 任务 prompt 时，别只写目标，要把验收口径也给出来。一个可复用模板是：
请在当前仓库中完成这个任务：
目标：
- 修复 xxx 场景下的 xxx 问题
- 不改变公开 API
范围：
- 优先查看 src/xxx 和 tests/xxx
- 不要改动部署配置
验证：
- 运行 npm test -- xxx
- 如果测试无法运行，请说明失败原因和已验证的部分
交付：
- 总结改动
- 列出风险
- 标明还需要人工确认的地方Cloud 不是让 prompt 变短，而是让任务执行变异步。你给的边界越清楚，最后回来的 Diff 越像一个可审查的工程产物。
4. GitHub 连接怎么打通
Codex Cloud 要真正进入团队工作流，绕不开 GitHub。仓库授权之后，Codex 才能看到你允许的 repo，才能围绕 PR、issue、代码审查这些协作对象工作。
连接器页面能看到当前 GitHub 是否已经连接，也能看到 Slack、Linear 这类协作系统入口。GitHub 是 Cloud 任务和代码审查的底座；Slack、Linear 则更偏团队协作，方便在评论区或任务系统里把问题分配给 Codex。新手先把 GitHub 接好就够了，不必一口气把所有连接器都打开。
这里还有一个容易忽略的安全点：不要把所有仓库都默认开放给自动化。个人练习仓库、教程仓库、非敏感内部工具，可以先接入；生产核心仓库、带大量密钥或合规要求的仓库，应该先确认组织策略、分支保护、审查责任和日志留存。
GitHub 接上之后，Codex 不会因此绕过你的仓库规则。它要么提交一个可审查的任务结果，要么在 PR 里留下 review。最终能不能合并，仍然由 GitHub 分支保护、必需检查、人工 review 决定。
5. 代码审查怎么接入
代码审查是 Codex GitHub 集成里最值得先用的能力。你可以在 PR 里评论 @codex review 触发一次审查，也可以在设置里开启自动审查，让 Codex 在 PR 创建时自动参与。官方说明里还有一个重要约束：Codex 在 GitHub review 里主要报告严重问题，也就是 P0/P1 级别的问题，不是把每个风格小毛病都刷屏。
Codex 的代码审查设置页顶部会说明两件事：开启后 Codex 可以自动给 PR 提改进建议；在 PR 中提到 @codex 可以启动任务或手动请求 review。中间则是个人偏好、自动审查、审查触发条件、全面代码审查和额度使用这些开关。
如果你想让 Codex 按团队标准审，而不是按通用直觉审，就把规则写进 AGENTS.md。比如：
# Review guidelines
- 重点检查鉴权绕过、越权访问、SQL 拼接、并发数据竞争。
- 只报告能从当前 Diff 推导出的具体问题。
- 对纯风格问题保持克制，除非它会导致实际行为差异。
- 每条审查意见都要说明触发条件、影响范围和建议修复方向。这类规则比在每个 PR 里临时解释靠谱。Codex 会按离目标文件最近的 AGENTS.md 生效，所以大型仓库可以在根目录写通用规则，在关键模块下面补更具体的审查重点。
另外，不要把自动审查当成替代人类 review。它适合做第一轮风险扫描，尤其是越权、边界条件、测试遗漏、明显回归。最终的产品判断、架构取舍、上线风险，仍然要人来拍板。
6. 本地和云端怎么选
Codex 入口变多之后，最怕的是每次都纠结该用哪个。其实判断标准很简单：需要互动就本地，能放手就云端；需要看屏幕、跑本机服务、边改边验，就本地 App、IDE 或 CLI；需要异步、并行、PR 化交付，就 Cloud。
本地的优势是贴身反馈。你要反复看 Diff、改 Prompt、跑本机服务、观察 UI 变化，就应该留在本地 App、IDE 或 CLI 里做小步迭代。Cloud 的优势是放手执行。你给它一个边界清楚、能独立验证的任务，它不占用当前电脑和当前窗口，也更适合同时派多个互不冲突的任务。
我自己的经验是：先本地、再云端、再回本地收口。复杂任务一开始在本地和 Codex 对齐范围，范围稳定后拆成几个 Cloud 任务并行跑，结果回来后再在本地 App 或 IDE 里审 Diff、跑完整验证、处理细节。这比把一个巨大任务直接丢给 Cloud 更稳。
7. 常见问题
Q：Cloud 任务需要我电脑一直开着吗？
不需要。任务在云端执行，不依赖你本机一直在线。你只需要在结果回来后审查即可。
Q：没有配置 Cloud 环境能不能用？
能不能顺利跑取决于仓库和任务。简单读代码类任务可能能跑，但需要安装依赖、跑测试、访问私有包源的任务，最好先配环境。
Q：Cloud agent 能不能随便联网？
不要这样理解。setup 阶段和 agent 阶段的网络边界不同；agent 工作阶段应尽量保持最小网络权限。确实需要联网时，按域名和方法精确放行。
Q：@codex review 会不会把 PR 评论刷爆？
官方设计更偏高优先级问题，不是普通 lint 机器人。你也可以用 AGENTS.md 的 Review guidelines 约束它只报告具体、可复现、影响明确的问题。
Q：Codex 能不能直接合并 PR？
不要把它当成绕过流程的机器人。GitHub 分支保护、必需检查、人工 review 仍然应该保留。Codex 的产出是给你审的，不是替你承担合并责任。
8. 小结
Codex Cloud 的核心不是酷，而是把一部分工程任务从同步陪跑变成异步委托。它在云端准备环境、检出仓库、执行任务、返回 Diff 或 PR，让你把能明确验收的工作并行排出去。
GitHub 自动化则让 Codex 进入团队协作链路：连接 GitHub 后，它可以围绕 PR 和仓库工作；开启代码审查后，@codex review 和自动审查能帮你先扫高风险问题；配合 AGENTS.md，还能把团队自己的审查重点固定下来。
最后记住一句话：要互动留本地，能放手上云端，重要结果必须审。 这才是 Codex Cloud 和 GitHub 自动化真正适合日常开发的用法。
关注秀才公众号：IT杨秀才，回复：面试
