AI 会写代码，然后呢？

AI 很会写代码了，我们为什么还要讨论开发流程？

先看一个很小的需求。产品说，给登录页加一个“记住我”。我们把这句话交给 AI，它很快会加上复选框，写入本地存储，可能顺手补一个测试。页面能点，刷新以后也还在，看起来做完了。

但接着问几句，事情就没那么简单了。记住的是账号，还是登录状态？有效期多长？公共电脑上怎么办？服务端的刷新令牌要不要调整？退出登录之后，客户端留下什么？原来的安全策略里有没有禁止项？

这些问题都不是代码语法问题。它们分散在需求、安全设计、接口约定、测试和验收里。AI 可以在几分钟内生成一个正确的复选框，却也可能在几分钟内把一个没想清楚的需求扩散到整个认证链路。

所以今天不急着比较工具。我想先把软件开发里那些听着有点老派的概念重新过一遍。等这些概念对上了，再看 Spec-Kit、OpenSpec、Superpowers，以及后面的 Comet，很多差异会变得很直白。

我们说的“标准开发流程”是什么

先说明一下，这里没有一张全行业统一的流程图。瀑布、敏捷、持续交付，各自的节奏不同，团队使用的阶段名称也不一样。

但无论怎么迭代，有几类问题绕不过去。

一开始要弄清楚为什么做、给谁做、做到什么程度。接着决定系统怎么改，把工作拆开，编码、测试、评审。交付以后，还要让文档、代码和实际行为保持一致。

流程可以循环，也可以并行。这里说的“标准”，只是在提醒我们：这些问题不会凭空消失。

需求、规格、设计，不是一份文档的三个标题

Requirement 通常翻译成需求。它描述用户或业务想解决什么问题。比如“用户希望在自己的设备上减少重复登录”。这句话表达了意图，但还不够拿来验收。

Spec，也就是规格，会把边界写清楚。哪些设备可以记住？默认是否勾选？保存多长时间？退出登录之后怎样处理？什么结果算成功，什么结果必须拒绝？规格的作用，是让产品、开发、测试和 AI 对“我们到底要做什么”有同一个答案。

Design 是技术设计。它回答怎么实现：令牌存在哪里，客户端和服务端怎样配合，旧会话如何兼容，出了问题怎么回滚。它要记录真正影响实现的选择。

Plan 和 Task 又是下一层。计划安排改动顺序、依赖和验证方式；任务要具体到可以执行。任务列表很长不代表计划好，每一项能追溯到规格或设计才有用。

这些产物是团队的外部记忆。换一个开发者或 AI 会话，也不必只靠聊天记录猜当时为什么这么做。

实现完成和工作完成是两回事

进入编码阶段以后，常见的工程动作包括分支隔离、代码实现、自动化测试和 Code Review。规模大一些的改动还会有集成测试、安全检查、性能验证和用户验收。

这里需要区分 testing 和 verification。测试在问代码行为是否符合预期。验证的范围更大，它还会检查规格覆盖、文档同步、构建结果和评审问题。

验证通过以后才进入发布。发布要考虑部署、数据迁移、监控和回滚，线上反馈又会进入下一轮需求。

最后还有归档。它要把新规则合并回长期规格，保留决策和验证证据，再把临时工作区收好。否则代码已经变了，规范还停在过去。

这是一个相对完整的开发闭环。错别字和认证协议，显然不该走同一套流程。流程应该和风险匹配。

AI 进入流程以后，多了哪些概念

第一个概念是 Spec-Driven Development，简称 SDD，也就是规格驱动开发。它把规格放到开发链路前面，让计划、任务和实现都从规格派生。

有些项目会说“规格可执行”。它并不是把 Markdown 当代码编译。规格成为 AI 的主要输入，代理据此生成计划、拆任务、实现并检查一致性。中间仍然有模型判断，也需要人审核。

第二个概念是 TDD，测试驱动开发。节奏是 Red、Green、Refactor：先写失败测试，再写最少的实现让它通过，然后整理代码。AI 很容易先生成实现，再补一组刚好能证明自己正确的测试；先看到失败，才能确认测试真的约束了行为。

还有 Greenfield 和 Brownfield。前者是从零开始，后者是在已有代码库上改造。旧项目有历史接口、隐含约定和不能随便动的依赖。AI 在新项目里容易跑得很快，在旧项目里容易跑错方向。

再说 Skill 和 Hook。Skill 是给代理使用的一套工作方法，写明何时触发、按什么步骤做、怎样才算完成。Hook 是执行点上的拦截器，可以检查或阻止动作。两者的约束力度不同。

