企业官网建设流程全解析

需求评审一结束，测试团队最重的活往往不是执行，而是把PRD里的一堆业务描述转成可执行的接口用例。我这边团队之前一直靠人肉完成，直到我们把AI接进这条链路，才真正感觉到自动化测试流程里那块“动手不动脑”的环节可以被省掉。今天想聊的不是PPT里的AI自动化测试概念，而是我们实际跑通的一条路线：从需求文档输入，经过结构化抽取、用例生成、规则校验三层处理，最终产出可直接入库的接口用例。这中间有真实收益，也有不少坑，我把能复用的细节尽量都写出来。

1. 先想清楚：AI在“需求文档到接口用例”这条链路上到底扮演谁

1.1 绝大多数团队卡在“预期太高”

一聊到AI自动化测试，很多人第一反应是：AI读PRD、AI出用例、AI执行用例、AI出报告，整个测试环节全自动。我跟几个想引入AI的团队交流过，大家最初的预期基本都这样。但真跑过一轮之后你会发现，如果哪个方案商跟你承诺“全自动”，那大概率没跑过真实项目。

原因不复杂：PRD写得好不好、字段全不全、接口文档准不准，直接决定了AI的上限。AI不是神，它是在你给的材料基础上做理解和转换。材料本身是残缺的，那输出一定有大量需要人工修补的地方。

我后来和团队把预期调整成一句话：AI不是替代测试，而是替代从需求到用例这条链路上最耗时的“转译”环节。读PRD、总结业务规则、把规则映射成接口参数，这四件事里有两件半是AI能干的，剩下那半件才是真正的测试设计。

1.2 把链路拆开，才知道该在哪个环节加AI

我习惯先把一条人肉链路拆成粒度更小的步骤：

1. 通读PRD，找到业务规则和边界条件。
2. 把规则转成测试场景，比如正常、边界、异常。
3. 把场景映射到接口参数，比如路径、方法、请求体字段。
4. 为每条场景写前置条件和预期结果。
5. 人工查漏，看有没有规则被漏掉。

我们用一个中等复杂度的注册模块做过一次粗略计时：人工从PRD到产出50条接口用例大约需要4小时，其中“找规则”和“转接口参数”两个步骤占掉2.5小时以上。剩下的时间才是测试设计本身。

这样拆完，加AI的点就很明确了：让AI做规则抽取、场景草拟、参数转换，人工做规则确认、用例审核、查漏补缺。这里我画了一条人机分工的边界，实际用起来比较舒服：

1.3 我给AI的定位：一个阅读能力强但不懂业务的实习生

如果一个实习生刚入职，你让他读PRD出用例，他会怎么做？他会读得很快，能提炼出一堆字面上的规则，也能按模板把用例写出来，但遇到“这里产品其实想表达的是XXX”这种潜台词，他就抓瞎了。AI现在的状态就是这个。

所以我在团队里反复强调一个原则：AI出第一稿，人做最后一公里。任何没有被校验过的AI用例，都不能直接进用例库。这个定位看起来保守，但恰恰是它能稳定落地到项目里的原因。

2. 需求文档进模型之前，先把它拆成一张“业务规则清单”

2.1 为什么不能把PRD直接扔给模型

很多人实验的时候喜欢直接把整篇PRD丢给模型，然后问一句“请帮我生成测试用例”。这么玩的产出基本不能直接用，因为PRD的噪声太多了：

• 里面有一大段用户流程图文字描述，跟接口测试没关系；
• 有原型图的说明，模型会把视觉元素当成接口字段；
• 有历史遗留的“本版本暂不支持”这类描述，模型可能把废弃逻辑也生成用例；
• 真正关键的规则往往只有几句话，但它们淹没在大量描述文字中。

举个例子，PRD里写了一句：“验证码5分钟内有效，过期后需重新获取”。这句话夹在第三段里的不起眼位置。直接把PRD扔给模型生成用例，它很容易漏掉这条边界规则；但如果我们先让AI把规则清单抽出来，这条规则就会出现在结构化清单里，后面逐条设计用例时不可能漏。

2.2 第一层抽取：让AI输出结构化规则JSON

我们第一步做的不是生成用例，而是让AI把PRD里的内容抽成一份“业务规则清单”。这个清单的结构要固定，否则后面没法用。我要求AI输出的JSON里至少包含三块：业务规则、字段定义、接口交互点。

给一个简化例子。假设PRD里有这么一段：

