01 “建设 AI 平台”还不是一个业务目标
一个可以启动的目标应当说明谁在什么场景下，用什么输入完成什么任务。例如，“售前人员根据已审核产品资料，生成带出处的方案初稿，再由负责人确认”，就比“引入大模型赋能销售”更容易设计和验收。
任务应足够窄，能够观察效果，同时又足够完整，包含使用者的输入、系统输出、人工动作和最终结果。把工具试用与业务立项分开，试用可以探索能力，立项必须明确责任。
02 用四个问题筛选首期场景
优先看任务是否高频、答案或结果是否可以验证、资料是否可获得，以及错误是否能够被及时发现。最先做的未必是技术最炫的场景，而应是业务有责任人、输入输出相对稳定、能够形成反馈的任务。
- 任务每周实际发生多少次，耗时主要在哪里？
- 使用者能否明确判断输出是否合格？
- 所需资料有无负责人、版本和访问边界？
- 错误出现后能否由人工接手并纠正？
03 先记录人工基线，再讨论节省多少时间
抽取一组具有代表性的任务，记录查资料、实际处理、等待和复核各自耗时。只统计“生成一段文字用了几秒”，会遗漏人工改写、事实核实与再次沟通的成本。
基线应分难度和任务类型保存。AI 试点之后用相近任务比较中位数与较慢任务的变化，避免把简单问题占比增加误认为整体效率提升。
04 把“质量”拆成可评分的项目
输出流畅不代表任务完成。知识问答要检查来源是否支持结论，材料生成要检查事实与格式，业务查询要检查身份、权限及结果是否正确。评分规则必须由业务人员参与定义。
| 评价维度 | 要验证什么 | 常见误区 |
|---|---|---|
| 正确性 | 结论与事实是否一致 | 只看文字是否通顺 |
| 依据 | 内容能否回到可信来源 | 有引用就默认可靠 |
| 任务完成 | 用户是否达到约定目标 | 把模型返回当作完成 |
| 可接手性 | 人工能否理解并继续处理 | 失败时只显示报错 |
05 成本应按有效完成的任务计算
可以用“模型与基础设施成本 + 检索及外部服务成本 + 人工复核成本”除以有效完成任务数，观察单位任务投入。计价单位与业务单位之间需要换算，单次调用便宜并不一定代表整体使用便宜。
把峰值负载、响应时间和资料更新成本纳入方案。初期未必需要复杂平台，先把任务量、部署边界和运行责任说明白，再决定技术组织方式。
06 设计正确的人工接管方式
对无法回答、资料冲突和需要对外承诺的情况，系统应当交接给适当角色。交接内容包含已确认事实、依据、失败原因和待处理事项，不把模型推断包装为已确认事实。
人工接管不是项目失败，而是完整流程的一部分。衡量转人工是否适当，比单纯压低转人工比例更能避免错误结果进入业务。
07 试点验收分三层进行
第一层用固定样本检查基础质量，第二层在受控使用中观察工作流和权限，第三层跟踪真实业务反馈。每次模型、知识或提示词更新之后，先用相同样本比较，再逐步扩大使用范围。
- 业务验收：任务、质量门槛与人工分工清晰。
- 技术验收：身份、权限、日志、超时和失败处理经过验证。
- 运营验收：有人维护资料、复盘问题并负责版本发布。
08 一张任务价值表足以让第一次讨论更有效
建议每个候选任务填写：业务负责人、使用角色、月任务量、当前耗时、输入来源、期望输出、质量门槛、人工接管、成本范围和试点期限。先比较两三个候选任务，再确定首期。
这张表的作用是把模糊预期转为可以共同验证的假设。一个可解释、可评估、有人负责的小闭环，才有机会成为企业长期使用的能力。