Vibe Coding 用这个 Skill 就够了？聊聊 mattpocock/skills 的轻量开发工作流

最近一个月，我一直在尝试用 Skill 优化自己的开发效率和质量，最后反复使用下来，最有感的一套是 mattpocock/skills。它让我重新思考一个问题：Vibe Coding 一定要配一套很重的项目管理框架吗？

对大多数个人开发者和中小型项目来说，答案可能是不一定。很多时候，我们缺的不是一套完整的项目管理系统，而是在关键节点拥有一个可复用的工程动作：先把需求问清楚，先验证交互，先查官方资料，先复现 Bug，或者在交付前做一次代码评审。

什么是 mattpocock/skills？

mattpocock/skills 是一套面向 AI 编程的可组合工程技能库。它把需求澄清、技术调研、原型设计、代码实现、测试驱动、Bug 诊断、会话交接和代码评审等工作，分别封装成可以阅读、修改和调用的 Skill 文件。

这里的 Skill 不是一个必须完整接入的运行时，也不是一个替你管理所有项目状态的平台。更准确地说，它是一组写给 AI 编程助手使用的工作说明：告诉 AI 什么时候使用某项能力、应该先做什么、需要产出什么，以及哪些边界不能忽略。

一句话定义：mattpocock/skills 是把 AI 编程中的工程判断拆成独立 Markdown 技能文件，让开发者可以按任务复杂度自由组合。

它解决的问题很具体：AI 可以很快生成代码，但不一定会主动澄清模糊需求、验证技术假设、补回归测试或整理会话上下文。Skills 把这些容易被跳过的步骤变成了随时可以调用的工具。

为什么 Vibe Coding 不一定需要重型项目框架？

Vibe Coding 的优势是快速试想法。如果每次修改一个小功能，都必须先建立完整目录、经过固定阶段、填写多份规格文件，流程成本可能超过功能本身的价值。

Trellis、BMAD、GSD、Spec Kit 等项目级 AI 工程工作流，通常会提供固定的项目目录、任务阶段、角色分工、规格文件和执行命令。它们更像完整的施工管理系统，适合团队协作、长期项目、统一规范和严格审计。

两种方式并不是谁一定更好，而是抽象层级不同：一个管理项目的完整生命周期，一个提供可以嵌入任意项目的工程动作。

因此，轻量 Skill 不是“没有工程化”，而是把工程化拆成更小的颗粒度。你仍然可以做需求澄清、测试和代码评审，只是在真正需要时才调用对应的能力。

mattpocock/skills 包含哪些核心能力？

这套技能库可以按开发过程分成八类：

1. 需求澄清：用 grill-with-docs 连续提问，明确目标、流程、边界、异常场景和第一版不做什么。
2. 原型设计：用 prototype 先做可观察、可讨论的粗原型，验证页面结构、操作路径和状态模型。
3. 技术调研：用 research 查阅官方文档、源码或 API 资料，把技术结论和依据记录到项目文档。
4. 规格整理：用 to-spec 把模糊需求整理成可执行的验收条件和实现约束。
5. 任务拆分：用 to-tickets 把规格拆成有优先级、可交付、可验证的任务。
6. 代码实现：用 implement 根据规格修改代码，保持改动范围清晰。
7. 测试与诊断：用 tdd 固化行为，用 diagnosing-bugs 复现问题并定位根因。
8. 协作与质量：用 handoff 记录会话上下文，用 code-review 检查代码质量、需求符合度和测试覆盖。

这些 Skill 可以单独使用，也可以组合使用。例如，需求模糊时只调用 grill-with-docs；一个小功能则可以组合 to-spec、implement 和 tdd；从零做产品时，再加上 prototype、research、to-tickets 和 code-review。

核心原则是：先判断当前缺哪一种工程能力，再调用对应 Skill。

需求不清楚时，为什么应该使用 grill-with-docs？

当需求只有一句“做一个资料编辑页面”或“加一个头像功能”时，最适合先使用 grill-with-docs。它的目标不是马上写代码，而是通过连续提问，把用户流程、边界条件、异常场景和 MVP 范围变成一份清晰文档。

一次需求澄清至少应该回答这些问题：

• 谁会使用这个功能，完成任务的主流程是什么？
• 哪些输入是必填的，空数据、重复提交和错误输入怎么处理？
• 成功、取消、加载中和失败分别显示什么状态？
• 第一版明确不做哪些功能？
• 项目里有哪些术语、已有约束和技术决策需要沿用？

比如“做头像上传”至少可能包含选择图片、格式检查、大小限制、裁剪、取消、保存、上传失败和重新上传。如果 AI 直接根据一句话开始实现，很可能只完成“选择文件并上传”这一条路径。