用户通过手机号注册，手机号需为11位大陆手机号。用户输入手机号后，系统发送6位数字验证码，验证码5分钟内有效。密码必须同时包含大写字母、小写字母和数字，长度8到20位。若手机号已注册，则提示“该手机号已注册”。

AI抽取后的结果大概是：

{ "module": "注册模块", "business_rules": [ {"rule_id": "R001", "type": "normal", "desc": "合法手机号+正确验证码+合规密码，注册成功"}, {"rule_id": "R002", "type": "boundary", "desc": "手机号少于11位或超过11位，注册失败"}, {"rule_id": "R003", "type": "boundary", "desc": "验证码超过5分钟有效期，注册失败"}, {"rule_id": "R004", "type": "exception", "desc": "手机号已注册，返回业务错误提示"}, {"rule_id": "R005", "type": "boundary", "desc": "密码长度小于8位或大于20位，注册失败"}, {"rule_id": "R006", "type": "exception", "desc": "密码缺少大写字母/小写字母/数字，注册失败"} ], "fields": [ {"name": "mobile", "alias": ["手机号", "phone"], "constraint": "11位数字，以1开头"}, {"name": "code", "alias": ["验证码"], "constraint": "6位数字，有效期5分钟"}, {"name": "password", "alias": ["密码"], "constraint": "8-20位，含大写字母、小写字母、数字"} ], "interfaces": [ {"request_path": "/api/v1/register", "method": "POST"} ] }

这里有一个细节值得注意：fields里的alias字段是我们被坑过之后才加上的。PRD里写的是“手机号”，到了接口文档里字段名可能叫mobile，也可能叫phone。让AI抽取时把别名也保留下来，后面做用例生成的时候就有了一条清晰的字段映射链路，不然AI会在PRD字段和接口字段之间疯狂猜。

2.3 人工确认规则清单：最便宜的质量保障

规则清单抽取出来后，先让人完整看一遍再进入下一步，不要急着生成用例。这一步在流程上看起来多了一道，但实际非常轻：一个中等模块的规则清单通常也就二三十条，人扫一遍二三十分钟搞定。

但如果不做这一步，让AI直接基于PRD生成用例，等用例全部出来再校对的返工成本是这一步的好几倍。我们第一次跑的时候图省事跳过确认，结果AI把一条“同一手机号30天内只能注册一次”的规则理解成“同一手机号永远不能重复注册”，后面20多条受影响的用例全要改。所以从那以后，无论多急，这条人工确认都保留。

3. 提示词工程：给AI的不是问句，是一份用例设计图纸

3.1 开放式提问为什么效果差

“请为注册接口生成用例”，这种问法我相信很多人都试过。模型确实会给你生成用例，但生成出来的往往是一堆看不出体系的东西：场景之间没有层级关系，边界条件东一个西一个，前置条件基本是空的，请求体也可能和接口文档对不上。这种用例拿去执行，十条里能真正跑通两三条就算不错了。

问题不在模型笨，而在于你给它的是一道开放题，而不是一张带约束的图纸。AI擅长在你给定框架的前提下做填充和扩展，你不给它框架，它就按照自己的“平均经验”自由发挥，而这种发挥往往是一种理想化的、和你的业务对不上的状态。

3.2 用例生成提示词的四个组成部分

我们后来把生成用例的提示词收敛成四个固定组成部分：

1. 业务规则清单（第2章的结构化产物）。
2. 接口契约信息，包括方法、路径、参数类型、必填校验等。
3. 输出模板，也就是每条用例必须包含哪些字段。
4. 两条few-shot示例，让AI知道我们想要的是什么风格。

提示词结构大概是：

你是接口测试用例设计专家。请根据以下业务规则和接口定义，设计接口测试用例。 要求： 1. 每条用例必须包含：case_id、scenario、preconditions、request、expected。 2. request必须包含method、path、headers、body。 3. expected必须包含status_code、business_code、assert_fields。 4. 场景需覆盖normal、boundary、exception三类。 5. 预期结果只能使用接口定义或业务规则中出现的字段，禁止自行编造状态码和错误码。 6. 输出格式为JSON数组。 业务规则： {此处粘贴第2章的规则清单} 接口定义： {此处粘贴接口契约} 请开始生成。

这个提示词看起来平平无奇，但里面两个“禁止”非常关键：禁止编造状态码、禁止编造字段。不加这两句，AI就会给你编一整套不存在的错误码体系出来。

3.3 一个具体的生成结果长什么样

AI按这个提示词生成的用例大概是这样的：

