企业官网建设流程全解析

1. 三个规格工具摆在一起，我到底在纠结什么

第一次把 Spec Kit、OpenSpec、Superpowers 这三个名字摆在同一张白板上时，团队里有人问了一句很实在的话：我们是不是又在给自己找新玩具？这个问题我没办法回避，因为过去两年里，光是"规格驱动开发"这个概念，我们就换过至少四套流程。每一套刚上手时都让人觉得"这次终于对了"，跑上两三个迭代之后又开始出现各种水土不服。所以这次我给自己定了一条规矩：不写评测，不搞对比表格里的参数堆砌，而是拿八个真实存在的 Skill 场景，把三个工具分别跑一遍，看谁在哪个环节真正省了力气，谁只是把复杂度从 A 处搬到了 B 处。

先把三个东西的定位说清楚，不然后面全是空谈。Spec Kit 更像是一套围绕"规格即契约"的轻量框架，它把需求、验收标准、边界条件都收敛到一份可执行的规格文件里，强调规格先行、代码后置。OpenSpec 走的是另一条路，它把规格拆成可组合的片段，每个片段对应一个能力单元，强调规格的可复用和可拼装。Superpowers 则更偏向"能力编排"，它不太关心规格本身长什么样，而是关心多个 Skill 之间怎么串起来、怎么在运行时被调度和组合。三者不是同一维度的竞品，但在实际项目里，它们又确实会在同一个决策点上撞车：这个 Skill 的边界，到底该由谁来定义？

我选八个 Skill 作为落地样本，覆盖了从数据清洗、格式转换、接口适配到流程编排的常见类型。之所以选八个，是因为少于八个很难看出工具在"规模稍微上来一点"之后的真实表现，多于八个又会把记录成本推高到影响判断。这八个 Skill 里，有三个是纯计算型、两个是 IO 密集型、两个是编排型、还有一个是混合型。这个分布不是随便定的，它基本对应了一个中等复杂度系统里最常见的 Skill 形态。

提示：如果你也在做类似的工具选型，先别急着看功能列表。把你要落地的 Skill 按"计算型 / IO 型 / 编排型 / 混合型"分个类，这个分类比任何功能对比都更能决定你最后选谁。

我踩过的第一个坑，就是一开始拿一个最简单的格式转换 Skill 去试三个工具，结果三个都跑通了，于是得出"差不多"的结论。这个结论害人不浅。简单 Skill 根本压不出工具的差异，就像用一杯白开水去评测三套咖啡机。真正拉开差距的，是那些有状态、有依赖、有失败重试需求的 Skill。所以后面我会重点讲那三个编排型和混合型的 Skill，它们才是决策的关键。

2. 八个 Skill 的落地实录：谁在什么环节真正省了力气

2.1 三个纯计算型 Skill：差异最小，但暴露了规格表达力的上限

纯计算型 Skill 是最没有悬念的一类。输入确定、输出确定、无外部依赖，理论上三个工具都能轻松拿下。我拿其中一个做数值归一化的 Skill 做对照，Spec Kit 的写法是把归一化公式、输入范围、异常值处理策略全部写进规格文件，代码几乎是规格的直译。OpenSpec 则把这个 Skill 拆成"范围校验"和"数值映射"两个片段，各自独立可测。Superpowers 这边，我一开始有点不知道该怎么下手，因为它不强制你写规格，最后我是把它当成一个纯执行单元注册进去的。

跑下来三者的功能表现几乎一致，但有一个细节值得说：当需求发生变更，比如归一化的目标区间从 [0,1] 改成 [-1,1] 时，Spec Kit 只需要改规格文件里的一行，代码自动跟着走；OpenSpec 需要改"数值映射"那个片段，但因为片段是独立的，改动影响面被天然限制住了；Superpowers 则需要我去找到注册时写死的参数，手动改。这个差异在单个 Skill 上微不足道，但八个 Skill 一起改的时候，就是几十分钟和几分钟的区别。

