大模型编程进入流水线时代-OpenSpec-Superpowers-Comet

大模型编程进入流水线时代：OpenSpec × Superpowers × Comet 如何重塑 AI 编程工作流

过去一年，很多开发者已经完成了一个心理转变：AI 不只是能写 demo，它真的可以参与真实项目开发。

你让它写一个接口，它很快；让它修一个 bug，它也能动；让它重构一个模块，它甚至能给出一套看起来很完整的方案。可越往真实项目里走，问题反而越明显：AI 写出来的代码，到底有没有理解需求？有没有遵守设计？有没有覆盖关键风险？这次对话里的判断，下一次还能不能被项目和团队继承？

所以，大模型编程的核心矛盾，已经不再是“AI 会不会写代码”，而是：

我们能不能把一个模糊念头，稳定地转化为可验证、可追溯、可沉淀的软件交付？

这正是 OpenSpec、Superpowers 和 Comet 组合起来最有价值的地方。

简单说：

• OpenSpec 管 WHAT：定义做什么、为什么做、边界在哪里。
• Superpowers 管 HOW：强化设计、计划、TDD、执行和审查纪律。
• Comet 管 FLOW：把二者串成一条可恢复、可守护、可归档的 AI 编程流水线。

一、AI 编程真正失控的，不是代码，而是工作流

很多团队第一次用 AI 编程时，最直观的感受是“快”。一个需求丢进去，AI 很快就能给出实现；一个报错丢进去，AI 很快就能定位原因；一个页面、一个接口、一个脚本，它都能快速产出。

但真实研发里，快只是表层收益。真正危险的地方，往往不是 AI 写不出代码，而是它写得太快，快到需求、设计、验证和知识沉淀都没来得及跟上。

1. 需求对齐失控：人说的是念头，AI 交付的是猜测

人类说“给系统加 API Key 管理”，脑子里想的可能是企业开放平台能力：管理员创建 Key、绑定 scope、轮换、禁用、审计。

但 AI 可能直接写成一个简单 token 表，甚至把明文 Key 存进数据库。代码能跑，接口也能通，可需求已经偏了。

这里的问题不是 AI 不够聪明，而是“为什么做、做什么、不做什么、做到什么程度”没有被结构化定义。没有清晰的 Why、Scope、Non-Goals 和 Scenario，AI 就只能根据经验补全空白，而补全空白，本质上就是替团队做隐性决策。

2. 代码产出黑盒：看到了 diff，却看不到推理链路

AI 可以生成大量代码，也可以补测试。但团队很难判断：它为什么这样设计？有没有遵守关键约束？有没有破坏领域规则？测试覆盖的是 happy path，还是覆盖了真正的风险？

一个接口测试通过，不代表权限边界正确；一个单测通过，不代表并发场景安全；一个功能能跑，也不代表它符合长期架构。

真正让人不安的是，我们看到的是代码结果，却看不到“需求 -> 设计 -> 计划 -> 实现 -> 验证”的完整链路。

3. 知识沉淀缺失：AI 做完了任务，但项目没有变聪明

普通 Chat 编程里，很多关键知识只存在于对话中：为什么采用这个方案，为什么不做另一个方案，哪些边界不能碰，哪些测试证明它已经满足规格。

会话一断，知识就散了。换一个 AI，重新猜；换一个开发者，重新问；过几周再改同一块代码，项目本身并没有变得更聪明。

真正需要沉淀的不是聊天记录，而是工程资产：

• 需求事实：Why、Scope、Non-Goals、Scenario
• 设计决策：方案取舍、MUST / MUST NOT、约束来源
• 执行证据：Plan、测试结果、验证报告、review 结论
• 长期规格：归档后的主规格，成为后续 AI 的项目事实

一句话总结：好问题定义不是让 AI 更容易回答，而是让 AI 更难跑偏。

二、真实研发现场：为什么普通 Chat 编程越用越不稳

想象一个很常见的企业 SaaS 场景：团队要给开放平台增加 API Key 管理能力。这个需求听起来并不复杂，似乎就是“创建一个 Key，然后用它调用接口”。

如果直接把这句话丢给 AI，它大概率会马上开始写表、写接口、写页面。但真实业务问题远不止这些。

API Key 是否只能展示一次？数据库能不能保存明文？Key 是否需要绑定 scope？禁用后是否立即失效？轮换时旧 Key 怎么处理？谁有权限创建 Key？所有操作是否必须进入审计日志？这件事是否会影响现有登录体系？是否要引入 OAuth？是否要支持第三方应用市场？

