从零到一搭建 AI 测试工作流：从需求到可执行测试

假设要让模型测试“库存不足时拒绝请求”。它很快写好了脚本，也断言返回了错误码。但如果商品根本没有创建，请求可能在检查商品时就被拒绝；即使测到了库存不足，只检查错误码，也可能漏掉失败后仍扣库存的问题。生成可运行代码只是开始，还要确认它确实测到了目标规则。

我在 Python 测试开发中使用 AI 时，围绕这些问题组织了一条工作流：读取需求与业务接口文档，学习存量脚本以及业务领域模型和规则，生成测试剧本，再在契约测试框架的骨架中填充前置构造、业务调用和结果校验。规约整理是其中一部分。XAT 则承接已有测试工程经验：从内部契约测试框架中移除公司特定协议、数据形式、鉴权和票据等依赖，提炼可以迁移的测试框架。

本文配套的 ai-test-workflow 将这条方法整理成可以从本机开始练习的工程。库存业务、HTTP 服务、校验器和故障示例是为教程编写的独立实现；工作实践的背景见 AI 测试交付。

下面会先运行一组参考测试，确认本机环境和缺陷检查能够工作，再让模型从资料生成自己的规则与剧本。完成这些步骤后，就有了一套可以重复运行的流程，以及接入公司现有框架的修改清单。业务人员审核规则和预期，测试人员准备资料、生成剧本并运行测试；接入框架时，还需要能维护 Python 和测试环境的工程师参与。

1. 先确定试点范围和验收条件

第一次接入选择一个规则明确、前置可构造、结果可查询的操作。例如创建订单、库存预占、额度校验。先处理同步流程，再扩展异步任务和跨系统操作。

本例测试“单商品库存预占”，假设商品已经存在，接口同步完成处理。需求规定：

1. 数量必须为正整数。零、负数、小数、布尔值和字符串都应拒绝，不改变库存和预占记录。
2. 库存足够时成功，扣减对应数量，创建一条预占记录；库存不足时拒绝，不改变这两类资源。
3. 同一请求编号、商品和数量重复提交，返回同一预占结果，不重复扣减。
4. 同一请求编号换用不同商品或数量，返回幂等冲突，保留原处理结果。

本轮示例验证数量、库存边界、同参数重复提交，以及改变数量的幂等冲突；不验证并发争抢、过期释放、跨仓库、权限及商品不存在。第 4 条中的“改变商品”也尚未被当前剧本格式表达，试点审核时应明确记录这个未覆盖分支。规则被某条用例引用，并不等于规则的全部分支都测过了。

这一轮的验收条件是：规则有来源，剧本的前置与预期经过审核，生成文件能被发现和执行，完整结果与当前输入版本对应，失败与阻塞能够被保留。模型一次生成多少文件，不作为验收条件。

2. 下载工程并理解各部分的职责

配套工程已发布到 captainamari/ai-test-workflow。需要 Git 和 Python 3.10 或以上版本；Python 工程仅使用标准库，不需要数据库。下面先运行固定的参考产物，不调用模型，也不需要模型 API Key；第 6 节开始使用你已有的编程助手或聊天模型。

下面的命令固定到本篇验证过的提交，避免后续更新改变教程中的输入格式与运行行为。

git clone https://github.com/captainamari/ai-test-workflow.git
cd ai-test-workflow
git checkout --detach 7e706ee0e70d645715bbdd59a8f1385eb3c5c43f
python workflow.py demo
python -m unittest test_workflow -v

教程对应 提交 7e706ee。git checkout --detach 将工作目录固定到该提交；需要自行修改并提交时，可以再创建自己的分支。仓库后续更新时，先验证新版工程，再更新文章引用的提交。

获取工程后，在编程助手中打开仓库目录，按第 6 节开始规则提取，或按第 10 节读取 skills/ai-test-workflow/SKILL.md。克隆工程本身不会自动安装 Skill。没有 Git 时，也可下载 该提交的源码 ZIP，解压后进入包含 workflow.py 的目录。

仓库的主要文件如下：

