先拆任务，再写需求
把「提升效率」翻译成具体任务：谁在什么时点、拿什么输入、产出什么形态的结果、由谁复核。四要素缺一不可，任务拆不到这一步，需求书写得再厚也无法验收，后期只能靠演示与口头确认推进，项目往往从这里开始失控。
评测集是最小合同
原型阶段就固定一批真实样本与判定口径，作为后续所有版本的对照基准。评测集的来源、标注人与修订记录都要留档，否则模型一换、数据一改，双方对结果究竟变好还是变差永远说不清，每次迭代都要重新争论一遍口径。
原型只回答一件事
原型阶段不必比界面与功能数量，只需回答一个问题：这类任务在当前数据条件下能否做到可用。做不到就换场景，比硬着头皮进入开发便宜得多；做得到也只证明可行性，不证明工程量，更不证明集成难度与真实工期。
集成才是工期大头
真实工期常卡在接口鉴权、字段对齐、老系统缺文档与网络策略上。立项时把要对接的系统列全，逐项确认接口责任人与联调窗口，否则开发做完了也接不进业务流程，只能长期停在演示环境，进度看起来完成了实际没有产出。
上线等于能接管
上线判据不是演示通过，而是有人在用、出错有人接、日志查得到、知识有人更新。缺少接管机制的系统通常三个月内被业务绕开，前期投入沉没，下一年再立项时组织内部的信任成本会更高，预算也更难批。
适用与不适用
适合谁
- 有明确业务问题、愿意先做单场景试点的企业
- 能指定产品负责人与 IT 对接人的项目组
- 数据条件基本具备、愿意投入知识整理的团队
不适合谁
- 只想采购工具、无人承接具体场景的团队
- 要求极短周期全量上线且完全跳过原型验证的项目
典型场景
某装备制造企业的售后团队希望缩短技术答复时间。业务负责人先梳理近半年工单，挑出高频且答案稳定的三类问题做试点；IT 提供备件系统只读接口；交付团队用历史工单搭评测集，先跑原型再进入开发。客服主管担任复核人，每周看接管率与错答类型，两个月后才扩展到经销商渠道。
可执行步骤
- 把业务诉求拆成角色、时点、输入、输出与复核人五要素，写成一页任务卡并由业务负责人签字
- 按样本充足度与错误代价给候选场景排序，同一时间只推一个进入原型，其余列入待办
- 用真实历史数据建立最小评测集，固定判定口径、标注人与修订记录，每次迭代都跑同一批
- 原型跑通后再评估集成工作量，列全待对接接口、权限、联调窗口与对方责任人
- 上线前完成接管流程、日志留存方案与知识更新责任人指派，并在业务侧演练一次
常见坑
- 把「上一个 AI 平台」当成需求，采购完成后才发现没有场景承接，平台闲置到第二年，预算被直接砍掉，团队也跟着背了锅。
- 评测集由供应商单方提供，样本偏简单，上线后真实流量下错误集中暴露，返工成本远高于当初的开发投入。
- 接口文档缺失却按乐观工期排期，联调阶段反复延期，业务方信心耗尽，项目在中途被叫停；返工也难以避免。
- 上线即撤场，知识无人维护，三个月后回答大面积过期，用户回流人工，系统名存实亡；复盘时已无从追溯。
自检与验收清单
- 每个任务卡是否写明输入来源、输出形态与复核人
- 评测集是否来自真实业务并留档，可追溯到样本来源
- 待对接系统是否逐项确认接口责任人与时间窗口
- 上线判据是否包含接管机制、日志留存与回退方案
- 知识更新是否有明确责任人与固定的更新频率
常见问题
一定要先做原型吗？
建议做。原型的作用是以最小成本回答可行性问题，尤其在文档识别、多轮问答这类受数据质量影响较大的场景；跳过原型直接开发，等于把可行性风险留到最贵的阶段去验证，一旦证伪，前面投入的时间与预算基本无法回收。
走完五步大概要多久？
取决于集成数量与数据整理进度。通常诊断与原型合计一到一个半月，开发与试运行按对接系统数量递增；排期建议以决策点为单位对外解释，不要用固定总工期作承诺，否则后续调整会非常被动。
内部没有 AI 团队能做吗？
可以，但需要指定产品负责人与 IT 对接人各一名，分别负责场景取舍、数据提供与验收组织。完全无人承接的项目，即使外部交付质量不错，上线后也难长期维持，通常半年内就退回人工流程。