Matt Pocock Skills——TypeScript 大佬的四个技能，治好了我的 Vibe Coding

系列：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@latestaddmattpocock/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 个最有用的，看看"全家桶"是省事还是添乱。