这些问题如果没有被提前定义，AI 就会替你做选择。更麻烦的是，它做出的选择不一定会显式告诉你，而是悄悄藏在代码里：明文存储、简单校验、没有审计、没有轮换策略。等到 review 时，你看到的是一堆 diff，而不是一条可追踪的工程链路。

这就是大模型编程在真实项目里的典型困境：

代码不是没写出来，而是写出来之后，团队不知道它是否真的代表正确的业务事实。

三、三者关系：OpenSpec 是规格层，Superpowers 是执行层，Comet 是工作流层

理解 OpenSpec、Superpowers 和 Comet，最重要的是不要把它们看成三个并列工具。它们更像三层能力，各自解决不同层面的问题。

OpenSpec：定义 WHAT，让需求成为工程资产

OpenSpec 关心的是：做什么？为什么做？边界在哪里？哪些场景必须成立？哪些事情明确不做？这次 change 最终如何归档为系统长期规格？

它的典型产物包括：

• proposal.md
• design.md
• tasks.md
• specs/
• .openspec.yaml

OpenSpec 的价值不是“多写文档”，而是让需求从一句话变成可审查、可演进、可归档的规格资产。

Superpowers：强化 HOW，让执行变得有纪律

Superpowers 关心的是：怎么设计？怎么拆计划？怎么 TDD？怎么执行？怎么审查？怎么收尾？

它会把粗粒度任务拆成更适合 AI 执行的计划，并要求每一步有文件、有步骤、有验证。这样 AI 不再只是“生成代码”，而是按计划执行，并留下证据。

它的典型产物包括：

• Design Doc
• Plan
• 测试
• review
• finish 结果

Comet：组织 FLOW，把两者串成流水线

Comet 关心的是：现在走到哪一步？下一步该调用谁？是否满足推进条件？OpenSpec 的上下文如何交给 Superpowers？验证失败能不能归档？会话断了以后如何恢复？

它的典型产物包括：

• /comet
• .comet.yaml
• guard
• handoff
• archive

所以，三者关系可以概括成一句话：

OpenSpec 管 WHAT，Superpowers 管 HOW，Comet 管阶段、交接、守护和归档。

Comet 不是替代 OpenSpec 和 Superpowers，而是把 OpenSpec 的规格生命周期和 Superpowers 的执行纪律，串成一条五阶段自动化流水线：

Open ->Design ->Build ->Verify ->Archive

实际使用时，开发者主要面对的是 Comet。你从/comet <需求描述>开始，Comet 会根据当前状态推进流程，在合适阶段调用 OpenSpec 或 Superpowers 的能力。

这才是它的关键价值：不是再发明一套 AI 编程方法，而是把原本依赖人肉提醒的流程，变成有状态、有守护、有归档的工程机制。

四、原理解析：它们如何解决三个失控问题

前面说了三个问题：需求对齐失控、代码产出黑盒、知识沉淀缺失。对应地，OpenSpec、Superpowers 和 Comet 分别从规格、执行、状态与归档三个层面给出了解法。

1. OpenSpec 解决需求对齐：把一句话变成可验证规格

OpenSpec 的作用，不是让团队多写文档，而是把需求变成可审查的工程资产。

一个健康的 change，不应该只有“实现 API Key 管理”这类一句话，而应该包含 Why、Scope、Non-Goals、Scenario、MUST、MUST NOT。

以 API Key 管理为例，Non-Goals 可以明确写：

• 不改现有用户登录体系
• 不引入 OAuth 流程
• 不做第三方应用市场
• 不允许 API Key 明文二次查看

Scenario 可以写：

• 当管理员创建 API Key 时，系统只展示一次明文
• 当 API Key 被禁用后，后续请求必须失败
• 当 scope 不包含目标权限时，接口调用必须被拒绝
• 当 Key 被轮换后，旧 Key 必须失效
• 所有创建、禁用、轮换操作必须记录审计日志

这样 AI 不再围绕一句自然语言自由发挥，而是围绕可验证规格工作。需求不再是“你理解一下”，而是变成了项目里可以被读取、被审查、被验证的事实。

2. Superpowers 解决代码黑盒：把生成代码变成按计划执行

OpenSpec 的tasks.md往往还是需求视角，比如：

• 新增 API Key 数据模型
• 实现 Key 创建接口
• 实现 scope 校验
• 补充审计日志
• 补充测试

这个粒度对需求评审够用，但对 AI 执行还不够。Superpowers 的价值，是把这些任务继续拆成可执行计划，让 AI 从“直接写代码”进入“按步骤实现并验证”的状态。

例如：

• Task 1：验证 API Key 明文只展示一次
• Task 2：实现哈希存储，禁止数据库保存明文
• Task 3：实现 scope 鉴权
• Task 4：实现禁用和轮换
• Task 5：补齐审计日志
• Task 6：运行安全相关测试与回归测试

