AI 编码会话的 5 次边界抉择：为什么 /compact 垫底

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 194 篇，AI 编程最佳实战「2026」系列第 71 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

AI编码会话五问决策树封面图

用 Claude Code 这类工具干复杂活的人，大概都卡过同一个地方。一个阶段干完了，Agent 停下问你下一步，你盯着那几个选项拿不定主意。

继续？上下文快满了。/clear？刚聊的需求还得用。/handoff？好像要写个文件。/compact？压完它还记得吗？

每个选项看起来都合理，选起来全靠猜。选错了也不当场报错，等走出好几步才发现方向已经偏了。

调研社区反馈的时候，我发现这几乎是 agentic coding 的通用痛点。Reddit 上有个用户提到：换更好的 system prompt、改 plan-mode 习惯、收紧指令，全都碰不到他真正反复踩的那个失败点——那个失败点指向上下文和会话管理，而不是提示词技巧。

Matt Pocock 的开源仓库 mattpocock/skills 里有一个专门回答这个问题的文件。它挂在 ask-matt skill 下，叫 PHASE-BOUNDARIES.md，是一棵五问决策树。这个仓库在 GitHub 上已经有十多万 star，被不少人当成 agentic coding 的教科书。

有意思的是，Medium 上有人专门写了篇文章说：别把这仓库当提示词抄，最短的那个 skill 文件才是关键——很可能指的就是它。

1. 先看全景：一次计费接入的 6 次边界

假设你要给一个内容创作工具接入第三方计费服务（订阅、用量计费、发票）。按官方 main flow 的编排，这次会话大概长这样：

grilling（拷问需求）→ to-spec（写规格）→ to-tickets（拆任务）
→ implement（实现）→ code-review（评审）→ QA（验收）

阶段之间一共有 6 处真实出现的 phase boundary。每处停下，决策树都会问一个不同的问题。先把 6 处边界一次走完，你就有地图了。

边界 1：grilling 结束，要不要直接写 spec？

继续。理由很硬：写 spec 要引用 grill 的原始回答——谁买单、按席位还是按用量、要不要免费层、退款谁负责。这些推理过程原文还在上下文里，是 spec 的一手来源。smart zone 也还远。Continue。

边界 2：spec 结束，要不要直接拆 tickets？

大概率继续。spec 阶段啃了一堆计费服务的文档、看了现有用户模型，上下文涨了不少，但还没到必须处理的程度。官方 main flow 明确说：grill → spec → tickets 这三步要保持一个不中断的上下文窗口，到 to-tickets 之后才允许 compact 或 clear。Continue。

边界 3：tickets 拆完，要不要直接 implement ticket 1？

这里要停一下，这是全会话值得停下来想的一处边界，后面单独展开。先给结论：/clear。 需求已经全部落盘成 spec 文件和 tickets 文件，实现只认 ticket，窗口里的对话噪音可以全丢。

边界 4：ticket 1 实现完，要不要直接做 ticket 2？

/clear。 每个 /implement 从 ticket 出发 fresh 开始，ticket 之间清上下文。ticket 2 想复用刚写的 Stripe 客户端封装？代码就在文件系统里，Agent 自己会读，不需要对话记忆。

边界 5：全部实现完，要不要 code-review？

subagent。 code-review 官方就是用 parallel sub-agents 跑的——Standards 和 Spec 两条轴并行评审，互不污染上下文。Agent 读 diff 汇报，期间不需要你盯着。这正是可以 AFK 完成的任务。

边界 6：评审完，要不要直接进 QA？

/compact。 评审的结论散布在整个 diff 会话里，QA 需要知道改了什么、评审发现了什么；上下文早就过了 smart zone；同一 harness、同一目录、需要留在循环里。四问都不成立，落到第 5 问。而且官方强调，compact 要带指令：/compact we're going to QA this area。

6 处边界，用了 4 个选项：Continue、/clear、subagent、/compact。还差一个 /handoff 没出场——它很窄，后面讲。

计费接入案例的6处会话边界地图

2. 五问决策树：五个选项的成立条件

PHASE-BOUNDARIES.md 的核心不是五个选项的定义，而是它们的成立条件和问的顺序。自上而下，先碰到的 yes 赢。

逐条拆开看成立条件，每条都窄得让人意外。

Continue 不是图省事才选，它有两个硬条件：要么下一阶段需要本阶段当一手来源，要么 smart zone 预算还够。前者是 grilling → implementation 的典型——实现要的是推理过程原文，不是摘要；后者是预算问题，smart zone 官方给的量级是 ~125K-150K tokens，而且原文明说了 this is debated，有争议，别当精确阈值用。

