首页 > 基础资料 博客日记
我用了 8 个月 Codex CLI,总结出这套 AI 编程工作流
2026-05-29 15:00:01基础资料围观5次

大家好,我是程序员海军,全栈开发|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,输出优先级化、可执行的问题,不会修改工作树。
也可以使用我们自己定制的标准去审 也可以使用Codex review
我的提示词是这样的:
codex "
请审查当前未提交改动。
重点检查:
1. 是否有行为回归
2. 是否有类型风险
3. 是否破坏响应式
4. 是否有无关文件改动
5. 是否有可维护性问题
6. 是否缺少必要测试
只输出高风险问题和建议修复方案,不要改代码。
"
MCP 增强工作流
我们可以使用外部MCP 扩展Codex 能力,例如对接设计稿实现,我们可以 Figma MCP, 如果想基于最新文档开发,可以使用 Context7 MCP等等
安装使用也很简单
codex mcp add context7 -- npx -y @upstash/context7-mcp
SKILLS 工作流
像我们经常使用的一些提示词,可以把它提炼成SKILLS,这样在实际开发的时候,可以直接使用SKILLS,只需要把变量因素告诉它,它就可以基于我之前提炼号的SKILLS进行开发了。
SKILLS 又分为系统级别和项目级别,这个看自己的需求,如果只是那种通用的SKILLS,可以放到全局,如果只是当前项目经常使用的一些提示词,可以把它封装成SKILLS,然后放置到自己的项目当中\.agents/skills。这样在使用Codex 时,它会识别你的问题意图然后调用对应的 SKILLS。也可以直接告诉它使用哪个SKILLS
例如
codex "
使用 haijun skill,实现这个页面。
"
最后
我想说一点真实感受。
很多人用 AI 写代码觉得不稳定,问题不一定出在工具本身,而是我们还在用“提需求”的方式使用它,却没有用“带团队”的方式管理它。你不给项目背景,它就只能猜;你不给边界,它就可能乱改;你不给验证标准,它就不知道什么叫完成;你不做最后判断,它就可能把一个看似能跑的方案交给你。
AI的上限取决于使用AI人的专业能力水平+认知能力水平如何....
我之前也长期用 Cursor,后来也用过一段时间 Claude Code。Claude Code 确实很强,很多时候强得让人印象很深,只是它对国内用户的限制比较明显,使用稳定性和可持续性对我来说不太理想。后来我慢慢切到了 Codex CLI,到现在已经用了半年多,甚至可以说,它已经成了我日常开发里最重要的协作工具之一。
这半年多,它帮我完成了很多事情:写页面、改组件、排查 Bug、重构项目、梳理架构、设计 Agent 工具、优化 RAG 链路、生成文档、做上线前检查。它不只是帮我“写代码”,更像是帮我把很多开发环节重新组织了一遍。
但前提是,你得给它一套工作方式。
所以我现在越来越确定,未来真正拉开差距的,不是谁会用某一个 AI 工具,而是谁能把 AI 工具变成自己的工程系统、内容系统、业务系统,甚至是个人能力放大器。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!
标签:

