覆盖率问题的解法，不是「让专家们更努力」，而是把验证这件事的成本打下来，把回流的管道修出来。这一章讲具体怎么做。
原则一：让验证发生在工作流里，而不是工作流外
最失败的机制设计，是给专家新增一个任务：「请在下班后填写知识资产反馈表」。这等于要求别人用休息时间做一件没有即时回报的事，回流率必然是零。
正确的设计是把验证嵌进他正在做的事里。张医生看 AI 诊断建议的那个界面，旁边就应该有一个「这条不对，应该是……」的输入框——一次点击、一句话，三十秒。反馈不是额外工作，是工作的一个手势。
软件业有现成模板：报错弹窗里的「发送错误报告」按钮。工程师不需要写邮件描述 bug，崩溃现场自动打包，一键回传。这个设计让全世界的软件用户变成了免费的测试员——数亿人每天都在为软件做验证，他们自己都没意识到。知识资产要的回流管道，就是这个东西的业务版。
原则二：能自动化的验证，绝不留给人
第四章说过，软件业攒了一整套自动化验证家当。这些家当对知识资产同样适用，只是要翻译一下：
- 给提示词写「单元测试」：攒一批有标准答案的历史病例，每次改提示词就自动跑一遍——改了「儿童用药史」之后，原来能答对的三十个病例还答得对吗？这叫回归测试，防止改进一处、搞砸三处。没有它，知识资产的每次迭代都是盲人摸象。
- 基准集：把「什么叫好」量化成一组固定考题。新版本先过考题再上线，不依赖某一个人的印象分。
- 灰度发布：新版本先给 5% 的使用场景跑，指标正常再全量。生物界管这个叫「小规模试错」，软件业管这个叫金丝雀发布——矿井里先放金丝雀，有毒气它先倒。
自动化验证每多覆盖一分，人类专家的稀缺判断力就省下来一分，花在真正需要品位的地方。
原则三：让贡献可见，让回路闭合
人为什么愿意当开源软件的贡献者？三个原因：贡献被署名、改动被采纳有即时反馈、自己的名字进入了「这个资产的作者列表」。这三样，组织内部的知识资产一样可以照搬：
- 每一版资产的更新日志写上：「本次改进来自急诊科李医生的发现」。
- 有人提交发现后，三天内必须得到回应——采纳或说明为什么不采纳。沉默是回流管道的头号杀手：一个发现石沉大海，这个人这辈子不会再提交第二次。
- 把验证贡献计入对专家的评价。如果考核表上只有「看了多少病人」，那验证永远排在最后。
大白话：让专家当验证者，本质是修一条从「现场发现」到「资产更新」的管道。管道的两头都要降阻力：提交这头要做到三十秒一次点击，回应这头要做到三天内有说法。管道中间，能机器判的别让人判。
小结
三个原则合起来一句话：验证不是靠觉悟，是靠设计。嵌进工作流、自动化能自动化的、让贡献可见——做到这三点，覆盖率问题就从「专家不愿意」变成「管道有多粗」的工程问题，而工程问题是有解的。
验证的问题解决了，改进攒下来了。但这些改进如果只存在某个角落，进化就还没完成——还差最后一个齿轮：复制。下一章。