作者回复: 数字型的验收标准怎么定，可能是 AI 项目里最容易产生争执的地方。我说一下个人理解。 首先，第 11 讲说的“开发前先定义好”，定义的是口径，而不是一个具体的数字。什么算答对、什么算答错、什么话绝对不能说，这些在开工前是可以和客户一起写下来的；但准确率最终能做到多少，其实是跑出来的，不是谈出来的。在没有评估集、没有 baseline 之前就承诺一个 90%，如你所说，这个数字大概率就是拍脑袋。所以我的建议是，立项阶段把口径谈清楚，把评估集怎么建、三类评估集各自按什么规则设门槛谈清楚，具体数字等第一版系统在第一版评估集上跑出 baseline 之后再定。这和第 6 讲在业务指标上先建基线是一个道理：效果讲的是增量，没有起点就没法谈终点。 其次，评估集不断扩充、分数跟着变化，这个现象本身是正常的，甚至是好事，说明评估集在变得更准。这里要区分两件事：补用例和改期望值。补了新用例之后分数下降，并不是系统退步，而是评估集覆盖了更多真实场景；真正要慎重的是把期望值改低。所以在跟客户谈的时候，可以把评估集当成一个有版本的东西来管理，每一个分数都对应某一版评估集，新补进来的用例单独看通过率，而不是和老用例混在一起算一个总分。这样客户看到的是两条线：老场景有没有守住，新场景覆盖到了哪里，而不会是一个忽高忽低的总分。 至于约定了 90% 后来发现做不到，我觉得第一步可以先不急着优化，先把做不到的那部分 case 拿出来，和客户一起看它们到底是什么。通常会有几种情况：有些 case 本来就超出了当初定义的场景范围；有些 case 的期望值本身就有争议，不同的业务人员给的答案都不一样；还有一些是模型确实做不到。这三种情况的处理方式不太一样。前两种是口径问题，业务口径由客户说了算，拿着具体的 case 去谈，客户通常是讲道理的；最后一种才是能力问题，这时候要谈的就不是能不能到 90%，而是剩下的那部分怎么处理，是转人工、是降低自动化的程度，还是缩小场景的范围。第 12 讲讲的放权节奏，其实就是在处理这件事。 我想再补充一个维度。验收门槛定多高，可能不应该由“客户能接受多少”倒推，而应该由“错一次的代价有多大”倒推。同样是 90%，如果剩下的 10% 错了只是多花几分钟人工核对，那这个系统已经很有价值了；如果错一次是一笔错误的资金划转，那 99% 也不够。把错误的代价算清楚，再决定门槛定在哪、剩下的部分靠什么机制来承接，这个讨论往往比纠结数字本身更有效，也更容易和客户达成一致。 最后，按一次签字谈验收还是按曲线谈验收，这背后还有商务上的考虑，第 15 讲讨论定价的时候会专门展开，欢迎到时候再来交流。