用 Codex 写了 8 个月代码后，很多人的感受是：它有时聪明得离谱，有时又会把事情搞复杂。关键不在于 Codex 聪不聪明，而在于你有没有给它一套稳定的工作流边界。
这篇文章把我在真实项目里反复验证过的一套 Codex CLI 高阶工作流拆开来讲——从截图还原前端页面，到 BUG 自动排查、大重构四步法、自审闭环，每一步都有可直接复制的提示词模板。
一、核心心法：固定工程流
在开始任何任务前，先把这七条规则刻进你的习惯：
- 项目规则沉淀到
AGENTS.md- 个人默认配置沉淀到
~/.codex/config.toml- 重复任务沉淀成 Skills
- 外部上下文交给 MCP
- 复杂任务先 Plan 再执行
- 前端任务用截图 + Playwright 闭环
- 风险任务用
/review/ diff / sandbox 控制- 稳定任务用
codex exec自动化
这七条不是玄学，是每次踩坑后总结出来的"稳态"。下面按场景展开。
二、截图还原前端页面：从"看一眼"到"做出来"
很多人直接用 Codex 写页面，效果往往差强人意。更高效的方式是先分析、再实现。
步骤 1：让 Codex 先分析截图（不要直接让它改代码）
codex -i ./screenshots/home.png "
先不要改代码。
请分析这张截图，并结合当前项目结构，输出：
1. 页面结构
2. 组件拆分
3. 样式系统映射
4. 需要新增/复用的组件
5. 可能不清晰的截图细节
6. 实现计划
"
这一步的价值：让 Codex 先"看懂"，再"动手"。跳过这一步直接让它实现，经常会出乱子。
步骤 2：基于分析结果实现
codex resume --last "
按照上一步计划实现页面。
要求小步修改，优先复用已有组件。
完成后运行 lint、typecheck、build。
如果有样式偏差，说明原因。
"
步骤 3：视觉差异自动修复
如果还有差异，用对比图让 Codex 自动修复：
codex resume --last \
-i ./references/target.png \
-i ./screenshots/current.png \
"第一张是目标图，第二张是当前实现效果。
请对比差异，只修复视觉差异，不要重构无关代码。
重点检查：
1. 页面整体比例
2. 顶部间距
3. 标题字号和字重
4. 卡片圆角、阴影、边框
5. 按钮尺寸和位置
6. 移动端断点
7. 是否存在横向溢出
完成后运行检查，并输出修改点。"
进阶：Playwright 视觉闭环
让 Codex 打开真实浏览器，对比截图做迭代：
codex -i ./references/home.png "
请实现这张参考图对应的页面，并使用 Playwright 做视觉验证。
要求：
1. 先确认本项目如何启动本地开发服务。
2. 实现页面后启动服务。
3. 使用 Playwright 打开页面并截图。
4. 对比参考图和当前截图，修正明显差异。
5. 至少检查 desktop 和 mobile 两个断点。
6. 最后输出差异说明和验证结果。
"
三、BUG 排查工作流：别上来就改代码
BUG 排查是最容易跑偏的场景——Codex 一激动，全项目代码乱改一通。
标准排查流程
把报错日志和你的范围限制一起给它：
Codex 日志一般在
History.log，你可以把相关段落复制给它。
codex "
请基于日志去排查处理这个问题。
工作方式：
1. 先不要改代码。
2. 找到可能相关的页面、组件、状态管理、接口请求和样式文件。
3. 说明最可能的 2-3 个原因。
4. 如果可以运行项目，请尝试复现。
5. 确认根因后，再做最小修改。
6. 修改后运行相关检查。
7. 最后说明根因、改动文件、验证方式。
"
核心原则：先定位，再修改。范围越清晰，Codex 越稳。
四、大重构工作流：四步走，别让 AI 一把梭
老项目重构，千万别让 Codex 直接动——它理解成本很高，改完往往一团糟。
四步法
理解现状 → 识别风险 → 制定迁移计划 → 分批执行
提示词模板
codex "
我准备重构当前项目的组件结构。先不要改代码。
请输出：
1. 当前组件目录结构和主要职责
2. 重复代码和可抽象点
3. 高风险文件
4. 推荐的目标目录结构
5. 分阶段迁移计划
6. 每阶段的验证方式
7. 哪些地方不建议现在动
"
拿到报告后，按阶段分批执行，每完成一个阶段就提交一次，随时可以回滚。
五、自审工作流：用 /review 做最后一道防线
Codex CLI 内置 /review 命令，可以审查工作区、commit 或基于分支的 diff，以独立 reviewer 视角输出优先级化问题，不会修改任何文件。
自定义审查提示词
codex "
请审查当前未提交改动。
重点检查：
1. 是否有行为回归
2. 是否有类型风险
3. 是否破坏响应式
4. 是否有无关文件改动
5. 是否有可维护性问题
6. 是否缺少必要测试
只输出高风险问题和建议修复方案，不要改代码。
"
这一步不是形式主义——让你自己在合并前看到 Codex 自己都没意识到的问题。
六、MCP + Skills：把能力封装进工具链
MCP 接入外部工具
比如接 Context7（获取最新文档）：
codex mcp add context7 -- npx -y @upstash/context7-mcp
Skills 封装高频提示词
把常用提示词提炼成 Skills，放在项目 .agents/skills/ 目录下。使用时直接调用：
codex "使用 xxx-skill，实现这个页面。"
Skills 分为系统级（全局）和项目级（仅当前项目），按需选择。
七、固定工作流速查表
| 场景 | 推荐工作流 | 关键命令 |
|---|---|---|
| 前端页面还原 | 截图分析 → 实现 → 视觉对比修复 | codex -i screenshot.png |
| BUG 排查 | 先看日志，定位根因，最小修改 | codex + 日志上下文 |
| 大重构 | 四步法：理解→风险→计划→分批 | codex "先不要改代码..." |
| 代码审查 | /review + 自定义检查清单 |
codex /review |
| 高频任务 | 沉淀为 Skills | codex "使用 xxx-skill" |
| 外部数据源 | 接入 MCP | codex mcp add ... |
八、写在最后
Codex 不是魔法，它是你工程能力的放大器。给它的边界越清晰，它给你的结果就越稳。
这八个月我踩过的坑总结成一句话：宁可花 5 分钟让 Codex 先规划，也不要让它花 50 分钟给你一堆要返工的东西。
来源：编程知识《我用了 8 个月 Codex CLI，总结出这套 AI 编程工作流》（hqwc.cn，2026-09-24）
资料最后核对日期：2026-09-24 · 内容整理自 CodexGuide 社区公开教程