给 Codex 加上 Superpowers 和 OpenSpec 后，AI Coding 工作流该怎么理解？
为什么 AI Coding 需要“工作流”而非单纯“写代码”
很多开发者第一次接触 Codex 时，都会被它几秒钟生成多文件的速度所震撼。但真正用下来会发现：速度快≠结果稳。缺少结构化流程时，AI 容易偏离需求、改动失控、返工不断。
Superpowers 和 OpenSpec 的出现，正是为了把 Codex 的“快”限制在正确的方向上。Superpowers 更像一套行为纪律，OpenSpec 则提供结构化规格管理。两者叠加后，AI Coding 才真正从“玩具”变成可落地的工程实践。
Superpowers：给 Codex 加上行为约束
Superpowers 的核心是限制 Codex 的行动范围，避免它“过度发挥”。它通过明确的规则集，让 AI 在每次修改前先做三件事：读 diff、看页面、跑关键流程。
实际操作中，你可以把 Superpowers 的约束写进提示词，让 Codex 在改代码前先列出改动影响范围、验证方式和潜在风险。这样一来，原本可能“顺手改一堆文件”的行为被收束在最小必要范围内，返工概率大幅降低。
OpenSpec：让 Codex 按规格而非直觉写代码
OpenSpec 解决的是另一个更底层的问题——需求漂移。它要求开发者先把功能需求写成结构化规格，再让 Codex 按规格执行，而不是让 AI 凭猜测写代码。
OpenSpec 的增量规格机制特别适合已有代码库的项目。你不需要一次性写完所有需求，发现遗漏就直接追加一条，格式清晰、变更可追溯。Codex 拿到规格后，改动会更有边界，也更容易被审查和回滚。
两者结合后的完整 AI Coding 工作流
把 Superpowers 的行为纪律和 OpenSpec 的规格管理放在一起，Codex 的工作流可以拆成四个阶段：
- 规格先行：用 OpenSpec 把需求写成结构化文档，明确用户场景、边界条件和成功标准。
- 任务拆分：把大需求拆成可独立验证的小步骤，每一步都配上验证方式。
- 约束执行：通过 Superpowers 限制 Codex 的改动范围，要求它先读 diff、跑测试、再确认业务结果。
- 结果审查：改完后用
/review或自建审查流程，检查行为回归、类型风险和可维护性。
这个流程刚开始会比直接扔需求给 AI 慢，但它把 Codex 的速度用在了正确的方向上，真正减少的是后面的返工。
程序员的角色正在发生迁移
Codex 没有降低对程序员的要求，反而把专业能力往两端推移：
- 往前：更需要定义问题，把模糊需求转化为清晰规格。
- 中间：更需要拆任务，把大需求拆成可独立验证的小步骤。
- 往后：更需要验结果，看它是否通过测试、跑通流程、留下证据。
这也是为什么第一次用 Codex 时，不要急着让它写代码。先让它理解你在做什么，再让它理解你要解决什么，最后让它用可验证的结果证明这一步走对了。
结语
Superpowers 和 OpenSpec 不是让 Codex 写得更多，而是让它在正确的问题上小步写、写完验、验完再继续。把方向盘留在自己手里，Codex 才能真正成为可靠的工程搭档。