Theo 如何评估 AI 智能体 Skills：Matt Pocock 的集合与 PStack

我关注 Matt Pocock 的工程师 AI skills 集合已经很久，却一直没有深入研究。起初我不太在意，过去一周才尝试了其中几个。我也研究了 Lauren，也就是 Potato，制作的 PStack；我一直很欣赏她在 React 编译器上的工作。

我检查了两个集合中的大多数 skill，挑选适合自己工作的部分，并在实际工作中使用。许多 skill 仓库都不值得整套安装。这两个集合包含有用的想法，但如何挑选和改造它们，与文件本身同样重要。

我的第一条原则是不要盲目照搬别人的配置。把它当成灵感来源，为自己实际从事的工作建立系统。如果不了解就复制整套配置，学到的东西很有限；弄清某条指令为何有效，才能帮助你设计自己的方案。

我先让智能体检查我在主要机器上的使用记录，将其与 PStack 比较，按适合程度和潜在收益给 skills 排名。它生成了一份带简短理由的报告，列出 interrogate、blast radius、technical writing、arena 和 prove it works 等候选项，供我进一步检查。

吸引我深入研究的是 unslop。我看过用它写出来的文字，觉得比智能体常见的泛泛之谈自然。在看具体内容之前，有一点值得注意：skill 的描述帮助智能体决定何时加载这个 skill。

我把描述看作触发条件，而不是对 skill 所有功能的完整介绍。它就像视频缩略图，要让合适的人找到内容。在我展示的系统中，模型首先看到名称和描述，判断相关后才加载 Markdown 指令。

Unslop 要求智能体先找出模式，再在保留原意和语气的前提下改写，加入表达风格，最后自查。目的不仅是删除常见的 AI 套话，还包括使用具体反应、变化句子节奏和补充细节，避免语言空洞乏味。

这个 skill 指出了夸大其词、缺少上下文的名称罗列、表面化短语和过度宣传等问题。它还要求语言更直白，并提醒不要滥用破折号。展示错误写法和更好的写法可以帮助模型学习，但示例无法预见所有问题。

我最喜欢的一条是说清楚事物做了什么。不要含糊地说数据库“近在手边”，而应指出可观察的行为，例如某个方法返回的具体字符串。如果一句话可以原封不动地放进任何项目的文档，就应该想想它是否真的告诉读者这个项目的任何信息。

为了演示，我让智能体解释 T3 Code 是什么以及为什么有人会使用它。我还打开一个有关应用构建的旧会话：它直接列出完成的工作、尚未验证的事项和需要采取的行动。这种清楚、容易扫读的回答正是我想要的。

我又在没有这些 skills 的 ChatGPT 中提出大致相似的问题，进行比较。我觉得 unslop 版本更易读，尤其是它给出了具体能力，而不是堆砌修辞。这只是我的非正式比较，并非针对所有提示词或模型的受控研究。

这一体验让我继续研究 PStack 的其他内容，也回头看 Matt 的集合。他的 engineering 目录包含代码审查、调试、领域建模、访谈、实现、测试和规划等 skills。我想先理解每个 skill 的作用，再把它加入自己的配置。

Grill-with-docs 短得令人惊讶：它启动一场访谈来打磨计划，并借助其他 skills 构建领域模型和决策记录。有些 skill 禁止模型自行调用，需要用户明确触发；我查看的版本中，diagnosing bugs 等其他 skill 则可以在合适的任务中由智能体调用。

Grilling skill 把设计视为一棵决策树，分轮提问，先处理前置条件已经确定的决策，直到用户和智能体形成共同理解。我不太喜欢其中部分写作风格，但这个工作流程很有意思，值得亲自试试。

为了快速实验，我把 grilling skill 的文本直接复制到提示词里，没有安装它，然后让智能体针对我的 Lakebed 项目向我提问。这是试用纯文本 skill 的简单办法；如果 skill 依赖脚本或其他文件，也需要提供这些依赖。

第一轮运行发现项目指引已经过时，代码库中还有相互竞争的执行模型。它接着询问用户是谁、谁付费、下一个里程碑是什么，以及 capsule 是规范还是实现细节。这些问题触及真正需要决定的事情，而不是只让我重复仓库中已有的事实。

我用另一个模型执行同一任务，得到的问题涉及 Lakebed 的用途、主要客户、自治的含义以及 capsule。更高推理强度的运行还在后台做了调查。简短的答案选项让我可以快速回复多个问题，不必依赖繁琐的提问界面。

回答过程中，我澄清了产品用户、智能体应控制的事项，以及本地开发和托管系统的边界。我也发现现有指引存在冲突：我希望尽可能简单，同时在有益时进行重写。仅仅第一轮就让我意识到项目需要整理。

Matt 的 teach skill 描述了一种跨会话保留状态的学习工作区。集合里还有用于寻找合适流程的 ask-matt、推动问题在不同阶段流转的 triage，以及 improve-codebase-architecture；后者可以使用共享的设计术语，并以 HTML 报告展示候选改进。

