05-入口选择与协同

​

用途

• 用一棵决策树在几分钟内选定入口；
• 比较四种入口的上下文、权限、网络、审查、并行和成本；
• 按“IDE 探索 -> CLI exec 验证 -> Desktop/Cloud 协同”的方式组织一项真实任务；
• 为每次交接留下分支、diff、命令和验收证据；
• 在权限、密钥、网络和并行冲突出现时及时停下并恢复。

本页讨论的是工作方法，不把模型名称、套餐额度或界面按钮写死。命令和功能可能随版本变化，执行前以本地 codex --help、对应子命令的 --help、入口中的实际选项和官方文档为准。

​

先记住三个边界

​

入口改变的是工作面

​

入口不等于权限

当前目录/仓库是什么？
当前分支和已有改动是什么？
Codex 能读写哪些路径？
命令是否需要批准？网络是否开放？
这次任务允许提交、推送或创建 PR 吗？

​

入口不等于验收

​

入口选择决策树

开始
  |
  | 任务必须读取或修改本机文件、本地服务、未提交改动或本地工具？
  |-- 是 --> 需要在编辑器中逐段理解、选中代码或看实时预览？
  |             |-- 是 --> IDE 扩展
  |             |-- 否 --> 需要脚本化、SSH、批量执行或机器可读输出？
  |                         |-- 是 --> CLI；一次性任务优先 codex exec
  |                         |-- 否 --> 需要同时管理多个线程、隔离 worktree 或可视化审查？
  |                                     |-- 是 --> Desktop App
  |                                     |-- 否 --> CLI 交互式或 IDE，按当前工作面选择
  |
  |-- 否 --> 仓库是否已在 GitHub，且允许在云端隔离环境中运行？
                |-- 否 --> 先在本地 CLI/IDE 准备仓库、分支和环境
                |-- 是 --> 任务是否适合离开本机并可用一句话验收？
                            |-- 否 --> 本地入口，保留本机上下文
                            |-- 是 --> 是否需要电脑关闭后继续或多个任务并行？
                                        |-- 是 --> Cloud
                                        |-- 否 --> Cloud 或本地，按数据和成本边界选择

​

决策树的快速解释

​

六个维度的比较

​

总表

​

上下文：相关比更多重要

​

权限：先收紧，再逐步放开

​

网络：本地和 Cloud 是两套网络

​

审查：入口越自动，交付越要可见

目标分支或 commit
改动文件清单
关键 diff
实际执行的验证命令及退出码
未验证的假设
是否提交、推送或创建 PR

​

并行：隔离比“同时打开几个窗口”重要

• Desktop App 使用 Worktree，让每个线程拥有独立副本；
• CLI 用多个 Git Worktree 和多个终端；
• Cloud 让每个任务使用独立容器和分支；
• 不要让两个任务同时负责同一批文件；
• 合并前分别跑验证，合并后再跑一次集成验证。

​

成本：算总任务成本，不只看单次响应

1. 先写清目标、范围、约束和验收，减少返工；
2. 用 @file、选中代码和测试输出缩小上下文；
3. 简单任务用较低推理强度，复杂任务再提高；
4. 长任务分成可独立验收的阶段；
5. 只有值得后台运行的任务才放 Cloud；
6. 并行前确认任务确实互不冲突；
7. 用 /status 或入口中的用量信息观察消耗，不把快速模式默认打开。

​

推荐协同工作流

​

阶段一：IDE 探索与范围确认

目标：修复登录成功后偶发跳转空白页。
上下文：请重点查看 @src/auth/login.ts、@src/router/index.ts 和相关测试。
约束：不要改变权限校验和公开 API；先只分析，不改文件。
验收：给出根因、最小修改范围和应补的测试用例。

​

阶段二：IDE 小范围实现

按刚才确认的最小方案实现。
只允许修改 @src/auth/login.ts 和 @tests/auth/login.test.ts。
先运行单个相关测试，失败时保留错误并说明原因；不要提交或推送。

​

阶段三：CLI exec 做可重复验证

git status --short
git diff --check

codex exec --sandbox read-only "审查当前未提交改动。只读取文件，按严重度列出回归风险、遗漏测试和与目标无关的改动，不要修改文件。"

​

阶段四：交给 Desktop App 管理并行和审阅

​

阶段五：把长任务交给 Cloud

• 仓库已经在 GitHub，权限和可见范围已确认；
• 任务不依赖本机未提交文件、内网服务或私有本地工具；
• 任务可以用明确的 diff 和测试结果验收；
• 允许在云端拉取代码，并接受云端运行时间与用量成本。

