试点要验证哪一个决策
试点的作用不是证明AI可以对话，而是回答企业是否值得继续投入。可以验证知识检索是否足够准确、接口能否支持任务，或业务人员是否愿意使用，但不宜同时承诺解决全部问题。
例如，选择“帮助售后人员查找指定产品的故障处理依据”，比“建立全自动售后中心”更容易定义数据、用户和结果。前者仍然可以覆盖问题输入、资料检索、人工采用及反馈的完整闭环。
优先选择边界清楚的任务
理想场景具有可获得的资料、稳定的权威答案、愿意参与的负责人和可接受的失败后果。发生频率要足以在试运行期收集观察，但不能仅因为频率高就忽略资料与权限问题。
只选最简单问题容易高估效果，直接选择付款或生产控制等高风险动作又会使试点负担过大。可以先以只读、建议或草稿形式验证核心能力，再逐步开放执行权限。
试点范围要同时圈定五项
明确用户群、知识范围、入口、工具和时间窗口。列出排除项，例如暂不支持扫描件、跨部门资料或自动退款，并说明排除原因与未来扩展条件。
范围还应包括失败处理：检索不到资料时怎样提示、问题转给谁、接口异常是否允许重试。一个只包含成功页面的原型，无法证明任务在真实业务条件下可以形成闭环。
样本和用户如何安排
样本应包含常见、复杂、无答案、版本冲突和权限边界问题，并与开发调试样本适当分开。由业务人员确认评分依据，避免团队只按自己设计的问题自评。
试用人员既要有熟悉流程的骨干，也可以包含新员工。记录是否采用答案、修改了什么以及没有使用的原因。单纯统计访问次数，不能说明系统是否帮助完成了工作。
让试点既完整又足够小
可以把首期限定为一个产品系列的售后资料查询，参与人员仍用现有渠道服务客户。助手提供引用与建议，坐席记录采纳或修改原因，无法处理时转原流程。这个范围没有自动退款，却能检验知识、使用体验与复核工作。如果连有效资料都难以提供，应先整理知识，而不是扩大试点用户来获取更好看的使用量。
- 用户是否愿意提交具体反馈。
- 样本是否覆盖不擅长的情形。
- 试点是否记录未采用的结果。
- 扩展条件是否由证据而非时间决定。
结束时输出可复核结论
比较原流程与试点流程的质量、净耗时、人工介入与运行成本，并列出未解决问题。用“扩大范围、继续修正、改变路线或停止投入”形成明确建议，说明对应证据。
扩展决策应考虑新增部门和资料是否仍满足原假设。一个部门试点成功，不代表权限更复杂、数据质量更差的全公司场景可以直接复制；每次扩展都应重新检查关键条件。