每一个任务都应该有明确文件、执行步骤、验证命令和结果记录。这样团队看到的不只是代码 diff，还有计划、步骤和验证证据。

3. Comet 解决流程漂移：把“记得做”变成“必须过闸”

Comet 和普通提示词最大的区别，在于它不只靠 AI 记流程，而是把流程状态写下来。

普通提示词只能告诉 AI：“请记住现在是 build 阶段。” Comet 会把这个事实写进.comet.yaml。下一次会话恢复时，/comet不是靠聊天记录猜，而是重新检测 active change，读取状态文件，再判断下一步该做什么。

它会记录的信息包括：

• 当前 phase
• build mode
• verify result
• branch status
• archive status
• plan 路径
• handoff 上下文
• verification report

这意味着，如果今天做到 build 阶段，plan 已经生成，但还没选择 branch 还是 worktree，明天继续时，Comet 不会让 AI 直接开始乱改代码，而是根据状态恢复到正确位置。

4. 三者共同解决知识沉淀：让项目本身变聪明

知识沉淀不是把聊天记录保存下来，而是把需求、设计、计划、验证和归档结果变成代码库里的可读资产。

OpenSpec 沉淀的是系统规格。每个 change 产生 proposal、design、tasks 和 delta spec。归档后，delta spec 会合并回主规格，成为后续 AI 和开发者理解系统的长期上下文。

Superpowers 沉淀的是执行证据。它留下设计文档、执行计划、测试结果、review 结论。后续团队不仅知道“改了什么”，还知道“为什么这么改、按什么计划改、如何证明改对了”。

Comet 沉淀的是流程状态和交接关系。它通过.comet.yaml记录阶段与验证结果，通过 handoff 文件完成 OpenSpec 到 Superpowers 的上下文交接，通过 guard 和 archive 机制确保没有验证证据就不能轻易归档。

这一层很关键。因为真正的工程知识，不应该只停留在一次对话里，而应该进入项目本身，成为后续开发和后续 AI 可以继承的长期记忆。

Comet 的本质，是把“记得做”变成“没满足条件就不能往下走”。

五、落地工作流：用 Comet 跑通一个真实 change

第一次接入 Comet，不建议一上来就丢一个庞大系统进去。更稳妥的方式，是挑一个中等复杂度、边界清楚、但确实需要长期沉淀规格的需求。

比如：企业 SaaS 的 API Key 管理。

1. 安装与初始化

可以从 Comet 开始安装：

npminstall-g@rpamis/cometcdyour-project comet init comet doctor comet status

comet init会引导选择 AI 平台、安装范围、语言，并处理 OpenSpec、Superpowers、Comet 相关 skill 的装配。

如果只是通过通用 skills CLI 安装，也可以使用：

npx skillsaddrpamis/comet

但对普通团队来说，第一次更建议从comet init开始。因为你真正要确认的不是 npm 包装上了，而是当前项目里 Comet、OpenSpec、Superpowers 三组 skill 是否都能被你的 Agent 宿主读取。

2. 从/comet输入真实需求

在 Agent 中输入：

/comet 为开放平台增加 API Key 管理能力。 企业管理员可以创建、禁用、轮换 API Key； Key 只能展示一次，数据库只能保存哈希； 每个 Key 需要绑定 scope； 所有创建、禁用、轮换操作必须记录审计日志； 不改现有用户登录体系，不引入新的 OAuth 流程。

这个输入不是越长越好，而是要把关键边界先说清楚。尤其是“不做什么”，往往比“做什么”更能防止 AI 跑偏。

3. Open 阶段：先把需求变成规格

Comet 会进入 OpenSpec 规格阶段。这里不要急着让 AI 写代码，重点看 proposal 是否说清楚 Why、Scope、Non-Goals。

尤其要检查 Non-Goals：

• 不改登录体系
• 不引入 OAuth
• 不做第三方应用市场
• 不允许 API Key 明文二次查询

Non-Goals 是防止 AI 顺手扩大范围的护栏。如果这一层没有写清楚，后面 AI 很可能把一个 API Key 管理需求，扩展成一套新的认证体系。

4. Design 阶段：把安全约束写成硬规则

设计阶段要把关键约束写成 MUST / MUST NOT，而不是模糊建议。

比如：

• API Key 明文 MUST 只展示一次
• 数据库 MUST 只保存哈希
• Key prefix MAY 用于检索
• scope MUST 参与鉴权
• 禁用后的 Key MUST 立即失效
• 所有创建、禁用、轮换操作 MUST 写入审计日志

设计阶段没定清楚，后面的 TDD 只会把错误方案实现得更认真。尤其是安全、权限、审计、账务这类需求，不能让 AI 自己拍脑袋决定方案。

