企业官网建设流程全解析

1. 问题现象：AI生成的测试用例正在“退化”

有个现象我观察了挺久：2023年用ChatGPT写测试用例，惊为天人，边界值、等价类、异常流给得头头是道。到了2025年，换成了最新的Claude、DeepSeek，同样一个需求，AI给出的测试用例反而越来越“飘”——每条用例看起来都覆盖到了，细看全是空话。

这不是幻觉，是真实情况。我手上好几个项目组都在用AI辅助写功能测试用例，最近三个月集中暴露出一批问题：

第一条就是断言模糊。AI写的用例经常出现“验证页面展示正确”“确认接口返回正常”这种表述，什么叫“展示正确”？什么叫“返回正常”？把这种用例丢给新来的同事，对方根本不知道怎么执行，最后只能靠猜。

第二条是上下文丢失。同一个模块，需求文档里明明写着“仅限已登录用户使用”，AI生成的用例里却有一半没走登录态，直接测匿名访问。这种用例不是没用，是不符合实际业务约束。

第三条是参数编造。AI为了显得专业，会自己“脑补”输入值。比如某业务要求金额精确到分、不能有负数，AI生成的测试数据里却出现负数和三位小数，跑用例的时候一片红，排查半天发现不是代码的锅，是AI编的参数根本不合法。

类比的话，现在的AI写测试用例就像拿建筑效果图去施工——图上富丽堂皇，每扇窗都画得清清楚楚，但施工队需要的是标注了承重墙位置、管线走向的结构图。效果图可以供甲方想象，结构图才能指导干活。

更麻烦的是，原来大家期待“AI越用越懂业务”，实际用下来发现，如果没有人持续喂反馈、校准输出，模型的生成质量并不会自动提升。它看起来聊得越多越贴合需求，换个场景、换个项目组、换一批需求描述，立刻回到原点。这也是为什么不少团队从“全面拥抱AI生成测试用例”退回到“AI只做草稿，人肉重写”。

2. 根本原因：为什么模型越大，用例越“虚”

聊这个话题之前，得先把AI写测试用例这件事的底层困境讲清楚。不然大家会以为换个大模型就能解决，实际上换谁都一样。

2.1 测试用例的本质是对“需求语义”的转译

一条能用的测试用例，本质是把需求描述翻译成“可执行的验证动作”。翻译得准不准，取决于两件事：需求本身说得清不清楚，以及翻译者是否理解系统的隐含约束。

传统人工写用例，测试人员会反复翻阅需求文档、和产品经理开会、翻看历史缺陷单、问开发要接口文档，甚至直接打开系统去点一遍。这些动作本质上是把散落在不同介质里的上下文捞起来，汇总成一份“验证计划”。

大模型做这件事的能力路径完全不同。它不看需求文档全文，不访问系统页面，不在缺陷库里查历史问题，它做的只有一件事：根据你给它的提示词，在训练过的参数空间里做概率预测，预测一段最像测试用例的文本。

这里存在一个天然的信息断层：AI看到的是提示词，不是业务系统。提示词里写了“登录功能”，它只能生成一个通行的登录功能测试用例模板；提示词里写了“金额计算”，它也只知道常规金额计算的测试套路。至于你的系统里面登录是手机号还是邮箱、金额精度是两位还是三位、有没有风控拦截、有没有异步校验，它一概不知。

也就是说，AI写的不是“你的系统的测试用例”，而是“某个泛化系统的测试用例”。早期大家觉得它好用，是因为通用用例在简单场景下够用；现在觉得越来越不靠谱，是因为系统越做越复杂，通用模板和真实业务之间的鸿沟越来越大了。

2.2 大模型的“表现力强”掩盖了“理解力弱”

很多人忽略了一个关键点：ChatGPT、Claude、DeepSeek这类模型，它们的强项是文本生成能力，不是业务建模能力。

你让模型分析一段需求，它能很流利地输出用户画像、业务流程、异常场景分析，看起来像那么回事。但模型内部的运作机制，决定了它并不“理解”业务，它只是在优化“下一段最合理的文字”。这在自然语言对话里问题不大，因为对话本身是开放式的，上下文是逐步累积的；但在测试用例这种需要严格、完整、可追溯的场景里，问题就暴露了。