这里我得到一个很重要的判断：纯计算型 Skill 选谁，取决于你的需求变更频率，而不是工具本身的能力。变更少，三者随便选；变更频繁，Spec Kit 和 OpenSpec 的规格驱动优势才会显现。很多人选型时忽略了这个变量，结果选了一个"功能最强"但变更成本最高的工具，用起来反而最累。

2.2 两个 IO 密集型 Skill：错误处理和重试策略才是分水岭

IO 密集型 Skill 是真正开始见真章的地方。我这两个 Skill 一个负责读取外部数据源并做增量同步，另一个负责把处理结果写回目标存储。它们的共同特点是：会失败，而且失败是常态，不是异常。网络抖动、目标端限流、数据格式临时不一致，这些都得处理。

Spec Kit 在这类 Skill 上的表现让我有点意外。它把"失败重试"当成规格的一部分来写，也就是说，重试次数、退避策略、幂等性要求，都是规格里明确声明的契约。这个思路的好处是，测试可以直接针对规格里的重试契约来写，不用去猜实现里到底重试了几次。OpenSpec 则把重试逻辑抽成一个可复用的片段，两个 IO Skill 共享同一个重试片段，改一处两个都生效。Superpowers 在这里暴露了一个短板：它的强项是编排，对于单个 Skill 内部的错误处理，它给的支持比较薄，我最后是自己在 Skill 内部手写了重试循环。

注意：IO 密集型 Skill 的重试策略，一定要区分"可重试错误"和"不可重试错误"。我见过太多实现把所有异常都无脑重试，结果一个数据格式错误被重试了五次，白白浪费了几十秒。这个区分在 Spec Kit 里是规格的一部分，在 OpenSpec 里是片段的一个配置项，在 Superpowers 里得你自己记得写。

实测下来，两个 IO Skill 在 Spec Kit 和 OpenSpec 下的稳定性明显更好，因为重试和幂等是被规格强制约束的，不会因为某个开发者偷懒就漏掉。Superpowers 下我多花了大概半天时间补错误处理，这部分成本在选型时很容易被低估。

2.3 两个编排型 Skill：Superpowers 的主场，但前提是你得先想清楚编排契约

到了编排型 Skill，Superpowers 终于进入了它的主场。这两个 Skill 一个负责按依赖顺序调度多个子任务，另一个负责在多个数据源之间做条件路由。Superpowers 在这类场景下的表达力确实强，它把"谁先谁后、谁依赖谁、失败后走哪条分支"这些编排逻辑变成了第一等公民，写起来很顺。

但这里有个前提，也是我踩得最深的一个坑：Superpowers 不会帮你定义编排契约，它只帮你执行编排。我一开始以为把几个 Skill 注册进去、连上线就完事了，结果跑起来发现子任务的输入输出对不上，因为我在注册时根本没想清楚每个 Skill 的输入输出契约。后来我回过头，先用 Spec Kit 的思路把每个子 Skill 的规格写清楚，再拿到 Superpowers 里做编排，整个流程才顺起来。

这个经历让我意识到，三个工具其实可以组合使用，而不是非此即彼。Spec Kit 负责把单个 Skill 的规格钉死，OpenSpec 负责把可复用的能力片段抽出来，Superpowers 负责把这些钉好的 Skill 编排起来。我后面几个 Skill 就是这么干的，效率比死磕单一工具高不少。

2.4 一个混合型 Skill：三个工具的能力边界在这里最清楚

混合型 Skill 是我特意加进来的，它既有计算逻辑，又有 IO，还需要被编排。这个 Skill 跑完，三个工具的能力边界就非常清楚了。Spec Kit 能把规格写得很完整，但编排能力弱；OpenSpec 的片段复用很舒服，但跨片段的编排契约需要额外维护；Superpowers 编排强，但单个 Skill 内部的规格约束弱。

我最后的做法是：这个混合 Skill 的规格用 Spec Kit 写，可复用的计算片段用 OpenSpec 抽出来，整体编排交给 Superpowers。听起来有点绕，但实际跑下来，每个工具都在它最擅长的地方发力，没有互相打架。这个组合方案我后面会详细讲怎么落地。

3. 规格驱动、片段复用、能力编排：三种工程方法论的底层逻辑

3.1 规格驱动开发真正解决的问题，不是文档，而是变更成本

