我最推荐的 4 个 AI 编程 Skills：grill-me、research、diagnosing-bugs、code-review

之前聊到`mattpocock/skills`仓库时，很多读者对`grilling`表示出了兴趣。回头来看，那两篇文章确实写得太简略了——只留下“让Agent持续追问”这个印象，但一次只问一个问题的逻辑、哪些信息该让Agent自己查、什么时候才能开始执行，这些关键细节都没有展开。 所以重新读了一遍仓库里的`SKILL.md`。`mattpocock/skills`把常见工程问题拆成了较小、方便修改、可以组合的Skill：需求含糊就补需求澄清，Bug难查就补诊断流程，准备交付再补代码审查。这种拆法很合实际使用习惯——Codex、Claude Code已经能稳定完成的基础动作，没必要每次重教；哪个环节经常返工，就给哪个环节加一小段流程。 群里讨论时，大家提到的也是类似问题：完整套件容易让小任务背上过重的流程，`grilling`虽然会连续追问，但需求确实能收得更清楚。 除了`grilling`之外，`research`、`diagnosing-bugs`和`code-review`这三个也非常不错，这篇文章都会分享。

grilling 不只是让 Agent 多问几句

前两篇文章里，其实把`grilling`写简单了：让Agent别急着写代码，先多问几个问题。普通Prompt加上这句话也能做到。 当前的`grilling`篇幅不长，但里面把访谈怎么往下走规定得很细。它会沿着决策树往下问，一次只处理一个决定。前面的答案可能改变后面的分支，所以不能一口气扔出十几个问题，让用户像填问卷一样回答。 它还把事实和决定分开。项目用了什么框架、现有接口怎么设计、数据库里有没有某个字段，Agent应该自己读代码和文档。首期做哪个方案、要不要兼容旧行为、愿意承担多少复杂度，则交给用户。双方没有确认已经达成共同理解之前，Agent也不能照着自己的判断开工。

grilling、grill-me 和 grill-with-docs 有什么区别？

`grilling`是可复用的底层访谈Skill，模型可以主动调用，用户也可以直接调用，其他Skill同样能复用。`/grill-me`是更明确的人工入口，本身只负责启动一次`/grilling`会话。 讨论会产生长期使用的领域术语或架构决定时，可以换成`/grill-with-docs`。它还会调用`domain-modeling`：术语确定后写入`CONTEXT.md`，少量难以撤销、以后看起来可能奇怪的决定再记录为ADR。 三者的关系可以这样理解： grill-me ──────────> grilling grill-with-docs ───> grilling + domain-modeling 访谈规则集中在`grilling`里，其他Skill直接复用。 v1.1.0又把确认步骤改成显式停止条件，并区分环境事实和用户决定。旧规则可能让组合调用它的Agent顺手替用户做产品决定，现在这类决定必须逐个问人。

我用 grilling 确认了一次知识库面试需求

拿`grilling`确认了一次需求方向的真实案例来自SpringAI智能面试项目。 当时准备把模拟面试和知识库打通，直接选择了`grilling`，给出的任务只有一句：帮我把这件事想清楚。 现有实现其实已经打通了一部分：普通模拟面试和知识库面试都使用`InterviewSession`，作答、异步评估和部分前端页面也已经复用。此时继续设计底层，可能改掉本来可以保留的代码，首期产品范围反而还没确定。 `grilling`问的第一个决定，是知识库在面试里扮演什么角色。 一种方案是完全根据用户资料生成定向面试；另一种是照常选择Ja va、系统设计等Skill，知识库只补充上下文。选了前者，现有的题库生成、分类、难度、固定追问和评分规则都能继续使用。后一种还会引出两类题目的混合比例、实时RAG、题目去重、来源冲突和评估依据。 这个决定确认后，它才进入下一个分支：一场面试绑定一个知识库，还是允许组合多个知识库？ 请求参数、会话字段和题库筛选都围绕单个`knowledgeBaseId`设计。多知识库还要处理召回结果合并、权重、重复内容和权限校验。首期因此限制为单库，没有提前改关联表和接口结构。 第三个决定是入口。知识库面试已经有独立页面，普通模拟面试则从“模拟面试中心”进入。最后保留两个入口，但底层继续复用`InterviewSession`，配置组件和创建接口也尽量共用，避免以后维护两套相似逻辑。 代码还没有开始改，首期范围已经收成三个选择：纯知识库面试、单个`knowledgeBaseId`、双入口共用会话与创建能力。 `grilling`没有替用户写产品方案。它给出推荐答案和代码依据，取舍仍然由用户确认。第一个答案如果换成“通用Skill + 知识库上下文”，后面要问的也不会是单库还是多库，而会转向两类题目的混合与评估方式。 现在的模型写代码已经够快了。需求范围没定时，Agent也能很快交出代码、测试和文档。方向偏了，这些产物都要跟着返工。 当然，不是每个任务都要先接受一轮“拷问”。改一处文案、补一个明确的空值判断、按现成模式增加字段，验收标准已经写得很具体，直接做通常更省时间。`grilling`也替代不了测试和代码审查，它只负责把动手前还没定下来的问题暴露出来。 当前的`grilling`也没有问题数量上限，复杂需求可能聊得很久。如果担心访谈拉得太长，可以给它设置每轮3～5个问题的预算。一轮结束后先整理已经确认和仍未确认的决定，再由用户选择是否继续。不要只写“最多问5个问题”。额度用完后，Agent仍然不能自行补齐剩余决定或直接开工。