ai-test-workflow/
├── workflow.py                  # 校验、审核关联、生成、执行、报告
├── harness.py                   # 测试基类和业务 API 适配层
├── demo_service.py              # 本地库存服务与故障开关
├── test_workflow.py             # 工作流自身的回归测试
├── examples/
│   ├── inputs/                  # 需求、契约、领域模型、能力和存量脚本
│   └── reference/               # 教学用参考规约与剧本
└── skills/ai-test-workflow/
    ├── SKILL.md
    └── references/
        ├── formats.md
        ├── 01-spec.md
        ├── 02-cases.md
        ├── 03-diagnose.md
        └── 04-adapt.md

沿着库存不足这个场景，模型先找出“拒绝后资源不变”的规则，再设计初始库存与申请数量。Python 程序检查剧本的结构和引用，把它填进固定骨架，执行并记录结果。规则解释是否正确、场景是否覆盖需要验证的分支，仍由业务与测试人员确认。三者在这里承担不同工作。

测试发现、资源清理和报告规则通常不随每条库存场景变化。骨架稳定后，可以让这些部分由程序重复完成，减少每次生成时需要重新审阅的内容。本例让模型输出结构化剧本，由程序填入已维护的 Python 骨架。接入已有框架时，也可以由模型根据剧本填写业务代码，但应限定在经过审核的调用方式和模板内，并额外做代码审阅。

3. 工作流及其停止位置

下面的图展示每个阶段交付什么，以及何时停止推进。规则冲突回到输入资料处理；缺少能力的场景保留为 blocked；执行失败先保存证据，再定位需要修复的阶段。

宽图可横向滚动。查看原图查看原图

如果结果有问题，需要知道它最早在哪个阶段偏离了要求。因此，每个阶段都留下一份文件，重新生成时也有明确的起点：

