ask-matt
ask-matt

什么是 ask-matt

如果你在 Claude Code、Cursor 或者 Codex 里装过 Matt Pocock 的那套 Skills，大概率会有这种体验——装的时候觉得“哇这么多技能”，真正用起来的时候，翻来覆去就用了那么两三个。剩下的十几个技能躺在列表里吃灰，不是没用，而是根本不知道什么时候该用哪个、用完了下一步该接什么。

ask-matt 就是专门解决这个问题的。

它是 Matt Pocock 工程技能体系里的一个路由器（router）。它自己不写代码、不修 bug、不画架构图。它只做一件事：根据你当前面临的情况，在这套工作流里告诉你用哪个命令、走哪条路径。

说白了，ask-matt 就是这套技能体系的导航仪。你不需要记住每一个 skill 是干什么的，遇到问题直接问 ask-matt 就行。

核心功能

技能路由与推荐

ask-matt 的核心功能是一个路由器——你把一个真实的任务或问题扔进去（比如“帮我重构这个模块”或者“这个功能该怎么落地”），它会先分析任务的性质，然后推荐最合适的技能组合和流程。它知道什么时候该用 /grill-with-docs 打磨想法，什么时候该用 /to-spec 写规格，什么时候该直接 /implement 开干。

主流程导航：从想法到交付

ask-matt 管理的所有技能，按照一条统一的主路组织——idea → ship（从想法到交付）。这条主路覆盖了 90% 的日常编码工作。主路经过以下几个阶段：

  • 打磨想法：用 /grill-with-docs（有代码库时）或 /grill-me（纯构思时）通过不断追问把模糊的想法磨锋利

  • 原型验证（可选分支）：遇到“这个交互到底行不行”这种必须跑起来才知道的问题时，用 /prototype 快速验证

  • 写规格：用 /to-spec 把讨论和决策整理成结构化的规格文档

  • 拆票：用 /to-tickets 把规格拆成可独立执行的任务

  • 实现：用 /implement 驱动 TDD 流程，一个红绿循环接一个

  • 代码审查：用 /code-review 做双轴审查（规范 + 规格）

多场景入口

除了主路，ask-matt 还能处理三种特殊情况：

  • 匝道（On-ramps） ：从 bug 修复、issue 处理等特定场景汇入主路

  • 代码健康：日常维护，改善架构、重整模块

  • 独立工具：完全不经过主路的场景——研究、原型、学习

会话边界管理

当工作跨越多个会话时，ask-matt 会用 /handoff 来衔接。它把当前对话压缩成一份 Markdown 文件，你可以在新会话中引用它继续。同时它也强调上下文卫生——在拆票之前不要压缩或清空会话，确保打磨、规格、拆票都基于同一套思考。

安装方法

ask-matt 的安装依赖 Node.js 环境和一个 AI 编程助手（Claude Code、Cursor、Codex、Windsurf 等均可）。

环境准备

确保你的机器上有 Node.js 16 或更高版本：

bash
node --version

如果没装，去 Node.js 官网下载安装。

安装 ask-matt

方式一：通过 npx 安装（推荐）

在终端执行以下命令：

bash
npx skills add https://github.com/mattpocock/skills --skill ask-matt

这条命令会从 Matt Pocock 的 GitHub 仓库下载并配置 ask-matt skill。

方式二：全局安装（SkillsAuth）

bash
npx skillsauth add mattpocock/skills ask-matt

这个方式适用于 Claude Code、Cursor 和 Windsurf。

方式三：在 Codex 中安装

在 Codex 插件市场中搜索 codex-real-engineering-skills:ask-matt 即可安装。

安装完整技能集

ask-matt 只是 Matt Pocock 工程技能体系的一部分。如果你想要完整的 18 个命令，可以安装整个技能包：

bash
npx skills add https://github.com/mattpocock/skills

安装完成后，重启你的 AI 编程助手让新技能生效。

可选：启用自动引导

ask-matt 支持一个可选的启动引导功能——在会话开始时自动注入路由摘要，让模型自动发现 ask-matt 而不用你手动调用。默认是关闭的，因为 /ask-matt 短命令对大多数用户来说已经够用了。如果你需要开启，可以用 /matt-bootstrap on 命令。

