1. 为什么你的 coding agent 总是跑偏从 Matt Pocock Skills 工作流说起如果你用 Claude Code、Cursor 或者 Codex 这类 coding agent 写过稍微大一点的功能大概率遇到过这种情况一开始聊得挺好模型也点头说明白了结果它写出来的代码跟你脑子里的方案差了十万八千里。你回头翻聊天记录发现它在某个环节自己脑补了一个假设然后一路错到底。Matt Pocock Skills 这套工作流本质上就是来解决这个问题的。它把从想法到代码拆成了一条有明确关卡的流水线先用 slash command 把模糊的想法逼问清楚再沉淀成 spec 文档锁定方向然后把 spec 拆成一个个 ticket最后用/implement一个 ticket 一个 ticket 地实现。每个 skill 边界清楚大部分需要你手动用 slash command 触发而不是让 agent 自己乱猜该干什么。这套东西适合谁我觉得有三类人特别值得试一是已经在用 coding agent 但总觉得它不听话的开发者二是团队里想把 agent 协作流程标准化的技术负责人三是刚开始接触 agent 编程、想建立正确工作习惯的新手。它不是什么魔法核心思想就一句话——把人的决策点和模型的执行点分开。我试过在几个真实仓库里跑这套流程最大的感受是以前我总想着一口气把需求描述完让模型开干现在我会先花十分钟跟它吵架把边界条件、技术选型、不做什么都聊清楚。这十分钟省下的返工时间往往是几个小时。下面我会按原问题与场景 → 前置准备 → 可复制配置 → 验证请求 → 常见报错排查 → 落地建议的顺序把 slash command、spec、ticket 三者的协作关系和触发时机拆开讲每一步都给可复制的片段。2. 前置准备TaoToken 接入与 Matt Pocock Skills 环境搭建在跑这套工作流之前你得先有一个能稳定调用模型的入口。Matt Pocock Skills 本身是一组给 coding agent 用的 skill 定义它需要底层有一个支持长上下文、工具调用的模型服务。这里我用 TaoToken 作为接入层来演示因为它对 Claude Code、Codex、Cline 这些常见客户端的兼容做得比较直接Base URL 和 Key 的配置方式统一。先说清楚 TaoToken 是什么它是一个模型 API 聚合接入服务你可以把它理解成一个统一的模型网关用一套 Key 和 Base URL 就能调用不同厂商的模型。官网在 https://taotoken.netAPI 端点是 https://taotoken.net/api。对于 Matt Pocock Skills 这种需要频繁切换模型、跑长上下文的工作流来说统一入口能省掉很多配置麻烦。环境准备分三步走。第一步拿到 API Key。登录后进控制台在 API Keys 页面创建一个新 Key。建议按项目或按用途分开建 Key比如matt-skills-dev专门给这套工作流用方便后面排查问题时定位。创建后立刻复制保存页面刷新后就看不到了。第二步确认你的 coding agent 客户端。Matt Pocock Skills 主要围绕 Claude Code 设计但核心的 slash command 思路在 Cline、Codex 里也能复用。如果你用 Claude Code配置走~/.claude/settings.json或者项目级的.claude/settings.json如果用 Cline走 MCP 配置如果用 Codex走~/.codex/auth.json。第三步把 Matt Pocock Skills 装进项目。这套 skill 的安装方式是在项目里创建.claude/skills/目录把各个 skill 的 markdown 定义放进去。每个 skill 对应一个 slash command比如/grill-with-docs、/to-spec、/to-tickets、/implement。安装完成后你在 Claude Code 里输入/就能看到这些命令。这里有个容易踩的坑很多人以为装完 skill 就能直接用其实还要先跑一次/setup-matt-pocock-skills。这个命令的作用是让其它 skill 知道这个项目怎么组织、用什么工具、有什么约定。它相当于给整个工作流做一次初始化把项目的技术栈、目录结构、测试命令这些信息登记下来。跳过这一步后面的/to-tickets和/implement会因为不知道项目上下文而给出很泛的建议。关于模型选择Matt 在直播里反复强调一个数字每个 ticket 的解决窗口不要超过 150k token100k 以内是模型的聪明区。这意味着你在配置模型时要优先选长上下文版本同时在/implement阶段严格控制一次处理的 ticket 数量。我一般是一个窗口解决一个 ticket复杂点的 ticket 甚至要拆成两个窗口。3. 可复制配置slash command、spec 模板与 ticket 拆分片段这一节是整篇的核心我把三个关键环节的配置片段都写出来你可以直接复制到自己的仓库里改。3.1 Claude Code 的 settings.json 配置先解决接入层。在项目根目录创建.claude/settings.json写入以下内容{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥, ANTHROPIC_MODEL: claude-sonnet-4-5-20250929 }, permissions: { allow: [ Read, Write, Edit, Bash(git:*), Bash(npm:*), Bash(pnpm:*) ] } }注意ANTHROPIC_BASE_URL后面不要加/v1TaoToken 的端点就是https://taotoken.net/api。模型 ID 按你实际要用的填Claude 系列和 GPT 系列都支持。如果你用 Codex对应的~/.codex/auth.json长这样{ OPENAI_API_KEY: sk-你的TaoToken密钥, OPENAI_BASE_URL: https://taotoken.net/api }Cline 走 MCP 的话在 MCP 配置里填 Base URL 和 KeyModel ID 选你要用的那个。三件套Base URL Key Model ID缺一不可少一个就会报 401 或者 model not found。3.2 slash command 的触发时机Matt Pocock Skills 的 slash command 不是随便用的每个都有明确的触发时机。我把主干流程的触发条件整理成一张表Slash Command触发时机产出物/setup-matt-pocock-skills每个 repo 只跑一次项目约定登记/grill-with-docs已有仓库想法还模糊时决策记录/to-spec讨论达成共识后spec 文档/to-ticketsspec 确认后多个 ticket/implement每个 ticket 单独触发代码实现/code-reviewticket 完成后新开会话审查报告关键点是/grill-with-docs和/grill-me的区别前者适合项目本身已经存在的仓库后者适合项目雏形还没建仓库时的头脑风暴。如果你在做一个全新项目先用/wayfinder做方向决策它内置了/grill-me等 skill更适合大型项目。3.3 spec 模板/to-spec生成的 spec 文档我建议你手动检查一下是否包含这几个部分。一个合格的 spec 模板长这样# Spec: 用户认证模块重构 ## 背景 当前认证逻辑散落在三个文件里新增 OAuth 登录时改动面过大。 ## 目标 - 把认证逻辑收敛到单一模块 - 支持邮箱密码 OAuth 两种方式 - 保持现有 API 兼容 ## 非目标 - 不做权限系统重构 - 不改数据库 schema ## 技术决策 - 使用 passport.js 作为策略层 - session 存储沿用现有 Redis ## 验收标准 - 现有测试全部通过 - 新增 OAuth 登录的集成测试 - 手动验证两种登录方式注意非目标这一节特别重要。Matt 在直播里强调spec 里写清楚不做什么比写做什么更能防止 agent 跑偏。模型看到非目标就不会自作主张去改权限系统。3.4 ticket 拆分示例/to-tickets会把 spec 拆成 agent 可以分别处理的小 ticket。一个好的 ticket 应该满足单个 ticket 的上下文窗口在 100k 以内有明确的验收标准不依赖其它未完成的 ticket。拆分示例## Ticket 1: 抽取认证核心逻辑 - 把 validateCredentials 从 authController 移到 authService - 保持函数签名不变 - 验收现有单元测试通过 ## Ticket 2: 接入 passport 策略层 - 依赖 Ticket 1 - 实现 LocalStrategy 和 OAuthStrategy - 验收新增策略层单元测试 ## Ticket 3: 迁移路由 - 依赖 Ticket 2 - 把 /login /logout 路由切到新模块 - 验收集成测试通过拆完之后用/implement一个 ticket 一个 ticket 地做。Matt 的建议是让模型implement tickets one by one不要一次性解决全部。我实测下来一个窗口处理一个 ticket代码质量和可控性都明显更好。4. 验证请求跑通一次完整流程并确认结果配置写完了接下来要验证这套流程真的能跑通。我按顺序给你可执行的验证动作。第一步验证接入层。在项目根目录打开 Claude Code输入一个最简单的请求请读取 package.json 并告诉我项目用了什么测试框架如果模型能正确读取文件并回答说明 Base URL 和 Key 配置没问题。如果报 401回去检查 Key 是否复制完整如果报 model not found检查 Model ID 拼写。第二步跑初始化。输入/setup-matt-pocock-skills这个命令会扫描项目结构登记技术栈和约定。跑完后你应该能在.claude/目录下看到生成的配置文件。如果它问你项目用什么包管理器、测试命令是什么如实回答。第三步验证/grill-with-docs。找一个你最近想改但还没想清楚的功能输入/grill-with-docs 我想给用户模块加一个邀请机制它会开始追问你邀请链接的有效期多久被邀请人注册后给什么奖励邀请上限是多少这些问题的答案会被记录下来。这一步的产出不是代码是一份决策记录。第四步验证/to-spec。讨论得差不多了输入/to-spec它会把你刚才的讨论整理成一份 spec 文档。打开看看重点检查非目标和验收标准两节是否完整。第五步验证/to-tickets。spec 确认后输入/to-tickets它会生成多个 ticket。你可以选择让它在本地生成 markdown 文件或者直接创建 GitHub issue。我一般选本地方便先审一遍再决定要不要同步到 issue。第六步验证/implement。挑一个最简单的 ticket输入/implement ticket-1观察它是否只处理这一个 ticket有没有越界去改其它文件。完成后跑一遍测试确认验收标准满足。第七步验证/code-review。新开一个会话输入/code-review这一步为什么要新开会话因为模型对自己写的代码有种自信让它自测容易漏掉条件。切到新窗口后它会对照项目标准和原始 spec 检查有没有开发方向错误。整套流程跑下来你应该能感受到每个环节的边界感讨论归讨论spec 归 spec实现归实现审查归审查。这种分离是这套工作流最大的价值。5. 常见报错排查401、local proxy failed、reading choices 与 OAuth 问题跑这套流程时报错主要集中在接入层和 skill 调用层。我把几个高频报错和排查路径列出来。401 Unauthorized。这是最常见的。原因通常是 Key 没填对、Key 过期、或者 Base URL 写错了。排查顺序先确认ANTHROPIC_API_KEY或OPENAI_API_KEY的值是不是完整的有些客户端会截断长 Key再确认 Base URL 是https://taotoken.net/api而不是带/v1的版本最后去 TaoToken 控制台确认 Key 状态是否正常。如果三件套Base URL Key Model ID里任何一个缺失都会报 401 或类似的认证错误。local proxy failed。这个报错通常出现在客户端配置了本地代理但代理没启动或者代理端口被占用。排查方法检查客户端设置里有没有开启本地代理选项如果有就关掉直接用 Base URL 直连。另外确认你的网络环境能正常访问taotoken.net可以用curl https://taotoken.net/api测试连通性。reading choices 相关报错。这个一般出现在响应格式解析阶段说明客户端期望的响应结构和实际返回的不一致。常见原因是 Model ID 填错了比如把 Claude 的模型 ID 填到了 OpenAI 兼容的客户端里。解决方法是确认你用的客户端和 Model ID 匹配Claude Code 用 Claude 系列 IDCodex 用 GPT 系列 ID。OAuth 相关报错。如果你在/implement阶段遇到 OAuth 报错先确认是不是 ticket 本身涉及 OAuth 实现。如果是检查 spec 里有没有写清楚用哪个 OAuth provider、回调地址是什么。这类报错往往不是接入层问题而是 spec 不够具体导致模型猜错了实现方式。回到/to-spec补充细节重新拆 ticket。skill 不触发。输入/grill-with-docs没反应通常是 skill 文件没放对位置。确认.claude/skills/目录下每个 skill 的 markdown 文件命名正确且文件头部的 frontmatter 格式没问题。另外/setup-matt-pocock-skills必须先跑一次否则其它 skill 不知道项目上下文。ticket 越界。/implement时模型改了 ticket 范围外的文件。这是上下文窗口太大的典型症状。解决办法是缩小 ticket 粒度或者在新窗口里重新/implement明确告诉它只处理 ticket-N不要动其它文件。排查这类问题的通用思路是先确认接入层Base URL Key Model ID再确认 skill 层文件位置 初始化最后确认内容层spec 和 ticket 是否足够具体。大部分报错在前两层就能定位。6. 落地建议把 Matt Pocock Skills 变成你的日常习惯跑通一次不代表能坚持用。我分享几个让它变成习惯的实操建议。第一把/grill-with-docs当成默认起点。以前你可能习惯直接说帮我实现 X现在改成先说我想做 X你先问我几个问题。这个习惯转变需要刻意练习但一旦养成返工率会明显下降。第二spec 文档进版本控制。/to-spec生成的文档不要只放在聊天记录里提交到仓库的docs/specs/目录。这样下一个接手的人或者下一个会话的 agent能直接读到上下文。第三ticket 粒度宁小勿大。Matt 建议的 150k 窗口上限是硬约束但实际操作中我建议按 100k 来控。一个 ticket 如果描述超过 200 字大概率需要再拆。第四/code-review必须新开会话。这一点我踩过坑在同一个会话里让它自测它会把之前实现时的假设带进来审查形同虚设。新窗口 原始 spec才能起到交叉验证的作用。第五善用分支 skill。当设计问题需要跑代码才能回答时绕到/prototype当任务跨多个 session 时先/to-spec再/to-tickets。这两个分支是主干流程的补充不要硬塞进主干。第六长期编码和 Agent 任务可以考虑用 Coding Plan 来承载把模型调用和额度管理交给专门的方案你专注在流程本身。如果你还在选模型阶段可以先去模型对话页面实际对比几个模型在/grill-with-docs追问环节的表现选一个追问质量高的。这套工作流的核心不是工具是纪律。slash command、spec、ticket 三者协作的本质是强迫你在正确的时间做正确的决策讨论时充分讨论锁定方向后不轻易改实现时一次只做一件事审查时换一双眼睛。把这套纪律内化成习惯比记住多少个 slash command 更重要。