我用一个生活里的类比来解释：你问一位出租司机“去机场怎么走”，他能流利地给出路线；但如果你把一份机场航班表丢给他，让他帮你在航班表里挑出所有可能延误的航班，并逐个说明延误原因，他大概率会懵。不是司机不聪明，是他的工作模式里根本没有“航班调度”的数据链路。

大模型也是同理。它的参数空间里装着海量测试用例范式和通用测试理论，这决定了它擅长“模仿测试用例的文体”，而不是“推理你的系统哪里会出问题”。

2.3 一个被低估的变量：模型对“业务上下文”的持久记忆能力极差

在这个问题里，很多人忽略了一个变量：AI对业务上下文的记忆，是对话级的，不是项目级的。

哪怕你在同一个会话里反复告诉它“本系统金额统一保留两位小数”，它生成下一条用例时也未必记得。它要记的东西太多——需求描述、业务规则、模型的字面意思、上一轮对话的记录——任何一个环节稍微偏离，它的输出就会回到通用的概率分布里去。

这也解释了为什么同一个问题反复出现：你给了AI十几条历史用例作为参考，它生成的后续用例仍然会偏离方向；你在提示词里写清楚了业务约束，换一个会话或换一个项目组，又得从头教一遍。

因为AI没有“项目记忆”这个概念。它不像人工测试那样，做完一个项目会积累对这个业务领域的直觉。它每次的上下文窗口是固定的，窗口之外的东西它看不到。这意味着，如果业务知识没有固化到提示词模板里，或没有变成某种外部规则被反复注入，那么AI每次生成用例都是“从零开始”。

2.4 为什么不是换一个更大的模型就能解决

到这里，所谓“换个更强的模型”为什么解决不了问题，答案就浮出水面了。

你换GPT-4、换Claude、换DeepSeek，换来的是更强的文本生成能力：它给出的用例表述更精准、结构更完整、覆盖更全面。但核心的信息断层没被补上——模型依然看不到你的系统，依然没有项目记忆，依然要在概率空间里“脑补”你的业务。

我可以做一个更直接的实验对比：用同一个需求，分别让ChatGPT、Claude、DeepSeek生成测试用例，表面上差异不小——有些人写得更详细，有些人写的更简练，有些人会主动列边界值，有些人偏重于主路径。

但把三条用例分别放到真实系统里执行，你会看到惊人的一致：主流程用例基本都能通过，异常用例一半跑不到那个分支，边界用例的参数一半不合法，结论全都一样——模型没有坏，是给你的系统“体检”这件事，它压根没做过。

换句话说，业界把“AI写测试用例不靠谱”归因于模型能力弱，是一个方向性误判。更准确的说法是：AI生成的用例之所以不准，不是模型的推理能力不行，而是系统信息和业务知识根本没有建模到提示词里去，模型是在没有地图的情况下画地图。

3. 实操拆解：AI生成测试用例真正卡住的地方

前面说了那么多原理层面的事，落到实际操作上，问题会更具体。我建议先把我自己实测下来容易出问题的环节拆开，因为每一个环节都能对应到一个具体的“坑”，也能对应到一个具体的改进方向。

3.1 第一关：需求文本的“信息密度”过低

AI能生成什么级别的用例，很大程度取决于你喂进去的需求文本长什么样。

如果喂给AI的是一句话：“用户登录后可以查看订单”，那么AI生成的用例肯定是清一色“输入正确账号密码，点击登录，验证跳转到订单页”——然后就没有然后了。因为它根本没有信息可以展开。

测试用例要覆盖的所有分支、所有边界、所有异常流，在需求描述里如果没有体现，AI就没有任何依据可以生成。这不是AI的问题，是需求本身的颗粒度决定了测试用例的颗粒度。

这也是一个很反直觉的地方：大家总觉得AI写测试用例省事，实际上你需要先花大力气把需求写细，AI才有东西可写。

实操中我见过最典型的对比是两个项目组：

