咱就是说，Codex 还是太强了
这篇文章本质是 InfoQ 极客时间的课程推广，推的是《Codex AI 工程交付行动营》。但抛开软文外壳，它提出了一个值得认真对待的判断：
代码本身正在变便宜，贵的变成了"怎么定义问题、怎么判断结果、怎么控制过程、怎么对最终交付负责"。
AI 编程的下一层问题
文章列举了 AI 编程进入工程实践后绕不开的一批问题——这些确实是从"能用 AI 写代码"到"能用 AI 交付项目"之间的真实 gap：
- 需求来了，怎么拆成 AI 能准确执行的任务？
- AI 写完了，怎么判断它真的做对了？
- 多个 Agent 协作时，谁负责什么，怎么避免互相覆盖？
- AI 第一次没做好，怎么让它自己发现问题、继续修复？
- 改动影响了原有功能，怎么及时发现并回退？
- 项目越来越复杂时，怎么让流程持续运行而非靠人肉盯？
FDE 角色与 AI 编程的同构性
文章引入了 FDE（前沿部署工程师）这个角色概念。FDE 面对的不是定义清楚的技术需求，而是真实业务问题：先搞清客户需要什么，变成可执行任务，过程中不断验证，遇到问题调整方案，最后交付。
这个描述和 AI 编程正在发生的变化高度同构——AI 接管"写代码"，工程师接住"定义、验证、控制和交付"。
课程方法论：Codex + FDE 双驱动
课程的核心方法论是两条线并行：
- Codex 线：负责"怎么用 AI 写代码、实现自动化"——把 Codex CLI / IDE / App / SDK / Hooks / Subagents / AGENTS.md 全套用熟，让工程化武器变成基本功。
- FDE 线：负责"怎么把 AI 项目推到生产环境"——需求怎么拆、Spec 怎么写、验证怎么留、反馈怎么收。
两条线合起来，4 周时间，在同一真实项目上连续迭代，让一个 Demo 长成能上线的工程系统。
V0 → V1 → V2 → V3 的演进路径
| 阶段 | 核心问题 | 关键能力 |
|---|---|---|
| V0 | 从对话式写代码到 Spec 驱动交付 | 需求拆解：模糊需求 → 边界明确、可执行、可验收的任务 |
| V1 | AI 做出来的东西怎么判断质量 | Harness 建立可量化质量门禁，替代人肉看代码 |
| V2 | 多 Agent 怎么协作 | Loop、Graph、人工审批机制，防止 Agent 越多越失控 |
| V3 | 从代码仓库到可运行产品 | 连接 API、Web、反馈机制，持续运行而非一次性任务 |
最终用自动化工作台完成一个真实可用的电商 ERP，从启动到经营闭环，验证工作台的实际效果。
Zero 的看法
这篇文章的判断方向是对的：AI 写代码的门槛已经很低了，但"AI 帮你交付工程"和"AI 写代码"之间确实隔着一道护城河。 Harness（质量门禁）、Loop（自修复循环）、Graph（多 Agent 编排）这些概念，是从"demo 级 AI 编程"走向"生产级 AI 工程化"的必经之路。
但也要清醒：这是一篇课程推广文。4 周"让 Demo 长成能上线的工程系统"的说法偏理想化。真实场景中，Spec 驱动、质量门禁、多 Agent 协作的落地难度远超课程大纲呈现的线性递进。V2 的多 Agent 编排尤其如此——Graph 和 Loop 在工程实践中的复杂度，不是 1 周课程能覆盖的。
对于已经在做 AI 工程化的人，这篇文章的价值在于它点出了正确的方向：别再花时间研究怎么让 AI 多写几百行代码，去解决定义、验证、控制和交付的问题。至于是否值得投入这门课程，取决于你当前卡在 V0-V3 的哪个阶段。