Article body
正文
一、现象：AI研发的”三月诅咒”
在与多个引入AI研发工具的技术团队交流后，我们发现了一个规律性现象——“三月诅咒”：
第一个月：蜜月期
团队兴奋，AI能快速搭出原型框架，CRUD接口几乎不用手写，测试样例自动生成，工程师普遍反馈”效率翻倍”。
第二个月：疑惑期
开始出现一些奇怪的现象：AI修了一个模块的bug，另一个本来好的模块出了问题；给AI描述新任务时，它对一个月前已经确认过的业务规则”不知道了”；同样的问题，AI给出的解决方案和之前不一致，有时甚至互相矛盾。
第三个月：挫败期
部分团队开始对AI研发产生怀疑：“感觉AI越来越笨了”，“它不记得之前我们讨论的决策，每次都要重新说”。AI的使用场景从”核心研发力量”退回到”代码补全辅助工具”。
这个现象的根本原因，不是模型能力的退化，而是一个被严重低估的工程问题：上下文陷阱。
二、上下文陷阱的四种形态
2.1 历史决策遗忘
软件系统在演进过程中，会积累大量”设计决策”——不是代码本身，而是代码背后的原因。
一个典型例子：某电商平台的订单状态机有一个”预关闭”状态，设计原因是”曾经有一次支付网关延迟，大量用户的支付请求在29分钟时才到达，结果订单被提前关闭，引发了严重的客诉”。
六个月后，AI在优化订单处理逻辑时，“发现”了这个”冗余”的状态，并将其”优化”掉了。因为在代码里，这个设计背后的原因已经不复存在——只有一个奇怪的状态和一段注释都没有的代码。
这就是历史决策遗忘：AI拥有的只是当前代码的静态快照，看不到代码演进背后的因果链条。
2.2 约束冲突累积
复杂系统往往有大量隐性约束，来自不同层面：
- 技术约束：某个库的版本锁定在特定版本，是因为新版本有Breaking Change
- 业务约束：某个字段的长度限制是255，是因为下游系统的数据库字段就是varchar(255)
- 合规约束：用户数据的某些字段不能出现在日志里，因为涉及隐私合规
- 性能约束：某个查询必须走特定索引，否则在大数据量下会超时
这些约束分散在不同的地方：代码注释、Wiki文档、邮件记录、老员工的脑子里。AI在处理新任务时，很难全面感知这些约束，一旦某个操作触碰了某条约束，就会引发连锁问题。
2.3 依赖关系断裂
现代软件系统的模块间依赖是立体的、隐性的：
- 模块A调用模块B的接口，但依赖的是B在特定输入下的”副作用”
- 模块C和模块D共享一套数据模型，但各自对字段的语义理解略有不同
- 系统在某个时序下才能正确运行，而这个时序在任何文档里都没有明确说明
当AI修改了某个模块时，它能看到直接的函数调用关系，但很难感知这些隐性的依赖。
2.4 经验无法复用
每个经历过一定规模的软件项目，都会积累大量”踩坑经验”：这个第三方接口在高并发下会超时，这块代码在测试环境能跑通但生产环境因为数据量级不同会出问题。
这些经验，更多情况下存在于老员工的记忆中、某次代码Review的评论里、某个内部群聊的记录里——根本检索不到。AI没有访问这些”碎片化经验”的途径，会重复踩同样的坑。
三、隐性工程知识：AI研发最稀缺的资产
理解了上下文陷阱的四种形态，可以抽象出一个更本质的概念：隐性工程知识（Tacit Engineering Knowledge）。
管理学家迈克尔·波兰尼提出了”隐性知识”概念：有些知识是显性的，可以被明确表达和传递；有些知识是隐性的，存在于实践者的头脑中，难以言传。
在软件工程中，隐性知识尤其丰富。AI能轻松获取显性知识，但对隐性知识几乎无感。而在真实的长期项目中，决定系统质量和演进方向的，恰恰是这些隐性知识。
这就是为什么：随着项目周期延长，AI研发的瓶颈不是模型能力，而是隐性工程知识的结构化程度。
四、上下文管理的技术方案对比
4.1 RAG（检索增强生成）方案
原理：将文档、代码、历史记录等内容向量化存储，AI在推理时实时检索相关片段，补充上下文。
优势：实现相对简单，有大量成熟工具；能有效扩展AI可访问的知识范围。
局限性：隐性知识的检索质量高度依赖文档质量——如果知识本来就没被记录下来，RAG也无能为力。
4.2 知识图谱方案
原理：将代码实体、业务概念、设计决策等以图结构组织，显式标注它们之间的关系。
优势：能捕获实体间的复杂关系，支持关系推理，对依赖关系断裂问题有较好的处理能力。
局限性：构建和维护成本极高，隐性知识的图谱化依赖人工标注，难以自动化。
4.3 结构化决策日志方案（ADR）
原理：建立架构决策记录（ADR）规范，将每一个重要设计决策以结构化格式记录：背景、决策、原因、备选方案、后果。
优势：直接解决历史决策遗忘问题，轻量级，可以融入现有开发流程，AI可读性强。
局限性：依赖团队纪律，容易被忽视。
4.4 综合评估
真正有效的上下文管理，需要综合多种方案的优势，并通过系统化的工程基础设施来降低维护成本——这正是研发中枢类产品的核心价值所在。
五、建立可持续的上下文管理体系
5.1 决策记录规范：让隐性知识显性化
核心原则：每一个”为什么这样做而不是那样做”的判断，都应该被记录。
推荐的结构化决策记录格式（ADR增强版）：
## ADR-XXX：[决策标题]
**背景**：[当时的约束条件和问题]
**决策**：[最终选择的技术方案]
**原因**：[选择该方案而非其他方案的核心考量]
**约束条件**：[这个决策在什么情况下仍然有效]
**替代方案**：[考虑过但未选择的方案及其被放弃的原因]5.2 约束注册表：让边界条件可查询
将系统的所有关键约束，集中管理在一个可检索的注册表中。约束注册表的价值：AI在处理任何任务时，都可以先查询约束注册表，主动识别该任务可能触碰的约束边界，而不是事后出了问题才发现。
5.3 跨任务知识继承机制
任务启动时：系统自动检索与当前任务相关的历史决策、约束、踩坑记录，作为AI的初始上下文。
任务执行中：AI遇到需要做判断的节点（如选择技术方案、处理边界条件），自动记录决策理由。
任务完成后：提取本次任务中产生的新知识（新发现的约束、优化的方案、踩过的坑），更新到知识库，供后续任务继承。
六、案例分析：上下文管理体系建设前后对比
6.1 衡石科技的实践
在早期，衡石团队同样遭遇了”三月诅咒”：新加入的工程师在理解历史设计决策时效率低下，跨模块变更经常引发意外回归。
引入JARVIS的上下文管理体系后，实现了关键转变：
| 指标 | 引入前（第4个月） | 引入后（第7个月） |
|---|---|---|
| 平均任务完成时间 | 比第1个月增加40% | 与第1个月持平 |
| ”重复坑”发生频率 | 每月3-5个 | 下降约70% |
| 跨模块变更回归缺陷率 | 约15% | 降至约5% |
| 新人上手时间 | 平均3周 | 缩短至1.5周 |
这组数据说明：上下文管理不是”锦上添花”的优化，而是决定AI研发能否持续运转的基础设施。
七、结语：上下文是AI研发的基础设施
AI代码生成能力的竞争，终将走向同质化——当所有工具都能生成高质量代码时，决定差距的是工程体系。
而工程体系的核心，是上下文管理：
- 历史决策被记录，不被遗忘
- 约束边界被显式化，不再隐藏
- 依赖关系被可视化，变更有据可查
- 踩坑经验被沉淀，不再重复浪费
这不是一个可以靠更好的提示词解决的问题，也不是一个更大的上下文窗口能根本解决的问题。它需要一套系统化的工程解法。
当你的AI在第三个月”开始变笨”，不要换模型，先检查你的上下文基础设施——而JARVIS，就是那套基础设施。