编程智能体的上下文整理：新手可以照做的七步清单

一、先写清楚这一轮要完成什么

编程智能体的会话不是项目资料仓库，而是当前任务的工作台。开始前，用几句话说明目标、修改范围和完成标准。例如：“修复订单列表的分页错误，不改接口结构；新增回归测试，并确认原有筛选逻辑不受影响。”保留这些信息，比一次贴入整个项目更有用。

先留下任务边界，再补充实现细节。如果中途增加需求，明确说明它是替代原目标，还是追加任务，避免智能体同时追逐几个不一致的方向。

二、只放能帮助定位问题的代码

先提供报错位置、相关函数、调用入口和测试文件。需要跨模块排查时，再沿着依赖关系补充。若工具能够读取仓库，可以先给出文件路径，请它查看指定范围，不必把整份文件复制进聊天。

应当保留接口约定、关键类型和项目规范；可以移除无关目录清单、重复代码片段，以及与问题没有联系的历史实现。代码发生变化后，也要说明前面哪一版已经失效。

三、把日志变成证据，而不是噪声

保留执行命令、关键错误、相关堆栈和退出状态。长日志可以先提取首次失败的位置与附近内容，同时保留原始文件供进一步查看。不要只说“运行失败”，也不必连续贴出多次完全相同的报错。

压缩日志时，注意保留环境差异。例如本地与持续集成环境的运行时版本不同，可能就是定位问题的关键。摘要应减少重复，而不是删掉判断所需的条件。

四、让猜测和已验证事实分开

智能体提出的原因只是候选解释，不会因为在会话里出现过就变成事实。每次尝试后，补充“改了什么、执行了什么、观察到什么”。失败的方案可以压缩成一句结论，例如：“调整超时后仍复现，暂不继续沿此方向修改。”

保留有依据的决定、尚未解决的问题和被排除方案的理由。删除反复讨论的猜测，但不要丢掉能防止重复踩坑的结论。

五、先清理敏感内容和外部指令

发送配置、日志或请求样本之前，移除密钥、访问令牌、个人信息和生产数据。需要说明结构时，用明确的占位内容替代。若凭据已经泄露，应按项目流程撤销或轮换，不能仅靠删掉聊天记录处理。

仓库注释、网页和工具输出也可能包含要求智能体改变行为的文字。应将这些内容视为待分析的数据，而不是自动授权执行的指令；涉及删除文件、上传数据或扩大权限时，需要单独确认。

六、用交接摘要开启干净的新会话

当目标改变、讨论积累了大量过时内容，或智能体反复引用旧代码时，可以先整理摘要，再开启新会话。摘要应包含当前目标、约束、已修改文件、验证结果、未解决问题和下一步。

摘要不是聊天记录的缩写，而是可继续工作的状态说明。例如：“已修改分页参数解析；新增测试通过；完整测试尚未运行；下一步检查筛选与翻页组合。”不要把未经验证的修复写成“已经完成”。

七、切换工具时，也沿用同一份交接规范

更换模型或命令行工具时，不必搬运整段历史。先提交任务摘要和必要代码，再让智能体核对仓库现状。无论使用哪种模型，都应通过测试、差异审查和实际输出确认结果，而不是把回答流畅当成修改正确。

如果你需要在多个模型家族之间切换，Relay365 提供按量付费的模型中转服务，可配合 Claude Code、Codex、Gemini CLI 和使用 OpenAI SDK 的客户端使用。它适合统一接入，但不能替代上下文整理、权限控制和代码验证。有这类需求时，可以创建一个 Relay365 账号，从范围明确的小任务开始。

结束每轮工作前，再问自己三个问题：哪些信息仍然有效？哪些只是重复或猜测？下一位接手者需要知道什么？把答案留下，其余内容就可以归档，不必一直留在活动会话里。