框架怎么落地？直接实战搞起。我在多个中型老项目的企业级前端项目上跑了这套体系，8 个 Skill 覆盖从需求到交付的完整链路，多个团队目前反馈都是非常好用。

先说一下：在推全链路 AI 化的过程中，我遇上了五个实打实的问题——

非开发岗位跟不上。 产品、测试日常也在用 AI，但用得浅——产品拿它润色文档，测试用它生成几个用例。开发侧已经把 AI 嵌入工作流了，到了需求评审还是口头沟通加截图，到了测试还是手工点点点。AI 出了编码边界就断电。

环节之间衔接不上。 产品写了一版 PRD，开发用 AI 生成了代码，测试又用另一套方式写用例。三个环节产出格式不一样、术语不一样，出了事往回追溯——产品说写清楚了，开发说按需求做的，测试说按实际行为测的。扯皮成本比编码成本高。

需求来回变，返工停不下来。 AI 写得再快架不住改三版。而且 AI 代码有个特点——第一版最工整，改到第三版开始"改不动了"，逻辑绕来绕去。

AI 识别不了变更范围。 改一个筛选条件，列表页、详情页、导出功能全炸了。测试测到崩溃。

经验跟着人走，不跟着项目走。 规范在老开发脑子里，某个模块为什么那么写只有经手过的人知道。新人从头踩一遍坑。

五个问题叠在一起，我开始意识到光靠个人提效的方法论不够用。问题不是某个环节卡住了，是环节之间的交接面全站在不一样的角度去表达。

转折点发生在一个周五下午。测试同事拿着 Excel 找我："你们这轮提测了 12 个功能点，我手工点了半天，覆盖率不到一半，还有 2 个小的功能点你们是不是忘写了，浪费我时间。"我让开发同事给他沟通解释，她听了十分钟放弃了。

那一刻我知道了——解法不是更多文档，是把每个环节的产出固定下来。需求评审的产出长什么样、接口对接的产出长什么样、测试用例的产出长什么样，全部标准化。然后让这些产出自动流转到下个环节。

所以我开始写 Skill。

八个 Skill，覆盖完整闭环

我把需求、设计、开发、测试、验收、Bug 修复全部写成独立的 Skill。我最开始只写了三个——product、ui、review。跑完第一个需求之后发现断档太多，才陆续补上 api、page、test、qa、bugfix。项目里实际在跑的八个：

Skill

职责

product

需求评审 → 任务拆解

api

接口文档 → 类型定义 + 请求函数

ui

设计稿 → 组件代码

page

组件 + API → 完整页面

test

单元测试

qa

QA 用例扫查

review

Code Review + 规范回写

bugfix

Bug Case → 根因定位 → 修复

依赖顺序是固定的，下游消费上游的产出：

product（需求评审 + 任务拆解）
│
├──▶ api（接口对接） ├──▶ ui（设计稿转组件）
│ │
└──────────┬───────────────────┘
▼
page（组件 + API → 完整页面）
│
▼
test（单元测试）
│
▼
qa（QA 用例扫查）
│
▼
review（Code Review + 规范回写）
│
▼
bugfix（Bug 修复，独立触发）
│
▼
review（二次审查）

qa 和 bugfix 是我最晚加进来的两个 Skill。加 qa 的原因很具体——测试同事的 Excel 用例跟代码实现之间有一个巨大的断层，开发说做完了、测试说没覆盖。加 bugfix 是因为 qa 提出了个 Bug，AI 改了三次都没好，每次都是"看起来像这里的问题"就下手改了，没先定位根因。后来补上约束：根因说不清，不许动手。

实现原理：所有产出收进一个目录：spec

八个 Skill 的产物不能散落在项目各处——否则三个月后谁也找不到哪个需求对应哪些文档。这块我参考了 OpenSpec（Fission-AI 开源的 spec-driven development 框架）的思路，核心就一条规矩：每个需求的全部 Skill 输出收进同一个目录。

具体长这样：

spec/changes/
├── .spec.template.yaml # 新需求的模板，复制即用
├── user-management/ # 一个 feature 的完整产出
│ ├── .spec.yaml # 进度追踪（每个 skill 状态：pending → completed）
│ ├── product.md # 需求评审：六维评审报告 + 任务列表
│ ├── api.md # 接口对接：接口契约 + 类型定义
│ ├── ui.md # 设计还原：组件列表 + 还原说明
│ ├── page.md # 页面组装：数据流 + 状态说明
│ ├── tests.md # 单元测试：测试结果 + 覆盖率
│ ├── qa.md # QA 扫查：用例对照 + 通过率
│ └── review.md # Code Review：结构化审查报告
└── archive/ # 已完成的按日期归档
└── 2026-07-15-user-management/

