已经在两三个人的小团队里试用了 Amazon Quick，要不要推到全公司，判断依据通常不是「大家觉得还行」，而是能不能拿出两组东西：一组人工能判对错的问题，和连续几周同一口径的记录。建议把扩面当成一次有门槛的放行：先把试点范围和记录口径固定下来，再看信号决定加不加人。
适用场景：小团队已用过 Amazon Quick、准备扩到更多部门。操作动作：先固定 20～30 条高频且答案可核对的问题，按命中、答偏、答不出三类记录，每周归因一次。验证方式：抽查原始对话，对比不同批次的同一口径记录。风险边界：数据与权限短板没补上，或者问题本身连人工都判不出对错时先暂缓扩面；试点结论也不适合直接外推到未被问题集覆盖的部门。
挑一个高频且答案可核对的问题集当试点范围
问题集的挑选标准只有三条：同一批人每周都会问、答案有确定的出处可以对照、不涉及敏感数据。凡是答案要靠业务经验临场拍板的问题，先不要放进试点集，因为对错判不了，后面的记录也就没有比较意义。含客户名单、未发布财务数据、员工个人身份信息的问题同样排除。
建议准备 20～30 条，分成 2～3 批投放，而不是一次全丢进去。这样每一批都有固定的问题清单，前后批次之间可以逐条对照。问题集放在一个受控的文档或表格里，标注期望答案的出处和判定人，方便后面归因时回查。
id,question,answer_source,judge,batch
Q-001,差旅住宿标准里一线城市的上限是多少,财务制度-报销章节,财务-张三,B1
Q-002,新员工入职当天要交哪些材料,HR 入职指引,HR-李四,B1
Q-003,某内部系统账号的申请入口在哪里,IT 服务目录,IT-王五,B2投放前用同一条问题人工问一遍数据源，确认答案确实能查到。查不到的，说明问题本身超出现有数据范围，应该从试点集里剔除或先补数据，而不是留到试点期当「答不出」样本。
定义试点期的三类记录口径：命中、答偏、答不出
三类口径要在开始记录之前定死，中途不新增档位，否则不同批次之间没法比。判定一律以「人是否需要修改才能使用」为准，而不是凭印象打分。
- 命中：回答内容与期望出处一致，人可以直接拿去用，不需要补充。示例：问差旅住宿上限，返回的金额、城市档次和生效条件与制度文档一致。
- 答偏：答到了相关话题，但主体、版本或范围不对，人纠正后才能用。示例：问同一问题，返回的是旧版标准，或者给的是另一个城市的档次。
- 答不出：明确表示没有相关信息，或给出与问题无关的泛泛回答。示例：问内部系统账号的申请入口，回答里没有可用的入口或路径。
谁来记：提问的人当场打标，只给三个选项，避免现场讨论；试点里再指定一名记录人，负责每周把零散记录合并去重。多久汇总一次：建议每周一次；如果一周提问量很少，就按每 20 条汇总一批，保证每个批次样本量接近。判不准的一律先记「答偏」，并在备注里写清争议点。
{"id":"Q-001","batch":"B1","asker":"user-a","verdict":"hit","expected_source":"财务制度-报销章节","note":"可直接使用"}
{"id":"Q-003","batch":"B2","asker":"user-c","verdict":"miss","expected_source":"IT 服务目录","note":"回答未给出申请入口"}收集未命中的问题并归因到数据、权限、提问方式
未命中项不要只统计数量，要分桶。归因只留三类：数据、权限、提问方式。分桶时以「改哪一边能解决」为准，改数据源能解决的归数据，改授权能解决的归权限，改问法或补充上下文才能解决的归提问方式。
归因表示意（每周维护一份，列固定为：归因类别、判定依据、问题原文、责任人、处理动作）：
- 数据①：制度文档只有扫描件，正文检索不到，问题因此答不出。
- 数据②：产品价格表在共享盘已更新，但数据源里仍是上一版，回答引用了旧值。
- 权限①：试点账号不在财务数据源的用户组里，问报销标准时取不到内容。
- 权限②：某业务系统的只读账号没有授权给问答服务，相关问题一律答不出。
- 提问方式①：「上次那个额度是多少」缺少对象和时间范围，无法定位到具体制度。
- 提问方式②：一句话里同时问申请流程和审批人，回答只覆盖了一半，属于答偏。
每周汇总方式：记录人把本周未命中项按三类分桶，每桶列出问题原文、归因结论和责任人，发给对应的数据 owner、系统管理员和业务对接人。归因不明确的不硬塞，单列一栏「待确认」，下周继续跟。归因的最终目的是判断短板在哪一边：如果反复落在权限上，扩面前先解决授权模型，而不是先训练用户怎么提问。
设定扩面的判断点和暂缓条件
「要不要扩」要有可观察的依据，建议至少盯住三条：
- 连续两个汇总周期里，三类记录的分桶结构稳定，未命中项集中在少数几个已识别的原因上，而不是每批都冒出新原因。
- 数据类和权限类的未命中项都有明确的责任人和处理动作，处理完之后用同一批问题复测，能看出回答是否发生变化。
- 试点问题集已经覆盖到拟扩面部门的主要日常场景，且这些问题在拟扩面部门同样能由人核对对错。
出现下面任一情况，先暂缓：一个周期内大量答不出且归因说不清；需要放开的权限涉及跨部门数据，授权方案要重新设计；试点集里的问题本身有争议，连人工判定都拿不准。
谁来决定：由业务负责人牵头，IT 或知识库管理员和数据源 owner 一起确认，不要只由发起试点的个人拍板。多久复盘一次：建议每两周复盘一次，扩面按批次放开，先加一个组、再加一个部门，每一批都保留同一套问题做对照。
扩面前建议准备好的清单：数据侧——文档格式可解析、版本唯一、有明确的更新入口和更新人；权限侧——列出用户组与数据源的授权对照表，按最小可用范围授权；记录侧——问题集模板、三类记录表、归因表和记录人名单都已就位。这三项没准备好，扩面只会把同一批问题放大到更多人身上。