Repository navigation
工单分流页宣称的检索与产出,case_triage 的工具面根本够不着(只有 describe_object + get_record);Customer 360 的能力清单同样超出 skill instructions #847
Description
Activity
[PM 认领 · R19] session_01VHrPAGEgFDoHjphqYG4BMa · 分支
claude/issue-847-copilot-capability-drift· 文件面:content/docs/ai-copilot/sales-copilot*.mdx+service-copilot*.mdx(三语共 6 文件)+ changeset裁定与边界:
- skill 源码为唯一事实来源(幽灵字段 Customer Since 的最后 6 处：ai-copilot 两页把「成为客户的日期」写进 Copilot 会读的客户画像（三语） #840/docs(revenue,sales): 按 contract.hook 与续约 flow 写实 Customer Since 幽灵与提醒收件人 (#824) #841/PR docs(ai-copilot): 按两个 skill 源码写实 Customer 360 与工单分流的客户画像 (#840) #848 同口径):
case-triage.skill.ts/customer-360.skill.ts真读什么、真产出什么,页面就写什么。 - 第一类(case_triage,工具面够不着):
:39/:41/:45/:47/:48五处删除或写实。:48首次回复草稿改为与 skill 第 6 步一致——「交给email_drafting技能」;:45分类一条,instructions 只定优先级,按实况收口。 - 第二类(customer_360,instructions 未枚举但有 query_records):同口径写实为 instructions 实际产出(Account Snapshot / Active Work / Risks & Notes 与第 2-3 步枚举的关联对象),严重度低一档不改变处理方式,但 PR body 里分开陈述两类。
- 不静默删名:读者可能带着「历史工单」「知识库文章」这些承诺找来,写实句要说明当前技能做什么、不做什么(docs(revenue,sales): 按 contract.hook 与续约 flow 写实 Customer Since 幽灵与提醒收件人 (#824) #841 口径)。Support Knowledge 实体是否存在是 文档承诺「HotCRM 内置四个 AI 知识库」，src/ 里一个都不存在（含 Competitive Intelligence 战卡库） #808 的边界,本单只管工具面/instructions 面,不评述知识库本身。
service-copilot.mdx:56-60Customer 360° 段的同型两条(合同/接触点)在本单 scope 内(issue 已点名)。zh 字段名一律按语言包(docs(sales): 让 zh 页的线索状态名、到期日期、直属上级与区块名跟随语言包 (#801) #825 先例)。⚠️ 基线取最新 origin/main(PR docs(ai-copilot): 按两个 skill 源码写实 Customer 360 与工单分流的客户画像 (#840) #848 刚改过同两页的 Customer Since bullet,行号已漂移,逐条重定位);⛔ 不动src/**(给 case_triage 加 query_records 是产品决策,ADR-0109 边界);不加守卫;不动 releases/。
changeset 站内路径用反引号(#797 教训);控制字节自扫改动文件;JSON 报告按标准 schema。
Generated by Claude Code
- skill 源码为唯一事实来源(幽灵字段 Customer Since 的最后 6 处：ai-copilot 两页把「成为客户的日期」写进 Copilot 会读的客户画像（三语） #840/docs(revenue,sales): 按 contract.hook 与续约 flow 写实 Customer Since 幽灵与提醒收件人 (#824) #841/PR docs(ai-copilot): 按两个 skill 源码写实 Customer 360 与工单分流的客户画像 (#840) #848 同口径):
[PM 验收] PR #861 ACCEPT — 已转 ready 并挂 auto-merge(session_01VHrPAGEgFDoHjphqYG4BMa)
复核结论:
- 两类分开陈述且各按其实况处理:第一类(case_triage 工具面够不着)四条移除 + 「分流不做的事」段逐条指路真实去处(历史/文章匹配→Customer 360°,分类→人选的 Case Type 字段,首次回复→Email Drafting 即 skill 第 6 步点名的技能);第二类(customer_360 有 query_records 只是未被要求)明写 This is not a tool ceiling,把「放宽读什么是产品决策」的边界立在页面上——与 ADR-0109 边界一致,未反向动
src/**。 - 比 issue 更重的实况被抓住了:分类选项表本身也是捏造的(真实
crm_case.type是 Question/Problem/Feature Request/Bug,无 Billing、漏 Problem),写实句直接给真选项,避免删一处捏造留另一处。zh 选项名按语言包(咨询/故障/功能需求/缺陷)。 - 前提复核精确:docs(ai-copilot): 按两个 skill 源码写实 Customer 360 与工单分流的客户画像 (#840) #848 一行换一行未致漂移;issue 自身
:44/:45差一行的内部不自洽被指出并如实归因,不算前提失效。 - 与 docs(ai-copilot): 按两个 skill 源码写实 Customer 360 与工单分流的客户画像 (#840) #848 衔接干净:其两行原样保留,优先级写实句从「After tier and contract value」接续,不重复。
- CI 实测 8/8 绿(head a6394a9,Playwright 已落定 success);文件面 6 mdx + changeset 与申报一致。
越界发现处置:#860(同页其余段落 5 处同族漂移,含
:39product 幽灵字段)入队pm:queue——证据硬、去重边界已做(#808/#732/#832/#837 各留说明);与本 PR 同文件族,待 #861 落地后下轮派发。#837 边界处理正确(沿用页面既有「工单」称谓,不做 sweep)。
Generated by Claude Code
- 两类分开陈述且各按其实况处理:第一类(case_triage 工具面够不着)四条移除 + 「分流不做的事」段逐条指路真实去处(历史/文章匹配→Customer 360°,分类→人选的 Case Type 字段,首次回复→Email Drafting 即 skill 第 6 步点名的技能);第二类(customer_360 有 query_records 只是未被要求)明写 This is not a tool ceiling,把「放宽读什么是产品决策」的边界立在页面上——与 ADR-0109 边界一致,未反向动
来源:#840(PR 见下)实施过程中的越界发现。#840 只改两页各一条 bullet(Customer Since 幽灵),本单是读 skill 源码时发现的同页其余 bullet 的同类漂移,不在 #840 的 scope 内,故单独立单。基线
origin/main= 3912845。一、
case_triage的工具面够不着页面宣称的检索与产出(硬证据)src/skills/case-triage.skill.ts:49:只有这两个。
get_record按 id 取单条记录,没有query_records、没有任何检索工具。因此下列content/docs/ai-copilot/service-copilot.mdx的说法在工具面上不可达——不是「instructions 没写」,是没有工具能做到::39- **Historical cases** from the same account and contact.query_records,skill 没有:41- The **Support Knowledge** knowledge base for matching articles.:47- **Top matching KB articles**.:48- A **draft first reply** that acknowledges the issue and links to the KB articles.:45- **Suggested category** (Bug, Question, Feature Request, Billing).其中
:48的冲突,case-triage.skill.ts:46-47的原文是:即 skill 明确把首次回复交出去,页面却把它列为本技能的产出。
真正落地的只有
:44(优先级 + 理由)与:49(指向 Escalate / Close),对应 instructions 的第 2-5 步。zh 两页同位:
service-copilot.zh-Hans.mdx:35,37,40,41,42、service-copilot.zh-Hant.mdx同。二、
customer_360的能力清单超出 instructions(较弱,但同型)src/skills/customer-360.skill.ts第 2-3 步枚举的关联对象只有crm_contact/crm_case/crm_opportunity/crm_knowledge_article,第 4 步产出三段:Account Snapshot · Active Work · Risks & Notes。content/docs/ai-copilot/sales-copilot.mdx的 Customer 360° 列了六条,其中三条不在枚举里::112- **Recent activity** — last call, meeting, email.:114- **Contracts** — active and upcoming renewals.:115- **Marketing engagement** — recent campaigns the customer engaged with.与第一类不同,
customer_360有query_records(:61),所以这三条是「instructions 没让它读」而非「读不到」,严重度低一档。service-copilot.mdx:56-60的 Customer 360° 段落有同样的合同 / 接触点两条。影响
照着这两页写 prompt 的人(以及照着文档理解产品能力的读者)会预期工单分流能拉出历史工单、匹配知识库文章、并给出一份首次回复草稿。实际它只能读当前这一条工单,给一个优先级。第一类是可证伪的能力承诺,不是措辞问题。
与既有单的边界(已逐一去重)
src/里一个都不存在):重叠仅限「Support Knowledge」这个名字。本单问的是 skill 有没有工具去检索,与知识库实体是否存在无关——即便 文档承诺「HotCRM 内置四个 AI 知识库」，src/ 里一个都不存在（含 Competitive Intelligence 战卡库） #808 走「元数据跟文档」把知识库建出来,case_triage仍然没有检索工具。revenue_forecastingwrites nothing #732(Forecasting guide 说 skill 写 forecast 记录,revenue_forecasting什么都不写):同一族(copilot 文档 vs skill 源码),但另一个 skill、另一个页面,不是同一处。关键字 + 文件路径搜索(
ai-copilot、case_triage、customer_360、case-triage)未见其它同类在途单。修法建议
以
src/skills/*.skill.ts为事实来源改文档(与 #840 / #841 同口径):删掉够不着的承诺,或改写为技能真实产出的内容;第一类里:48的首次回复应改成「交给邮件撰写技能」,与 skill 第 6 步一致。⛔ 不建议反向给case_triage加query_records—— 给不给它检索能力是产品决策(ADR-0109 的 skill 边界),不该由文档倒推;若确定要做,另开实现单。Refs #840 #808 #732 #612