AI不懂你的团队知识：开发协作中的上下文断层

AI编程助手为何"不懂"你的项目

加入一个新软件团队时，你拥有GitHub仓库、Jira工单、文档和Slack的访问权限。一切在技术上都触手可及。

但你仍然不知道架构为何是现在这个样子，某个方案为何被否决，上次发布时出了什么问题，哪些决策至今悬而未决。于是你开始问人。问题在于：答案散落在数月以来的对话、PR、工单和文档中，而那些了解历史的人正忙于构建别的东西。

这不仅仅是入职培训的问题。每当有人加入项目、更换团队、重新审视旧决策，或从另一位工程师手中接手工作时，同样的事情都会发生。

这个问题在AI辅助开发时代被进一步放大。AI编程助手的能力越来越强，但它们只能使用手头可得的上下文。你的编码助手可能理解眼前的代码，却不知道团队六个月前为何做出某个特定决策；它可能看到一个bug报告，却不知道导致当前实现的讨论过程；它可能建议一个方案，却不知道团队已经尝试过并否决了它。

真正的挑战并不总是让AI更聪明，而是给AI访问正确知识的通道。

知识孤岛：AI时代的隐性成本

大多数工程团队的知识分布在四类系统中：代码仓库承载最终实现，工单系统记录任务分配和状态流转，设计文档保存方案初稿，而即时通讯工具沉淀了最关键的讨论和决策过程。这四类信息各自独立，彼此之间缺乏有效的关联机制。

当一位开发者提出这样的问题："我们为什么选择这个认证流程？否决了哪些替代方案？还有哪些需要修复？"答案可能同时涉及一个PR、一个Jira工单、一份设计文档和一次旧团队讨论。今天，某个人可能需要找到全部四个来源，然后手动重建整个故事。

这个过程的成本是隐性的——它不体现在代码行数或部署频率上，却直接消耗工程师最宝贵的注意力资源。更糟糕的是，当了解历史的人离开后，这些上下文可能永久丢失。

检索增强生成（RAG）与上下文供给

理解 AI 编程助手为何"不懂"项目，需要区分两类上下文供给方式。一类是把代码、文档等材料直接放进模型的上下文窗口，受限于窗口长度，无法覆盖数月甚至数年的团队历史；另一类是检索增强生成（RAG）——把企业知识切分成片段存入向量库或索引，在提问时先检索出最相关的若干片段，再交给模型作答。RAG 让 AI 不必"记住"全部历史，而是按需调用。但 RAG 的效果高度依赖检索质量：如果决策推理只存在于 Slack 对话里、未被索引，或者 PR 描述写得含糊，检索就召不回关键片段，模型只能基于残缺上下文给出看似合理却重复老路的建议。这正是文章强调"连接各系统信息"的技术必要性。

LISA的解决思路：让知识可追溯、可验证

开发者正在构建LISA，目标是帮助公司将已有知识对员工和AI工具变得有用。核心理念是连接企业各系统中的信息，帮助人们无需手动搜索多个工具就能找到答案、理解项目决策背后的历史、跟上正在进行的工作和待解决的问题、在团队变更和项目交接时保留上下文，并且对照公司底层源来验证答案。

这个愿景超越了搜索本身。目标是让公司知识在最初创造它的人无法解释时仍然保持有用。

以认证流程为例，LISA试图让开发者通过一次查询就能获得来自PR、工单、设计文档和团队讨论的综合答案，并且这些答案有据可查、受公司权限控制。实现这一目标需要四个关键属性：知识必须可访问、有上下文、可验证，并且由组织控制。

知识图谱与实体关联

把 PR、工单、设计文档和讨论串连成完整故事，本质上是一个知识图谱问题：每个 PR、工单、文档、消息都是节点，它们之间的"引用了""解决了""否决了""替代了"等关系是边。传统搜索按关键词匹配孤立文档，而知识图谱可以沿边遍历，把"认证流程"相关的 PR 与当初讨论它、最终否决备选方案的对话串起来。对企业场景而言，图谱还能承载权限元数据，使不同角色只能看到自己有权访问的节点，从而在提供上下文的同时满足合规要求。LISA 所追求的"可验证"，很大程度上依赖于这种显式的实体关联结构，而非让模型凭空推断文档之间的关系。

团队知识管理的三个现实问题

这个方向引发了一些值得每个工程团队思考的问题。

你的团队如何保存技术决策背后的推理过程？ 代码注释和文档通常只记录"做了什么"，而非"为什么这么做"。被否决的方案、权衡的细节、当时的约束条件——这些往往只存在于当事人的记忆中。

当新开发者加入项目时，他们能自己发现事情为何如此运作，还是必须去问当时在场的人？ 如果答案是后者，团队就在承受不应有的知识传递瓶颈。

当AI助手给出建议时，你如何判断它是否了解团队已经尝试过并否决的方案？ 没有企业知识库的支撑，AI的代码建议可能重复团队已经走过的弯路。

这些问题的共同指向是：在AI辅助开发日益普及的背景下，企业知识的组织方式需要从"人找信息"转向"信息随人流动"。把散落在各系统中的上下文连接起来，让AI和人共享同一套可验证的知识底座，可能是释放AI编程真正潜力的关键前提。

架构决策记录（ADR）与决策留痕

文章反复提到"为什么这么做"难以保存，业界对此有一类专门实践：架构决策记录（ADR）。它以短文档形式，为每一个重要技术决策记录背景、可选方案、最终选择及其理由，并随代码库一起版本化管理。ADR 的价值在于把隐性推理显性化，让六个月后的人——以及 AI 助手——都能读到"当时为什么否决了方案 B"。不过 ADR 通常只覆盖被正式认定的架构级决策，日常的取舍、临时的妥协仍散落在 PR 评论和聊天中。因此 ADR 是必要但不充分的，真正的完整上下文仍需与工单、讨论等系统打通，这也呼应了 LISA 试图整合多源信息的方向。