很多人对规格驱动的理解停留在"先写文档再写代码"，这个理解太浅了。规格驱动真正解决的问题是变更成本。在没有规格约束的项目里，需求一变，你得去代码里找所有相关的地方，改完还得担心漏了哪里。有了规格，需求变更首先体现在规格上，代码是规格的投影，改规格就等于改代码的意图。

Spec Kit 把这个逻辑做得比较彻底，它要求规格足够精确，精确到可以据此生成验收测试。这个要求一开始会让人觉得繁琐，但跑上两三个迭代之后，你会发现它省下的是大量的沟通成本和回归测试成本。我拿一个 Skill 做过对比：同样的需求变更，没有规格约束时改完加验证花了将近两小时，有规格约束时改规格加跑测试只花了二十分钟。

提示：规格驱动不是让你写更多文档，而是让你写更少但更精确的文档。如果你的规格文件比代码还长，那说明你写错了方向。

3.2 片段复用的代价：你得先接受"能力是有边界的"

OpenSpec 的片段复用思路很吸引人，把能力拆成独立片段，哪里需要哪里拼。但它的代价也很明显：你得先接受"每个能力都是有边界的"，不能什么都往一个片段里塞。我一开始贪心，把一个片段做得很大，结果它既不好复用，也不好测试，最后又拆回三个小片段。

片段复用的另一个隐性成本是版本管理。当多个 Skill 共享同一个片段时，片段的任何改动都会影响所有使用方。OpenSpec 在这方面给了一些隔离机制，但最终还是得靠人来判断"这个改动会不会影响别的 Skill"。我的经验是，片段要拆到"单一职责"的程度，一个片段只做一件事，这样改动的影响面才可控。

3.3 能力编排的隐藏前提：契约先于编排

Superpowers 的能力编排很强，但它有一个隐藏前提：契约必须先于编排存在。也就是说，你得先知道每个被编排的 Skill 输入什么、输出什么、失败时表现如何，才能编排得起来。这个前提在文档里往往一笔带过，但实际落地时，它是决定成败的关键。

我见过一个团队直接用 Superpowers 做编排，结果因为子 Skill 的契约没定义清楚，编排逻辑写了一堆防御性代码，最后比不用编排还乱。所以我的建议是，用 Superpowers 之前，先用规格工具把每个子 Skill 的契约钉死，哪怕只是写一份简单的输入输出说明，也比没有强。

4. 选型决策：什么团队、什么阶段、该用哪个

4.1 按团队规模选：小团队别碰重编排

小团队，尤其是三五个人的团队，我建议优先考虑 Spec Kit 或 OpenSpec，别一上来就上 Superpowers。原因很简单：编排的价值在 Skill 数量多、依赖关系复杂时才体现，小团队通常没到这个规模，上编排工具只会增加理解成本。我见过一个四人团队硬上编排框架，结果光是维护编排配置就占了不少时间，得不偿失。

Spec Kit 和 OpenSpec 之间怎么选？如果你们的 Skill 之间复用少、每个 Skill 都比较独立，选 Spec Kit；如果 Skill 之间共享大量逻辑、复用需求强，选 OpenSpec。这个判断标准比看功能列表靠谱得多。

4.2 按项目阶段选：早期重规格，中期重复用，后期重编排

项目阶段也是一个重要变量。项目早期，需求还不稳定，这时候最重要的是把规格写清楚，让变更成本可控，Spec Kit 更合适。项目中期，能力开始沉淀，复用需求上来，OpenSpec 的片段复用能省不少事。项目后期，Skill 数量多了，依赖关系复杂了，Superpowers 的编排价值才真正显现。

我自己的项目就是按这个节奏走的：早期用 Spec Kit 把八个 Skill 的规格钉死，中期用 OpenSpec 抽出可复用片段，后期用 Superpowers 做整体编排。三个阶段用的工具不同，但每个阶段都在解决当时最痛的问题。

4.3 一张表看清三个工具的真实取舍

这张表不是让你照着选，而是让你看清每个工具的取舍。没有全能工具，只有适合当前阶段的工具。