项目组A的需求文档是产品经理直接从原型工具里导出的描述，每个功能写两到三句话，流程图和验收标准缺失。AI生成用例的时候，我不得不把所有相关信息一条条补进提示词，费时费力，用户体验也差。

项目组B的需求文档里写清楚了用户角色、权限矩阵、状态机、异常分支、历史缺陷记录，AI在这种输入下生成用例的质量，明显提高了一个档次。虽然还是有不完美的地方，但至少每条用例都有据可依。

所以第一件事，先把需求文档当成一种“算力资源”来看待——需求文档里有多少信息，AI就能在此基础上跑出多少用例。你省了描述的功夫，省掉的这部分信息不会凭空出现，而是被AI用“通用业务假设”替代了，而这些假设往往和你的真实业务不符。

3.2 第二关：提示词里的业务约束传递效率低下

很多团队用AI生成测试用例，做法是写一套“万能提示词模板”，里面套上业务规则，然后所有模块共用一套。

实测下来效果并不稳定。问题出在提示词模板的篇幅和结构上，业务规则一旦多起来，模板会变得非常长，AI在超长上下文中难以稳定把握哪些规则适用于哪些场景。

一个典型的失败案例：某业务模块的规则是“新用户首单享受折扣，老用户不参与”“折扣仅适用于自营商品，不适用于第三方商品”“金额满200元才可抵扣运费”。我把这三条规则同时写进提示词，让AI生成用例，结果AI在某个用例里把老用户也套用了折扣，在另一个用例里没有限制商品类型。

这暴露出一个提示词工程的关键痛点：规则之间的条件关系，AI很难精确建模。文字描述里的“仅适用于”“不适用于”“且”这类逻辑关系，人类读起来一目了然，AI在处理的时候却容易丢失限定条件。它倾向于把一个规则扩展开来，而不是精确地限制在指定范围内。

实操上的改进方向有两个。

一是把规则表格化。不要用长句子描述规则，而是列成表格：角色、商品类型、金额区间、是否适用折扣、折扣比例、运费规则。AI对这种结构化信息的理解，远好于对自然语言长句的理解。

二是把规则拆分到不同的提示词场景里。不要试图在一个提示词里让AI同时兼顾所有规则，而是分别生成“正常场景用例”“边界场景用例”“异常场景用例”，每个场景只注入该场景需要的那几条规则。实测下来，拆分后的生成质量明显好于一次性注入全部规则。

3.3 第三关：AI生成的“预期结果”普遍缺乏可验证性

如果说前两关是输入侧的问题，这一关直接卡在输出侧。

测试用例的三大要素是步骤、数据、预期结果。AI在步骤和数据上的问题还可以通过优化提示词缓解，但预期结果这一项，几乎是大模型的一个通病：它给出的预期结果过于“概念化”，无法直接用于断言。

比如它写“验证订单状态为已完成”，但没有说清已完成状态在前端显示成什么文案、在后端数据库里对应什么枚举值、在接口返回里code是多少。执行用例的人拿着这句预期结果，打开页面看到一个“已完成”标签，翻数据库却找不到对应记录，用例就算是通过了也无法确认测的到底是什么。

还有一种更隐蔽的情况：预期结果里包含了一条与本次操作不相关的隐含状态。

比如AI为“修改订单地址”写的预期结果是“订单详情页地址更新成功，订单状态不变，物流单号不变”。前两句没问题，“物流单号不变”这个预期结果不是从需求里推导出来的，而是AI默认订单在出库后物流单号已生成的情况下输入的。如果系统在该状态下还不允许修改地址，这条用例在第一步就会失败，而AI又不会告诉你先决条件是什么。

所以我一直跟团队强调：AI生成的预期结果一定要人工复审，且复审的重点不是看它写得“对不对”，而是看它是否“可验证”。

每条预期结果都要能回答三个问题：这个结果在前端哪里能看到？在数据库哪个字段里能查到？在接口响应的哪个字段里能断言？

3.4 一个容易被忽视的环节：AI对“数据准备”的天真假设

AI在生成测试用例时还有一个隐藏的坑——它默认测试数据是现成的。

