做了这么多年测试，拿到需求文档的第一反应永远不是“这个功能怎么验”，而是“用例怎么写得又快又不漏”。尤其碰上迭代节奏快的项目，产品原型刚出，开发排期已经定死，用例评审时间被压缩到可怜的两三天。这时候，靠人肉硬写一份覆盖全的测试用例非常痛苦，漏场景、漏边界几乎是必然的。后来我开始尝试把大模型拉进用例设计这个环节，用提示词工程约束它按测试人员的思路去拆解需求、补充场景。经过几个项目的实弹演练，我总结出一套相对稳定、可复用的“大模型生成用例提示词方案”，这篇文章就是把这段实战过程里最有价值的部分整理出来——包括提示词框架、具体模板、踩过的坑和把它工程化接入测试平台的思路。
适合谁来参考？如果你是在用大模型辅助写功能用例、接口用例、白盒用例，或者想把这套能力接进公司的测试管理平台、让团队共享用例生成能力，那这篇文章正好对路。下面的内容不会讲太多模型原理，全部围绕“怎么写提示词、怎么约束输出、怎么落地”这三个实际问题来展开。
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 请求参数： - couponId（int，必填，优惠券ID，范围1-9999） - userId（int，必填，用户ID，大于0） - source（string，选填，来源渠道，默认值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%以上的可用率，这已经足够释放测试人员的大部分重复劳动了。
从我个人经验看，一个更符合实际的路线是：先用提示词工程跑通流程、积累团队方法论，当团队的用例生成需求真正稳定下来、样例数据足够并且确实卡在格式或规则一致性上时，再考虑微调。不要一上来就奔着微调去，那是为问题寻找豪华解法，往往得不偿失。
说起来，现在我自己搭的那套“规则抽取-用例生成-追问细化”流程，已经在好几个不同业务线的项目里复用了。每次新项目启动，我只需要花十几分钟更新上下文业务规则，就能快速获得一份可评审的用例初稿。这也是提示词总结最终带给我的核心价值——不是某个魔法提示词，而是一套可以复制的思维框架，它把大模型从“玩具”变成了测试工作流里一个真正靠谱的协作对象。
如果你也在用大模型辅助测试设计，我的建议是：不要追求一步到位，也从“一句话写用例”开始，然后逐步加结构、加规则、加约束，在一次次实测中迭代出自己的提示词方案。当你把这套流程跑顺之后，你再回头看会发现，最花时间的反而不是调提示词，而是把业务规则整理清楚——但这件事，本来就是测试人员最应该做好的事。