适用场景

刚装了 Matt Pocock 的技能包不知道从哪开始

这是 ask-matt 最典型的使用场景。你装了十几个技能，却不知道哪个是干什么的。直接问 ask-matt——“我现在有一个想法，想做一个小工具，该怎么开始？”它会告诉你从 /grill-with-docs 开始。

做到一半不知道下一步该用什么

你已经在用 /grill-with-docs 打磨想法，打磨完了之后该用哪个？是 /to-spec 还是直接 /implement？ask-matt 会根据你的具体情况给出建议。

遇到 bug 不知道怎么处理

修 bug 修到一半发现根因是架构问题，不知道该切哪个命令。ask-matt 会告诉你走“Something's broken”匝道，用 /diagnosing-bugs 来定位问题。

不确定当前任务是否需要拆成多个会话

一个功能比较复杂，不知道是应该在一个会话里做完，还是拆成多个会话。ask-matt 会根据任务的复杂度给出判断——如果是多会话构建，走 /to-spec → /to-tickets 路线；如果不是，直接在当前会话里 /implement。

想学习这套工作流的设计思路

ask-matt 不仅是导航工具，也是理解 Matt Pocock 工程哲学的门户。通过 ask-matt 的指引，你会逐渐理解为什么“从想法到交付”要经过打磨→规格→拆票→实现→审查这五个环节。

使用案例

案例一：从一个模糊想法开始

你在 Claude Code 里输入：

“/ask-matt 我想给项目加一个多格式导出功能，目前只能导出 CSV，想支持 PDF 和 Excel。”

ask-matt 分析后告诉你：这是一个新功能开发任务，建议走主流程——先用 /grill-with-docs 打磨需求，然后 /to-spec 写规格，再 /to-tickets 拆票，最后 /implement 实现。

你按照这个路线走完，整个功能从想法到交付一气呵成。

案例二：不知道用什么命令

你装了 Matt Pocock 的 Skills 之后，想修一个 bug，但不知道该用哪个命令。你在 AI 助手里输入：

“/ask-matt 我有个 bug 要修，该用什么流程？”

ask-matt 会告诉你：走“Something's broken”匝道，用 /diagnosing-bugs 先定位问题根因，然后再决定是走主路修复还是需要更深入的架构调整。

案例三：判断是否需要做原型

你在打磨一个 UI 交互方案的时候，不确定某个交互方式是否可行。你问 ask-matt：

“/ask-matt 这个交互方式不确定能不能跑通，要不要先做个什么东西试试？”

ask-matt 会告诉你：这种情况适合走原型分支——用 /handoff 把当前上下文导出，开一个新会话用 /prototype 快速验证，验证完用 /handoff 把学到的内容带回来。

案例四：多会话构建的决策

你准备做一个比较大的功能，不确定是否应该在一个会话里完成。你问：

“/ask-matt 这个功能估计要搞两天，应该怎么安排？”

ask-matt 会判断这是多会话构建，建议走 /to-spec 写规格 → /to-tickets 拆成独立任务 → 每个任务开新会话用 /implement 实现。同时提醒你：在拆票之前不要压缩或清空会话，保持上下文连续。

注意事项

ask-matt 是路由器，不是执行器。 它自己不写代码、不修 bug。它的作用是告诉你“用哪个”，而不是“帮你做”。你得到建议之后，还需要手动调用对应的命令。

它导航的是 Matt Pocock 的技能体系，不是所有 skill。 ask-matt 管理的是 Matt Pocock 精心设计的那套工程技能流程。如果你装的是其他作者的 skills，ask-matt 管不着。

自动引导默认是关闭的。 ask-matt 支持在会话启动时自动注入路由摘要，但默认是关闭的。对大多数用户来说，手动输入 /ask-matt 已经足够了。如果你确实想开启，用 /matt-bootstrap on 命令。

保持上下文卫生。 ask-matt 的设计者明确建议：在打磨想法、写规格、拆票这三个步骤完成之前，不要压缩或清空会话。否则会丢失关键的上下文信息，影响后续实现的质量。

超过智能区就 handoff。 如果会话接近模型的智能区上限（约 15 万 token），不要硬撑——用 /handoff 导出上下文，在新会话里继续。