用AI生成测试计划，先把版本范围和可用测试资源说清楚，再让它从需求、接口和历史缺陷中提取风险，安排测试顺序，最后写出进入测试与结束测试的条件。测试计划回答“这次测什么、为什么测、谁来测、何时能交付”；具体的点击步骤和断言则放在测试用例里。
墨刀AI客户端面向本地项目文件和桌面任务，可作为整理入口；先查看墨刀AI客户端的本地项目工作方式，再按本文案例准备材料。把材料范围限定在当前版本，生成的结果更容易与需求负责人逐项对照。
输入材料先形成版本边界
以“退款流程改版”为例，准备需求文档、接口变更说明、原型链接、权限表和历史缺陷摘要。文件名带版本号，明确本次改动涉及申请、审核和通知，不把整个仓库默认当成测试范围。若材料缺失，先列出缺口而不是让AI自行补规则。
本例约定：用户可在订单详情申请部分退款；审核人员确认后发起退款；结果经通知更新。已支付100元、累计已退20元的订单，本次最多申请80元；退款中的金额也要占用可退额度。规则尚未确定时，先把“退款中是否占用额度”列为问题，不能悄悄采用其中一种解释。
refund-release/
scope.md 本次范围与不测项
requirements/refund.md 金额、权限、状态规则
api/refund-contract.md 请求字段与结果通知
history/defects.csv 重复退款、金额错误记录
resources.md 人力、环境与提测时间
output/ 保存计划和问题清单在scope.md中明确：纳入申请、审核、结果通知与订单展示；本次未修改的发票功能不做完整功能测试，但要检查它是否读取退款后的实付金额。这种“范围外模块的相关影响检查”应单列，既避免范围无限扩张，也避免把“不测”误解成“不受影响”。
文件夹准备好后，在客户端打开该本地项目，指定要读取的上述文件。资料中的生产密钥、真实银行卡和个人信息不需要参与这项任务，使用测试账号、占位值和脱敏缺陷记录即可。
让AI输出五张计划表
| 产物 | 至少包含 | 负责人 |
|---|---|---|
| 范围表 | 功能、平台、用户角色、明确不测项 | 产品与测试 |
| 风险表 | 风险、触发条件、影响、缓解动作 | 测试负责人 |
| 环境表 | 账号、数据、服务依赖、版本 | 研发与运维 |
| 策略表 | 冒烟、功能、兼容、回归顺序 | 测试 |
| 退出标准 | 阻断缺陷、关键路径通过条件 | 项目负责人 |
提示词应要求每个结论标出来源文件和段落；没有依据的内容写“待确认”。生成后先核对范围，再检查风险是否覆盖权限、数据一致性、重复提交和失败恢复。
把退款风险转成可安排的测试工作
风险不能只写“金额有风险”“需要充分测试”。应把触发条件与损失联系起来，再说明如何发现问题。下面的分级是本例的排期规则：涉及资金重复划出、越权或账实不一致的项目优先处理，不按页面数量平均分配时间。
| 风险与依据 | 安排的测试 | 准备条件 | 完成后检查 |
|---|---|---|---|
| 同一申请被重复提交，可能重复退款 | 同一申请标识重复提交、超时后重试 | 可查询退款请求与处理记录 | 仅形成一次有效退款，重复请求有确定结果 |
| 两笔并行申请超过可退额度 | 两笔申请合计超过剩余额度 | 已支付100元、已退20元的测试订单 | 累计成功及在途金额按业务规则受控 |
| 结果通知迟到，页面与账单状态不同 | 延迟通知、重复通知、先失败后成功 | 测试环境支持控制通知时序 | 状态转移和最终金额一致，可查到处理记录 |
| 无审核权限的账号发起审核 | 页面操作与直接请求分别检查 | 申请人、审核人、普通账号 | 服务端拒绝越权操作，订单状态不变 |
如果环境无法控制通知时序，计划里就要写明由谁提供替代验证条件，以及哪部分风险仍未覆盖。不能把“测试受阻”直接改成“低优先级”。原型适合检查申请、审核、失败提示与返回路径；金额扣减和服务端权限需要在对应测试环境检查。
可复制的退款版本测试计划提示词
请基于当前项目生成退款改版测试计划，保存为output/refund-test-plan.md。只读取scope.md、requirements/refund.md、api/refund-contract.md、history/defects.csv和resources.md；先列出资料冲突与缺项，再输出计划。
本次交付需要：①范围表，区分本次功能、关联影响和不测项；②按资金、权限、状态一致性排列的风险表，每条写来源文件及章节、触发条件、检查方法；③账号、订单数据、通知时序与服务依赖清单；④按依赖安排冒烟、功能、异常和回归顺序；⑤进入条件、退出条件与负责人。
为每项风险分配稳定编号R-01起，为测试工作分配T-01起，并关联到需求规则。区分原文件明确规定的规则与你提出的测试建议。没有证据的超时时长、金额精度、审核时限写入问题清单，不自行设定。
根据resources.md计算可用人时，分别列数据准备、执行、缺陷复测和评审的估算；写清任务依赖，不把所有工作排成并行。不修改源码，不执行测试，不把计划项标成已通过。最后给出可供产品、研发与测试负责人逐项确认的决定清单。
第一轮结果到手后，先抽查R-01的来源能否找到原句，再反查一条需求是否关联了测试工作。只有“需求→风险→工作项”能双向追踪，增加测试条数才有意义。需要详细操作步骤时，再按确认的工作项生成测试用例，避免让用例细节淹没计划。
资源不足时，减少范围而不是缩短每项验证
假设两名测试人员可投入3天，每人每天实际可用5小时，总容量为30人时。可以先估算数据和环境准备6人时、执行14人时、缺陷复测6人时、结果整理与评审4人时。这是排期演算，需要用团队经验替换；“两人同时工作”不代表依赖同一个环境的任务可以并行。
当初稿估算达到38人时时，应让AI列出可延期项及其关联风险，再由负责人取舍。例如先完成退款金额、权限和关键状态检查，再决定是否将未改动页面的低风险兼容检查移到后续窗口。资金正确性检查所需时间不能被平均压缩为原来的一半；可以调整发布范围、增加资源或延后时间。
计划末尾可直接使用这样的决策记录：“R-03通知延迟验证依赖测试通知入口，由研发负责人确认可用日期；未满足时，该项保持阻塞，不能计入已完成。退款主路径与资金一致性问题未关闭前，不满足本版本退出条件。”这样写比“所有测试通过后上线”更能暴露真实依赖。
用三轮评审把计划变成行动
第一轮由产品确认本次做什么；第二轮由研发确认环境、接口和不可测限制；第三轮由测试确认场景顺序、数据准备和缺陷出口。将修改记录和决定人写回同一份计划，避免AI每次重新生成造成版本漂移。
进入测试前确认可安装版本、测试数据、账号权限和依赖服务已准备好；结束测试时，逐项核对已约定的关键路径结果、阻断缺陷状态和未覆盖风险。若范围在评审后变化，保留计划编号，只更新受影响的风险、资源和排期，不整篇重新生成。
最终成果应包含一页范围摘要、风险矩阵、环境准备清单、执行顺序和退出标准。进入工作区整理需求与原型，再把计划初稿交给团队核验。
