我见过不少大模型项目卡在同一个问题上：团队很早就被问到“准确率能到多少”，但这时往往还没有代表性样本，也没有统一的好坏标准。无论回答多少，那个数字都缺少依据。
这不是准备不足。真正的问题是，我们还在用传统软件的交付方式管理一个结果带有概率的系统。
交付对象已经变了
传统软件接收明确输入，执行确定规则。需求写清楚以后，开发和测试可以围绕同一份规格判断对错。
大模型不同。同一句输入可能得到不同表达，边界输入也不可能被全部穷举。功能做出来，只说明链路通了，不代表结果已经稳定。
所以 AI 项目的“完成”不能只看功能清单。它至少还要回答：目标用户是谁，在哪些场景使用，什么结果可以接受，出现错误时由谁处理。
管理的是结果不确定性
传统项目常问“能不能按时做完”。AI 项目还要问“做完以后，结果会落在哪个范围”。这两个问题需要不同的管理方式。
我现在更关心三类证据。
第一类是真实样本。没有贴近使用场景的输入，演示效果再好也不能说明产品可用。
第二类是分层标准。格式、字段和引用可以做硬校验；相关性、完整性和语气需要评测规则，也可能需要人工复核。把它们混成一个“准确率”，只会掩盖问题。
第三类是失败路径。模型答错以后，是阻止输出、降级到固定流程，还是交给人确认？错误代价越高，产品越不能只展示成功状态。
把验收放到前面
AI 项目最容易在开发完成后才讨论效果。到了那一步，需求、数据和模型已经绑在一起，任何调整都很贵。
更稳妥的做法，是在立项阶段先做一组小而真实的评测样本，写清每条样本为什么算好，哪些错误不能接受。开发过程中，每次修改都回到同一组标准上比较，而不是凭几次演示判断“这次好像更聪明”。
上线以后也一样。Bad Case（异常样例）不是一张越清越短的 Bug 清单，而是用来发现能力边界和数据缺口的持续输入。团队需要记录它属于哪类问题、由谁处理、是否值得修改系统。
下一道 Gate 看证据
我不再把“模型已经接上”“主要功能已经开发完成”当成交付结论。更有用的问题是：现有证据是否足以进入下一阶段？
如果样本不代表真实场景，就先补样本。如果标准说不清，就先让业务和产品把判断写出来。如果高风险错误没有降级路径，就先不要放量。
大模型项目不是不能交付。只是交付对象变了，验收方式也必须跟着变。