北京
给AI编程助手更多上下文，这个建议几乎人人都听过。加README，加AGENTS.md，加架构文档，加日志，加历史决策，加整个代码库，再加跨会话记忆。听起来很合理，但这里有个问题：更多上下文并不总是意味着更好的理解。有时候它意味着更多噪音、更多过时假设、更多互相冲突的指令、更多无关文件，以及更多让助手把注意力放错地方的机会。
想象一下，你把400个文件、12份架构文档、8份旧事故报告、3份过时的迁移计划、6个指令文件、40页日志、之前的助手记忆，再加上当前任务，全部交给一个开发者，然后说“修一下这个bug”。这不会自动变得有帮助，这是一大堆需要梳理的信息。AI助手面临的是同一个问题。
上下文有质量，不只是数量
不是所有上下文都同样有用。有些是相关的，有些是过时的，有些是互相冲突的，有些是错的，还有些技术上正确但与当前任务无关。如果你给它们同样的权重，助手就必须自己判断什么才重要。而错误往往就是从这里开始的。
假设你当前的系统用的是控制器到服务再到仓储的分层结构，但一份旧的架构文档里还写着控制器直接到数据层。你让助手加一个功能，现在它有了两个“真相来源”。它该信哪个？也许它跟着代码走，也许它跟着文档走，也许它把两者混在一起。结果就是你得到了一个以前从未存在过的新模式。问题不在于缺少上下文，而在于上下文的卫生没做好。
过时的上下文比缺失更危险
缺失上下文通常会带来不确定性。过时的上下文则可能让人朝着错误的方向充满信心，这更危险。比如三个月前所有支付都走供应商A，今天系统里已经有一半迁移到了供应商B，但助手记忆里还留着旧规则。于是它非常自信地实现了错误的集成。这就是为什么持久记忆既可能有用，也可能同时带来风险。
互相冲突的指令会制造安静的问题。AGENTS.md里写着所有业务逻辑都用服务类，另一个文件里写着业务逻辑保留在路由处理器里，还有一条旧任务笔记说避免新增服务层。这三条在不同时间可能都是对的，现在它们同时存在，助手必须自己解决冲突。这不是一个安全的默认状态。
更多token不等于更多注意力
更大的上下文窗口让助手能接触到更多信息，但它并不保证对每一条信息给予同等关注。如果你塞进去几百个文件、很长的日志、旧讨论和巨大的文档，真正重要的细节反而可能更难浮现出来。真正的问题变成了：助手能不能在正确的时刻找到正确的上下文？这和“助手能不能把所有东西都塞进提示词”是两回事。
更好的目标应该是“最小充分上下文”——给助手足够做出正确决策的信息，而不是你拥有的全部信息。比如任务是修复结账流程里的一个校验bug，助手大概需要结账流程、校验规则、相关测试、相关数据模型和当前架构约束。它大概不需要邮件服务文档、分析历史、无关的迁移日志、旧的设计讨论和每一个前端组件。
让助手自己说要什么
一个更好的模式是渐进式上下文：从小处开始，给出相关文件，让助手自己检查，只在需要时添加更多。而不是一股脑全倒进去，然后指望助手能找到重点。这本质上就是面向编程助手的渐进式披露，让助手随着任务需要去“赚取”更多上下文。
还有一个出奇有用的做法：不要一上来就给整个代码库，而是先问助手——在改动任何东西之前，你需要什么信息？哪些文件可能相关？你目前做了哪些假设？什么上下文能减少不确定性？这样助手会告诉你它缺什么，这比盲目添加更多内容要好得多。
团队应该把上下文分成两类。一类是永久性的，几乎总是成立的：编码标准、架构边界、安全规则、命名约定、归属规则。另一类是任务专属的，只和当前工作相关：一个bug报告、一个功能需求、一组日志、一个模块、一次事故。把两者混成一大团，会让推理变得更难。
永久规则要短。你的助手指令不该变成一部小说。如果AGENTS.md有5000行，开发者自己大概也不会仔细读。最好的永久规则通常很简单，比如业务逻辑留在服务层、仓储只负责持久化、未经批准不添加依赖、没有明确要求不改动认证规则、测试必须覆盖变更的行为。清晰、简短、难以误解。
有些上下文还应该有“过期时间”。临时迁移规则、事故专属的变通方案、旧的功能开关、已弃用的API行为、一次性的实现笔记，这些都不该永远留着。如果助手能永远记住某件事，那就得有人来决定这段记忆什么时候该失效。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