它写“输入已注册用户的手机号”，但没有交代这个已注册用户是谁、在哪注册、密码是什么、当前状态是否是可用的。它写“准备一笔已支付订单”，但没有交代这笔订单是怎么支付的、支付回调有没有完成、订单金额是多少。

这个问题我在多个项目组里碰到过，最后你会发现，AI生成的测试用例里有一半需要的测试数据根本不存在，执行前要先花大量时间造数据。

而且造数据这件事，AI是干不了的。不同系统的数据准备路径千差万别：有些要走页面操作，有些要直接改数据库，有些要调用特定接口。用AI生成测试用例，本质上相当于把数据准备的这颗雷埋在你执行环节里。

后来我的处理方式是，在提示词里强制要求AI标注“数据前置条件”，每条用例都必须写清楚“前置数据是什么、在哪里构造、状态是什么”。如果AI没有这个信息，它生成的用例再好，也只是纸面上的用例，离真正可执行还有一段距离。

这里的实操建议也很直接：别指望AI帮你搞定数据，把数据准备当成测试用例图谱里的一个独立图层来管理。

4. 横向对比：ChatGPT、Claude、DeepSeek 实测表现差异

前面主要是讲共性问题，这一节聊聊差异。我拿同一个功能模块的需求，让三家模型分别生成测试用例，内容覆盖“订单取消”这个场景，对比它们在六个维度上的表现。

这个对比不是为了分出优劣，而是为了说明：即使你选对了模型，也只能缓解问题，不能解决根源。

4.1 基础维度对比表

4.2 实测案例：一句话需求 vs 详细需求

我做了两组对比。第一组只给了一句话需求：“用户可以取消待付款状态的订单”，三家模型给出的用例都偏模板化，主路径都是取消成功、取消失败、取消后状态变更，差异不大。

第二组给了详细需求描述，包含订单状态机、取消时限、退款规则、库存回滚逻辑。这时候差距开始拉开：

ChatGPT生成的用例比较全面，把取消后库存是否回滚、优惠券是否退还这些衍生场景都覆盖到了，但有个问题——它把“取消后优惠券退还”写得太绝对，没有区分优惠券是否在有效期内。

Claude生成的用例在边界条件上更强，主动提出了“取消时限截止前1分钟、截止后1分钟”这种时间边界，也把并发取消的情况列了进去。不过它也出现了前面说的预期结果概念化问题，“验证库存已回滚”没有给出回滚到什么状态的具体说明。

DeepSeek生成的用例在业务规则理解上较弱，直接把“取消待付款订单”和“取消已付款订单”混在一起了，给用户状态和订单状态的对应关系造成混乱。但DeepSeek在中文表达的简洁性上反而更好，用例步骤简短，适合做快速检查清单。

4.3 深入理解差异背后的成因

三家模型的差异，反映了它们在训练数据、指令遵循能力、推理深度上的不同：

ChatGPT的指令遵循能力最强。你给它明确的提示词格式，它基本上能遵循并输出匹配结构的用例。这是真正的“良构输出”能力，人类维护成本最低。

Claude的推理深度较好。它更倾向于在用例设计时加入“思考性”的边界条件，而不是简单模板化的覆盖。但它的输出有时会超出需求范围，增加一些需求里没有提及、系统里也不存在的假设场景，反而让用例变得冗余。

DeepSeek的输出更“文本压缩化”。如果你不给它精细的提示词，它生成的用例更接近“摘要式”的，步骤和预期结果都极其简短。这种风格的好处是阅读成本低，坏处是执行时缺少判断依据。

还有一个经常被忽略的变量：模型的输出风格会影响团队的用例评审习惯。用ChatGPT生成的用例，因为结构完整，评审的时候大家容易“想当然”地认为没问题；用DeepSeek生成的用例，反而因为缺失太多，评审的时候会逐条检查，发现问题更早。这和模型本身的能力无关，纯粹是格式带来的心理暗示。

4.4 在实际落地时，我会怎么做模型选型

如果团队的基础是提示词工程比较成熟、业务规则梳理得比较结构化，我会选ChatGPT作为主力生成工具，因为它的输出风格最稳定、最可预期。

