📘 OpenAI Codex理解版 · 从原理到实战
11 · 从理解到实战场景
模糊度更高的输入。没分诊就动手 = 灾难。
⏱️ 预计阅读 12 分钟 | 🎯 目标:把"懂概念"变成"真任务能写出来"
前 10 篇讲了所有概念。这一篇做统一动作:拿真实模糊需求 → 改写成 Codex 能执行、能验证、能交付的任务。 理解 ≠ 会用。这一篇是落地的 lever(杠杆)。
🎬 一句模糊话 → 一份工程任务
flowchart LR
Vague["💬 模糊一句话<br/>'帮我把网站做快一点'"]
Step1["1️⃣ 分诊<br/>问题在哪"]
Step2["2️⃣ 收证据<br/>读现场"]
Step3["3️⃣ 拆任务<br/>明确边界"]
Step4["4️⃣ 写提示词<br/>带验收"]
Run["🤖 Codex 执行"]
Vague --> Step1 --> Step2 --> Step3 --> Step4 --> Run
style Vague fill:#fee2e2,stroke:#ef4444
style Run fill:#dcfce7,stroke:#22c55e
核心铁律:前 4 步都不动代码。这是把模糊变清晰的代价,比改完回滚便宜得多。
🩺 案例 1:「网站做快一点」
Step 1 · 分诊(不改代码)
提示词:
请分诊「网站做快一点」这个需求,不要改文件。
请输出:
- 这句话的可能含义有哪些(首屏快 / 加载快 / 交互快 / SEO 快…)
- 每种含义需要查什么证据
- 推荐先确认哪个含义Codex 给的:
可能含义:
1. 首屏 LCP(Largest Contentful Paint)慢
2. 加载所有资源慢(带宽 / CDN)
3. 路由切换交互卡顿
4. API 响应慢
5. 搜索引擎抓取慢
建议先打开 Chrome DevTools Performance 录一段,看到底慢在哪。💡 分诊价值:让你和 Codex 在同一频道,避免它去优化错地方。
Step 2 · 收证据
请围绕首屏 LCP 慢收集证据,不要改文件。
请查找:
- next.config.js 配置
- _app.tsx 全局加载
- 首屏组件(Home / Hero / 主图)
- 图片大小 / 格式
- 第三方脚本(analytics / chat widget)Step 3 · 拆任务
基于证据,拆成最小修复任务:
任务 A: 把首屏图片转 WebP + 加 priority loading
任务 B: 把 analytics 脚本延后 (lazy)
任务 C: 把第三方 chat widget 延后到用户交互后再加载
每个任务独立,先做 A,看效果再决定 B/C。Step 4 · 写正式任务
任务 A · 首屏图片优化
🎯 目标:
首屏 LCP 从 3.2s 降到 < 1.8s
📁 范围:
- 只改 components/Hero.tsx 和 public/images/hero.*
- 不改其他页面、不改路由
🚧 边界:
- 不新增图片处理库(用 next/image)
- 不动 next.config.js 全局配置
✅ 验证:
- Chrome DevTools Lighthouse Performance ≥ 90
- 首屏 LCP < 1.8s
- 视觉效果一致(前后截图对比)
请先给计划,确认后再改。🐛 案例 2:「这个 bug 你看下」
模糊度更高的输入。没分诊就动手 = 灾难。
Step 1 · 分诊
请分诊:
报错截图描述:用户说「点保存按钮没反应」
请问我以下信息(不要改文件):
- 哪个页面 / 哪个按钮
- 浏览器 + 系统 + 版本
- 控制台报错全文
- 最近改了什么
- 能稳定复现还是偶发Step 2 · 三层假设
让 Codex 给假设清单,再让你筛掉不合理的:
基于现有信息(控制台报错 Cannot read properties of undefined):
可能原因(按概率排序):
1. 🔴 数据返回结构变了(API 少字段)
2. 🟡 状态管理初始值缺失
3. 🟢 异步竞态(先点先 race)
建议先验证 1:用 curl 调当前 API 看返回结构。Step 3 · 最小修复
任务:修复保存按钮 undefined 错误
🎯 目标:
profile API 返回 email 缺失时不崩溃
📁 范围:
- 只改 components/ProfileForm.tsx
- 加可选链 + 默认值
🚧 边界:
- 不改 API(那是后端的事,单独 issue)
- 不改其他页面
✅ 验证:
- email 缺失时显示 placeholder 而不是 crash
- 补一个测试用例覆盖 email = undefined
- pnpm test ProfileForm 通过
请先给计划。📚 案例 3:「读懂这个新代码库」
新人入职最常见的需求。不要让 Codex 直接动。
我刚加入这个项目。请帮我建立项目地图,不要修改文件。
请阅读:
- README / CONTRIBUTING / AGENTS.md
- package.json / pyproject.toml
- 主要源码目录(src/ 或 packages/)
- 路由 / 入口文件
- 测试目录
请输出:
1. 项目用途(一句话)
2. 技术栈(语言 / 框架 / 包管理器)
3. 主要目录职责(每个 ≤ 1 行)
4. 启动 / 测试 / 构建命令
5. 最重要的 5 个文件 + 为什么
6. 「我作为新人下一步该读什么 / 做什么」
7. 你不确定的地方明确标出💡 这条提示词翔宇本人每次接陌生项目都用。比自己 ls / cat 半小时高效多了。
🎯 4 类高频实战场景的提示词模板
按你现在最可能遇到的场景,给可直接复用的模板:
A · 修中等规模 bug
任务:修 {bug 描述}
🎯 目标:{用户角度的现象消失}
📁 范围:只改 {目录}
🚧 边界:
- 不改无关文件
- 不新增依赖
- 不改 db / .env / 部署配置
✅ 验证:
- {真实验证命令,如 pnpm test X}
- {人工验收步骤}
📦 交付:
- 修改文件清单
- 验证结果
- 剩余风险
请先给计划,等我确认。B · 补一个测试
任务:给 {组件 / 函数} 补单测
🎯 覆盖点:
- 正常路径
- {边界 1}(如空数组)
- {边界 2}(如 null)
- {边界 3}(如错误状态)
🚧 边界:
- 不改源文件,只加测试
- 用项目已有 testing-library / vitest
✅ 验证:
- pnpm test 通过
- 覆盖率 ≥ {目标}
📦 交付:测试文件 + 覆盖率说明C · 局部小重构
任务:重构 {文件 / 模块}
🎯 目标:
- {可衡量目标,如「把 200 行 handler 拆成 ≤ 50 行的 N 个 helper」}
- 行为不变(regression test 通过)
🚧 边界:
- 只改 {文件}
- 不改其他文件的导入
- 不动签名(API 不变)
✅ 验证:
- 所有相关测试通过
- 类型检查通过
- 行为对比(diff 不该有功能变化)D · 改 API 接入
任务:把 {API} 从 v1 升级到 v2
🎯 目标:
- 替换调用点
- 适配新返回结构
📁 范围:
- 只改 lib/api/{module}.ts
- 调用此 API 的页面只改类型,不改逻辑
🚧 边界:
- 不改其他 API
- 不改 UI 行为(除非 v2 字段缺失要兜底)
✅ 验证:
- 类型检查通过
- 集成测试通过
- 手工跑一次主流程🚫 把模糊需求变可执行:4 个最常踩坑
| ❌ 踩坑 | ✅ 修法 |
|---|---|
| "帮我优化"(没具体目标) | 必须有可衡量指标:"LCP 降到 1.8s 以下" |
| 不写禁止事项 | 至少列 3 条不该改的:依赖 / 全局配置 / 部署 / 无关页面 |
| 验证只写 "跑测试" | 验证要跟目标对应:改 UI 看截图、改性能看 Lighthouse、改 API 看接口测试 |
| 跳过分诊直接动 | 所有含糊任务都先分诊:让 Codex 列假设、问问题,你确认方向再上 |
📊 你已经会的全部技术(前 10 篇大复盘)
按"接到任务该怎么做"重排:
flowchart TB
T[💬 接到任务]
Q1{任务清楚吗}
P1[📖 分诊 + 收证据<br/>第 11 篇]
Q2{规则齐吗}
P2[📜 写 AGENTS.md<br/>第 4 篇]
Q3{选哪个入口}
P3[🚪 4 入口选 1-2<br/>第 6 篇]
Q4{要边界吗}
P4[🛡️ sandbox + approval<br/>第 5 篇]
Q5{需要外部工具吗}
P5[🔌 MCP / 浏览器<br/>第 7 篇]
Q6{重复任务吗}
P6[🛠️ Skill / Subagent / Hook<br/>第 8 篇]
Run[🤖 执行]
V[✅ 验证 4 项证据<br/>第 2 篇]
T --> Q1
Q1 -->|否| P1 --> T
Q1 -->|是| Q2
Q2 -->|否| P2 --> T
Q2 -->|是| Q3 --> P3 --> Q4 --> P4 --> Q5 --> P5 --> Q6 --> P6 --> Run --> V
style P1 fill:#dcfce7,stroke:#22c55e
style V fill:#fef3c7,stroke:#f59e0b
🎯 这就是 Codex 工程协作系统的全貌。 12 篇里每一篇都对应这条决策链上的一个节点。
🔍 想再深一层(点击展开)
📋 万能任务提示词(直接抄)
请完成下面任务,但先停在计划阶段。
🎯 目标:
{描述完成后达到什么效果,可衡量}
📁 范围:
{允许修改的文件或目录}
🚧 禁止事项:
- 不新增依赖(除非先说明理由等我确认)
- 不修改无关文件
- 不做需求外功能
- 不改公开 API
- 不改部署 / 配置 / 环境变量
🔄 执行要求:
1. 先阅读相关上下文
2. 复述你理解的目标和边界
3. 给出最小修改方案
4. 标出风险和需要确认的问题
5. 等我确认后再改
✅ 验证:
{真实验证命令或人工验收步骤}
📦 交付:
- 修改文件清单
- 验证结果
- 未验证项 + 原因
- 剩余风险🩺 分诊型提示词(处理含糊需求)
请分诊以下需求,不要改文件。
需求:
{贴用户原话}
请输出:
1. 这句话可能的含义(≥ 3 种)
2. 每种含义需要什么证据来确认
3. 推荐先做哪一种验证
4. 不确定的地方需要我补充什么📖 术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| 分诊 | triage | 把模糊问题拆成可验证的假设 |
| LCP | 最大内容绘制 | Largest Contentful Paint,首屏关键性能指标 |
| regression test | 回归测试 | 验证已有功能没坏的测试 |
| race condition | 竞态条件 | 多个异步操作顺序不确定导致的 bug |
| placeholder | 占位符 | 数据缺失时显示的默认值 |
📝 本章自检
| # | 问题 | 自检 |
|---|---|---|
| 1 | 模糊需求 → 工程任务的 4 步是什么? | ☐ |
| 2 | 「网站慢」分诊出哪些可能含义? | ☐ |
| 3 | 一份合格的工程任务必须包含哪些字段? | ☐ |
✅ 过关标准: "任何模糊需求都要先分诊、收证据、拆任务、写边界,最后才动手。"
📚 下一篇
- ➡️ 12 · 一句话复盘 Codex 全貌 —— 用一条主线串起 12 篇
- 🎯 实战场景总览
- 📚 让 Codex 快速读懂大型代码库
- 🐛 用 Codex 做 Bug 分诊
🧭 一句话记住
模糊需求是劣质燃料。分诊 → 证据 → 拆任务 → 写边界,
才能把它炼成 Codex 能跑的工程任务。