/handoff，只有几行，却是Matt Pocock调用频率最高的 skill

和 Claude Code 对话时，每次工具调用、每次文件编辑都在往上下文窗口里塞 token。厂商说窗口有 100 万 token，但聊到后面它开始忘事，方案也越来越敷衍。

Matt Pocock 也遇到了这个问题。他的解决办法短到离谱——一个叫/handoff的 skill，内容只有几行，结果成了他自己用得最多的那个。他的 skill 仓库目前 18 万星， 是他最依赖的。

AI 聊到后面会变蠢，不是你的错觉

Matt 把上下文窗口分成两段：聪明区和愚蠢区。

对话刚开始时 token 少，模型输出精准。后面 token 多了，注意力在所有内容上摊薄，agent 在大量无关信息里迷路。Matt 的实际体感是，120K token 左右就进入愚蠢区了。

厂商标 100 万，真正好用的也就前面 12 万。这个数字不是理论值，是 Matt 反复用出来的经验线。

---

Compact 能用，但它是单行道

Claude Code 内置的 Compact 做的就是这件事：把对话摘要成一段精简文本，塞进新会话开头，继续干活。

摘要里是引用过的文件列表、对话要点、整体基调。压缩成一小块，后面追新内容时持续引用。

每次 compact 像铺一层沉积物。旧对话压成摘要，新对话往上堆。调试的时候，把所有试过的方案 compact 掉，保留当前状态，继续试。这很适合死磕同一个问题。

但问题也很明确：Compact 只能在单个会话内接力。

你需要的是另一件事——把当前对话里和某个 bug 相关的部分切出来，新开一个独立会话去修。当前会话不动、不受影响。Compact 做不到。它要么压缩整个会话，要么你就硬撑。

---

三条指令的事

Matt 的 handoff 做的事：

当前会话 → 总结成 Markdown → 存到临时目录 → 粘贴到新会话

假设你正在写一个 Remotion 视频组件，会话已经跑了 80K token。agent 刚帮你调完  里的 3D 粒子效果，但你突然想到——视频的转场动画还用的是默认 fade，应该换成自定义的 slide-left。

这事跟当前任务无关。硬塞进这个会话的话，上下文会逼近愚蠢区。

你在 Claude Code 的输入框里敲：

/handoff 把视频所有转场从默认 fade 替换为自定义 slide-left 动画，
 参考已有的 Transition 组件风格，先做一个全局搜索列出所有需要改的地方，
 再逐个替换。改完跑一次 npx remotion render 验证。

Agent 在终端打印了一行：

✓ handoff document written to C:\Users\dingAI\AppData\Local\Temp\handoff-20260730-142105.md

你打开这个文件，里面是结构化的一段 Markdown——当前项目的视频框架信息、已有的 Transition 组件路径、之前讨论过的转场设计原则、一段建议加载的 skill，但没有重复任何已有的代码内容。

然后你新开一个 Claude Code 窗口，把这份 Markdown 粘贴进去。新会话的 agent 读到第一行就明白了上下文，直接开始全局搜索所有  转场。跑完 75K token，全改好了，验证通过。

你原来的会话毫发无损，继续调粒子效果。

和 Compact 的区别就一个：Compact 是压缩加延续，handoff 是压缩加分叉。主会话继续推进，子会话独立处理分出去的那件事。

Matt 自己用这个用疯了。比如做一个 grilling session，让 AI 反向追问需求、梳理项目规划，进行到一半他突然意识到"迭代和完成信号应该拆成独立 API"。这事超出了 grilling 的范围。

他直接说：把这个任务 handoff 给另一个 agent。skill 生成了一份 20 行的 Markdown，有聚焦点、建议加载的 skill、绝不重复已有内容。

同时完成了两件事：grilling 立刻收束回了核心问题，而那个 API 拆分任务没丢，新会话拿着 handoff 独立推进。

---

出去探路，再回来

第二种用法更有意思。

Grilling 过程中，agent 追问一些不看到代码没法回答的问题——UI 交互怎么设计？复杂逻辑的边界条件？Matt 的做法是当场 handoff 出去做原型。

流程：grilling 生成 handoff，新会话做原型（这个原型会话跑了 169K token，远超 grilling 能装下的量），原型跑完后，再生成一份 handoff，总结学到了什么、哪些结论不是一眼能看出来的，然后传回 grilling。

去回一个闭环。

本质上是个手工的子代理：干净上下文做单一任务，压缩学习成果，传回父会话。

交接格式是 Markdown，所以不绑定 agent。Claude Code 发起，handoff 给 Codex，或者 Copilot CLI，完全看情况。

Matt 的原话是：想在几个不同 agent 之间做对抗性审查？Markdown 交接是最简单的方式。

---

5 条设计规则

handoff 这个 skill 短得要命，但每条规则背后都有反复踩坑的痕迹：

•  文档里列好下一个会话该加载什么，粘贴进去自动触发，不用自己记住每个 skill 的名字。

•  文件路径、GitHub Issue 链接当指针用。Matt 踩过的坑是 handoff 文档越长越大，全是复制粘贴已有内容，没意义。

•  这些文件是一次性的，不是文档，不该留在代码库里腐烂。

•  API key、密码、任何个人身份信息不能在 Markdown 里到处飘。

•  agent 不知道下一个会话要聚焦什么，就写不出有用的 handoff。Matt 每次都会口述目的，语音输入一开，一句话的事。

---

说真的

handoff 没有什么技术含量。它是一种工作习惯：关注上下文预算、一个会话只做一个任务、把交接当成常规动作而不是临时救火。

我自己用 Remotion 做视频开发就是这样——素材准备一个 session，合成一个 session，字幕一个 session。各干各的，上下文不污染。比任何 prompt 技巧都实在。

---

*基于 Matt Pocock 视频 "/handoff is my new favourite skill"（YouTube: dtAJ2dOd3ko）改写。配图为视频关键帧截图。*

**免责声明**：本文为基于原视频的二次创作，内容仅代表原作者观点。配图均为视频截图及原创设计图，仅供学习交流，版权归原作者所有。