说实话，我在刚接触“提示词”这个词的时候，脑子里第一反应是玄学。好像写几句话丢给AI，它就能吐出漂亮的测试用例，这里面到底有多少确定性，我心里没底。后来项目里真刀真枪用了几个月，踩了坑也尝到了甜头，才慢慢明白：软件测试用例提示词不是什么咒语，它更像是一份写给新同事的测试任务说明书，只不过这位“新同事”理解力很强、记忆力很差、还特别喜欢自由发挥。你怎么说，它就怎么做，说漏了的地方它绝不会替你补上。
这一章我想把自己的认知掰开揉碎聊一聊。提示词能干什么、不能干什么，它和测试需求、用例要素之间到底怎么对应，一条高质量的提示词应该长什么样，以及大家最容易掉进去的几个坑。这些想清楚了，后面写模板、做工程化落地才有根。
1.1 软件测试用例提示词的定义、价值与适用边界
我理解的软件测试用例提示词，是一段用来指导大模型生成或补全测试用例的结构化自然语言指令。它通常包含角色、背景、输入材料、约束条件和输出格式。它不负责执行测试，也不负责判断业务对错，它干的是“把测试设计意图翻译成可读用例草稿”这件事。你可以把它想成一个测试设计助理，你给需求，它给初稿，你再审再改。
它的价值在重复劳动扎堆的地方特别明显。登录、权限、字段校验这类模式化场景，人工写十条用例可能半小时，提示词调好之后几秒钟就能出一版，测试工程师的时间腾出来去琢磨那些真正复杂的业务链路。团队里新人多、业务迭代快的时候，提示词还能起到“知识固化”的作用，把老测试的经验写成约束条件沉在模板里，新人拿来就能用。
适用边界这块我得说清楚。提示词擅长的是“已知规则的组合展开”，比如根据字段类型生成边界值、根据状态机推导异常流转。它不擅长的是判断“这个需求本身合理不合理”、评估“这个缺陷到底算不算阻塞”。业务领域知识、风险优先级、上线决策这些事，还得靠人。我见过有人把提示词当成万能钥匙，结果生成一堆看起来齐全、细看全是废话的用例，评审的时候被怼得说不出话。工具是好工具，用错地方就是负担。
1.2 提示词与测试需求、用例要素之间的映射关系
这一块是我觉得最值得反复琢磨的部分。测试需求讲的是“要验证什么”，用例要素讲的是“怎么写清楚”，提示词夹在中间，扮演的是翻译器和约束器。需求里一句“用户登录失败要有提示”，提示词要把它拆成输入条件、操作步骤、预期结果的骨架，还得告诉模型“提示文案要跟需求文档一致，不要自己编”。
映射关系可以这么看：需求里的业务规则对应提示词里的“约束条件”，需求里的功能描述对应提示词里的“任务目标”，需求里的验收标准对应提示词里的“输出校验点”。用例要素里的前置条件、测试数据、步骤、预期结果，在提示词里则体现为输出格式的结构化字段。少了任何一环，生成出来的东西就容易偏。
我自己习惯在写提示词之前先把需求做一次“要素标注”。哪些是硬性规则、哪些是可枚举的取值、哪些是依赖外部系统的前置状态，用不同颜色标出来，再对应写进提示词。这个过程多花十分钟，后面省下的返工时间远不止十分钟。映射做得越细，模型自由发挥的空间就越小，产出就越贴近你想要的样子。
1.3 高质量提示词的设计原则：角色、上下文、约束、示例与输出规范
这五个要素我踩过坑之后才真正重视起来。角色设定不是走形式，跟模型说“你是一名资深测试工程师”和什么都不说，产出的语气和细致程度确实有差别。上下文是给模型铺地面的，把需求背景、系统模块、已有用例风格放进去，它才不会写出牛头不对马嘴的东西。约束是刹车，明确告诉它“不要生成性能测试用例”“测试数据必须用真实业务字段格式”。
示例这一项很多人省略，我觉得挺可惜。给一两条符合你团队风格的用例样例，模型模仿能力很强，输出格式和颗粒度会明显靠拢。输出规范就更不用说了，不写清楚字段名、层级、空值怎么处理，模型就会按自己的理解给一套，后面解析的时候全是麻烦。我一般的做法是把输出格式用JSON示例直接贴在提示词末尾，比用文字描述一百遍都管用。
这五点凑齐了，提示词才算有个样子。我试过只写目标和约束、省掉示例和输出规范的版本，生成结果格式五花八门，整理花的时间比手写还多。后来老老实实把五要素补齐，一次生成基本能直接用。教训就是这么直白。
1.4 常见误区与关键词需求拆解：软件测试用例AI提示词模板的定位
误区我总结了几条自己中过招的。一条是“提示词越长越好”，堆了一堆形容词和废话，模型反而抓不住重点，核心约束被淹没了。另一条是“一次提示覆盖所有场景”，想让一段提示词同时生成功能、接口、兼容性用例，结果哪类都不够深。还有一条是“生成完就直接入库”，跳过了人工评审，后面发现重复用例、无效预期结果一堆，清理成本很高。
关键词需求拆解这个说法，我的理解是把用户搜索或团队内部沟通时用的关键词，还原成提示词能消化的具体指令。“登录测试用例”这样的关键词背后，其实藏着正常登录、密码错误、账号锁定、验证码失效等一堆细分意图，提示词模板的定位就是把这些意图显性化、结构化，变成可复用的指令骨架。模板不是让人偷懒的拐杖，它是一份经过验证的配方，保证每次做菜的味道不会差太远。
我认为模板的定位要摆正：它是起点，不是终点。拿模板开个头，再根据具体项目补上下文、调约束，才是正常的使用姿势。指望一套模板打遍天下，跟指望一份用例模板覆盖所有系统一样不现实。认清这一点，后面的模板设计和版本管理才不会走偏。
第1章聊的是认知层面的东西，这一章我想把袖子撸起来，讲讲模板到底长什么样、怎么拼装。我电脑里有个文件夹叫“prompt-lab”，乱七八糟存了四十多个版本，有的是半夜改出来的，有的是评审被骂之后重写的。翻回去看那些早期版本，我自己都嫌弃——一堆形容词堆在那儿，核心约束反而被埋了。模板这个东西，就是把这些乱七八糟的尝试沉淀成一套能反复用的骨架。
2.1 通用测试用例提示词模板的组成：目标、输入、范围、格式与验收标准
我现在的通用模板基本是五块结构，顺序固定下来之后写起来顺手很多。目标放在最前面，用一两句话说清楚这次要让模型干什么，比如“为登录模块生成功能测试用例，覆盖正常登录与密码错误两类场景”。这句话不能含糊，说成“帮我测一下登录”模型就开始自由发挥了。输入材料紧跟着目标，把需求片段、字段说明、已有用例风格样例贴进去，用分隔符隔开，模型对分隔符的敏感度比想象中高。
范围这一块是我踩坑之后加进来的。早期我不写范围，让模型生成“用户注册”的用例，它把短信验证码、邮箱激活、第三方授权全给我铺了一遍，看着挺全，实际项目里压根没接第三方。现在我明确写“本次范围仅限手机号注册，不涉及邮箱和第三方登录”，输出的边界一下就收窄了。格式部分我习惯直接贴一个JSON示例，比用文字描述字段结构可靠得多，模型照着示例的壳子往里填内容，省掉大量格式纠正的功夫。
验收标准这块很多人会忽略。我在模板末尾会写几条自查项，比如“每条用例必须有明确的前置条件”“预期结果不得出现‘正常显示’这类模糊表述”“步骤数量控制在三到八步之间”。这些标准模型不一定条条遵守，但写进去之后命中率明显上升。我甚至试过把验收标准写成让模型自己逐条核对的形式，效果又比单纯罗列好一截。
这五块拼起来，模板就有了基本形状。我建议别一上来就追求完美，先搭起来跑几条用例看看，缺什么补什么。我们组最开始那版模板只有目标和输入两块，生成出来的东西一塌糊涂，后来一块一块加，加到现在这个版本，中间改了十几轮。
2.2 面向不同测试类型的模板扩展：功能、接口、UI、兼容性、性能与安全
通用模板是底子，真正干活的时候得往上加扩展块。功能测试的扩展块主要补业务规则和状态流转，我会把状态机的关键节点列进去，让模型照着推导异常流转路径。接口测试的扩展块完全不一样，得写清楚协议类型、请求方法、字段类型约束、鉴权方式、状态码约定，这些信息缺一项，生成的用例就没法执行。
拿接口测试举例，我在扩展块里会固定放三样东西：字段清单（名称、类型、是否必填、取值范围）、错误码映射表、依赖的上下游服务说明。有了这三样，模型生成的用例才谈得上“可执行”。之前有次偷懒没放错误码映射，模型自己编了一套403、404的含义，跟我们的接口文档对不上，评审的时候被开发同学当场指出来，我脸都红了。
UI测试的扩展块重点在元素定位和交互状态，我会把页面结构描述、关键控件的可交互状态、常见操作序列放进去。兼容性测试的扩展块是一张环境矩阵，浏览器、系统版本、分辨率、网络条件怎么组合，得在模板里说清楚组合规则，不然模型会把所有组合穷举一遍，生成几千条用例，看都没法看。
性能和安全这两类的扩展块要求最高。性能得给出指标阈值、并发模型、压测场景描述，安全得给出攻击面清单和防护预期。我一般会单独建模板文件，不跟通用模板混在一起。一个模板专注一类测试，扩展块别贪多，塞太满模型注意力就散了。这条经验是实打实换来的。
2.3 使用json_object设计结构化用例输出：字段、层级、枚举与约束
输出格式这件事，我从早期的纯文本表格一路换到JSON，中间没少折腾。纯文本表格的问题在于解析太脆，模型稍微改一下列的顺序或者多加一列，脚本就崩了。换成JSON之后，解析稳定性上了一个台阶，配合 json_object 输出模式，拿到的就是标准结构，代码里直接取值就行。
字段设计我摸索出一套自己的习惯。用例对象里必带这几个：用例编号、标题、所属模块、用例类型、优先级、前置条件、测试数据、步骤数组、预期结果、备注。步骤我特意设计成数组，每个元素包含操作描述和该步骤的预期。这个层级设计让用例既能整体展示，也能按步骤做自动化映射。早期我把步骤写成一个大字符串，解析的时候还得自己按序号切分，麻烦得要命。
枚举值这块必须提前定死。优先级我限定P0到P3四档，用例类型限定为功能、接口、UI、兼容性、性能、安全六类，模块名限定在项目已有的模块清单里。不限定枚举，模型就爱造词，什么“P1-高”“关键级”“功能类测试”，五花八门。有了枚举约束，输出清洗的工作量能降一大半。
约束条件得写细。哪些字段必填、字符串是否允许为空、步骤数组的元素数量范围、预期结果的最短长度，这些都用自然语言在模板里说明白。我还会在JSON示例里用注释标出约束，有些模型对注释的遵循度不错。有个细节值得提，让模型输出标准JSON时一定要强调“不要包含markdown代码块标记”，不然拿到的字符串前面挂着三个反引号，解析前还得先剥壳。
2.4 模板复用、参数化与版本管理：提升生成一致性与可维护性
模板写多了之后我发现一个问题，同一个功能测试模板，换个项目就得改一堆硬编码的地方，改漏一处输出就跑偏。后来我开始做参数化，把项目名、模块名、字段规则、错误码表这些变化的部分抽成占位符，用双花括号包起来，调用的时候统一替换。这一改，一个模板能覆盖好几个项目，维护成本降下来了。
参数化还有个好处是降低误改风险。以前改模板经常改着改着把别的项目要用的部分也动了，参数化之后核心骨架稳定，变的部分都在占位符里，改起来心里有数。我习惯在模板头部维护一张参数表，说明每个占位符的含义、取值范围和示例值，新同事接手的时候不至于一脸茫然。
版本管理这件事我是吃过亏才重视的。早期模板就一个txt文件，改完覆盖，出了问题想回退都找不到旧版本。现在我们组的提示词模板全部放git仓库，每次改动写清楚变更原因、影响的测试类型、验证结果。版本号我用了简单的语义化规则，大版本改结构，小版本调措辞和示例。
模板复用我还做了一层分类，按测试类型分目录，目录里再按业务域放子模板。调用的时候先取通用骨架，再叠加业务扩展块，像搭积木一样拼。拼装逻辑写成文档放在仓库首页，谁都能看懂怎么组合。这套东西听起来有点重，实际用起来比每次从零写提示词省太多时间，生成结果的一致性也稳得多。团队里新来的同学照着文档拼两天就能上手，比我当年瞎摸索强太多了。
说实话，写完第2章那些模板设计之后我一度觉得自己已经摸到门道了。模板搭好、字段定死、json_object也跑通了，看起来挺像回事。真拿几个实际需求扔进去跑，输出质量跟坐过山车一样——同一个模板，换个需求文档，出来的用例水平能差出两条街。问题出在哪儿？我花了两周才想明白：模板是骨架，但骨架立在那儿不会自己动，真正让ChatGPT干活干到位的，是调用它之前那一整套工程化的铺垫动作。这章就聊这些动作。
3.1 ChatGPT生成软件测试用例提示词的角色设定与任务拆解
我一开始不太在意角色设定，觉得“你是一个资深测试工程师”这种话纯属仪式感。后来有次对比测试打脸了：同样一段需求，不设角色的输出泛泛而谈，设了“十年经验的金融系统测试专家”之后，模型开始主动往资金安全、幂等性这些方向靠。角色不是玄学，它实实在在地收窄了模型的注意力分布。我现在会写得具体一点，比如“你是一位有支付系统背景的高级测试工程师，擅长从需求文本中推导边界条件和异常路径”，比泛泛的“资深测试”管用。
任务拆解这件事更关键。早期我习惯一口气把需求丢过去让它生成全部用例，结果往往是前面几条还行，后面开始注水，或者模块之间互相串。现在我基本拆三步走：第一步让模型先梳理需求里的功能点和约束条件，输出一份功能清单；第二步基于清单逐模块生成用例，每个模块单开一轮对话；第三步再单独让它做覆盖度自查。这样拆开之后，每轮的上下文压力小，输出质量稳定得多。有个细节，拆步骤时我会在提示词里明确写“这一步只做功能点提取，不要生成用例”，不写这句话模型老忍不住往下跑。
角色和拆解这两件事配合起来用效果最好。我现在的习惯是在对话开头把角色立住，然后第一句话就限定任务边界，中间轮次只做上下文延续，不重复角色描述。有些同行喜欢每轮都贴一遍人设，我试过，反而让模型在长对话里变得啰嗦，输出里开始出现“作为资深测试工程师”这种废话前缀。
3.2 需求文档、用户故事与接口说明的上下文组织方式
上下文怎么放，是我踩坑最多的环节。最开始我把需求文档整段复制进去，几千字扔过去，模型的表现是“什么都提到了，什么都没说透”。后来我改成只贴核心段落，但矫枉过正，有一次把支付流程的关键约束条件给截掉了，生成的用例全是happy path，漏了金额上限校验。这个度的把握，说白了就是得判断哪些信息是“生成用例必需的”，哪些是“背景参考”。
我现在的做法是分层组织。第一层放需求摘要，用自己的话把业务目标、核心流程、关键规则提炼成三到五条；第二层放用户故事，按“作为什么角色、我要什么、以便达成什么”的格式贴两三条典型故事，模型对用户故事的理解力比干巴巴的需求文档强不少；第三层才是接口说明或字段定义，这一层我会做成表格贴进去，字段名、类型、是否必填、取值范围列清楚。三层之间用分隔线隔开，每层前面加一句说明“以下是需求摘要”“以下是用户故事”。
用户故事这个载体特别好用，尤其是它天然带角色和目的，模型拿到之后推导场景的角度会丰富一些。接口说明我一般只放当前模块相关的部分，整份API文档丢过去反而稀释注意力。有个经验，接口说明里错误码那部分一定得带上，缺了它模型就开始编错误场景，编得还挺像那么回事，一评审全是错的。上个月有个同事没放错误码表，生成的用例里出现了“返回409表示用户不存在”，我们接口文档里409是并发冲突，被开发指着屏幕笑了半天。
3.3 覆盖维度扩展：正常流、边界值、异常流、权限与数据组合
覆盖维度这件事，如果不主动引导，模型默认偏科得厉害。正常流它写得最顺，边界值偶尔能想到几个，异常流和权限组合基本靠运气。我后来在提示词里专门加了一段覆盖维度清单，把这几类列出来，要求它逐类覆盖并在输出里标注维度类型。
正常流不用多说，把主流程描述清楚就行。边界值这块我摸索出一个技巧：与其让模型自己找边界，不如在上下文里直接把字段的取值范围和约束条件列出来，然后明确要求“针对每个有范围约束的字段，生成上边界、下边界、越界三类用例”。这么写之后边界覆盖率肉眼可见地往上走。异常流我一般会提示它从三个角度想：输入异常、状态异常、依赖异常。状态异常特别容易漏，比如订单已取消状态下再发起支付，这种场景不主动提模型想不起来。
权限和数据组合是最费劲的部分。权限维度我会把角色清单和权限矩阵放进去，让它按角色交叉生成。数据组合复杂的时候，我会先让模型列出影响用例的关键数据因子，再基于因子做组合。这块我承认目前做得还不够体系化，pairwise那套东西我试过让模型直接做，效果一般，它容易在组合数量上失控。现在的折中办法是限定组合数量上限，比如“数据组合维度不超过三种，每种不超过四个取值”，输出可控一些。这段经验比较零碎，但都是实打实跑出来的。
3.4 少样本示例、分步生成与结果校验的提示词组合策略
少样本示例是我认为性价比最高的一个手段。给两到三条高质量的用例样例，模型输出的风格、粒度、措辞都会往样例上靠。样例的选择有讲究，别挑最复杂的，挑一条正常流、一条异常流、一条边界用例，覆盖三种典型形态。样例里的字段填写要完整规范，模型会照着抄格式。我有时候会故意在样例里放一条“反面教材”，标注“此用例预期结果模糊，不可接受”，模型看到之后同类问题少很多。
分步生成我在3.1提过任务拆解，这里想说的是生成阶段的分步。一个模块的用例量大时，我会让它先出用例标题清单，我快速扫一眼有没有明显遗漏或重复，确认之后再让它逐条展开成完整用例。这个“先列纲再展开”的节奏，比一次性生成全部内容的可控性高出一大截。标题清单这一步还能起到去重的作用，模型自己看到清单之后展开时会主动避免重复。
结果校验环节我一般做两遍。第一遍是模型自检，在提示词末尾加一段“生成完成后请逐条检查：前置条件是否完整、预期结果是否可验证、步骤是否超过八步”，让它自己过一遍。第二遍是我这边的规则校验，写过一个小脚本检查必填字段、枚举值合法性、步骤数量区间这些硬性指标。模型自检能抓住语义层面的问题，脚本校验兜住格式层面的问题，两层配合下来返工率降了不少。有次模型自检时主动标注“第7条用例的预期结果可能不够明确”，我一看确实模糊，这种自我纠错能力在加了校验指令之后才明显起来。
3.5 从自然语言到json_object输出的解析、校验与重试机制
json_object输出这块，我在第2章讲过字段设计，这节聊解析和重试的工程细节。理想情况是模型直接吐标准JSON，实际跑起来你会发现各种意外：偶尔前面带一段“好的，以下是用例”的寒暄，偶尔某个字段该是数组的地方给了字符串，偶尔枚举值冒出来一个“P0-紧急”这种自创档位。解析代码里如果不做防御，一个字段异常整个流程就挂。
我的解析流程现在是三段式。第一段做预处理，剥掉可能存在的markdown代码块标记和前置说明文字，用正则找第一个左花括号到最后一个右花括号之间的内容。第二段做结构校验，检查必填字段是否存在、类型是否正确、枚举值是否在允许清单内，校验不通过的字段打标记但不直接丢弃。第三段做自动修复，能修的就修，比如字符串转数组、枚举值模糊匹配到最近的标准值，修不了的才进重试队列。
重试机制我设计得比较简单但管用。第一次重试是把校验报错信息附在提示词后面，让模型“根据以下错误修正输出”，这种方式修好的比例挺高。第二次重试就降级处理，换一个更严格的提示词模板，把json示例贴得更完整，约束写得更死。两次还不行的话，我会把这条用例退回人工处理，同时记录下来作为模板优化的输入。重试次数我控制在两次，再多就是在烧token了。这套机制跑了一个多月，自动修复加两次重试能兜住九成以上的异常输出，剩下那一成基本都指向模板本身的缺陷，修模板比修输出划算。
整套工程化实践跑下来，我最大的感受是：ChatGPT生成测试用例这件事，门槛不在“会不会写提示词”，而在“有没有把提示词当成一个需要工程化管理的生产环节”。角色设定、上下文组织、覆盖引导、少样本、校验重试，每一个环节单独看都不复杂，串成流水线之后输出质量的稳定性才真正提上来。
前三个月我一直在埋头调提示词，追求的是“这次输出比上次好”。某天领导问了我一句：你怎么证明现在这套提示词比上个月强？我愣了半天，翻出两个版本的输出对比给他看，他扫了两眼说“感觉是好了点，但好多少说不清”。那次对话之后我才意识到，光靠感觉调提示词，跟蒙着眼睛开车差不多。这章聊聊评估、迭代和真正把提示词用起来的过程。
4.1 软件测试用例提示词的效果评估指标：覆盖率、有效性、可执行性与去重率
覆盖率这个指标我一开始理解得太窄，只盯着功能点有没有被覆盖到。跑了一段时间发现一个问题：功能覆盖看着挺全，打开用例列表一翻，某几个模块堆了几十条，另外几个模块零星两三条。这种“总量达标、分布失衡”的情况光看一个总数根本发现不了。后来我改成按模块维度拆开算覆盖率，每个模块单独看正常流、边界、异常各占多少。这下问题藏不住了，之前有个订单模块看着覆盖率85%，拆开一看异常流只有一条，这哪够用。
有效性和可执行性这两个指标我是放在一起看的。有效性说白了就是生成的用例有没有测到点子上，我自己的判定标准很土：拿给对应模块的开发看一眼，他会不会说“这条用例我一看就知道你在测什么”。可执行性更偏操作层面，前置条件写没写清楚、测试数据能不能造出来、预期结果能不能逐条验证。之前有批用例前置条件写着“系统处于正常状态”，我评审的时候直接打回去，什么叫正常状态，登录了没有、数据初始化了没有，这种模糊表述到执行阶段就是灾难。
去重率是让我最头疼的指标。模型生成用例有个毛病，它喜欢换着说法重复同一条用例，尤其是异常流，把“用户名为空”和“用户名未填写”当成两条输出，看起来数量上去了，实际水分很大。我试过两种去重方式：一种是生成后基于标题和步骤做相似度计算，阈值设太高会误杀，设太低又漏网；另一种是在提示词里直接要求“每个场景只输出一条用例，不同场景之间测试目的不得重复”。两种结合用效果还行，提示词层面的约束能减少源头上的重复，后置的相似度过滤兜底。
这四个指标我现在的用法是每周跑一次固定测试集，生成结果按指标打分，记在一张表里。数据本身不复杂，关键是有了横向对比的基准。上个月有一次我把角色描述从“资深测试工程师”改成具体领域方向，去重率直接从72%跳到85%，覆盖率没怎么动。要是没有这张表，我根本不会注意到这个变化。
4.2 人工评审与自动化校验结合的提示词迭代闭环
纯靠自动化校验有个天花板，它能查字段完整性和格式合法性，查不了“这条用例值不值得写”。纯靠人工评审又扛不住量，一个中等模块跑一次生成几十条用例，逐条看下来一下午就没了。我现在走的路线是自动化先过一遍筛掉明显废的，人工只看过了筛的那部分。
自动化校验脚本我做得很轻，三件事：必填字段缺没缺、枚举值在不在白名单、步骤数量和预期结果条数在不在合理区间。这三项一跑基本能滤掉两三成的低质输出，剩下的交给人工。人工评审我拉了一个三人小组，每人负责自己熟悉的业务模块，评审的时候只关注三件事：测试目的是否清晰、前置条件和步骤能不能直接照着执行、预期结果能不能一眼判断通过与否。评审结果不打分，直接标“可用”“需修改”“废弃”三档。
迭代闭环的关键在评审结果怎么回流到提示词。我最初的做法是看到问题用例就手动改提示词，改完再跑一轮看看问题少了没有。这种做法太依赖个人记忆，改了什么、为什么改、效果如何，过两周全忘了。现在我会在评审表里加一列“问题归因”，分几类：角色描述不到位、上下文缺失、覆盖维度没引导、输出格式约束不够。每周汇总一次归因分布，哪类问题占比最高就先改对应的提示词段落。改完之后用同一批测试用例跑前后对比，有量化结果才决定是保留还是回滚。
这个闭环跑顺了之后有个意外收获：有些问题反复出现在不同模块的评审里，说明不是某一次生成的偶然偏差，而是提示词结构性的缺陷。比如连续三周都有评审人反馈“边界值用例只测了数字类型字段，字符串长度和日期范围从来不管”，我回去翻了提示词，发现边界引导那段只举了数值型字段的例子，模型自然就照着学了。补上字符串和日期类型的示例之后，这类反馈直接消失了。这种跨周期的规律，单看一次生成结果根本发现不了。
4.3 典型应用场景与工作流集成：测试设计、评审、回归与知识沉淀
把提示词真正嵌进日常工作流，比调提示词本身难多了。我见过不少团队提示词写得挺好，用起来还是靠人想起来才跑一次，跑完结果往文档里一贴就完事。这种用法发挥不出持续价值。我们现在的做法是把它挂在需求评审之后、用例评审之前这个节点上，需求定稿了先跑一轮生成，生成结果作为用例评审的输入材料。
测试设计阶段是主战场。需求评审通过后，负责该模块的测试同学把需求摘要和接口说明整理好，套模板跑生成，半小时能出一版初稿。初稿不是直接用的，是拿来做查漏补缺的。人的思维有惯性，写用例的时候容易顺着主流程往下走，异常和边界靠经验补。模型的好处是它没有惯性，你引导它覆盖哪几个维度它就往哪几个维度铺，虽然质量参差不齐，但拿来做覆盖面自查很管用。我现在的习惯是自己先写核心用例，再拿模型输出做对照，漏了的补上，重复的忽略。
回归测试场景我们用得比较轻。版本迭代的时候，改动模块的影响范围分析完之后，把改动点描述扔给模型，让它针对改动点生成一轮回归用例建议，重点是关联影响和状态迁移这类容易漏的地方。生成结果不直接进用例库，作为回归范围确认的参考清单。有个版本改了优惠券叠加规则，模型提示了“已过期优惠券参与叠加”这个场景，我们之前确实没考虑到，后来补了一条用例。这种提示价值比生成本身更实在。
知识沉淀这块我做得比较晚，但觉得最值得投入。每次评审中标记为“需修改”或“废弃”的用例，我会挑典型的存到一个案例库里，标注问题类型和修改后的版本。这些案例有两个用途：一是作为少样本示例的候选素材，二是新人培训的时候拿来当反面教材。运行几个月下来攒了上百条案例，新同事照着案例库过一遍，对“什么叫合格用例”的理解能快不少。提示词模板本身也在迭代，每个版本改了什么、为什么改、效果变化，我都记在一个简单的表格里，版本号、日期、改动点、评估结果四列。这事听着枯燥，但回头查问题的时候特别好使，上个月有个模块输出质量突然下降，我翻记录发现两周前改过覆盖维度那段，回滚之后恢复正常。
再说说风险控制和数据安全。我们最开始跑生成的时候有人直接把生产环境的接口文档贴上去了，里面有内部IP和部分未脱敏的字段说明。发现之后我定了几条规矩：贴进提示词的需求材料必须经过脱敏处理，接口地址统一替换成占位符，字段示例数据不能用真实用户信息。团队层面还建了一个提示词资产库，把验证有效的模板、少样本示例、校验脚本都放进去统一管理，版本变更走简单的评审流程。这事一开始大家嫌麻烦，出过一次小事故之后都老实了。
回头看这几个月，提示词从“我电脑里的一个txt文件”变成了团队共用的生产工具，最大的变化不在技术层面，在协作习惯上。评估指标让改进有了方向，评审闭环让问题有了出口，工作流集成让工具有了固定位置。这几件事单拎出来都不新鲜，串在一起才让提示词从“能用”变成“敢用”。
