# Spec 驱动开发（SDD）的三个 Skills：覆盖 Spec→Implement→Verify 闭环

- 来源：meng shao (@shao__meng)
- 发布时间：2026-06-12 08:46
- AIHOT 分数：75
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmqa7y9h20iyrsllds3s2dok3
- 原文链接：https://x.com/shao__meng/status/2065234132431675439

## 精选理由

邵猛把SDD从概念变成三个可安装Skill，特别是第五步用计算机操作验证UI，这招对Rust桌面应用团队是降维打击。做AI coding的可以直接抄作业。

## AI 摘要

邵猛分享 Spec 驱动开发（SDD）方法，用三个 Skills（/write-product-spec、/write-tech-spec、/validate-changes-match-specs）覆盖 Spec→Implement→Verify 闭环。规格分两层：PRODUCT.md（用户故事、不变量）和 TECH.md（架构、实现策略），均放在 specs/<issue>/ 目录，随 PR 提交。五步流程：写产品规格、写技术规格、Agent 按规格实现、一致性校验、计算机操作端到端验证。Skills 可移植，不绑定 Warp。开源仓库 warpdotdev/common-skills，安装：npx skills add warpdotdev/common-skills。

## 正文

Spec 驱动开发 （SDD） 需要这三个 Skills：覆盖 Spec -> Implement -> Verify 闭环

Agent 出错往往是需求理解偏差。解决办法是把规格当作 PR 的一部分，让队友和 Agent 都能对照同一份文档。

规格分两层：
1. 产品规格：PRODUCT.md
做什么，用户视角、用户故事、可验证的产品不变量
2. 技术规格：TECH.md
怎么做，架构、代码位置、实现策略
都放在 specs/<issue>/ 目录，随实现 PR 一起提交、一起 Review。

# SDD 五步流程（包含三个 Skills）

1. 写产品规格（/write-product-spec）
从用户行为出发，写用户故事和详细的不变量（invariants）--即「无论什么情况都必须成立」的规则。可附 Figma、截图等。这些不变量后续可被代码检查，甚至用计算机操作（computer use）验证。

2. 写技术规格（/write-tech-spec）
在同一目录生成 TECH.md，说明架构思路、改哪些文件、实现时要注意什么。这是给 Agent 的「施工图纸」。

3. 让 Agent 按规格实现
理论上任何 Agent、包括推理能力较弱的模型，只要有清晰规格，实现质量都会更稳定。

4. 规格一致性校验（/validate-changes-match-specs）
实现后不能默认「做完了就对」。用 Skill 让 Agent 对照 PRODUCT.md 和 TECH.md 自查，列出与规格不一致之处，再由人决定如何处理。这是规格驱动开发里容易被忽略、但很关键的一步。

5. 用计算机操作做端到端验证
Warp 内部用 Oz 做 UX 验证：在云端沙箱里给 Agent 鼠标键盘权限，模拟真实用户操作。对他们这种 Rust 原生桌面应用尤其必要--单元测试覆盖不了完整交互链路。

# 为什么用这三个 Skills 编码流程

Skills 把「怎么写产品规格」「怎么写技术规格」「怎么校验」固化成可复用指令，不绑定 Warp，流程可移植。

@warpdotdev 开源仓库：warpdotdev/common-skills
安装：npx skills add warpdotdev/common-skills

本质是把人的工程习惯（先 PRD、再设计、再实现、再验收）变成 Agent 可执行的流水线。

### 引用推文

> Zach Lloyd：http://x.com/i/article/2065151123128721408