第一步：把任务说窄
把做个智能客服收窄成按工单描述生成处理建议，供二线工程师选用。任务越窄，评测越可做，结论越可信；范围宽的原型只能得到模糊的乐观判断，也无法界定责任，后续排期与验收都会失真，验收也更清楚。
第二步：评测集先于代码
从真实记录中抽样本，覆盖常见、边界与难例，由业务人员标注可接受答案。没有评测集就开始写代码，最后只能靠演示挑样本，验证失去意义，也无法在模型升级后做对比，团队也无法积累经验，复跑也更方便。
第三步：薄原型不接生产
原型只跑通端到端链路：输入、检索或调用、生成、人工接管、记录。用离线样本即可，不必接生产系统，避免把集成问题混进效果评估，也能降低安全评审的阻力，原型反而会被集成与安全问题拖住，评审也更省力。
第四步：盲测与归因
让真实使用者在不知来源的情况下试用，按错误类型分类记录：事实错误、遗漏、格式不符、越权引用。分类比总准确率更能指导下一步，也便于判断哪类错误可以靠流程兜住，接管规则也更清楚，接管也更顺畅。
第五步：给结论不给情怀
结论只有三种：可进入工程化、需调整后再测、当前条件不具备。每种都要写明依据、剩余风险与下一步所需资源，避免用效果不错收尾，让决策人无从判断，最后往往只能凭印象拍板决定下一步，决策也更有据。
适用与不适用
适合谁
- 已有明确场景但不确定模型能力的团队
- 准备立项开发、需要先给管理层证据的企业
- 采购模型或平台前想做中立评测的单位
不适合谁
- 场景尚未确定、需求仍在讨论的项目
- 期望原型直接上线使用、不做工程化的团队
典型场景
某保险公司的理赔初审场景，团队用四周完成验证：抽取近半年报案记录建立评测集，搭一个只做要点提取与条款匹配的原型，让六名理赔员盲测。结果显示条款匹配可用、金额判断不可用，项目据此缩小到条款提示，避免了一次大规模开发。
可执行步骤
- 把场景收窄成一句可验收的任务描述，并写明不做哪些判断，并写入评测维度
- 从真实记录抽样建评测集，请业务岗标注可接受答案与边界，附判定理由
- 搭薄原型，跑通从输入、检索、生成到人工接管的最小链路，不接生产系统，并留档
- 组织业务岗盲测，按错误类型记录结果，并逐条做归因与留存证据，形成书面记录
- 输出三选一结论，附剩余风险、下一步所需资源与明确责任人，并安排决策会
常见坑
- 先写代码后补评测集，样本被挑成有利结果，验证变成一场演示，结论无法复核，也无法指导开发，也无法复盘。
- 原型直接连生产库却没做脱敏，安全评审阶段被叫停，工期白费，还留下合规隐患，补救成本很高，返工也更贵。
- 只统计总准确率，不分类错误，无法判断问题出在知识、检索还是指令，改进没有方向，只能靠猜着改。
- 把原型当正式系统交付，权限、审计与异常处理缺口被带进生产，整改成本更高，安全评审也过不了。
自检与验收清单
- 任务描述是否可验收，边界与不做项是否清楚，可判定
- 评测集是否覆盖常见、边界与难例，且包含难例，且有难例
- 标注人是否来自业务岗并有交叉复核，有记录，且有记录
- 盲测是否对使用者隐藏来源与模型信息，可复核
- 结论是否写明剩余风险与下一步资源，有清单，且有清单
常见问题
原型需要多少样本？
取决于场景复杂度，通常每类任务数十条到上百条，覆盖常见与难例。样本代表性比数量重要，抽样要说明时间范围与来源，否则结论无法复现，也无法扩大，这一点常被忽略。
原型能用开源模型吗？
可以，且常用于快速验证。但结论要注明模型与版本，换模型需重跑评测，不能把一次结果当成通用结论，也不能据此推算其他场景的效果，否则结论很容易被外推过度，更稳妥一些。
原型失败是不是白花钱？
不是。失败结论能阻止更大投入，并留下评测集与错误类型清单，下一轮换方案时可直接复用。这部分资产往往比一次成功演示更有价值，这一点值得写进最终结项报告，也便于交代。