SSD 实战拆解Claude Code 里用 Skills 把 vibe coding 驯化成工程化开发【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills过去一年vibe coding从程序员的自嘲变成了真实工作方式把需求丢给对话式编码代理看它一路狂奔地写代码、改界面、修 bug。这种模式的爽感毋庸置疑但问题同样明显——没有需求边界、没有验收标准、没有过程痕迹Agent 的自由度越高返工和烂尾的风险就越大。于是社区开始讨论一个词SSDSpec-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 progresskeep investigating这类说法除非被锐化成一个可验证的结果否则不予通过。这就是规范驾驶的第一道闸门在 Agent 出发之前先把终点坐标定死。二、Skills 如何承载规范路由、验证与人工卡点设计有了 SSD 的理念下一个问题是规范放哪里社区对 Skills 的共识是它是可封装、可验证、按需加载的标准作业模块区别于又臭又长的 Prompt——Prompt 是一次性的上下文灌输Skill 是可持续沉淀的工程资产。结合本仓库的真实实现Skills 承载规范靠的是三个机制。2.1 路由用元数据做确定性触发一个 Skill 的目录结构在 skill-creator 里被定义为Anatomy of a Skill必选的SKILL.mdYAML 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.pyfrontmatter 只允许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 找到 specnotion-fetch 拉取全文 2) 解析需求与歧义reference/spec-parsing.md 3) 创建实施计划Notion:notion-create-pagesquick 或 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.mdSpec 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-implementationSkill 开始。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考