企业官网建设流程全解析

很多人只把 Codex 当成代码生成器：写页面、改代码、解释报错。

真正拉开效率差距的，是 Plan、AGENTS.md、Worktree、子 Agent、Review 和 Skills 组成的完整工作流。

下面整理 10 个可以直接复用的 Codex 进阶技巧。

PS：还没安装配置Codex，可以借助AI编程助手完成部署。

01｜先开 Plan，避免边改边猜 🧠

面对陌生项目、复杂需求或跨文件重构，不要直接让 Codex 修改代码。

先通过/plan或Shift + Tab进入 Plan 模式，让它读取项目、划定范围、分析风险，再决定怎么改。

先不要修改任何文件。 请阅读当前项目，重点分析： 1. 相关模块和调用链； 2. 需要修改的文件； 3. 可能影响的现有功能； 4. 测试和验收方式。 如果需求存在歧义，先向我提问。 输出执行计划，等我确认后再修改。

如果需求本身还不清楚，再补一句：

先向我提出最多 6 个关键问题，确认用户流程、异常场景、权限边界和验收标准。

复杂任务先 Plan，通常比写完再返工更快。

02｜四段式指令锁定范围 🎯

提示词不需要写几千字，只要说清四件事：

目标： 需要完成什么功能。 上下文： 重点查看哪些文件、目录、报错或参考实现。 限制： 哪些内容不能改，需要遵守什么规范。 完成标准： 运行哪些测试、出现什么结果才算完成。

例如修复“退出登录后仍能访问个人中心”的问题，可以明确：

• 重点检查src/auth、中间件和路由守卫；

• 不修改现有登录接口；

• 不新增第三方依赖；

• 退出后访问/profile必须跳转到登录页；

• 修复完成后补充回归测试。

如果已经知道相关文件，可以直接使用@指定，减少 Codex 在整个仓库里盲目搜索。

好用的指令只需要回答四个问题：改什么、看哪里、不能碰什么、怎样才算完成。

03｜重复要求写进 AGENTS.md ⚙️

如果每次都要提醒 Codex：

• 修改后运行测试；

• 不要随意增加依赖；

• 使用 pnpm 而不是 npm；

• 不允许修改生产配置；

• API 返回结构必须统一；

那就把这些规则写进AGENTS.md。

Codex 开始工作前会自动读取该文件。CLI 用户还可以使用/init生成初始版本。

# 项目协作规则 ## 开发要求 - 修改前先阅读相关模块 - 不得修改生产环境配置 - 新增依赖前必须说明原因 - 修复 Bug 时必须补充回归测试 - 不得覆盖用户未提交的代码 ## 验收要求 - 运行单元测试 - 运行类型检查 - 汇总修改文件 - 说明仍然存在的风险

常用规则可以分成三层：

• ~/.codex/AGENTS.md：个人通用习惯；

• 项目根目录：整个项目的公共规范；

• 子目录：特定模块的单独要求。

不需要一开始写几千字。同一个错误出现两次，再把对应规则补进去。

04｜截图、日志、源码一次给全 📷

只说“页面有问题”或“运行报错”，Codex 很难准确判断。

排查问题时，最好同时提供：

• 截图：展示页面现象和错误位置；

• 日志：提供报错堆栈和执行路径；

• 源码：帮助定位真正原因。

Codex CLI 还有几个容易被忽略的命令：

排错时不要只发一张截图，可以直接告诉 Codex：

结合截图、控制台日志和相关源码定位原因，先判断问题来自页面样式、组件状态、接口数据还是路由权限，再修改并实际验证。

截图负责展示现象，日志负责提供证据，源码负责定位原因。

05｜Git + Review 双重验收 ✅

让 Codex 大范围改代码之前，先确认 Git 工作区状态，避免覆盖用户尚未提交的修改。

完成后不能只看“已经修复”的回复，还要检查实际差异和测试结果。

先检查当前 Git 状态和未提交修改， 不要覆盖已有代码，不要修改无关文件。 完成后运行相关测试并检查 Git diff， 再使用 /review 审查以下问题： 1. 功能回归； 2. 异常和边界处理； 3. 权限与数据安全； 4. 性能退化； 5. 测试遗漏。 Review 只输出问题，不要直接修改文件。

Codex CLI 的/review可以审查：

• 当前未提交修改；

• 某一次提交；

• 当前分支与目标分支的差异；

• 自定义文件或审查范围。

一套更稳的验收顺序是：

