真正工程师的技能

背景

作者 Matt Pocock 是 TypeScript 圈最知名的教育者之一，做了 Total TypeScript 课程平台。他日常重度使用 Claude Code 写代码，发现一个要命的问题：

AI 写代码太快了，快到一个礼拜就能搞出一坨屎山。AI编程工具虽然高效，但缺乏工程纪律可能导致代码质量失控。

我们平常用AI写代码，肯定遇到这种问题，就是AI 写代码的速度远超你的代码审查速度。

手动编程时，正常的工程师会：

• 开工前先对齐需求
• 写测试保证行为正确
• 代码写完了过一遍是否合理
• 定期检查架构有没有腐化

但 AI 有可能不会主动做这些——你让它写它就写，它不会停下来问你"这个需求你确定想清楚了吗？"“要不要先写个测试？”

你手写代码时，一个模块可能要半天，你有足够时间停下来想架构。AI 三分钟生成了一个 500 行的模块，你甚至来不及想"这个模块职责对吗"，代码已经躺仓库了。一个礼拜下来，项目就烂了。

根因不是 AI 蠢，是 AI 缺少工程纪律。

四个经典失败模式：

失败模式	表现	后果
需求没对齐	你以为 AI 懂了，它理解偏了	返工率极高
没有共享语言	AI 每次都用大白话解释概念，啰嗦又烧 token	context window 被撑爆
没有反馈循环	写完代码不看测试、不看类型、不看浏览器	代码上线 = 炸弹上线
没有架构审查	AI 往一个模块里塞五个职责，函数 20 行变 200 行	屎山堆得比手写快 10 倍

所以他把这些工程纪律写成了 18 个 Skill 文件，本质就是给 AI 加了一层"教练"——你给 AI 丢需求前先跑 /grill-with-docs，AI 被迫先把需求问清楚；你写代码前跑 /tdd，AI 被迫先写测试；你每天下班跑一次 /improve-codebase-architecture，AI 被迫做代码审查。

他在自己项目里把这些该做的事固化成了一组可在 Claude Code / Codex 等AI编程工具中用的 Skill 文件——本质就是把 Code Review、需求评审、TDD、架构审查这些工程师本来该做的流程，变成 Agent 必须执行的步骤。

核心理念：不绑定任何模型，每个 Skill 是一个独立 Markdown 文件，可以自由组合、随意修改。不做框架，做工具。本质不是给 AI 加能力，是给 AI 加纪律。好工程师该做的，AI 被 skill 逼着也得做。

项目地址：https://github.com/mattpocock/skills

安装

运行命令进行安装：

npx skills@latest add mattpocock/skills

接着运行一次以下命令进行初始化：

/setup-matt-pocock-skills

配置，回答三个问题：

1、issue tracker？(GitHub / Linear / 本地），选择你用哪个工具管理 Issues

2、triage 标签名？(自定义 / default默认)，给 Issue 打标签时用哪些词汇（/triage 技能会用到）

3、生成的 ADR 和文档放哪？（Single-context / Multi-context）

1) Single-context

适合：

• 一个仓库里基本就是一个产品/一个应用
• 文档和 ADR 都能统一放在仓库根目录下
• 没有特别复杂的分区需求

特点：

• 只有一个 CONTEXT.md
• ADR 放在 docs/adr/
• 结构简单，最适合大多数仓库

如果你不确定，通常选这个。

2) Multi-context

适合：

• Monorepo
• 一个仓库里有多个应用、包、服务、模块
• 每个部分都有自己独立的上下文和文档
• 需要一个 CONTEXT-MAP.md 去指向不同的 context 文件

特点：

• 根目录有 CONTEXT-MAP.md
• 每个子项目/模块各自有 context 文件
• 更适合大型、多团队协作仓库

完成配置后，会在项目根目录生成一个 CONTEXT.md，作为 AI 与你之间的共享语言词典。

这个文件非常重要——它统一了项目中术语的使用方式，AI 之后所有命名和注释都会基于它。

每个技能的作用

工程技能---针对写代码编程

技能/grill-with-docs — 需求对齐 + 术语建设

AI 对你的需求进行多轮拷问，一次一个问题。碰到模糊的词汇立刻让你澄清，确认后实时更新 CONTEXT.md（项目术语词典）。遇到重大决策当场写 ADR（架构决策记录）。

什么时候用：每次新需求开始前。