如果团队的测试负责人本身经验很强，能够在生成后做一轮高质量的用例重构，我会推荐Claude，因为在有经验的人肉把关下，Claude的边界条件覆盖能带来较大增值。

如果团队对用例的详略要求是“执行时不需要读太多字，只看要点”，DeepSeek可以作为快速生成第一版草稿的工具，但必须有明确的质量复审环节兜底。

选型的关键不是“哪个模型最强”，而是“你的工作流能消化哪种模型的输出”。模型的输出是一个中间制品，它要经过人工检查、补充、修正，最终成为你的正式资产。所以选型要配合工作流来定，而不是被“哪个大模型更火”带着走。

5. 优化路径：让AI写测试用例从“抽卡”变成“写作业”

前面分析了很多问题，这一节直接讲怎么解决。我在这条路上折腾了大半年，目前的实践结论是：要建立一个AI辅助生成测试用例的完整工作流，而不是让AI孤零零去生成用例。

5.1 把“一次性提示词”改成“多层提示词模板”

最基础也是最重要的一步：不要每次生成用例时都从零开始写提示词，而是建立一套分层模板。

我的分层方式是三层：

• 第一层是基础模板，包含测试用例的基本结构要求、覆盖范围要求、命名规范。
• 第二层是业务模板，包含当前项目的业务规则、必测场景、历史缺陷高发区域。
• 第三层是执行模板，包含当前用例的执行数据要求、环境要求、前置条件格式。

每次生成用例时，先让AI读取基础模板和业务模板，理解规则；再让AI读取执行模板，明确输出格式；最后才让它根据具体的需求描述生成用例。

这样做的核心好处是：业务规则的精确约束可以与当次生成的具体需求松耦合。你不需要在每次提示词里都重复“折旧只适用于原价购买的商品”，而是让AI在业务模板里先理解这件事，生成的时候按理解后的规则来写。实测下来，上下文漂移的问题大幅下降。

5.2 让AI先“提问”再“生成”，而不是直接输出

这是我踩了很多次坑之后总结出来的一条关键改动。

以前我用AI生成用例，都是直接把需求描述丢进去，让它输出用例。后来发现输出总是不稳定，有时候漏边界，有时候写错规则。直到有一天我尝试着让AI先生成“需求澄清问题清单”，把不确定的业务点问明白，再喂回它的回答生成用例，稳定度一下子提上来了。

具体做法：在你把需求描述给AI后，先不让它生成用例，而是让它列出它觉得信息不足、可能影响用例设计的问题。你根据问题清单去问产品经理或查文档，把答案收集齐了，再让AI基于需求描述加问题答案生成用例。

这样做看起来多了一步，实际上把“AI猜业务规则”变成了“人确认业务规则”。AI不再需要把自己的假设投射到用例里，因为你不确定的地方都已经被提前确认过了。对测试用例来说，这比任何提示词技巧都重要。

5.3 对AI生成的用例做“断言可执行性”检查

这是我有意识地加入的一个环节。AI生成的用例进入正式资产库之前，我会先做一轮“断言可执行性”检查，也就是说，每条预期结果都要能对应到某个可实际观测的对象。

为此我制定了一套规则：AI生成的每一条预期结果，必须至少包含前端实际显示文案、后端数据库字段值、接口返回码/响应体字段之一。如果预期结果写的是“页面显示成功”，那就需要补充“成功提示文案为X”；如果写的是“数据保存成功”，就需要补充“数据库X表Y字段更新为Z”。

这套规则在提示词里写清楚后，AI的输出质量有明显提升。最典型的改进是，AI从“给你一句很笼统的断言”变成了“给你一个可以对照检查的具体状态”。区别就像有人说“车修好了”和说“发动机故障灯灭了，胎压已复位，刹车片换新了”之间的差别，显然后者才是可验收的状态。

5.4 建立“业务规则库”，把知识沉淀在工具里

大家都知道测试用例复用难，但很少有人意识到，测试用例难以复用的根因是业务规则没有结构化，导致每生成一批用例，都要重新理解一遍业务。