检查状态 → 实施修改 → 运行测试 → 查看 diff → 独立 Review。

06｜Worktree 隔离并行任务 🚀

ChatGPT 桌面端中的 Codex 支持 Git Worktree，可以基于同一个仓库创建多个相互隔离的工作副本。

例如：

• Worktree A：开发登录功能；

• Worktree B：修复支付 Bug；

• Worktree C：补充自动化测试；

• Local：继续处理当前工作。

不同 Worktree 拥有独立的文件和分支状态，不会直接挤在同一个工作区。

任务完成后，还可以通过 Handoff 转回本地继续检查。

它特别适合耗时较长、相互独立的任务。

需要注意两点：

1. 项目必须已经是 Git 仓库；

2. 多个任务尽量不要修改同一批文件。

否则节省的时间可能全部耗在冲突处理上。

07｜子 Agent 并行调查 🤖

Worktree 解决“代码修改相互隔离”，子 Agent 解决“分析任务并行处理”。

面对大型项目，可以让 Codex 主动分工：

请把这次问题排查拆给 3 个子 Agent： Agent 1：梳理前端登录状态和路由守卫； Agent 2：检查后端 Token 生成与失效逻辑； Agent 3：分析现有测试覆盖和复现步骤。 三个 Agent 只读取和分析，不修改文件。 最后由主 Agent 汇总结论并给出修复计划。

子 Agent 更适合这些读取型任务：

• 探索不同模块；

• 分析日志；

• 检查测试覆盖；

• 对比多个方案；

• 整理大型项目结构。

不要让多个 Agent 无边界地修改同一个模块。并行任务必须职责清楚、输入输出独立。

子 Agent 也会增加 Token 消耗，简单任务不需要强行拆分。

08｜重复流程封装成 Skill 🧩

一套提示词重复使用三次，就可以考虑做成 Skill。

Skill 可以包含：

• SKILL.md：执行步骤和规则；

• scripts/：辅助脚本；

• references/：参考资料；

• assets/：模板和固定资源。

适合封装成 Skill 的任务包括：

• 代码审查；

• Bug 排查；

• 发布前检查；

• 测试报告整理；

• 固定格式的文档生成。

例如“发布前检查”可以固定为：

运行单元测试和类型检查，检查 Git 差异、调试代码、临时文件和敏感信息，最后输出发布风险清单，未经确认不得部署。

以后只需调用 Skill，不必反复复制整段要求。

09｜仓库外数据交给 MCP 🔌

Codex 默认擅长处理项目里的文件和代码，但很多开发信息存在仓库之外，例如：

• GitHub Issue 和 Pull Request；

• 项目管理平台；

• 团队文档；

• 数据库；

• 错误监控系统。

这类场景可以通过 MCP 或插件连接外部工具，减少反复复制粘贴。

几个概念可以这样区分：

例如：

• “修改后必须运行测试”写进AGENTS.md；

• “怎样生成上线检查报告”做成 Skill；

• “读取项目管理平台中的任务”交给 MCP 或插件。

不要一开始接入十几个工具。先找出最重复、最耗时间的一条工作流，再增加对应能力。

10｜稳定流程定时运行 🔁

经过多次验证、流程已经稳定的任务，可以交给 Codex 定时执行。

常见场景包括：

• 每天检查失败测试；

• 每周整理依赖更新；

• 定期扫描过期文档；

• 汇总最近代码变化；

• 检查项目规则是否与代码现状脱节。

Git 项目可以让定时任务运行在独立 Worktree 中，避免影响正在开发的代码。

为了降低风险，定时任务最好遵守三个原则：

• 默认只检查和生成报告；

• 不自动部署；

• 不自动升级依赖或删除文件。

项目级任务运行时，电脑需要保持开机，ChatGPT 桌面端需要保持运行，项目目录也必须可以访问。

如果需要接入脚本或 CI/CD，还可以使用codex exec执行非交互式任务。

上面这些进阶用法的前提，是 Codex 已经完成安装和基础配置。

如果还没有跑通环境，可以参考这个 Codex 部署小助手，再继续配置AGENTS.md、Worktree、Skills 和自动化任务。

总结

Codex 的“奇技淫巧”不是冷门命令，而是更成熟的工作方式：

• 用 Plan 控制方向；
• 用 Git 和 Review 控制风险；
• 用 Worktree 和子 Agent 并行处理；
• 再用AGENTS.md、Skill 和定时任务持续复用。