例子：你跟 AI 说"加个用户登录"，它反问："你说的'用户'是 Customer 还是 Admin？登录方式是邮箱密码还是手机验证码？是否支持 SSO？Token 存在哪？"——一轮拷问下来，原本模糊的 5 个字变成了精确的规格说明书，项目术语表也更新了。

技能/grill-me — 快速需求澄清（不建文档）

和 /grill-with-docs 一样的拷问流程，但不维护 CONTEXT.md 和 ADR。

什么时候用：非编码场景（方案讨论、技术选型），或者项目还没建 CONTEXT.md 时。

例子："你想用 Redis 还是 PostgreSQL 做缓存？"——AI 会抛出 5 个追问帮你理清技术选型的权衡，但不写入文档。

技能/tdd — 测试驱动开发（正确版）

强制「红→绿→重构」循环。每次只写一个测试、只写刚好让它通过的代码。只测公开接口行为，不碰实现细节。禁止一次性写完所有测试（水平切片）。

什么时候用：任何写新功能或修 bug 的时候。

例子：你要加一个"购物车结算"功能。AI 不先写代码，而是先跟你确认："结算接口的输入是什么？（Cart 对象）输出是什么？（OrderConfirmation）失败情况有哪些？（库存不足、支付失败、优惠券过期）"——然后逐条写失败的测试，逐条写让它通过的实现。

技能/diagnose — 系统化调试

6 阶段方法论。Phase 1 最关键——先造一个 Agent 能自动跑的 pass/fail 信号（测试、curl 脚本、headless 浏览器脚本等），没有反馈循环别碰代码。

什么时候用：遇到复现困难、原因不明的 bug。

例子：一个 API 偶尔返回 500，日志里啥也没有。AI 先用 curl 写一个重试脚本每 5 秒打一次，跑 10 分钟后收集到 3 次失败的请求体，锁定了触发条件（某个特殊字符导致的 SQL 注入误报），然后对症下药。

技能/improve-codebase-architecture — 架构体检

Agent 派 subagent 浏览代码库，找出「浅模块」（接口跟实现差不多复杂，相当于没封装），给「加深」建议列表让你选。

什么时候用：每几天跑一次，或在代码量明显增长后。

例子：跑完后 AI 报告："UserService 接口暴露了 15 个方法，但其中 8 个只是转调 UserRepository 的同名方法。建议合并为一个 upsertUser + queryUser 两个方法，内部处理 CRUD 逻辑。"——接口从 15 个减到 2 个，调用方瞬间清爽。

技能/to-prd — 对话→PRD

把当前对话上下文综合成一份 PRD 提交到 issue tracker。包含：问题描述、解决方案、用户故事、实现决策、测试决策、不在范围内。

什么时候用：需求讨论结束后一键归档。

例子：你跟 AI 聊了半小时"要给管理后台加数据导出功能"，聊完跑 /to-prd，它自动生成："Problem：运营无法导出用户行为数据做分析。Solution：管理后台新增 CSV 导出按钮。User Stories：1) 作为运营，我想选择日期范围导出用户活跃度数据... Implementation：在 /admin/export 新增路由..."——不需要你再写一个字。

技能/to-issues — PRD→开发任务

把 PRD 拆成垂直切片的独立 issue。每个 issue 贯穿所有集成层（前后端都包含），可独立交付。标 AFK（Agent 可独立做）还是 HITL（需要人类决策）。

什么时候用：PRD 确认后。

例子：PRD 里"数据导出功能"被拆成 3 个 issue：

• Issue 1（AFK）：后端导出接口 + CSV 生成

• Issue 2（AFK）：前端导出按钮 + 日期选择器

• Issue 3（HITL）：权限控制——谁有权导出全部数据？（需要你拍板）

技能/triage — Issue 分类管理

一个小型状态机。每个 issue 有一个类别（bug/enhancement）+ 一个状态（needs-triage/needs-info/ready-for-agent/ready-for-human/wontfix）。被拒的增强提案自动归档到 .out-of-scope/。

什么时候用：整理 issue 列表时。

例子：有人提了个"支持 WebSocket 实时推送"的需求。AI triage 后标记为 enhancement + needs-triage，然后列出权衡：当前项目规模是否需要？现有轮询方案够不够用？——如果判断不需要，标记 wontfix 并写一份说明放入 .out-of-scope/，半年后有人再提时直接引用。