/clear 的条件是上下文与接下来完全无关——会话里的一切，探索、决策、死胡同，都可丢弃。它是棋盘上代价最小的一步：不花时间、把整个窗口还回来，旧会话还能恢复。但选错的代价是单向的：清掉相关上下文，为什么就丢了，翻不回来。

/handoff 很窄，只在四种情况需要：换到新 harness（Claude → Codex）、移到新目录或仓库、把工作交给同事、mid-phase 叉出一条支线任务而不打乱主线。它买到的是可移植性——一个能旅行的 markdown 文件。没有东西在旅行，就不需要它。

subagent 的条件是任务紧到可以离开键盘。范围要小、要自包含、不需要你中途操控。自动评审是标准案例。

/compact 是兜底：相关上下文、同一 harness、同一目录、需要留在循环里——四问都不成立，就落在这里。而且它经常落在这里。

五问决策树串行过滤流程图

3. 边界 3 的完整推理：tickets 拆完该不该直接 implement

把边界 3 的决策过程完整走一遍，你就知道这棵树是怎么用的。

问题 1：能否在当前会话继续？

两个条件：下一阶段需要本阶段一手来源？不需要——spec 和 tickets 已经落盘，实现读文件就行，对话窗口里的推理过程原文已经完成使命。smart zone 还剩够多？不——从 grilling 一路啃到 tickets，一个窗口撑了三个阶段，预算早见底了。

两个条件都不成立，问题 1 是 no，往下走。

问题 2：上下文与接下来完全无关？

要丢的东西：grilling 时的来回拷问、spec 阶段讨论过的被否决方案、拆 tickets 时的取舍理由。这些对实现 ticket 1 有用吗？ticket 本身是自包含的，实现只认 ticket 里的验收标准。窗口里剩下的都是可以丢的。

是，/clear。

注意这里的关键：/clear 之前，信息必须已经迁移到别处。spec 和 tickets 落盘了，窗口里剩下的对话本来就是可以丢的——/clear 丢的是窗口，不是重要信息。这就是为什么官方在 main flow 里强调到 to-tickets 之后才 clear——tickets 文件就是那个别处。

4. 一手 vs 二手：每次边界都是一次损耗交换

现在可以解释为什么这棵树长这样了。核心模型一句话：上下文是一次性资产；除 Continue 外，每个边界动作都是把一手资料（primary source）压成二手资料（secondary source）的损耗交换。

Continue 保留一手：信息全、噪音多、活动空间小——你只能在当前窗口里活动。/compact 和 /handoff 产出二手：干净、有损、活动空间大——摘要可以随身带走，但代价是细节被压扁。

subagent 是这套模型里比较特殊的一个：它把损耗转移而不是支付。主会话的窗口不动，token 密集的活（读全部 diff、跑双轴评审）在它自己的窗口里完成，还给你一份二手报告。所以 code-review 用 parallel sub-agents 不是炫技——它让主会话既不用 /compact 也不用 /clear，就能保持干净。

这个模型有个反直觉的推论，来自 Context Rot 那篇论文的整理：退化是输入长度本身造成的，不是内容脏才造成的。实验把非目标 token 全换成空格，退化照样发生。也就是说，你没法靠把上下文收拾干净来省钱——长度本身就在花钱。smart zone 就是这笔预算的度量。

Matt Pocock 自己写过一篇延伸文章，专门吐槽 Anthropic 的 Ralph 插件：bash 循环每次迭代都是全新 context window，Ralph 插件却把迭代累积在一个会话里，三到四次迭代后 agent 就完全在 dumb zone 里工作。他的经验法则是大约 40% context 处开始退化，前 40% 是 smart zone，后 60% 是 dumb zone——边界在哪有争议，但人人都同意边界存在。

所以他给会话定了预算纪律：一次会话一个任务，每个任务给它会话最锐利的部分。单个任务超过一个 smart zone，就拆开，在自然边界 handoff 或 compact。

所以决策树的逻辑是：只在留下比损失更贵的时候，才付有损的代价。 Continue 不付损耗，所以被优先排除；/compact 付损耗，所以垫底。

一手与二手资产损耗交换模型示意图

5. 为什么顺序就是逻辑

问题 1 先问，因为 Continue 代价最小、什么也不丢，rule it out first。 如果继续没问题，后面四问根本不用问。先排除代价最小的选项，是这棵树的基本盘。

/clear 排在问题 2，因为它的代价是单向的。 清掉相关上下文，丢的是为什么——为什么选按席位计费而不是按用量、为什么拒绝免费层。这些推理只存在于对话里，不在代码里。代码 diff 只显示改了什么，不显示为什么这么改。读多少 diff 都找不回来。