[ { "case_id": "REG_001", "scenario": "合法手机号+正确验证码+合规密码注册成功", "preconditions": "通过数据工厂预置手机号13800138000的未注册状态；在验证码存储中写入验证码123456", "request": { "method": "POST", "path": "/api/v1/register", "headers": {"Content-Type": "application/json"}, "body": {"mobile": "13800138000", "code": "123456", "password": "Passw0rd"} }, "expected": { "status_code": 200, "business_code": 0, "assert_fields": ["user_id", "token"] } } ]

注意到preconditions这个字段没有？这是我们后来加进去的。第一版让AI生成用例时，它只输出“正例：注册成功”这种和没写没区别的用例。真实接口测试里99%的场景都需要准备数据：验证码要先写入Redis、用户状态要先重置、风控标记要先清除。所以我们在输出模板里强制加了preconditions，让它把“这条用例执行前需要准备什么”写清楚。加了这一项以后，用例的可执行度提高了非常多。

3.4 一次别生成太多，分批反而快

如果你把几百条规则一次性塞给模型让它生成所有用例，结果通常很差。原因有两个：一是模型上下文窗口有限，塞太多内容之后它会“忘记”前面的规则；二是审核者一次看五十条用例和看十条用例，审核质量完全不一样。

我们现在的做法是按模块分批，一次生成10到15条。生成之前还会加一个小技巧：让AI先把规则编号R001、R002这样列一遍，然后再按规则逐条对应场景。这样无论从生成结果还是审核节奏上都更可控，遗漏率明显下降。

4. 校验层设计：把AI的“一本正经胡说八道”挡住

4.1 翻车现场一：AI会编造接口字段

AI一个很典型的毛病是：你给的接口定义里根本没有某个参数，但它会依据自己的“常识”把参数补进去。比如接口文档里手机号字段是mobile，生成时它写成了phoneNumber；或者业务里根本没提渠道，它给body里加了一个channel字段。

这种问题在没有校验层的时候非常隐蔽，因为人浏览用例的时候容易被“看起来像那么回事”带过去。我们的解法是做一个字段白名单校验：从接口契约里抽出一个所有合法字段的集合，生成的每条用例的body和query参数都必须在这个集合里，凡是白名单之外的字段直接标红。

4.2 翻车现场二：AI会编造预期结果

另一个高频问题出现在expected里。业务规则只写了“手机号已注册，提示报错”，AI就自己猜了一个400状态码，甚至编了一个企业根本用不到的错误码E1001。如果这种用例直接进入执行阶段，请求发出去以后收到的实际返回和预期对不上，你根本分不清是接口Bug还是用例本身写错了。

解法是状态码和业务码白名单。在提示词里就限定，AI只能从我们提供的枚举里选择状态码和业务码，并且给一个固定取值表。取值表内容类似：

AI只要敢输出表里没有的值，校验脚本直接打回重写。

4.3 翻车现场三：规则漏掉导致覆盖不到位

这个问题的隐蔽程度比前两个高。前两个是“写错了字段/写错了预期”，肉眼能看出来；但漏场景是“该有的用例根本没出现”，你如果不知道业务里有这条规则，你就永远不会觉得它漏了。

比如PRD里写着“同一手机号30天内只能注册一次”，如果规则抽取环节没有把它捞出来，那AI生成的用例里就永远不会有这个场景。为了解决这个问题，我们加了一步覆盖率反检：用规则清单逐条问“哪条用例覆盖了R003”，凡是找不到对应用例的规则，立即补生成。

4.4 一套简单的自动化校验脚本就够了

很多人以为这块要上很复杂的平台，其实一段二三十行的Python脚本就能挡住80%的翻车。核心就是三个函数：字段白名单校验、状态码枚举校验、规则覆盖反检。

字段校验的框架大概是：

class FieldWhitelistValidator: def __init__(self, allowed_fields: set): self.allowed_fields = allowed_fields def validate(self, case: dict) -> list: errors = [] body = case.get("request", {}).get("body", {}) for key in body.keys(): if key not in self.allowed_fields: errors.append(f"case {case.get('case_id')}: 字段 {key} 不在白名单中") return errors

状态码校验就是直接比对枚举，规则覆盖反检就是拿规则ID与用例的tag字段做关联。跑完三个检查输出一份校验报告，哪条用例哪有问题一目了然。这一步的价值不是追求“完美AI”，而是把错误尽早暴露在进入用例库之前。

4.5 人工还是得看，但看的姿势变了