所以，grill-with-docs 的价值是让 AI 先基于清晰文档执行，减少“做出了功能，但不是我要的功能”的返工。

设计或交互不确定时，为什么应该先使用 prototype？

当你还不知道页面怎么排、操作路径是否顺手，或者不确定某个状态是否需要独立设计时，应该先使用 prototype，而不是直接写正式代码。

以头像上传为例，粗原型可以先验证这条路径：

1. 点击上传区域并选择图片。
2. 进入裁剪状态，确认或取消本次裁剪。
3. 保存成功后展示新头像。
4. 上传失败时展示原因，并允许重新尝试。

原型阶段重点观察的是页面结构、状态切换和用户能否理解下一步，而不是组件抽象、数据库设计或视觉细节。原型的价值不是直接上线，而是用低成本回答高价值的设计问题。

技术方案不确定时，为什么应该先使用 research？

涉及第三方服务、框架限制、数据迁移、版本兼容性、权限模型或性能边界时，应该先用 research 研究，再开始实现。

一次有效的技术调研应该包含：

• 明确要回答的问题和已知约束。
• 优先查阅官方文档、源码、API 参考和版本说明。
• 对关键结论进行验证或对比，而不是只凭模型记忆。
• 记录选择某个方案的依据、限制和待确认事项。
• 把结论写入 README、技术说明或 ADR，方便后续会话复用。

例如，要把文件上传切换到某个云存储服务，不能只问 AI“帮我接入这个 SDK”。还应该确认签名上传、文件大小、MIME 类型、权限、回调、失败重试和 SDK 版本。先研究再实现，通常比写到一半才发现 API 或权限模型不支持更省时间。

小功能如何组合 to-spec、implement 和 tdd？

实现一个边界清楚的小功能时，可以使用 to-spec、implement 和 tdd 三件套：先定义完成标准，再修改代码，最后用测试固定行为。

以“修改昵称”为例，可以这样向 AI 下达任务：

先用 to-spec 明确修改昵称的验收条件，再用 implement 和 tdd 完成实现。昵称长度限制为 2 到 20 个字符，不能包含敏感词，保存成功后返回最新昵称，页面显示更新后的结果。

三个 Skill 的职责不同：

这样做的好处是，需求、实现和验证之间有清晰的对应关系。TDD 不是要求每个临时 Demo 都建立完整测试体系，而是把最重要的行为先固定下来。

小 Bug 为什么应该先诊断，再修复？

遇到 Bug 时，应该组合 diagnosing-bugs 和 tdd，先建立稳定复现路径、定位根因，再补回归测试和修改代码。

例如，“头像为空时保存资料会报错”不应该直接对 AI 说“修一下”。更稳定的请求方式是：

用 diagnosing-bugs 和 tdd 修复头像为空时保存资料报错的问题。先复现，确认错误发生的调用路径和根因；再补一个回归测试，最后修改实现并运行相关测试。

诊断过程通常要回答：

1. 问题是否可以稳定复现？最小复现步骤是什么？
2. 错误发生在哪个边界条件、调用链或数据状态？
3. 当前修复是否只掩盖了表面异常，是否会影响正常路径？
4. 回归测试能否在未来阻止同一个问题再次出现？

性能变慢、接口偶发超时和数据偶尔不一致，也应该先诊断，不要让 AI 凭感觉批量改代码。诊断的目标是缩小问题范围，TDD 的目标是把错误行为固定成可重复验证的测试。

从零完成第一版时，如何串起一条轻量流程？

从零做一个小产品时，可以把这些 Skill 组合成一条从 MVP 到交付的轻量流程：

1. grill-with-docs 确定 MVP：澄清用户目标、主流程、边界和第一版范围。
2. prototype 验证关键交互：先确认页面结构、状态和操作路径。
3. research 确认技术方案：针对第三方服务、框架限制和兼容性查资料并记录依据。
4. to-spec 固化需求：把讨论结果转成验收条件和实现约束。
5. to-tickets 拆分任务：按优先级拆成可以独立交付和验证的工作项。
6. implement 逐项实现：每次只处理一个边界清楚的任务。
7. tdd 补测试并验证：用测试覆盖关键成功、失败和边界路径。
8. code-review 交付前检查：检查规范、需求符合度、潜在回归和测试覆盖。

这不是必须完整执行的固定仪式。如果只是改一个文案，可能只需要 implement；如果是改登录权限，则应该增加 research、tdd 和 code-review。流程长度应该由风险、寿命和协作复杂度决定。

会话切换时，handoff 能解决什么问题？