我在团队里尝试了一个做法：维护一个“业务规则库”文档，以表格形式记录每个模块的关键业务规则。每次AI生成用例时，把规则库的相关内容注入提示词。这个规则库可以持续积累：每发现一个AI容易出错的地方，就把它作为一条规则补进去。

举个例子，某订单模块的规则库内容大概是：

这套规则库的好处很明显：AI生成用例时，不会再把“已付款订单直接取消”作为正常场景来写，也不会在优惠券已经过期的情况下去验证退回逻辑。规则库成了AI与业务之间的一道稳定接口，AI从“凭空理解”变成了“按规则推导”。

5.5 从“AI生成”到“AI生成 + 人工演进”的闭环

最后要建立一个反馈闭环：每次AI生成的用例被人工修改后，把修改的部分记录为“修正反馈”，定期回灌到提示词模板里。

我的做法是每月做一次“AI生成用例修正复盘”，把当月的修正项归类，看哪些是AI反复犯的错误，哪些是新的业务规则需要补充进规则库。次月的生成工作流里，这些修正项就会自动生效。

这个闭环的意义在于，它把AI的“单次生成能力”升级成了“一个可持续进化的系统”。即使AI本身的能力没有提升，只要外部反馈在持续积累，AI的产出也会越来越接近项目的实际需求。

6. 不同规模团队的落地建议

前面讲的方案，对不同规模的团队来说，落地方式差异很大。这里按照团队规模给几个参考路径。

6.1 5人以内的小团队：以“人盯规则”为主，AI做草稿

小团队的特征是人手少、业务杂、没有专职测试平台团队。在这种配置下，不建议一开始就上很重的规则库和模板体系，太重了维护不起。

我的建议是：AI只负责生成“第一版草稿”，人工必须逐条复审，重点检查业务规则是否偏差。规则库不用做成文档，用一张共享表格就够了，每次AI生成用例前，把这张表格的内容直接粘贴进提示词。

这个阶段的工时分配大概是这样：AI生成用例半小时，人工补全修正两小时。看起来没省太多时间，但AI至少帮你解决了“从空白到成稿”的拖延成本，而且能保证用例格式统一。

6.2 中型团队：建立轻量级规则库，按模块管理

团队在10到30人之间，通常有多个项目并行，可以开始建设结构化的规则库。

做法是：每个模块建一张规则表，字段包括规则编号、业务场景、前置条件、预期行为、规则来源。AI生成用例前，从规则表里抽取当前模块相关的内容注入提示词。

这个阶段可以考虑让团队的测试负责人做一次“AI生成用例样板间”，把最优的提示词模板和规则表整理成标准文件，作为团队通用资产。新人加入时，先学习这个样板间，再上手用AI生成用例，效率会好很多。

6.3 大型团队：建设测试用例生成平台，把流程固化

团队超过50人的情况下，靠个人维护提示词和规则表已经不可持续了，需要注入到平台层。

这个阶段做的事情是：把前面说的规则库、提示词模板、断言检查规则、修正反馈闭环，全部固化到一个内部工具里。测试人员输入需求描述，平台自动拼接提示词、自动注入规则库、自动生成草稿用例，然后推送到评审流里。

不同规模团队的做法差异，本质上是把“人肉维护经验”沉淀为“工具自动执行”的程度不同。小团队靠人盯细节，大团队靠工具兜底。但无论规模大小，一个共识是：AI不能脱离闭环单独工作，必须有人工校验和反馈机制存在。

7. 常见问题与排查技巧实录

做AI辅助生成测试用例这段时间，团队里踩过的坑和解决问题的过程都很有代表性，整理成几个典型问题进行记录。

7.1 AI总在用例里“发明不存在的按钮”

这是一个高频问题。AI生成用例时，经常会出现“点击页面右上角的‘导出’按钮”这类步骤，但实际系统里根本没有这个按钮。

排查思路是：先在提示词里明确要求AI不得虚构交互元素，所有提到的按钮、字段、弹窗，必须来自需求文档原文。如果需求文档没有提到，就写“按需求文档为准，跳过”。

