AI 编程的上下文限制了什么？大项目里的失焦

小脚本让 AI 写，从头到尾不出错；换成几万行的大项目，用得照样挺顺，合进主干却开始出怪事：上周刚定下的接口约定，AI 今天给的新函数又违反了；明明已经封装好的工具函数，它又重写了一个几乎一样的。这些问题大多指向同一个机制：上下文限制。模型一次能「看见」的内容有限，项目越长，远处的约定越容易被挤出视野。这篇讲清上下文到底限制了什么、失焦长什么样、怎么把关键约束钉住。

上下文窗口决定了什么

模型没有记忆，只有上下文：一次对话里它能看到的内容，就是它思考的全部依据。上下文窗口再大也有边界，而且还有更实际的一层——有效注意力会随内容变长而衰减，塞进去几十个文件之后，中间部分的细节常被看漏。大项目里表现为两类失焦：一类是视野外的失焦，项目约定写在某个文档里，这轮对话没带上，AI 就当作不存在；另一类是视野内的稀释，窗口里塞了太多无关代码，关键约束被噪声淹没。这与模型强不强无关，是机制本身：它对项目的认知止于你给它的内容，加上训练时的通用惯例。

失焦在大项目里的表现

高频剧本有四个。约定漂移：早期对话里定好的命名规范、错误处理风格，对话拉长之后，新代码悄悄回到模型的默认习惯。重复造轮子：项目里已有日期格式化、参数校验函数，AI 看不到，又生成一套平行的实现，两套逻辑从此各自维护。接口不一致：同一个接口这轮返回对象、下轮返回数组，调用方跟着遭殃，机理与重构翻车同源，隐含约定的丢失见AI 重构的风险一篇。过时引用：把已经废弃的模块当现存依赖来写。四个剧本的共同点：每处单看都「合理」，是通用惯例下的合理，唯独不符合这个项目的约定。

关键约束要主动重申

既然 AI 只看得见上下文，就把约束放进上下文。三个做法。约定文档化：把命名规范、目录结构、禁用写法写成一份简短的项目约定，放在每次对话开头带上，或者用支持项目级配置的工具让它常驻，比口头重述可靠。状态阶段化：长任务做到一半，花一分钟让 AI 复述当前进度与已定约定——「到目前为止我们确定了哪些决定」，它答不上来的部分就是已经失焦的部分，及时补上。材料精选化：贴相关代码而非整包粘贴，无关文件只给函数签名不给实现，窗口里的信噪比越高，失焦越少。用 DeepSeek 或通义千问处理中文注释密集的项目时，约定文档同样建议放在首条消息里，注释里夹带的口径多，更值得把关键约束显式写出。

用流程兜住失焦

重申约束降低失焦概率，流程负责兜底，三条线。测试线：约定相关的行为补上自动化测试，AI 偏离约定时测试先红，比人眼发现得早；AI 自己声称的测试结论不算数，采信边界见AI 测试结论的采信一篇。审查线：合入前重点看跨模块一致性——命名、接口签名、错误处理风格，与项目其余部分对照着看，单看一段代码永远发现不了漂移。边界线：上下文不够想「把整个仓库喂给它」之前，先过一遍代码分级，哪些能贴、哪些脱敏、哪些不出内网，见代码保密的三个层级一篇。跨模块改动的连带风险与回归做法，AI 重构的风险一篇有完整流程；AI 忘掉的约定，提交人负责兜住。

上下文管理速查

• 约定成文：规范写进项目文档，每轮对话带上
• 阶段复述：长任务中途让 AI 复述已定约定
• 精选材料：贴相关代码，控制窗口信噪比
• 测试兜底：约定行为进自动化，偏离先红

上下文限制快问快答

• 把整个代码库都喂给 AI，是不是就解决了？：缓解不了根本问题。窗口有边界且注意力会稀释，全喂进去反而让关键约束被淹没；精选相关材料加约定文档，比堆量有效。
• 上下文限制会随着模型升级消失吗？：窗口在变大，但注意力衰减与「只见上下文」的机制不变，大项目里约定文档化、测试兜底这套做法长期有效。
• 新会话接续老任务，怎么让 AI 快速恢复状态？：准备一份交接摘要——已完成什么、约定是什么、下一步做什么，放在新会话开头；比让它翻聊天记录可靠，也比从头解释省时间。