企业官网建设流程全解析

1. 三个规格驱动框架的选型背景与核心差异

第一次接触规格驱动开发（Spec-Driven Development）是在一个跨平台工具链项目上，当时团队面临的核心痛点是：需求文档和代码实现之间的鸿沟越来越大，产品经理写的 PRD 到了开发者手里就变成了"各凭理解"，测试用例更是靠口口相传。那段时间我试了三种不同的规格管理框架——Spec Kit、OpenSpec 和 Superpowers，各自跑了几个真实项目，踩了不少坑，也积累了一些可以复用的经验。

这三个框架虽然都打着"规格驱动"的旗号，但底层设计哲学完全不同。Spec Kit 走的是结构化模板路线，它把需求拆成 spec、plan、task 三层，每一层都有严格的格式约束，适合流程规范、角色分工明确的团队。OpenSpec 更偏向轻量级契约路线，核心思路是用 YAML 或 JSON 定义接口契约和行为边界，然后自动生成测试骨架和文档，适合快速迭代、接口频繁变动的项目。Superpowers 则是技能编排路线，它把每个开发能力抽象成独立的 Skill，通过组合 Skill 来完成复杂任务，适合需要高度自动化和跨领域协作的场景。

我之所以三个都试了一遍，是因为一开始只用了 Spec Kit，结果在一个需要频繁调整接口协议的项目里被它的模板刚性拖慢了节奏。后来换 OpenSpec 解决了灵活性问题，但又发现团队新人在理解契约语义时容易产生歧义。最后引入 Superpowers 做技能编排，才找到相对平衡的方案。这个过程让我意识到：没有最好的框架，只有最适合当前项目阶段和团队结构的框架。

下面这张表是我根据实际使用体验整理的对比，参数和评价都来自真实项目的观察：

选型时我一般会问三个问题：第一，当前项目的需求变更频率有多高？如果一周要改三次接口，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 直接提交，需要在分支保护规则里加上强制检查。

我整理了一个速查表：

4.2 Skill 执行失败的典型场景

Skill 执行失败的原因五花八门，我遇到最多的三类是：输入格式不符（比如契约文件缺少必填字段）、依赖缺失（比如编排 Skill 依赖的子 Skill 未注册）、超时（比如影响分析在大型项目上跑太久）。

针对输入格式问题，我在每个 Skill 入口加了校验逻辑，格式不对直接报错并提示具体缺什么。针对依赖缺失，我在编排配置里加了依赖检查步骤，启动前先验证所有依赖 Skill 是否可用。针对超时，我给每个 Skill 设了超时阈值，超时后自动降级为手动处理并报警。

def execute_skill(skill, inputs, timeout=300): validate_inputs(skill, inputs) check_dependencies(skill) try: result = run_with_timeout(skill, inputs, timeout) return result except TimeoutError: alert(f"Skill {skill.name} timed out, fallback to manual") return None

4.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 流程更深度地结合，让规格变更自动触发对应的构建和部署流程；或者把规格健康度评分接入项目管理工具，作为项目健康度的一个维度来跟踪。这些扩展我还在摸索中，有新的经验再分享。