如果这个办法仍然不起效，那就说明需求文档本身缺少页面元素清单。我会在提示词的前置条件里加一个“页面元素参考”区域，把实际页面的主要控件列出来供AI参考，生成时就不会跑偏了。

7.2 AI生成的用例里业务规则前后矛盾

前面提到过这种情况，AI在规则的精确建模上较弱。比如它既写了“新用户享受折扣”，后面又给老用户的用例加了折扣。

我在排查后发现，问题不在模型，而在我一次性把太多规则塞进了提示词。多条规则之间有条件交叉时，AI很容易在生成过程中丢失前后的限定条件。

更好用的处理方式是先把所有规则拆成独立小场景，再让AI按小场景逐条生成用例，最后人工合并去重。规则一旦压缩到一个较小范围，AI的遵守率就比较高了。

7.3 AI生成用例的速度越来越慢、内容越来越乱

这在长对话中很典型。同一个会话持续使用超过两个小时，AI的生成速度会下降，输出质量也会不稳定，上下文越长，注意力越分散。

我的建议是：不要把同一个会话当永久的项目工作区。每完成一个模块的用例生成，就开一个新的会话，把该模块的关键规则和需求摘要重新注入。虽然看起来重复劳动多了一些，但质量和速度都更稳定。

7.4 AI生成的用例与已有的自动化脚本对不上

这个问题出现在那些已经有自动化测试框架的团队里。AI生成的是功能测试用例，但团队需要的是能对应到自动化脚本的用例。

针对这种情况，我会在提示词里增加一个“关联脚本”字段，要求AI生成的每条用例都标注适合关联到哪一类自动化脚本。如果团队已经在用Playwright这类工具，还可以把已有关键字的调用序列写进提示词，让AI在用例步骤里直接引用这些关键字。

7.5 提示词模板很长，但效果不稳定

很多团队把提示词模板写得很长，里面塞满了各种约束和要求，但实测效果反而不如一个简洁的模板。

排查思路是：先把模板里的约束分为“硬约束”和“软约束”。硬约束是指格式、结构要求，必须严格遵守；软约束是指业务规则、建议性要求，允许AI灵活判断。把硬约束放在提示词最前面，把软约束放在最后面。

实测下来，把关键的规则和格式要求放在开头，AI的遵循率会明显提升，因为模型在处理超长上下文时存在注意力衰减，前面的内容往往被更好地遵循。

7.6 几种“避坑”习惯分享

除了上面的具体案例，几个习惯也建议直接养成：

第一，AI生成的用例必须保留原始需求描述作为每条用例的关联依据，否则后续评审时没人知道这条用例是从哪句话推导出来的。

第二，每次用AI生成用例前，保证需求描述已经经过一次人工整理。需求本身混乱，AI输出的质量一定上不去，不存在“需求很烂但是AI很强”的情况。

第三，生成后不要直接入库，至少要过一轮“案头评审”加一轮“验证执行”。案头评审查逻辑，验证执行查可操作性，两轮跑完才算真的可用。

8. 写在最后的体会

折腾了大半年AI生成测试用例，我的结论是：AI不是不能生成测试用例，而是不能脱离人的业务知识单独生成能用的测试用例。它的角色应该是“测试用例的第一版草稿生成器”，而人的价值在于做业务语义的补齐员、规则冲突的仲裁者和断言可执行性的把关人。

不要指望AI能自动理解你的系统，系统是你的，业务也是你的，AI能帮你的地方，是把已经沉淀的知识按你要求的结构快速输出成稿。想要AI越来越靠谱，核心方法是持续把你的业务知识注入到AI的工作流里——不是靠一次对话写完一套规则就完事，而是把规则、修正、反馈做成闭环，让AI在你的体系里“越来越懂行”。

就这套方法论本身而言，它和具体的大模型版本没什么关系，今天用ChatGPT可以这么干，明天换DeepSeek也行。只要AI的底层运作方式不变——从概率分布生成文本，而不是理解你的系统——那么“业务知识注入 + 提示词模板化 + 人工校验闭环”这个框架就一直有效。