摘要：越来越多企业发现，AI研发工具在项目早期表现亮眼，但随着项目推进，AI的表现开始退化——不是模型变差了，而是上下文失真了。本文深入分析企业级AI研发中的"上下文陷阱"的四种形态，探讨隐性工程知识的系统化方法，并给出可落地的上下文管理体系建设方案。

---

一、现象：AI研发的"三月诅咒"

在与多个引入AI研发工具的技术团队交流后，我们发现了一个规律性现象，姑且称之为"三月诅咒"：

第一个月：蜜月期

团队兴奋，AI能快速搭出原型框架，CRUD接口几乎不用手写，测试样例自动生成，文档注释信手拈来。工程师普遍反馈"效率翻倍"，管理层对AI研发抱有高度期待。

第二个月：疑惑期

开始出现一些奇怪的现象：

• AI修了一个模块的bug，另一个本来好的模块出了问题

• 给AI描述新任务时，它对一个月前已经确认过的业务规则"不知道了"

• 同样的问题，AI给出的解决方案和之前不一致，有时甚至互相矛盾

• 某些边界场景，明明排查过一次，AI在处理新任务时又踩了同样的坑

第三个月：挫败期

部分团队开始对AI研发产生怀疑：

• "感觉AI越来越笨了"

• "我还要给它解释半天背景，还不如自己写"

• "它不记得之前我们讨论的决策，每次都要重新说"

• 悄悄地，AI的使用场景从"核心研发力量"退回到"代码补全辅助工具"

这个现象的根本原因，不是模型能力的退化，而是一个被严重低估的工程问题：上下文陷阱。

---

二、上下文陷阱的四种形态

"上下文陷阱"并非单一问题，而是在AI研发的长周期过程中，由多种因素交织形成的系统性困境。具体表现为四种形态：

2.1 历史决策遗忘

软件系统在演进过程中，会积累大量"设计决策"——不是代码本身，而是代码背后的原因。

一个典型例子：某电商平台的订单状态机，有一个看起来很奇怪的状态转换路径：订单在"待支付"状态下，如果超过30分钟未支付，不是直接关闭，而是先进入一个"预关闭"状态，等待5分钟后才真正关闭。

这个设计的原因是：曾经有一次支付网关延迟，大量用户的支付请求在29分钟时才到达，结果订单被提前关闭，引发了严重的客诉。"预关闭"状态就是为了给支付网关留缓冲时间而设计的。

六个月后，AI在优化订单处理逻辑时，"发现"了这个"冗余"的状态，并将其"优化"掉了。因为在代码里，这个设计背后的原因已经不复存在——只有一个奇怪的状态和一段注释都没有的代码。

这就是历史决策遗忘：AI拥有的只是当前代码的静态快照，看不到代码演进背后的因果链条。时间越长，积累的"不明原因的设计"越多，AI误操作的风险越高。

2.2 约束冲突累积

复杂系统往往有大量隐性约束，来自不同层面：

• 技术约束：某个库的版本锁定在特定版本，是因为新版本有Breaking Change

• 业务约束：某个字段的长度限制是255，是因为下游系统的数据库字段就是varchar(255)

• 合规约束：用户数据的某些字段不能出现在日志里，因为涉及隐私合规

• 性能约束：某个查询必须走特定索引，否则在大数据量下会超时

这些约束分散在不同的地方：代码注释、Wiki文档、邮件记录、老员工的脑子里。AI在处理新任务时，很难全面感知这些约束，一旦某个操作触碰了某条约束，就会引发连锁问题。

更棘手的是，随着系统演进，某些约束可能已经失效（下游系统升级了，varchar(255)的限制已经放开），但没有人更新记录。AI在遵守一个过时的约束，或者违反了一个仍然有效但没有明确标注的约束——两种情况都会出问题。

2.3 依赖关系断裂

现代软件系统的模块间依赖是立体的、隐性的：

• 模块A调用模块B的接口，但依赖的是B在特定输入下的"副作用"（如更新某个全局状态）

• 模块C和模块D共享一套数据模型，但各自对字段的语义理解略有不同

• 系统在某个时序下才能正确运行，而这个时序在任何文档里都没有明确说明

当AI修改了某个模块时，它能看到直接的函数调用关系（通过代码分析），但很难感知这些隐性的依赖。结果是：改了A，莫名其妙影响了B和C，而这两个影响在代码图谱里根本不可见。

2.4 经验无法复用

每个经历过一定规模的软件项目，都会积累大量"踩坑经验"：

• 这个第三方接口在高并发下会超时，需要做熔断处理

• 这类数据在某些边界条件下会出现编码问题，需要特殊处理

• 这个业务逻辑在测试环境能跑通，但生产环境因为数据量级不同会出问题

这些经验，如果有完善的文档体系，会被记录在Wiki或issue中。但更多情况下，它们存在于：

• 老员工的记忆中（人员流动后就消失了）

• 某次代码Review的评论里（深埋在git历史中）

• 某个内部群聊的记录里（根本检索不到）

