固定工程流

任务上下文、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"

请基于日志去排查去处理这个问题。

工作方式：

1. 先不要改代码。

2. 找到可能相关的页面、组件、状态管理、接口请求和样式文件。

3. 说明最可能的 2-3 个原因。

4. 如果可以运行项目，请尝试复现。

5. 确认根因后，再做最小修改。

6. 修改后运行相关检查。

7. 最后说明根因、改动文件、验证方式。

"

大重构工作流

尤其老项目改时，千万不要让AI 直接改，老项目本身就够复杂，AI理解起来也困难。

可以拆成4层让AI 去跑，这样比较稳。

理解现状-----> 识别风险-----> 制定迁移计划-----> 分批执行

提示词可以这样写

codex "
我准备重构当前项目的组件结构。先不要改代码。

请输出：
1. 当前组件目录结构和主要职责
2. 重复代码和可抽象点
3. 高风险文件
4. 推荐的目标目录结构
5. 分阶段迁移计划
6. 每阶段的验证方式
7. 哪些地方不建议现在动