企业官网建设流程全解析

阶段边界决策树：在 Agent 会话中管理上下文与交接的完整指南（ask-matt / Phase Boundaries）

【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills

导读

在长期使用 Claude Code、Codex 等编码 Agent 的过程中，最容易被忽视却最影响产出质量的决策，发生在两个工作阶段之间的"缝隙"里：这个阶段结束后，是继续留在当前会话、清空上下文、写一份交接文档、派给子代理，还是压缩上下文？本项目（skills 仓库）中的 PHASE-BOUNDARIES.md 给出了一张有序的五问决策树，配合 ask-matt 路由器使用，可以让你在每一个阶段边界上做出成本最低、信息损失最小的选择。读完本文，你将掌握 phase / phase boundary 的准确定义、五种选项的适用场景与代价对比、从上到下逐条判断的决策流程，以及 primary / secondary source 的取舍原理，并能在真实的多会话工程流程中直接套用。

什么是 Phase 与 Phase Boundary

Phase（阶段）是会话内的一段工作块：一次 grilling（访谈式需求澄清）、一次 implementation（实现）、一次 QA（质量检查）都是独立的阶段。文档刻意没有给"阶段"一个精确边界——"一个阶段何时结束"由你自己判断，标准就是当你觉得"ok，这块做完了"的时候。

Phase boundary（阶段边界）则是两个阶段之间的间隙，它是在整个会话中唯一适合做"是否切换上下文"决策的地方。理由很直接：

• 阶段中途不存在这个决策：要么继续推进，要么把剩余工作拆给子代理。此时压缩上下文（compact）会让 Agent 丢失线索（"Compacting mid-phase makes the agent lose the thread"）。
• 阶段边界上，上一阶段的工作成果已经沉淀（可能是推理链、代码 diff、一份文档），下一阶段的输入已经明确，此时做切换决策的信息最完整、代价最可控。

这一概念在本仓库的 ask-matt 技能中有明确的落点。ask-matt/SKILL.md 的 "Context hygiene" 一节规定：主流程的第 1～3 步（grilling → spec → tickets）应保持在一个不断裂的上下文窗口内，直到/to-tickets之后每个/implement再各自开新会话。而决定在哪里切、怎么切，正是由阶段边界决策树来回答的。

五种选项及其代价

在阶段边界上，你有五个选项。原文档用一张表精确概括了它们各自的行为：

注意/handoff与/compact在机制上的本质区别：前者产出一个文件（portability，可移植性），后者产出一份摘要（compression，压缩）。仓库中的 handoff/SKILL.md 进一步说明：/handoff将当前对话总结为交接文档，写入操作系统临时目录（而非工作区），并附带一个 "suggested skills" 段落，告诉下一个 Agent 应该调用哪些技能；同时会脱敏 API 密钥、密码等敏感信息，并且绝不复制spec、plan、ADR、issue、commit、diff 中已有的内容，而是用路径或 URL 引用，避免双份内容漂移。

决策树：从上到下逐条判断，第一个"是"胜出

这棵树是文档的核心骨架，规则是：在边界处自上而下逐条询问，第一个回答"是"的选项胜出。

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

两个条件之一成立即可回答"是"：

1. 下一阶段需要把本阶段当作 primary source（一手来源）。最典型的例子是 grilling → implementation：实现阶段需要的是访谈推理的逐字原文，而不是一份摘要。原文档的判断是 "the implementation wants the reasoning verbatim, not a summary of it"。
2. 剩余的 smart zone（智能区）足够装下下一阶段（约 150k tokens，指模型仍能清晰推理的窗口容量）。

Continue 的成本为零、损失为零，所以必须先把它排除掉再做别的判断。这也与 ask-matt 技能中的上下文卫生建议一致：主流程尽可能在一个不中断的窗口里推进，直到窗口逼近 smart zone 上限。

问题 2：当前上下文与接下来的工作是否无关？

如果本会话里的一切——探索过程、决策、死胡同——都是可丢弃的，就用/clear。它是整张棋盘上最便宜的招：不花时间，把整个窗口还回来。而且/clear不是终局操作：旧会话仍然可恢复（resumable）。

但这一选项的错误代价是单向的：清掉一个仍然相关的上下文，你就失去了"为什么这样做"（thewhybehind what you built），无论事后怎么重读 diff 都找不回来。这是整棵树里唯一"错了就无法挽回"的分支，值得特别警惕。

问题 3：是否需要交接（handoff）？

/handoff是五个选项里最窄的一个。原文档明确给出了它的全部触发条件，只有这四种：

• 切换到新的 harness（例如 Claude → Codex）；
• 移动到新的目录或仓库（原型目录是常见场景）；
• 把工作交给同事；
• 在阶段中途发现一个旁支任务，想分叉出去而不打乱主线。

这份清单就是它的全部适用条款。/handoff买到的是可移植性（a file that travels）。如果没有任何东西需要"旅行"，你就不需要它。

