OpenAI 不想写 Spec 了，Codex 正把软件开发带进 Skill 时代
OpenAI 不想写 Spec 了，Codex 正把软件开发带进 Skill 时代
过去两年，AI 编程圈最常见的讨论是 Prompt、Spec、Workflow。
大家总在想，怎么把需求写得更完整，怎么把步骤拆得更细，怎么让模型更稳定地按图施工。
但 OpenAI Codex 团队最近释放了一个非常清晰的信号：他们正在主动降低 Spec 的权重，把更多执行权交给 Skill 和 Agent。
在他们的实际工作流里，很多需求文档已经短到只剩下 10 条 bullet。更复杂的部分，不再靠人把过程提前写死，而是靠模型结合上下文、自主规划，再调用现成能力去完成。
这不是一句产品宣传语，而是开发范式正在变化的标志。
一、Spec 正在从“施工图”退回“方向卡”
Codex 团队在访谈里提到，他们现在只有在一个问题已经复杂到无法装进一个人的脑子时，才会认真写 spec。
即便真写，也通常只有 10 个要点左右，不会展开成长篇大论。
这背后的逻辑很直接：
- 模型能力变强了，很多中低复杂度任务已经不需要人手写完整流程。
- 单个人的可控范围变大了，因为大量编码工作可以直接委托给 agent。
- 真正有价值的，不再是把过程写清楚，而是把方向判断清楚。
换句话说，Spec 没有消失，但它正在被压缩成一种更轻量的形式。
它不再是传统软件流程里那种厚重的“前置文档”，更像是一张方向卡：告诉模型目标、边界和约束，然后让它进入工作状态。
这件事很重要，因为它意味着开发活动的重心正在迁移：
- 以前强调“把过程描述完整”
- 现在更强调“把能力组织正确”
二、真正接管执行的，不是 Prompt，而是 Skill
如果说 Spec 的地位在下降，那么 Skill 的地位就在上升。
Codex 团队明确提到，Skills 是他们产品里最有意思的一类能力。
例如：
- 接 Figma skill，直接把设计稿、变量、组件映射进实现流程
- 接部署 skill，直接把项目发布到 Vercel、Cloudflare、Render
- 接任务管理 skill，把讨论结果自动写进 Linear 并持续跟踪
这意味着什么？
意味着未来的开发，越来越不是“你怎么告诉模型一步步做”，而是“你给模型准备了哪些可调用能力”。
这和很多团队还停留在 Prompt Engineering 阶段形成了鲜明对比。
Prompt 当然仍然重要，但它越来越像自然语言入口。真正决定产出上限的，是模型背后能不能调用一套稳定、可复用、可组合的工具系统。
Spec 变轻，Skill 变重，本质上是 AI 开发从“语言驱动”走向“能力驱动”。
三、Coding Agent 的核心，不是会写代码，而是会接管任务
访谈里一个反复出现的关键词，是 delegate，也就是“委托”。
Codex 团队认为，未来的 coding 不再只是人和 IDE 一起写代码，而是人把任务交给 agent，再和 agent 协作推进。
这个判断背后，其实有三个层次的升级：
1. 从即时补全，走向完整任务交付
过去的 AI 编码更像副驾驶，帮你补全代码、解释错误、生成函数。
现在的 Codex 想做的是：
- 接受一个较长任务
- 自己读取项目上下文
- 自己生成计划
- 自己执行修改
- 自己验证结果
- 必要时继续推进下一步
这已经不是“写几行代码”，而是“接管一段工作流”。
2. 从单任务执行，走向多 Agent 并行
Codex 团队提到，他们看到很多高级用户已经在用 tmux、多终端、多 pane 同时跑多个任务。
这说明模型能力一旦越过阈值，人类自然会追求并行委托。
也正因此，Codex app 出现了，它本质上不是一个更漂亮的聊天窗口，而是一个更适合同时管理多个 agent 的界面。
3. 从“写代码工具”，走向“软件生产操作系统”
当 Skill 能接 Figma、接部署、接任务系统、接沟通系统，Coding Agent 的边界就被大幅拉宽。
它不只是生成代码，而是在覆盖整个软件生命周期：
- 需求整理
- 方案规划
- 任务拆分
- 代码修改
- 测试验证
- 部署上线
- 反馈回收
这也是为什么 Codex 团队说，他们越来越把 Codex 看成开发者平台的基石，而不只是一个 coding feature。
四、OpenAI 为什么强调“让产品变得隐形”
Alex 在访谈里讲了一句很关键的话：
他们会非常谨慎地定义核心原语，尽量让产品不要挡在模型前面，而是给模型让路。
这句话值得反复咀嚼。
很多 AI 产品失败，不是因为模型不够强，而是因为产品层把模型包得太死。
规则太多，路径太固定，入口太复杂，最后用户反而得先学习工具本身，才能开始工作。
Codex 团队的思路是反过来的：
- 底层 harness 保持强大、开放、可配置
- 上层 app 保持简单、直觉、易发现
- 让普通用户先轻松开始，再逐步发现高级能力
这就是他们为什么一边开源 harness，一边又强调产品要“像游戏一样逐步解锁能力”。
本质上，他们是在解决一个老问题：
如何既让顶级用户拥有改造系统的自由，又让普通用户不被复杂度吓退。
五、最受冲击的，也许不是工程师，而是岗位边界
这场对话里还有一个非常有意思的判断：
模型变强之后，被改写的不只是开发流程，还有团队分工。
设计师开始写更多代码，PM 开始做原型，工程师开始自己看用户反馈、排优先级、推进任务。
传统岗位的边界，正在快速模糊。
过去很多企业的逻辑是：
- PM 写需求
- 设计师画图
- 工程师实现
- 测试再兜底
现在这条链正在变短。
因为当代码生成、任务拆解、反馈汇总这些工作越来越容易被 agent 接管，人类角色的价值就会往两个方向集中：
- 做方向判断
- 做质量把关
所以 Codex 团队反复强调，问题不再是“你能不能生成代码”，而是：
- 你到底决定要做什么
- 你怎么保证最后的东西质量够高
这其实是 AI 时代最现实的一点。工具越强，人越需要对方向负责。
六、为什么这件事对所有 Builder 都有启发
很多人会把 Codex 的经验理解成“OpenAI 内部特例”。
但我更愿意把它看成一种提前到来的行业样本。
因为无论你是不是在用 Codex，只要你在做 Agent、做自动化、做 AI 原生工作流，都会碰到同样的问题：
- 需求文档要不要写得很细？
- Prompt 到底该多复杂？
- 工具怎么接？
- 任务如何委托？
- 如何在简单体验和高级能力之间平衡？
而 Codex 给出的答案已经越来越明确：
1. 不要迷信长 Spec
长文档不等于高质量协作。
如果模型、工具链和上下文都足够强，真正有效的文档应该更短、更聚焦，重点描述目标、约束和验收标准。
2. Skill 会成为新的竞争壁垒
未来大家拼的不只是模型，更是谁能把设计、部署、项目管理、数据系统、业务系统接成一整套可复用技能。
3. 会“组织能力”的人，会比会“描述过程”的人更值钱
过去最强的人，是能把流程说得最清楚的人。
以后更强的人，是能把模型、工具、上下文和任务目标编排得最顺的人。
七、我的判断：2026 年，Agent 开发正式进入 Skill 时代
如果把 AI 编程的演进粗略分一下阶段，我会这么看：
- 第一阶段：Prompt Engineering 解决“怎么说模型才听得懂”
- 第二阶段：Context Engineering 解决“怎么把对的上下文喂给模型”
- 第三阶段：Skill / Harness Engineering 解决“怎么让模型真正把事做完”
Codex 团队现在的动作，实际上已经站在第三阶段。
他们不再把 spec 当成核心护城河，也不再把 prompt 当成主战场，而是把重点转向：
- harness 要足够强
- skill 要足够多
- 任务委托要足够自然
- 产品体验要足够轻
这套逻辑一旦跑通，软件开发的角色关系、工作流结构、工具入口，都会跟着改写。
对今天的团队来说，最值得警惕的一件事是：
如果你还在用传统软件流程的思路，去管理一个已经具备 agent 能力的系统，那大概率会越来越笨重。
真正该升级的，不只是模型，而是整个生产方式。
结语
OpenAI Codex 团队释放的信息，其实可以浓缩成一句话：
未来的软件开发，不再是先把流程写清楚，再让人执行；而是先把能力组织好，再把任务交给模型。
Spec 还会存在，但它会更短。
Prompt 还会存在，但它会退居入口。
真正站到舞台中央的，是 Skill、Harness，以及人与 Agent 之间越来越自然的任务委托关系。
谁更早理解这一点，谁就更可能在下一轮开发范式切换里占据主动。
原文来源：InfoQ
原文标题：OpenAI 不想写 spec 了：Codex 只留 10 条要点，把执行交给 skills
原文链接：https://www.infoq.cn/article/C2fWkH2EgBlDPNUNlcZX