第一步：盘点与选题
把岗位任务拆成可判断、可生成、可执行的单元，按发生频次、错误代价、接口可用性三项打分。频次低或错误不可回滚的任务先不做，避免用试点去验证一个本来就不该做的场景。如何排序，取决于这三项的综合得分。
第二步：原型打通工具
先接一到两个只读接口，让 Agent 完成查询、比对与草稿，写操作留到评测通过之后。原型阶段的目标是暴露接口与数据问题，而不是追求功能完整。为什么先做只读？因为范围越小结论来得越快，写权限的风险可以留到评测之后再评估。
第三步：评测与接管
用历史任务做固定样本集，记录任务成功率、人工接管率与失败类型分布。同时把接管入口、责任人与响应时限做进流程。为什么这一步不能省？因为系统一旦卡住而无人接手，业务只会绕开它走回人工。
第四步：扩面与交接
扩面前先补齐版本管理、日志审计与告警，明确提示词与知识的更新责任人。交接不清的系统在上线三个月后准确率必然下滑，扩面只会放大这个后果。如何判断交接完成？看提示词、知识目录、评测集与值班安排这四项是否都有明确的接手人。
适用与不适用
适合谁
- 有稳定业务系统与可调用接口的中大型企业
- 愿意先做单场景试点并指定验收人的团队
- 需要把多步人工流程压缩的业务部门
不适合谁
- 接口与账号体系尚未打通、只能人工导表的组织
- 要求完全无人值守、后果不可逆的业务流程
典型场景
某物流企业的客服团队把异常件查询与回复草稿作为试点：先盘点近半年工单，只接查询接口，Agent 输出处理建议与回复草稿，客服确认后发送。六周后用两百条历史工单回放评测，接管率与错误类型清晰之后，才扩展到改约与理赔引导两个环节。
可执行步骤
- 先列出三类候选任务清单，按发生频次、错误代价与接口条件打分排序
- 先只接一到两个只读接口，把范围严格限定在查询、比对与草稿输出
- 用历史任务建立固定样本集，把失败类型拆成可统计的几类再定口径
- 设定接管入口、责任人与响应时限，并在上线前完整做一次接管演练
- 等日志审计、版本管理与告警全部补齐之后，再评估是否值得扩大范围
常见坑
- 跳过任务盘点直接采购平台，场景迟迟定不下来，平台长期闲置，团队对 AI 的耐心也被消耗掉。
- 原型阶段就接入写接口，一次误操作污染生产数据，项目被迫中止，修复周期远超试点收益。
- 没有固定的样本集，验收很容易开成一场演示会，会上所有人都说效果好，真正上线却没人敢用。
- 交接只交代码与部署文档，不交提示词、知识目录与评测集，接手团队根本无法继续迭代。
自检与验收清单
- 四个阶段是否都各有可验收的交付物与责任人
- 试点范围是否限定在一个岗位、一类任务之内
- 样本集与失败分类是否已固化，能否复现同一结果
- 接管人、兜底流程与响应时限是否都明确到人
- 交接文档是否包含提示词、知识目录与评测集
常见问题
走完四步要多久？
单场景试点通常四到八周，取决于接口打通与样本准备。若接口需要改造或权限审批排期较长，时间会明显拉长，应在立项时就把这段等待排进计划，不要留到试点中期才发现。
能不能跳过原型直接开发？
不建议。原型的作用是尽早暴露接口、权限与数据质量问题，此时改动成本最低。跳过它，问题会在开发后期集中出现，修改代价成倍增加，还容易把技术问题误判成模型能力问题。
验收标准由谁定？
由业务负责人定任务成功率与可接受的错误类型，技术团队定测量方法，双方在试点前书面确认。只由供应商单方设定标准，验收就会失去约束力，后续一旦出现争议也没有依据。