做测试这行做久了大家应该都有同感PRD一改用例推倒重来版本迭代快回归用例堆成山新来的同学不太了解业务写出来的用例缺胳膊少腿。我也试过直接用通用对话模型去生成测试用例结果就是表面看着格式对实际上深度不够换个场景就不会了。后来我花了两周时间用Coze平台从零搭了一个专门干这活的AI智能体现在团队里PRD一进来它能自动跑出测试点、生成功能用例、标注优先级和依赖关系基本能把基础用例的底子给兜住。这篇文章就是把整个搭建过程从思路到踩坑完完整整拆给你看。先说清楚这个智能体能解决什么问题它能接收PRD、需求文档甚至一段功能描述自动拆解出被测功能点按照功能流程、异常流、业务规则、数据校验、交互边界几个维度去生成测试用例最后输出一份结构化的Markdown用例文档。你不需要懂大模型原理也不用写复杂代码跟着一步步配置就能跑起来。内容适合谁看如果你是测试工程师、测试开发、项目管理者或者团队里经常要写测试用例的人这篇文章可以直接当作落地参考。就算你没用过Coze跟着操作也能搭出第一版可用智能体。1. 项目整体设计与思路拆解1.1 为什么选Coze而不是直接问大模型我在一开始就试过最原始的路子把PRD复制粘贴给大模型让它“给我生成测试用例”。结果是什么呢能出东西但是你要的东西它未必能给你。主要问题有三个。第一个是输出格式不稳定一会儿是表格一会儿是列表一会儿连编号都对不上第二个是深度不够它只会把需求复述一遍转换成用例描述根本不去想异常场景、边界值、状态流转这些东西第三个是最要命的它没有“记忆”也没有“规则”你今天让它按优先级标P0/P1/P2明天再问它又给你标成高/中/低。Coze平台解决的就是这几件事。你可以在一个智能体里把提示词、工作流、知识库、插件、数据库、变量这些都串起来让大模型的输出是结构化、可复用、可维护的。你也可以理解为裸大模型是一个刚毕业的实习生有知识但没规矩Coze就是你把公司流程规范教给他的过程最后他才能按你的标准干活。1.2 测试用例生成智能体的能力拆解在动手搭建之前我先把“测试用例生成”这件事拆成了几个子能力这是整个项目最关键的一步也就是想清楚再动手。我最终梳理出的能力清单是这样的理解需求能读取粘贴的PRD文本也能直接上传PRD文档把文字内容提取出来。拆解测试点从需求描述中识别出功能模块、业务流程、输入项、状态变化、权限关系、数据来源。生成用例按标准字段输出用例编号、模块、标题、前置条件、测试步骤、预期结果、优先级、用例类型。输出结构化内容最终结果可直接用于后续手工执行也可以导出到Excel、接入项目管理平台。这个拆解过程不能省。如果一开始只是想着“做个能生成用例的机器人”后面做出来的东西一定四不像。得先知道自己要什么能力才知道要在Coze里堆什么组件。1.3 整体方案选型工作流 大模型节点 知识库方案选型上面我对比了两种路线。第一种是全靠智能体的人设和提示词也就是把所有的规则都放在Bot的System Prompt里用户输入PRDBot直接回复用例。这种方案的优点是搭建特别快不用动工作流文本处理能力也够缺点也很明显当Prompt越来越长之后模型会逐渐“遗忘”前面的一些规则输出不稳定而且逻辑链太长了容易跑偏。第二种是用Coze的工作流加节点编排把整个流程拆成开始节点 - 内容提取 - 测试点拆解 - 用例生成 - 整理输出这几个步骤每个步骤用一个节点负责。工作流的好处是每一段逻辑都被单独封装了出了问题好排查哪里不对改哪里后面要加需求分析、用例评审这些步骤也方便扩展。我最终采用的是混合方案外层用智能体接收消息和文档内层用工作流核心处理知识库存放用例模板和历史经验数据给模型参考。这个方案的优势在于智能体负责交互工作流负责逻辑知识库负责提供参考各干各的活互不干扰。2. 核心细节解析与实操要点2.1 提示词设计怎么让模型真正懂测试提示词是整个智能体的灵魂。刚开始我写的提示词相当简单就是告诉模型“你是一个测试工程师请根据以下需求生成测试用例”效果只能用惨不忍睹来形容。后来我总结了一套结构化提示词的写法核心是给模型一个清晰的思考框架。关键的技巧是让模型先做“测试点分析”再做“用例生成”两件事分开。这个思路其实和测试设计的经典方法是一致的先用需求出发列出所有需要验证的内容再将测试点转化为可执行的测试用例。直接让模型生成用例就跳过了中间分析步骤它会漏很多细节。我提示词的核心结构是这样的角色限定明确告诉模型它是一位具备N年经验的测试专家擅长功能测试、接口测试和场景设计。输出规则明确字段、格式、编号规则、优先级规则、用例类型分类方式。思考路径要求模型按照“需求摘要 - 功能拆解 - 测试点提取 - 用例编写 - 自查补充”五步路径来思考和分析。约束条件只基于给出的需求来判断不臆造不存在的功能不确定的地方要明确标注“待确认”。负面约束不要输出与测试无关的内容不要给出代码本身不要重复需求原文。我用了一套固定模板即使换了不同的PRD内容思维框架保持一致输出的稳定性就会高很多。2.2 工作流设计每个节点该干什么活Coze工作流里我用到了最常见的几个节点类型开始节点、大模型节点、插件节点、条件分支节点、代码节点、结束节点。我设计的核心链路是这样的开始节点接收用户输入然后第一个大模型节点做“测试点拆解”它输出的是一份结构化的测试点清单包含功能模块、测试点描述、测试类型、优先级。第二个大模型节点再基于前面输出的测试点清单生成完整测试用例这一步的Prompt和第一步不一样更侧重于用例步骤和预期结果的具体化。最后用结束节点输出最终的Markdown内容。为什么要把生成拆成两步这是我踩了好几次坑总结出来的。在一次生成的情况下模型会试图把“拆解”和“编写”一起完成但这两步对于token的消耗和逻辑复杂度来说都太大了所以输出很容易在最后阶段崩掉。拆成两个阶段之后每个阶段的模型只要做好一件事质量稳定提升非常明显。2.3 文件上传与文档解析让智能体能处理PRD文件用户需求里有很多人是直接上传PRD文档的而Coze的智能体插件里自带了文档解析能力。这一点非常实用配置也简单在插件列表里找到文档提取和解析插件在工作流里加上一个文档读取的节点把用户上传的文档路径作为输入参数节点输出就是文档内的文本内容。实测下来对Word、PDF、TXT的解析效果都比较理想。特别要提醒的是扫描版PDF和图片型PRD普通插件是提取不出文字内容的一定要先做OCR。如果你的团队PRD是图片扫描件居多建议先在工作流里加一个OCR识别插件不要等到解析结果乱码了才回去找原因。2.4 知识库的作用给模型装上领域经验知识库这个配置刚开始我没用后来发现有必要。原因是有一些测试用例是高度依赖业务经验的比如支付场景里金额精度问题、登录场景里验证码的时效性、权限场景里越权访问的验证方式。这些内容如果完全靠大模型自己理解它也能写出来一部分但颗粒度和标准化程度都不够。我自己建了一个“测试用例模板库”和“典型场景库”把过去项目里高质量的用例放进去按模块分了文件夹然后在智能体设置里关联了这两个知识库。模型在生成用例时会优先参考知识库内容输出的用例风格和我之前团队的习惯基本保持一致。提示知识库里的内容不一定要很多但质量要过关。放十份高质量用例模板比放一百份凑数的用例效果要好得多。3. 实操过程与核心环节实现3.1 从零创建智能体的完整流程下面这一套流程是我反复操作多轮之后整理出来的照着做就行。第一步登录Coze平台进入“工作台”点击创建智能体。命名的时候建议直接叫“测试用例生成助手 ”方便团队成员识别和复用也能避免后期智能体多了之后管理混乱。第二步在“人设与回复逻辑”里写清楚这个智能体是做什么的、用户应该怎么用它、它最终会输出什么格式。第三步在“工作流”菜单里点击新建工作流开始搭主体处理流程这一步是整个项目的核心具体做法下一节展开。第四步在“知识库”里上传你自己的测试用例模板。第五步在“预览与调试”里进行测试输入一段PRD试运行看看效果。第六步调试通过后点击发布获得访问链接这样团队成员就能直接使用了。这六步表面上看起来不难但每一步背后都有很关键的配置参数我一一说明。3.2 工作流核心节点配置详解我拿“开始节点 - 内容输入整理 - 测试点拆解 - 用例生成 - 输出整理 - 结束节点”这条链路来举例。开始节点我设置了两个字段一个是“用户需求”格式是String另一个是“上传文档内容”格式是String。这样设计的好处是用户可以直接粘贴PRD文字也可以通过上传文档把解析后的内容传进来两种输入方式都能覆盖。内容整理节点用的是大模型节点Prompt设置为将用户的原始输入清洗成为结构化的需求描述。这个节点非常重要。因为用户粘贴的需求可能格式混乱、夹杂各种说明直接丢给后面的处理节点生成的用例质量会大打折扣。经过清洗后的文本统一了标点、去除了无关说明、整理了段落后续节点处理起来会顺手很多。测试点拆解节点继续用大模型节点输入是内容整理节点的输出Prompt我会写得非常详细要求模型从功能流程、异常分支、数据校验、权限控制、兼容性、接口逻辑等维度去拆解测试点然后针对每个测试点标记模块、类型、优先级。输出格式是JSON数组这样的好处是后面第二个大模型节点可以精准地拿字段去对应扩展而且方便调试排查。用例生成节点是工作流的最后一个大模型节点输入是前面节点输出的测试点JSONPrompt要求模型针对每个测试点生成对应多条用例并按Markdown表格输出。在这个节点里我加入了一个用法技巧把“用例标题”要求改成一句完整的话把“操作步骤”要求拆成编号列表这样输出的用例可读性会提升很多。最后用结束节点返回完整的Markdown内容用户那端就能直接看到一份格式规范的测试用例文档。3.3 让输出更规范的Prompt模板参考这个模板是我现在在用的放在大模型节点里核心结构可以直接复用你是一名资深测试工程师精通功能测试、边界分析、场景法、错误推测法。 请根据下方需求描述严格按以下结构输出测试用例 一、需求简要分析 - 核心功能 - 主要用户角色 - 关键约束 二、测试点清单 列出所有需要覆盖的测试点标注功能类型功能/异常/边界/数据/权限。 三、测试用例 表格输出字段包括用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级、用例类型。 编号规则MOD-001MOD-002。 优先级定义 P0-核心功能主流程阻塞发布 P1-重要功能分支必须修复 P2-一般功能不影响发布 P3-优化建议类。 要求所有用例必须可执行步骤描述要完整预期结果要明确。不要输出与测试无关的内容。这个模板里最关键的是把“优先级定义”和“编号规则”写清楚了模型就不会自己发挥。而“不要输出与测试无关的内容”这一句能有效过滤掉它编的故事和废话。3.4 完整案例演示用一段PRD实测运行效果我们用一段简化版的“用户登录”PRD来实测一下。需求描述用户可以使用手机号和密码登录系统手机号必须为11位有效号码密码长度不低于8位连续输错5次密码账号锁定30分钟支持记住登录状态。这套流程跑完之后生成的测试点大概覆盖了正常登录成功、手机号格式错误、密码长度不足、密码错误、连续输错5次触发锁定、锁定期间登录被拒、锁定到期后恢复登录、记住登录状态生效、退出登录后清除状态等场景。实际输出的用例数量在12-15条之间覆盖面和人工编写的要求基本持平。尤其是“连续输错5次密码账号锁定”这个场景大模型能自己推导出锁定时间到期后要验证是否恢复正常登录这一点让我比较惊喜。如果是简单的对话式Prompt这里往往会缺少恢复验证的用例。4. 常见问题与排查技巧实录4.1 模型输出格式不稳定怎么解决刚开始的时候模型输出的表格有时能正常显示有时变成一堆代码块有时连字段都对不上。排查下来主要有两个原因。第一个原因是提示词里对格式的约束不够明确。解决办法是在Prompt里直接加上一句硬性要求输出必须为Markdown表格表头字段为…严禁输出其他格式。第二个原因是模型在不同输出长度下会“自我发挥”当用例数量特别多的时候尤其明显解决办法是把一次生成的数量限制在15条以内超出就分批处理。4.2 复杂PRD处理效果差怎么办如果你的PRD描述了多个独立模块模型很容易混在一起。对策是先用代码节点把需求按“模块”切分或者在工作流中加入一个预处理步骤把大段需求切片每个切片只处理一个模块。这个方法对复杂的后台管理系统、会员体系、交易链路特别有效。实际测试下来当一个工作流只处理单个模块时生成的用例质量和完整度会高出不少。4.3 上传文档后内容为空或解析乱码这个问题的排查步骤需要按顺序来先确认文档格式是否是平台支持的格式再确认文档是文字版还是扫描版扫描版必须要先过OCR最后看一下文档的编码格式。有几个坑是特别容易踩的一是页面里有些非文字元素被解析成乱码二是某些文档里的大图片把内容分割得七零八散。我遇到扫描版PRD时会换成OCR插件处理目前识别准确率在可接受范围内但扫描图质量太差时也会出问题。注意上传的文档本身如果包含复杂表格插件解析会丢失表格结构导致内容变成一段连续的文本字段关系就乱了。这种表格型PRD建议先转成文字描述再喂给智能体效果会好很多。4.4 智能体回复内容过于啰嗦、不聚焦这个问题通常是因为智能体的人设与回复逻辑里写了太多“废话”比如“我也是个有经验的测试工程师很高兴为你服务”之类。解决方法是把人设提示词写成像命令一样简洁你是测试用例生成工具。用户发送PRD你返回测试用例。输出格式见工作流。不做解释、不寒暄、不补充。4.5 排查思路的顺序建议如果你运行之后结果不对我建议按这个顺序去查先看开始节点有没有拿到正确的输入。再看内容整理节点有没有输出成型的需求描述。再逐个检查大模型节点的输出哪一步的内容和预期不符问题就出在那一步。最后才考虑调整全局Prompt。Coze的工作流界面是支持单节点试运行的每次构建之后我建议按节点逐个试跑一遍。这一步不能省。跳着调试往往会让你搞不清问题到底出在哪个环节白白浪费时间。5. 进阶优化与扩展方向5.1 增加多轮对话能力实现用例追问与修改第一版做出来之后我又加了一个重要的能力让智能体根据用户反馈对用例做增量修改而不是全局重新生成。具体做法是在智能体的人设提示词里加入规则如果用户针对某条用例提供补充信息则只更新对应的测试点与用例不重复生成其他内容。场景是这样的用户上来传了一份PRD生成一批用例然后再说“支付模块金额边界值再多考虑一下”智能体这时候只针对支付模块补充边界值用例而不是把全量用例重新输出一遍。这个交互体验跟独立工具完全不一样更接近真实测试评审时“提意见、改用例”的协作方式。5.2 结合表格输出能力导出到Excel或接入项目管理平台测试用例最终要用于执行和跟踪一直放在对话窗口里肯定不行。我试过用Coze的表格处理能力把输出转成Excel格式也用过平台提供的插件将结果推送到项目管理工具。如果你只是要在本地使用还可以直接复制Markdown表格粘贴到Excel里就能自动分列效率也是很快的。5.3 沉淀团队知识逐步升级成用例资产库使用一段时间之后你对智能体产出的用例质量会有一个判断。团队里评审通过率高的用例、常见改法、典型漏测场景都是非常宝贵的资产。把这些内容持续充实到知识库里智能体的生成质量会随着时间逐步提升等于团队多了一个越用越聪明的用例沉淀库。这个方向的价值很实在不是锦上添花而是把用例设计经验从个人身上抽离出来变成团队资产的过程。写在最后的小体会这个智能体从构思到跑通我前后花了大概两周时间其中最花时间的不是搭建而是调试提示词和测试不同输入场景。如果你也想搭一个我建议不要一上来就追求功能大而全先让主流程跑通、生成一批能用的用例再逐步加文档解析、知识库和追问修改这些能力。每个阶段的效果都是立竿见影的做起来也更有成就感。我自己实际用下来最大的感受是这类智能体能承担的是测试用例设计里“量大面广”的部分把基础覆盖做扎实但它替代不了人对业务深度的理解和对隐性风险的直觉。最好的使用方式是把AI当作一个不知疲倦的初级测试设计者你来当那个把关的人。这样配合效率提升的幅度会非常明显。