系列：AI 编程工具生态挖掘 ｜ 字数：约 2800 字 ｜ 预计阅读：7 分钟

---

Matt Pocock 是 TypeScript 社区最有影响力的布道者之一。他出的 12 个 Claude Code 技能包，核心卖点一句话：Real Engineering, not Vibe Coding。

Vibe Coding 是 2025 年流行起来的词——描述很多人在用 AI 写代码时的状态：把需求丢给 AI，看输出差不多就 Approve，不仔细审查，不关心质量。直到部署爆炸。

Pocock 的这组技能就是反 Vibe Coding 的工程实践封装。12 个技能里，我挑了 4 个最有代表性的逐个测了一遍。

---

安装

npx skills@latest add mattpocock/skills

装在项目的 .claude/skills/ 下。装完之后四个技能直接可用：

/grill-me    — 盘问你的需求，不让你写模糊指令
/tdd         — 严格的 Red-Green-Refactor 循环
/diagnose    — 系统化排错，不是瞎试
/caveman     — 极致压缩 token，用最少的词说清楚

---

/grill-me——在你写出烂 prompt 之前拦住你

这是四个里面最有特色的。

用法很简单：描述你要做什么，然后 /grill-me。AI 不会立刻写代码——它先反过来盘问你。

实测：

用户: 加一个用户头像上传功能，支持裁剪。

用户: /grill-me

Claude Code (grill-me):
  在开始之前，我需要确认几点：

  1. 图片来源？—— 用户本地上传，还是 URL，还是两者？
  2. 存储位置？—— 本地文件系统，S3，还是 CDN？
  3. 裁剪是前端做还是后端做？—— 前端裁剪节省带宽，后端裁剪更可控
  4. 尺寸限制？—— 最大文件大小、宽高比、输出尺寸
  5. 已有用户的默认头像？—— 没有上传的显示什么
  6. 权限？—— 谁可以修改/删除头像

  回答完这些再开始。你现在只需要回答我，不需要实现。

用户: 用户本地上传，存到 S3，前端裁剪（react-image-crop），
  最大 5MB，1:1 输出 200x200，默认用首字母头像。

Claude Code: 明确了。开始实现。

效果——你本来模糊的"上传头像"被拆成了 6 个决策点。AI 没有浪费时间写你用不着的代码，你也没有在半路上反复改需求。

日常用的时候，/grill-me 不是每次都需要。但当你发现自己的需求描述只有一句话、而且你其实也没想清楚的时候——先 grill 自己，再写代码。

---

/tdd——Red-Green-Refactor，但有惩罚

Pocock 的 TDD 技能跟普通 TDD 的区别在于，它严格控制了实现阶段的行为。

规则：

1. 红灯：先写失败测试，AI 运行测试证明它是失败的
2. 绿灯：写最小的实现让测试通过。不能多写——测试没覆盖的功能一行也不写
3. 重构：测试全绿后，才能调整结构
4. 循环：每个新功能从红灯开始

实测： 写一个字符串工具函数 truncate(str, maxLen, suffix)——超出长度的截断加后缀。

用户: /tdd 实现 truncate(str, maxLen, suffix)

Claude Code (tdd):
  [RED] Writing test first...
  test_truncate.py:
    def test_truncate_short_string():
        assert truncate("hello", 10) == "hello"
    def test_truncate_long_string():
        assert truncate("hello world", 8, "...") == "hello..."
    def test_truncate_exact_length():
        assert truncate("hello", 5) == "hello"
  → pytest: 3 failed (function not defined yet) ✓ 确认红灯

  [GREEN] Minimal implementation:
    def truncate(s, max_len, suffix="..."):
        if len(s) <= max_len:
            return s
        return s[:max_len - len(suffix)] + suffix
  → pytest: 3 passed ✓ 绿灯

  [REFACTOR] All tests green. Checking for opportunities:
    - Could extract suffix length calculation to variable
    - No edge case gaps detected
    Current state is clean. No refactoring needed.

TDD 模式下 AI 不会"顺手"加参数验证、不会多写 Unicode 支持、不会顺便处理负数 maxLen。测试没要求的一行不写。这跟没有 TDD 约束时 AI 的表现截然不同——默认模式下它可能写着写着就加上"防御性编程"的额外代码，而 TDD 模式把 AI 变成了只满足测试的极简实现者。

