把“做一个AI功能”变成可以验收的工程任务，需要先回答：输入是什么，系统被允许执行什么，结果由谁确认，以及出现哪类样本时算通过。与其先列模型、接口和页面数量，不如先选择一段边界清楚的流程，将输入、处理、人工确认与完成依据连接起来。
本文讨论流程范围的设计方法。订单与发货衔接、内容审核作为解释场景；字段、样例及检查表均为构造的设计建议，不是客户内部系统截图或生产运行数据，也不据此宣称效率提升。
一、先用一个业务动词定义范围
“电商自动化”通常太宽，“将一类获准处理的订单转入发货系统，并提供可核对的接收结果”则更容易讨论。这里的完成条件是目标系统接收，不自动包含实际出库、物流签收或售后完成。
内容场景也一样。“自动生成内容”和“完成公开发布”是不同范围。可以先将本期目标约定为：用已确认版本的素材生成待审稿件，由指定人员确认后形成可提交版本。平台审核和最终公开状态需要另行说明。
范围说明可以使用一句话：当【输入条件】满足时，由【授权角色】启动【一段处理】，产出【具体结果】，用【可检查依据】确认本期完成。句子中任何一个位置空白，都容易在开发或验收时出现不同理解。
二、为输入建立可检查的契约
输入契约不只是字段类型，还要说明来源、版本、完整性与使用权限。以一个构造的任务对象为例：
{
"sample_id": "DEMO-ORDER-001",
"source_version": "sample-v1",
"workflow_scope": "handoff_to_shipping_system",
"required_fields_checked": true,
"operator_role": "authorized_operator",
"expected_output": "receiving_record"
}
这里的字段用于解释设计。真实项目应按业务和平台能力调整，不能把这个对象直接当成已经验收的接口定义。
sample_id用于关联同一条验收样例；source_version让输入发生变化时可以回查；workflow_scope限定本期任务；expected_output说明检查哪一种结果。required_fields_checked只记录检查结论，不应替代真实校验逻辑，也不应仅凭客户端传入的布尔值放行操作。
权限同样由服务端或目标系统实际验证。operator_role是描述字段，不是授权凭据。不能因为请求写了“authorized_operator”，就认为调用者拥有权限。
三、把人工确认当成业务步骤
人工确认需要有对象、有版本、有决定。只记录“审核通过”，却不记录通过的是哪一版内容，在素材发生变化后可能无法判断原结论是否仍有效。
一种设计方式是让确认记录关联输入版本、输出版本、审核角色、决定与时间。当输入或输出变化时，重新判断哪些确认需要失效。可以把“生成完成”和“允许执行下一步”分开：前者表示系统已有产物，后者表示本期要求的确认条件已经满足。
内容场景中，审核者可能需要确认商品事实、引用资料及发布范围；订单场景中，需要核对哪些信息则取决于现有业务系统。不要为了追求自动化率删除本来就需要人员判断的业务环节，也不要把审核责任默认交给模型。
四、验收样例要覆盖不满足条件的情况
只给一条完整输入，证明的是这条路径能够运行。更实用的范围讨论应同时包含允许执行和应当阻止执行的样例。以下为可选择的测试集合，并非历史项目测试成绩。
| 构造样例 | 期望行为 | 检查依据 |
|---|---|---|
| 必填信息完整、权限有效 | 执行约定处理 | 产出与样例及输入版本对应 |
| 缺少本期必需字段 | 阻止进入下一步并提示缺项 | 提示内容和未执行记录 |
| 操作者缺少权限 | 拒绝对应动作 | 授权检查结果，目标系统未新增结果 |
| 人工审核未通过 | 保留待修改结果，不执行后续动作 | 审核决定与当前版本关联 |
| 审核后输入版本改变 | 按约定失效规则重新确认 | 当前版本不错误复用旧批准 |
| 用户操作完成 | 能找到结果和后续处理入口 | 使用者完成约定操作检查 |
“未执行记录”本身也不能单独证明没有副作用，必要时需要核对目标系统。检查依据应与本期动作对应，而不是只看按钮、提示或HTTP返回码。
五、如何将验收范围写进交付清单
交付清单可以分成四组。第一组是范围说明：本期起点、终点、依赖系统和不包含的后续环节。第二组是配置与实现：按约定交付必要配置或系统对接，说明部署与权限条件。第三组是操作材料：使用路径、人工确认位置、错误提示与问题反馈方式。第四组是验收记录：实际采用的样例、对应版本、预期与观察结果，以及未完成项。
源码、部署权限、第三方服务费用、后续维护并非天然包含在每个项目中，应分别约定。工程师不应使用一个“已交付”状态抹平这些差异；客户也需要知道交付物怎样用于实际操作。
验收记录可以使用以下格式：
样例：DEMO-ORDER-001
范围：订单转入目标系统；不含实际签收
输入版本：sample-v1
预期：目标系统出现可核对的接收记录
实际观察：执行后填写，不预先写“成功”
检查人及版本：按项目权限记录
结论：通过 / 未通过 / 待核对
“待核对”适用于证据暂时不足的情况，不能为了关闭任务自动变成通过。该模板使用虚构样例标识，不包含客户资料。
六、从一次开发者演示到使用者接手
演示通常由熟悉系统的人执行，而实际交付还涉及其他人员。可以让预定使用者在授权样本上走一遍约定路径，检查他是否知道从哪里开始、何处需要确认、如何找到结果，以及问题交给谁处理。
这里需要分别记录系统执行结果、使用者操作结果、业务负责人对约定范围的确认。没有发生的操作不预先勾选完成；本次通过的范围也不自动扩展到其他版本或其他业务。
流程验收的重点，是把一句宽泛需求拆成可以检查的输入条件、授权动作、确认节点和完成依据。先定义这一段，再决定是否扩展下一段，能够让需求、开发与使用者围绕同一个目标讨论。
作者：温舒。本文为工程设计方法整理，AI辅助编辑；全部字段和测试样例均为设计建议，不包含客户内部资料，也不代表已验证的生产性能或商业效果。
