02 · 一次任务是怎么完成的

⏱️ 预计阅读 12 分钟 ｜ 🎯 目标：把"发一句话→等代码"重新理解成"控制一条工程任务管线"

上一篇讲清了 Codex 是什么。这一篇要讲清它怎么干活。 看懂这条管线，你给 Codex 的提示词会立刻多两件东西：计划阶段和验收标准。

🎬 先看一个场景

你想让 Codex 做一个贪吃蛇小游戏。下面三种说法你会用哪种？

🤔 差别不在字数，而在结构。 后者多出来的是「目标 / 边界 / 执行顺序 / 交付」—— 这就是这一篇要讲的：Codex 任务管线的关键节点。

🧭 一次任务的 7 步管线

Codex 不是「输入 → 输出」黑盒，是一条有节点、有反馈、有验证的工程管线：

flowchart TB
    A["1️⃣ 接收任务<br/>从你的提示词开始"]
    B["2️⃣ 澄清目标<br/>复述 + 边界确认"]
    C["3️⃣ 收集上下文<br/>读文件、规则、配置"]
    D["4️⃣ 制定计划<br/>列改动范围 + 验证方式"]
    E["5️⃣ 执行修改<br/>真正动手改文件"]
    F["6️⃣ 运行验证<br/>测试 / 构建 / lint"]
    G{"验证通过?"}
    H["7️⃣ 交付汇报<br/>diff + 证据 + 风险"]
    I["👤 你审查"]

    A --> B --> C --> D --> E --> F --> G
    G -->|是| H
    G -->|否| C
    H --> I

    style D fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
    style F fill:#dbeafe,stroke:#3b82f6,stroke-width:2px
    style H fill:#dcfce7,stroke:#22c55e,stroke-width:2px

每一步都有它最大的风险，新手要知道在哪里防：

💡 核心洞察：Codex 失败的 80% 不在第 5 步「执行」，而在 1-4 步任务定义 和 6-7 步验证交付。 新手把所有注意力放在「它写代码行不行」，老手把注意力放在「任务定义和验收清单」。

🆚 同一句任务，三种问法的真实差距

延续上篇的方法，看 Codex 拿到不同问法会输出什么：

⚠️ 同一个 AI、同一个项目，输出的代码质量天差地别 —— 差别不在 AI 强弱，在你给的任务结构。

🎯 新手最该控制的 3 个边界

任务管线再清晰，没有边界都会失控。3 个边界把开放问题变成封闭问题：

mindmap
  root((任务边界))
    📁 文件边界
      只改 src/components/
      不碰 config/
      不碰 公共依赖文件
    🚫 行为边界
      不新增动画
      不改主题样式
      不引入新登录逻辑
    ✅ 验证边界
      pnpm test 通过
      375px 视觉不溢出
      控制台无报错

🎯 任务越小，边界越好写。 新手最好从 30 分钟内能验收的小任务开始练习写边界。

🧠 控制系统视角：Codex 任务 = 4 要素闭环

从第一性原理（first principles，最基本的原理）看，Codex 一次任务不是命令执行，是控制系统：

flowchart LR
    Goal[🎯 目标<br/>系统要达到的状态] --> Observe[👀 观测<br/>当前现场是什么样]
    Observe --> Action[🛠️ 动作<br/>采取哪些修改]
    Action --> Feedback[🔄 反馈<br/>结果是否接近目标]
    Feedback -->|未达成| Action
    Feedback -->|已达成| Done[✅ 交付]

    style Goal fill:#dcfce7,stroke:#22c55e
    style Feedback fill:#fef3c7,stroke:#f59e0b

💡 结论：Codex 不是"一次生成完美答案"的工具，而是**"在反馈里逐步逼近正确结果"** 的工具。 计划 / 验证 / 汇报这些步骤不是仪式感，是控制系统的关键部件 —— 没它们，反馈链就断了。

📖 一个例子讲透：「导出报表很慢」三阶段拆解

用户反馈："导出报表很慢"。新手会直接扔给 Codex 说"修一下"。这就是失败的开端。

正确做法：分诊 → 收证据 → 限定修复，三阶段递进。

🩺 阶段 1 · 分诊（不改代码）

请先分诊"导出报表很慢"这个问题，不要修改文件。

请输出：
- 需要确认的问题
- 可能涉及前端、后端、数据库还是文件生成
- 需要查看哪些文件
- 需要哪些日志或数据
- 建议的排查顺序