区分用户调用和模型调用很有用：前者像我主动选择的操作，后者则能在任务合适时引导智能体。我自己觉得调试 skill 很有帮助；wizard 也很吸引我，因为它可以引导人完成智能体无法自行执行的步骤。

我把 skill 文件放在管理多台机器的 fleet 仓库中。视频里我让智能体检查 wizard 是否已安装，并把新加入的机器也考虑进去。我就是这样改造并分发自己想要的部分，而不是原封不动地采用整套集合。

Matt 文档中的主要流程把访谈和决策记录连接到规格、任务单、实现和代码审查。其他 skills 涉及梳理模糊想法、用 wayfinder 规划大型工作、制作可丢弃的原型，以及从一手来源研究答案。这个集合不只是一个提示词。

我也喜欢领域建模和共享词汇。我一直与智能体一起记录项目专用术语和词汇表，因此把这种方法包装成 skill 很合理。我有点想把它们全部装上，但还是更愿意保持现有配置精简，只提取真正需要的部分。

回到 Lakebed 访谈，智能体询问哪种简单性最重要、平台必须支持哪些应用、开发者和智能体如何分工，以及获得授权的智能体是否可以采取不可逆操作。它还问到了付款和本地模拟。我经常不同意建议答案，但这正有价值：目的是暴露需要决定的问题，而不是接受默认选项。

我注意到，相比同一项目的旧会话，fleet 会话中较新的回答更容易读。智能体直接解释了为什么之前没有安装 wizard，然后完成安装。这只是个人观察，但写作上的差异确实让我更愿意阅读报告。

我希望 T3 Code 有一个跨机器 skill 管理器，可以批量启用或禁用 PStack、Matt 的 skills 这样的分组，也能控制单个条目。这些文件很多都在规定思考流程。我不想让它们规定我的每一步，但愿意借用 grilling、wizard 和架构整理等有用方法。

Writing-for-agents 吸引我，是因为智能体给其他智能体写的指令也可能很差。更好的指导有助于编写 skills、项目 Markdown 或子智能体提示词。Wait-what 是一个简短的用户调用 skill，用于要求智能体把没讲清楚的回答解释得更简单。

一次要求语言更简单可以改善当前回答，却不一定解决后续的术语问题。Matt 的文档还建议通过领域建模访谈，提前建立共同语言。尚未打好这一基础时，wait-what 就很有用。

Writing-for-agents 讨论了上下文指针：用简短文字告诉智能体何时、到哪里寻找额外材料。Skill 描述和智能体指令文件中的文档链接都是例子。如果必要材料藏在措辞含糊的指针后面，智能体可能无法在恰当的时候找到它。不过，我觉得这段解释本身不如 PStack 的文字易读。

我尝试了一个 AI 文本检测器，并猜测这些 skill 文件的写作方式，但检测结果不能证明作者是谁。基于阅读体验，我能说的是：我个人觉得 PStack 的文字更容易理解，它的工作流也更适合我的日常工作。

Arena 是我喜欢的一个 PStack skill。它针对同一任务并行运行多个尝试，通读并比较候选方案，选出一个基础版本，吸收其他方案的优点，再验证结果。它会跟踪各阶段，避免步骤悄悄遗漏；但反复运行会消耗大量推理预算，我使用它已经花了数百美元。

PStack 的一个限制是部分内容与 Cursor 绑定得很紧。我希望有人把这些想法做成更通用的版本。它的 bro skill 要求用普通语言重新简单说明，功能与 Matt 的 wait-what 很相似；展示的版本也需要手动调用。

Blast-radius 要求智能体查找一项改动可能在其他地方造成的破坏，并通过测试关键事实，而不是相信一份看似有说服力的说明。我多次使用它，发现过一些后来可能很难处理的问题。它还通过 unslop 整理回答，让结果更容易读。

Show-me-your-work 为长期或无人值守的运行提供了另一个想法：用 TSV 文件记录可审阅的决策轨迹。每行记录一项决定或检查点、原因、证据和结果。纠正错误时新增一行，可重复执行的证据能帮助审阅者理解工作，而不必重建整个对话。

这次介绍变成了我实际工作过程的演示：阅读 skills，尝试几个，再挑选适合自己做事方式的部分。从小处开始很有用。仅仅 unslop 就改变了我阅读智能体回复的意愿，但对其他人来说，第一个最有价值的 skill 可能不同。

可以让智能体结合你的使用历史比较这些集合，但安装前要亲自阅读 Markdown。选出自己需要的内容，用合适的方式管理，再根据经验调整。个人仓库是一种选择；安装数百个陌生 skills 不能代替理解。

不要害怕修改智能体配置中的 Markdown 文件。根据我的经验，调整它们帮助我并行完成更多工作，同时减少出错。探索 Matt 的集合和 PStack，亲自尝试，留下喜欢的部分，舍弃不适合的部分，也可以自己制作 skills。