Usecase Factory · AI 测试工作流设计

模型生成了一个可以运行的负向用例：请求失败，测试也通过。但回看前置发现，账户根本没有创建，测试提前撞上“账户不存在”，没有到达原本要验证的余额不足分支。语法检查和运行通过都无法发现这类测试意图偏移。

Usecase Factory 的设计从这个问题出发，把测试意图、规则来源、可执行能力和观察结果分别保存。我结合已有测试开发流程提出方向，整理重构方案与 MVP 计划，并通过设计评审明确生成、审核、恢复和验收要求。目前交付物是设计与评审材料，完整执行实现尚未验证。

一个场景需要保存哪些关系

以下是独立编写的库存例子，用来说明设计要求。需求规定库存不足时拒绝且不改变资源；测试剧本要把这条规则连接到具体输入、调用能力与观察手段。

对象	示例内容	为什么要单独保存
规则	R2：不足时拒绝，不扣库存、不创建记录	提供预期依据，不能由运行结果反推
剧本	C02：库存 1，申请 2，其他条件合法	说明如何到达目标分支
能力绑定	构造商品、预占、查库存、按请求编号查记录	判断当前环境能执行和观察什么
生成产物	当前剧本版本对应的测试文件及摘要	检查代码是否落后于审核
观察结果	返回码、库存值、记录及执行日志	为差异诊断提供事实

沿着 C02 往下执行，假如当前 API 只能查库存，不能查预占记录，那么响应和库存两项可以验证，最后一项仍然没有观察手段。这时应把缺口留在场景中，等待补齐能力；删掉断言虽然能让脚本跑通，却改变了原本要验证的规则。

将阻塞限制在受影响的场景

假设同一批任务还包含正常预占等独立场景，C02 缺少查询能力，不必让已经完成的其他审核和执行结果一起作废。需要暂停的是依赖这项能力的部分。为以后恢复，阻塞记录至少要写清场景、缺少的能力、受影响断言和恢复条件：

{
  "case_id": "C02",
  "case_version": 3,
  "status": "blocked",
  "missing_capability": "reservation.lookup_by_request_id",
  "affected_assertion": "no_reservation_created",
  "resume_when": "能力已登记，返回语义经审核，场景重新绑定"
}

这是一份设计示例，不是现成平台的接口格式。恢复需要沿依赖关系检查：补入查询能力后，重做 C02 的绑定，重新审核受影响剧本并生成代码；其他没有依赖变化的场景可以保留。若变的是规则 R2，就需要找出全部引用 R2 的场景，不能只重跑刚才失败的一条。

人工修改同样是一项输入。保存修改前产物、修改差异和原因，再建立新版本。直接覆盖模型输出会丢掉诊断依据，也无法区分“模型本来就做对”与“人工修复后可交付”。

运行失败先分流，不能自动改预期

假设 C02 返回库存不足，但查询发现了一条预占记录。诊断应同时呈现规则、剧本、实际请求和观察结果。接下来至少有三种可能：规则文档遗漏了允许保留失败记录的约定；查询能力把审计记录误当作预占记录；被测实现违反了规则。

这三种解释对应不同修改。第一种需要确认业务契约，第二种需要修正能力语义，第三种应保留失败并修复业务。将断言直接改成“记录可以存在”，会绕过需要业务判断的步骤。

因此，设计把生成、发布、平台同步与执行分开记录。文件已生成不代表平台已接收；平台已接收不代表执行结束；执行结束也不代表结果完整且满足业务预期。失败重试应从实际中断位置恢复。

MVP 怎样验收

先选同一组规则和能力资料，分别交给单次 Prompt 和分阶段流程；固定可用工具、预算及审核标准。保存原始产物与人工修改，比较有效场景、缺陷检出、人工复核时间和恢复后的重复工作。

三个故障尤其适合先做：能力缺失只阻塞相关场景；规则变化使相关审核失效；报告缺少一个结果时不能完成整批验收。正常路径跑通后再扩大业务范围，避免先实现平台同步，却没有解决预期来源和结果判定。

ai-test-workflow已经公开了单商品库存的分阶段产物、审核关联、模板生成与执行报告，可作为这一方向的练习起点。完整教程说明其命令与格式。它尚不等于 Usecase Factory 的通用平台实现：这里设计的跨场景依赖恢复、平台发布和同步，需要独立实现与验证。