- 公司最宝贵的知识，往往装在少数几个人的脑子里，他们离职那天，这些知识也跟着走了。
- 别一上来就让他们写手册。从记录他们实际解决问题的过程入手，得到的东西更管用。
- 好的系统每次回答都要注明出处，让人能核对答案来自哪份文件。
先从容易失传、又真正有人在用的知识开始
问问自己：如果跟了您二十年的老师傅明天辞职，哪些工作会马上卡住？这个问题的答案，就是应该最先保存的知识清单，不必从给全厂挨个写手册做起。
用四个问题画出知识风险地图（Knowledge Risk Map）：这个人不在，哪些工作会停？出错的后果有多严重？要教多久才能教会？还有几个人懂？然后给具体情况排优先级，比如总要叫资深技师来处理的故障代码、换原材料时的调机、大客户的特殊例外，或者涉及安全的步骤。
别泛泛地问专家想传授什么。挑一起真实发生过的事件（Incident），陪他从头走一遍（Walk-through）：看到了什么信号，想到了哪些原因，按什么顺序检查，什么时候必须停下，新手通常在哪里出错。除了常规步骤，还要把理由和前提条件记下来。
把经验变成知识卡片（Knowledge Card）
比起请他写手册，更有效的办法是在他实际解决问题时跟在旁边，记下他先看什么、凭什么做决定，以及遇到过哪些这个办法行不通的情况。
| 栏目 | 必须包含的信息 |
|---|---|
| 背景 | 设备、型号、客户、情境和限制条件 |
| 症状/问题 | 用户实际搜索时的说法，以及同义词 |
| 检查步骤 | 顺序、理由、参考值和图片 |
| 禁止事项 | 安全要求、公司规定，以及何时转交专家 |
| 依据 | 手册、工单或审批人 |
| 生命周期 | 负责人、版本、复审日期、状态 |
可以用 AI 转写录音、整理结构、生成草稿，但发布之前必须由专家核对内容是否准确。把内容拆成小块，每块只回答一个问题，并链接到完整手册。明确标注草稿（Draft）、已批准（Approved）和已弃用（Deprecated）三种状态，旧文件在搜索中的排序不能和现行版本一样靠前。
设计一个会注明出处、也敢说“不知道”的助手
系统在检索之前应先问清背景，比如设备型号、故障代码、客户，或者已经试过哪些办法。回答必须显示出处、版本和日期，并把已确认的内容和建议分开。依据不足时，就回答“没有找到”，同时建立升级处理的路径，绝不能凭常识编造安全步骤。
按角色、厂区和保密等级限制权限。按照隐私政策记录提问、所用的来源和用户反馈。不要把所有聊天记录自动写回知识库（Knowledge Base），否则误解会越传越广。应该让 AI 起草更新，再由负责人审批。
上线前的测试集
- 常规问题，以及同一问题的多种问法
- 相似但处理方法不同的型号或条件
- 没有答案、系统必须停下的问题
- 用户无权查看的数据
- 不能再推荐给用户的旧内容
让知识库保持更新，并产生实际效果
把更新和日常工作绑在一起：重要的工单或事件关闭时，让 AI 根据记录起草知识卡片，专家核对后再发布。仪表盘上列出答不了的问题、人工推翻过的回答、快要过期的内容和没人看的文章，形成一份待改进的质量清单（Backlog）。
写给开发团队 · 技术指标
把获得答案的时间（Time-to-Answer）、一次修复率（First-time Fix）、重复事件（Repeat Incident）、升级次数、新员工上手时间（Onboarding）和安全差错（Safety Error）放在一起衡量。如果答案是错的，使用率（Adoption）再高也没用。先从 20 个问题和一个班次的团队做起，效果好了再扩展到更多类别和语言。
做成功的标志，是形成一个循环：专家的贡献得到认可，新员工学得更快，企业每遇到一次真实事件就修订一次经验。有了这个循环，系统才会成为有专人负责的组织记忆，不至于沦为又一个文件库；光把知识从人身上挖出来，做不到这一点。
INTERVIEW TECHNIQUE · 把思路问出来
用决策复盘（Decision Replay）代替“您有什么要教的吗”
拿出最近一次事件，打开当时的照片或工单，请专家一步一步讲：看到了什么，排除了哪些可能，哪个信号让他改变了判断。问一句“换成新手，会在哪里出错”，往往比请他对着白纸写手册，更能挖出隐性知识（Tacit Knowledge）。
回答的 3C 原则
Context（背景）：适用于哪台设备、哪位客户；Citation（出处）：注明来源和版本；Cut-off（止步点）：说明在哪里停下、转交专家。三个 C 缺了任何一个，这个回答都还不能拿到现场用。
提示：在知识卡片上署上传授人和审核人的名字。专家感到自己受重视，就会把分享看成传承手艺，不会觉得别人掏走了自己的知识，再拿系统来顶替自己。
从知识到真正能解决问题的系统
问题的根源
好的知识系统（Knowledge System）用不着什么问题都回答。它的回答出自经过审批的来源，说明适用背景，也知道什么时候该停下。
分步解决方案
- 绘制知识风险地图，并围绕真实事件做决策复盘
- 整理成知识卡片，写明背景（Context）、出处（Citation）、止步点（Cut-off）和负责人
- 搭建基于检索（Retrieval）的助手，配好权限、反馈和复审机制
让企业的知识能回答问题，同时清楚每条知识由谁负责
有价值的知识库，要比一个文件搜索框做得更多。DNA Maker 先帮企业挑出重要的问题，搭好分类体系（Taxonomy）、元数据、负责人、版本和需要升级处理的节点。内容由客户自己的专家把关，我们负责设计采集（Capture）和检索的方式，让回答带上背景和出处。这样用户不必盲目相信 AI，企业也能看出哪些问题还没有知识支撑。
DNA Maker 可以在 Web 或移动端开发知识门户（Knowledge Portal）、企业搜索（Enterprise Search），或者基于检索增强生成（RAG）的 AI 智能体（AI Agent），对接 SOP、手册、工单和内部资料，按角色分配权限，回答时附上出处，收集反馈，资料不足时转交专家。我们可以从知识梳理工作坊、对话体验设计、数据准备、系统架构、开发，一直做到效果评测和数据分析。如果企业文件很多，员工却还是要反复去问同几个人，我们可以帮您把这些知识变成好查、可信、也能持续维护的系统。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这张表用不着背。它的用处是让管理层、工作负责人和开发团队沟通时，对同一个词不会有两种理解。请把释义、示例和右侧的问题一起看，这些问题常常能在开发开始之前，把隐藏的范围、风险和成本揭示出来。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| RAG | 让 AI 先检索企业自己的资料，再回答 | 根据已审批的 SOP 回答，并附上文件链接 | 系统从哪些来源检索？怎样避免调出旧文件？ |
| Embedding | 把内容转成一串数字，以便按意思检索 | 搜“机器发烫”，能找到写着“温度过高”的文件 | 泰语资料和专有名词真的能搜到吗？ |
| Metadata | 附在文件上的说明信息 | 标明设备型号、负责人和失效日期 | 查找和管控文件需要哪些必填字段？ |
| Access Control | 控制谁能看到哪些数据 | 某个团队只能看到所在厂区的手册 | 权限如何继承？员工调岗时怎样撤销？ |
| Citation | 注明回答的来源 | 显示手册名称、版本和页码 | 用户能打开原文、查看版本吗？ |