咱就是说，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——从启动到经营闭环，以亲手验证这个工作台的实现效果。

从V0 → V1 → V2 → V3，对应的是一个很清晰的变化：从“AI 帮我写代码”，到“AI 参与一个完整的工程交付过程”，每一周都在前一周的成果上继续长。

AI 写代码这件事，门槛已经越来越低。但 AI 写代码和 AI 帮你把工程交付上线之间，仍然隔着一道真正的护城河。这道护城河的名字，叫 Harness、叫 Loop、叫 Graph、叫 FDE 落地路径。

《Codex AI 工程交付行动营》想帮你跨过去的那一步，不是“再学一个工具”，而是用 4 周时间，用 Codex 跑成一套你自己能持续优化的工程系统。

如果你正在做 AI 工程化、或者打算把 AI 拉进自己的研发链路——这 4 周，值得你认真投入。

首发特惠，立减 ¥300

扫码查看详细课程安排