有了校验层之后，人工审核的负担减轻不少，但并没有消失。现在审核的人不再从零设计用例，重点看三件事：业务规则理解得对不对、边界条件是否覆盖到、预期结果是否符合产品逻辑。

我自己团队跑下来的感觉是：50条AI生成的用例，人工审核后真正需要调整的大概是10到15条，主要集中在业务语义上。省下的是从无到有的设计时间，留下的还是人的业务判断，这种分工比纯人工或者纯AI都健康。

5. 从验证到落地：流程嵌入、工具选型与效果度量

5.1 接在哪个节点：需求评审通过后、开发提测前

要把这个流程真正落地到团队里，不是写个脚本自己玩玩，而是要找个稳定的触发时机。我们选择的是需求评审通过之后、开发提测之前。

具体流程是：

1. PRD评审通过。
2. 测试负责人把PRD交给AI做规则抽取。
3. AI输出业务规则清单，人工确认。
4. 确认后调用用例生成，跑校验脚本。
5. 测试人员审核用例，修正业务语义。
6. 用例入库存入用例管理系统，后续关联执行。

比起原来的流程，前期只多了一个“规则清单确认”的环节，后期却少了一整个下午或一整天的“埋头写用例”时间。整体节奏变化不大，但人的精力被释放了出来。

5.2 技术栈怎么选：别一上来就追求平台化

我们在技术选型上走过一点弯路，一开始想得很宏大，甚至考虑过自研一个AI测试平台，后面发现完全没必要。第一版落地其实只要几个组件：

如果团队有条件，模型部分可以用开源方案本地部署，但从实际效果看，多数团队的瓶颈不在模型，而在提示词设计和规则清单质量。模型的选择只要能力在中等偏上，具体哪家都不是决定性因素。

5.3 效果度量：别只看生成速度，要看采纳率和缺陷发现率

我们团队跑了两个迭代之后，汇总了几个数据：

有一点必须提醒：不要只盯着生成速度。AI生成100条但100条都要改，等于没省。真正应该看的是采纳率，也就是不修改直接能用的比例。采纳率低，大概率是规则清单写得不好或者接口契约信息不完整，这时候该回头调上游，而不是继续调模型。

5.4 需求变更后怎么维护：增量更新而不是全量重跑

这是我认为整个链路里最容易被忽略的环节。需求变了，界面、接口可能都会变，如果此时把整份PRD重新丢给AI全量再生成一遍用例，结果一定是灾难：之前人工审核过的用例被AI悄悄改了写法，评审过的基线被冲掉了。

我们的做法是增量更新。需求变更时，把变更的那段PRD单独摘出来，喂给AI，让它对比旧规则清单，输出三样东西：新增的规则、删除的规则、受影响的用例编号。然后只对受影响的那部分用例重新生成，其他保持原样。

这个“变更影响分析”功能实现起来也不复杂，本质上也是提示词设计问题。但它的价值很大，因为需求变更才是团队常态，处理不好这套流程很快就会废掉。

6. 如果想在自己团队复制这套做法，我的三条建议

6.1 先找一个需求最稳定的模块做POC

不要一上来就拿核心支付、账务这类高风险模块试。压力大不说，模型一旦出错，被放大和质疑的概率也大。我们当时选的是一个权限管理模块，规则相对固化，字段不多，历史用例齐全，特别适合做对照实验。跑两周之后，数据一出来，团队内部自然就信了，后续推广阻力小很多。

6.2 把“规则清单”当成流程资产，而不是中间产物

我跑完这套流程最大的体会是：哪怕AI生成的用例最后不能用，抽出来的规则清单本身已经是巨大的价值。因为它是需求的结构化表达，评审的时候可以用，开发提测的时候可以用，后面写自动化脚本还是要用。

所以不要让规则清单成为一个临时产物。它应该入库，应该有版本，应该和需求变更联动。把它当成团队的一项资产来维护，AI用例生成只是它的一项应用而已。

6.3 维护一张“AI生成质量错误类型记录表”

最后分享一个实战小习惯。落地AI生成用例的前几周，我让每个审核的测试同学随手记录一下AI的错误类型，比如“字段写错”“状态码编造”“边界场景漏掉”“业务理解偏差”。每周汇总一次看趋势。

这个表看起来很小，用处却很大：当错误类型总体在下降，说明规则清单和提示词已经调顺了；如果某个错误类型一直降不下来，说明不是模型问题，而是源头输入有问题。有了这张表，你就能判断这个流程做得到底好不好，而不是靠感觉。