TypeScript 大神把 .claude 目录公开了，里面 8 条工程师心法值得每个程序员抄

如果你最近一周刷 GitHub trending，大概率绕不开一个仓库：mattpocock/skills。

4.8 万 star，trending 第 2 位连占 6 天。但比数字更值得看的是它的副标题：

Skills for Real Engineers. Straight from my .claude directory.

给真工程师用的 skills，直接来自我自己的 .claude 目录。

Matt Pocock 是谁？TypeScript 圈头部教育者，写 total-typescript 课程的人，长期做工具链。这次他把自己天天用的那一坨 Claude Code skills 原样公开——不是教学版本，不是 demo，是他每天 push 代码前都要过一遍的真实工作流。

仓库里 13 个 skills 分两组：工程类 10 个，生产力类 3 个。我挑 8 条最有”心法”感的——哲学层面立得住，又每条都有具体可执行的 prompt 模板——一条一条拆给你。

一句话立场：real engineering 不是 vibe coding

读 Pocock 这个仓库前先记住一句话：

这套 skills 的存在前提，是区分 vibe coding 和 real engineering。

vibe coding 就是”嘿 Claude 给我写个 Redis client”，AI 哗哗给你一坨能跑但你不知道哪儿不优雅、哪儿有 bug、哪儿明天会爆的代码。初学者用得开心，专业工程师用一次就想关掉。

real engineering 不是反对 AI 协作，是反对让 AI 替你做不该 AI 做的判断。架构决策、测试边界、领域语言这些事 AI 可以辅助但不能主导。Pocock 的 13 个 skills 都是同一个逻辑——把 AI 框在它该做的位置上，让工程师保留判断权。

下面 8 条心法，按”通用频率 × 价值密度”排序。

心法一：TDD 红-绿-重构循环（/tdd）

TDD 这词儿很多人听过，但真的天天跑 TDD 的程序员我认识的不超过五个。原因不复杂——人懒，先写测试比先写代码多两步心理障碍。

Pocock 把 TDD 做成一个 skill，意思是把”懒”这件事交给 AI 解决。

工作流：

1. 你描述要实现的功能 + 给一个具体输入输出例子
2. Claude 先只写一个失败的测试（红）
3. 跑测试，确认失败原因符合预期
4. Claude 再写最小实现让测试过（绿）
5. Claude 找重构机会简化代码（重构）
6. 完成后回到 1 加下一个 case

这个循环最值钱的不是 TDD 本身，是它让 AI 没机会跳步骤。

如果你不强制 TDD 节奏，Claude 默认会一次性给你完整实现 + 完整测试，然后报告”全部通过”。但实际上它内部哪儿幻觉了、哪儿没考虑 edge case，你不知道，因为它跟你说”全部通过”你就信了。

TDD 强制每写一行代码都有一个它没法作弊的小考试。红是真的红，绿是真的绿，幻觉无处藏。

心法二：系统化调试（/diagnose）

第二个心法是 Pocock 仓库最严谨的一个，厉害了。debug 工作流定死六步：

reproduce → minimize → hypothesize → instrument → fix → test

逐字翻译就是：复现 → 最小化 → 假设 → 加埋点 → 修 → 验证。

每个程序员都知道这六步该这么走。但绝大多数人实际 debug 时跳过 2 和 4。

跳 minimize 的代价：你在一个 5000 行的代码库里看症状，永远不知道是哪一段引发的，每次都要肉眼扫一遍。

跳 instrument 的代价：你猜了一个原因，直接改代码看症状没了——但其实是巧合，真正的 bug 还在，几周后用别的形式爆。

Pocock 这个 skill 强制你每一步都跟 AI 对齐，不让 AI 跳。Claude 必须先复现给你看（不是它脑补的复现，是实际跑出来的复现），再给最小化的复现 case，再列出 3-5 个假设，再插埋点验证哪个假设对，最后才动手修。

整套流程比”直接让 AI 修 bug”慢 30%。但真 bug 真修对的概率从 50% 飙到 95%。

心法三：用一次性原型验证设计（/prototype）

这个 skill 解决的是工程师最容易掉的一个坑——把”想清楚”和”写干净”耦合在一起。