技能/prototype — 写可丢弃的原型

用最少代码验证一个设计假设。逻辑问题 → 跑终端小程序推状态机；UI 问题 → 在同一路由下生成多个不同方案用 URL 参数切换。原型代码明确标记为 throwaway，不写测试、不抽象。

什么时候用：对某个设计决定没把握时。

例子：你不确定"任务看板"是该用拖拽还是点击弹窗来移动任务。跑 /prototype，AI 在 /kanban?variant=drag 和 /kanban?variant=modal 下各生成一个原型，你在浏览器里切换对比，5 分钟决定用拖拽。原型代码删掉，设计决策合并进正式代码。

技能/zoom-out — 全局视角看代码

干什么：一句话 prompt 让 AI 画出当前模块的所有相关模块和调用方地图。

什么时候用：碰不熟的代码段时，先 zoom out 再动手。

例子：你要改 PaymentService.processPayment()，先跑 /zoom-out。AI 画出：这个方法被 OrderController、SubscriptionRenewal、RefundHandler 三个地方调用，依赖 PaymentGateway 和 InvoiceGenerator。"改签名会炸三个上游，建议只改内部实现或者让所有调用方一起升级。"——避免了改完发现自己炸了三个模块。

提高效率的技能---针对工作流程非代码

技能/caveman — 省 token 模式

Agent 切成电报体，砍冠词、寒暄、filler，token 省 ~75%。

什么时候用：context window 快满时，或想加速交流。

例子：

• 正常模式：「好的，我来分析一下 PaymentService 这个类的结构，然后帮你重构它。这个类目前有大约 200 行代码...」

• caveman 模式：「分析 PaymentService → 4 个方法, 2 个 helper → 提取 helper 到 PaymentsHelpers → 开始？」

技能/handoff — 交接文档

把当前对话压缩成交接文档，新 session 或新 Agent 可以直接接手。

什么时候用：换 Agent、换 session、或交给同事时。

例子：你跟 Claude Code 干了半天刚把 PRD 拆成 issue，该睡觉了。跑 /handoff，第二天早上 Claude Code 读了这个文档，直接知道你昨天做了什么、卡在哪、下一步要干什么。

技能/write-a-skill — 写自己的技能包

一步步教你用 Matt 的格式创建新 Skill。

什么时候用：想把自己团队的工程规范也固化成 skill 时。

例子：你们公司代码审查有一堆规矩——commit message 格式、分支命名规范、部署前 checklist。跑 /write-a-skill，AI 引导你把它们写成 /code-review、/pre-deploy 两个 skill，新来的 Agent 自动遵守。

技能/setup-matt-pocock-skills — 一次性初始化

配置 issue tracker、label 词汇表、文档路径。其他技能依赖这些配置。

什么时候用：每个新 repo 必须跑一次。

例子：你用的是 GitHub，label 叫 bug/feature/needs-triage，文档放 docs/decisions/。跑完初始化后，/triage 自动用这些 label，/improve-codebase-architecture 自动把 ADR 写到 docs/decisions/。

工具类技能---很少用的

技能	干什么	例子
git-guardrails-claude-code	Claude Code 的 git hook，拦截 push / reset --hard / clean	不让 Agent 误操作 git
setup-pre-commit	配 Husky + lint-staged + Prettier + 类型检查 + 测试	新建项目中跑一次，每次 commit 自动过检查
migrate-to-shoehorn	as 断言统一迁移到 shoeshorn	老项目里到处是 as Type→ 统一替换
scaffold-exercises	生成练习目录结构	做教学/教程网站时的章节、题目、答案模板

推荐工作流

收到新需求
  /grill-with-docs    →  对齐需求，建术语，写 ADR
  /to-prd             →  一键生成 PRD
  /to-issues          →  拆成垂直切片 issue
  /triage             →  设状态（ready-for-agent）

开始实现
  /tdd                →  红→绿→重构，一次一个测试

遇到 bug
  /diagnose           →  先造反馈循环，再修

日常维护
  /improve-codebase-architecture   →  每几天跑一次
  /zoom-out           →  遇到陌生代码先看全局

token 不够了
  /caveman            →  省 75%

换 session
  /handoff            →  生成交接文档

核心就一句话：没这技能包，你该做的（code review、需求评审、TDD、架构审查）你也该做；

有了它，AI 被迫也参与进来。