Cloud 结果怎么带回本地

Cloud 结果怎么带回本地

Cloud 做完任务，不等于你可以直接相信结果。你还要审查、带回本地、验证。

前置教程：第一次创建 Codex Cloud 任务
如果你还没有完成 Cloud 只读任务，先完成前置教程。

依据来源：OpenAI Codex 官方手册中关于 Codex cloud tasks、从 CLI 浏览和应用 Cloud 变更、IDE 预览 Cloud 变更、本地验证的说明。

先分清两种结果

Cloud 任务结果大致分两类：

类型	怎么处理
只读分析结果	作为后续任务上下文，不需要应用到本地
代码修改结果	必须审查 diff，再决定是否带回本地验证

前一篇我们做的是只读分析，所以不需要应用代码。

后续如果 Cloud 真的改了代码，你才需要“带回本地”。

第 1 步：先审查 Cloud 总结

不要第一眼就点应用。

先看 Cloud 的总结：

• 它做了什么。
• 改了哪些文件。
• 有没有运行检查。
• 检查是否通过。
• 有没有失败或剩余风险。
• 有没有超出任务范围。

如果总结很模糊，追问：

请重新总结这次 Cloud 任务：
1. 修改了哪些文件。
2. 每个文件为什么修改。
3. 哪些检查通过了。
4. 哪些检查没有运行，原因是什么。
5. 是否有超出任务范围的修改。
6. 剩余风险是什么。

第 2 步：看 diff

代码修改必须看 diff。

你要检查：

• 是否只改了任务范围内的文件。
• 是否有无关格式化。
• 是否引入新依赖。
• 是否修改配置文件。
• 是否改了密钥、环境变量、CI 配置。
• 是否动了你没有授权的模块。

如果 diff 太大，先不要应用。

问：

这次 diff 太大了。
请把修改拆成更小的提交建议，并说明哪些文件是必要修改，哪些可以撤回。

第 3 步：决定是否带回本地

只有满足这些条件，才考虑带回本地：

• 修改范围符合任务目标。
• 没有明显无关文件。
• 没有敏感信息。
• 检查结果可信。
• 你知道本地要怎么验证。

如果不满足，先让 Cloud 继续修改或缩小范围。

第 4 步：带回本地的方式

根据你使用的入口不同，可能有几种方式：

• 在 Cloud/Web 界面中查看或应用变更。
• 在 IDE 扩展里预览 Cloud 变更。
• 通过 CLI 的 codex cloud 相关能力浏览或应用任务结果。
• 通过 GitHub PR 拉到本地审查。

具体按钮和界面会随版本变化，所以本教程不硬写某个固定按钮名称。

你要抓住原则：

先审查，再应用；先本地验证，再合并。

第 5 步：本地验证

带回本地后，用 CLI 或 IDE 验证。

推荐用 CLI 做项目级检查：

请检查刚刚从 Cloud 带回本地的变更。

要求：
1. 总结当前 Git 变更文件。
2. 判断是否有无关文件。
3. 根据项目现有脚本进行必要验证。
4. 如果检查失败，请判断是否由本次 Cloud 变更引入。
5. 不要提交代码。

如果只是当前文件的小改动，也可以用 IDE 看具体代码。

第 6 步：发现问题怎么办

如果本地验证失败，先不要手改。

先让 Codex 分析：

Cloud 变更带回本地后验证失败。

错误信息如下：
【粘贴错误，隐藏敏感信息】

请判断：
1. 是否由 Cloud 变更引入。
2. 哪个文件最可能相关。
3. 最小修复范围是什么。
4. 是否建议回退 Cloud 变更。
5. 不要直接修改，先给分析。

第 7 步：进入提交前检查

本地验证通过后，再做提交前检查：

• Git 提交前检查

不要因为 Cloud 已经检查过，就跳过本地检查。

Cloud 环境和本地环境可能不同。

本篇验收

完成后，你应该能做到：

• 区分只读结果和代码修改结果。
• 先看 Cloud 总结和 diff。
• 知道什么时候可以带回本地。
• 带回后用 CLI 或 IDE 验证。
• 验证通过后再进入提交前检查。

下一步可以进入：实战案例总览。