AI没有访问这些"碎片化经验"的途径。它在处理新任务时，会重复踩同样的坑，每次都要花相同的时间排查——这是最昂贵的浪费，因为它是可预见、可避免、却反复发生的。

---

三、隐性工程知识：AI研发最稀缺的资产

理解了上下文陷阱的四种形态，我们可以抽象出一个更本质的概念：隐性工程知识（Tacit Engineering Knowledge）。

管理学家迈克尔·波兰尼（Michael Polanyi）提出了"隐性知识"概念：有些知识是显性的，可以被明确表达和传递；有些知识是隐性的，存在于实践者的头脑中，难以言传。

在软件工程中，隐性知识尤其丰富：

知识类型	显性知识（可文档化）	隐性知识（难以捕获）
架构决策	架构图、ADR文档	为什么放弃了备选方案B？
业务规则	需求文档、PRD	这条规则背后的业务逻辑是什么？
踩坑经验	部分在Wiki里	大量在老员工脑中、群聊记录里
约束边界	部分在代码注释里	跨模块约束往往无人维护
设计取舍	几乎不被记录	完全存在于当时参与决策的人的记忆里

AI能轻松获取显性知识，但对隐性知识几乎无感。而在真实的长期项目中，决定系统质量和演进方向的，恰恰是这些隐性知识。

这就是为什么：随着项目周期延长，AI研发的瓶颈不是模型能力，而是隐性工程知识的结构化程度。

---

四、上下文管理的技术方案对比

面对上下文陷阱，技术社区已经有多种探索方向。我们来对比分析主流方案的能力边界：

4.1 RAG（检索增强生成）方案

原理：将文档、代码、历史记录等内容向量化存储，AI在推理时实时检索相关片段，补充上下文。

优势：

• 实现相对简单，有大量成熟工具

• 能有效扩展AI可访问的知识范围

• 适合检索明确、结构化的知识（如API文档、功能说明）

局限性：

• 隐性知识的检索质量高度依赖文档质量——如果知识本来就没被记录下来，RAG也无能为力

• 检索是"关键词匹配"的逻辑，对隐性的因果关系理解有限（"为什么这样设计"往往无法被检索到）

• 检索到的片段是碎片化的，缺乏上下文关联，AI需要自行拼接，容易产生理解偏差

• 对实时变化的工程状态（当前任务的进展、最新的约束变更）感知滞后

4.2 知识图谱方案

原理：将代码实体、业务概念、设计决策等以图结构组织，显式标注它们之间的关系。

优势：

• 能捕获实体间的复杂关系（如"模块A依赖于模块B的副作用"）

• 支持关系推理（如"修改了X，会影响哪些下游模块？"）

• 对依赖关系断裂问题有较好的处理能力

局限性：

• 构建和维护成本极高，需要专门的知识工程师

• 隐性知识的图谱化依赖人工标注，难以自动化

• 知识图谱的时效性难以保证（系统频繁变更，图谱可能跟不上）

4.3 结构化决策日志方案

原理：建立架构决策记录（ADR，Architecture Decision Record）规范，将每一个重要设计决策以结构化格式记录：背景、决策、原因、备选方案、后果。

优势：

• 直接解决历史决策遗忘问题

• 轻量级，可以融入现有开发流程

• ADR本身就是AI可读的结构化文本，易于被检索和利用

局限性：

• 依赖团队纪律，容易被忽视（"先写代码，ADR以后补"——然后就没有以后了）

• 只能捕获"被意识到"的决策，隐性知识中最隐蔽的部分仍然无法覆盖

• 随着项目增长，ADR数量庞大，检索效率下降

4.4 基于版本的上下文快照方案

原理：在每个重要里程碑（版本发布、重大重构）时，对当前的工程状态做完整快照：包括架构状态、核心约束、未解决问题、关键决策摘要。

优势：

• 提供时间维度的上下文定位（"在版本2.0时，系统的状态是..."）

• 适合AI研发中的"历史还原"需求（当遇到奇怪问题时，可以回溯到问题出现前的状态）

• 结合ADR，能构建相对完整的决策演进脉络

局限性：

• 快照粒度和频率难以把握

• 跨版本的上下文关联仍需人工梳理

4.5 综合评估

方案	隐性知识覆盖	实时感知	实现成本	维护成本
RAG	中（依赖文档）	中	低	中
知识图谱	高	低	极高	极高
结构化决策日志	中高	中	低	中（需团队纪律）
版本快照	中	低	中	中
研发中枢（综合方案）	高	高	中	低（系统化支撑）

真正有效的上下文管理，需要综合多种方案的优势，并通过系统化的工程基础设施来降低维护成本——这正是研发中枢类产品的核心价值所在。

---

五、建立可持续的上下文管理体系

理论分析之后，来看可落地的实践方案。建立企业级AI研发的上下文管理体系，需要在三个层面同时发力：

5.1 决策记录规范：让隐性知识显性化

核心原则：每一个"为什么这样做而不是那样做"的判断，都应该被记录。

