企业官网建设流程全解析

SSD 实战拆解：Claude Code 里用 Skills 把 vibe coding 驯化成工程化开发

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills

过去一年，"vibe coding"从程序员的自嘲变成了真实工作方式：把需求丢给对话式编码代理，看它一路狂奔地写代码、改界面、修 bug。这种模式的爽感毋庸置疑，但问题同样明显——没有需求边界、没有验收标准、没有过程痕迹，Agent 的自由度越高，返工和烂尾的风险就越大。于是社区开始讨论一个词：SSD（Spec-Driven Development，规范驱动开发）。在 Claude Code 这类 Agent 生态里，SSD 的核心思路是把 vibe coding 的自由探索，约束到一套结构化的"先规格、后计划、再实施"流程中。而承载这套规范的最佳载体，正是近半年热度直追 MCP 的 Skills 机制。

本文将以一个真实维护的 Skills 目录仓库为样本，拆解 SSD 为什么需要"规范驾驶"、Skills 如何用路由、验证与人工卡点三个机制把规范落地，并给出一个可以直接复制的端到端工作流。

一、SSD 是什么：为什么 vibe coding 需要"规范驾驶"

vibe coding 的本质问题不是"AI 写代码不够快"，而是"缺少一个可校验的契约"。没有契约，Agent 只能靠对话上下文里的即兴理解行事——需求模糊它就猜测，边界不清它就扩大，做完没有验收它就自认为完成。这在原型阶段无伤大雅，一旦进入多人协作、需要持续维护的工程阶段，就成了灾难。

SSD 的解法非常朴素：让 Agent 在动手之前，先经历一条强制链路——规格（Spec）→ 实施计划（Plan）→ 任务拆分（Tasks）→ 验收（Acceptance）→ 实施（Implementation）。这条链路把"感觉对了"换成"证据够了"。

在仓库中，define-goal 这个 Skill 把"定义目标"本身做成了可校验的动作。它明确要求目标必须回答五个问题：完成时什么具体事实为真？用什么证据证明？量化或二元的成功阈值是多少？范围边界在哪？什么情况应该停下问人？仓库里给了一组极有说服力的对照：

好目标：Reduce checkout API p95 latency below 250 ms ... by making the smallest safe server-side change, then verify with npm run test:checkout and the existing local latency benchmark showing p95 under 250 ms across 3 consecutive runs. 坏目标：Make checkout faster.

注意两者差距：好的目标把"快"翻译成了p95 < 250ms + 连续 3 次基准通过 + 指定测试命令，而坏的只有情绪。define-goal 甚至明文拒绝纯活动型目标——"make progress""keep investigating"这类说法，除非被锐化成一个可验证的结果，否则不予通过。这就是"规范驾驶"的第一道闸门：在 Agent 出发之前，先把终点坐标定死。

二、Skills 如何承载规范：路由、验证与人工卡点设计

有了 SSD 的理念，下一个问题是：规范放哪里？社区对 Skills 的共识是，它是"可封装、可验证、按需加载的标准作业模块"，区别于又臭又长的 Prompt——Prompt 是一次性的上下文灌输，Skill 是可持续沉淀的工程资产。结合本仓库的真实实现，Skills 承载规范靠的是三个机制。

2.1 路由：用元数据做确定性触发

一个 Skill 的目录结构在 skill-creator 里被定义为"Anatomy of a Skill"：必选的SKILL.md（YAML frontmatter + Markdown 指令体），加可选的scripts/、references/、assets/资源目录。三层结构对应三层加载时机——元数据常驻上下文、指令体在触发后加载、资源按需读取。这就是社区反复强调的"渐进式披露"：上下文窗口是公共资源，Skill 只在需要时把规范注入进来。

触发机制全部押在 frontmatter 的name和description上。以 define-goal 为例：

--- name: define-goal description: Help the user define a concrete, measurable goal before starting work, especially when they ask to use the goal tool, create a goal, set an objective, clarify success criteria, or turn a fuzzy intention into a quantitative outcome... ---

description同时承担"这个 Skill 做什么"和"什么时候该用"两个职责——SSD 的规范就是通过这种路由设计，在正确的时刻被精确唤醒。而为了防止路由失效，仓库还提供了强制校验脚本 quick_validate.py：frontmatter 只允许name/description/license/allowed-tools/metadata五个字段；name必须是连字符小写且不超过 64 字符；description不得超过 1024 字符且不能包含尖括号。这意味着路由元数据本身是被 CI 化的、可测试的——Skill 即代码，规范即配置。

2.2 验证：把"感觉完成了"换成"证据通过了"

SSD 最关键的工程化动作，是把验收标准变成可勾选清单。在 notion-spec-to-implementation 及其参考文档里，这套验证逻辑层层展开：

• 解析层：spec-parsing.md 规定了从规格里抽取什么——功能需求、非功能需求、验收标准、优先级（P0-P3）、歧义、冲突。特别值得注意的是它对"可测标准"的强制转换：

❌ 不可测：System is fast ✓ 可测：Page loads in < 2 seconds ❌ 不可测：Users like the interface ✓ 可测：90% of test users complete task successfully

• 计划层：standard-implementation-plan.md 给出了实施计划模板的完整骨架：Linked Specification（链接回原规格）、Requirements Summary、Implementation Phases、Acceptance Criteria、Risks & Mitigation、Success Criteria。注意模板强制要求"技术成功标准"和"业务成功标准"分开列出，且技术侧必须是测试覆盖率 > 80%这类可量化项。