/compact 垫底，因为它是 default，排在问题 5。 从它开始按的失败模式是：新会话对一份被摘要压扁的决策自信地错。摘要看起来很完整、很干净，新会话不知道哪些细节被压掉了，于是基于一份残缺的决策做出自信的判断——这种错很难发现，因为每一步看起来都对。

顺序本身就是在帮你省钱：先试零成本的，再试可逆的，有损的垫底。

值得补一句 /clear 和 /handoff 的差别：/handoff 也产出二手，但它把摘要写进了文件，主会话随时能恢复，代价可逆；/clear 什么都不留，代价单向。所以决策树把 /clear 放在问题 2、/handoff 放在问题 3——先问能不能直接丢，丢不了才问要不要写下来带走。

6. 这是判断题，不是客观题

这棵树容易被误解的地方：它不给标准答案。

源码里写得很清楚，这些问题每个都含品味判断——同一处边界，两天可能走两条路，两条都合理。比如边界 2：如果 spec 阶段啃了大量文档、上下文真的见底，在就近的边界 /compact 一次（比如带指令：/compact we're going to keep splitting tickets，这是示例，不是官方原文）也是对的；如果还宽裕，Continue 也行。

价值不在于选对，而在于在边界问、按顺序问。两件事分开说：

在边界问。 mid-phase 没有决策可做，只有两条出路：继续，或者把剩余工作拆给 subagent。mid-phase 里 /compact 会让 Agent 丢主线：它正在实现 ticket 3 的中段，你压一下，它忘了自己刚改到哪、为什么这么改，只能从摘要里猜。

按顺序问。 五个问题不是并列的五选一，是串行过滤。从 Continue 开始，每问一个就排除一类情况，剩下的才是 /compact。跳过问题 1 直接按 /compact，等于默认继续一定不行——多数时候这个默认是错的。

7. 四个选错的反例

把常见错误摆出来，比背条件更直观。

反例 1：上下文还很热就 /clear。 grilling 刚聊完需求，你觉得差不多了，/clear 开新会话写 spec。结果写 spec 时 Agent 问：免费层到底要不要？你发现自己也记不清当时怎么定的了。需求的 why 已经丢了——免费层怎么定的，你和 Agent 都说不清了。

反例 2：stage 中间 /compact。 实现 ticket 3 到一半，上下文告急，你随手 /compact。Agent 回来接着写，写出来的东西和之前的方向对不上——它丢了 thread，只能从摘要里推断大概要做什么。mid-phase 的正确出路只有继续或拆 subagent，不是压缩。

反例 3：本可 Continue 却 /handoff。 spec 刚写完，上下文还很健康，你觉得换个文件保险，写了个 handoff 交给新会话。代价是：推理过程原文被压成了摘要，新会话的 spec 质量取决于你 handoff 文件写得有多好——而你本来可以直接继续。handoff 的四个条件一个都不满足，就不需要它。

反例 4：万事皆 compact。 把 /compact 当默认动作，每个边界都压一次。会话是挺干净，但每一压都丢一层细节。压到第三次，新会话面对一份压了三遍的摘要，照样自信地错——它不知道每次压缩各自丢了什么。这种失败模式很隐蔽，因为全程没有任何报错。

四个边界选择错误反例场景图

8. 总结

回到开头那个问题：阶段交界处，到底选哪个？

五问决策树的答案一句话：按顺序问。能继续就继续；上下文无关就 /clear；有东西要旅行就 /handoff；能 AFK 就拆 subagent；实在不行才 /compact。每个动作都是一次一手到二手的损耗交换，你只在留下比损失更贵的时候付这笔损耗。

这套树以 Claude Code / Codex 为默认环境，/compact、/clear、subagent 机制不是所有 Agent 平台都有等价物——换平台前先确认你的 harness 支持哪些原语。

再留个判断：这棵树的真正价值不在五个选项，在于它把什么时候处理上下文从感觉变成了流程。阶段中间你不需要想，边界处你必须想。就凭这一点，它就比大多数上下文管理技巧值得抄。

说明：本文内容基于 Matt Pocock 开源仓库 mattpocock/skills 的源码（ask-matt 的 PHASE-BOUNDARIES.md）和官方文档分析整理而成，属于源码级解读，尚未在笔者的生产环境中完成全场景验证。文中的配置模板和参数建议仅供参考，实际效果请以你的业务数据和环境测试结果为准。文中提到的 smart zone 约 15 万 tokens 为官方给出的有争议量级，不是精确保证。如果有实际使用经验，欢迎在评论区分享交流。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！