推荐的结构化决策记录格式（ADR增强版）：

markdown

复制

关键点：记录"约束条件"字段，是最容易被忽视但最有价值的部分。它明确了"这个决策在什么情况下仍然有效"，让AI在引用历史决策时能判断其时效性。

5.2 约束注册表：让边界条件可查询

将系统的所有关键约束，集中管理在一个可检索的注册表中：

yaml

复制

constraints:- id: C-001name: 订单状态预关闭缓冲scope: 订单模块type: 业务约束description: 订单超时关闭前必须有5分钟预关闭状态reason: 支付网关偶发延迟，避免支付到账后订单已关闭valid_until: 直到支付网关SLA保证<30s响应为止owner: @payment-team- id: C-002name: 用户ID字段日志屏蔽scope: 全局日志type: 合规约束description: userId字段在任何日志输出中必须被脱敏处理reason: GDPR合规要求，违反可能导致监管处罚valid_until: 永久有效owner: @compliance-team

约束注册表的价值：AI在处理任何任务时，都可以先查询约束注册表，主动识别该任务可能触碰的约束边界，而不是事后出了问题才发现。

5.3 跨任务知识继承机制

在AI研发流程中，引入显式的"知识继承"环节：

任务启动时：系统自动检索与当前任务相关的历史决策、约束、踩坑记录，作为AI的初始上下文。

任务执行中：AI遇到需要做判断的节点（如选择技术方案、处理边界条件），自动记录决策理由。

任务完成后：提取本次任务中产生的新知识（新发现的约束、优化的方案、踩过的坑），更新到知识库，供后续任务继承。

这个机制将"知识沉淀"从依赖个人自律的手工行为，变成了嵌入研发流程的系统行为。

---

六、案例分析：上下文管理体系建设前后对比

6.1 衡石科技的实践

衡石科技在服务WPP、宝马、广汽本田、阳狮集团等大型集团客户的过程中，HENGSHI SENSE产品经历了长达数年的持续迭代。作为一款企业级数据分析平台，其代码库规模庞大、业务逻辑复杂、客户定制需求多样——上下文管理的挑战极为严峻。

在早期，衡石团队同样遭遇了"三月诅咒"：新加入的工程师（包括AI助手）在理解历史设计决策时效率低下，跨模块变更经常引发意外回归。

引入JARVIS的上下文管理体系后，衡石团队实现了关键转变：

引入前的状况：

• 项目进行到第4个月时，AI研发效率开始下滑，平均任务完成时间比第1个月增加了40%

• 每个月有3-5个"重复坑"——之前排查过、本应避免的问题再次出现

• 跨模块变更的回归缺陷率约15%（改了A破坏B的概率）

• 新人加入项目的上手时间平均需要3周（大量时间花在理解历史决策上）

引入JARVIS上下文管理体系后（3个月）：

• 平均任务完成时间在第7个月仍与第1个月持平（"三月诅咒"被打破）

• "重复坑"发生频率下降约70%

• 跨模块变更的回归缺陷率降至约5%

• 新人上手时间缩短至1.5周（JARVIS知识库提供了完整的历史决策脉络）

6.2 关键实践：JARVIS如何解决四种上下文陷阱

上下文陷阱形态	JARVIS的应对机制
历史决策遗忘	架构决策记录（ADR）自动归档，与代码关联，AI执行任务时自动检索相关决策
约束冲突累积	约束注册表统一管理，任务启动前自动检查约束边界，变更时自动校验
依赖关系断裂	代码变更时自动分析影响范围，标注隐性依赖，触发关联模块验证
经验无法复用	踩坑经验自动提取为结构化记录，任务启动时注入相关历史经验

这组数据说明：上下文管理不是"锦上添花"的优化，而是决定AI研发能否持续运转的基础设施。JARVIS的实践证明，通过系统化的工程解法，"三月诅咒"是可以被打破的。

---

七、结语：上下文是AI研发的基础设施

AI代码生成能力的竞争，终将走向同质化——当所有工具都能生成高质量代码时，决定差距的是工程体系。

而工程体系的核心，是上下文管理：

• 历史决策被记录，不被遗忘

• 约束边界被显式化，不再隐藏

• 依赖关系被可视化，变更有据可查

• 踩坑经验被沉淀，不再重复浪费

这不是一个可以靠更好的提示词解决的问题，也不是一个更大的上下文窗口能根本解决的问题。它需要一套系统化的工程解法——在研发流程中内嵌知识沉淀、经验传承、约束管理的机制。

衡石科技的HENGSHI JARVIS正是基于这一认知构建的。JARVIS不是一个更大的对话窗口，而是一个从工程体系层面解决上下文失真问题的研发中枢。它将上下文管理从"依赖个人自律的手工行为"变为"嵌入研发流程的系统行为"，让AI在每一个任务中都能获得完整的工程记忆，而不是从零开始。

当你的AI在第三个月"开始变笨"，不要换模型，先检查你的上下文基础设施——而JARVIS，就是那套基础设施。