正常情况下你设计一个新 feature，第一反应是”我要写得优雅”。结果写到一半发现某个设计假设不成立，但你已经写了 300 行带类型 + 单测 + 文档的代码，舍不得删，于是硬塞补丁。三个月后这块代码成了技术债。

prototype 这个 skill 把”想清楚”提到前面：

1. 明确告诉 Claude 这是throwaway prototype（一次性原型）
2. 用最丑的姿势把核心逻辑搭起来——硬编码、any 类型、没测试都行
3. 跑通，验证设计假设
4. 整个 prototype 删掉，再用工程级姿势重写

很多人卡在第 4 步——“已经写了为啥不留着改改？“。Pocock 这个 skill 强制你删——因为留下的 prototype 代码会污染后续的设计判断。你会下意识地围绕已写的东西继续走，而不是基于学到的东西重新走。

做实验和做产品要分开容器。prototype 是实验。

心法四：把 PRD 拆成 vertical slices（/to-issues）

这条特别值得抄。

工程师拆任务有两种姿势：

• horizontal slice（水平切）：先做完整的数据层，再做完整的逻辑层，再做完整的 UI。各层做完前互不交付。
• vertical slice（垂直切）：每个 issue 是一个从 UI 到 DB 的完整薄片，做完就能让用户用。下一个 issue 再加一片。

绝大多数团队默认水平切，因为感觉”模块化”。但水平切的致命缺陷是没东西能 demo 直到最后一刻。三周后 PM 来看进度，你 DB schema 设计完了但用户看不到任何功能。

Pocock 这个 skill 强制 vertical slice：

1. 你给它一个 PRD 或者 spec
2. Claude 帮你拆成 N 个 issue，每个都是独立可交付的垂直薄片
3. 每个 issue 自己包含 UI + 逻辑 + DB，跑完就能让产品体验
4. issue 之间互不阻塞（理论上多人能并行）

让我说点直白的：好家伙，这一个 skill 抄回去，你团队下季度 sprint 节奏立刻变。从”完成 1 个 issue 但用户看不到”变成”完成 1 个 issue 用户立刻能用一片新功能”。

心法五：跳出当前 context 看高层视角（/zoom-out）

这是最反直觉但又最值得抄的一条。

跟 Claude 协作久了你会发现一个很反人类的现象：你给 AI 的 context 越细，它越容易给你局部最优解。比如你贴了一段 30 行的函数让它优化，它会针对那 30 行做漂亮的局部优化——但完全错过”这 30 行其实应该删掉，因为更上层有更简单的实现”。

zoom-out 这个 skill 的作用是强制 AI 跳出你给的局部，看一眼更大的 context。具体怎么做：

1. 在你的局部问题上方加一句 trigger：zoom out before answering
2. Claude 会先扫一遍周边代码（同文件 / 同目录 / 相关 import）
3. 给一份”这段代码在更大系统里的位置”的总结
4. 然后再回答你的局部问题，但答案会带着大 context 的判断

这个 skill 单独看好像没啥特别，但它消除了一类极其常见的 AI 协作 bug——“针对错的问题给出了对的答案”。

实战姿势：每次让 AI 改代码前默念一遍 zoom out。即便不调用这个 skill 本身，你这个意识也会让协作质量上一个档次。

心法六：穷尽提问消除决策歧义（/grill-me）

grill 直译是”烤”，引申义是”逼问”。这个 skill 把”逼问”的方向反过来——不是你 grill AI，是让 AI grill 你。

场景：你脑子里有个新 feature 的模糊想法，但还没想透。你给 AI 一段 200 字的概述，期望它直接帮你写代码。

正常情况下 AI 会基于它对你想法的猜测做出实现。结果跑出来你说”诶这不是我想要的”，再改。来回 3-5 轮。

grill-me 这个 skill 强制 AI 先把你想法里所有歧义点列出来逼你拍板。比如：

• 「这个新 feature 是给登录用户还是匿名用户用？」
• 「失败时是 silent 还是 throw？」
• 「这个数据要持久化还是只在 session 里？」
• 「你说『快』，是 100ms 还是 1s 内？」

每个问题你必须答。所有问题答完之前 AI 不写一行代码。

这个 skill 最值钱的不是省时间，是逼你想清楚。很多 feature 你以为想透了，被 grill 三轮之后才发现自己其实没想透。

