Free Preview
先试读：Codex实战：从需求到可审PR的完整工作流
Codex 的产出深度，取决于你给它的任务是否像工程任务，而不是像一句愿望。
很多人用 Codex 的第一句是：“帮我把这个页面优化一下。”这句话太松。Codex 可能会改文案、改样式、改结构，甚至顺手改一些你没有要求的地方。最后它很努力，但你很难判断哪些改动是必要的。
这篇能解决什么问题
- 把一句模糊需求改成 AI 能执行、你能验收的任务卡。
- 知道执行前要先检查哪些文件、风险点和验证命令。
- 避免 AI 顺手改无关内容，最后只交付可审、可回退的改动。
付费后能看到哪些内容
- 先把“帮我改一下”改成一张任务卡
- 让 Codex 先找路，不要让它先动手
- 执行前必须要它交计划：文件、动作、验证、回退
- 执行中如何控制范围：让 Codex 做小步，不要做顺手优化
可以先照着试的一句话
这是我要改的功能：___。请先阅读项目结构，列出会动哪些文件、风险点和验证命令；等我确认范围后，再开始做最小改动。
试读到这里先判断是否对你的任务有用；完整文章会继续展开步骤、案例、模板和避坑细节。
先把“帮我改一下”改成一张任务卡
Codex 的产出深度，取决于你给它的任务是否像工程任务，而不是像一句愿望。
很多人用 Codex 的第一句是：“帮我把这个页面优化一下。”这句话太松。Codex 可能会改文案、改样式、改结构，甚至顺手改一些你没有要求的地方。最后它很努力，但你很难判断哪些改动是必要的。
更好的方式是把需求写成任务卡。任务卡不需要复杂，但必须包含五件事：背景、目标、范围、验收标准、禁区。
背景
为什么要改？现在用户遇到什么问题？只写和任务有关的上下文。
目标
改完以后要达成什么可观察结果，例如按钮可点击、入口可见、测试通过。
范围
预计涉及哪些页面、组件、脚本或测试；不确定时要求 Codex 先列范围。
禁区
明确不允许碰登录、支付、数据库、部署、外部发送、密钥和隐私数据。
背景：某个模拟会员页移动端底部按钮被遮住，用户无法继续操作。
目标：修复移动端遮挡问题，桌面端布局不能变坏。
范围：优先检查会员页 HTML/CSS 和相关共享样式；不要改后端。
验收标准：
1. 375px 宽度下底部按钮可见且可点击
2. 1440px 桌面布局不出现明显错位
3. 只改必要文件
禁区：不要修改登录、支付、数据库、部署脚本、外部 API 配置。这一层写清楚以后，Codex 才有机会像一个执行者，而不是像一个猜谜者。
让 Codex 先找路，不要让它先动手
Codex CLI 可以在选定目录里读文件、改文件、运行命令；官方文档也把 sandbox 和 approval 作为边界控制。第一步应该利用它的读取能力，而不是马上利用它的写入能力。
把任务卡交给 Codex 后，第一轮只让它做项目地图。项目地图不是让它解释所有文件，而是找出完成这个任务必须知道的入口。
| 要找什么 | 输出应该长什么样 | 为什么重要 |
|---|---|---|
| 相关文件 | 列出 3-8 个可能涉及的文件，并说明理由。 | 避免它大范围搜索后随意改无关文件。 |
| 验证命令 | 找到测试、构建、格式检查或本地预览方式。 | 没有验证，代码只是“看起来对”。 |
| 高风险区 | 列出不能碰或需要确认的文件。 | 防止一次小改动牵连账号、支付、数据或部署。 |
| 不确定点 | 明确哪些文件需要进一步确认。 | 让不确定性显性化，而不是藏在改动里。 |
请先只读当前项目，不要修改文件，不要运行写入/删除/部署/上传/外部发送命令。
请基于这张任务卡输出：
1. 你认为相关的文件列表和理由
2. 你认为不该碰的高风险文件
3. 可以用于验证的命令或手动检查方式
4. 你准备如何把任务拆成最小改动
只输出分析和计划，不要开始修改。执行前必须要它交计划：文件、动作、验证、回退
如果 Codex 不能在改之前说清楚它要做什么，改之后你会更难审。
计划不需要写成长篇报告，但必须可检查。一个合格的 Codex 执行计划应该包含：改哪些文件、每个文件改什么、为什么这样改、怎么验证、如果失败怎么处理。
“我会修复这个问题”不是计划。“我会修改 `member.css` 的移动端安全区处理，补一个 375px 检查，并确认桌面布局不变”才是计划。
执行中如何控制范围：让 Codex 做小步，不要做顺手优化
Codex 的一个常见问题不是能力不够，而是太愿意“顺便”。你要把“顺便”关掉。
在任务执行时，提示词里要明确禁止三个动作：顺手重构、顺手改命名、顺手统一风格。除非这些就是任务目标，否则它们会让 diff 变大，审查成本变高。
开始执行前请遵守：
- 只解决任务卡里的问题
- 不做顺手重构
- 不改无关命名
- 不改公共逻辑，除非你先说明并等待确认
- 如果发现更大的问题，先记录为“后续建议”，不要直接处理这段话看起来啰嗦，但能显著降低“一个小 bug 修出一堆无关 diff”的概率。
验收 diff，而不是验收总结
Codex 的总结是为了帮助你理解，不是事实本身。事实在 diff、测试结果和页面表现里。
Codex 做完后，你需要让它输出一份交付报告，但这份报告不是让你直接相信，而是帮你快速审查。
看文件范围
实际改动是否和计划一致，有没有动到禁区。
看行为变化
用户可见行为是否真的解决问题，而不是只改了表面文案。
看验证结果
测试、构建、预览、截图或手动检查是否真实执行。
看剩余风险
移动端、权限、数据、边界条件有没有未验证部分。
请用下面格式汇报：
1. 实际修改文件
2. 每个文件改了什么
3. 验证方式和结果
4. 未验证的部分
5. 你认为我应该重点审查的 diff
6. 是否触碰高风险区域：是/否，理由完整可复制模板：从需求到可审 PR
下面这段可以作为 Codex 执行小需求的固定开场。
你将处理一个模拟项目的小需求。请分阶段执行。
任务卡：
- 背景：[现象/用户问题]
- 目标：[可观察结果]
- 范围：[优先检查的页面/模块]
- 验收标准：[测试/构建/截图/手动检查]
- 禁区：[登录/支付/数据库/部署/外部发送/密钥]
阶段 1：只读项目地图
- 不修改文件
- 列出相关文件、高风险文件、验证方式、不确定点
阶段 2：执行计划
- 列出要改的文件
- 说明每个文件为什么要改
- 说明验证方式和回退方式
- 等我确认后再改
阶段 3：执行
- 只解决目标问题
- 不做顺手重构
- 不改无关文件
阶段 4：交付
- 汇报实际改动、验证结果、未验证部分、重点审查 diff- 不是“Codex 说完成了”，而是 diff 可审、验证可复现。
- 不是“一次改很多”，而是一个任务一个闭环。
- 不是“把风险藏起来”，而是明确哪些没有验证。
- 不是“让 AI 替你负责”，而是让 AI 把执行工作推进到你可以判断。