仓库对分叉场景有更完整的展开：/handoff的分叉用法允许你留在原会话里，同时把已积累的上下文副本交给第二个 Agent 并行处理。这正是主流程中"原型绕行"的桥接方式——ask-matt/SKILL.md 第 18 行描述的流程是：/handoff出去 → 在新会话用该文件播种 →/prototype用一次性代码回答问题 →/handoff把学到的东西带回来并在原思路线程中引用它。原型活在自己的目录里，往返的两次跨越正是/handoff的用武之地。

问题 4：任务能否在无人值守（AFK）下完成？

如果任务范围足够紧、不需要你在旁边持续纠偏（no steering），就交给subagent，让本会话保持不动。自动化 review 是标准场景：Agent 读取 diff 并回报，期间不需要你在场。

从源码结构看，subagent 的价值在于把任务放进它自己的上下文窗口，从而不占用主会话的 smart zone，与问题 1 中"剩余窗口容量"的判断形成互补。

问题 5：否则，用/compact

相关上下文、同一 harness、同一目录、且你还需要持续参与——决策树最终落在这里，而且经常落在这里。此时应当给/compact传一条指令（例如/compact we're going to QA this area），让摘要保留下一阶段需要的东西。

原文档特别强调：/compact是默认项，而不是首选。它被放在树的最底部，是因为它上面的四个问题全都更便宜或更精确。人们常见的失败模式就是一开始就用/compact：结果是开出一个新会话，它对着被摘要压平的决策"自信地犯错"（confidently wrong about a decision the summary flattened）。这正是问题 1 必须排第一的原因。

Primary Source 与 Secondary Source 的取舍

除Continue之外的每一个动作，都会把一个primary source（一手来源：原样发生的会话）变成secondary source（二手来源：对它的摘要）。这个交易的形状永远相同：

也就是说：Continue 保留全部信息但噪声也多、剩余可活动空间小；压缩或交接则有损，但换来更干净的上下文和更大的活动余地。这也是为什么问题 1 排在首位——你只有在"留在原地"的代价大于收益时，才应该为有损转换付费。

/handoff的文档页 docs/productivity/handoff.md 用一句话总结了三种工具各自的保留对象，可以当作记忆锚点：/compact保留你的意图（intent），/clear什么都不保留，/handoff保留工作"能够移动"的能力（portability）。

这些判断是品味问题

原文档在结尾给出了清醒的提醒：这五个问题不是客观的，每一个都掺着判断力（taste），同一条边界在两个不同的日子里可能走向不同的选择。决策树的价值不在于给出唯一正确答案，而在于：

• 按顺序提问（自上而下，第一个"是"胜出）；
• 在边界处提问，而不是在工作中途。

在本仓库中的位置与使用方式

这份决策树是 ask-matt 路由器的一部分，服务于整个 skills 体系。相关文件结构如下：

• 决策树本体：skills/engineering/ask-matt/PHASE-BOUNDARIES.md
• 路由器总览：skills/engineering/ask-matt/SKILL.md（其 "Phase boundaries" 一节把五个选项浓缩成一段速查，并指向本文档阅读完整决策树）
• 交接工具实现：skills/productivity/handoff/SKILL.md 与 docs/productivity/handoff.md

ask-matt 的元数据（agents/openai.yaml）中allow_implicit_invocation: false，即它是仅用户触发的路由器，需要你主动输入/ask-matt（或等价触发词）来调用；阶段边界的决策也因此始终由你主导，Agent 不会自行替你选择/clear、/compact或/handoff。handoff 技能的 frontmatter 同样设置了disable-model-invocation: true，需要你主动输入/handoff。

如果你想在本地安装使用这套技能（含 ask-matt 与 handoff），仓库 README.md 提供了两种方式：Claude Code 下执行claude plugins install mattpocock-skills（插件方式，自动更新），或其他 Agent / 折腾党使用npx skills@latest add mattpocock/skills（文件方式，可自行修改）；首次使用工程类流程前，还需在每个仓库执行一次/setup-matt-pocock-skills配置 issue tracker、triage 标签与文档布局。

总结：一张可以贴在终端边的速查卡

把整棵决策树压缩成五句话，就是：

1. 下一阶段需要本阶段的一手推理，或窗口还够 →Continue（先排除它）；
2. 当前上下文对下一步毫无价值→/clear（但注意：错了就是单向损失）；
3. 要换 harness / 换目录 / 交同事 / 分叉旁支 →/handoff（买的是可移植性）；
4. 任务足够紧、可无人值守 →Subagent（不碰主会话）；
5. 其余情况 →/compact（默认项，但绝不是首选，记得带上指令）。

在边界处按此顺序判断，你就能在"信息完整度"与"上下文成本"之间始终做出理性选择，避免最常见的两种翻车：中途压缩导致 Agent 丢线，或清空相关上下文导致"为什么这么做"永远失联。

【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills