service 三页仍写「建议一个解决方案」会检索知识库并起草回复 / Copilot 用知识库对相似历史工单做模式匹配——两个技能都做不到 #890

发现自 #808（四个知识库写实）的实施过程。#808 的裁定面是知识库实体是否存在，而这三处的主语是技能能力（哪个技能会检索文章），属于 #860 / PR #865 已经确立口径的那一族，不在 #808 的 scope 内，故单独立单，未在该 PR 里顺手改。

现象（实测 origin/main @ 0d3f321）

三个页族 ×3 语言共 6 处，把「检索知识库并起草回复」记在做不到这件事的技能名下：

1. content/docs/service/cases.mdx:156（zh-Hans / zh-Hant 同位 :156）

   - *"Suggest a resolution"* — searches the [Support Knowledge Base](/docs/service/knowledge-base) and drafts a customer reply.
   

2. content/docs/service/index.mdx:48（zh 同位 :48）

   - *"Suggest a resolution"* — searches the support knowledge base and drafts a customer reply.
   

3. content/docs/service/sla-and-escalation.mdx:105（zh 同位 :105）

   - The Copilot uses the [Support Knowledge Base](/docs/service/knowledge-base) to pattern-match against similar past cases.
   

与源码对照

• src/skills/case-triage.skill.ts:49 的 tools 只有 ['describe_object', 'get_record']——没有任何检索类工具，既检索不了文章，也拉不出「相似的历史工单」。它返回的是优先级 + 判定理由 + 升级/关闭指引。
• src/skills/email-drafting.skill.ts:21-37 的五步 instructions 从头到尾没有一步去取知识来源，因此草稿不会引用文章（PR docs(ai-copilot): 按 skill 源码写实 service-copilot 其余段落的能力残留 (#860) #865 已把 service-copilot 页按这条写实）。
• 真正会读文章的是 customer_360（src/skills/customer-360.skill.ts:48-52，query_records 查 status 已发布、按工单的 category / tags 匹配）。

也就是说，「建议一个解决方案」这句话跨了两个技能，而两个技能都不做其中的检索部分。#865 已经在 content/docs/ai-copilot/service-copilot.mdx 上把同一事实写实，这三页是同一批说法里没被那单覆盖到的部分。

附带的第二个事实

这三处里的链接文字 Support Knowledge Base 也是 #808 那四个虚构知识库之一的名字。#808 落地后，content/docs/service/knowledge-base.mdx 与 content/docs/ai-copilot/knowledge-bases.mdx 已明确写着「本应用不 ship 名为 Support Knowledge 的独立知识库」，所以这个链接标签与它指向的页面自相矛盾。修这三句时把标签一并改成页面真实标题（Knowledge Base / 知识库）即可，不必单独处理。

修法建议

按 #865 的既有口径整句重写：把「检索」归给 Customer 360°，把「起草回复」归给邮件撰写，并说明分流本身两件都不做。三语同步。

Related: #808（知识库实体，已落地）、#860 / PR #865（同一族的既有口径）、#887（同为 cases.mdx 但改的是工作流自动化清单，另一处）。