心法七：文档驱动的访谈式规划（/grill-with-docs）

这是 grill-me 的升级版。它把 grill 跟项目文档绑在一起。

工作流：

1. 项目根目录有个 CONTEXT.md，记录团队对术语、边界、约定的共识
2. 你提一个新需求，触发 grill-with-docs
3. AI 一边 grill 你一边对照 CONTEXT.md 检查
4. 发现 CONTEXT.md 没覆盖到的新术语 / 新概念，当场让你补
5. 补完写回 CONTEXT.md
6. 然后才开始实现

这条 skill 解决的是软件团队最隐形的成本——术语漂移。

你跟 AI 用 “user” 这个词，AI 在 prompt 1 默认理解成”已登录用户”，prompt 5 默认理解成”任何能访问 API 的客户端”，prompt 10 默认理解成”业务定义的『付费用户』“。三个意义混用，代码里就是三种 bug。

CONTEXT.md + grill-with-docs 强制每个术语只能有一个定义。AI 用错了它会自己 catch 出来，因为 CONTEXT.md 是它的 ground truth。

DDD（Domain-Driven Design）讲的”ubiquitous language”理论在这套机制里落地成了一个可执行 skill。

心法八：用领域语言重构架构（/improve-codebase-architecture）

最后一条最难也最深。它处理的是软件最难的事——架构腐烂。

代码库刚起步时永远是干净的，因为信息密度低。每加一个 feature 就多一层 if-else，多一个 helper function，多一份”临时的” workaround。半年后那个曾经干净的 codebase 已经认不出来了。

improve-codebase-architecture 这个 skill 的姿势是反向走——不从代码出发找问题，从领域语言出发找问题。

工作流：

1. AI 扫一遍 codebase，先只列出代码里出现的所有术语（函数名、类名、变量名）
2. 你跟它 review 这个术语表，把模糊的 / 冗余的 / 错位的标出来
3. AI 找出术语跟实际语义不匹配的代码块——这些就是架构腐烂点
4. AI 给出用更准的术语重构的方案
5. 你拍板要不要执行

这条 skill 有点子牛逼的地方是它把”代码 review”重新定义成”领域语言 review”。绝大多数代码 review 关注的是”这段代码对不对”，而 Pocock 这条逼你关注”这段代码在说一件什么事，说得准不准”。

后者比前者重要十倍。准确的术语决定代码能不能维护。

这套 skills 共同的”心法之心法”

8 条单独看像是 8 个工作流模板。但你把它们摞在一起看，会发现 Pocock 在做同一件事——把工程师的判断锚点从『代码能跑』移到『代码表达对了我想表达的事』。

• TDD 让 AI 不能撒谎（红绿真实反馈）
• diagnose 让 debug 不能跳步骤
• prototype 让实验和产品分开容器
• to-issues 让交付不能停在中间层
• zoom-out 让局部最优不掩盖全局错
• grill-me 让模糊想法在动手前显化
• grill-with-docs 让术语漂移在团队层面闭合
• improve-codebase-architecture 让架构腐烂可以被领域语言捕获

8 条心法共有的内核：AI 协作时代，工程师的核心价值不再是写出代码，是判断”什么代码该被写”。

Pocock 把这种判断显性化成了 13 个 skill。我们围观的程序员，最大的收益不是 git clone 这个 repo 直接用——是意识到自己每天工作里那些”该判断但没判断”的位置，然后补上。

写在最后

仓库里的 13 个 skills 你今晚能做的最小动作：

1. 打开 仓库主页 翻一遍 README
2. 挑你最近一个月最痛的工程场景（debug 卡壳 / 架构纠结 / PRD 不清晰，任选一个）
3. 找仓库里对应的 SKILL.md
4. 直接复制到你 ~/.claude/skills/ 目录
5. 明天工作里遇到那个场景时主动调一下，感受效果

如果觉得有用，挑下一个；觉得不顺手，删掉。真实工作流验证 > 任何评测和教程。

这就是 Pocock 公开这套 skills 的真正价值——它不是给你抄答案，是给你抄『怎么把 AI 嵌进工程师日常』的范式。

参考链接：

• 仓库主页（含完整 README + 所有 skills）
• Matt Pocock 个人网站 aihero.dev
• Claude Code 官方 skills 文档