Context Engineering 面试：摘要记住了项目，却忘了纠正怎么办？

摘要记住了项目名，却把“我只负责回滚脚本”压缩成“我负责整个迁移”。这不是记得少，而是记错了关键事实。Anthropic 的 Context Engineering 文章讨论了有限上下文预算的管理。下面专门练一个更窄的问题：哪些纠正必须跨过压缩边界，怎样证明它没有丢？

区分当前问题、事实和补充知识

给每个来源安排明确职责。分开当前请求、最近真实对话、持久用户事实和补充检索，并说明谁能定义身份、谁只能解释概念、谁允许过期。来源血缘比一个模糊的“记忆”标签更有价值。

压缩时保留纠正与未决问题

压缩的目标是保持连续性，而不是图方便。摘要要保留决策、纠正、未解决问题和责任归属。裁剪可选背景前，先保护当前问题和最近真实对话，并验证摘要能指回来源，否则更短的上下文反而会制造自信的错误。

恢复必须检查版本和适用范围

在优化前先设计恢复。明确检索失败、摘要过期或 Provider 超时时怎么办。安全兜底应恢复最近一次已验证上下文，并说明缺口。这个回答比承诺无限扩大的上下文窗口更成熟。

构造一组纠正、追问和过期写入

用虚构对话做回放：候选人先说“参与了数据库迁移”，随后补充“我负责回滚脚本，迁移方案由另一位工程师设计”。面试官追问：“你个人做了什么决定？”回答应围绕脚本，不能把整个方案的所有权揽过来。

为真实转写保留稳定来源标识和时间顺序。再模拟一个摘要任务：它在纠正之前启动，却在纠正之后才完成。此时原文已有新事实，旧任务正准备写入派生记忆，这才是关键竞态。

摘要读起来合理，也可能已经过期

格式合法不等于可以接受。应检查摘要覆盖的来源范围与版本；如果它早于纠正，就按现有记忆合同保留更新的原句，或拒绝让旧摘要替换新状态。不能因为摘要更短，就让它拥有更高事实权威。

补充检索也不能重新定义候选人的角色。一篇迁移指南可以解释回滚策略，却不能证明这个人主导过迁移。构造最终请求前，要分清概念解释和个人经历证据。

验收最终回答，而不是只看“摘要已保存”

检查真正送给回答模型的输入：当前问题有没有出现，最新纠正是否可用，来源顺序是否清楚。数据库里有一条保存成功记录，并不能证明下一轮回答正确消费了它。

再增加三个变体：摘要生成超时、旧任务最后完成、候选人后来补充自己还评审过检查清单。第三种是在增加职责，不一定推翻前面“没有设计整体方案”的边界。只用最新一句覆盖一切，也可能丢失有用事实。

恢复路径必须继续符合当前会话和权限。“上次有效”不能变成恢复已撤权文档或另一场面试资料。当派生摘要不可信时，优先保留当前问题与最近真实转写；缺少事实就承认缺口，不要用通用知识补一段个人履历。

面试里可以说：“我会回放摘要晚到的竞态，检查最终模型输入，并确认回答仍把个人职责限定在回滚脚本。”最后明确验证边界：来源保留可以做确定性测试，自然语言回答质量仍需重复评估和人工复核。

常见问题

上下文越长越好吗？

不是。更长会增加干扰、成本和过期证据。相关性与来源更重要。

哪些内容不能被压缩掉？

当前任务、最近纠正、确认过的身份事实，以及理解下一步动作所需的证据。

怎样测试上下文质量？

用固定回执回放真实对话，检查最终回答是否保留当前问题、来源边界和纠正。

参考来源

• https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
• https://www.anthropic.com/engineering/infrastructure-noise

下一步

接着阅读Context Engineering 基础与预算设计。练习时可以把自己的案例整理进 Interview AiBox 面试档案，但工具不会自动替你核实项目成果。

• 功能全景
• 产品路线图
• 当前版本说明
• 下载 Interview AiBox