AI 写代码的真正瓶颈,不是上下文长度,而是状态管理

用 Codex 做长任务时，你很快会遇到一个微妙的问题。

刚开始，它很清楚。

需求是什么，文件在哪，为什么这么改，下一步要做什么，都能跟得上。

但一个任务做久了，聊天越来越长，搜索记录、错误日志、调试过程、方案讨论、临时判断全堆在上下文里。然后你会发现，它开始重复搜索，重复解释，甚至重新尝试之前已经失败过的方案。

这时候很多人的第一反应是：

是不是上下文不够长？

但更深一层看，问题不只是上下文长度。

真正的问题是：

AI Coding Agent 缺少稳定的工作状态管理机制。

上下文不是记忆，只是工作台

我们很容易把上下文窗口理解成 AI 的“记忆”。

但这其实不准确。

上下文更像一张临时工作台。你可以把材料都摊在上面，但桌面总有边界。东西越来越多以后，重点会被淹没，旧信息会被压缩，新信息会挤掉旧信息。

Codex 的自动上下文压缩当然有用。

它能让一个长 Session 继续跑下去，不至于上下文一满就中断。

但压缩不是完整记忆。

它更像把一堆开发过程做成摘要。摘要会保留一部分结论，但不一定保留过程。

而软件开发里，很多真正重要的信息，恰恰不是结论，而是过程。

比如：

为什么不用方案 A？

为什么这个文件暂时不能动？

为什么这个测试失败不是业务问题？

为什么这里选择保守修改，而不是重构？

哪些坑已经踩过，不要再试？

这些信息如果只存在聊天历史里，就很脆弱。

一旦上下文被压缩，Agent 可能还记得“我们选了方案 B”，但忘了“为什么必须选 B”。

这就是长任务里最危险的地方。

不是它什么都忘了，而是它忘掉了决策背后的约束。

/handoff 解决的不是总结问题，而是接力问题

Matt Pocock 的 Skill 里有一个 /handoff 思路，表面上看是“生成一份交接文档”。

但它真正解决的不是总结，而是接力。

/handoff 的本质是：

在一个 AI Coding Session 结束前，把隐含在上下文里的工作状态，外部化成一份可读取、可接续、可验证的文档。

它不是让 AI 写一篇漂亮总结。

它要回答的是：

当前目标是什么？

已经完成了什么？

代码改到了哪里？

哪些决策已经定了？

哪些尝试失败过？

当前风险是什么？

下一步应该怎么继续？

下一个 Session 不要重复做什么？

这听起来像开发日报，但它比日报更关键。

因为人类开发者有长期记忆，有项目经验，有团队语境。AI Agent 没有。它每次重新开始，都高度依赖你给它什么上下文。

所以 handoff 不是锦上添花。

在复杂任务里，它是 AI 工作流的“状态快照”。

OpenSpec 管长期事实，handoff 管短期状态

这里很容易把 /handoff 和 OpenSpec 混在一起。

但它们不是一个东西。

OpenSpec 更像项目的长期事实源。它应该记录：

这个项目要做什么；

为什么要做；

验收标准是什么；

有哪些业务约束；

长期架构原则是什么。

它追求稳定、干净、可复用。

而 handoff 记录的是短期工作状态。它应该记录：

这个 Session 做到了哪里；

哪些文件被改过；

为什么这么改；

哪些方案已经失败；

哪些问题还没解决；

下一轮应该从哪里继续。

如果用记忆类型来类比：

OpenSpec 是语义记忆。

它保存长期知识和项目事实。

handoff 是情景记忆。

它保存这一次工作过程中的经历、判断和现场状态。

这两种记忆不能互相替代。

只用 OpenSpec，Agent 会知道项目目标，但不知道当前进度。

只用 handoff，Agent 会知道接下来要干什么，但可能不知道长期边界。

所以更合理的结构是：

这几个层次合在一起，才构成一个更可靠的 AI 开发系统。

为什么不能只依赖 Git？

