回一个社区问题两分钟，其中三四个答案值得留下来。这动作一周二十次上下——烦的不是回答本身，是回完还得把它搬进知识库。现在我在按保存之前，会先删掉三行东西。⚡
answerLoops 的知识库管理界面里，所有者手动录入问答是保存即发布、立刻进索引，没有草稿态，条目落进“Added by hand”那一类。这条默认值我愿意给它鼓掌，也正因为这样，那个保存按钮在我脑子里改了名：它不是“记一笔”，它是“发布”。发布是要过一遍检查的。
对比一下就很清楚——从 Notion 导进来的内容默认是未发布状态，团队可以先看一遍再决定要不要拿去对外回答，而且这个选择在后续同步里会保留。手动录入没有这个待遇。
第一个，删字段。用 Promote to KB 把已解决工单转成文章的时候，工单里天然带着一堆只对那一个人成立的东西。
保存前删掉：@用户名、邮箱、订单号、内部工单链接、私有仓库名
留着有用：报错原文、版本号、平台、复现步骤
我一开始觉得这步多余，内部知识库嘛。不对。网站聊天组件检索的是已发布文章，不是原始工单——你漏一个订单号，它就有机会出现在某个陌生用户的对话框里，而你事后不会收到任何提醒。
更阴的是 Knowledge Gaps 里那个 + KB 按钮：点开会把工单的问题和现有答案预填好，保存之后还会关联回原工单把缺口关掉。太顺了。顺到你会直接按保存。正因为预填好了，才最容易漏删——这跟“从零写一条”完全是两种心理状态，前者你在编辑，后者你在校对。
第二个，把答案写成别人能用的形状。工单里那段答案是写给你和当事人看的，满是“我刚帮你看了”“你这个配置”。Promote 之后它要面对完全不知道上下文的人。
Q: 用用户的原话，别改写成你内部术语
A: 症状一句 → 检查项两三条 → 还是不行去哪儿问
模板短得有点可笑，但它逼你在保存前想一次“这条以后会被谁检索到”。手动加文章不会重训模型，就是给 agent 多一份在相关问题出现时能捞出来的参考来源——所以答案的形状直接决定它捞出来有没有用。
第三个，Review 队列别当收件箱，当待办。它收的是现有知识没覆盖的问题，重复的只加计数不新建条目，问得最多的排最前。设计是对的，但也意味着你不清它就一直在那儿堆。
我固定每天收工前十分钟过一遍，只做两个动作——批准，或者拒绝。不在队列里现场写长答案，那是另一个时段的事。
# 每天 17:40 提醒，工作日
40 17 * * 1-5 osascript -e 'display notification "只做批准/拒绝" with title "Review 队列"'
这一下⚡ 起作用的是“只做两个动作”这个约束，不是提醒本身。队列一旦允许你在里面顺手写答案，十分钟就变四十分钟。
顺手补一句边界：仪表盘上那个“上下文提供次数”别拿去当 KPI。一次回答喂了三篇文章、答案只用了其中一篇，三篇全计数，现在还没有“检索到但没被采纳”这个状态。作者在评论里认了，issue 也开了，说要把“提供”和“实际引用”拆开。在那之前这个数字只能告诉你“有没有被检索到”，不能告诉你“有没有用上”。
第四个，自动回复先关着。默认就是关的，这个默认值别手快去改。要开之前我给自己定了三条门槛：
1. Review 队列两周没有“无可用答案”堆积
2. coverage 里用真实客户原话打五条，全命中
3. 自动发送只放“怎么装/怎么配”，账单、权限、数据一律人工
第二条的原因是，coverage 那个客户问题测试字段跑的是和网站组件一模一样的检索，它只能证明“找得到那篇文章”，证明不了“生成的回答是对的”。这两件事差得挺远，混在一起就容易出事。
最后，我这套东西学起来十分钟：一份删除清单，一个提醒，三条门槛。省下来的不是打字的时间，是“发出去之后才想起来没删干净”那种事后排查——那种排查一次就是小半天，怎么算都回本。
老实说，如果你一周只回一两个问题，这套流程比手动回还慢，跳过就行。有更省事的写法，教教我。