我用了 8 个月 Codex CLI，总结出这套 AI 编程工作流
久没更新文章了。
这段时间确实太忙，一直在公司里推进 AI 项目开发。很多事情从需求拆解、方案设计、前后端开发，到 Agent、RAG、接口联调、上线排查，基本都是我一个人往前扛，不过好在有我的战友和我战斗，Codex！
从去年到现在，我对 AI 工具的感受越来越强烈：变化真的太快了。
去年我们还觉得，AI 每隔四五个月来一次大更新，就已经很夸张了。现在不一样了，很多能力几乎一两个月就会被重塑一次。模型在变，工具在变，开发方式也在变。以前我们讨论的是“AI 能不能帮我写代码”，现在更现实的问题已经变成了：你能不能把 AI 变成一套稳定、可控、可复用的工程工作流。
我大概摸索 Codex CLI 有 8 个月了。中间用它开发过不少项目，也踩过很多坑：有时候它很聪明，有时候也会乱来；有时候效率高得离谱，有时候如果你不给边界，它也会把事情搞复杂。这篇文章就想把我这 8 个月总结出来的 Codex CLI 高阶工作流分享出来。分享我在真实项目里反复用、反复调、最后觉得比较稳定的一套 AI 编程提效系统。
固定工程流
任务上下文、AGENTS.md、配置、MCP、Skills、自动化是提高 Codex 稳定性的关键路径。
项目规则沉淀到 AGENTS\.md 个人默认配置沉淀到 \~/\.codex/config\.toml 重复任务沉淀成 Skills 外部上下文交给 MCP 复杂任务先 Plan 再执行 前端任务用截图 \+ Playwright 闭环 风险任务用 review / diff / sandbox 控制 稳定任务用 codex exec 自动化Codex CLi 能力边界探索
本地代码代理能力
Codex CLI 不是只能生成代码片段，它可以在你选定的目录里读取仓库、编辑文件、执行命令。
新功能开发 Bug 排查 前端页面实现 组件重构 接口联调 测试补齐 代码审查 文档生成 脚本自动化 项目结构理解 技术债梳理越是模糊、跨模块、影响面大的任务，越应该先让它规划、定位、确认边界，再让它改代码。
先进入 Plan 模式，让 Codex 收集上下文、提出问题、形成计划后再实现。
图片理解前端复原
官方支持\-i/\-\-image给初始 prompt 附加图片，一张或多张都可以，多张可以逗号分隔，也可以重复传入。常见格式如 PNG、JPEG 都支持。
codex -i ./screenshots/home.png "请分析这张前端页面截图，并在当前项目中实现对应页面"使用边界：图片只负责提供视觉目标，不负责替代工程上下文。如果只给一张截图，它能做出大概效果；如果同时给出页面很多状态以及细节部分，那么它还原会稳定很多。
更高效的用法：
codex \ --sandbox workspace-write \ --ask-for-approval on-request \ -i ./screenshots/home-desktop.png \ -i ./screenshots/home-mobile.png \ "请基于两张截图实现当前项目首页。 先阅读项目结构，确认路由、组件目录、样式方案、设计系统和已有页面实现。 再分析截图中的布局、组件层级、间距、字体、颜色、响应式规则。 实现时优先复用现有组件、tokens、Tailwind 配置和项目约定，不要另起一套风格。 完成后运行 lint、typecheck、build。 最后说明：改了哪些文件、哪些地方是根据截图推断的、还有哪些视觉差异需要人工确认。"Playwright 视觉闭环
我们可以结合 Playwright，让 Codex 打开真实浏览器，对比实现结果和参考图，在不同屏幕尺寸下迭代布局和行为。
完整的高效工作流：
参考图 → 实现页面 → 启动本地服务 → 浏览器打开 → 截图对比 → 修正 → 再检查提示词可以这样写：
codex -i ./references/home.png " 请实现这张参考图对应的页面，并使用 Playwright 做视觉验证。 要求： 1. 先确认本项目如何启动本地开发服务。 2. 实现页面后启动服务。 3. 使用 Playwright 打开页面并截图。 4. 对比参考图和当前截图，修正明显差异。 5. 至少检查 desktop 和 mobile 两个断点。 6. 最后输出差异说明和验证结果。 "我的实战工作流
截图转页面工作流
不直接让它干，先让Codex 分析图片元素
codex -i ./screenshots/home.png " 先不要改代码。 请分析这张截图，并结合当前项目结构，输出： 1. 页面结构 2. 组件拆分 3. 样式系统映射 4. 需要新增/复用的组件 5. 可能不清晰的截图细节 6. 实现计划 "然后再让它实现
codex resume --last " 按照上一步计划实现页面。 要求小步修改，优先复用已有组件。 完成后运行 lint、typecheck、build。 如果有样式偏差，说明原因。 "当前效果图 和 目标图对比 自动修复
可以先让Cdoex 基于图片实现一版本，然后使用该段提示词让它自动对比修复差距。
codex resume --last \ -i ./references/target.png \ -i ./screenshots/current.png \ "第一张是目标图，第二张是当前实现效果。 请对比差异，只修复视觉差异，不要重构无关代码。 重点检查： 1. 页面整体比例 2. 顶部间距 3. 标题字号和字重 4. 卡片圆角、阴影、边框 5. 按钮尺寸和位置 6. 移动端断点 7. 是否存在横向溢出 完成后运行检查，并输出修改点。"BUG 排查工作流
这一步很重要，有时改不好，整个系统一堆烂泥，越改越乱。
我们可以把报错的日志+以及范围告诉它，越清晰越好，这样的话它理解起来以及改动会越稳，因为有了范围限制。它不会乱改。
codex 日志在 History.log"
请基于日志去排查去处理这个问题。
工作方式：
先不要改代码。
找到可能相关的页面、组件、状态管理、接口请求和样式文件。
说明最可能的 2-3 个原因。
如果可以运行项目，请尝试复现。
确认根因后，再做最小修改。
修改后运行相关检查。
最后说明根因、改动文件、验证方式。
"
大重构工作流
尤其老项目改时，千万不要让AI 直接改，老项目本身就够复杂，AI理解起来也困难。
可以拆成4层让AI 去跑，这样比较稳。
理解现状-----> 识别风险-----> 制定迁移计划-----> 分批执行提示词可以这样写
codex " 我准备重构当前项目的组件结构。先不要改代码。 请输出： 1. 当前组件目录结构和主要职责 2. 重复代码和可抽象点 3. 高风险文件 4. 推荐的目标目录结构 5. 分阶段迁移计划 6. 每阶段的验证方式 7. 哪些地方不建议现在动 "自审工作流
Codex CLI 有/review，可以审查工作区、commit 或基于分支的 diff，而且官方说明它会以独立 reviewer 方式读取 diff，输出优先级化、可执行的问题，不会修改工作树。
也可以使用我们自己定制的标准去审 也可以使用Codexreview
我的提示词是这样的：
codex " 请审查当前未提交改动。 重点检查： 1. 是否有行为回归 2. 是否有类型风险 3. 是否破坏响应式 4. 是否有无关文件改动 5. 是否有可维护性问题 6. 是否缺少必要测试 只输出高风险问题和建议修复方案，不要改代码。 "MCP 增强工作流
我们可以使用外部MCP 扩展Codex 能力，例如对接设计稿实现，我们可以 Figma MCP， 如果想基于最新文档开发，可以使用 Context7 MCP等等
安装使用也很简单
codex mcp add context7 -- npx -y @upstash/context7-mcpSKILLS 工作流
像我们经常使用的一些提示词，可以把它提炼成SKILLS，这样在实际开发的时候，可以直接使用SKILLS，只需要把变量因素告诉它，它就可以基于我之前提炼号的SKILLS进行开发了。
SKILLS 又分为系统级别和项目级别，这个看自己的需求，如果只是那种通用的SKILLS，可以放到全局，如果只是当前项目经常使用的一些提示词，可以把它封装成SKILLS，然后放置到自己的项目当中\.agents/skills。这样在使用Codex 时，它会识别你的问题意图然后调用对应的 SKILLS。也可以直接告诉它使用哪个SKILLS
例如
codex " 使用 haijun skill，实现这个页面。 "