research：把查资料这条支线交出去

给项目升级某个SDK时，当前版本支持哪些参数、旧接口何时弃用、流式事件怎么变化，不该靠用户凭记忆回答，也不适合让主Agent一边改代码一边翻长文档。 `research`会把问题交给后台Agent，只查官方文档、源码、规范和第一方API。结论写进仓库里的一个Markdown文件并标明来源，主Agent可以继续处理其他工作。 关键点在于它把资料来源和交付物钉死了：不拿二手教程替代官方资料，也不把几十页搜索过程塞回主会话，只留下可复查的结论。 使用它有两个前提：Agent支持后台或Subagent调查，项目也接受多一个研究文档。只查一个方法签名时，直接打开官方文档更快；涉及版本迁移、协议差异或陌生依赖，再把这条支线交出去。

diagnosing-bugs：先做出一个会变红的反馈环

Agent排查Bug时很容易过早形成判断。看到一个可疑分支，马上改代码，再跑一遍测试；没修好，就继续换下一个猜测。改动越来越多，最初的故障现象反而没有被稳定复现。 `diagnosing-bugs`把最多精力放在第一阶段：先做出一个能准确捕获当前Bug的反馈环。 反馈环可以是一条失败测试、一段`curl`、带固定输入的CLI、Playwright脚本或线上请求回放。它要能捕获原故障，运行稳定、足够快，并且Agent可以独立执行。 确实无法复现时，它会列出尝试过的办法，再向用户申请可复现环境、HAR、日志、`core dump`或临时生产插桩权限。 反馈环准备好后，再重复复现并缩小输入。接着列出3～5个可以证伪的假设，说明“如果它是原因，改变什么之后现象会如何变化”，再根据预测增加断点或定向日志。 修复阶段会把最小复现转成回归测试，在正确的模块接口处看它先失败，再应用修复。结束前重跑原始场景，清掉带唯一前缀的临时日志和调试程序，并把最终根因写进提交或PR。 这套流程适合难复现的Bug、性能退化和已经猜错几轮的问题。编译错误、明显的字段拼写错误，没必要先建一套诊断流程。项目没有合适的测试接缝时，最小复现也无法变成可靠测试。这个Skill会记录下架构问题，不会硬写一个和真实调用方式不一致的单元测试。

code-review：代码规范和需求实现分开审

代码审查经常只看实现质量：命名是否清楚、有没有重复逻辑、异常处理是否合理、测试够不够。代码本身可能挑不出大问题，却实现错了需求。 `code-review`把审查分为`Standards`和`Spec`两条线。 `Standards`会读取仓库自己的`CONTRIBUTING.md`和编码规范，再检查变更是否遵守约定。当前版本还内置了一组`Fowler Code Smells`。仓库明文规则优先，Smell只能作为判断线索，不能直接算违规。 `Spec`则回到最初的Issue、PRD或技术方案，检查交付内容是否真的覆盖了原需求。两条审查由并行Subagent分别完成，最后再合并结果，避免负责代码风格的上下文影响需求检查。 审查前还要固定`commit`、分支、`tag`或`main`作为比较基点。Skill基于`merge base`查看`HEAD`以来的`diff`，不会把整个仓库泛泛看一遍。 项目没有PRD、Issue或验收标准时，`Spec`这条线只能跳过；仓库没有编码约定，`Standards`更多依赖通用Code Smells。并行审查还要求宿主Agent支持Subagent。CI、静态检查和人工领域审查仍然要保留。

怎么安装

这个仓库可以通过`skills.sh`的安装器接入Codex、Claude Code等支持Agent Skills的工具： npx skills@latest add mattpocock/skills 安装器会让你选择具体Skill和目标Agent。只想体验需求访谈，可以先选`grill-me`和`grilling`。需要在讨论过程中维护`CONTEXT.md`和ADR，再选择`grill-with-docs`与`domain-modeling`。 按照项目当前说明，使用工程链路前还要在目标仓库运行一次`/setup-matt-pocock-skills`，确认GitHub、Linear或本地任务管理方式，并确定`Triage`标签和Agent文档目录。 也可以直接让Coding Agent帮你安装，以Codex为例： 请帮我从 mattpocock/skills 仓库安装 4 个 Agent Skill：grilling、research、diagnosing-bugs、code-review。 安装完成后，通常要到下一轮对话才会出现在可用Skill列表里。 `tdd`、`to-spec`和`to-tickets`没有单列。TDD、规格说明和任务拆分已经是常见工程方法，不少Agent也能完成基础版本。项目采用“讨论 → Spec → Tickets → 实现 → 审查”的整条链路时，再组合它们。 这篇文章挑的4个，对应的是开发过程中几个最典型的失败点：开工前方向没定，资料来源不可靠，Bug没复现就开始猜，代码写完却没有对照原始需求。 第一次安装不用全局启用。先限定在一个仓库，拿两三个真实任务观察返工次数、执行时间和产物质量。模型没有Skill也能稳定完成，就删掉；同一个问题反复出现，再留下那一小段流程。 第三方Skill是交给Agent的指令。安装前读一遍`SKILL.md`，再检查`scripts/`、`references/`和权限要求。列表短一点没关系，知道每个Skill为什么还在，使用时反而更省心。