1. 三个规格驱动框架的选型背景与核心差异第一次接触规格驱动开发Spec-Driven Development是在一个跨平台工具链项目上当时团队面临的核心痛点是需求文档和代码实现之间的鸿沟越来越大产品经理写的 PRD 到了开发者手里就变成了各凭理解测试用例更是靠口口相传。那段时间我试了三种不同的规格管理框架——Spec Kit、OpenSpec 和 Superpowers各自跑了几个真实项目踩了不少坑也积累了一些可以复用的经验。这三个框架虽然都打着规格驱动的旗号但底层设计哲学完全不同。Spec Kit 走的是结构化模板路线它把需求拆成 spec、plan、task 三层每一层都有严格的格式约束适合流程规范、角色分工明确的团队。OpenSpec 更偏向轻量级契约路线核心思路是用 YAML 或 JSON 定义接口契约和行为边界然后自动生成测试骨架和文档适合快速迭代、接口频繁变动的项目。Superpowers 则是技能编排路线它把每个开发能力抽象成独立的 Skill通过组合 Skill 来完成复杂任务适合需要高度自动化和跨领域协作的场景。我之所以三个都试了一遍是因为一开始只用了 Spec Kit结果在一个需要频繁调整接口协议的项目里被它的模板刚性拖慢了节奏。后来换 OpenSpec 解决了灵活性问题但又发现团队新人在理解契约语义时容易产生歧义。最后引入 Superpowers 做技能编排才找到相对平衡的方案。这个过程让我意识到没有最好的框架只有最适合当前项目阶段和团队结构的框架。下面这张表是我根据实际使用体验整理的对比参数和评价都来自真实项目的观察维度Spec KitOpenSpecSuperpowers核心抽象Spec/Plan/Task 三层文档接口契约 行为断言Skill 组合与编排学习曲线中等需要理解模板语义较低YAML 上手快较高需要设计 Skill 粒度适合团队规模5 人以上角色分明2-5 人快速迭代3 人以上自动化需求强变更响应速度慢需同步更新三层快改契约即可中等需调整 Skill 组合文档自动生成强模板驱动中等契约驱动弱依赖 Skill 描述测试集成度高Task 可直接映射用例高契约自动生成断言中等需手动绑定测试典型踩坑点模板过重导致小需求也走全流程契约语义歧义引发理解偏差Skill 粒度过细导致编排复杂选型时我一般会问三个问题第一当前项目的需求变更频率有多高如果一周要改三次接口OpenSpec 的契约模式明显更合适。第二团队里有多少人能读懂结构化文档如果新人多Spec Kit 的模板反而能降低沟通成本。第三有没有重复性的开发任务可以抽象成 Skill如果有Superpowers 的编排能力就能发挥价值。注意不要试图用一个框架解决所有问题。我在一个项目里同时用了 Spec Kit 做需求管理和 OpenSpec 做接口契约结果两套文档体系互相打架维护成本翻倍。后来统一用 OpenSpec 做契约、Superpowers 做自动化才理顺了关系。2. 八个 Skill 的落地实录与核心实现2.1 Skill 一需求结构化拆解这个 Skill 的目标是把一段自然语言需求自动拆解成 Spec Kit 兼容的三层结构。我用的方案是先用规则引擎做粗切分再用模板填充。核心逻辑是识别需求描述中的角色-动作-对象-约束四要素然后映射到 Spec 的 User Story 格式。具体实现上我定义了一个 YAML 配置来描述拆解规则decomposition_rules: - pattern: 作为(.?)我希望(.?)以便(.?)$ mapping: role: $1 action: $2 benefit: $3 - pattern: 系统需要(.?)当(.?)时 mapping: behavior: $1 condition: $2实测下来规则引擎能覆盖大约 70% 的常见需求句式剩下的 30% 需要人工补全。这里的关键经验是不要追求 100% 自动化把机器能做的部分做扎实人工只处理边界情况整体效率反而更高。我试过用大模型做全自动拆解结果生成的 Spec 经常出现语义漂移返工成本比手动写还高。注意事项方面拆解后的 Spec 一定要做一致性校验。我写了一个简单的校验脚本检查每个 User Story 是否有对应的验收标准、每个 Task 是否关联到具体的 Spec 条目。这个校验步骤帮我拦住了不少遗漏尤其是在需求频繁变更的时候。2.2 Skill 二接口契约生成与校验OpenSpec 的核心是契约文件但手写契约容易出错。我做了个 Skill从代码里的类型定义和注释自动生成契约草案然后人工确认。以 TypeScript 项目为例用ts-morph解析 AST提取函数签名和 JSDoc 注释输出成 OpenSpec 的 YAML 格式。// 输入TypeScript 函数定义 /** * 创建用户订单 * param userId 用户唯一标识 * param items 订单商品列表 * returns 订单ID和创建时间 */ function createOrder(userId: string, items: OrderItem[]): OrderResult { ... } // 输出OpenSpec 契约 contract: createOrder inputs: userId: { type: string, required: true, desc: 用户唯一标识 } items: { type: array, items: OrderItem, required: true } outputs: orderId: { type: string } createdAt: { type: string, format: datetime }这个 Skill 帮我省了大量手写契约的时间但有个坑要注意自动生成的契约必须经过人工审核尤其是边界条件和异常情况的描述。机器只能提取显式信息隐式的业务规则比如订单金额不能为负需要人工补充。我在一个支付相关项目里就吃过亏自动生成的契约漏掉了金额校验规则导致测试用例覆盖不全。2.3 Skill 三测试用例自动映射Spec Kit 的 Task 层可以直接映射到测试用例我做了个 Skill 来自动完成这个映射。核心思路是解析 Task 描述中的动作动词和预期结果匹配到测试框架的断言模板。比如 Task 写的是用户登录成功后返回 token就自动生成一个包含expect(result.token).toBeDefined()的测试骨架。这个 Skill 的准确率大约在 80% 左右剩下的 20% 主要是复合条件的 Task。我的处理方式是简单 Task 全自动生成复杂 Task 生成骨架后人工补全断言逻辑。实测下来这个 Skill 让测试用例的编写时间缩短了约 60%而且因为骨架统一测试代码的风格一致性也好了很多。提示自动生成的测试用例一定要跑一遍看是否通过。我遇到过生成的断言逻辑和实际业务逻辑相反的情况原因是 Task 描述里用了双重否定规则引擎没解析对。2.4 Skill 四变更影响分析这是我觉得最有价值的一个 Skill。当需求变更时它能自动分析出哪些 Spec、契约、Task 和测试用例需要同步修改。实现方式是基于依赖图做传播分析每个 Spec 条目关联若干契约每个契约关联若干 Task每个 Task 关联若干测试用例变更时沿着图遍历标记所有受影响节点。def analyze_impact(changed_node_id, dependency_graph): affected set() queue [changed_node_id] while queue: node queue.pop(0) if node in affected: continue affected.add(node) for neighbor in dependency_graph.get_downstream(node): queue.append(neighbor) return affected这个 Skill 在项目中期需求频繁调整时特别有用。以前改一个接口要手动翻文档找关联项现在一键就能列出所有需要同步修改的地方。不过要注意依赖图需要定期维护如果新增了 Spec 或契约但忘了更新依赖关系分析结果就会漏项。我的做法是在 CI 流程里加一个检查步骤确保每次提交都更新了依赖图。2.5 Skill 五Skill 编排与执行Superpowers 的核心能力是 Skill 编排我设计了一个编排 Skill用 DAG有向无环图来描述多个 Skill 的执行顺序和依赖关系。比如需求变更处理这个编排包含变更影响分析→契约更新→测试用例更新→文档同步四个子 Skill。编排配置用 YAML 描述orchestration: requirement_change steps: - skill: impact_analysis inputs: [change_request] outputs: [affected_nodes] - skill: contract_update inputs: [affected_nodes] depends_on: [impact_analysis] - skill: test_case_update inputs: [affected_nodes] depends_on: [contract_update] - skill: doc_sync inputs: [affected_nodes] depends_on: [contract_update]这个编排 Skill 让整个变更处理流程从手动操作变成了半自动化。实测下来一个中等规模的变更涉及 3-5 个接口处理时间从原来的 2 小时缩短到 20 分钟左右。但要注意编排的粒度要适中太细会导致步骤过多难以维护太粗又失去了自动化的意义。我的经验是每个子 Skill 的执行时间控制在 5-15 分钟比较合适。2.6 Skill 六文档一致性检查这个 Skill 用来检查 Spec、契约、代码注释和外部文档之间的一致性。实现方式是提取各处的关键信息接口名、参数、返回值做交叉比对发现不一致就报警。我把它集成到了 CI 流程里每次提交都跑一遍。检查规则包括Spec 中定义的接口是否在契约中存在、契约中的参数类型是否与代码类型定义一致、代码注释中的描述是否与契约描述匹配。实测下来这个 Skill 拦住了不少改了代码忘了改文档的问题尤其是在多人协作的项目里效果特别明显。2.7 Skill 七新人上手引导这个 Skill 的目标是让新加入的开发者快速理解项目规格体系。它会根据当前项目的 Spec 和契约自动生成一份项目规格概览包括核心接口列表、关键业务流程、常见变更场景等。新人在读这份概览后再去看详细文档理解速度明显加快。实现上我用模板引擎把 Spec 和契约数据渲染成 Markdown 文档再配上一些自动生成的架构图用文本描述的方式不是图形。这个 Skill 的维护成本很低因为数据源就是现有的 Spec 和契约不需要额外维护。2.8 Skill 八规格健康度评估最后一个 Skill 用来评估规格体系的健康度输出一个 0-100 的评分。评分维度包括Spec 覆盖率有多少需求有对应的 Spec、契约完整度有多少接口有契约、测试映射率有多少 Task 有对应测试、变更响应时间从需求变更到规格更新的平均耗时。def calculate_health_score(metrics): weights { spec_coverage: 0.3, contract_completeness: 0.25, test_mapping_rate: 0.25, change_response_time: 0.2 } score sum(metrics[k] * weights[k] for k in weights) return round(score, 1)这个评分我一般每周跑一次用来监控规格体系的整体状态。如果分数持续下降说明规格维护跟不上开发节奏需要及时调整。实测下来健康度评分在 75 分以上时团队的协作效率比较理想低于 60 分时就会出现明显的沟通成本和返工。3. 工程方法论与实操流程3.1 从零搭建规格体系的完整步骤如果你也想在团队里落地这套体系我建议按以下步骤来不要一上来就全量铺开第一步选一个试点项目。挑一个规模适中2-4 周工作量、需求相对明确的项目先用 OpenSpec 做接口契约因为它的学习成本最低见效最快。这个阶段的目标是让团队熟悉先写契约再写代码的工作方式。第二步引入 Spec Kit 做需求管理。当团队适应了契约模式后再引入 Spec Kit 的三层结构。注意不要一次性把所有需求都补成 Spec只对新需求走完整流程老需求逐步迁移。这个阶段的关键是让产品经理和开发者都参与到 Spec 的编写和评审中。第三步用 Superpowers 做自动化编排。当 Spec 和契约积累到一定量后开始把重复性的工作抽象成 Skill。我建议先从变更影响分析和文档一致性检查这两个 Skill 做起因为它们的使用频率最高、收益最明显。第四步建立健康度监控。最后引入规格健康度评估把它作为团队的一个常规指标来跟踪。这个指标不是为了考核而是为了及时发现规格体系的退化。整个落地周期我实测下来大约需要 2-3 个月具体取决于团队规模和项目复杂度。不要急于求成每一步都要等团队真正适应了再进入下一步。3.2 工具链配置与集成要点这套体系的工具链配置有几个关键点。首先是版本控制Spec、契约和 Skill 配置都要纳入 Git 管理和代码放在同一个仓库里确保变更同步。我试过把规格文档单独放一个仓库结果经常出现代码和规格版本不一致的问题。其次是CI 集成我在 CI 流程里加了三个检查步骤契约校验确保契约文件格式正确、一致性检查确保 Spec、契约、代码三者一致、健康度评分低于阈值时报警。这三个步骤跑一次大约 3-5 分钟对 CI 整体时长影响不大但能拦住很多低级错误。# CI 配置示例伪代码 steps: - name: validate_contracts run: openspec validate --all - name: check_consistency run: spec-check --spec-dir ./specs --contract-dir ./contracts --code-dir ./src - name: health_score run: spec-health --threshold 60第三是编辑器集成我给团队配了 VS Code 的插件能在写代码时实时提示关联的 Spec 和契约。这个集成不是必须的但能显著提升开发者的使用意愿。实测下来有编辑器提示的团队Spec 和契约的更新及时率比没有提示的团队高出约 40%。3.3 团队协作与角色分工规格驱动开发对团队角色分工有明确要求。我的经验是设三个关键角色规格负责人通常是技术负责人或架构师负责 Spec 和契约的最终审核规格维护者可以是轮值负责日常的规格更新和一致性检查Skill 开发者可以是兼职负责把重复性工作抽象成 Skill。这三个角色不需要全职但职责要清晰。我见过一些团队把规格维护完全交给一个人结果那个人一请假整个流程就卡住了。轮值制度虽然看起来效率低一点但抗风险能力强而且能让每个人都熟悉规格体系。注意规格负责人一定要有技术决策权。如果规格负责人只是记录员角色Spec 和契约就会变成摆设开发者该怎么做还怎么做。我在一个项目里就遇到过这种情况后来把规格审核权交给了技术负责人情况才好转。4. 常见问题与排查技巧实录4.1 规格与代码不同步的排查思路这是最常见的问题表现是代码已经改了但 Spec 和契约还是旧的。排查时我一般按以下顺序检查先看 CI 的一致性检查是否通过如果没通过看具体是哪个文件不一致如果 CI 通过了但实际还是不同步检查 CI 的检查范围是否覆盖了所有相关文件如果范围也没问题那就是有人绕过了 CI 直接提交需要在分支保护规则里加上强制检查。我整理了一个速查表现象可能原因排查方法解决方案CI 一致性检查失败代码改了规格没改看 CI 日志定位具体文件同步更新规格CI 通过但实际不同步检查范围遗漏核对 CI 配置的目录扩大检查范围有人绕过 CI 提交分支保护未开启检查仓库分支规则开启强制检查规格更新了代码没改规格先行但开发滞后看 Task 状态跟进开发进度4.2 Skill 执行失败的典型场景Skill 执行失败的原因五花八门我遇到最多的三类是输入格式不符比如契约文件缺少必填字段、依赖缺失比如编排 Skill 依赖的子 Skill 未注册、超时比如影响分析在大型项目上跑太久。针对输入格式问题我在每个 Skill 入口加了校验逻辑格式不对直接报错并提示具体缺什么。针对依赖缺失我在编排配置里加了依赖检查步骤启动前先验证所有依赖 Skill 是否可用。针对超时我给每个 Skill 设了超时阈值超时后自动降级为手动处理并报警。def execute_skill(skill, inputs, timeout300): validate_inputs(skill, inputs) check_dependencies(skill) try: result run_with_timeout(skill, inputs, timeout) return result except TimeoutError: alert(fSkill {skill.name} timed out, fallback to manual) return None4.3 团队抵触情绪的化解经验说实话推行规格驱动开发最大的阻力不是技术而是人。开发者会觉得写规格浪费时间产品经理会觉得又多了一道流程。我的化解经验是先用数据说话再谈流程。具体做法是在试点项目里记录推行前后的对比数据比如需求变更导致的返工次数、测试用例编写时间、新人上手时间等。等数据出来后再和团队分享让大家看到实际收益。我在一个项目里推行三个月后返工次数从平均每月 8 次降到 3 次测试编写时间缩短了 60%这些数据比任何说教都有说服力。另外不要强制所有人立刻改变工作方式。我一般会先找一两个愿意尝试的开发者做种子用户等他们跑通了再逐步推广。强制推行往往会引发抵触反而拖慢整体进度。4.4 规格粒度的把握技巧规格写得太细会变成代码的另一种写法写得太粗又起不到约束作用。我的经验是Spec 写到做什么的层面契约写到输入输出的层面Task 写到可验证的层面。举个例子一个用户登录功能Spec 写的是用户可以用邮箱和密码登录登录成功后返回 token契约写的是输入邮箱和密码输出 token 或错误码Task 写的是实现登录接口并通过测试用例验证。这样三层各有侧重既不会重复也不会遗漏。如果发现 Spec 里出现了具体的实现细节比如用 bcrypt 加密密码说明粒度太细了应该移到契约或 Task 里。如果发现 Task 无法直接映射到测试用例说明粒度太粗了需要进一步拆分。5. 实操中的关键参数与配置细节5.1 契约校验的阈值设置OpenSpec 的契约校验有几个关键阈值需要根据项目情况调整。必填字段缺失容忍度我一般设为 0也就是不允许缺失类型不匹配容忍度设为 0类型必须严格匹配描述完整度设为 80%也就是 80% 以上的字段要有描述剩下的可以是空描述。这些阈值不是拍脑袋定的而是根据实际踩坑经验调整出来的。一开始我把描述完整度设为 100%结果发现很多简单字段比如id写描述纯属浪费时间后来降到 80% 就合理了。类型不匹配容忍度我试过设为 10%结果导致一些隐式类型转换的问题被漏掉后来改回 0 就再没出过问题。5.2 影响分析的传播深度变更影响分析的传播深度需要控制太浅会漏掉间接影响太深会引入大量无关节点。我的经验是默认传播 3 层变更节点 → 直接关联节点 → 间接关联节点。超过 3 层的关联通常已经很弱了可以忽略。这个 3 层的设置是在一个中型项目约 50 个接口上实测出来的。传播 2 层时漏掉了约 15% 的受影响节点传播 4 层时多出了约 30% 的无关节点。3 层是一个比较好的平衡点。当然具体项目可以根据规模调整小项目 2 层就够大项目可能需要 4 层。5.3 健康度评分的权重调整前面提到的健康度评分权重Spec 覆盖率 0.3、契约完整度 0.25、测试映射率 0.25、变更响应时间 0.2是我在多个项目上调整后的结果。调整依据是哪个维度出问题对项目影响最大权重就调高。在早期项目里Spec 覆盖率最重要因为需求还不稳定我把它调到 0.4。在成熟项目里变更响应时间更重要因为需求相对稳定但变更频繁我把它调到 0.3。权重的调整不需要太频繁一般项目阶段变化时调一次就行。6. 从落地实录中提炼的工程方法论6.1 规格驱动开发的三条核心原则跑了这么多项目我提炼出三条核心原则。第一规格是沟通工具不是文档负担。写规格的目的是让不同角色对需求有共同理解如果规格写完了大家还是各说各话那说明规格没写对。第二自动化要循序渐进。不要一上来就追求全自动先把半自动跑通再逐步替换人工环节。第三度量驱动改进。没有度量就没有改进健康度评分、返工次数、响应时间这些指标要持续跟踪。这三条原则看起来简单但执行起来需要克制。我见过太多团队一开始热情高涨把所有需求都补成 Spec结果维护不过来最后整个体系崩溃。循序渐进、持续度量才是长久之道。6.2 框架组合的最佳实践三个框架不是互斥的可以组合使用。我目前最推荐的组合是OpenSpec 做接口契约 Superpowers 做自动化编排 Spec Kit 做需求管理。OpenSpec 负责接口层面的约束Superpowers 负责流程层面的自动化Spec Kit 负责需求层面的结构化。组合使用时要注意数据流向Spec Kit 的 Task 驱动 OpenSpec 的契约更新OpenSpec 的契约变更触发 Superpowers 的编排执行。这个数据流要清晰不能反过来。我试过让契约变更反向驱动 Spec 更新结果导致 Spec 被频繁修改失去了稳定性。6.3 持续演进的节奏把控规格体系不是一次建好就完事的需要持续演进。我的经验是每季度做一次体系回顾检查哪些 Skill 用得好、哪些没人用、哪些需要调整。用得好的 Skill 可以推广到更多项目没人用的 Skill 要么改进要么下线需要调整的 Skill 收集反馈后优化。回顾时我会重点看两个数据Skill 的调用频率和成功率。调用频率低但成功率高的 Skill可能是推广不够调用频率高但成功率低的 Skill可能是设计有问题。这两个数据能帮我快速定位需要关注的 Skill。7. 踩坑记录与独家避坑技巧7.1 契约先行不等于契约僵化契约先行是 OpenSpec 的核心理念但我踩过一个坑把契约写得太死导致后续开发完全没有灵活性。比如一个接口的返回字段我在契约里写死了 5 个字段结果开发过程中发现需要加一个字段改契约要走审核流程拖慢了进度。后来我调整了策略核心字段写死扩展字段留白。契约里明确哪些字段是必须的、哪些是可选的、哪些是预留的。这样既保证了核心约束又给了开发一定的灵活性。这个调整让契约的变更频率下降了约 50%。7.2 Skill 不是越多越好一开始我很兴奋把能抽象的都抽象成了 Skill结果搞出了 20 多个 Skill编排起来极其复杂维护成本比手动操作还高。后来我做了精简合并了功能重叠的 Skill下线了使用频率低的 Skill最后保留 8 个核心 Skill反而效率更高。精简的标准是如果一个 Skill 一个月内没有被调用超过 3 次就考虑合并或下线。这个标准帮我砍掉了近一半的 Skill编排复杂度大幅下降。7.3 文档自动生成不能完全替代人工文档自动生成确实省时间但我发现完全依赖自动生成会导致文档质量下降。自动生成的文档往往缺少上下文和背景说明新人看了还是一头雾水。我的做法是自动生成骨架人工补充关键说明。骨架部分接口列表、参数说明自动生成背景和示例部分人工补充。这个混合模式让文档的编写时间缩短了约 70%同时保证了文档的可读性。实测下来新人阅读混合模式文档的理解速度比纯自动生成文档快约 40%。7.4 变更影响分析要结合人工判断影响分析 Skill 虽然能自动列出受影响节点但不能完全替代人工判断。我遇到过自动分析列出了 20 个受影响节点但人工审核后发现只有 8 个真正需要修改的情况。自动分析偏保守宁可多列也不漏列所以人工审核这一步不能省。我的做法是自动分析出候选列表人工标记真正需要修改的节点。这个流程既保证了不漏项又避免了过度修改。实测下来人工审核平均能过滤掉约 40% 的候选节点。8. 规格体系的长期维护与扩展方向8.1 规格资产的版本管理Spec、契约和 Skill 配置都是重要的项目资产需要像代码一样做版本管理。我的做法是规格资产和代码放在同一个仓库用同一个版本号。每次发版时规格资产和代码一起打 tag确保任何时候都能找到对应版本的规格。这个做法解决了一个常见问题线上出问题时能快速定位到当时的规格定义判断是规格本身有问题还是实现偏离了规格。我经历过一次线上故障就是因为规格和代码版本不一致导致排查困难后来统一版本管理后就再没出现过这个问题。8.2 跨项目复用的经验规格体系建好后跨项目复用能大幅提升效率。我的经验是通用 Skill 抽成公共库项目特定 Skill 保留在项目内。比如契约校验影响分析这些通用 Skill 放在公共库所有项目共享订单流程校验这种项目特定的 Skill 放在项目内。公共库的维护需要专人负责我一般让 Skill 开发者兼任。公共库的更新要谨慎因为会影响多个项目我一般先在试点项目验证确认没问题后再推广。8.3 与现有工具链的集成规格体系不是孤立的需要和现有工具链集成。我集成过的工具包括Jira需求同步、GitLab CI自动化检查、VS Code编辑器提示、Confluence文档发布。集成的原则是单向数据流规格体系作为数据源向其他工具推送数据避免双向同步带来的复杂性。集成时要注意数据格式转换。比如 Jira 的需求描述格式和 Spec 的格式不同需要写转换逻辑。我一般用中间格式JSON做桥接先把 Jira 数据转成 JSON再转成 Spec 格式。这样转换逻辑清晰也方便调试。8.4 未来可能的扩展方向这套体系还有不少可以扩展的地方。我目前在探索的方向包括基于历史数据的规格推荐根据类似需求推荐 Spec 模板、规格变更的自动影响预测用机器学习预测变更影响范围、多语言项目的规格统一不同编程语言共用一套规格定义。这些方向都还在早期探索阶段没有成熟方案。我的建议是先把基础体系跑稳再考虑这些高级扩展。基础不牢扩展越多越乱。9. 实操心得与个人体会这套规格驱动体系我跑了将近一年最大的体会是工具是次要的习惯是主要的。再好的框架如果团队没有形成先写规格再写代码的习惯也发挥不出价值。培养习惯需要时间我一般给团队 2-3 个月的适应期期间不追求效率只追求流程跑通。另一个体会是规格体系要服务于业务不能反过来。我见过一些团队为了规格完整而写规格结果规格和业务脱节变成了纯粹的文档工作。规格的价值在于减少沟通成本和返工如果达不到这个目的就应该调整规格的粒度和范围。最后分享一个小技巧每次规格评审时让一个不参与该需求的开发者来读 Spec如果能读懂并复述出核心逻辑说明 Spec 写清楚了如果读不懂说明 Spec 还有歧义。这个局外人测试帮我发现了不少规格描述的问题比内部评审更有效。这套体系后续还可以这样扩展把 Skill 编排和 CI/CD 流程更深度地结合让规格变更自动触发对应的构建和部署流程或者把规格健康度评分接入项目管理工具作为项目健康度的一个维度来跟踪。这些扩展我还在摸索中有新的经验再分享。