📚AI 编程官方教程中文版
📘 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一份合格的工程任务必须包含哪些字段?

过关标准"任何模糊需求都要先分诊、收证据、拆任务、写边界,最后才动手。"


📚 下一篇


🧭 一句话记住

模糊需求是劣质燃料。
分诊 → 证据 → 拆任务 → 写边界,
才能把它炼成 Codex 能跑的工程任务。

On this page