Spec已死，Skills万岁——OpenAI Codex团队正在抛弃你熟悉的开发流程

最近 OpenAI Codex 团队的一次访谈里，有个观点让很多工程师不舒服：只有问题复杂到很难装进一个人脑子里时，才写 spec，而且即便写，也就 10 条 bullet。

这跟过去十年我们被教导的软件工程哲学完全相反。

1. 传统开发流程的三个隐含假设

过去我们写 spec，是因为我们默认：

• 人类会犯错误：spec 是跨越时间传递意图的唯一可靠载体
• 代码是事实：最终代码和原始设计必然产生偏差，spec 是校准工具
• 模块需要预先定义：接口、边界、数据流在上线之前就需要锁定

这套逻辑在人类开发者主导的时代没问题。但当 AI 开始写 90% 的代码时，这些假设开始失效了。

2. 为什么 spec 成了浪费？

OpenAI Frontier 团队 5 个月写了 100 万行代码，1500 个 PR，零人类编写。负责人 Ryan Lopopolo 的解释是：

当 AI 能够实时补全和纠正代码时，提前写清楚"要做什么"的 ROI 趋近于零。

这不是说规划不重要，而是规划的形式变了：

传统方式	新方式
写 50 行的 SPEC.md	写 10 条决策原则
定义模块接口	定义 Skill 的边界和入口
人工 review 代码	AI 验证 + 人类抽查

Skills 是这一转变的核心抽象。

3. Skills 是什么，为什么比模块更好用

Codex 团队提出的 Skill，不是某个代码文件或函数，而是一个可复用的能力组。它包含：

• 触发条件：什么情况下调用这个 Skill
• 执行边界：Skill 内部自主决策，不外溢
• 接口契约：输入输出用自然语言描述，而非接口签名

传统的模块强调"是什么"（数据结构+函数），Skill 强调"能做什么"（能力+场景）。

举个例子：

# 传统模块
class UserAuth:
    def login(username, password) -> Token:
        ...

# Skill
"当用户说'帮我登录'时：
  1. 识别意图 → 触发 login Skill
  2. 提取凭证 → Skill 内部处理
  3. 返回 Token → 自然语言输出"

你发现区别了吗？Skill 对 AI 友好，但人类读起来反而更自然。

4. 开发范式转变：从"写菜谱"到"组装预制菜"

旧范式下，工程师是"写菜谱的厨师"——需要详细列出每一个步骤。

新范式下，工程师是"组装预制菜的餐厅老板"——从 Skills 菜单里选择需要的能力，定义它们的组合逻辑。

这种转变对团队结构的影响是深远的：

以前：Senior Engineer 设计架构 → Junior 按图施工 → Tech Lead 审核 现在：Team Lead 定义 Skill 边界 → AI 自主实现内部逻辑 → 人类只做边界验证

这不是说架构设计不重要，而是架构设计的颗粒度从"代码级别"变成了"能力级别"。

5. 真实案例：幽灵库的七层架构

OpenAI Frontier 团队内部有一个被称为"幽灵库"（Ghost Libraries）的系统，它的核心架构是七层，每层都是 Skill：

1. 意图层：解析用户需求为结构化意图
2. 路由层：将意图分发到对应 Skill
3. Skill 层：每个 Skill 独立维护，自己管理内部状态
4. 验证层：Skill 输出通过自动化测试验证
5. 集成层：多个 Skill 协作时的冲突检测
6. 记忆层：Skill 之间的上下文共享
7. 部署层：Skill 的灰度发布和回滚

这个架构最反直觉的地方：没有任何一层是给人读的。每一层首先是给 AI 看的，人只能看摘要视图。

6. 对普通工程师的影响

你可能会问：这个转变对我意味着什么？

三个直接冲击：

1. 写 spec 变成了一种浪费时间的技能——至少在 AI 原生团队里
2. Skill 设计能力成为新的核心竞争力——你能把复杂问题分解成 AI 可执行的 Skill 吗？
3. 代码阅读能力比代码写作能力更重要——因为你要 review AI 生成的 Skill 实现

那些还在用传统方式管理 AI 开发团队的 Tech Lead，会发现团队效率差距在快速拉开。

7. 反对意见：这不是回到了"先把问题想清楚"吗？

有人会说：Codex 团队说的 10 条 bullet，难道不就是一个极度精简的 spec 吗？

从形式上看，确实。但关键区别在于谁在消耗这 10 条 bullet。

传统 spec 是给人看的，人需要完整阅读并理解上下文才能执行。10 条 bullet 的 spec 对 AI 来说是完整输入，对人来说只是一个高层次的指南——AI 会自动补充中间步骤，而人类会陷入细节。

这不是"把 spec 写短点"，而是换了一个消费 spec 的主体。

总结

OpenAI Codex 团队正在用实际行动告诉我们：当 AI 能够处理复杂性时，"提前把一切想清楚写下来"的工程价值正在快速贬值。

取而代之的是：把问题分解成可组合的 Skills，并定义它们之间的协作边界。

这不是软件的死亡，这是软件工程从"人类编写真相"到"人类定义能力、AI 填充实现"的关键一跃。

技能保质期缩短了三个月，但 Skills 的保质期，可能比你想象的久得多。