每个 Skill 最后一步必须把产出写入对应文件，并更新 .spec.yaml 中对应状态为 completed。进度不用问人，打开看一眼就知道卡在哪。Review 的时候所有上下文全在一个目录里，不用追着问"那个接口文档发哪了"、"测试报告在哪"。

实际产出如下

每个 Skill 内部的三个共同设计

八个 Skill 分工不同，但内部有三条共同设计。这三条比具体步骤更重要——它们是"为什么这套东西能稳定运行"的底层逻辑。

设计一：先读 CLAUDE.md，不可跳过。api 上来先确认命名规范和响应体格式，ui 先确认封装了哪些组件、哪些已废弃、哪些禁止直接用 antd 导入，bugfix 先确认修复可能触碰哪些禁区。AI 不知道的事不会主动问。 不喂约束，它就按训练数据里的"通用实践"来，出来的代码必然跟团队规范打架。最早版本的 ui 没加这条，生成出来的组件用的全是 antd 原生组件，但项目里全封装过了。

设计二：有明确的决策点，停下来等人。 不是全自动。全自动在企业场景里是灾难——AI 做错判断没人拦，一路跑到线上才炸。product 发现某个功能已经有人做过了——停下来确认是复用还是重做。api 发现接口字段文档没说清楚——标 [待确认] 等人补，不猜不推断。bugfix 发现 Issue 信息不全（没复现步骤、没预期行为）——暂停等人补充。AI 不会补位的地方，用决策点兜住。

设计三：末尾挂一张"常见坑速查表"。 同一个模型在不同项目里犯不同的错。每个坑写成"现象 → 原因 → 处理"三列。这只表是活的——每交付一个需求，review 发现新坑就补进去。比如 bugfix 的表：

现象

原因

处理

修完一个 Bug 引入另一个

只看了 happy path

回三步检查法里"边界"逐条过——空值、权限、并发

顺手重构了无关代码

忍不住"顺便优化"

改前把"不做什么"念一遍，多一行都不写

改了好几个文件但根因没找到

在症状层面修修补补

退回定位：一句话说清根因了吗？说不清继续查

下一个修 Bug 的人不需要重踩这些坑——AI 加载 bugfix Skill 时，这些坑自动变成约束。

贯穿全流程的四个底座

八个 Skill 跑起来之后，我开始盯另一个问题——单个环节的产出稳了，但整条流水线还是会翻车。于是我开始补底座。下面这四个机制不是设计出来的，是修 bug 修出来的。

SDD 闭环（规范驱动开发）。 四步循环：

CLAUDE.md 定义规范 → AI 按规范生成 → Code Review 验证符合度 → 发现违规补规范

举个真实例子：AI 生成的 UI 没用 CustomSkeleton 封装组件，直接用了原始组件库的 Skeleton。不是骂一句 AI 智障就完事了——回去翻 CLAUDE.md，有没有写"骨架屏必须用 CustomSkeleton"？没写 → 不是 AI 的错，是规范缺失，补进去。写了 → 代码错误，修代码。每次 AI 跑偏都是发现规范漏洞的机会。

不清晰就停。 需求模糊、接口缺字段、设计稿不确定、Case 信息不全——任何环节遇到不确定就停下来问，不许猜、不许脑补、不许替用户决策。

文档驱动防幻觉。 Tailwind / React / useRequest 等关键依赖强制先读 Context7 官方文档再回答，每个 Skill 第一步必读项目 rule 文件。代码不是从模型训练数据里瞎编的，是从真实文档锚定出来的。

spec 单目录收拢。 前面展开讲了——所有产出在一个目录下，进度可追踪，上下文不丢失，Review 时一眼看清全貌。

三条铁律，是血泪堆出来的

这些规则是踩了无数次坑之后焊死的，每条背后都有一个真实翻车现场。

Characterization Test（行为基线）。 改造老模块之前，别急着写"应该返回什么"的测试。先跑一遍现有代码，把实际输出记录下来，转成断言。测的是代码实际在做什么，不是应该做什么。这一步跳过去直接改代码，改完之后 AI 可能悄悄改了某个没测到的行为路径——测试全绿、diff 干净、上线炸了。这种情况最阴险了，因为你不是没测，你测错东西了。

预期值必须是字面量。expect(price).toBe("1.00")，不能写成 expect(price).toBe((100/100).toFixed(2))。不能在断言里重算被测逻辑来拼 expected——万一被测的算法有 bug，你的 expected 也跟着错，测试永远绿。这条规则看着简单，我见过至少三次因为违反它导致线上事故。