5. 组合使用的落地路径：我最后是怎么把三个工具串起来的

5.1 第一步：用 Spec Kit 把每个 Skill 的规格钉死

组合使用的第一步，是用 Spec Kit 把八个 Skill 的规格全部写清楚。这一步不能省，因为后面无论是复用还是编排，都依赖这一步产出的契约。我写规格时遵循一个原则：每个 Skill 的规格必须包含输入、输出、边界条件、失败表现四部分，缺一不可。

这一步花了我大概两天时间，但后面省下的时间远超这个投入。规格写清楚之后，OpenSpec 的片段抽取和 Superpowers 的编排都有了依据，不用再靠猜。

5.2 第二步：用 OpenSpec 抽出可复用片段

规格钉死之后，我开始用 OpenSpec 抽可复用片段。抽取的标准是：如果一段逻辑在两个以上的 Skill 里出现，就抽成片段。我最后抽出了五个片段，包括重试逻辑、数据校验、格式转换等。这五个片段被多个 Skill 共享，改一处多处生效，维护成本明显下降。

注意：片段抽取不要过度。我一开始抽了十几个片段，结果片段之间的依赖关系变得很复杂，反而增加了理解成本。后来合并到五个，才达到一个比较舒服的状态。

5.3 第三步：用 Superpowers 做整体编排

最后一步是用 Superpowers 把钉好规格、抽好片段的 Skill 编排起来。因为前两步已经把契约定义清楚了，这一步的编排逻辑写起来很顺，几乎没有出现输入输出对不上的情况。编排配置里我重点处理了三件事：依赖顺序、失败分支、并发控制。这三件事在 Superpowers 里都有对应的表达方式，写起来不费劲。

整个组合方案跑下来，八个 Skill 的维护成本比我之前用单一工具时低了大概四成。这个数字不是精确测量，但体感上确实轻松不少。

6. 八个 Skill 跑完后，我总结出的几条硬经验

第一条经验：别在简单 Skill 上做选型决策。简单 Skill 压不出工具差异，拿它选型等于抛硬币。要选型，就拿有状态、有依赖、有失败重试需求的 Skill 去试。

第二条经验：规格的精确度决定后面所有环节的顺畅度。规格写得越精确，复用和编排越顺；规格写得含糊，后面全是补丁。我在这上面吃过亏，后来宁可多花半天写规格，也不愿意后面花两天补漏洞。

第三条经验：工具可以组合，不必非此即彼。Spec Kit、OpenSpec、Superpowers 不是互斥的，它们各自解决不同阶段的问题，组合使用往往比死磕单一工具更有效。

第四条经验：编排的前提是契约，契约的前提是规格。这个链条不能颠倒。跳过规格直接编排，最后一定会返工。

第五条经验：片段复用要克制。片段不是越多越好，拆得太细反而增加依赖复杂度。我的经验是，片段数量控制在五个左右比较舒服，超过十个就要重新审视是不是拆过头了。

第六条经验：变更成本是选型的核心指标，不是功能数量。功能再多，变更一次要改十个地方，那也是个累赘。选型时多问一句"改一次要动几处"，比看功能列表有用得多。

第七条经验：给每个 Skill 写一份"失败说明书"。这份说明书不用很长，但要写清楚这个 Skill 在什么情况下会失败、失败后应该怎么处理。这份说明书在编排阶段价值极高，能省下大量调试时间。

第八条经验：定期回顾规格和实现是否还一致。规格驱动最大的风险是规格和实现慢慢脱节，最后规格变成摆设。我的做法是每个迭代结束前花半小时对一遍，发现脱节立刻修。

这八条经验里，前四条是方法论层面的，后四条是操作层面的。方法论决定方向，操作决定落地，两者缺一不可。我在实际项目里反复验证过这些经验，它们不是纸上谈兵，而是踩过坑之后总结出来的。

最后再分享一个小技巧：如果你不确定该从哪个工具入手，就先拿一个混合型 Skill 分别用三个工具跑一遍。混合型 Skill 能同时压出规格、复用、编排三个维度的差异，跑完一遍，你心里基本就有答案了。这个方法我推荐给过几个同行，反馈都还不错。