什么是handoff？
如果你用AI编程助手做过稍微复杂一点的工作，大概遇到过这种情况：会话进行到一半，上下文窗口快满了，或者你想换个工具试试，但新开的会话对刚才讨论的几十轮内容一无所知。你只能手动复制粘贴，或者从头再解释一遍。
handoff就是来解决这个问题的。它是Matt Pocock开发的一个AI技能，做的事情很单一：把当前对话压缩成一份交接文档，让另一个AI智能体（或者同一个人换个工具之后）能无缝接上。
这个技能由用户主动通过 /handoff 命令触发，AI不会自己调用。它的输出是一份Markdown文件，保存在操作系统的临时目录里，而不是写进你的代码仓库。
Matt Pocock本人对它的定位很明确：handoff买的是“可移植性”，而不是“压缩” 。如果你的工作不需要从一个环境搬到另一个环境，你就不需要handoff——用/compact就够了。
什么时候该用handoff？
handoff不是用来解决“会话太长”这个问题的——那是/compact的活儿。handoff只用在四种情况：
换工具：从Claude Code换到Codex，或者从Cursor换到其他工具。新工具看不到旧会话的上下文，需要一份文档来传递信息。
换目录或仓库：你正在做一个原型，需要换个目录继续。或者从一个仓库切到另一个仓库。
把工作交给同事：同事用不同的工具，或者在不同的机器上。他们需要一份能读的东西来接上你的进度。
分支出一个并行任务：这是最容易被忽略但最有价值的使用场景。你正在做一个设计讨论，突然遇到一个问题“只有跑起来代码才知道答案”。你不想在当前会话里花时间搞这个分支，于是handoff一份给另一个会话去跑原型，拿到答案之后再handoff回来。
Matt Pocock在文档里特别强调了这一点：“分支（branching）是被大家跳过的用法。” 很多人把handoff理解成“结束当前会话、开启下一个会话”，那看起来确实不如/compact好用。但handoff真正的价值在于并行——你留在当前会话继续工作，同时派一个“分身”去另一个会话做实验。
交接文档里装了什么，不装什么
handoff生成的交接文档会包含：
当前进行中的工作：正在做什么、为什么做、接下来该做什么
建议的技能列表：告诉下一个AI智能体应该调用哪些技能
但handoff不会复制已经写下来的东西——规格说明、计划文档、ADR、Issue、commit、diff。这些东西已经存在于仓库里了，交接文档只会用路径或URL引用它们，而不是复制一份。这样做有两个好处：文档保持小巧，而且已确定的内容只有一个来源，不会出现两份文档互相矛盾的情况。
另外，handoff会在写入之前自动删除敏感信息——API密钥、密码、个人身份信息等不会被写进交接文档。
如何安装handoff
在终端中执行以下命令：
npx skills add https://github.com/mattpocock/skills --skill handoff
安装完成后，技能会自动配置到你的AI编程环境中，可以在Claude Code、Cursor或OpenClaw等工具中使用。
你也可以通过以下命令验证安装：
npx skills list
如何使用handoff
安装之后，在你的AI编程助手中输入：
/handoff 接下来要做什么
比如：
/handoff 继续完成用户认证模块的测试
AI会基于当前对话生成一份交接文档，保存在临时目录中。文档会包含一个“suggested skills”部分，建议下一个会话应该调用哪些技能。
如果你想把工作交接给同事或者切换到另一个工具，只需要把这份文档的内容提供给新的AI会话即可。
应用场景
场景一：切换AI工具
你一直在用Claude Code做需求分析，现在想用Codex来写代码。两个工具之间没有共享上下文。用/handoff生成一份交接文档，在Codex里打开新会话时把文档内容贴进去，Codex就知道你分析到什么程度了。
场景二：换台机器继续干活
你在公司电脑上做了一半的功能，回家想用自己的电脑继续。handoff生成的文档可以随身带走——或者通过git提交，或者复制到剪贴板——到家之后新会话读一下文档，接着干。
场景三：并行分支实验
这是handoff最被低估的用法。你在做一个架构设计，不确定某个方案是否可行。与其在当前会话里花时间写原型、把会话搞乱，不如/handoff一份给另一个会话去跑实验。那个会话跑完拿到结论之后，再/handoff回来。你从头到尾没离开过主会话，所有上下文都完好无损。
场景四：把工作交给同事
你马上要下班了，但有个任务需要同事接手。用/handoff生成一份交接文档，发给同事。同事打开自己的AI工具，把文档贴进去，AI就知道你在做什么、做到哪了、下一步该干什么。
使用案例
案例一：从Claude Code换到Codex写代码
一位开发者在Claude Code里花了两个小时分析一个API设计的各种方案，最终确定了技术选型和接口规范。接下来要开始写实现代码，但他觉得Codex在这种“写大量代码”的任务上表现更好。
他在Claude Code里输入了/handoff 开始写API实现代码。AI生成了一份交接文档，总结了已确定的接口规范、技术选型、以及尚未决定但需要实现时注意的几个点。他打开Codex，把文档内容作为初始提示词贴进去。Codex准确理解了他要做什么，直接开始写代码，没有问任何“你们之前讨论了什么”之类的问题。
案例二：下班前交接，第二天无缝继续
一位开发者在下班前正在调试一个棘手的并发问题，已经排查了三个方向，都失败了，但排除了不少可能性。他不想第二天从头再来。
他输入了/handoff 继续调试这个并发问题。AI生成的文档里包含了：已经试过哪三种方案、为什么失败、还剩下哪些方向值得尝试、以及当前代码的修改状态。第二天上班，他打开新会话，把文档内容贴进去，AI立刻接着说“好的，我们试试第四种方案”，就好像昨天没断过一样。
案例三：用handoff做并行实验
一位开发者正在做一个数据库迁移方案的设计讨论，讨论到一半，发现某个技术细节“只有实际跑一下才知道”。他不想在当前会话里开一个新分支去写代码——那样会打乱讨论的节奏，而且等跑完回来，之前讨论的上下文可能已经被挤出窗口了。
他在当前会话里输入了/handoff 验证一下这个迁移脚本在100万条数据下的性能表现。另一个会话收到文档后，去写了一个性能测试脚本，跑完拿到结果。然后那个会话又用/handoff把结果传了回来。主会话收到结果之后，继续做设计决策。从头到尾，主会话的上下文没有被打断，也没有被挤出去。
案例四：跨团队交接
一个前端开发者在完成了一个组件的UI实现之后，需要把这个组件交给后端同事来接入API数据。但后端同事用的AI工具不一样，而且对前端的讨论上下文一无所知。
前端开发者输入/handoff 把这个组件交给后端同事接入API。AI生成的文档里包含了：组件的props接口定义、当前的数据mock方案、API需要返回的数据结构、以及几个需要注意的边界情况。他把文档发给后端同事，同事打开自己的AI工具贴进去，AI直接开始写API接入代码，没有问任何“这个组件是干什么的”之类的问题。
handoff和compact的区别
这是handoff最容易被混淆的地方。简单来说：
/compact：在同一会话中压缩上下文，让当前会话能继续往下走。适合“会话太长、需要精简”的情况。/handoff：把上下文打包成一份文档，让另一个会话（或另一个人）能接上。适合“工作要换地方”的情况。
Matt Pocock在文档里写得很直接：“/compact除非有东西要移动。同一个任务、同一个工具、同一个目录——用compact，不是handoff。”
总结
handoff解决的是一个非常朴素的问题：AI会话之间没有共享记忆。
你换了个工具、换了个目录、换了台电脑，或者想让同事接上你的进度——以前只能手动复制粘贴、从头解释。handoff把这个过程标准化了：一次/handoff命令，生成一份结构化的交接文档，该有的信息都有，不该有的（敏感信息、重复内容）都没有。
触发方式：用户主动输入
/handoff输出位置：操作系统临时目录，不污染代码仓库
核心价值：可移植性，而不是压缩
最被低估的用法：并行分支实验
如果你经常在多个AI工具之间切换，或者需要把工作交给别人，handoff是一个值得装上的技能。它不做任何花哨的事情，只是确保你的上下文不会因为“换了个地方”而丢失。
◯ 评论 0