关于 context: fork 最常见的误解是它的范围。Fork 不创建沙箱。不隔离文件操作。它只隔离一样东西：对话上下文——模型记住的东西。
一个有 Write 权限的 fork skill 创建的真实文件在 fork 结束后持久存在于项目中。导致那些文件产生的冗长分析留在 fork 中。文件留在磁盘上。
Fork 实际做什么
当 skill 用 context: fork 运行时，Claude Code 启动一个有自己对话上下文的子代理。子代理执行 skill 的工作——读文件、跑分析、生成输出。完成后，只有一个摘要返回主会话。详细输出留在 fork 的上下文中，主会话无法访问。
这意味着：
| 操作 | 隔离了？ | 原因 |
|---|---|---|
| 对话上下文 | 是 | Fork 是独立的上下文窗口 |
| 文件读取 | 否 | 读的是真实文件系统 |
| 文件写入 | 否 | 写到真实文件系统 |
| Bash 命令 | 否 | 在真实 shell 中执行 |
一个探索代码库（3,000 token 分析）然后写重构代码的 skill：分析留在 fork，重构后的文件持久存在于磁盘。一个 fork skill 满足两个需求——不需要拆成独立的探索和修改 skill。
取舍：上下文效率 vs 后续追问
Fork 前：代码库分析 skill 消耗 65% 的主上下文。只剩 35% 给后续工作。
Fork 后：skill 的摘要消耗 5% 的主上下文。95% 留给工作。
但开发者反映不能再问详细的后续问题了。“详细说说 auth.ts 里的漏洞”得到”我没有关于那个模块的信息”——因为详细发现只存在于 fork 的上下文中，主会话访问不到。
方案：更好的摘要
取舍不是非此即彼。设计良好的摘要能兼顾两个需求。
一个团队调查了开发者对 fork 安全扫描的反馈：
- 70%： 摘要太模糊——“发现 3 个漏洞”但没有细节
- 20%： 摘要差不多——关键发现带文件位置
- 10%： 摘要太详细——违背了 fork 的意义
说”差不多”的 20% 描述了目标格式。修复 70% 的方法是在 skill 正文中加指令，指定摘要必须包含什么：
- 发现数量和严重度
- 受影响的文件路径
- 简要修复提示
摘要变得可操作但不冗长。开发者可以追问摘要级细节（“修 auth.ts 里那个高危的”），不需要完整分析在上下文中。
这由 skill 指令控制，不是 fork 配置。Fork 没有”摘要详细度”设置。子代理返回什么取决于 skill 让它总结什么。
什么时候 fork
Fork 当：
- 输出超过约 5,000 token 且主会话只需要摘要
- 冗长的探索、头脑风暴或扫描，详细输出是中间工作
- Skill 既探索（冗长）又修改（持久）——fork 两者都正确处理
不要 fork 当：
- Skill 产出很少输出（200 token，一个通过/失败结果）
- 开发者需要问关于输出的详细追问
- Skill 建立会话上下文（架构笔记、规范）后续命令需要
- 快速操作，fork 开销不成比例（2 秒 lint 检查）
决策标准不只是 token 数。一个建立关键会话上下文的 200 token skill 不该 fork。一个开发者从八个方案里选一个的 4,000 token 头脑风暴 skill 该 fork——选定一个后其他七个就是噪音。
数据：Fork 前后
一个团队给代码库分析 skill 加 fork 后：
| 指标 | Fork 前 | Fork 后 |
|---|---|---|
| 主上下文消耗 | 65% | 5% |
| 剩余工作空间 | 35% | 95% |
| 后续追问细节 | 完整 | 仅摘要 |
60 个百分点的上下文节省改变了团队的工作流——之前因上下文耗尽而失败的后续任务现在有了充裕的空间。摘要质量问题通过更好的 skill 指令单独解决。
/compact 不是答案
一个冗长的非 fork skill 填满上下文后，/compact 压缩对话。这是手动的、有损的变通办法：
- 每次冗长 skill 调用后都得手动运行
- 可能和 skill 输出一起丢弃有用的上下文
- 开发者必须记得做
Fork 是架构层面的修复。它在结构上预防问题——不需要手动步骤，主上下文不丢信息，不依赖开发者纪律。
一句话总结： Fork 隔离的是 Claude 记住什么（对话上下文），不是它做什么（文件系统操作）——它返回的摘要质量取决于你的 skill 指令，不是 fork 设置。