有人可能会说：代码状态不是已经在 Git 里了吗？

是，也不是。

Git 很适合回答：

哪些文件改了？

具体 diff 是什么？

什么时候提交的？

谁改的？

但 Git 不擅长回答：

为什么这么改？

当时有哪些备选方案？

为什么没有重构？

哪个 bug 已经排查过？

哪些路径不要再走？

Git 保存的是代码事实，不保存完整的认知过程。

而 AI Agent 接手任务时，最容易缺的就是这部分认知过程。

所以 handoff 的价值不在于重复 Git，而在于补上 Git 没有保存的那一层：

决策语境。

什么时候应该触发 /handoff？

不要把 /handoff 当成上下文快爆时的救命按钮。

更好的做法是把它当成阶段性交接制度。

适合触发 handoff 的时机有三类。

第一类是上下文风险出现时。

比如一个 Session 已经持续很久，搜索过很多文件，调试过多个错误，聊天历史开始变重。这个时候就应该交接，而不是等到上下文 95% 才抢救。

第二类是阶段边界出现时。

比如需求分析结束，准备进入实现；后端实现完成，准备做前端；功能写完，准备联调测试。这些阶段之间，本来就应该有明确交接物。

第三类是任务暂停时。

比如今天先做到这里，明天继续。对人来说，睡一觉还能想起来；对 Agent 来说，新 Session 就是新生命。没有 handoff，它只能靠你重新解释现场。

一个更稳的节奏是：

这不是增加仪式感，而是在减少认知损耗。

好的 handoff 应该写什么？

一个可用的 handoff 不需要长，但要准。

尤其要避免写成空泛总结：

“本轮完成了部分功能，后续继续优化。”

这句话对下一个 Agent 几乎没用。

真正有用的是这种信息：

改了哪些文件；

每个文件为什么改；

当前测试跑到哪一步；

哪个错误已经定位；

哪个方案已经失败；

哪些代码不要碰；

下一步第一件事是什么。

我会把 handoff 设计成这样：

这里最重要的不是模板，而是意识：

handoff 不是为了记录“我很努力”。

handoff 是为了让下一个 Session 少走弯路。

更深一层：AI 编程需要外部化记忆

人类工程团队为什么需要文档、Issue、PR、commit message、测试、ADR？

因为复杂工程不能只靠脑子记。

AI 更是如此。

Agent 的上下文窗口越长，我们越容易误以为它“记得”。但它的记忆不是稳定资产，只是一次推理时临时加载的材料。

所以未来的 AI 开发工作流，重点不会只是：

怎么写 prompt；

怎么选模型；

怎么扩大上下文。

更重要的是：

怎么把项目事实放进 OpenSpec；

怎么把代码事实放进 Git；

怎么把行为事实放进测试；

怎么把过程状态放进 handoff；

怎么让新的 Agent 从这些外部记忆中恢复现场。

这就是 AI 编程从“聊天式开发”走向“工程化开发”的关键一步。

最后

/handoff 看起来只是一个小 Skill。

但它背后的问题很大：

当 AI 参与长期软件开发时，我们如何保存它的工作状态？

如果没有 handoff，长任务就会变成一场越来越混乱的长对话。

如果只有 compact，关键过程会被压缩成模糊摘要。

如果只有 OpenSpec，当前进度和调试经验没有地方安放。

如果只有 Git，代码变了，但决策语境丢了。

所以 handoff 的价值不是“多一份文档”。

它真正做的是：

把 AI Agent 的短期记忆，从脆弱的上下文里迁移到稳定的工程资产里。

这也是我觉得 /handoff 值得重视的原因。

AI 写代码的能力会继续变强。

上下文窗口也会继续变大。

但只要软件开发仍然是一个持续、多阶段、多人或多 Agent 接力的过程，状态管理就不会消失。

未来真正高效的 AI 编程，不是一个超长 Session 从头干到尾。

而是一套可以交接、可以恢复、可以验证、可以继续推进的工程系统。

最后推荐一下我最近在做的小册：