阶段	输入	输出	继续执行的条件
准备资料	需求、接口、领域知识、样本代码	inputs/、input-manifest.json	范围和资料版本明确
提取规则	本次输入快照	spec.json	来源存在，疑问已处理，业务审核通过
设计剧本	已审核规则、接口和能力清单	cases.json	前置、动作、观察和预期经过测试审核
生成代码	已审核剧本、固定模板	generated/、render.json	当前输入与审核版本匹配
执行和诊断	生成文件、测试环境	reports/*.json	实际执行完整，通过数和阻塞数分别记录

审核记录保存输入和产物的摘要。资料或剧本发生改变后，旧审核不能直接用于新版。它能发现“审核的是上一版，执行的是下一版”这类错误，但不能证明审核者身份，也不能证明审核质量。公司环境应将它与现有代码评审和 CI 权限关联。

4. 先跑通参考示例，确认执行环境

在工程根目录运行：

python workflow.py demo
python -m unittest test_workflow -v

第一条命令启动只监听本机的 HTTP 服务，运行 10 条参考测试，然后分别启用 3 种缺陷。正常实现应得到 passed；缺陷版本应得到 failed，且失败原因是业务断言。整个 demo 返回码为 0，表示这个对照成立。

运行版本	刻意改变的行为	负责发现它的观察
正常实现	无	10 条用例应全部通过
reject-writes	库存不足时仍扣减库存	拒绝后的库存不应改变
double-reserve	重复请求再次扣减并创建记录	库存、记录数、结果编号应保持幂等
missing-record	返回成功并扣减库存，却不保存记录	成功后应存在一条预占记录

运行需要宿主机允许 Python 监听和连接 127.0.0.1。如果出现 socket 权限错误，先解决执行环境问题，不将它统计为发现了业务缺陷。服务数据只保存在内存中，退出后释放。

本篇对应的提交已在 Windows、Python 3.12 环境验证：正常服务 10 条用例全部通过；三种故障依次触发 1、1、4 条断言失败，均无执行错误。test_workflow.py 的 10 项工作流检查也通过。Python 3.10 是按所用标准库 API 声明的最低版本，本次未实测其他 Python 版本或操作系统。

这一步使用 examples/reference 中手写的参考产物，没有调用模型。自动生成的审核记录标有 reference-example-not-human-review。它用于验证执行器、断言和故障示例，不能用来衡量 AI 生成质量。

下一步再进行真实的模型生成。为避免答案泄漏，不要在生成前把参考剧本或被测服务实现交给模型。

5. 准备模型真正需要的五类资料

建立一个独立运行目录：

python workflow.py init runs/pilot

命令复制教学输入。第一次练习可以原样使用；换成公司业务时，先替换资料，然后执行 python workflow.py snapshot runs/pilot 保存新的输入摘要。不要在同一次试点中混用不同版本的接口文档和业务要求。

文件	应包含的内容	不足时会出现的问题
requirements.md	业务目标、触发条件、主流程、拒绝规则、作用范围	模型根据接口名称猜业务
contract.json	请求和响应字段、业务码、调用约束	生成不存在的字段和错误码
domain.md	资源、状态、数量关系、一致性假设	只断言响应，漏掉资源变化
capabilities.json	构造、原始调用、状态查询、记录查询、清理能力	剧本合理但无法执行或观察
existing_test.py	维护中的基类、fixture、断言、清理和运行习惯	生成另一套不能进入现有流水线的脚本

实际项目可以有多个需求文件和样本脚本，记录进输入快照即可。教学工程固定了这五个入口，便于第一次操作。多文档项目还应约定来源优先级，并把无法按优先级解决的冲突交给业务负责人确认。

能力清单要写出可调用的方法

“支持自动化测试”太宽泛。本例需要五项具体能力：

能力标识	示例方法	必须确认的行为
create_item	create_item(stock)	创建隔离商品，返回可用于调用的编号
reserve_raw	reserve(sku, quantity, request_id)	保留非法数量的原始类型和值
read_stock	stock(sku)	查询当前可用库存
count_reservations	reservation_count(sku)	查询本商品的预占记录数
delete_item	delete_item(sku)	清理商品及其关联的教学记录

清单写完后，先实际调用一次。例如，“可以查询预占记录”需要确认接受什么标识、返回什么数据。available: true 只表示资料声称能力存在，还不能证明它足以支持这条断言。

若 SDK 把字符串 "2" 自动转换为整数，测试就没有验证服务端对字符串的拒绝行为。可以复用项目已有的原始请求入口；没有这样的入口时，保留能力缺口。不要把在客户端抛出的参数异常写成服务端业务拒绝。

存量代码用于学习调用和资源管理方式。验收规则应来自确认过的需求；若现有实现与新需求冲突，应记录冲突，不能因旧脚本目前通过就沿用旧预期。

6. 用 Prompt 提取可审阅的规则

在能读写本地文件的编程助手中打开工程根目录，说明“本次运行目录为 runs/pilot”，然后使用下面的 Prompt。普通聊天模型也能使用：提供五类资料和 formats.md，将返回的 JSON 手动保存到本次目录，再由本地 Python 执行校验。

这一步先停在规则上。模型需要说明什么条件触发哪种结果、哪些资源会改变或保持不变，并留下来源。把这些判断审清楚以后，下一步才有依据设计输入和断言。

你正在维护一个分阶段测试工作流。项目根目录有 workflow.py，本次运行目录由用户指定。

读取本次目录中的 inputs/requirements.md、contract.json、domain.md、capabilities.json、existing_test.py，以及本 Skill 的 references/formats.md。

先说明被测操作、范围和排除项；理解存量脚本的前置构造、原始参数发送、观察与清理方式。然后仅在本次运行目录生成 spec.json。

每条规则写明触发条件、业务动作和可观察结果，分配稳定 R 编号，并引用输入文件内一段精确原文。区分字段合法性、业务拒绝、状态改变和仅记录告警的行为。接口结构不能替代缺失的业务语义；代码现状也不能覆盖已确认的新需求。

冲突和缺失信息写入 open_questions，不凭常识补出错误码、超时、重试次数、权限或幂等策略。可以提出待确认的候选解释，但不得将其写成已确认规则。只提取本次范围内的行为。

执行 python workflow.py check 本次运行目录 --stage spec。根据错误做最多两次局部修复。最后给出规则清单、来源、待确认问题和实际检查结果。停止在规则审核处，不执行 approve，不生成测试代码。不读取 examples/reference 或 demo_service.py。

生成文件的结构如下，完整参考文件位于仓库的 examples/reference 中：

{
  "rules": [
    {
      "id": "R02",
      "statement": "库存足够时预占成功并扣减库存、创建记录；不足时拒绝且不改变资源。",
      "source": {
        "file": "requirements.md",
        "quote": "这里填写需求文件中实际存在的一段原文，至少八个字符"
      }
    }
  ],
  "open_questions": []
}

上面的 quote 说明填写位置，不是可通过校验的来源。实际生成时必须复制输入文件原文。校验器检查该片段是否确实存在，不判断模型对片段的解释是否正确，也无法发现所有遗漏规则。

业务审核应重点看：成功和拒绝条件是否写反；“记录告警”是否被误写为“拒绝请求”；重复提交是否真的有已确认的约定；拒绝后哪些资源必须保持不变。出现不确定信息时，写进 open_questions，向业务方核实后更新输入、重新快照和生成。

当前规则审核完成后，由实际审核者执行或明确委托执行：

python workflow.py check runs/pilot --stage spec
python workflow.py approve runs/pilot --stage spec --reviewer "实际审核者姓名"

approve 会拒绝仍含待确认问题的规约。不要让模型为自己生成的规则自动写一条“人工已审核”。

7. 用 Prompt 把规则变成测试剧本

测试剧本是一个具体实验：先建立什么状态，发送什么请求，最后观察什么。预期在执行前从规则推导出来。

以库存不足为例，初始库存为 1，申请数量为 2。接口应返回 INSUFFICIENT_STOCK，库存仍为 1，预占记录仍为 0。请求必须使用已存在的商品和有效的请求编号，否则可能先被其他规则拒绝，无法证明库存不足逻辑是否成立。

读取本次运行目录中的 spec.json、review-spec.json 和全部 inputs，以及本 Skill 的 references/formats.md。先执行 python workflow.py check 本次运行目录 --stage spec，再执行 python workflow.py verify-review 本次运行目录 --stage spec；若失败，报告需要重新审核并停止。

根据已审核规则生成 cases.json。覆盖成功、有效边界、无效输入和需求明确规定的重复请求行为。每条用例写出目标规则、初始状态、请求及预期的响应和资源变化；除目标失败条件外，其余前置保持有效。

识别 SDK 是否会转换或拦截非法输入。需要验证服务端参数检查时保留原始类型和值。测试相同请求时复用同一 key；不同测试依靠框架的独立命名空间隔离。

核对构造、调用、观察、清理五类能力。缺少能力的场景保留为 blocked，说明具体缺口；不要发明 API，不要用无条件 skip 或删除场景把它隐藏。预期必须由规则推导，不能先运行服务再反填答案。

执行 python workflow.py check 本次运行目录 --stage cases，最多做两次针对检查错误的修复。最后提供可读剧本表、规则关联、未覆盖边界和 blocked 清单。停止在剧本审核处，不执行 approve、render 或 run。不读取 examples/reference 或 demo_service.py。

一条可执行剧本如下。它在完整 cases 数组中使用，不能替代其他规则所需的场景：

{
  "id": "C02",
  "title": "库存不足时拒绝且不改变资源",
  "rule_ids": ["R02"],
  "status": "ready",
  "blocked_reason": "",
  "initial_stock": 1,
  "requests": [{"quantity": 2, "key": "first"}],
  "expect": {
    "codes": ["INSUFFICIENT_STOCK"],
    "remaining_stock": 1,
    "reservation_count": 0,
    "same_reservation": null
  }
}

key 表示同一个测试内的请求身份。相同 key 会得到相同请求编号；不同用例由基类加入独立命名空间，避免重复运行时互相污染。

参考剧本包含以下 10 个实验。模型不必逐字复现标题，但应说明自己选取的输入、覆盖依据和遗漏：

类别	初始库存与请求	核心预期
普通成功	库存 5，申请 2	剩余 3，一条记录
库存不足	库存 1，申请 2	拒绝，剩余 1，无记录
恰好耗尽	库存 2，申请 2	成功，剩余 0，一条记录
非法数量，5 条	库存 5，分别发送 0、−1、true、1.5、"2"	拒绝，资源不变
重复提交	库存 5，相同 key 申请 2 两次	同一结果编号，只扣一次
幂等冲突	库存 5，相同 key 先申请 2，再申请 1	第二次冲突，保留第一次结果

本例没有穷举所有合法整数和所有非法值。无穷输入空间需要等价类、边界和风险取舍；更全面的参数测试可以在试点之后扩展。

缺少能力时保留 blocked

如果公司系统不能查询预占记录，就无法验证“成功必须保存记录”这一断言。应保留对应场景：

{
  "id": "C11",
  "title": "成功后应创建一条可查询的预占记录",
  "rule_ids": ["R02"],
  "status": "blocked",
  "blocked_reason": "测试环境尚无预占记录查询能力，无法验证持久化结果",
  "initial_stock": null,
  "requests": [],
  "expect": null
}

教学模板要求每条 ready 用例都具备五类能力，因此一项公共能力缺失时，所有依赖它的场景都要改为 blocked。真实平台可以按每条用例的操作和观察需求计算依赖，但要同时调整 schema、校验器和模板。

测试审核需要确认目标规则确实会被触发，其他条件保持有效，断言有独立观察依据，资源能够清理。审核后执行：

python workflow.py check runs/pilot --stage cases
python workflow.py approve runs/pilot --stage cases --reviewer "实际审核者姓名"

规则必须至少关联一条剧本；关联到 blocked 剧本仍然不算完成测试。审核表中还应单独列出已知未覆盖分支，例如本例尚未实现的“同一请求编号换商品”。

8. 把剧本填入测试骨架并运行

python workflow.py render runs/pilot
python workflow.py run runs/pilot

render 只处理 ready 剧本，每次写入新的生成目录。run 检查输入、审核、模板实现及生成文件摘要，确认测试发现数量，再启动本机服务执行。生成文件被直接修改时会停止，应回到剧本或模板修复，再重新生成。

对应库存不足剧本的代码大致如下。实际文件由 code_for() 生成，基础设施来自 ScenarioCase：

from harness import ScenarioCase

class GeneratedC02(ScenarioCase):
    def test_C02(self):
        sku = self.api.create_item(stock=1)
        self.addCleanup(self.api.delete_item, sku)
        self.assertEqual(self.api.stock(sku), 1)

        result = self.api.reserve(sku, 2, self.request_id("first"))

        self.assertEqual(result["code"], "INSUFFICIENT_STOCK")
        self.assertIsNone(result["reservation_id"])
        self.assertEqual(self.api.stock(sku), 1)
        self.assertEqual(self.api.reservation_count(sku), 0)

代码先把库存构造成 1，再读回来确认前置确实成立；发起数量为 2 的预占后，除了检查错误码，还检查库存和记录。清理则在断言之前就已登记，即使后面失败，也能尝试释放资源。这三个步骤分别保护前置、业务结果和资源生命周期。unittest 提供测试发现、断言与 cleanup 机制，具体行为可查阅 Python unittest 文档。

示例是同步服务，因此立即读取结果。公司系统如果是最终一致，必须给出完成条件和有界等待策略，例如等待带本次请求标识的任务进入终态，再查询结果。固定 sleep 只能碰运气；无限重试则可能隐藏缺陷或重复产生副作用。

报告保存在本次目录的 reports 中，包含执行日志、逐条状态、blocked 清单、审核记录和版本摘要。命令返回码为：

返回码	含义
0	本次计划的可交付范围完整执行并通过，没有 blocked
1	用例失败、执行错误或仍有 blocked，不能作为完整通过
2	输入无效、审核过期或执行准备失败

假设结果是 9 条通过、1 条 blocked，报告应把两部分都留下，整体标为 blocked。被阻塞的那条仍属于原计划，不能从统计里删除后再报 100% 通过。另一个字段 complete 只说明计划执行是否完整，需要与断言是否通过分别看。

9. 失败后回到证据所在的阶段

脚本失败可能来自产品缺陷，也可能是资料错误、前置构造失败或测试实现错误。先保留原报告，再分析具体证据。

读取用户指定的运行报告，以及报告所关联的 inputs、spec.json、cases.json 和生成文件。先核对 report.fingerprint、render 清单与当前产物是否一致；不一致时不要把旧结果用于当前版本验收。

逐条说明实际结果与剧本预期的差异。根据原始日志，将失败归为资料或规则问题、能力缺失、前置未成立、业务行为不符、测试代码问题、执行环境问题或清理失败。证据不足就保留未判定，不仅依据异常名称猜根因。

给出最小修复建议、需要改变的文件，以及修复后应重跑的检查。不要改预期来迁就现有实现，不要隐藏 blocked、skip 或缺失结果，不要自动重试可能重复产生业务副作用的操作。

如用户已授权修复本地生成产物，最多做两次针对性修复；改变 spec 或 cases 后按项目流程重新审核并生成。不要直接篡改已经登记哈希的生成文件。报告应分别列出通过、失败、错误、阻塞和未执行，不把生成文件数当成通过数。

例如库存不足场景返回了预期业务码，但库存从 1 变成了 0。规则明确要求不改变库存，前置读回也确认初始为 1，那么应调查被测实现，而不是把剧本预期改成 0。反过来，如果创建接口没有建立期望库存，后续业务断言不具备有效前提，应先修复 fixture 或能力映射。

修改内容	必须重做的步骤
需求或接口资料	更新输入快照，重新核对规约、剧本及审核
规则含义	审核规约，核对受影响剧本，再审核、生成和执行
剧本参数或预期	审核剧本，重新生成和执行
模板或适配层	审阅代码，重新生成，运行工作流回归和受影响测试
被测系统缺陷	保留失败报告，在修复版本重新执行，比较结果

“最多两次修复”只是本例防止模型在同一个阶段无限试错的操作限制，不是两次之后就允许放宽规则。仍然失败时保留错误和缺口，由人判断下一步。

10. 将 Prompt 固化成可重复使用的 Skill

Prompt 适合第一次操作；多次执行后，可以把阶段入口、约束和引用文件保存在 Skill 中。仓库中的 Skill 提供如下入口，详细 Prompt 按阶段放在 references，避免每次都加载全部内容。

---
name: ai-test-workflow
description: Build reviewable business rules and executable test plans from requirements, API contracts, domain knowledge and existing tests. Use for staged test generation or diagnosing a failed generated case in the companion Python workflow project.
---

# AI test workflow

Work from the companion project root containing `workflow.py`. The user supplies a run directory. Keep other runs and company repositories unchanged unless the task explicitly includes them.

Read that run's `inputs/requirements.md`, `contract.json`, `domain.md`, `capabilities.json` and `existing_test.py`. Use [formats.md](references/formats.md) for artifact structure and workflow commands.

Choose the stage that matches the request:

- Requirements to rules: read [01-spec.md](references/01-spec.md), write `spec.json`, run `check --stage spec`, and present unresolved questions and rules for business review.
- Reviewed rules to cases: verify that `review-spec.json` matches the current inputs and spec, read [02-cases.md](references/02-cases.md), write `cases.json`, run `check --stage cases`, and present the test plan for review.
- Reviewed cases to code and results: use `workflow.py render` then `workflow.py run`. Use [03-diagnose.md](references/03-diagnose.md) to explain failures. Do not rewrite a failing expectation to match observed behavior.
- Company framework migration: read [04-adapt.md](references/04-adapt.md). Map real capabilities before implementing an adapter or changing the case schema.

Only repair artifacts belonging to the current stage. Reuse rule and case IDs when their meaning is unchanged. If a source conflicts with another source, retain the conflict as an open question instead of selecting the convenient answer. Missing execution or observation capabilities keep the affected case blocked.

The `approve` command records a review decision; do not issue it on a person's behalf unless that person explicitly confirmed the current artifact. A matching hash proves version association, not the identity or quality of the reviewer. The bundled `demo` is a reference replay and deliberately labels its review records as non-human examples.

For a check failure, make at most two targeted repair attempts using the reported errors. Then return the remaining errors, relevant input excerpts and the blocked artifact. Stop after the requested stage; do not add publishing, company-system calls or unrelated dependency setup.

For a generation-quality evaluation, do not read `examples/reference/` or `demo_service.py` before producing rules and cases. Those files contain answers or implementation behavior and would contaminate the trial. They may be used later to inspect a failed local demonstration, with that use recorded.

这个组织方式采用 SKILL.md 的 name、description 元数据及分层引用，参见 Agent Skills 格式规范。不同助手的技能安装位置和自动发现方式可能不同；本教程不依赖自动发现。直接让助手读取仓库中的 skills/ai-test-workflow/SKILL.md 即可开始，或者逐个粘贴本文 Prompt。

一次调用应明确目录和阶段，例如：

请读取 skills/ai-test-workflow/SKILL.md。
项目根目录为当前目录，本次运行目录为 runs/pilot。
仅完成需求到规则阶段；写入 spec.json 并执行检查，
将规则和待确认问题交给我审核后停止。

下一阶段使用同一运行目录，并明确“规约已审核，请生成剧本”。助手应先校验审核记录对应当前版本。不要在长期会话中只说“继续”，却让它猜测本次处理哪个目录、哪版资料。

这份 Skill 与配套工程共同分发。若只复制 Skill 文件夹，Python 校验器和输入资料不会自动随之安装。

11. 接入公司的现有测试框架

本机跑通后，先让测试开发人员接入一个业务操作。业务人员负责确认规则，测试人员设计实验，平台维护人员确认环境和能力；可以由同一个人兼任，但每项工作仍需完成。

第一步：映射现有能力

把下面的 Prompt 交给可读取公司测试仓库的助手，同时指定仓库路径、一个操作、维护中的样本脚本和本次允许修改的目录。

这是一次公司测试框架接入任务。用户会指定测试仓库、隔离环境、一个业务操作、可修改目录和维护人员确认过的样本脚本。先读取这些资料与本次 inputs，不要调用真实业务接口。

产出接入表：逐项列出前置构造、业务调用、状态观察、记录查询、清理、身份获取、结果汇报对应的真实函数、参数、返回值、来源文件，以及缺失能力。区分 SDK 的客户端校验和服务端校验入口。未找到的函数保留为缺口，不根据命名规律编造。

检查当前 cases 格式能否表达目标领域。不能表达时，提出最小字段调整，并同时列出 validator、代码模板、adapter 和回归用例的修改；不要把其他业务强行塞入库存字段。需求中的异步等待、跨接口流程和并发行为分别设计，不在当前同步模板里偷偷增加 sleep 或无限重试。

先提交接入表和一条代表剧本的实现方案供维护人员确认。确认后，只在授权目录实现 adapter 与模板；复用现有基类、fixture、鉴权入口和清理机制。代码生成只填写确认过的调用、参数与断言，不修改测试发现和结果汇总规则。认证信息从项目已有配置入口获取，不写入提示词、样本或生成文件。

静态检查后，给出发现的测试列表及将创建和清理的资源。只有用户已指定可执行的隔离环境与范围时才运行；保存原始响应中的必要诊断字段并按项目约定脱敏。用一个正常场景和一个明确失败场景核实 adapter 的语义，再运行整个试点集合。报告实际执行范围及仍被阻塞的场景，不声称已经支持其他业务域。

输出应包含能找到实际代码的映射，例如：

工作流需要的动作	公司实现需要确认的内容
前置构造	工厂或测试 API 的真实函数、参数、返回实体、清理方式
业务调用	协议适配、请求构造、既有鉴权配置、原始参数入口
状态观察	查询来源、隔离条件、一致性时点，是否会读到缓存旧值
记录查询	使用哪种业务标识关联本次请求，如何排除其他测试记录
结果汇报	当前框架怎样收集失败、跳过、异常和未执行

先验证这些能力，再让模型批量生成剧本。缺少构造或观察能力时，补齐测试 API 往往比调整 Prompt 更有效。

第二步：接入基类、模板和领域格式

教学工程有三个直接的修改位置：

1. harness.py：用公司 SDK 或契约测试框架的能力实现适配层；复用已有配置、身份和清理入口。
2. workflow.py 中的 cases_check() 和 code_for()：同步修改剧本格式、校验及代码模板。把生成业务代码限制在明确的前置、调用、断言区域。
3. run_tests()：用现有测试环境的生命周期或 runner 替换 demo_service.serve，保留版本关联、测试发现和完整报告。

当前 run 命令始终调用本机演示服务，没有公司 URL 参数。仅替换输入文档不会让它自动调用公司系统。接入工作需要修改以上实现，并用样本验证；这一点应在试点排期时明确。

库存字段也不是通用业务语言。若要测试转账，应表达付款方、收款方、金额、账务记录和状态；若要测试审批，应表达申请、角色、动作和审批状态。可以复用产物分阶段、来源关联、模板和检查机制，不能沿用不适合新领域的字段。

如果框架已有契约层，业务剧本可以映射到现有的测试 API；保留协议编码、鉴权、错误转换在 adapter 内。生成代码应使用稳定的业务调用，避免把公司协议细节复制到每条测试中。这也使同一方法更容易迁移到其他框架。

第三步：运行代表场景，再接 CI

先手工审阅并执行一条成功场景和一条业务拒绝场景。确认请求真正抵达目标服务，前置可读回，断言能观察实际状态，清理不会影响其他测试。然后扩大到一组包含边界、重复请求和已知缺口的试点集合。

即使每条测试使用不同目录，写入同一个业务对象的请求仍可能相互影响。并行前确认资源、请求身份和观察查询的隔离；暂时不能隔离的场景可以串行运行，并明确限制。

初次接入 CI 时，可以只运行已经过评审的产物：先验证规则和剧本，再验证审核版本，生成并执行测试，最后上传报告。不要在 CI 中自动填写人工审核记录来让流程通过。试点成熟后，再接入模型调用和任务调度；保留每次使用的模型标识、Prompt 版本、输入版本和产物，方便回归。

12. 验证它是否提高了交付质量和效率

先选一组人工可核对的代表需求，建立参考规则、场景和已知缺陷集合。生成时不给模型看参考产物，完成后由人对比。记录模型配置、输入版本和人工修改，才能比较下一次改动。

指标	计算或记录方式	能回答的问题
首次结构校验通过率	首次产物通过检查的任务数 / 全部尝试任务数	输出是否稳定可处理
语义修正	逐条记录遗漏规则、错误前置、错误预期及修改原因	业务正确性还依赖多少人工修复
完整执行比例	实际有结果的计划场景数 / 计划场景总数，blocked 单列	生成内容能否真正进入执行
已知缺陷检出	被业务断言发现的已知缺陷数 / 注入或历史缺陷数	测试是否具备区分正确和错误行为的能力
人工投入	资料准备、审核、修复和排错分别计时	节省了哪个环节，又增加了哪个环节
交付周期	从收到相同范围需求到完成有效验收的总时长	整体交付是否变快

本地故障开关可以作为最小断言检查，但只有三种缺陷，不能代表真实系统的全部风险。扩大评估时，应加入错误码不符、记录字段错误、状态未更新、权限缺失、重复消息等实际历史问题，并由业务域决定哪些适用。

比较效率时，从准备资料开始计时，一直到审阅、执行和错误预期排查完成。只比较模型生成与人工写代码的时间，会漏掉这些交付工作。效果记录也要写清统计对象：框架覆盖率、生成文件数和团队总体产出，不能直接换成个人使用 AI 的效果。

13. 试点完成前的检查表

• 输入有版本，需求和接口冲突已解决或明确阻塞。
• 规则能够回到原始资料，人工确认了条件和资源变化。
• 剧本覆盖范围已说明，未知分支与能力缺口仍可见。
• 非法输入能够到达需要验证的层，预期在执行前确定。
• 前置、业务调用、观察和清理都经过代表场景验证。
• 生成文件被测试框架发现，失败、异常和缺失结果没有被吞掉。
• 已知错误实现会触发断言，而非因环境故障偶然失败。
• 报告与当前输入、剧本和代码版本关联，部分通过没有被写成完整交付。

完成这些检查后，再增加第二个操作。每新增一种业务能力，都补充相应的格式、模板和回归样例；能够由程序稳定处理的部分留在程序里，需要业务判断的部分保留明确的审核位置。