第一步：场景立项
立项的输出不是方案文档，而是一页纸：业务问题、现状处理方式、期望输出、验收人、明确不做什么。缺少任何一项，后面都会在范围上反复拉扯，工期与预期同时失控。
第二步：拆任务备数据
把任务拆成判断、生成、复核三段，标出哪些环节必须由人完成；同时整理真实输入样本与知识底稿并标注权限。这一步通常占项目一半时间，压缩它等于压缩成功率。
第三步：试点与评测
用固定评测集跑基线，再逐步调整提示词、检索与流程。指标至少包含任务成功、人工接管与高风险错误漏检三类，连续观察四周再判断是否达标，避免被单次演示误导。
第四步：嵌入与交接
把系统接入真实业务入口，同步修改岗位说明书、操作规范与培训材料，并完成运维交接。只上线不交接的项目，在第一次人员变动后就会失去维护能力。
验收口径：三层证据
验收证据分三层：评测集结果、真实业务日志、复核记录，三者缺一，验收就只是口头确认。涉及签章类成果时，由客户方持证人员复核签认，我方不替代签章，也不承诺审减或中标。
适用与不适用
适合谁
- 已确定要做 AI 但缺少路径的转型团队
- 需要向管理层汇报里程碑的项目负责人
- 希望把试点做成可复制方法的企业
不适合谁
- 期望一步到位重构全流程的企业
- 没有任何真实样本可用的场景
典型场景
某物流企业的单证团队每月处理大量格式不一的托运单据。项目组先立项，明确只做字段抽取与异常提示；再整理三百份历史单据做评测集；试点四周后接管率稳定，才接入业务系统并调整岗位分工。
可执行步骤
- 写一页立项纸，明确问题、输出、验收人与不做什么
- 拆任务三段，整理样本与知识底稿并标注权限
- 建评测集跑基线，记录成功率与接管率
- 试点四周，按错误类型迭代提示词与流程
- 接入业务入口，改岗位说明书并完成运维交接
常见坑
- 立项只写目标不写不做什么，后期范围不断扩张，交付时间与质量同时恶化。
- 用演示样本做评测集，指标虚高，真实业务上线后表现落差很大。
- 跳过岗位说明书修改，员工不清楚复核责任，出错后互相推诿。
- 验收只看一次演示，没有连续日志与复核记录，问题在上线后集中暴露。
自检与验收清单
- 立项纸是否含业务问题与不做什么
- 评测集是否来自真实业务输入
- 是否连续观察四周以上再判断
- 岗位说明书与操作规范是否同步更新
- 运维交接与培训是否完成
常见问题
四步必须严格按顺序走吗？
大体按顺序，但第二步与第三步可以小循环。常见做法是先用少量样本做原型，再回头补样本与知识，关键是不要在评测前直接改造流程。
试点多久算合适？
取决于业务频次。高频场景两周可看出趋势，低频场景需要覆盖完整业务周期，例如月度或季度结算，否则样本不足。
验收由谁签认？
由客户方业务负责人与验收人签认，我方提供评测报告与日志。涉及执业签章的成果，由客户方持证人员复核签认，我方不替代签章。