• 任务层：task-creation.md 对任务粒度做了硬约束——单任务 1-2 天、单一可交付物、可独立测试；每个任务必须携带验收标准清单、依赖关系、优先级和命名约定（Setup:/Implement:/Integrate:/Test:/Fix:/Refactor:前缀）。这就是把工程师的直觉纪律，翻译成了 Agent 能执行的检查表。

• 评测层：evaluations/README.md 甚至给整套流程配了跨模型评测场景（Haiku/Sonnet/Opus），用"任务标题是否具体可执行""验收标准是否为清单格式"等硬性指标来判定 Skill 行为是否符合预期。

2.3 人工卡点：对 Agent 自主性的刻意收敛

SSD 不是要让 Agent 全自动跑完全程，恰恰相反，它要求在关键节点强制停下、交出决策权。仓库里多个 Skill 示范了这种"人工卡点"设计：

• gh-address-comments：先把 PR 上所有 review 线程和评论编号列出、给用户一份摘要，等用户指定要处理哪些评论之后才动手改代码——Agent 负责枚举与定位，人负责裁决。
• gh-fix-ci：明确"draft a fix plan and implement only after explicit approval"（先起草修复计划，获得明确批准后才实施）；其配套脚本inspect_pr_checks.py在仍有失败项时以非零码退出，可直接接入 CI 做断言。
• security-best-practices：产出安全报告后先让用户阅读，用户批准后才逐条修复，且要求"一次只修一个问题"。

这些卡点的共同模式是：Agent 的自主范围被 Skill 显式收窄——它可以调查、分析、出方案，但写代码、改文件、提 PR 这类有外部影响的动作，必须跨越人工审批线。这是 vibe coding 与 SSD 最本质的分野：前者是"AI 全权代理"，后者是"AI 高速执行 + 人在关键节点把关"。

三、一个可复制的 SSD + Skills 工作流示例

把上面三个机制串起来，就能得到一条可以直接复制到团队里的完整链路。仓库里的 notion-spec-to-implementation 本身就是这条链路的完整实现，其 Quick Start 定义了五个动作：

1) 定位规格：Notion:notion-search 找到 spec，notion-fetch 拉取全文 2) 解析需求与歧义：reference/spec-parsing.md 3) 创建实施计划：Notion:notion-create-pages（quick 或 full 模板二选一） 4) 定位任务数据库、确认 schema，创建任务 5) 双向链接 Spec ↔ Plan ↔ Tasks，持续更新进度

配合 examples/api-feature.md 里的端到端案例（User Profile API），这条链路的工程味道就完全具象化了：

第一步，解析规格。从 spec 中抽取 5 条功能需求、4 条非功能需求（p95 < 200ms、支持 1000 并发、头像 < 5MB、GDPR 合规）、5 条验收标准（AC-1 到 AC-5），并把"响应时间 < 200ms (p95)"这类阈值直接写进技术方案。

第二步，计划分级。简单改动用 quick-implementation-plan.md（Spec + Summary + Tasks + Timeline 四段式）；多阶段功能或迁移用 standard 模板。案例里选择了后者，产出 5 个阶段、12 个工作日、20 个任务的完整计划，每个阶段都带 Goal、Tasks、Deliverables、Estimated effort。

第三步，任务落地。每个任务被写成带 Context / Objective / Acceptance Criteria / Technical Approach / Dependencies 的规格化条目，例如：

"Name": "Setup database schema for User Profile API", "Status": "To Do", "Priority": "High", "Story Points": 3, Acceptance Criteria: - [ ] Migration file created - [ ] Schema includes all required fields - [ ] Indexes on email (unique) and name (search) - [ ] Migration tested on dev database

第四步，双向链接。计划链回规格、任务链回计划和规格、规格页追加"Implementation"章节反向指向计划——SSD 的三件套（Spec/Plan/Tasks）从此不再是三个孤岛，而是一个可导航的活文档。

第五步，进度追踪。progress-tracking.md 定义了完整的任务状态机（To Do → In Progress → In Review → Done → Blocked）、每日更新节奏、velocity 与质量指标，以及 blocker 的登记与升级流程。进度从"感觉在推进"变成"42/56 条验收标准已通过"。

值得一提的是，这套规范并不绑定某一个 Agent。仓库里的 migrate-to-codex 展示了 Claude Code 生态与 Codex 生态之间的 Skills/commands 迁移路径（.claude/commands→ Codex skills、.claude/settings.json hooks→.codex/hooks.json），说明 Skills 目录结构正在成为一种跨 Agent 的标准作业格式——规范写一次，处处可执行。

结语

回到最初的问题：vibe coding 需要"规范驾驶"吗？答案是需要的，但规范的目的不是束缚，而是让自由更贵。Skills 给了 SSD 一个恰到好处的载体：用 YAML frontmatter 做确定性路由，用 spec 解析与任务模板把验收标准物化成清单，用人工卡点守住每一次有外部影响的动作。当 Agent 的每次输出都能被"哪个 spec 的哪条验收标准"回溯，vibe coding 就从一场不可复现的即兴表演，变成了可度量、可审计、可交接的工程流水线。下一个项目的起点，不妨就从拆出一个"spec-to-implementation"Skill 开始。

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills