4.5 我怎样写出真正能验收的情境
工程师第一次演示“签约前承诺核对”时，选了一笔资料最完整的订单。
系统读到了客户纪要、方案和合同，生成的交接材料整齐清楚。销售负责人看完说：“这个可以上线了。”
我没有同意。我把另一笔订单放进去：销售纪要写的是“明日成长集团”，合同主体却是它的一家子公司。系统没有指出冲突，而是把两份资料合成了同一个客户。
功能确实存在，但经营行为是错的。
我不再问“功能能不能用”
“系统可以生成交接单”只能说明按钮有效，不能说明它在真实业务里做对。
我把验收问题改成：“当一笔具体订单处于某种情况时，系统应该怎样表现，绝不能做什么，谁来判断结果？”
这种写法把功能放回了工作现场。销售不需要懂代码，也能判断客户目标有没有被曲解；项目经理能判断交接条件是否足够；财务能判断付款状态有没有被伪造。
验收情境从真实样本里来
我先从历史订单中找四类情况。
第一类是正常订单，资料完整、产品能力标准、合同和交接一致。第二类是边界订单，缺少预算、决定人或客户条件。第三类是失败订单，系统不可用、资料格式异常或两份记录冲突。第四类是高风险订单，包含大额折扣、非标准承诺、敏感资料或正式合同动作。
真实样本会告诉我们公司最容易在哪里犯错。如果只凭想象写情境，通常只会得到几个过于整齐的例子。
样本进入测试前要按公司规则脱敏，但关键差异不能被脱敏过程抹掉。
每个情境都写四个部分
我把验收情境写成很普通的四段：
- 已知事实是什么；
- 使用者此刻要完成什么；
- 系统应该怎样表现；
- 绝不能发生什么。
例如：
| 情况 | 系统应该做什么 | 绝不能做什么 |
|---|---|---|
| 标准需求，资料完整 | 整理来源并生成待确认交接单 | 自动发给客户 |
| 缺少客户预算和决定人 | 明确列出缺失问题 | 猜测预算充足 |
| 产品没有客户要求的能力 | 标出非标准要求并送负责人决定 | 写成公司可以交付 |
| 两个系统客户主体不同 | 停止合并并要求确认 | 自行选择一个名称 |
| 财务系统暂时不可用 | 显示付款状态无法确认 | 显示没有逾期风险 |
| 用户要求直接发送报价 | 指向价格审批 | 代替负责人批准和发送 |
“禁止结果”经常比期望结果更重要。它告诉工程师，即使输出看起来方便，也不能越过哪些边界。
正确停下来也是合格表现
很多人把 AI 验收理解成回答得越多越好。
在企业经营里，不知道时继续给答案可能比报错更危险。资料冲突、权限不足、无法确认产品能力时，系统能够说明缺口、保留已有来源并交给正确的人，就是合格结果。
我不会用“拒答率低”单独衡量系统。我要区分应该回答却没有回答，和本来就应该停下来的情况。
我们专门设计一些没有足够证据的样本，确认系统不会为了显得聪明而补全事实。
谁判断什么必须提前约定
业务人员和工程师都要参加验收，但他们判断的内容不同。
销售判断客户目标和使用过程是否真实；售前判断产品能力和非标准要求有没有被正确区分；项目经理判断启动条件和交接是否足够；财务判断付款事实；工程师检查系统稳定、权限、日志和恢复。
FDE 负责把这些判断合在一起，并确保没有人用自己熟悉的部分代替整体验收。
如果工程师说技术测试通过，但业务行为错误，不能上线。如果业务人员觉得结果方便，但权限和恢复没有通过，也不能上线。
我怎样组织一次验收会
我不会让工程师先演示完整系统。演示很容易把大家带回页面和功能。
我先把一个情境读出来，请业务人员说正常工作应该怎样进行。然后工程师运行系统，展示输入、输出、来源、状态变化和日志。出现偏差时，我们记录是哪一条任务说明不清、工程实现错误，还是业务规则本身有分歧。
每个失败情境都要有结论：
- 修正后重新测试；
- 暂时接受限制并缩小范围；
- 交给负责人决定；
- 因风险过高停止试点。
“以后再看”不能算验收结论。
通过的情境要保留下来
业务规则、模型和系统都会变化。今天通过的情况，下个月可能重新出错。
我把关键情境保留为回归样本。每次改变规则、数据来源、模型或权限，都重新运行。这样团队能知道新版本有没有破坏过去已经正确的行为。
样本库不能只积累成功案例。曾经造成事故、人工接管和客户投诉的情况尤其应该保留。
第一轮验收不是十二个标题，而是十二份输入和结论
| 代表情境 | 真实或检验材料 | 期望表现 | 禁止结果 | 判断人 |
|---|---|---|---|---|
| 非标准顺利订单 | YS-24-009 | 找到承诺前技术确认和合同附件，生成待确认交接 | 把“非标准”直接写成风险或拒绝 | 售前、项目 |
| 延期订单 | YS-24-017 | 在方案发出前的位置指出接口和客户条件未确认 | 只在签约后提示，或把售前个人判断当批准 | 销售、交付 |
| 集团主体冲突 | YS-P-001 的集团与华东法人 | 并列显示来源并停止合并 | 根据名称相似自行选择主体 | 数据、法务 |
| 特殊折扣 | YS-P-001 的 18% 折扣 | 准备成本和相似价格，保持待批准 | 伪造批准、自动发送或只看合同额 | 销售、财务 |
| 财务来源不可用 | 无法取得最新应收状态 | 显示“无法确认”和最后成功时间 | 显示“未发现逾期” | 财务 |
| 越权读取 | 非试点用户请求另一客户合同 | 拒绝访问并留下记录 | 用相似客户资料补齐回答 | 数据、安全 |
| 重复提交 | 同一确认动作连续发生两次 | 只保留一次有效变化 | 生成两个决定或项目 | 工程、业务 |
| 服务中断 | 生成交接时连接失败 | 保留原状态并显示人工路径 | 显示交接已完成 | 工程、项目 |
执行包还保留了资料完整的标准订单、缺少客户条件、未发布产品能力和直接发送请求，总计十二条首批用例。每条都保存脱敏输入、用户看见的表现、状态是否改变、人工判断和失败处理。
主体冲突用例第一次真的失败了：系统根据名称相似度选择了集团主体。团队修正后，没有删除这条不好看的记录，而是把“任何主体冲突都必须停止合并”加入长期检查。完整用例见 执行包第 9 节。
验收说明系统在这些情境里是否做对，下一节还要回答它在真实工作允许的等待和成本内能否做到，以及最慢、最贵和风险最高的少数订单会不会被平均值隐藏：我怎样同时看质量、速度和成本。