handoff 是会话之间的交接文档机制。一次会话做不完时，它可以整理当前任务、已完成内容、测试结果、未提交改动、关键决策和下一步计划，帮助新的 AI 会话快速恢复上下文。

一份实用的 handoff 文档至少应记录：

• 任务目标和当前范围。
• 已完成的文件与功能。
• 已运行的测试、结果和未解决的失败。
• 未提交的改动和可能影响的文件。
• 已确认的技术决策、限制和待办事项。
• 下一步建议，以及接手者应该先阅读的 Spec 或 ticket。

需要注意，handoff 只是交接文档，不会自动启动下一个 agent，也不会自动复制代码。接手的 AI 仍然需要读取 handoff、Spec、ticket 和项目当前状态，再继续工作。

使用 mattpocock/skills 有哪些限制？

mattpocock/skills 能降低工程动作的调用成本，但它不能替你承担工程责任，也不会自动保证 AI 的结论和代码正确。

常见限制包括：

• Skill 是工作说明，不是权限系统；敏感操作仍需要人工确认和合理的工具权限。
• research 能要求优先查资料，但不能保证资料版本正确，关键结论仍要人工核对。
• tdd 能推动测试先行，但测试本身也可能写错，不能只追求覆盖率数字。
• code-review 可以提供审查意见，但不能替代安全审计、性能压测和领域专家评审。
• Skills 之间可能产生重复文档；项目需要约定 Spec、ticket、handoff 的存放位置和命名方式。
• 如果上下文、项目状态或验收标准不清楚，组合更多 Skill 也不一定能得到更好的结果。

因此，Skills 的正确用法不是“让 AI 自动跑完整流程”，而是把关键判断显式化，并在高风险节点保留人的检查。

Vibe Coding 用 mattpocock/skills 就够了吗？

对大多数个人开发者和中小型产品来说，mattpocock/skills 通常已经足够覆盖日常 Vibe Coding 所需的工程环节：

但“够用”有边界。如果是多人长期维护的核心系统，或者涉及支付、身份认证、医疗、隐私数据和公共基础设施，仍然需要更完整的项目治理：架构设计、权限控制、CI/CD、安全扫描、可观测性、变更审计和发布回滚都不能省略。

常见问题

mattpocock/skills 适合哪些人？

它适合希望用 AI 加速开发、但又不想为每个小任务接入完整项目框架的个人开发者和小团队。它尤其适合原型、个人工具、短周期产品和边界清楚的功能迭代。

mattpocock/skills 和 Trellis、BMAD、GSD、Spec Kit 有什么区别？

核心区别是抽象层级。Trellis、BMAD、GSD 和 Spec Kit 等工具通常组织完整的项目流程与协作规范；mattpocock/skills 提供可以独立调用的工程 Skill。前者更适合统一治理，后者更适合按需组合。

grill-with-docs 会直接帮我写代码吗？

它的主要职责是澄清需求并沉淀文档，不是直接完成正式实现。需求明确后，可以再使用 to-spec、implement 和 tdd 推进开发。

prototype 做出的原型可以直接上线吗？

通常不应该直接上线。原型用于低成本验证页面结构、操作路径和状态模型；正式上线前仍要重做或整理组件、数据、权限、错误处理、测试和部署配置。

handoff 会自动启动新的 AI agent 吗？

不会。handoff 只负责生成会话交接信息，不会自动启动下一个 agent，也不会自动复制代码。新的会话需要读取交接文档和项目当前状态后继续工作。

Vibe Coding 什么时候应该使用更重的项目框架？

当项目需要多人长期协作、严格的需求追踪、统一的角色分工、审批审计或稳定的交付节奏时，更完整的项目级工作流通常更合适。选择标准不是“框架越轻越好”，而是流程成本是否匹配项目风险。

总结：Vibe Coding 的关键是按场景调用 Skill

mattpocock/skills 是一套面向 AI 编程的可组合工程技能库。它把需求澄清、原型设计、技术调研、规格整理、代码实现、测试、Bug 诊断、会话交接和代码评审拆成独立能力，让开发者可以根据任务需要自由组合。

它的价值不在于替你接管整个项目，而在于把真正需要工程判断的地方变成一组随时可以调用的工具：需求模糊时先问清楚，设计不确定时先做原型，技术不确定时先研究，小功能用规格、实现和测试推进，Bug 先诊断再修复，交付前再做评审。

所以，Vibe Coding 用这个 Skill 就够了吗？对大多数个人开发者和中小型产品来说，够用。不是因为它包含了所有工程能力，而是因为它让你可以用更低的流程成本，补上 Vibe Coding 最容易缺失的工程环节。

一句话记住：不是选择更大的工具箱，而是在关键时刻调用正确的 Skill。