这两个月我一直在折腾同一件事把手头一个原本需要三个人才能维护的全栈小项目压缩成“一个开发者 两条 AI 编程工作流”的形态。最后复盘真正让这件事跑起来的不是哪个特别聪明的模型也不是越写越长的 prompt而是给 AI 编程流程补上了规格驱动这套规矩。所谓规格驱动就是让 AI 在写业务代码之前先把“要做的功能、验收标准、任务拆分”作为文件落地到仓库里。OpenSpec 负责这件事Superpowers 负责在 AI 拿到规格之后用一套完整的工作流防止它跑偏。这篇文章想把我跑通后的完整打法复盘一遍适合正在用 Claude Code、opencode 这类工具写全栈项目或业务系统的人。如果你现在的状态是“AI demo 写得飞起项目一复杂就翻车”那这篇内容大概率能帮上忙。1. AI 编程在长流程任务上失控问题不在生成而在约束1.1 一次让我印象深刻的“AI 越帮越忙”现场先说个反面教材。我之前在做一个订单系统第一天让 Claude Code 加了个“会员积分”功能生成速度很快。用户下单、订单完成、积分入账链路一次跑通我当时觉得 AI 编程也就这样了。问题出在半个多月后。需求方又说“退款的时候要把积分扣回来但已经用掉的积分不能扣成负数”。这是个合理需求于是我又打开会话让 AI 改。结果它为了满足这个新规则直接改了积分账户表的数据结构还顺手把之前“订单完成入账”的逻辑也改掉了。关键问题是它并不知道自己改坏了。测试用例没有覆盖到旧链路AI 也不记得我当初为了“防止重复入账”在代码里留了什么特殊约定它只盯着最近一轮对话里的需求觉得把所有相关代码统一改掉就完成了。最后我花了一个晚上查数据才发现老用户积分被多扣了一轮。这次经历让我意识到一个本质问题AI 生成代码的能力早就不是瓶颈瓶颈在于它做长流程任务时的“行为一致性”。它没有一个稳定的项目记忆也没有一套硬性的执行契约。指望每一轮对话都靠上下文把之前所有设计决定“记住”本来就是反人性的做法——对人不行对 AI 更不行。1.2 长上下文、多轮对话与“语义稀释”很多人会问Claude 这类模型的上下文窗口不是很大吗为什么还会忘窗口大不代表它会一视同仁地利用上下文。当对话轮次多、文件内容杂、需求反复修改时AI 对早期信息的权重天然会降低。尤其是用户在最后几轮给了新指示模型很容易倾向于“以最新指示为准”。这在心理学上叫近因效应在 AI 推理里其实也非常明显。我自己的体感是AI 在单次会话的前 20 轮表现通常是最好的超过某个临界点后它开始频繁出现“前面已经定过的方案突然被推翻”“某个边界条件反复确认”“同一个字段在不同文件里出现两套命名”这类现象。不是模型变笨了是它的注意力被过长的上下文稀释了。打个比方你对着一个新人连续口述交代三周的工作他当然会越听越乱。真正靠谱的项目交接靠的是需求文档、设计文档、任务列表这些“物件化”的东西。AI 也一样它需要一个外置记忆系统。最便宜的方案不是给它更大的上下文而是把关键结论从对话流里抽出来写进文件。1.3 对话式开发与规格驱动开发的本质差异我整理了一张对比表基本能说明为什么越大的项目越需要规格驱动对比维度纯对话式开发规格驱动开发需求存放位置聊天窗口里仓库中可版本化的规格文件验收标准“你说差不多就行”任务列表 可验证规则跨会话恢复靠 AI 模糊记忆重新读取规格文件即可需求变更追溯很难查“当初为什么这么定”change 记录完整保留多任务并行能力弱容易互相污染强规格之间边界清晰适合场景一次性脚本、快速验证多模块、长期迭代的系统但这不意味着所有项目都该上规格驱动。如果你只是让 AI 写个一次性的 CSV 处理脚本那规格驱动纯属浪费。真正需要用到这套打法的是“明天还要继续长”的项目——它会在未来几周甚至几个月里持续迭代多个人或多个 AI 会话会反复走进来改代码。2. OpenSpec 的规格驱动思路先定义“什么是对的”再让 AI 写代码2.1 OpenSpec 到底是一个什么东西OpenSpec 是一套围绕规格驱动开发设计的工具链。它不绑定某个模型也不绑定某个编辑器核心是一组命令行工具加上一套固定的目录/文件约定。你可以把它理解成一套“AI 时代的变更管理协议”。以前我们做需求变更靠的是 Jira 工单、PR 描述和 WikiOpenSpec 则把这些东西压缩成一个当前变更目录里面主要分三类文件proposal记录这个变更为什么存在背景是什么要解决什么问题。specs记录功能做出来之后“应该满足什么规则”里面尽可能写可验证的条款。tasks把这个变更拆成的具体落地任务AI 照着做即可。每个新需求进来不是先讨论代码而是先为这个变更创建一个 OpenSpec 目录。这个目录会成为后续所有实现的唯一依据。AI 实现完功能后再来更新对应的任务状态。整个过程跟传统的“用户故事 验收条件 任务拆分”很像但它被设计成了 AI 可以顺畅读懂的文件结构。2.2 我用下来的核心命令流创建、校验、执行、收尾下面这组命令是我当前环境里在用的。需要注意OpenSpec 迭代速度不慢命令名在不同版本里可能叫new也可能叫create所以千万不要背死命令重点是懂流程# 在 git 项目根目录初始化规格仓库 openspec init # 为一次新变更创建规格骨架 openspec create 会员积分系统 # 如果实现过程中你发现规格描述不完整可以用 update 同步 openspec update # 校验 spec 是否完整、任务是否有遗漏 openspec validate # 查看这次变更的进度还差哪些任务没完成 openspec status # 变更完成后收尾关闭这次 change openspec complete我自己的习惯是接到一个需求后先用openspec create把变更骨架拉出来然后立刻去编辑 proposal 和 specs 文件。等 specs 里的规则写得差不多再让 AI 补 tasks。这个顺序很重要——如果 tasks 先于 specs 被写出来AI 很容易把任务拆得跟需求对不上。openspec validate是我最常用的一条命令。它相当于在正式写代码之前做一次“需求体检”功能有没有验收条件任务列表有没有和规格对应变更描述里的影响范围是否清晰。这些问题在体检阶段暴露总比代码写完再返工要便宜得多。2.3 什么才算“好规格”可验证规则优先很多人第一次接触规格驱动时会犯同一个错误用写博客的方式写规格。比如- 系统要具备良好的积分管理能力 - 用户体验要流畅 - 注意并发和数据安全这种规格我称之为“伪规格”因为它每一句都正确但没有任何一句可以被执行或验证。AI 读了之后可以写出一百种实现方式你根本没法判断它到底有没有满足需求。真正好用的规格长这样## 规则积分发放 - 触发条件订单状态进入 completed - 积分计算按实付金额向下取整每 1 元发 1 积分 - 可验证样例一笔实付 99.9 元的订单发放 99 积分 - 边界情况退款成功后对应积分在同一事务内扣回AI 看到这样的规则不会对“什么是对”产生理解分歧测试工程师照着最后一条“边界情况”就能写出回归测试你自己过一周回来看也能快速理解当初为什么这么设计。我在实际项目里给团队定的标准是一条规格如果没有配套的“可验证样例”或明确边界就不允许进入开发阶段。宁可前面多花半个小时打磨规则也不让 AI 后面多花半天猜需求。规格驱动真正的价值不是“写文档”而是把模糊的需求翻译成 AI 和测试都能执行的判断标准。3. Superpowers 在做什么把 AI 的一次性聪明变成可复用的干活流程3.1 一个 skills 技能库在 AI 编程里的角色OpenSpec 解决了“做什么”的问题但 AI 拿到规格后具体怎么干活还是会乱。这时候就需要 Superpowers 出场。Superpowers 本身是一套开源技能库面向支持 Skills 机制的 AI 编程客户端。Skills 机制可以简单理解为把一套成熟的工作流打包成 AI 能读取的 Markdown 指令文件。AI 一旦识别到当前任务匹配某个技能就会按里面的步骤走而不是自由发挥。我以前始终觉得 AI 写代码有一个明显缺陷它对“怎么开始一件事”没有固定章法。同一个需求今天心情好它先写文档再写代码明天换个会话它可能上来就改数据库表结构。Superpowers 解决的就是这个问题。它给 AI 装上了一套类似“肌肉记忆”的行为准则让推理过程稳定、可复现。3.2 从 brainstorming 到 debugging 的完整动作拆解我在实战中用到的 Superpowers 工作流大致包含四条主流程第一条是 brainstorming。需求方抛出问题时AI 不会马上写代码而是先进入澄清状态把涉及的业务背景、边界条件、异常情况一项项问清楚。以前我总觉得这一步浪费时间后来发现这里多问五个问题后面能少改十次代码。第二条是写计划。需求澄清完之后AI 会把实现思路落成一个计划文档列出准备改哪些文件、涉及哪些数据模型、接口怎么调整。这个计划不是为了给你看的是为了让 AI 自己有一个可以反复参照的执行基准。第三条是执行计划。它会根据计划生成任务清单一个任务一个任务地做而不是一口气把所有代码全倒出来。每完成一个小任务它会停下来确认测试状态再进入下一个任务。第四条是 debugging。遇到问题时AI 会先做假设、再设计验证方案而不是东改一行西改一行。这套流程看起来不复杂但如果你用过原生状态下的 AI 编程工具就会知道没有这套约束时AI 太容易在第一步就冲进代码堆里等它把关键文件改得面目全非再回头解释“我为什么这么改”。3.3 为什么它比“精心写一段 prompt”更靠谱经常有人问我Superpowers 不就是一组更长的 prompt 吗我自己写一个“你必须先规划再写代码”的 system prompt 不就行了问题在于prompt 是一次性的。你今天写一段“请先规划再写代码”它只能约束当前会话当前任务明天换一个需求你又要重新叮嘱一遍。而且 prompt 写长了AI 到后面很容易忽略里面的某些条款因为那些内容对它来说只是“背景信息”不是“操作指令”。Superpowers 这类技能库的本质区别在于它把工作流拆成了一个个可以被独立调用、组合、复用的技能块。收到需求时AI 先识别场景再调用对应的技能流程。技能内容可以跨会话、跨项目被反复使用也可以根据项目特点增删。比 prompt 更结构化也比 prompt 更扛得住长任务。用公司管理来类比prompt 像领导开会时口头说一句“大家干活仔细点”Superpowers 像给每个岗位发了一份标准作业手册。口头叮嘱的效果看运气手册的效果相对稳定。4. 组合打法OpenSpec 划边界Superpowers 定流程AI 照单执行4.1 两套工具为什么能无缝拼在一起OpenSpec 和 Superpowers 不是同一层的东西所以它们不冲突反而高度互补。OpenSpec 的核心产出是“规格文件”本质是给 AI 划定问题和验收的边界但规格文件不会自动告诉 AI“你应该先澄清需求再写代码写完代码要跑测试”。后者是 Superpowers 的活。Superpowers 的核心产出是“流程纪律”但它的流程不能凭空产生业务规则。它做 brainstorm 时需要从某个变更上下文出发写计划时也需要知道究竟要覆盖哪些功能边界。这些内容正好来自 OpenSpec 的 proposal 和 specs 文件。两者都认定同一件事文件系统是人和 AI 之间最可靠的协作接口。聊天窗口是易失的模型记忆是不可信的只有落在仓库里的文件可以被反复读取、 diff、评审。顺着这个共识二者就自然可以拼出一套稳定打法。下面这张表是我在项目里划分的责任边界流程阶段OpenSpec 的责任Superpowers 的责任核心产物需求澄清提供变更背景负责追问边界条件澄清记录输入到 proposal规则定义生成并维护 specs不参与可验证的功能规则执行计划提供基础任务拆分细化成可执行子步骤计划文档 任务清单代码实现不参与监督 AI 按计划逐步实现代码提交验证回归validate 校验规格完整性运行测试、进入 debugging测试报告与状态更新4.2 一套可以直接照抄的七个步骤我现在的项目流程基本是固定的七步你们可以直接照搬第一步让 AI 先读项目里的 AGENTS.md 或 CLAUDE.md把工作协议加载进来。第二步告诉它新需求进来后先进入 Superpowers 的 brainstorming 流程不写代码先澄清边界。比如“会员要分等级吗”“积分会过期吗”“退款怎么处理”这些问题在 brainstorming 阶段就要问完而不是边写边猜。第三步把澄清后的结果用openspec create落成变更骨架再编辑 proposal 和 specs把业务规则写清楚。第四步执行openspec validate确认规格没有含糊其辞的地方。第五步让 Superpowers 进入 planning 流程OpenSpec 提供变更约束它负责生成计划文档和详细任务清单。第六步AI 按任务清单逐项实现每完成一个任务跑一次相关测试再进入下一个任务。所有代码改动都关联到这次 OpenSpec change 的范围内不允许顺手改无关文件。第七步所有任务完成后跑openspec status看剩余项再跑一遍完整测试最后用openspec complete收尾关闭这次变更。这套流程最大的好处是中途即使你换了客户端甚至把任务交给另一个 AI 工具继续做只要仓库里的 OpenSpec 目录还在、计划文档还在新 AI 读一遍就能无缝衔接。它不需要你重新把项目背景从头讲一遍。4.3 一个具体的落地样例给订单系统增加“会员积分”为了方便理解我模拟一个真实需求给一个商城订单系统增加会员积分功能。需求刚抛出来时AI 可能会表现得很兴奋准备直接改订单模块。我会先拦下它告诉它按 OpenSpec 流程走。于是它先生成 proposal里面写清为什么要做积分、影响范围是什么# Change Proposal: 会员积分体系 ## 背景 用户下单完成后没有任何