第二章：桌面工作流

App 的核心模型

Codex App 可以理解为一个桌面开发主控台。它把这些能力放到同一个工作流里：

内嵌表格

本系列后续功能都要回到这个模型里解释。

三种工作方式

2.1 Local thread

适合小任务和只读任务：

阅读这个项目并总结启动命令、测试命令、主要目录。不要修改文件。

优点：快，直接使用当前工作区。

风险：如果让 Codex 写文件，改动会进入当前工作区。学习阶段要盯住 Review 面板。

2.2 Worktree thread

适合功能开发、重构、风险较高的改动：

在新的 worktree 里实现登录页移动端布局修复。改完运行相关测试，最后给我 diff 摘要。

优点：隔离改动，多个任务可以并行。

注意：worktree 仍然是真实 Git 工作区。合并前要 Review。

2.3 Cloud / Web handoff

适合云端仓库任务、长时间后台任务和 PR 工作流。App 是本地主控台，Cloud 是远程执行环境。不要把 Cloud 当成本地 App 的替代品。

App 任务描述模板

好任务要包含五件事：

目标：修复用户资料页加载失败。
范围：只改 src/pages/profile.tsx 和 src/api/user.ts。
约束：不要改数据库 schema，不要引入新依赖。
验证：运行 npm test -- profile。
交付：展示 diff 摘要和测试结果，不要自动提交。

不要只写：

帮我修一下。

因为 Codex 不知道范围、验证方式和停止条件。

App Review 工作流

每次 Codex 修改文件后，你都应该看 Review：

1. 看文件列表：确认只改了目标范围。
2. 看 diff：确认行为变化合理。
3. 看测试输出：确认验证真的跑过。
4. 行内指出问题：让 Codex 继续修。
5. 需要提交时再 stage / commit。

典型提示：

Review 这次 diff。重点检查是否改了范围外文件、是否缺测试、是否引入兼容性风险。

App 中的 Commands

Commands 是 App 里最快的工作流入口。你可以在输入框里输入 / 查看当前可用命令。

常见类型：

内嵌表格

不同版本、实验开关和插件会改变命令列表。App 用户先输入 / 看当前列表；/goal、/loop 等长目标/循环入口如果当前 App 显示，再按 CX-03 的实验能力写法使用。完整讲解见 CX-03。

App 中的项目指令

AGENTS.md 是 Codex 理解项目规则的核心文件。它应该写：

• 项目是什么。
• 常用命令是什么。
• 代码风格和测试要求。
• 哪些文件不要动。
• 修改后如何验证。

不要把临时任务、密钥、个人路径写进去。详见 CX-04。

App 中的 MCP

MCP 是外部工具协议。App 通过 MCP 使用浏览器、数据库、文档源、内部系统等工具。

App 用户应该先理解：

• MCP 不是 prompt。
• MCP server 可能带权限和数据风险。
• 连接后要在 App 或 /mcp 中确认工具是否可用。
• CLI 管理 MCP 只是辅助，不是主线。

详见 CX-05。

App 中的 Skills

Skills 是可复用工作流。适合把“每次都要重复说的步骤”沉淀下来。

例如：

• 代码审查流程。
• 发布前检查。
• 文档核对流程。
• 特定团队的写作规范。

App 中可以通过自然语言或 $skill-name 点名触发。详见 CX-06。

App 中的 Plugins / Connectors

Plugins 是能力包，可能包含 Skills、MCP、Apps、配置等。Connectors 是连接外部服务的入口，例如 GitHub、Google Drive、Slack、Gmail 等。

App 用户要记住：

• 安装插件不等于自动授权所有外部数据。
• 连接器需要单独登录和授权。
• 外部服务权限要按最小范围配置。

详见 CX-07。

App 中的 Subagents

Subagents 适合并行分析、分工改代码、独立审查。不要滥用。

适合：

• 一个 agent 查 API 文档，一个 agent 看代码实现。
• 一个 agent 改前端，一个 agent 改测试。
• 一个 agent 做实现，一个 agent 做 review。

不适合：

• 单个错别字。
• 线性的一步任务。
• 你还没定义清楚范围的大任务。

详见 CX-08。

App 中的 Automations

Automations 用来让 Codex 周期性或后台执行任务：

• 每天检查测试是否失败。
• 每周总结依赖更新。
• 定期检查文档是否和代码漂移。
• 监控某个 PR 或部署状态。

创建自动化前要明确：

• 运行频率。
• 工作目录。
• 是否允许写文件。
• 找到问题后通知还是自动修。

详见 CX-09。

App 与 GitHub / PR

App 的 Git 工作流通常是：

1. Codex 修改本地文件。
2. 你在 Review 面板检查。
3. 运行测试。
4. stage / commit。
5. 推送分支。
6. 创建 PR。
7. 必要时交给 Cloud / Web 继续处理。

GitHub / PR 详见 CX-10。

App 用户什么时候看 CLI / Web

内嵌表格

常见问题

Q1：App 是不是只能聊天？

不是。App 是本地开发主控台，核心是线程、文件改动、Review、终端、插件、自动化。

Q2：所有功能都要学吗？

不需要。先掌握 Thread、Review、Commands、AGENTS.md，再按需要学 MCP、Skills、Plugins、Automations。

Q3：App 中看到的命令和 CLI 一样吗？

不一定。以当前 App 的 /help、命令补全和官方文档为准。CLI 能帮助核对，但不是 App 的替代品。