9 篇博文 含有标签「knowledge-management」

你最高产的工程师刚刚递交了辞呈。你对这套流程已经烂熟于心：移交工单、记录部署流程、交接值班轮换、安排知识分享会议。这份离职核查清单经过了数十年的完善，涵盖了公司认为其拥有的一切资产。

以下是 2026 年的核查清单所遗漏的内容：那位工程师的家目录（home directory）中包含一个经过 18 个月调校的个人 CLAUDE.md 文件、十几个编码了如何处理最棘手子系统的自定义技能（skills）、存储了智能体积累的关于代码库难点事实的记忆文件，以及经过数百次尝试和错误校准的座架（harness）设置。这些都不在代码仓库中，也不会随账号一起移交。

在他们的最后一天，IT 部门停用了笔记本电脑，数月积累的智能体配置——这正是他们的智能体能独立交付功能而其他人的智能体却在挣扎的区别所在——在无人察觉的情况下蒸发了。

就在此时，你的笔记本电脑里的某个角落正存放着你的团队有史以来最详尽的工程决策记录，却没有任何人读过其中的一个字。每一个智能体会话 —— 无论是每一次 Claude Code 的运行、每一次 Cursor 对话，还是持续数小时的重构历程 —— 都会被记录成一份转录文本（transcript）。它包含了尝试过又被放弃的三种方案、导致产生这种丑陋临时方案的约束条件，以及你否决模型建议的时刻及其原因。然后会话结束，PR 带着一行 commit message 被合并，所有这些上下文都进入了一个永远不会被打开的 JSONL 文件。

以前，我们丢失这些信息是“理所当然”的。某个设计选择背后的推导过程只存在于某个人的脑子里，随着时间推移而淡忘，并在他们换工作时彻底流失。当时没有什么可以保存的，因为根本没有记录下来。这种借口已经不复存在了。现在的推导过程正被逐字逐句地记录下来，带有时间戳，机器可读 —— 而我们却将其视为随手可弃的废气。

大多数构建 RAG 系统的团队在第一个月都花在流水线（pipeline）上——分块策略、嵌入模型选择、向量数据库配置、检索微调。他们让系统跑通了。演示顺利通过。利益相关者印象深刻。

六个月后，系统开始悄无声息地退化。支持工单提到了错误的流程。机器人引用了一个已经在第三季度停用的价格档位。客户得到了关于一个在他们注册前就已弃用的产品功能的肯定回答。流水线没问题，问题出在知识库上。

你的 RAG 系统通过了所有检索基准测试。准确率看起来很稳健。LLM 评估器评分全部绿灯。然而，在你的索引某处，存在一份描述八个月前已废弃 API 端点的文档、一个已不复存在的定价层级，以及一项在第三季度被新法规取代的合规政策。检索器对此毫不知情。语义相似度没有时间概念。

这就是知识半衰期问题：一种隐蔽的失效模式——RAG 系统在你所有监控指标上看起来健康运行，却在向用户提供越来越陈旧的决策依据。73% 的组织报告称，RAG 部署在 90 天内出现准确率下滑——原因不是检索架构缺陷或 Embedding 模型质量问题，而是没有人将知识过期建模为可靠性关注点。

你最棒的系统提示词是由一位已经不在这里工作的人编写的。

那句话的杀伤力取决于你在组织中所处的位置。如果你是一名继承了一个管理着生产级 AI 功能的、未经文档记录的 3,000 token 提示词的工程师，你肯定已经经历过这种情况。你盯着像“除非上下文需要，否则不要包含补充数据”这样的条款，却完全不知道“上下文”意味着什么，是什么触发了这条规则，或者删除它会导致 5% 的质量提升还是灾难性的性能回归。如果你是一名团队负责人，你眼睁睁地看着制度性知识随着每一位资深工程师或提示词专家的跳槽而流失——而这些知识并没有进入文档，因为没有人意识到有什么需要记录的。

这就是系统提示词的知识管理问题，它比大多数团队意识到的还要严重。解决办法借鉴了机器人研究中的一个理念，并将其应用于一个深刻的人性化工程挑战：行为克隆 (behavioral cloning) —— 捕捉专家做了什么，以及背后的原因，在他们离职之前。

打开公司里那位上线真实的 AI 功能超过六个月的工程师的日历。数一数那些重复出现的 “30 分钟同步 —— 关于 Agent 的问题” 邀请，那些最终被预定的即时 “能耽误你 15 分钟吗？” Slack 消息，那些被标记为 “可选” 但他们实际上不得不参加的架构评审，以及最初只是周五下午的一个时段、现在却每天吞噬两个小时的 Office Hours。然后看看路线图，追踪哪些功能取决于该工程师尚未做出的决定。两者的交集才是你真正的发布时间表。Jira 看板只是虚构。

这就是 AI Office Hours 瓶颈，它在 2026 年的 AI 组织中是核心承重约束，尽管组织里没人会大声说出来。团队快速扩展了 AI 功能开发 —— 每个产品小组都拿到了模型预算，每个 PM 都学会了写 Prompt —— 然后把每一个 “这个模型对吗”、“这里该不该用 RAG”、“我们的评估设计是否有效”、“为什么缓存命中率很奇怪” 的问题都抛给了唯一那个真正上线过足够多生产环境 AI 功能、能给出答案的工程师。六个月后，那位工程师的日历成了半个路线图的限速试剂，“我需要找他谈 30 分钟” 成了你的事故响应本该明确化的核心升级路径。

你的企业刚刚部署了一个 RAG 系统。你索引了每个 Confluence 页面、每份运行手册（runbook）、每篇架构文档。六个月后，一位高级工程师离职了——就是那个知道为什么支付服务会有那种不寻常的重试模式、为什么你们从不把缓存扩容超过 80%，以及周五绝对不要给哪家供应商打电话的人。这些知识从未被记录下来。你的 RAG 系统根本不知道它的存在。

这就是隐性知识（tacit knowledge）问题。这也是为什么大多数企业 AI 系统表现不佳的原因——不是因为检索质量或幻觉，而是因为它们所需的知识从一开始就没被捕获。60% 的员工表示，很难甚至几乎不可能从同事那里获取关键信息。90% 的组织表示，员工离职会导致严重的知识流失。你的 RAG 能索引的文档只是冰山一角。

负责构建客户支持 AI 的工程师离职去迎接新工作了。在他们的最后一天，你进行了一次离职面谈，并要求他们记录下所知道的一切。他们写了几段文字来解释系统的工作原理。六个月后，客户满意度评分开始下降。有人建议微调系统提示词（system prompt）的语气。另一位工程师进行了修改，运行了几次手动测试，然后上线了。三周后，你发现原始系统提示词中的一个特定措辞其实起到了没人知道的关键支撑作用——它是防止模型在周五下午过度升级工单的唯一机制，这是最初的工程师注意到并用一句话悄悄修复的模式。

没有人知道那句话的存在是有原因的。它看起来像是实现细节，但实际上是组织知识（institutional knowledge）。

在一个金融科技团队推出 AI 编程智能体来处理日常后端任务的三个月后，一位资深工程师离职去了另一家公司。当团队试图还原六周前做出某些身份验证决策的原因时，却发现没有人能做到。PR 描述写着“按讨论实现”，提交信息写着“根据需求”。AI 智能体做出了选择，代码正常运行，而背后的推理过程却消失得无影无踪。

这并非文档记录的失败。当原本用于传递理解的渠道——工程师之间的往复沟通、解释带来的摩擦、向他人证明决策合理性的压力——被一个优化输出而非优化理解的系统所取代时，必然会发生这种情况。