前言

Matt Pocock 是 TypeScript 圈的知名开发者，他把自己日常使用的 AI 编程方式沉淀成了一套技能组合：wayfinder、to-spec、to-tickets、implement、code-review。这五个技能不是零散的提示词，而是一条按顺序执行的工程化工作流。

这套流程的核心目标，是把一个模糊的想法，通过严格的工程纪律，逐步转化为可执行、高质量的代码。它解决的矛盾是：AI 的会话是一次性的，但工程不是。

核心工作流概览

flowchart LR
    A[模糊想法] --> B[wayfinder 规划]
    B --> C[to-spec 规格化]
    C --> D[to-tickets 任务化]
    D --> E[implement 实现]
    E --> F[code-review 审查]
    F --> G[高质量代码]

wayfinder 负责把模糊想法变成决策地图，to-spec 把决策整理成规格说明，to-tickets 把规格拆成可独立完成的工单，implement 按工单用 TDD 实现，code-review 在提交前做双轴审查。下面逐一解析。

wayfinder：规划者

作用：当一个想法太大、太模糊，单个 AI 会话装不下时，wayfinder 负责规划而不是执行。它会将大块工作拆解成一张决策地图，地图上的每个节点都是一张决策票证，也就是一个需要回答的问题，而不是一个需要完成的任务。wayfinder 会逐一解决这些决策问题，直到通往目标的路径清晰。这个阶段只做调研和规划，不写任何实现代码。

何时使用：当你对要做什么只有一个模糊概念，或者工作范围大到需要多次会话才能完成时。

简单示例：你有一个模糊的想法，想做一个博客平台。运行 /wayfinder 后，AI 会和你一起探索，创建一系列决策票证：

  • 用户如何登录，用邮箱密码还是 OAuth
  • 文章如何存储和获取，数据库怎么选型，API 怎么设计
  • 前端界面长什么样，用 SPA 还是服务端渲染

当这些关键决策都确定后，路就找到了，wayfinder 阶段完成。

to-spec：规格化

作用：将 wayfinder 阶段（或之前对话中）已经讨论过的内容，综合整理成一份结构化的规格说明（Spec），并发布到项目的问题跟踪器（如 GitHub Issues）。这个技能不会向你提问，只负责整理已知信息。产出的 Spec 类似产品需求文档（PRD），包含问题描述、解决方案、用户故事、实施决策等。

何时使用：在 wayfinder 完成后，或者在你和 AI 讨论清楚需求之后。

简单示例：承接博客平台的例子，运行 /to-spec 后，AI 会根据之前的讨论生成一份规格说明，内容可能包括：

  • 用户故事：作为一个访客，我想浏览文章列表，以便找到感兴趣的内容
  • 实施决策：使用 PostgreSQL 作为数据库，使用 React 构建前端
  • 测试决策：对 API 端点进行集成测试

to-tickets：任务化

作用：把上一阶段生成的 Spec 拆解成一组曳光弹式（Tracer Bullet）的垂直切片工单。每张工单都是一个端到端、可独立演示或验证的完整功能切片，并且明确声明阻塞关系（Blocking Edges），也就是哪些工单必须先完成。

何时使用：在 Spec 生成之后，准备开始编码之前。

简单示例：AI 会把博客平台的 Spec 拆解为：

  • Ticket 1：搭建项目基础架构，无阻塞
  • Ticket 2：实现文章列表页，阻塞 Ticket 1
  • Ticket 3：实现文章详情页，阻塞 Ticket 1
  • Ticket 4：实现用户登录功能，阻塞 Ticket 1
  • Ticket 5：实现文章创建功能，阻塞 Ticket 1 和 Ticket 4

每张工单都是可独立工作的垂直切片，依赖关系一目了然。

implement：执行者

作用：根据 Spec 或工单列表构建代码。它驱动 TDD（测试驱动开发）流程，一次只构建一张工单，确保代码质量。在提交之前，必须调用 /code-review 进行审查，保证每次提交的代码都是经过审查的。

何时使用：在工单准备好之后，开始逐个实现。

简单示例：准备实现文章列表页时，运行 /implement，AI 会先为文章列表 API 和前端组件编写测试，再写代码让测试通过（红灯变绿灯），然后重构。完成后自动触发 /code-review 进行审查。

code-review：审查者

作用：从两个独立维度对代码变更进行并行审查：

  • 标准（Standards）：代码是否符合项目的编码规范和最佳实践，如命名、重复代码等
  • 规格（Spec）：代码是否忠实地实现了原始 Issue 或 PRD 中描述的需求

两个审查由并行子代理完成，互不干扰，最后汇总成一份并排的审查报告。

何时使用：在 /implement 完成一张工单后自动调用，也可以单独对某个分支或 commit 运行。

简单示例：对文章列表页的代码变更，审查报告会给出：

  • 标准审查：发现一处命名不规范，getData 应改为 fetchArticles，建议修改
  • 规格审查：代码实现了文章列表的获取和展示，符合 Spec 中访客浏览文章列表的要求

一个完整示例：添加用户个人资料页面

假设你想为项目添加一个用户个人资料页面功能，完整流程如下。

  1. 启动规划，输入 /wayfinder，AI 会与你讨论关键决策：资料包含哪些字段、如何编辑资料、是否需要头像上传。这些决策被记录为决策票证。产物是一组已解决的决策票证，通往目标的路径已清晰。
  2. 生成规格，输入 /to-spec，AI 根据讨论生成用户个人资料页面的 Spec，包含用户故事、实施决策等，并发布到 Issue Tracker。产物是一份结构化的 Spec 文档，比如 GitHub Issue 101。
  3. 拆解任务，输入 /to-tickets，AI 把 Spec 拆成多张工单：Ticket A 创建用户资料数据模型和 API（无阻塞），Ticket B 实现资料页面 UI 和交互（阻塞 Ticket A），Ticket C 实现头像上传功能（阻塞 Ticket A）。产物是一组有依赖关系的工单列表。
  4. 执行任务，输入 /implement 加上工单编号，比如 /implement 102，AI 用 TDD 方式实现用户资料数据模型和 API。产物是可工作的代码变更。
  5. 审查代码，AI 在 /implement 完成后自动执行 /code-review，从标准和规格两个维度审查代码变更，给出审查报告。修复问题后即可提交代码。

重复第 4 和第 5 步，依次实现 Ticket B、Ticket C，直到整个功能完成。

一些额外提示

  • 流程顺序很重要：这个工作流的顺序是精心设计的，建议按部就班执行。
  • 保持上下文：从 wayfinder 到 to-tickets 的过程最好在同一个会话中完成，确保信息不丢失；每个 implement 建议从全新会话开始，只聚焦当前这一张工单，避免上下文过载。
  • 核心原则：wayfinder 只负责规划和提问，不写代码；to-spec 只整理信息，不提问；implement 必须走 TDD，提交前必须经过 review。
  • 想在项目中落地这套技能，先运行 /setup-matt-pocock-skills 配置环境，再按流程走。