Vibe Coding 上下文裁剪：围绕改动影响保留最小充分证据

长任务进行几轮后，上下文会积累初版计划、已修复报错、旧文件快照、重复搜索结果和大段测试日志。继续全部保留，会让 AI 同时面对互相冲突的仓库状态；粗暴清空，又可能丢掉用户限制和关键调用方。上下文裁剪的目标不是文本尽量短，而是对当前下一步保持“最小充分证据”。

这和平台侧的摘要压缩不同。上下文工程强调给模型保留与任务有关的信息；代码任务中的裁剪更接近一次影响分析：先确认补丁准备改变的行为，再保留能证明边界、实现和验收的材料，其余内容变成可按引用重新读取的索引。

从当前决策点反向裁剪

不要问“哪些内容太长”，先问“下一步要做什么决定”。若下一步是修改一个 API 返回字段，证据闭包至少包含入口契约、实现、消费者、类型或 schema、相关测试和仓库规则。上周讨论的部署方案即使很重要，只要不改变这次决策，就可以移出活跃上下文。

用四个桶整理材料：

1. immutable：用户边界、授权规则、禁止操作和验收条件，不能因预算不足删除。
2. working：当前文件、直接调用方、测试与尚未解决的错误，是本轮主要输入。
3. index：已确认但可随时从路径和 revision 重取的背景，只保留结论与定位。
4. discard：已被新证据推翻、重复、与当前影响闭包无关的内容。

每次移动材料都记录理由。discard 不是事实被删除，而是它不再参与当前决策；若内容包含未验证假设，应把假设转进未知项账本，不能借裁剪悄悄让它消失。

用 diff 和依赖边界确定必留集合

Git diff 展示已跟踪内容在所选端点之间的差异，是裁剪的起点而不是完整答案。默认 git diff 只看工作树相对 index 的未暂存变化，已暂存变化需看 git diff --cached，未跟踪路径则从 git status --short 补齐。对每个改动符号搜索定义、引用、注册表、配置键和测试，再把动态加载、字符串路由和生成代码标成未知边。仓库依赖图驱动的改动规划可用于复杂影响闭包；小任务至少要做调用方与测试的双向搜索。

decision: change parseSession return shape
must keep: implementation, exported type, all direct callers, auth tests
retrieve on demand: architecture overview at docs/auth.md@8d31c2f
unknown: plugin loaded by SESSION_PROVIDER may bypass typed callers
discard: first-round lint output fixed by current diff

不要因为文件很长就只保留函数体。import、类型参数、错误边界和邻近注释可能决定语义。相反，一个完整日志文件通常只需保留执行命令、退出码、首个根因、关键堆栈与原始制品位置。

区分陈旧、重复和低相关

三者处理方式不同。陈旧材料必须失效：如果源文件已修改，旧片段不能继续作为事实。重复材料可以去重：多次搜索得到相同调用方时，保留一次带命令和 revision 的结果。低相关材料仍可能有效，只是暂时降为索引。

大型 Monorepo 的索引新鲜度指出索引必须绑定提交与脏工作树覆盖层。人工上下文也一样：路径引用至少带当前 HEAD，若文件有未提交修改则标明来源是工作树，而非假装它来自 commit。裁剪后重新读取时，先检查 revision 条件是否仍成立。

用删减试验检查是否裁过头

完成候选裁剪后，让 AI 在不写文件的情况下回答四个问题：目标行为是什么，哪些路径允许修改，最危险的兼容边界是什么，改完运行哪些验证。答案若缺少一项，说明必留集合不完整。再要求它指出每个结论的证据路径；只能说“根据之前讨论”的结论不够可靠。

还可以做反事实试验：暂时移除某段材料，看计划是否改变。移除一份旧日志后计划不变，说明可裁；移除权限中间件后，AI 开始建议只做前端校验，说明那是必留证据。试验不是追求模型每次措辞相同，而是确认安全与验收决策稳定。

为可再取信息留下精确索引

不要用“认证相关代码看过了”替代被裁内容。索引应包含路径、符号、revision、已确认结论和重新读取条件。例如“src/auth/guard.ts 的 requireOwner 在工作树版本负责对象级授权；修改资源加载逻辑前重读”。这比保存两百行源码更省空间，也比模糊摘要更可核查。

编程 Agent 的上下文预算提供分层预算思路；裁剪时还应预留输出、工具结果和下一轮错误信息空间。若活跃证据已经超过预算，不要继续压缩不可省略项，应缩小任务或在明确检查点开启新会话。

裁剪后的完成条件

一轮裁剪完成时，应满足：所有用户约束仍可逐条找到；当前 diff 的入口、调用方、配置和测试至少各有证据；旧快照已标失效；未知边仍可见；被移出的材料有可重取定位。随后冻结一个新的上下文 revision，后续代码变化再触发增量更新。

好的裁剪不会让 AI“记住得更少”，而是让它更难把过去的正确结论误用于现在。它保留决定补丁成败的证据，把其余背景变成可验证索引，并在证据不足时明确停下。

延伸阅读

• 编程 Agent 的上下文预算
• 仓库依赖图驱动的改动规划
• 大型 Monorepo 的索引新鲜度
• 上下文工程