每批只做 1-3 个。 测试也好、组件也好，AI 一次生成 20 个，一半跑不通，整批都不可信。每批做 1-3 个，跑通、review 过、确认没问题，再做下一批。慢就是快。

不做什么

这些规则是 AI 替我踩出来的。有一次它顺手改了一个不在需求范围内的导出逻辑，review 没发现，上线后导出的 Excel 列名全是错的。从那以后"不做什么"变成了强制约束，写在每个 Skill 的禁区栏里。

不在没有 PRD 的情况下凭空拆任务不引入项目技术栈以外的依赖不顺手重构不在任务范围内的代码不用 AI 自己说的"没问题"代替人手验证不为一次性操作创建 Skill——只有可复制、可参数化、可自动化的事才值得 Skill 化跨项目分发：别让 Skill 分叉

一套 Skill 打磨好了，不能让每个项目手动拷。我们最早就是手动拷的，两个月后发现 A 项目改了 product 加了防重复，B 项目还在用旧版——同一个坑 B 项目月月踩。手动拷的致命问题不是麻烦，是分叉。 后来写了同步脚本，一个 sync.sh 推到所有下游。源仓库改了什么，所有项目统一更新。

为什么是 OpenSpec，不是 Spec-Kit 或 Superpowers

现在市面上做规范驱动开发的主流方案有三个：Spec-Kit（GitHub 官方）、OpenSpec（Fission-AI 社区）、Superpowers。三个我都研究过，说说我为什么选了 OpenSpec。

理念

适合场景

安装

学习成本

Spec-Kit

七阶段门控流水线，流程严谨

新项目、大团队、企业级合规

Python + uv，较重

中等偏高

OpenSpec

三步迭代（propose→apply→archive），轻量灵活

存量改造、小团队、敏捷迭代

npm install -g

，30 秒

低

Superpowers

Skill 机制 + harness 配置，工具集成深

已有 Claude Code 深度用户，需 hooks 和权限管控

配置式，不依赖 CLI

中等

我的选择逻辑很简单——我的场景是在已有项目上做增量改造，不是从零搭建新项目。团队不大，流程不想太重。OpenSpec 的三步走（提案→执行→归档）刚好够用，不绑 GitHub 生态，装完就能跑，而且对 Claude Code / Codex / Cursor 的兼容最好。

Spec-Kit 太像瀑布流了——七个阶段一个一个过，对存量项目来说太重。Superpowers 的思路很好，但它更偏工具配置层，不太适合作为团队协作的主流程引擎。

我们这套 Skill 体系的灵感其实都参考了上面三个 SDD 工具 ，只是opensepc 理论作为基座

选工具的核心不是谁功能多，是谁刚好够用，不多不少。 对我来说，OpenSpec 刚好卡在这个位置。

Skill 是长出来的 + 从哪开始

第一个版本的 Skill 很粗糙，就三四步。跑第一个需求，review 发现 AI 生成已存在的组件——product 补上第零步。跑第二个需求，review 发现没处理 loading 态——page 补上四态覆盖。跑第三个需求，线上 Bug 查三天找不到根因——bugfix 补上根因确认铁律。跑第四个需求，QA 说测试用例没覆盖——qa

从零写出来。四个需求下来，八个 Skill 被真实业务反复摩擦，该补的坑都补上了。

网上的现成 Skill 可以参考，但骨架得自己搭——只有你们知道禁区在哪、习惯是什么。

如果你现在就想动手：

先只做一个 Skill——挑最痛点。需求不清做 product，UI 还原差做 ui，Bug 反复出做 bugfix。一个跑稳再扩用 Markdown 写，放 .claude/skills/ 下。结构就三段：触发条件、执行步骤（标注决策点）、常见坑建一个单目录收产出，哪怕只收两三个文件，也比到处散落强。进度用 yaml 标，别靠脑子记第一个版本别追求完美，跑起来 review 自然会告诉你漏了什么CLAUDE.md 是约束来源——Skill 管流程，CLAUDE.md 管规范，AI 跑偏了先判是哪个漏了

单项目跑稳之后，下一步是多 Agent 并行——这块上一篇文章已经展开聊了。顺序不能反：Skill 是基础，多 Agent 是加速器。 先把八个 Skill 跑上三五个需求，每个 Skill 的产出格式稳定了、决策点验证过了、常见坑表累计了至少五条了，再拆并行。

多 Agent 这块我目前自己也在试水阶段，实践不到一个月，预计一个月后深度分享企业级多 Agent 的AI Coding 团队协作的经验。

八个 Skill 串起来的全链路，说白了就是一套 Harness 工程——把 AI 这匹野马套上缰绳，不是让它跑得慢，是让它跑得对。笼子里面的 AI 不是更弱，是更可靠。