分诊后你可能发现：问题不是「导出真的慢」，而是「点击后没有 loading（加载中状态），用户以为卡住」。这种情况根本不需要改后端，只需改前端反馈。

➡️ 节省的工作量：90%。

🔍 阶段 2 · 收集证据（仍不改代码）

如果确认是性能问题：

请围绕报表导出性能收集上下文，不要修改文件。

请查找：
- 导出入口
- 后端生成逻辑
- 数据查询（query）逻辑
- 文件写入或流式返回逻辑
- 相关测试
- 最近是否有性能相关改动

🛠️ 阶段 3 · 限定修复

证据收集完，慢在数据库查询，这时才进入修复：

请优化报表导出的数据库查询。

范围：
- 只改报表导出相关 query
- 不改导出文件格式
- 不改权限逻辑
- 不改前端交互

✅ 验证：
- 补充查询逻辑测试
- 用现有 fixture（测试夹具）验证导出结果一致
- 说明性能改善的判断方式

💡 这三阶段的价值：把"模糊反馈"变成"可执行任务"，每阶段都有明确的不做什么，避免 Codex 凭一句话开始大刀阔斧改 5 个模块。

⚖️ 哪种任务适合新手起步

不是所有任务都该一上来就交给 Codex。任务大小直接决定你是否还能审查它：

🎯 第三类任务最有学习价值：让 Codex 「只定位、只解释、不改文件」。 比如：「定位设置页面移动端按钮溢出的原因，不改文件」—— 这迫使它先观察、解释、定位，是建立 Codex 工作认知最便宜的方式。

🎓 新手该养成的 3 个任务习惯

把上一篇的「复述 / 边界 / 验证」三步落地到任务管线里，就是下面 3 个习惯：

1️⃣ 让 Codex 先复述任务，再动手

请先复述你理解的任务目标和不做的事情。

➡️ 作用：在它动手前发现误解。

你心里想「修一下登录提示」，它理解成「重写整个认证（authentication）逻辑」—— 复述能在 30 秒内戳穿这种偏差。

2️⃣ 让 Codex 先给计划，等你确认再改

请先给实施计划。等我确认后再修改文件。

➡️ 作用：在它动手前圈出改动范围。

计划里如果出现「我会重构 XX 模块」「我会升级 YY 接口」这类大动词，立刻叫停 —— 这是范围爆炸的前兆。

3️⃣ 让 Codex 交付时给 4 项证据

请按下面 4 项汇报：
1. 改了哪些文件 + 为什么
2. 跑了什么验证命令、结果是什么
3. 哪些没有验证（说明原因）
4. 还剩什么风险或人工检查项

➡️ 作用：把"完成了"变成可审查的工程交付。

没有这 4 项，Codex 说"完成了"等于"我觉得完成了"。你看不到证据 = 你看不到风险。

🚫 常见误解 → ✅ 正确理解

🤝 再次类比新同事：你不会让新人第一周就重构整个项目。先给小任务、看他怎么做、怎么汇报、怎么验证 —— 建立信任后才放权。Codex 同理。

🔍 想再深一层（点击展开）

请完成下面任务，但先停在计划阶段。

🎯 背景：
{为什么要做}

🎯 目标：
{完成后达到什么效果}

📁 范围：
{允许修改的文件或目录}

禁止事项：
- 不新增依赖
- 不修改无关文件
- 不做需求外功能
- 不改公开 API
- 不改部署配置

🔄 执行要求：
1. 先阅读相关上下文
2. 复述你理解的目标和边界
3. 给出最小修改方案
4. 标出风险和需要确认的问题
5. 等我确认后再改

✅ 验证：
{真实验证命令或人工验收步骤}

📦 交付：
- 修改文件列表
- 修改说明
- 验证结果
- 剩余风险

结果思维：它写对了吗？
过程思维：它每一步都能被看见、被纠正、被验证吗？

📝 本章自检

读完这一章，看你能不能回答：

✅ 过关标准：能用一句话说清 —— "Codex 一次任务不是命令执行，是控制系统：目标 → 观测 → 动作 → 反馈 → 交付。"

📚 下一篇

• ➡️ 03 · 上下文从哪里来 —— 文件、规则、提示词、工具输出怎样影响 Codex 的判断
• 📖 写好 Codex 提示词
• 🚪 在 App 中审查改动
• 🎯 实战场景总览