任务变长以后，还会遇到状态机和 HITL。状态机记录当前阶段并限制下一步。HITL 是 Human in the Loop，也就是在需要判断或授权时让人参与。人不必盯住每一行代码，但需求边界、技术取舍和失败处理，最好别让代理偷偷决定。

Spec-Kit：把规格放到开发链路中心

Spec-Kit 是 GitHub 开源的 Spec-Driven Development 工具包。它的常见流程从 constitution 开始。constitution 可以理解成项目宪章，里面放长期有效的工程原则，比如测试标准、安全要求、技术边界和用户体验约束。

接下来是 specify，把需求写成规格；clarify，找出模糊和冲突；plan，形成技术方案；tasks，把方案拆成可执行项。实现前还可以用 analyze 检查规格、计划和任务是否对得上，最后由 implement 执行。

代价也很明显。流程和 Markdown 产物都不少，小改动全套照跑会显得重。现在的 Spec-Kit 也支持 Brownfield 演进，所以它并非只能从零开发；它更适合规格需要成为主要事实来源的项目。

回到“记住我”这个需求。用 Spec-Kit，我们会先在规格里写清用户场景和验收条件，再决定令牌方案，生成任务，检查任务有没有遗漏安全约束。它关注的是整条链路有没有从明确的意图出发。

OpenSpec：把每次改动单独管起来

OpenSpec 也做规格驱动开发，但姿态更轻。它把一次功能开发看作一个 change。change 目录里通常有 proposal、specs、design 和 tasks。proposal 说明为什么改，specs 记录新增或修改的要求，design 记录技术选择，tasks 用来推进实现。

实际使用时，可以用 /opsx:propose 创建 change，用 /opsx:apply 执行，完成后用 /opsx:archive 归档。归档时，增量规格会合并到长期规格里。它更像在代码库旁边放了一套变更账本。

这套结构很适合 Brownfield。旧系统很少有机会一次性补齐全部规格，但我们可以从今天的改动开始记。每做一个功能，就补上相关的 delta spec。时间长了，长期规格会逐渐接近系统真实行为。

OpenSpec 允许随时调整产物，没有很硬的阶段顺序。它适合快速迭代，但文档存在不等于执行纪律自然存在。代理是否先设计、坚持测试，仍要靠工作方法和团队约束。

“记住我”放进 OpenSpec，会成为一个独立 change。我们能清楚看到它改了哪些认证规则，相关任务做到哪里，归档后又怎样改变长期规格。它最在意的是这次变更有没有留下完整、可合并的记录。

Superpowers：直接约束代理怎么工作

Superpowers 把注意力放在另一处。它用一组可以组合的开发 Skills 约束代理执行，长期规格库并不是中心。

准备做功能时，brainstorming 要求代理先理解需求、比较方案并让用户确认。writing-plans 把实现拆细，test-driven-development 要求先写失败测试。碰到异常先系统查根因，做完以后还要验证和评审，不能只凭一句“已经修复”收工。

它约束的是代理的工作习惯。需求相对明确，但团队担心 AI 跳步骤、乱猜或自证正确时，这类方法很直接。

不过，Superpowers 产生的设计文档和计划主要服务于执行。它并没有把产品规格的长期演进当成首要问题。跨越多个 change 以后，哪些行为是当前正式规则，哪些只是某次实现的设计记录，仍然需要另一套规格管理方式。

同一个“记住我”需求交给 Superpowers，代理会先追问边界，比较存储方案，得到确认后列出计划；编码时先写测试，完成后再跑验证和审查。它最关心的是代理有没有用可靠的方法把事情做完。

讲到这里，三者的关系大概清楚了。Spec-Kit 试图建立完整的规格驱动链路；OpenSpec 围绕 change 管理规格的增量变化；Superpowers 把工程方法写成代理必须遵循的 Skills。它们有重叠，却不是同一层的替代品。

工具可以组合，组合以后又有新问题

一个自然想法是，把 OpenSpec 和 Superpowers 一起用。OpenSpec 负责记录需求和变更，Superpowers 负责设计、计划、测试和评审。方向没问题，实际跑长任务时仍会遇到麻烦。

比如 OpenSpec 已经生成 proposal 和 delta spec，切到设计阶段以后，代理有没有真的加载 brainstorming Skill？设计改了规格，交接上下文有没有更新？会话中断一天后，新代理怎么知道停在哪里？代理说验证通过时，有没有报告和分支处理记录？