从 main 创建独立分支。
只修改 tests/auth/test_redirect.py，为登录后空白页补一个失败复现和一个成功断言。
运行项目约定的测试命令；不要修改生产代码，不要提交包含密钥的文件。
完成后返回根因、测试命令、退出码和完整 diff，先不要自动合并。

​

三个实际案例

​

案例一：陌生前端项目的空白页

1. IDE Chat 模式读取入口组件、登录请求、路由和错误边界；
2. 要求输出调用链、复现条件和最小修改计划；
3. 切到 Agent，只修改相关组件和回归测试；
4. 在 IDE Review 中确认没有顺手重构状态管理；
5. 用 CLI exec 以只读方式审查 diff，并运行前端测试和构建；
6. 若需要另一条线补测试，可在 Desktop App 的 Worktree 中单独完成。

​

案例二：每天审查提交并生成报告

codex exec --sandbox read-only --json \
  "审查 HEAD~1..HEAD 的改动。只读仓库，按严重度输出问题、文件位置和建议测试；不要修改、提交或推送。"

​

案例三：大仓库的依赖升级和长时间测试

1. 本地检查 AGENTS.md、包管理器、锁文件和测试命令；
2. 在 IDE Chat 中要求列出直接依赖、间接影响和回滚方式；
3. 把明确的分支、版本范围、禁止修改项写进 Cloud 任务；
4. 云端设置脚本只负责安装依赖，Agent 网络保持关闭，除非明确需要访问白名单域名；
5. 云端结束后审查锁文件、生产配置和测试日志；
6. 通过 PR 交给人工 Review，合并前在 CI 再跑一次。

​

交接协议：换入口前写清四件事

项目与基线：<仓库路径或 GitHub 仓库>，基于 <分支/commit>
当前状态：<已修改文件>，<是否有未提交改动>
已确认：<根因、方案、约束>
已验证：<命令> -> <退出码/结果>
下一步：<一个明确动作>
禁止：<不允许修改、联网、提交、推送或读取的内容>

​

验收清单

​

选择是否合理

• 入口选择由任务的上下文和运行位置决定，而不是由个人偏好决定；
• 需要本机文件或服务的任务没有误交给 Cloud；
• 需要脚本、SSH、CI 或机器可读输出的任务使用 CLI；
• 需要编辑器上下文的探索任务先在 IDE 完成；
• 需要并行时使用 Worktree 或独立云端容器；
• 成本、运行时间和用量边界已确认。

​

任务是否可交付

• 分支、commit、仓库路径和账号正确；
• diff 只包含目标文件和必要的测试/配置；
• git diff --check 通过；
• 格式化、类型检查、测试或构建命令有实际结果；
• 失败检查没有被忽略或用“应该没问题”替代；
• 未提交、未推送、未创建 PR 的约束得到遵守；
• 关键边界、错误路径、权限拒绝和回滚方式已检查。

​

Cloud 额外验收

• GitHub 仓库和授权范围正确；
• 云端运行时、设置脚本和锁文件一致；
• Secrets 没有写入仓库、日志或普通环境变量；
• Agent 网络保持关闭，或白名单和 HTTP 方法足够具体；
• 云端 diff、测试日志和 PR 分支可追溯；
• 合并前仍在 CI 或本地干净环境复验。

​

风险处理与回滚

​

发现改错了

​

发现并行冲突

​

发现权限或网络过宽

​

Cloud 结果不可复现

​

最小可执行流程

1. 在正确仓库运行 git status --short，确认分支和已有改动。
2. IDE 只读探索，使用 @file 或选中代码，得到范围和方案。
3. IDE 小范围实现，立即查看 diff。
4. CLI 运行 git diff --check、测试和只读 codex exec 审查。
5. 需要并行则 Desktop App 使用 Worktree；需要后台运行则 Cloud 使用隔离分支。
6. 交接时写状态、决策、证据、下一步和禁止事项。
7. 人工审查最终 diff，验证通过后再决定 commit、push 或 PR。

最重要的判断不是“我喜欢哪个入口”，而是“这个入口能否提供任务所需的上下文，同时把权限、并行和验收保持在可控范围内”。先用 IDE 把问题说清楚，再用 CLI 把验证变成可重复证据，最后按运行时间和并行需要选择 Desktop App 或 Cloud，通常能得到稳定且可恢复的协作结果。