真正的工程师所需技能

这些是我每天用于实际工程开发的能力——而非仅仅为了玩乐而编码。

开发真正的应用程序并非易事。GSD、BMAD 和 Spec-Kit 等方法试图通过掌控整个流程来提供帮助。但这样做会剥夺你的控制权，使得开发过程中的错误更难解决。

这些技能被设计得小巧、易于调整且可组合。它们适用于任何模型，其基础是数十年的工程实践经验。你可以随意尝试改造它们，让它们成为属于自己的工具，享受使用过程。

如果你想随时了解这些技能的更新以及我新创建的技能，可以加入我的新闻简报，与另外约 60,000 名开发者一起获取信息：

订阅新闻简报

安装（30 秒完成）

有两种方式，两种理念。Claude Code 插件 会将整套技能以托管的只读包形式安装，每当我有新版本发布时就会自动更新——你需要订阅而非 Fork 代码。而 skills.sh 会将可编辑的技能文件复制到你的项目中，这样你就可以对其进行修改并使其成为自己的东西。请选择一种方式——如果同时安装两种，每个技能就会出现两次。

1. 获取技能

claude plugins install mattpocock-skills

/plugin install mattpocock-skills

npx skills@latest add mattpocock/skills

npx skills@latest add mattpocock/skills

2. 运行 /setup-matt-pocock-skills

在你的智能体中，为每个仓库运行一次该命令。它将：

• 询问您想使用哪种问题追踪工具（GitHub、Linear 或本地文件）
• 询问您在对工单进行分类时会给其添加哪些标签（/triage 会使用标签）
• 询问您希望将我们生成的文档保存在何处

3. Bam - 您已准备好开始使用。

为何需要这些技能

我创建这些技能，是为了解决在 Claude Code、Codex 以及其他编程智能体中常见的故障问题。

#1：智能体没有按我的要求行事

“没人能确切知道自己想要什么”

David Thomas & Andrew Hunt，《务实程序员》]

问题所在。软件开发中最常见的故障就是目标不一致。您以为开发人员明白您的需求，但看到他们完成的成果后才发现，他们根本没理解您的意图。

在人工智能时代，情况也是一样的。您与智能体之间存在沟通隔阂。解决此问题的方法是进行深入询问——让智能体就您要构建的内容向您提出详细的问题。

解决方案是使用：

• /grill-me - 用于非代码相关场景
• /grill-with-docs - 与 /grill-me 功能相同，但附加了更多功能（见下文）

这些是我最常用的技能。它们能帮助您在开始工作前与智能体对齐目标，并促使您深入思考即将进行的变更。每次想要进行变更时都请使用它们。

#2：智能体的表达过于冗长

由于存在一种通用语言，开发人员之间的交流以及代码的表述都源自相同的领域模型。

Eric Evans，《领域驱动设计》]

问题所在：在项目开始时，开发人员与软件的最终用户（领域专家）通常使用不同的语言进行交流。

我在使用智能体时也遇到了同样的问题。智能体通常会被直接投入到项目中，需要边做边去理解其中的行话。因此，它们常常会用20个词来表达本可以用1个词就能说清的内容。

解决方案是建立一种共享语言。即一份文档，用于帮助智能体理解项目中所使用的行话。

这一功能已内置在/grill-with-docs中。它也是一种深入询问的方式，但同时能帮助您与人工智能建立共享语言，并在 ADR 文档中记录那些难以解释的决策。

很难用言语形容它的强大之处。这或许是该代码库中最酷的技术了。试试看吧，亲自体验。

[!TIP] 使用通用语言除了能减少冗长表述外，还有诸多其他好处：

• 变量、函数和文件的命名更加统一，都采用这种通用语言
• 因此，智能体更易于浏览代码库
• 由于能使用更简洁的语言，智能体在思考时消耗的令牌也更少

#3：代码无法正常运行

“始终采取小步、有计划的行动。反馈的频率就是你的速度上限。绝不要承接过于庞大的任务。”

David Thomas & Andrew Hunt，《实用程序员》]

问题所在：假设你和智能体在要构建什么功能上已达成一致，但如果智能体_仍然_生成糟糕的代码该怎么办？

是时候审视一下你的反馈机制了。如果没有关于其生成的代码实际运行情况的反馈，智能体就会在盲目中工作。

解决方案：你需要常规的几类反馈机制：静态类型检查、浏览器访问权限以及自动化测试。

对于自动化测试而言，红绿重构循环至关重要。在这种循环中，智能体会先编写一个失败的测试用例，然后再修复它。这有助于为智能体提供稳定的反馈，从而生成质量更高的代码。

我开发了一项**/tdd技能**，你可以将其应用到任何项目中。它能推动红绿重构循环的实现，并为智能体提供大量关于何为优质测试、何为劣质测试的指导。

在调试方面，我还开发了一项**/diagnosing-bugs技能**，它将最佳的调试实践封装在一个结构严谨的循环中，逐阶段进行控制。

#4：我们造出了一个一团糟的东西

“每天都要投入精力优化系统设计。”

Kent Beck，《极限编程详解》]

“最好的模块结构是深度化的。它们能让大量功能通过简单的接口被调用。”

John Ousterhout，《软件设计哲学》]

问题所在：大多数由智能体构建的应用程序都十分复杂，且难以修改。由于智能体能极大提升编码速度，它们也会加速软件的熵增现象。代码库的复杂度正以前所未有的速度上升。

对此的解决方案是一种全新的、基于人工智能的开发理念：重视代码的设计。

这一理念已融入这些技能的每一个层面：

