做了这么多年测试拿到需求文档的第一反应永远不是“这个功能怎么验”而是“用例怎么写得又快又不漏”。尤其碰上迭代节奏快的项目产品原型刚出开发排期已经定死用例评审时间被压缩到可怜的两三天。这时候靠人肉硬写一份覆盖全的测试用例非常痛苦漏场景、漏边界几乎是必然的。后来我开始尝试把大模型拉进用例设计这个环节用提示词工程约束它按测试人员的思路去拆解需求、补充场景。经过几个项目的实弹演练我总结出一套相对稳定、可复用的“大模型生成用例提示词方案”这篇文章就是把这段实战过程里最有价值的部分整理出来——包括提示词框架、具体模板、踩过的坑和把它工程化接入测试平台的思路。适合谁来参考如果你是在用大模型辅助写功能用例、接口用例、白盒用例或者想把这套能力接进公司的测试管理平台、让团队共享用例生成能力那这篇文章正好对路。下面的内容不会讲太多模型原理全部围绕“怎么写提示词、怎么约束输出、怎么落地”这三个实际问题来展开。1. 先想清楚为什么让大模型写用例必须依赖一套好的提示词1.1 大模型生成用例的底层逻辑大模型本质上是一个“根据输入预测下一段合理文本”的系统。你给它一段描述它按概率生成看起来最像样的回答。问题在于对测试用例来说“看起来像样”和“能用、覆盖全、可执行”之间差距巨大。模型并不知道你的业务规则、不知道你项目中哪些状态是真实存在的、不知道开发团队对用例粒度的偏好它只是把语料里见过的“测试用例模板”拼出来。这决定了提示词的作用并不是“让模型会写用例”而是“告诉模型在写用例时要参考哪些上下文、遵守哪些规则、输出成什么形态”。一套高质量的提示词本质上是把测试人员脑子里那套拆解逻辑显性化、规则化输出给模型。想清楚这一点你就不会指望随便丢一句“帮我写测试用例”就能拿到能用的东西而是认真设计提示词的结构。1.2 提示词写得好不好差别有多大可以很直接地告诉大家我在实际项目里做过对比一半用例用默认方式生成只给一句话需求另一半用完整的提示词框架约束生成。对比下来的差别非常明显。对比维度一句话提示词结构化提示词用例条数8-10条25-35条覆盖维度只覆盖主流程主流程、异常流、边界值、数据规则、权限用例粒度“验证登录成功”这类大而空前置条件、步骤、预期结果一一对应可用率无需人工改可直接用约40%约85%评审修改耗时1-2小时20-30分钟差距的来源在于后者通过提示词给模型“补齐了信息上下文”。“默认方式”下模型缺少需求细节只能靠通用逻辑猜在“结构化提示词”里我明确告诉它当前模块的业务规则、字段约束、状态流转、操作权限模型就有了足够信息去推演场景。还出现过另一种情况团队里不同人用同样的话术去问模型结果每次写出来的颗粒度不一样。后来我把提示词做成团队统一模板把这套模板沉淀在文档里或测试平台的用例生成入口保证无论谁来用输出质量都稳定。这也是做“提示词总结”而不是简单“写个好提示词”的真正意义——让能力可复制、质量可预期。2. 提示词框架一套能直接套用的用例生成模板2.1 五个核心要素拆解我自己调试很多轮以后把“生成用例提示词”拆成了五个必备要素目标设定、角色设定、上下文信息、约束规则、输出格式。每个要素都对应了一个要解决的问题。首先是目标设定。开头就要告诉模型“你接下来要做什么”。有两种写法区别很大错误示范帮我写一些登录功能的测试用例。 正确示范请输出一份面向功能测试的登录模块测试用例需要覆盖正常流程、异常流程、边界值和权限控制四类场景每条用例包含用例编号、前置条件、测试步骤、预期结果、优先级。“错误示范”的问题在于目标太宽模型不知道覆盖到什么程度算完成。“正确示范”明确了范围登录模块、场景分类正常、异常、边界、权限和输出字段编号、前置、步骤、预期、优先级。目标越具体模型的对齐效果越好。然后是角色设定。给模型一个“身份”等于给它激活对应领域的知识分布。测试工程师这个角色设定会让模型调用软件测试方法论的语料分布而不是泛泛的AI助手语气。我惯用的写法是你是一名在大型互联网公司从业8年的测试工程师擅长功能测试与接口测试熟悉等价类划分、边界值分析、场景法等用例设计方法。在实际使用中发现加了角色设定以后生成用例里用到“边界值分析”“等价类划分”这些专业方法的比例明显提高说明角色设定确实会引导模型往更专业的语料方向靠拢。更关键的是上下文信息。这是决定用例质量最重要的部分。你需要把需求相关的规则“喂”给模型。上下文信息包括但不限于业务规则比如订单金额必须大于0且小于等于10000、字段规则手机号必须11位、以1开头、状态流转订单状态从待支付到已支付、不能从已支付回退到待支付、权限定义管理员可操作所有订单、普通用户只能查看自己的订单。刚开始用大模型写用例的人最容易犯的毛病就是“空手上阵”——只给一句“帮我测试下单功能”然后吐槽模型写的用例太泛。实际上模型根本不了解你的业务规则它只能给出最通用的流程性用例。要拿到能用的用例请先把需求文档里和规则相关的信息摘出来整理成几段描述作为上下文信息输入给模型。规则给得越全用例的可执行性越强。约束规则是防止模型“自由发挥”的关键。常见的约束有不要编写不存在的功能不要假设系统中没有的按钮或页面用例步骤要可操作不能出现“验证系统稳定性”这类无法直接执行的描述预期结果要具体不能写“系统正常”如果模型不确定某些业务逻辑要在用例中用“待确认”标记出来不要自行脑补。这些约束写不写直接决定了下游人工筛选的精力成本。最后是输出格式。如果只是让人阅读Markdown表格就够用了。如果用例要导入测试管理平台比如禅道、Jira、TestRail你就要让模型输出成对应的格式例如带Tab分隔的文本或者明确的字段顺序。输出格式这块会直接影响后续的工程化效率我们到第4章再展开细讲。2.2 负面约束怎么写给模型看很多人写提示词只写“要做什么”不写“不要做什么”结果模型有时候会为了显得专业而胡编乱造。在用例生成的场景里“不做什么”和“做什么”同等重要。我整理出几条非常实用的负面约束写法禁止编写用例库中明显不存在的功能场景 禁止假设隐藏菜单、隐藏按钮、隐藏权限 同一场景不要重复出现在不同分类中 不要使用含糊的预期结果例如“系统正常”“页面正确” 如果不确定某个业务逻辑请在该用例预期结果末尾标注“待确认” 不要生成与上下文规则相矛盾的用例例如订单金额已限定为0-10000就不要出现金额20000的用例。写负面约束的原则是回顾之前项目中模型生成的“垃圾用例”把导致垃圾的规律写成禁止项。比如大模型非常喜欢编造一些不存在的按钮名称诸如“批量导出V2按钮”这种系统里根本没有的东西那么我们就可以把这一类问题写入负面约束“用例中出现的操作元素必须与上下文描述的功能模块完全一致不得自行添加新按钮、新入口。”2.3 一个完整的提示词模板可直接复制把上面五要素整合起来我目前最常用的模板长这样你是一名有8年工作经验的资深测试工程师擅长功能测试与接口测试熟悉等价类划分、边界值分析、场景法等用例设计方法。 请根据以下需求描述输出一份可执行的功能测试用例。 【模块名称】 订单提交 【业务规则】 1. 订单金额字段范围为0.01元至10000元小数点后最多两位 2. 优惠券金额不能超过订单金额 3. 用户提交订单后订单状态进入“待支付”支付成功后状态为“已支付” 4. “已支付”状态不可回退到“待支付” 5. 普通用户只能查询自己的订单管理员可以查询所有订单 6. 库存不足时点击提交订单弹窗提示“库存不足”订单不生成。 【接口与页面】 页面订单确认页、订单列表页 操作点击“提交订单”、输入优惠券码、选择配送方式 【约束】 1. 操作元素必须来自“页面与操作”部分描述不得新增不存在的按钮或入口 2. 预期结果必须具体可验证不得使用“系统正常”“页面正确”等模糊表述 3. 覆盖正常流程、异常流程、边界值、权限控制四类场景 4. 如果业务逻辑不明确请在该用例预期结果后标注“待确认”。 【输出格式】 Markdown表格字段包含用例编号、用例标题、前置条件、测试步骤、预期结果、优先级(P0/P1/P2)、场景分类。这段模板我几乎每个新项目都会先用一遍然后在具体项目里补充“项目特有的规则”。真正用起来以后你会发现提示词模板不是一成不变的而是“骨架固定、血肉随项目换”。3. 实操案例从需求描述到功能测试用例全流程3.1 场景设定与输入信息准备用上面的模板结合一个具体场景来演示。假设我们要测一个“优惠券领取”功能。这个功能本身不复杂但如果只给大模型三个字“领优惠券”它大概率会给出“点击领券-弹出成功提示”这种2到3条用例完全不够用。我的做法是先花10分钟把需求信息从产品文档里摘出来整理成规则描述再喂给模型。这个环节是人工投入最重的地方也可以说是提示词工程中真正的核心。以“优惠券领取”为例需要整理的规则大概包括券的总量限制比如活动期间限量5000张领完即止、每人限领张数、领券时间窗口比如每天10点到24点可领、领取条件比如用户等级大于等于2级才能领、领券的入参优惠券ID、用户ID、返回参数成功券码、面额、有效期失败错误码、错误信息等。规则整理越全后续模型的输出就越靠谱。这里分享一个经验不要直接粘贴整个需求文档给模型。大模型上下文有限需求文档里大量的页面布局描述、背景说明会占用上下文窗口反而稀释规则信息的重要性。我一般会写一个“规则抽取”的前置步骤让模型帮我从长需求文档中提取业务规则清单人工审核后再喂给用例生成提示词。用两个阶段来做这件事效果比全量硬塞要好得多。3.2 逐步输出与追问细化当我把准备好的规则和模板一起发给模型后第一次输出的用例通常会有20条上下。大致会分成“领取成功不同时间、不同用户等级”“数量超限、重复领取、时间外领取、等级不足”等场景。这个阶段基本已经比人工裸写快很多了。但真正的价值在于“多轮追问”。第一次输出之后我会根据自己的经验继续向模型提问促使它细化你刚才的用例里没有覆盖“领取时网络超时但券已扣减”这类一致性问题。请在已输出的用例基础上补充关于异常中断场景的用例。请检查上面的用例看看有没有遗漏“同一手机号绑定的多个账号领取”这种业务限制场景。这类追问的效果异常显著。模型的单轮输出能力有限一轮生成不可能覆盖所有思考角度但通过测试人员自己的领域经验持续追加“垂直场景”可以逐步逼近一份高质量用例集。而且这本身就是一个“人机协同”的过程——你不是把工作完全丢给模型而是用模型来加速自己的结构化思考。一个比较常见的误区是很多人拿到第一轮输出看着20条用例就开始用起来了完全不追问。结果上线后总缺那么几个关键场景。我的习惯是至少追问两轮第一轮问异常场景第二轮问边界值。这两轮追问下来用例数量通常从20条扩展到35条左右覆盖质量明显提升。3.3 人工审核提示词解决不了的问题无论提示词写得多好我都不建议完全放弃人工审核。大模型生成用例的定位应该是“替代从0到1的草稿过程”而不是替代测试设计本身。草稿生成后需要人工做三件事。第一确认每条用例和业务规则是否匹配。有时候模型会基于语义进行合理但错误的推导比如它看到“金额范围0.01-10000”可能会想到去测负数和大于10000的值这没错但有的模型也会自动假设“库存不足时点击提交按钮置灰”如果你的产品设计是“按钮仍可点击、点击后弹窗”这种推导就和实际不一致了需要人工修正。第二去重和合并。当规则复杂时模型容易做出重复的用例比如“重复领取优惠券”与“用户已领取但未使用仍可再次领取”可能是同一个场景需要人工判断并合并。第三补业务沉淀。来自项目历史的经典缺陷用例、特殊回归场景这些是模型在上下文里看不到的。我会在人工审核阶段追加这些项目经验形成一个“模型生成人工补充”的混合用例集。这也是所有测试专家正在使用的真实流程大模型承担创意量、广度覆盖人工承担准确性和关键经验。4. 进阶场景白盒用例、接口用例与边界情况4.1 白盒测试用例生成的特殊提示词除了功能测试我在一些重视代码覆盖率的项目里也尝试用大模型生成白盒测试用例。白盒测试用例的本质是“基于代码逻辑设计输入使特定分支、路径被执行并被验证”。这就要求提示词里不只是给需求还要给代码。我使用的白盒用例提示词结构大致是你是一名熟悉Java/Python的白盒测试工程师请根据以下代码片段设计满足分支覆盖的单元测试用例。 代码片段 粘贴代码 输出要求 1. 列出需要覆盖的分支条件 2. 针对每个分支设计测试输入数据与期望输出 3. 指出对应分支的编号如if-else分支1、循环分支2 4. 对于难以构造输入的复杂分支给出Mock建议 5. 输出格式为Markdown表格。在试用这个方案的过程中我踩到的坑是模型对代码行为的理解会受代码风格的强烈影响。变量命名混乱、函数过长、有深层嵌套时模型的路径分析容易出错。所以实际使用时建议先让模型做“代码逻辑摘要”用自然语言把函数功能和分支结构列出来人工确认摘要无误后再基于摘要生成用例。这和“先抽取业务规则再生成功能用例”是一模一样的思路——先确认信息侧对齐再让模型输出产物。另外白盒用例生成时一定要明确覆盖标准。只写“设计测试用例”模型可能会选择最容易的路径来覆盖。我在提示词中会显式加上“需覆盖条件覆盖、路径覆盖各分支”这样的覆盖标准并要求模型在输出里标注“该用例覆盖了哪个分支”方便人工审查覆盖率。4.2 接口测试用例让模型关注入参和出参接口测试用例的生成逻辑和功能用例有明显差异。接口用例的核心对象是“入参校验”、“出参校验”和“业务异常分支”。提示词里需要提供接口定义URL、方法、请求参数、必填/选填、类型、长度限制和接口的业务规则。模板片段参考你是一名接口测试工程师请基于以下接口定义设计接口测试用例。 接口名称领取优惠券接口 请求方式POST /api/v1/coupon/receive 请求参数 - couponIdint必填优惠券ID范围1-9999 - userIdint必填用户ID大于0 - sourcestring选填来源渠道默认值h5枚举h5/app/miniprogram 业务规则 - 优惠券ID不存在时返回错误码40001 - 同一用户对同一张券只能领取一次重复领取返回错误码40002 - 优惠券库存为0时返回错误码40003 - 来源渠道非枚举值时拒绝请求并返回40004 - 正常领取返回券码、面额、有效期限。 输出 按参数校验、业务校验、正常流程三类组织用例每条用例包含用例标题、请求参数、预期返回码、预期响应体、优先级。这种提示词里最关键的是参数边界信息。比如couponId的范围是1-9999那么用例里必须有0、-1、10000、9999、1这些边界值。大模型通常会对边界值敏感的前提是你把边界规则写清楚。如果规则里只写着“int”模型就只会做类型错误这种基础校验。接口用例生成后人工核验的点主要是请求参数是否正确传入了约束条件、预期返回码和实际后端定义是否一致。因为大模型并没有真的看过后端代码它只能按你给的信息推测返回码。返回码定义这块以人工确认为准。4.3 边界值提示词的三种常见写法边界值用例是功能测试中非常有价值的一部分但大模型默认情况下对边界值的推导比较保守。我试过三种写法效果递增第一种笼统要求“请补充边界值用例。”效果一般模型主要给出最大值、最小值、超出最大值三类用例。第二种显式给出边界规则“请针对以下字段生成边界值用例金额字段范围为0.01-10000元类型为decimal(10,2)保留两位小数。”这种写法会促使模型考虑小于最小值的值、等于最小值、略大于最小值比如0.011传入系统被四舍五入还是拒绝、略小于最大值、等于最大值、超过最大值、负数、0、空值等更多角度。第三种在多轮追问中加入“越界推导”指令“请考虑数据类型转换导致的边界情况、并发边界、服务端二次校验与服务端一次校验不一致的边界场景。”这种写法通常能触发模型生成更深入的边界分析例如前端限制金额最大10000但接口层未校验时传10001的结果——这类“前后端校验不一致”的用例对于发现真实缺陷非常有价值。第三种写法是我比较推荐的能力进阶方向。它本质上是让大模型基于“真实系统可能存在的缺陷模式”去推导用例而不是简单围绕字段规则来回测。用这种方式生成出来的边界用例质量已经不输给有3-5年经验的测试人员手写的用例。5. 会踩的坑和解决办法实测总结5.1 提示词太长模型反而“抓不住重点”很多人觉得提示词写越长、信息越全越好但我实测发现当提示词超过一定长度后模型的处理效果会下降。尤其是当你把需求文档、接口文档、历史用例一股脑全部粘贴进去后模型往往迷失在海量信息里生成的用例反而变得通用且发散。解决的办法是分层处理。第一层让模型从你的长文档里提取关键规则清单第二层把规则清单作为上下文信息输入用例生成模板。两层之间加入人工确认环节。这个“抽取-确认-生成”的链路本质上是在给大模型做“信息减负”让它聚焦在最核心的规则上。同时给提示词加一个“结构化分段”也有着明显作用。用【模块名称】【业务规则】【接口与页面】【约束】【输出格式】这样的分隔标签比一大段连写更利于模型理解信息边界。我怀疑这与大模型训练时对结构化文本的敏感度有关不管机制是什么实践效果是稳定的。5.2 大模型编造不存在的功能和字段这件事遇到的概率非常高。比如让模型设计“订单查询功能”的用例它可能会生成“在订单列表页点击‘高级筛选’按钮”——结果系统里压根没有这个按钮。原因是大模型在训练语料里见过太多订单列表页都有高级筛选它按概率联想补全了。应对的方法是双管齐下。第一在提示词里明确写入“操作元素必须来自上下文给出的页面与操作描述”用负面约束抑制编造行为。第二在上下文信息中把系统真实存在的页面、按钮、入口都罗列清楚让模型有据可依。如果可能强烈建议把真实页面的DOM结构或接口路径清单放进上下文告诉模型“这些都是真实存在的元素只能从中选用”。还有一种比较好的做法是把项目里真实存在的基础数据字典、枚举值、状态值作为提示词附录输入给模型。比如“订单状态只能取待支付、已支付、已取消、已退款”这样模型就不太会生成“订单冻结中”这类状态因为它有明确的枚举边界。5.3 输出的用例粒度忽大忽小不同项目中如果提示词不固定模型生成的用例粒度可能不一致。比如同一个登录功能有时候会生成“登录成功”和“登录失败”两条大用例有时候又会生成十几条细颗粒用例。问题不在模型而在于你给的上下文详略程度。如果要稳定粒度需要在提示词里加入“用例拆分粒度”的示例说明。Few-shot示例是控制输出形态最有效的手段之一。我一般在提示词里加一个拆解范例参考以下拆分粒度 用例1输入正确手机号和正确密码点击登录预期跳转首页 用例2输入正确手机号和错误密码点击登录预期提示“密码错误” 用例3不输入手机号点击登录预期手机号字段红色高亮并提示“请输入手机号” 用例4手机号输入为10位点击登录预期提示“手机号格式不正确” 请按同样的粒度设计其他功能的用例。加入示例后模型的用例粒度会紧密跟上示例的颗粒度。这算是提示词工程里的一个通用手法不要用抽象描述告诉模型“粒度要细”直接给它看一个“细粒度”的例子。5.4 多轮对话中的上下文漂移在连续对话里用户第一次提问后模型按照当时的上下文生成了不错的用例紧接着你又改了需求让它基于新需求重新生成却发现模型还在回答旧需求或者把新旧需求的信息混在一起——这种情况非常典型。原因在于大模型的注意力分布在多轮语境中是持续作用的新旧需求信息会产生干扰。应对手法有两个。一是每一轮新的用例生成都“重置上下文”在新一轮提问开头明确写“以下是一份独立的新需求请忽略之前对话中所有与本次需求相关的信息”。这种强制重置在多数模型上都有不错的效果。二是更干脆重新开启一个新的对话会话把标准模板新需求重新粘贴一次。虽然看起来重复劳动多但输出质量的提升值得这点成本。对于把大模型接进内部测试平台的团队我建议在工程层面对每次用例生成请求做“会话隔离”每次用例生成都是一个新的上下文窗口只包含当前需求信息。不要使用长会话串联多个需求这条经验经历了多次实战验证。5.5 提示词的“破甲”与“投毒”问题要谨慎在测试模型能力边界的过程中比如让模型故意违反规则来测试它的识别能力或引入一些对抗性提示词去探测模型安全边界这类操作要非常谨慎。模型的边界测试不等于业务用例生成这部分好的做法是单独做一轮“模型能力测试”不要混在日常用例设计流程里。日常用例设计应当聚焦于模型能力范围内、需求规则可验证的场景避免让模型生成内容越界或违反产品规范。这一点可能和一些希望“榨干模型能力”的测试同学想法不同但我个人的经验是提示词的设计应该“有所为、有所不为”把不正经、对抗性的测试建立在可控、合规、要目标明确的范围内否则模型输出的内容很可能无法归类到正式用例库反而浪费了时间。6. 从提示词到工程化API集成、流式输出与微调6.1 把用例生成能力接进测试平台当提示词方案在一两个项目里跑通后最自然的下一步是把它工程化让团队其他成员不用自己复制粘贴提示词直接在测试平台上点一个按钮就能生成用例。我实践下来的做法是用FastAPI写一个轻量的用例生成服务前端暴露一个表单页后端把模板中的变量模块名称、业务规则、接口定义、约束条件等做成可配置字段调用大模型API返回结果。工程化过程中有一个细节非常重要——模板变量要“槽位化”。不要把整个提示词写死在代码字符串里而是做成模板字符串把业务规则、命名空间、追加约束等用变量占位符标记。团队使用同一套提示词工程代码但每个项目传入自己的上下文这样提示词的迭代可以被复用而不是每次变更都复制粘贴一大堆文本到代码里。工程化后的另一个优势是提示词模板可以做成“版本化”。比如v1模板、v2模板把每次优化记录下来团队可以对比不同时期的模板生成用例的质量进行持续调优。这也才是“提示词总结”最终形态——它不是一篇文档而是一套可以迭代的资产。6.2 流式输出与中断控制的取舍在实际工程接入大模型时会面临LLM接口流式输出的问题。大模型生成用例是一个相对长的文本输出过程如果不做流式渲染用户可能要等十几秒甚至更久体验很差。接SSE流式输出让用户能看到用例逐条生成这类需求非常常见。但流式输出带来的新问题是“中断控制”。用户在生成过程中如果要打断需要在客户端主动Abort请求。这个看似简单的功能真正落地时却需要处理不少边界问题当Abort发生时后端请求是否需要同步取消已生成的半截用例要不要保留重新请求时是接着上一轮生成还是重新开始我的建议是对于用例生成这种“长文本结构化输出”场景不上流式采用同步请求加载态反而更稳妥。因为用例生成的结果本身需要格式完整、前后对照流式输出中间态的格式不稳定前端处理起来比较麻烦。如果不是产品体验上有硬要求我建议优先使用同步接口。如果确实需要流式我建议前端在展示时不要逐字使用Markdown渲染而是缓冲完整段落后再渲染表格块避免用户在流式过程中看到半截表格影响体验。这个细节在当时调试时绕了不少弯路分享出来帮助大家避坑。6.3 关于大模型微调什么情况下值得做聊大模型生成用例很多人会问是不是应该微调一个专属模型效果更好我直接说结论对于绝大多数测试团队微调的性价比远低于提示词工程。微调大模型需要高质量的数据集、标注成本、GPU训练资源和持续的运维投入而且微调后的模型仍然存在通用能力退化的风险。哪些情况下微调才值得考虑一个前提条件是你的团队有大量成体系的历史用例数据比如几万条经过评审的结构化用例同时你们的用例风格非常统一、有强烈的公司特色比如特定字段写法、特定编号规则。这种情况下用LoRA等参数高效微调技术做一个轻量的专属模型也许可以把用例格式规范性和公司特有规则遵守率提高几个百分点。但对大多数团队用好提示词人工审核链路已经能达到85%以上的可用率这已经足够释放测试人员的大部分重复劳动了。从我个人经验看一个更符合实际的路线是先用提示词工程跑通流程、积累团队方法论当团队的用例生成需求真正稳定下来、样例数据足够并且确实卡在格式或规则一致性上时再考虑微调。不要一上来就奔着微调去那是为问题寻找豪华解法往往得不偿失。说起来现在我自己搭的那套“规则抽取-用例生成-追问细化”流程已经在好几个不同业务线的项目里复用了。每次新项目启动我只需要花十几分钟更新上下文业务规则就能快速获得一份可评审的用例初稿。这也是提示词总结最终带给我的核心价值——不是某个魔法提示词而是一套可以复制的思维框架它把大模型从“玩具”变成了测试工作流里一个真正靠谱的协作对象。如果你也在用大模型辅助测试设计我的建议是不要追求一步到位也从“一句话写用例”开始然后逐步加结构、加规则、加约束在一次次实测中迭代出自己的提示词方案。当你把这套流程跑顺之后你再回头看会发现最花时间的反而不是调提示词而是把业务规则整理清楚——但这件事本来就是测试人员最应该做好的事。