靠提示词提醒当然能做。但任务一长，提醒会散落在聊天记录和文档里。人还是要记住当前阶段、下一条命令和必须同步的文件，只是从盯代码变成了盯流程。

Comet 就从这里出现了。

Comet：给长程任务加一个可恢复的运行框架

我不太愿意把 Comet 叫作第四个规范工具。就目前这个项目的实现来看，它更接近 Agent Skill Harness，也就是承载和约束 Skills 运行的框架。

Comet 的经典工作流把开发分成五个阶段。

Open 阶段使用 OpenSpec 建立 proposal、design、tasks 和 delta spec。Design 阶段接入 Superpowers 的需求细化与深度设计，并生成交接材料。Build 阶段形成实现计划，再选择子代理执行、分批执行或直接构建，也可以要求 TDD。Verify 阶段运行测试、检查规格覆盖、处理评审和分支状态，留下验证报告。Archive 阶段把 delta spec 合并回长期规格，再归档 change。

五个阶段本身不新鲜。Comet 真正补上的，是阶段之间的运行状态。

每个 change 有自己的 .comet.yaml，记录阶段、构建方式、验证结果和归档状态。引擎另存 run state，状态变化写入追加式事件日志。Guard 检查能否推进，handoff 记录交接内容，验证阶段必须拿出报告。

第二天重新打开项目，/comet 会先看活跃 change 和当前状态，再决定继续设计、构建、验证还是归档。恢复依据来自代码库里的产物和状态，不必重讲整段聊天。

Comet 没有要求所有事情都跑完整流程。新增认证能力可以走 full，范围明确的中等改动走 tweak，修复已有行为的 bug 走 hotfix。轻量路径碰到跨模块、新 capability 或 schema 变化时，会停下来让人决定是否升级。

再看“记住我”。如果它只是修复一个已经定义好的过期时间错误，hotfix 足够。要是产品准备新增可信设备体系，涉及新接口、安全策略和多端行为，那就应该走 full。工具不替我们判断风险，但它要求我们把判断说出来，并把选择记住。

/comet-any 把工作流想法整理成可评审、验证和分发的 Skill Bundle；comet eval 用 Rubric、Pass@k 和 Pass^k 等指标观察 Skill 重复运行时是否稳定。

Skill 很容易让人产生一种错觉：提示词看着完整，应该就有效。真正运行五次，可能有四次成功，也可能每次漏掉不同步骤。留下轨迹和评估结果以后，改 Skill 才不只是凭感觉调句子。

当然，Comet 也会增加产物和流程成本。一个人改一行静态文案，直接改、跑检查、提交，通常更省事。它更适合会跨会话、跨阶段，或者需要多人和多个代理接力的任务。项目风险不高，却把所有检查都开到最重，也是一种浪费。

怎么开始：我建议直接使用 Comet

讲到这里，我给一个明确建议：如果你准备在团队里建立一套规范的 AI 编程流程，可以直接从 Comet 开始。不用先在 Spec-Kit、OpenSpec、Superpowers 之间反复纠结，也不用自己手工串联 OpenSpec 和 Superpowers。

原因很实际。Comet 已经把需求、设计、构建、验证和归档接成了一条可恢复的工作流，还会根据任务规模选择 full、tweak 或 hotfix。团队面对的是同一个入口，流程状态和验证证据也留在项目里。换人、换会话，或者任务做到一半停下来，都比较容易接着走。

上手只需要两步：先用 npm install -g @rpamis/comet 安装，再到项目目录运行 comet init。之后做功能、改需求或者修 bug，直接调用 /comet。它会检查当前有没有活跃 change、任务停在哪个阶段，然后创建或恢复合适的工作流。

我建议把 /comet 作为正式开发任务的默认入口。一行文案、明确的配置修改，直接改完跑检查就可以；只要需求开始涉及设计取舍、多个文件或后续验证，就交给 Comet 路由。人只需要在需求边界、方案选择和失败处理这些地方做决定。

结束

回到开头那个“记住我”。AI 把复选框写出来，只能说明实现开始了。需求边界有没有确认，认证设计有没有调整，测试是否覆盖退出和过期，变更是否进入长期规格，这些都有答案，工作才算结束。

下次把需求交给 AI 之前，可以先问四件事：这次到底改变什么行为？哪些条件算验收通过？我们准备拿什么证据验证？完成以后，哪个文件记录系统的新事实？

如果这些问题没人回答，AI 写得越快，返工可能来得越早。