咱就是说，Codex 还是太强了 | 极客时间|codex|代码|工程师|极客时间|知名企业|编程|自动化

最近 AI 编程的发展速度，确实有点快。

从最开始让 AI 补几行代码、写一个函数，到现在直接让 Codex 接手一个完整任务，AI 能做的事情已经发生了很大的变化。尤其是 Codex 这类工具，真正让很多开发者开始重新思考一件事：

如果 AI 已经可以承担越来越多的编码工作，那工程师接下来到底应该把时间花在哪里？

我觉得答案可能已经越来越清楚了，不是继续研究怎么让 AI 多写几百行代码，而是开始解决另外一批问题：

一个需求来了，怎么拆成 AI 能准确执行的任务？
AI 写完以后，怎么判断它真的做对了？
如果一个任务需要多个 Agent 协作，谁负责什么，怎么避免互相覆盖？
AI 第一次没做好，怎么让它自己发现问题、继续修复？
如果这次改动影响了原来的功能，怎么及时发现并回退？
再往后，当项目越来越复杂，怎么让这一套流程持续运行，而不是每次都靠工程师手工盯着？

这些问题，才是 AI 编程真正进入工程实践之后绕不开的。代码本身正在变得越来越便宜。真正贵的东西，开始变成了：怎么定义问题、怎么判断结果、怎么控制过程，以及怎么对最终交付负责。

这也是为什么我最近越来越关注FDE这类角色。

FDE 面对的往往不是一个已经定义得非常清楚的技术需求，而是一个真实业务问题。你要先搞清楚客户到底需要什么，再把它变成可以执行的任务；过程中要不断验证结果；遇到问题要调整方案；最后还要真正把东西交付出去。

这其实和 AI 编程正在发生的变化非常像。AI 正在接管越来越多的“写代码”，工程师需要接住的，是“定义、验证、控制和交付”。

所以我看到《Codex AI 工程交付行动营》时，觉得这个方向挺有意思，因为它没有把重点放在“再教你一遍怎么用 Codex”，而是在讨论一个更实际的问题：怎么把 Codex 从一个写代码的工具，变成真正参与工程交付的协作者。

首发特惠，立减 ¥300

扫码查看详细课程安排

这件事，具体应该怎么做？

整门课的核心方法论，是 Codex + FDE 双驱动：

Codex 这条线负责“怎么用 AI 写代码、实现自动化”——把 Codex CLI / IDE / App / SDK / Hooks / Subagents / AGENTS.md 全套用熟，让工程化武器变成基本功。
FDE（前沿部署工程师）这条线负责“怎么把 AI 项目推到生产环境”——需求怎么拆、Spec 怎么写、验证怎么留、反馈怎么收。

两条线合起来，4 周时间，让一个 Demo 长成一套能上线的工程项目。

这门课的背景是一个真实项目，每一周都在同一个系统上生长，连续做 4 周，而不是做 4 个独立项目。

第一阶段 V0，从对话式写代码到 Spec 驱动交付，先把最基础的闭环跑起来。把一句比较模糊的需求，拆成边界明确、可以执行、最终又能够验收的任务。这一步做好了，后面的 AI 才有基础。

到了 V1，问题就变成了 AI 做出来的东西，到底怎么判断质量？所以这里用 Harness 建立可量化的质量门禁。不能每次都靠人肉看代码、跑一下程序，然后凭感觉说“好像可以”。要让结果能够重复验证，出了问题也能够知道问题在哪里。

再到 V2，开始进入很多团队真正头疼的地方：多个 Agent 到底怎么协作？谁负责拆任务？谁负责执行？谁负责检查？什么时候需要人工介入？如果这些事情没有被设计清楚，Agent 越多，系统反而越容易失控。所以这里会进一步涉及 Loop、Graph，以及人工审批等机制，让整个过程保持在可控范围内。

到了 V3，从代码仓库到可运行的演示产品，才真正开始往“工作台”走。把 API、Web、反馈机制等连接起来，让这套东西不再只是完成一次任务，而是能够持续运行、持续获得反馈、持续迭代。

最后，还会借助已经实现的自动化工作台，去完成一个真实可用的电商 ERP——从启动到经营闭环，以亲手验证这个工作台的实现效果。