5. Build 阶段：把任务变成可执行计划

Comet 会把 OpenSpec 的任务交给 Superpowers 的执行纪律。此时 AI 不应该直接“开始实现 API Key 管理”，而应该按计划推进。

一个更健康的执行计划可能是：

• 先写 Key 创建测试
• 再写哈希存储测试
• 再写 scope 越权测试
• 再写禁用失效测试
• 再写轮换测试
• 最后写审计日志测试

每一步都应该有文件、步骤、命令和验证结果。这样一来，开发者 review 的不是一团代码，而是一条可追踪的执行链路。

6. Verify 阶段：不要只看“测试通过”

验证阶段不能只问“测试过了吗”，而要问“规格满足了吗”。

API Key 管理至少要检查：

• 明文是否无法二次查询
• 数据库是否没有保存明文
• 禁用后的 Key 是否立即失效
• scope 越权是否失败
• 轮换后旧 Key 是否失效
• 审计日志是否完整
• Scenario 是否都有测试映射
• MUST / MUST NOT 是否被违反
• OpenSpec verify 是否通过
• Comet verify report 是否存在

这一步的意义，是把“能跑”提升为“符合规格”。

7. Archive 阶段：把正确事实沉淀进系统

Archive 不只是收尾。它代表这次 change 的 delta spec 要进入系统长期规格。

一旦错误规格被归档，后续 AI 会把它当成项目事实。所以 archive 前应该保留人工确认：

• 这个 change 是否真的代表系统新事实？
• 验证证据是否足够？
• 安全约束是否写进主规格？
• 后续 AI 是否能据此理解 API Key 管理的边界？

这一步，正是知识沉淀真正发生的地方。不是“代码合了就完了”，而是让这次开发成为项目长期记忆的一部分。

六、边界与不足：流程闭环不等于内容质量足够好

Comet + OpenSpec + Superpowers 很有价值，但它不是银弹。它能显著改善流程问题：需求有规格，执行有计划，验证有证据，归档有状态。

但流程走完，不代表内容天然足够好。

1. 需求质量仍然需要判断

Why 是否真实？有没有识别伪需求？有没有把业务目标和实现手段混在一起？这些问题，工具可以提醒，但不能完全替团队判断。

如果一开始的问题定义就是错的，后面的流程越严谨，越可能把错误需求实现得更完整。

2. 设计质量不能只看形式

设计文档写了，不代表设计就好。DDD 里的聚合、实体、值对象这些形式可以被 AI 写出来，但模型划分是否真的合理，仍然需要领域判断。

尤其是权限、认证、账务、审计、风控这类场景，设计质量要看它是否保护了领域不变量，是否处理了并发、事务、失败重试和回滚。

3. 测试质量不能只看数量

代码覆盖率不等于功能覆盖度。接口测试通过，不代表权限矩阵完整。happy path 通过，不代表异常路径安全。

更好的测试检查，应该关注：

• Scenario 是否都有测试映射
• 异常流是否覆盖
• 权限矩阵是否覆盖
• 并发路径是否覆盖
• 关键约束是否有反例测试
• 回归测试是否能证明旧能力没有被破坏

4. 归档质量决定长期上下文质量

错误代码只是 bug，错误规格会影响未来很多次 AI 判断。

归档前必须确认：这次变更是否真的可以成为系统事实？如果只是为了让当前实现过关而修改规格，那就是把实现偏差包装成长期规则。

所以，下一阶段真正值得做的，不是再堆一层工具，而是给每个环节建立内容质量 rubric：

• 需求 rubric：Why、Scope、Non-Goals 是否成立
• 设计 rubric：关键约束、风险、替代方案是否充分
• 测试 rubric：Scenario、异常流、权限矩阵、覆盖率是否匹配
• 归档 rubric：这次变更是否真的可以成为长期规格

AI 编程的下半场，不只是自动化流程，而是让流程具备质量判断能力。

七、结语：未来的程序员，是智能研发流水线设计者

大模型编程不是替代程序员，而是重组研发流程。

过去，我们把 AI 当成一个更快的代码生成器；现在，我们需要把 AI 放进需求、设计、开发、测试、归档的完整链路里。

OpenSpec 让需求可定义。 Superpowers 让执行可约束。 Comet 让流程可恢复、可守护、可归档。

三者组合起来，代表的是一种新范式：AI 不再只是聊天窗口里的助手，而是进入工程流水线的协作者。

未来的程序员，不只是写代码的人，而是设计智能研发工作流的人。真正的竞争力，也不只是“谁更会问 AI”，而是谁能把 AI 纳入一套稳定、可验证、可沉淀的工程体系。