第一步：场景库排序
把候选场景按频次、错误代价、数据可得性与责任人清晰度打分，排出前五个。为什么先做这个？因为智能体的价值高度依赖场景选择，选错场景会让团队把时间耗在数据补齐上。排序时把「错误代价高且无复核人」的场景直接排除，边界清楚才不会返工。
第二步：数据与权限底座
把场景需要的制度、话术、案例与系统字段列成清单，标注来源、更新频率与访问权限。怎么做才不失控？先做最小可用集，允许不完美但必须可追溯；权限按岗位而非按人配置，避免离职后权限悬空。这一步通常占总工时四成以上，预算要留足。
第三步：单场景试点
选一个高频低风险场景，约定四周试点期与三项指标：任务完成率、人工接管率、平均处理时长。验收由业务负责人签字，而不是由供应商自评。若指标未达约定，按预案停止并复盘，不要把试点默认延长为正式项目，这也是为什么要设停止条件。
第四步：扩展与采购
试点通过后再谈扩展，顺序是先同部门加场景、再跨部门复制，最后才考虑平台化采购。采购合同要写清数据归属、模型升级回归、服务中断处理与退出时的数据导出。边界在于：没有稳定运行三个月以上的场景，不进入平台采购议程。
适用与不适用
适合谁
- 准备启动首个智能体场景的企业团队
- 已有试点、但缺乏推进节奏的团队
- 需要向管理层提交行动方案的负责人
不适合谁
- 希望一次性采购平台解决所有场景的企业
- 内部尚无明确业务负责人、也无复核安排的组织
典型场景
一家物流企业按清单推进：先用两周整理异常件处理场景的知识与权限，再用四周做试点，指标为一次解决率与接管率。试点期间业务负责人每周复核二十条记录，发现地址识别错误集中在老旧小区，补充规则后指标回升。三个月后才讨论扩展到仓配调度。
可执行步骤
- 用频次、错误代价、数据可得性与责任人清晰度给场景打分，排出前五名
- 整理最小可用的知识集，按岗位而非按人配置权限，并标注更新频率
- 约定四周的试点周期与三项验收指标，同时写明触发停止的书面条件
- 由业务负责人每周抽检二十条记录，按错误类型分类留档，周末复盘
- 达标后再评估同部门与跨部门的扩展，未达标则不进入平台采购议程
常见坑
- 一次列出十几个场景同时开工，数据与复核人力被摊薄，最后每个都停在演示阶段，无一验收。
- 把知识整理完全外包，供应商离场后内部无人更新，三个月后回答大面积过期，返工更贵。
- 试点没有停止条件，效果不佳的场景被默认延续，预算在无声中耗尽，还挤占了新场景的资源。
自检与验收清单
- 场景是否按统一维度打过分，并排出明确优先级
- 知识与权限是否有内部 owner 与更新频率
- 试点是否有书面停止条件，并约定复盘的时点
- 验收是否已由业务方签字，而非由供应商自评
常见问题
第一个场景应该选多大？
选一个部门内、两周能整理完数据、四周能出指标的场景。太大容易拖成半年项目，太小则验证不出集成难度。经验上，涉及两到三个系统接口、日均数十次调用的场景比较合适。
需要先买平台吗？
不需要。首个场景用现成模型加自建知识库即可验证价值，平台采购留到多场景复用出现之后。先买平台容易把预算锁在功能上，反而限制了场景选择的空间。
内部没有 AI 人才怎么办？
先指定一位懂业务、愿意学工具的场景负责人，比急着招算法工程师更关键。工程侧可以用外部支持，但知识与验收标准必须留在内部，否则很难持续运营下去。