• /to-spec技能会在你编写需求规格之前，让你判断自己将要修改哪些模块]

而且至关重要的是，/improve-codebase-architecture 会扫描代码库以找出优化机会，并将候选方案呈现给你。我建议每隔几天在您的代码库上运行一次该工具。它只是用于扫描，而非自动修复：在真正陈旧的代码库中，它确实能找到可优化的点，但无法替您理清复杂的混乱状况。

总结

软件工程的基础知识比以往任何时候都更为重要。这些技能是我将这些基础转化为可重复实践的最佳尝试，旨在帮助您打造职业生涯中最出色的应用。祝使用愉快。

参考

这些技能可根据调用者进行分类。用户调用的技能只有在您手动输入时才能使用（例如 /grill-me）；它们的作用是进行协调。模型调用的技能既可以由您手动触发，也可以在任务适合时由智能体自动调用；它们承载着可复用的规则体系。一个用户调用的技能可以调用模型调用的技能，但绝不能调用另一个用户调用的技能。

工程实践

我日常用于代码工作的技能。

用户调用的

• ask-matt — 询问哪种技能或流程适合当前情况。该工具是此仓库中用户调用技能的路由器。
• grill-with-docs — 一种审查会议，同时用于构建项目的领域模型，明确术语，并实时更新CONTEXT.md和ADR文档。
• triage — 通过分拣角色构成的状态机来处理问题。
• improve-codebase-architecture — 扫描代码库以找出优化机会，以可视化HTML报告的形式展示这些机会，随后针对您选择的选项进行深入审查。
• setup-matt-pocock-skills — 配置此仓库以支持各种工程技能（问题跟踪器、分拣标签、领域文档布局）。在使用其他工程技能之前，需为每个仓库运行一次该命令。
• to-spec — 将当前的对话转化为规范文档，并将其发布到问题跟踪器中。无需面试——只需综合已讨论的内容即可。
• to-tickets — 将任何计划、规范或对话拆解为一组带追踪链接的任务单，每张任务单都会注明其依赖关系——这些内容可以以文本形式存储在本地文件中，也可以直接作为真实问题跟踪器上的链接呈现。
• implement — 根据规范或任务单的内容进行开发，在预先约定的节点执行/tdd操作，并在提交代码前通过/code-review完成最终确认。
• wayfinder — 为规模庞大的工作任务制定计划，这类任务超出了单次智能体会话的处理能力，该工具会在问题跟踪器上以共享地图的形式展示各类决策任务——逐个解决这些任务，直到通向目标的路径清晰可见。

模型调用的

• prototype — 构建一个临时原型来回答设计问题——针对状态/逻辑问题，可创建一个可共享的 HTML 文件；或者针对几种截然不同的 UI 变体，通过单个路由实现切换。
• diagnosing-bugs — 针对难以解决的漏洞及性能退化问题，采用规范的诊断流程：建立反馈循环，即发现漏洞 → 最小化影响 → 提出假设 → 添加调试工具 → 修复问题 → 进行回归测试。
• research — 基于可信度高的原始资料对问题展开调查，并将调查结果以带引用标记的 Markdown 文件形式保存在代码仓库中，该流程可作为后台任务运行。
• tdd — 采用测试驱动开发模式，并结合红-绿-重构循环。每次只针对一个功能模块或一个漏洞进行开发或修复。
• domain-modeling — 积极构建并完善项目的领域模型——对照术语表检验相关术语，通过边界情况对模型进行压力测试，并实时更新CONTEXT.md及 ADR 文件。
• codebase-design — 为深层模块的设计制定统一的规范与术语标准：在简洁的接口背后实现大量功能，且该接口具备可测试性。
• code-review — 对自某个固定点之后的代码差异进行双维度审查：标准维度（是否遵循代码仓库的编码规范以及 Fowler 恶臭代码基准？），规范维度（是否完整实现了最初的 issue 或规范要求？），这两个审查流程作为并行子任务运行，从而避免相互干扰。
• resolving-merge-conflicts — 逐块处理正在进行的 git 合并或 rebase 过程中产生的冲突，根据每侧原始资料所体现的意图来解决问题，之后再完成整个操作——绝不能--abort。
• wizard — 生成交互式 bash 向导，引导用户完成仅其本人能执行的操作：配置基础设施、设置凭证或 CI 密钥、操作不熟悉的第三方控制面板，或执行一次性迁移或切换操作。

生产力工具

通用工作流工具，而非针对代码的专用工具。

用户触发

• grill-me — 不断对某个计划或设计进行追问，直到设计树的每一个分支都得到解决。
• handoff — 将当前的对话整合成一份交接文档，以便其他智能体能够继续处理工作。
• teach — 通过多轮对话向用户传授新技能或概念，以当前目录作为具有状态的教学工作空间。
• to-questionnaire — 将那些你无法独自解答的决策转化为 Markdown 问卷，发给唯一能解答的人——可以异步填写，也可以在会议中一起填写。该问卷会针对发送内容（发送给谁、需要对方反馈什么）进行提问，而非主题本身。
• wait-what — 一旦消息未被正确理解，立即触发此指令。智能体会用通俗的英语，并结合你的CONTEXT.md词汇表，补充你缺失的背景信息后重新提出问题。

模型调用相关

• grilling — 不断对用户的计划、决策或想法进行追问，直到设计树的每一个分支都得到解决。这是grill-me、grill-with-docs、triage、wayfinder和improve-codebase-architecture背后所使用的可复用追问机制。
• writing-for-agents — 为智能体编写文档：包括技能说明、AGENTS.md/CLAUDE.md，以及智能体通过链接能够访问的任何文档。