AI 总忘记约定、修了又坏，怎样提供上下文？
整理一份可接手的当前状态，给相关信息而非堆满聊天历史。
本页目录
直接回答
上下文工程要回答：这次任务需要知道什么、哪些信息仍然有效、到哪里核实。增加字数并不必然提高判断质量，缺少资料、过期决定和无关信息都可能造成误解。实用做法是维护一份简短现状，为重要结论保留证据入口，并让新一轮工作先核实现有实现。
适用场景
- 对话很长，AI 开始重复走已经否定的路线。
- 切换工具、模型或聊天后，需要继续同一个项目。
一步一步做
先定位任务真正涉及的范围
说明用户问题和入口，再让 AI 查相关代码、配置、错误信息与调用方。不要因为文件很多就全量粘贴，也不要只给孤立报错而缺少触发操作。
把事实、决定和想法分开
事实是已经观察到的行为；决定是已接受的约束；想法是尚未验证的方案。给每条重要事实附文件、截图或检查结果，避免下一轮把讨论当成已实现功能。
保存最小可接手状态
记录目标、当前完成范围、未解决问题、关键文件、运行方式及下一步。长对话需要整理时，检查摘要有没有丢失限制或把失败写成成功，再开始新上下文。
对变化快的信息回到原始来源
库 API、平台规则和工具选项不能只靠模型记忆。给实际版本及官方文档位置；若外部资料与项目代码不同，先说明冲突，再决定如何迁移。
让接手者先复核再行动
新对话先读交接说明与关键实现，确认未提交改动和验证状态。项目发生变更后同步更新说明，删除被取代的结论，不让多份互相矛盾的“最新文档”并存。
用三种症状诊断上下文，再补最小证据包
先记录一条可定位的失败事实：从哪个入口、哪个版本、做了什么、实际与预期差在哪里。资料不足时补相关函数及调用方；信息太多时先给目录和搜索线索，再打开必要片段；旧结论混入时写清新现状和已废弃决定。证据充分后仍然执行错误，应检查实现或模型判断，不能把所有责任归给提示词。最终产出是一张能定位问题的证据卡。
先定位再贴片段，做一次三色检查
可选择提供具体代码、定位入口后再取片段、换会话交接，或查外部资料核实。提交前做三色检查：绿色为可定位到文件或日志的现状，黄色为尚未确定的假设，红色为过期或无关信息。没有代码访问时提供最小可复现输入、相关配置和完整错误上下文；有访问能力时先找实际入口再扩大阅读，避免把另一个登录模块误作当前调用链。
先问会改变实现的问题，再固定决策
追问应集中在隐含假设、重要边界、含糊要求以及用户是否真的需要。每次先追一个会改变目标、数据或权限的重要问题；已有答案先查资料，低风险细节给合理默认。答案写成“决定＋理由＋验收”，例如分享进入是否登录、失败是否重试、记录是否可撤销。目标、非目标和关键边界已有可检查答案后即可开始，无须以问满固定轮数为条件。
把长期资料变成有来源和失效条件的索引
规则、参考资料、记忆、技能和工具配置承担不同职责。为复用知识附证据、核验时间、适用版本和替代关系；事实改变后保留必要记录并标记旧结论失效。敏感证据仅保存在获准位置，交接给出脱敏结论和受控引用。无需把所有邮件或客户记录灌入模型；能找到资料不等于工具有权读取或执行。
案例拆解
假设示例：支付问题交接
“支付已经完成”容易误导。更准确的是：“测试支付创建成功，回调尚未到达；本地接口在某文件；已排除签名配置问题，下一步检查公网回调地址。”接手者就不会重新写一套支付流程。
行动检查
可复制模板
项目续接模板
目标：
已接受的约束与决定：
已实现并验证：
已实现但未验证：
当前失败现象与复现步骤：
关键文件/原始来源：
尝试过但无效的方案及原因：
下一步最小动作：
接手要求：先核对代码与状态；发现摘要过期请指出，不要把建议当完成。
最小上下文证据卡
任务与用户结果：
当前入口/页面/调用方：
代码版本、未提交改动与环境：
触发步骤/输入：
实际结果 → 预期结果：
相关文件、日志时间或截图：
绿色：已核实现状（每条附来源）：
黄色：假设/未知，以及如何验证：
红色：过期决定/不相关信息，本轮忽略：
不可破坏的约束：
需要用户回答的关键问题（没有则写无）：
本轮最小产出、验收与停止条件：
换会话交接与知识失效表
目标/非目标：
已决定事项 → 理由 → 决定来源：
已实现事项 → 文件/版本 → 已测范围：
失败/未执行/缺配置：
下一步入口和第一项核查：
知识条目 | 原始来源 | 适用版本 | 最后核验 | 失效触发 | 替代条目
接手者复核：实际文件是否存在、版本是否改变、上次失败是否仍在、摘要是否把讨论当完成。
不携带：明文密钥、完整客户隐私、未经授权的资料。
易错点
- 上下文窗口大不等于可以无限塞资料；噪声依然会干扰判断。
- 摘要是索引和工作状态，不能代替原始证据。
- 不要把账号密码、密钥或完整个人隐私放进通用交接文档。