---

/diagnose——系统化排错

AI 排错最常见的问题：试一个方案、不行、换一个、不行、再换——像没头苍蝇。/diagnose 给排错套上了一个系统框架。

用户: /diagnose 测试 test_truncate_unicode 失败了，输入是 "你好世界"，
  期望 "你好..."，实际 "你好世..."

Claude Code (diagnose):
  [OBSERVE] What exactly happened?
   - Input: "你好世界" (4 Chinese characters)
   - Expected: "你好..." (3 chars)
   - Actual: "你好世..." (the 3rd char leaked)

  [HYPOTHESIZE] What could cause this?
   Hypothesis A: Python string slicing works on bytes, not chars
     → No: Python 3 handles Unicode code points correctly in slicing
   Hypothesis B: len("...") != number of display characters
     → No: len("...") = 3, correct
   Hypothesis C (MOST LIKELY): s[:max_len - len(suffix)] is subtracting
     byte count, not character count. Chinese chars are 3 bytes in UTF-8,
     so max_len - len(suffix) overshoots when mixed with ASCII suffix.

  [TEST HYPOTHESIS]
    >>> s = "你好世界"
    >>> s[:5 - 3]  # max_len=5, suffix="..."
    → "你好"  ✓ we get 2 chars
    >>> truncate("你好世界", 5, "...")
    → "你好..." ✓ fix confirmed

  [FIX]
    The issue: s[:max_len - len(suffix)] works fine because
    both max_len and suffix are measured in characters.
    Wait — the hypothesis was wrong. Let me re-test...

    >>> truncate("你好世界", 4, "...")
    Actual behavior: 4 - 3 = 1, s[:1] = "你", output = "你..."
    Expected: "你..."  ← correct!
    The original bug was: test expected "你好..." but max_len=5
    and 4 Chinese chars = 4 chars, truncates at 5 - 3 = 2 chars,
    output = "你好..."  ← this IS correct. The test was wrong.

  [CONCLUSION] No bug in truncate(). Test expected wrong value.
    truncate("你好世界", 5, "...") → "你好..." is correct behavior.
    The test writer assumed Chinese chars count differently than they do.

系统化排错的过程有三个阶段：观察、假设、验证。没有跳步、没有猜。最后一个转折——排了半天发现是测试写错了，不是代码有问题。如果不用系统化框架，大概率已经改了好几轮代码，把本来对的实现改错了。

---

/caveman——极致压缩

不写代码的时候用的——纯分析、解释、回答问题。用最短的句子，不展开，不带任何修饰词。

用户: /caveman 解释这个项目的路由结构

Claude Code (caveman):
  / → home()
  /posts/<slug> → post_detail()
  /tag/<name> → posts_by_tag()
  /archive → archive()
  /feed → rss_feed()
  Blueprint: blog, prefix: /

  That's it. 5 routes. 1 blueprint. No middleware.

没有"这个项目的路由结构包括以下端点…"这样的开场白。直接回答。token 节省 60-80%。

适合的场景：快速查代码结构、问"这个文件引入了哪些模块"、“这个函数被哪些地方调用”。不适合复杂分析——太浓缩了会丢失上下文。

---

四个技能的组合用法

Pocock 的技能设计理念是"各管一摊，组合使用"：

/grill-me → 想清楚再动手
/tdd → 严格测试驱动
/diagnose → 出 bug 时系统化排错
/caveman → 快速查代码，不多说

日常流的顺序：接到需求 → /grill-me 盘清楚 → /tdd 按红灯绿灯写 → 测试挂了 → /diagnose 分析原因 → 中间查代码用 /caveman 快速确认。

不是每个需求都要走全套。小改动跳过 grill-me，简单 bug 跳过 tdd。但如果你发现自己经常在模糊需求中改来改去，这四个技能就是救场。

---

下一篇

Pocock 的四个技能是精准工具，各管一道工序。下一篇测 ECC——社区最大的全家桶：30 个 Agent、135 个 Skill、60 个 Command。从 135 个里挑 5 个最有用的，看看"全家桶"是省事还是添乱。