8.0
热点
AI SCORE
编程提效2026-09-15 06:36
Claude Code 技能组合：从想法到完整功能的实战流程
dev.to · AI#Claude Code#AI编程#开发者工作流
Editor brief · 编辑速览
通过真实案例演示如何将 Matt Pocock 技能集、Ponytail、UI/UX Pro Max 等多个 Claude Code 技能串联成完整开发工作流。
我试用过很多 Claude Code 技能，其中一些组合起来使用时特别有用。
不是因为它们神奇地让模型变得更擅长编码，而是因为它们帮助解决了编码周围那些烦人的部分：弄清楚你实际想要什么、避免不必要的复杂性、保持设计的一致性，以及记住你做到哪里了。
所以我不打算简单地列出这些技能，而是想展示一个实际的例子。
想象我们要在一个书签管理器中添加 AI 生成的收藏夹。用户粘贴一个链接，应用判断它应该属于哪里，如果还没有合适的收藏夹的话，可能还会创建一个。
想法很简单，但下面隐藏着大量需要决策的地方。
我们将使用一些技能来处理这些决策、构建功能，以及让以后回来继续工作时更容易。
你需要安装 Claude Code 和你想使用的技能。每个仓库都有自己的安装说明，所以按照那些说明来，不要假设它们都使用相同的设置。
这里涉及的技能包括：
Matt Pocock 的技能：用于追问（grilling）、领域建模和交接。
Ponytail：用于保持实现简洁。
UI/UX Pro Max：用于设计指导和持久的设计系统。
Hallmark：用于更独特的界面结构。
i-have-adhd：用于让当前任务和下一步行动更容易跟踪。
Caveman：用于更简洁的工作对话。
你不需要全部使用它们。关键是让每个技能有自己明确的职责。
我要做的第一件事不是让 Claude 实现这个功能。
"添加 AI 生成的收藏夹"听起来足够具体，直到你开始思考当 AI 不确定时应该发生什么、收藏夹已存在时该怎么办，或者用户已经手动整理过时该怎么办。
这就是 grill-me 的用武之地。
它使用底层的追问技能，把讨论变成一棵决策树。不是问一长串不相关的问题，而是问那些现在就能回答的问题，然后用这些答案来决定接下来需要问什么。
从一个类似这样的开场白开始：
/grill-me
我想给我的书签管理器添加 AI 生成的收藏夹。
用户应该能够粘贴一个 URL，然后应用建议或选择一个合适的收藏夹。
在实现任何东西之前，先帮我理清行为。
检查现有代码库以获取你可以自己确定的事实。
问我产品决策方面的问题，而不是你能在代码里找到的东西。
重要的一点是 Claude 应该检查项目，而不是让你解释每一个现有的函数。
它可能会发现：收藏夹已经有创建函数、书签可以属于多个收藏夹，或者已经有一个现有的元数据获取管道。
这些都是关于代码库的事实。
而问你的是诸如此类的问题：
AI 应该自动应用建议还是先询问？
AI 是否应该优先选择现有收藏夹？
允许创建新的收藏夹吗？
AI 是否可以重新整理用户已经排好序的书签？
这些是产品决策。
假设你决定 AI 应该优先选择现有收藏夹，只在没有合理匹配时才创建新的。
现在又有了一个新问题：什么才算"合理匹配"？
也许你想要一个置信度阈值。也许你宁愿让 AI 建议一个新的收藏夹，然后让你批准。也许用户应该能够完全关闭自动创建功能。
追问工作流程有用的原因在于，这些问题依赖于之前的决定。在决定是否允许自动创建之前，花十分钟讨论自动创建收藏夹的删除行为是毫无意义的。
继续下去，直到重要的分支都被解决了。
对于一个小型工具来说，这可能过程过于繁琐。但对于一个有多种可能行为的功能来说，它可以避免在实现进行到一半时出现"好吧，那不是我的意思"的情况。
如果这个功能不仅仅是 一个快速实验，我建议使用 grill-with-docs 而不是普通的追问会话。
这将结构化访谈与领域建模结合在一起，所以重要的术语和决策不会消失在聊天历史中。
/grill-with-docs
帮我定义这个书签管理器中的 AI 收藏夹功能。
首先检查现有代码和文档。
澄清重要的领域概念和行为。
保持文档专注于那些我以后回到这个项目时仍然重要的决策和术语。
我喜欢这种领域建模方法的一点是，它挑战模糊的术语。
例如，"收藏夹"在这个应用中实际上是什么意思？
它是一个用于书签的文件夹吗？一种类似标签的分组？一个书签可以属于多个收藏夹吗？AI 生成的收藏夹与手动创建的收藏夹不同吗，还是唯一的区别是创建方式？
这些区别很重要，因为它们影响数据模型和行为。
该技能可以维护一个 CONTEXT.md 术语表来记录领域术语。那个文件旨在解释事物的含义，而不是成为一个庞大的实现规范。
它还可以创建 ADR（架构决策记录），用于真正值得保存的决策。
例如，如果你决定：
AI 建议永远不应该在没有批准的情况下修改手动整理过的书签。
如果这影响了系统的多个部分，而且对以后阅读代码的人来说会很意外，那么这可能值得记录下来。
这种区分很有用：
术语表："收藏夹"是什么意思？
ADR：我们为什么决定 AI 不应该自动重新整理手动排序的书签？
并不是每个小决定都需要一个 ADR。目的是保存那些否则很容易丢失的推理过程。
现在行为已经更清楚了，很容易想让 Claude 把整个东西都构建出来。
在这样做之前，我会引入 Ponytail。
它的总体理念是像一个最懒惰的有能力的高级开发人员那样思考。
不是那种"做得很烂"的懒。而是：
当项目已经有我们所需的大部分东西时，为什么要创建六个抽象层和一个新服务？
让它先审查计划：
使用 Ponytail 审查这个功能的实现计划。
寻找可以重用的现有代码、平台功能或依赖项。
识别不必要的抽象或基础设施。
推荐满足需求的最小实现方案。
不要简化掉验证、安全性、错误处理或我们商定的行为。
对于我们的书签管理器，也许应用已经有：
一个 URL 元数据获取器。
一个收藏夹创建函数。
一个书签到收藏夹的关系。
一个现有的 AI 提供者抽象。
如果是这样，我们可能不需要一个单独的"AI 收藏夹编排服务"，带有自己的插件架构和十二个接口。
也许我们只需要在现有的保存流程中添加一个分类步骤。
这就是我想要的简化。
Ponytail 还包括相关技能，如 ponytail-review、ponytail-audit 和 ponytail-debt。
实现功能后，我会用审查来查看 diff 中的不必要复杂性：
对 AI 收藏夹功能的更改使用 ponytail-review。
寻找不必要的抽象、重复的逻辑，以及可以用现有项目功能替换的代码。
保留商定的行为和正确性要求。
债务技能对于有意识的捷径来说很有意思。
也许我们决定现在一个简单的分类调用就够了，但我们知道如果书签库增长到数万条，可能需要一个更复杂的系统。
这不意味着我们今天需要构建复杂的系统。这意味着我们可以记录为什么选择简单方案，以及什么会促使我们重新考虑它。
行为确定之后，我就开始做界面。
UI/UX Pro Max 给 Claude 一个可搜索的设计知识库，涵盖风格、色板、排版、UX 指导、图表选择以及特定技术栈的实现建议。
在我们的例子中，我会在接触 UI 之前让它确定设计方向：
使用 ui-ux-pro-max 为这个书签管理器中的 AI 收藏夹功能确定设计方向。
应用使用 React 和 Tailwind，支持暗色模式。
我希望这个功能感觉像是现有应用的自然组成部分，
而不是一个独立的 AI 仪表板。
推荐交互模式、排版、颜色、间距和组件指导。先不要实现任何东西。
我发现特别有用的部分是持久化设计系统的能力。
这里我要引入 Hallmark。
Hallmark 专注于结构多样性，而不仅仅是换颜色和字体。它的目标是避免为所有页面重复使用同一种通用的 AI 生成页面构图。
它有构建、审查、重构和研究设计的工作流。
对于我们的书签管理器，我会给它一个与 UI/UX Pro Max 不同的任务：
使用 Hallmark 来设计 AI 集合的交互方式，
遵循我们刚刚确立的设计方向。
保持约定的调色板和字体排版。
专注于清晰、有特色的布局和交互流程，
适配现有的书签管理器。
不要用不同主题替换设计系统。
不要重构应用无关的部分。
UI/UX Pro Max 建立实用的设计基础。
Hallmark 则负责实际的构图和结构。
我们不希望两个 skill 各自独立决定应用的外观，然后在设计系统上产生冲突。
当有参考时使用 study 模式
Hallmark 的 study 模式也很有意思，如果你有一张喜欢的界面截图或 URL。
你可以让它分析设计的"DNA"：布局结构、字体排版、色彩方向和视觉层次。
使用 Hallmark study 模式分析这张截图。
解释使其生效的布局结构、间距、字体排版和视觉层次。
我想把那些原则用在我的书签管理器上，
而不是复制原始设计。
这是一种从参考中学习的有用方式，而不只是让 Claude 复刻它。
Hallmark 也有针对组件的工作流，所以你可以让它改进一个模态框或按钮，而不会把请求变成整页重构。
此时，功能正在实现中，这是几个小型 skill 可以让日常工作体验更好的地方。
i-have-adhd 是一个输出风格 skill，它改变 Claude 展示工作的方式。
它会尽量优先展示下一个动作，把多步骤工作拆分成更小的任务，保持当前状态可见，并抑制不相关的跑题。
/i-have-adhd
帮我完成这个功能。
显示当前任务、已完成的部分，
以及单一的下一个动作。把不相关的想法放在后面的部分。
你不会得到一篇关于接下来可能发生的事情的巨大解释，而是更接近于：
第 3 步，共 5 步，已完成：集合分类已实现。下一步：测试 AI 返回无效集合 ID 时会发生什么。依赖清理可以等一下。
当我同时在多个项目之间切换、需要知道现在该做什么的时候，这种方式正是我觉得有用的。
它仍然允许在你要求时提供更完整的解释，所以它不会为了让每个答案都变短而牺牲有用性。
Caveman 针对的是一个略有不同的问题：减少不必要的废话。
它的基本 skill 会压缩 Claude 的解释，同时保留重要的技术细节，如代码、命令、错误信息、确切名称、数字和改变指令含义的词语。
本次实现会话使用 Caveman lite 模式。
保持解释简洁，但保留确切的命令、
错误信息和重要的技术细节。
所以不是一篇解释一个小 React 问题的大文章，你可能会得到：
每次渲染新建对象引用。Prop 身份变化。记忆化稳定值。
项目有不同的模式，包括 lite、full 和 ultra，并且可以在事情模糊、安全关键或需要适当解释时切换回更清晰的叙述。
它还有相关的 skill 用于简洁的提交、审查、记忆文件压缩和 token 统计。
值得记住的一件事：更少的输出 token 并不意味着总会话成本按相同比例减少。指令本身有开销，输入和推理 token 仍然计入。
基本的简洁输出 skill 也独立于仓库更大的可选代理/引擎和云相关工具。在安装整个工具栈之前，我会先区分它们。
现在想象功能大部分完成了，但集成测试失败了，而你今天要到此为止。
这就是 Matt Pocock 的 handoff skill 的用武之地。
它在操作系统临时目录中创建一个 Markdown 交接文档，以便另一个会话或代理可以获取重要的上下文。
我会这样用：
/handoff
AI 集合功能已大部分实现。
保留：
- 当前任务和已完成的工作。
- 我们关于集合行为做出的决定。
- 数据模型及选择它的原因。
- 失败的集成测试。
- 单一的下一个动作。
在有用时引用现有的计划、规格、ADR 或提交，
而不是把所有内容都复制到交接文档中。
这个想法是在不将整个聊天记录转储到下一个会话的情况下保留重要的状态。
这是上下文可移植性，而不是神奇的上下文窗口压缩。
交接文档仍然可能丢失细节，所以如果被拒绝的方案背后的推理很重要，我会明确要求保留它。如果对话中包含任何敏感内容，在分享文件之前我也会检查一下。
handoff 保留重要的上下文。
i-have-adhd 让这些上下文在你回来时更容易执行。
在下一个会话中，我会让 Claude 指向生成的交接文件并说：
/i-have-adhd
读取交接文件并帮我恢复。
显示当前状态，然后给我第一个具体动作。
把不相关的想法放在后面的部分。
这应该可以更容易地重新打开一个项目，避免在会话的第一部分重建昨天发生的事情。
对于同时进行多个项目的人来说，这听起来非常有用。
以下是我会尝试的顺序：
你不一定每次都要用所有阶段。
如果我在做一个很小的工具，我可能只用 Ponytail 和一个简洁的输出风格。
如果我在构建一个有复杂行为的功能，我会花更多时间盘问和记录决定。
如果我在做前端，我会使用设计 skill，但不会让两者都独立发明整个视觉方向。
有用的部分是给每个 skill 一个明确的职责。
避免把工作流程当作强制性过程。整个目的是让构建东西更容易，而不是把一个小功能变成涉及六个代理和一堆文档的仪式。
组合方式是：盘问 → 文档化 → 简单实现 → 交接。
结果是让你从"我有一个想法"到"我知道我要做什么"，而不丢失那些决定或意外地把一个小项目变成一场大型架构练习。