docs(ai-copilot): 按 case_triage 与 customer_360 源码写实两页能力清单 (#847)

[yinlianghui]

Fixes #847

以 src/skills/*.skill.ts 为唯一事实来源（#840 / #841 / PR #848 同口径），把
content/docs/ai-copilot/ 两页的能力清单改回技能真实的工具面与 instructions。三语共 6 文件

• 1 个 changeset，src/** 一行未动。

一、前提复核（重定位后的行号表）

issue 基线是 3912845b，当前 origin/main 是 9d2c787a（PR #848 / #849 / #854 已合）。
逐条重定位结论：issue 的每一处在最新 main 上都仍然成立，premise_still_valid: true。

git diff 3912845b..origin/main -- content/docs/ai-copilot/ 显示 #848 对这两页各只做了
一行换一行 的原地替换（Customer Since 幽灵那条 bullet），没有增删行，因此行号整体没有漂移：

issue 引用	最新 main 实际行号	该行内容	复核结论
service:39	:39 未动	- **Historical cases** from the same account and contact.	成立
service:41	:41 未动	- The **Support Knowledge** knowledge base for matching articles.	成立
service:45（分类）	:46	- **Suggested category** (Bug, Question, Feature Request, Billing).	成立；issue 正文此处行号自身差一行（它把 :44 记作优先级、:45 记作分类，实际是 :45 / :46，且它列的 :47 / :48 / :49 又是对的——是 issue 内部不自洽，不是 #848 造成的漂移）
service:47	:47 未动	- **Top matching KB articles**.	成立
service:48	:48 未动	- A **draft first reply** …	成立
service:56-60	:57-63 段落	Customer 360° 段（合同状态 / 最近接触点）	成立
sales:112/:114/:115	未动	Recent activity / Contracts / Marketing engagement	成立

源码侧复核（都在最新 main 上重读过）：
case-triage.skill.ts:49 仍是 tools: [ 'describe_object', 'get_record' ]；
case-triage.skill.ts:46-47 的第 6 步仍写着把面向客户的回复交给 email_drafting；
customer-360.skill.ts:61 仍带 query_records + aggregate_data，第 2-3 步枚举的关联对象
仍是 crm_contact / crm_case / crm_opportunity / crm_knowledge_article，第 4 步产出
仍是 Account Snapshot · Active Work · Risks & Notes 三段。

一处比 issue 更重的实况：issue 说 :46 的分类「instructions 从未指派」，这没错；额外查到
它连选项表都是错的——src/objects/case.object.ts 的 type 字段实际只有
Question / Problem / Feature Request / Bug，没有 Billing，而 Problem 又没被列出。写实句因此
直接给出真实选项，避免删掉一处捏造又留下另一处。

二、第一类：case_triage 工具面够不着（硬缺陷）

describe_object + get_record 两个工具，get_record 按 id 取单条，没有任何检索工具，因此
「历史工单」「知识库文章匹配」「最匹配的 KB 文章」不是 instructions 漏写，是没有工具能做到；
「首次回复草稿」与 skill 自己的第 6 步直接矛盾。改动：

• :39 / :41（分析清单）与 :47 / :48（返回清单）四条从清单里移除；
• :45 优先级一条按 instructions 第 2-3 步写实（一条理由 + 引用工单 ID 与字段值 + 完整评判顺序）；
• :49 指向 Escalate / Close 一条保留，并补上 skill 真会给的 reason / resolution 可粘贴文本；
• :46 分类一条按实况收口。

不静默删名（#841 口径）：新增一段 **What triage does not do.**，逐条说明被删掉的三项能力
各自真正的去处——历史与文章匹配去问 Customer 360°（它才带 query_records，读 crm_case
与 crm_knowledge_article）；分类是人在工单上选的 Case Type 字段；首次回复由
Email Drafting 接手（就是 skill 第 6 步点名的那个技能，正好是同页第 3 节）。

三、第二类：customer_360 instructions 未枚举（低一档）

这个技能有 query_records，所以 sales 页的 Recent activity / Contracts / Marketing
engagement 与 service 页的合同状态 / 最近接触点是「instructions 没让它读」而非「读不到」。
PR 里刻意把这一档与第一类分开表述：写实段明确写出 This is not a tool ceiling，并点名它
本可够到 crm_contract / crm_campaign / crm_event / crm_task，只是没有被要求去读，
而放宽一个技能读什么是产品决策而非文档决策（ADR-0109 的 skill 边界，见下方「未动的东西」）。

两处 Customer 360° 段按 instructions 第 2-4 步重写为真实枚举与产出：
crm_contact（主要联系人优先）、crm_case（is_closed 为 false、最新优先）、crm_opportunity
（阶段 / 金额 / 预计成交日期）、已发布的 crm_knowledge_article（按工单的分类或标签匹配）；
总数取自 aggregate_data 而非逐行相加；产出固定三段 Account Snapshot · Active Work ·
Risks & Notes，内联引用记录 ID，风险必须点名记录与信号。

顺带写实的同段一条（同属第二类）：service 页原本写「所有过往工单（未结和已结）」，
instructions 只让它查 is_closed 为 false 的工单，已结部分是 aggregate_data 的按状态计数——
改后仍然支撑该段结尾「本季度第 3 次」那句话，只是把它挂到真正数得出来的那个工具上。

四、与 #848 措辞的衔接

#848 今晚刚把两页各一条 bullet 改成 Customer Since 幽灵的写实句，本 PR 未改动这两行
（sales:110 / service:38，diff 里可见它们不在改动块内），并让新句子与它们读起来连贯：

• service 页 :38（docs(ai-copilot): 按两个 skill 源码写实 Customer 360 与工单分流的客户画像 (#840) #848）说「客户分层 与 合同金额 是分流评判标准里排在最前面的权重」，
  本 PR 的优先级写实句就从 After tier and contract value 接着往下列剩余三项权重，不重复它
  已经说过的前两项；
• sales 页 :110（docs(ai-copilot): 按两个 skill 源码写实 Customer 360 与工单分流的客户画像 (#840) #848）的 Relationship snapshot 保持原样作为 Customer 360° 清单第一条，
  本 PR 只在其后接续真实枚举，两句共同构成「快照 + 关联对象」的完整一段。

五、未动的东西（边界）

• ⛔ src/** 一行未改。给 case_triage 加 query_records、或给 customer_360 的 instructions
  加合同 / 营销活动，都是产品决策（ADR-0109 的 skill 边界），不由文档倒推；本 PR 只让文档停止
  承诺技能还没有的能力。
• Support Knowledge 知识库实体是否存在不归本单（文档承诺「HotCRM 内置四个 AI 知识库」，src/ 里一个都不存在（含 Competitive Intelligence 战卡库） #808 的边界）。写实句只谈「哪个 skill 有
  什么工具、instructions 让它做什么」，对知识库本身不作评述；引用的 crm_knowledge_article
  是 src/objects/knowledge_article.object.ts 里真实存在的普通对象。
• 未加任何守卫 / 测试（按派发裁定），未动 content/docs/releases/，未改任何
  @objectstack/* 依赖版本（锁 17.0.0-rc.2）。

六、本页仍有残留，已另立单 #860（不在本 PR 修）

实施中发现同页 其余段落 还有四处同类问题，超出 #847 的 scope，按 Prime Directive #10 立为
新单而非夹带修复：service-copilot.mdx:39 的「工单中引用的产品」是幽灵字段
（crm_case 全字段里没有任何 product 字段，也没有指向 crm_product 的 lookup）；三段 tips
（:92 / :96 / :101 改前编号）仍在复述「分流会匹配知识库文章」；另有 :79 属于第三个
skill（email_drafting）的同族漂移。已对 #847 / #808 / #732 / #832 / #837 逐一去重。

七、验证输出

全部在共享锁 flock -w 7200 /tmp/os-heavy-verify.lock 下、NODE_OPTIONS=--max-old-space-size=4096 执行：

命令	退出码	关键行
pnpm validate	0	✓ Validation passed (1303ms) · Data: 17 Objects 344 Fields
pnpm typecheck	0	tsc --noEmit，无输出
pnpm build	0	✓ Build complete (1492ms) · Artifact: dist/objectstack.json (1921.3 KB)
pnpm test -- --maxWorkers=2	0	Test Files 66 passed (66) · Tests 1587 passed | 1 skipped (1588)
pnpm lint	0	13 warning(s), 14 suggestion(s) (1225ms)
pnpm hygiene	0	Source hygiene — 245 files under src, test, e2e, scripts; the control-byte scan adds 388 under content, .changeset · ✓ source hygiene clean

validate / build / lint 的 warning 与 suggestion 全部是 main 上既有的（审批节点可能空审批人、
crm_campaign_member 字段组被高亮条遮蔽、行项目建议改 master_detail 等），与本 PR 无关。
test 输出里 ✗ source hygiene failed: … 是 source-hygiene-scan-surface.test.ts 元测试
故意打到 stderr 的预期文本，同一批次里 66 个测试文件全绿。

控制字节自扫（改动的 6 个 mdx + changeset，转义写法，非裸字节）：

grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f]' <六个 mdx> .changeset/copilot-capability-drift.md
→ exit=1（零命中）

pnpm hygiene 的控制字节扫描面自 #818 / PR #835 起已覆盖 content/ 与 .changeset/，
上表里那 388 个文件即是，本次改动全部落在该扫描面内。

changeset：.changeset/copilot-capability-drift.md，'hotcrm': patch，站内路径一律反引号、
无 markdown 链接（#797 教训）。

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Aug 6, 2026 12:20am