查一个产品参数，搜出来一份几十页的 PDF，还得打开再找。文件是找到了，工作只做了一半。
再往后看，即使这次找到了准确答案，下周同事遇到相似问题，仍然可能重新搜索、重新问人。一个答案在对话里很好用，不意味着它已经进入团队的能力。
我想把知识工程沿着使用过程展开：从找到材料，到理解它回答什么，再到带着适用条件进入下一次工作。
文件命中与问题解决之间还有距离
我维护产品资料和可用性资料两套知识库。它们分开，是因为“这个功能怎样配置”与“这条要求在什么条件下适用”，需要不同上下文。
对一个准确型号或术语，关键词可能直接定位。对一段不确定的自然语言描述，语义检索可以帮助找到候选材料。但返回相关片段，还需要检查它是否真正回答了问题。
一份旧版手册可能与提问高度相似，却对应不同配置。一段方法说明可能没有错，却省略了前面的适用条件。因此，我会把检索结果当成判断的入口，并保留回到原文的位置。
“找到了”与“可以这样用”，应当是不同状态。
切分资料，其实在安排解释的边界
段落太长，返回一个章节，使用者仍需筛选。太短，前提、限制和术语定义容易掉在另一块里。
我希望每个片段能独立读懂，同时知道它来自哪份材料、哪个章节、哪一版本。遇到不能拆开的定义和例外，应优先保留完整意思，而不是机械追求统一长度。
资料之间的关系也重要。一份更新说明可能改变旧手册的解释，一条通用方法可能在某个任务中存在例外。把它们分别存得很整齐，却不保留关系，检索时仍会让使用者自己拼接。
这些判断无法在建库第一天全部完成。真实问题会不断暴露哪里切得不合适、缺了什么连接，需要回写到整理方式里。
从结论条目转向有上下文的知识条目
假设一篇论文发现某种交互方式在实验中表现更好。团队如果只保存“方式 A 优于 B”，下次很容易把它带到不同的人群和任务里。
我更希望条目同时留下研究问题、参与者与任务、比较条件、主要结果、限制，以及它可能影响的决定。某种方法有启发，不等于已经适用于我们的项目。
Gebru 等人的 Datasheets 工作提出记录数据集的动机、构成、收集过程和推荐用途。我借用的是保留使用条件的思路；团队知识条目并不是该论文所验证的另一类系统。Datasheets for Datasets
这种组织方式使知识可以被反驳和更新。新材料与旧结论冲突时，我们可以检查是任务不同、样本不同，还是原来的判断需要修改，而不是只把两个摘要并排放着。
可访问性会改变知识是否被使用
一份简报如果只能在作者的聊天记录里找到，或者需要别人安装额外工具才能打开，其使用范围会受限。
这也是我关心 HTML 页面、可复制表格和可重新部署内容的原因。不同媒介适合不同动作：页面适合长期引用和浏览，表格适合比较与继续整理，原始文件适合回查细节。
但采用网页也不能自动证明人人都能访问。实际读者的网络、手机显示、登录要求和下载条件，都需要检查。尤其面对不同地区的同事，作者自己能打开只是起点。
表达还要围绕读者的任务。研究人员需要方法与限制，产品团队需要应用条件和待验证机会。不是给两群人各写一套互不相连的结论，而是让他们从同一来源进入不同阅读层次。
更新要能影响旧答案
知识库最容易显得成功的时刻，是刚整理完成。真正困难的是材料更新以后，旧的检索结果和旧结论是否还会继续流通。
我会区分原始来源、提炼条目和实际使用记录。来源更新，需要检查哪些条目受影响；条目修改，需要说明改变了什么；旧项目引用过的版本则应该能够回查。
过时不一定意味着删除。有些历史判断仍有解释价值，只是不再适合作为当前建议。保留时间和状态，比把所有内容悄悄替换成“最新版”更容易理解过去为什么那样决定。
责任也需要具体。谁发现材料变化，谁判断是否影响使用，谁更新条目，谁处理同事提出的疑问？没有这些安排，知识库可能只是更容易搜索的文件堆。
用下一次工作检验知识系统
我不太关心条目数量本身。更有用的检查是，同事能否找到相关材料，能否判断是否适用，还需要多少额外翻找，以及哪里仍必须请作者重新解释。
“没有答案”也值得记录。是资料确实不足，还是已有材料难以找到？前者需要研究，后者需要改善组织。把两者混在一起，会让团队反复购买已经拥有的信息，或误以为整理能够填补事实缺口。
如果下一次项目产生新的限制或反例，应该有一个方便回写的位置。系统维护越接近日常工作，经验越不容易只留在个人记忆里。
我想要的循环是：具体问题触发查找，资料支持当前判断，实际使用检验这个判断，新发现再改变资料的组织与说明。这与把研究做成 Skill互相补充：一个保存怎样做，一个保存做的时候应当知道什么。