大模型编程进入流水线时代-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 和 ScenarioAI 就只能根据经验补全空白而补全空白本质上就是替团队做隐性决策。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.mddesign.mdtasks.mdspecs/.openspec.yamlOpenSpec 的价值不是“多写文档”而是让需求从一句话变成可审查、可演进、可归档的规格资产。Superpowers强化 HOW让执行变得有纪律Superpowers 关心的是怎么设计怎么拆计划怎么 TDD怎么执行怎么审查怎么收尾它会把粗粒度任务拆成更适合 AI 执行的计划并要求每一步有文件、有步骤、有验证。这样 AI 不再只是“生成代码”而是按计划执行并留下证据。它的典型产物包括Design DocPlan测试reviewfinish 结果Comet组织 FLOW把两者串成流水线Comet 关心的是现在走到哪一步下一步该调用谁是否满足推进条件OpenSpec 的上下文如何交给 Superpowers验证失败能不能归档会话断了以后如何恢复它的典型产物包括/comet.comet.yamlguardhandoffarchive所以三者关系可以概括成一句话OpenSpec 管 WHATSuperpowers 管 HOWComet 管阶段、交接、守护和归档。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读取状态文件再判断下一步该做什么。它会记录的信息包括当前 phasebuild modeverify resultbranch statusarchive statusplan 路径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-grpamis/cometcdyour-project comet init comet doctor comet statuscomet 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需求 rubricWhy、Scope、Non-Goals 是否成立设计 rubric关键约束、风险、替代方案是否充分测试 rubricScenario、异常流、权限矩阵、覆盖率是否匹配归档 rubric这次变更是否真的可以成为长期规格AI 编程的下半场不只是自动化流程而是让流程具备质量判断能力。七、结语未来的程序员是智能研发流水线设计者大模型编程不是替代程序员而是重组研发流程。过去我们把 AI 当成一个更快的代码生成器现在我们需要把 AI 放进需求、设计、开发、测试、归档的完整链路里。OpenSpec 让需求可定义。 Superpowers 让执行可约束。 Comet 让流程可恢复、可守护、可归档。三者组合起来代表的是一种新范式AI 不再只是聊天窗口里的助手而是进入工程流水线的协作者。未来的程序员不只是写代码的人而是设计智能研发工作流的人。真正的竞争力也不只是“谁更会问 AI”而是谁能把 AI 纳入一套稳定、可验证、可沉淀的工程体系。