干测试的同学应该都有过这种经历：产品丢过来一份PRD，嘴上说着“小需求”，打开一看三五十页，然后留下一句“明天用例必须出完”。你一边翻文档一边在Excel里敲用例编号，从正常流程写到边界异常，写到后面大脑基本宕机，手指完全机械运动。后来我开始用Coze（扣子）搭了一个专门用来生成测试用例的AI智能体，把PRD丢进去，几分钟就能拿到一版结构完整的用例草稿，我再花时间过一遍、补几条关键场景，效率提升非常明显。这篇文章把我从零搭到实际使用的完整过程写下来，包括工作流怎么搭、提示词怎么写、踩了哪些坑，希望能帮到同样被用例压得喘不过气的测试工程师，也适合所有想在Coze上快速落地一个AI智能体的朋友参考。
1. 先想清楚：为什么用Coze搭测试用例生成智能体
1.1 从测试用例生成这个场景说起
做测试用例生成这件事，看起来简单，实际复杂度很高。普通用户会觉得“不就是让AI读需求然后列几条步骤嘛”，但真正干过测试的人都明白，一份合格的用例清单需要考虑功能逻辑、输入输出、边界值、异常场景、权限控制、数据一致性、系统间依赖，还要兼顾优先级和可执行性。
我把这些要求拆解了一下，一个能用的用例生成智能体至少要具备四层能力：第一层是理解需求文档，能从大段产品描述里提取“功能模块”和“业务规则”；第二层是测试设计，能自动应用等价类划分、边界值分析这些方法；第三层是结构化输出，要生成带编号、前置条件、步骤、预期结果的标准用例；第四层是二次优化，能根据我的反馈调整粒度或补充场景。
这四层能力如果全靠在对话窗口里重复输入提示词，每次都要重新强调一遍，成本太高了。Coze这类AI智能体平台的价值就在这里，它允许我把这套流程固定成一个可复用的Bot，以后只需要把PRD文本丢进去，所有处理逻辑都在内部自动完成。
1.2 Coze为什么适合干这活：对比直接开一个通用模型聊天窗口
可能有人会问，我直接用豆包或者ChatGPT开个窗口，把PRD复制进去让它生成用例，不也一样吗？说实话，临时用一次确实可以，但一旦进入真实工作流，差距就出来了。
直接开通用模型聊天，第一个问题是角色设定不稳定。你这次跟它说“你是资深测试专家”，它输出了不错的结果；下次忘记强调，它就开始自由发挥，格式千奇百怪。第二个问题是超长文档很容易被截断，一个30页的PRD贴进去，经常对话到一半模型忘了前面的内容，或者直接提示超长。第三个问题是每次都要重复解释规则，过程极其繁琐。
Coze解决的是“把经验沉淀成产品”的问题。我打一个比方：直接跟模型聊天就像每次请一个新实习生，你得从头交代背景、要求、格式；而搭好的Coze智能体，相当于把老员工的工作流程写成了SOP，固定在一个助手身上，它每次都会按这套SOP执行。在这个智能体里，人设、步骤、提示词、插件都是提前配置好的，不需要每次重复描述。
1.3 智能体整体架构：Bot + 工作流 + 知识库 + 插件
在动手搭建前，我先梳理了一下Coze里的核心概念和整体架构，这里也分享给第一次接触的朋友。
整个智能体分四层：
- 入口层：就是用户能接触到的地方，可以是Coze网页里的调试对话框，也可以是发布到飞书、企业微信、公众号之后的消息窗口。
- Bot层：负责对话交互，包含人设、开场白、触发词和基础指令。测试用例生成助手在这一层做的事情就是告诉用户“请粘贴PRD内容，我会按功能模块输出用例清单”。
- 工作流层：这是核心，相当于产品的后端逻辑。一个完整的工作流可以拆成开始节点、大模型处理节点、代码节点、插件节点和结束节点，每个节点负责一个步骤，节点之间传数据。
- 能力层：包括知识库（存测试用例规范、模板、历史优秀用例）、插件（文档解析、Word导出、表格处理等）、数据库（存每次生成的用例，方便追溯和复用）。
搭建时有一个原则要牢记：如果只是“随便聊聊”的任务，直接用Bot对话就行；但像测试用例生成这种有固定流程、固定格式、固定处理步骤的任务，一定要把流程写成工作流。工作流就像一个流水线，原料（PRD）从入口进去，经过拆解、设计、格式化，最后出口出来的是成品（用例清单）。这也是为什么我下面会花大篇幅讲工作流的搭建。
2. 搭建前的准备：账号、团队空间与核心概念
2.1 创建团队空间与Bot：第一次打开Coze该做什么
第一次登录Coze平台（国内版访问coze.cn），界面可能有点陌生，我先说最基础的操作路径。
登录后，左侧导航栏里有“工作空间”或“团队空间”的入口。我第一次用的时候找了好久才发现，团队空间其实是个资源隔离和协作的单位，不是聊天室。个人使用或者小团队协作，建议先创建一个团队空间，比如命名为“研发效能组”，然后把所有Bot、知识库、工作流、插件都建在这个空间里，避免和个人其他项目混在一起。
创建完空间之后，在空间首页点击“创建智能体”或“创建Bot”，进入创建页面。这里需要填写三样东西：名称、功能介绍、模型选择。名称我建议起得直白一点，比如“测试用例生成助手_TEST_v1”，方便后续迭代维护。功能介绍会影响模型对Bot的理解，比如“这是一个测试辅助工具，接收PRD文本，输出功能测试用例”。
模型选择这里我多说两句。国内版Coze一般默认提供豆包系列模型，比如Doubao-pro-32k、128k这些，也支持接入其他主流大模型API。对于测试用例生成这种任务，我的建议是优先选上下文窗口大的模型，后面生成长文档和长表格时不容易截断。如果团队已经采购了某个大模型API，也可以在模型配置里换成自己熟悉的，逻辑是一样的。
2.2 工作流和对话流，到底选哪个
Coze里有“工作流”和“对话流”两种可视化编排模式，新手经常搞混，这里我做个对比。
工作流（Workflow）适合固定流程的任务，像流水线一样，从开始节点走到结束节点，每个节点做确定的事情。比如测试用例生成，输入PRD文本、拆解功能点、生成用例、输出表格，这条路是固定的，用工作流最合适。
对话流（Chatflow）保留了多轮对话能力，可以让AI在执行过程中根据情况动态决定下一步，适合像客服助手、咨询顾问这类需要来回沟通的场景。比如一个能回答“用例怎么设计”的测试知识问答助手，更适合用对话流。
我当时的选择很简单：主流程用工作流，把“PRD转用例”这件事做成一条标准流水线；用户交互和后续的多轮优化指令，放在Bot层处理。如果后续想支持“继续帮我补几条边界用例”“把P0用例按优先级重排”这类动态反馈，可以在工作流里再接一个对话流分支，或者直接用Bot的人设来兜底。初期不要贪多，先把主流程跑通。
2.3 模型参数与Bot人设配置的小技巧
在Bot配置页面里，除了选模型，还有几个参数值得关注。
第一个是温度（temperature）。这个参数控制输出的随机性，数值越高回答越发散。测试用例生成需要稳定、格式统一，我把温度调到了0.2到0.4之间，这样每次生成的用例结构基本一致，不会出现一次输出表格、一次输出纯文本这种失控情况。
第二个是开场白设置。好的开场白其实是给用户看的“使用说明书”。我写的开场白是：“把PRD内容粘贴给我，我会自动拆解需求并生成一份功能测试用例清单。如果要调整粒度或补充场景，直接告诉我。”这样用户一进来就知道这个Bot能干什么、怎么用。
第三个是Bot人设回复逻辑。这里我写了一段类似“你是一个测试用例生成助手，收到PRD后必须严格按照工作流输出，不要输出多余解释，不要输出安慰性语言”的指令。这段指令的价值在于，它能压制模型自由发挥的冲动，把它框定在“执行流程”的定位上。
3. 核心实现：测试用例生成智能体的完整搭建过程
3.1 第一步：设计PRD输入与预处理模块
工作流的第一步是接收输入。在工作流编辑页里，开始节点的作用就是定义整条流水线的入参。我在这里定义了一个参数叫prd_text，类型是文本，描述是“用户粘贴的产品需求文档内容”。
这里有个很关键的工程经验：输入方式会影响成功率。我在测试初期尝试过几种路径：
- 直接粘贴文本：最稳定，推荐。
- 上传Word或PDF文件：需要调用文档解析插件，解析效果取决于插件质量，偶尔会出现乱码和排版丢失。
- 输入URL让插件抓取：效果很不稳定，网页结构复杂时抓回来的内容经常缺胳膊少腿。
所以最后我的方案是：在Bot人设里引导用户“复制PRD纯文本内容，直接粘贴到对话框”，然后工作流接收纯文本。如果你非要支持文件上传，建议在文件上传后先用文档解析插件把内容转成纯文本，再传到prd_text变量里。在开始节点还可以加一个简单的判断逻辑：如果prd_text长度超过一定阈值，就提示用户分模块粘贴，避免超出模型上下文上限。
3.2 第二步：需求拆解与测试点提取
直接拿整篇PRD去生成用例，效果通常不好。原因很简单：用例生成是一个高度依赖细节的任务，PRD里的功能点交织在一起，大模型一口气生成很容易漏项，尤其是异常场景和边界条件。
为了提升覆盖率，我在工作流里加了一个“需求结构化解构”的大模型节点。这个节点的作用是把长文本PRD先转换成结构化条目，相当于给AI配了一个分析环节。我给这个节点的提示词是这样设计的：
你是资深测试架构师。下面是产品需求文档内容。请提取所有可测试的功能点，按以下格式输出： 【功能模块】模块名称 【功能描述】一句话描述 【涉及角色】谁在使用 【操作路径】用户操作的主要步骤 【输入条件】所有输入项及其类型 【业务规则】穷举所有业务规则，包括分支判断、时间限制、权限限制、数值边界 【异常场景】可能出现的异常输入和异常操作 【依赖关系】与其他模块或第三方系统的关系 注意：业务规则要尽量穷举，不要遗漏if-else分支、金额边界、时间范围、重复操作、并发冲突等场景。不要输出多余解释。为什么这个步骤重要？因为“功能模块”和“业务规则”这两个字段，直接决定了后面用例生成时的覆盖方向。如果这个节点拆得细，最后用例数量和质量都会有明显提升。我实测过，不做拆解直接生成，用例漏项率很高；加了这一步之后，覆盖率明显改善，尤其是异常场景。
3.3 第三步：测试用例生成的编排逻辑
需求拆解完成后，进入最核心的生成环节。我在工作流里建了三个连续的大模型节点，分别承担不同的职责。
第一个节点叫“模块分组”，把结构化条目按功能模块分组，每个模块生成一个用例子集。第二个节点叫“单模块用例生成”，针对每个模块的测试点生成完整用例。第三个节点叫“全局校验”，把生成的所有模块用例合到一起，检查重复项、补充遗漏场景、给用例排优先级。初学者如果觉得三个节点太复杂，也可以先只用一个“用例生成”大模型节点，一次生成全部用例，跑通后再拆分细化。
单模块用例生成的提示词大概长这样：
你是一名有十年经验的测试开发工程师，擅长功能测试用例设计。 请根据以下需求条目生成一份功能测试用例清单。 要求： 1. 输出Markdown表格，列名固定为：用例编号、所属模块、用例标题、优先级、前置条件、测试步骤、预期结果。 2. 测试步骤用 1/2/3 编号，必须具体到输入值和操作。 3. 覆盖正常流程、等价类、边界值、异常输入、权限控制、重复提交、数据一致性。 4. 优先级规则：核心主流程为P0，重要业务逻辑与边界校验为P1，UI和提示文案为P2。 5. 不要输出表格以外的解释内容。 需求条目： {{requirement}}这里再说一下变量引用的操作。在Coze工作流里，上一个节点的输出会出现在“变量选择器”里。上面提示词里的{{requirement}}，实际配置时不是手动输入，而是从左侧变量列表里选中上游“需求拆解”节点的输出字段。如果你改成了手工输入，节点之间就没有真正连起来。
3.4 第四步：输出格式化与Markdown转Word
用例以Markdown表格形式生成后，在Coze聊天窗口里展示没问题，但真要拿到测试评审会上用，还是得转成Word或Excel。这一步有二种走法。
第一种是直接在“结束节点”把Markdown文本返回给对话窗口，适合快速预览和在线编辑。第二种是接一个文档生成插件，在插件商店里搜“文档”“Word”或“Markdown转Word”，找一个安装量高、更新时间近的插件绑定到工作流里，把Markdown内容传给插件，插件会返回一个生成好的文件链接。测试时需要重点检查插件参数的匹配，比如插件接收的是字符串还是文件标识，如果类型不匹配，要用代码节点先做一次类型转换。
我在实践中发现，转成Word之后格式偶尔会乱，尤其是表格列宽和换行。一个稳妥的替代方案是：在代码节点里用Python把用例数据拼成CSV格式字符串，再交给表格导出插件生成Excel。Excel在测试团队里的接受度其实比Word更高，评审时筛选排序都方便。
3.5 提示词模板分享：可直接抄作业
把上面提到的提示词整理成套，这里直接放完整版，方便大家复制修改。
整套提示词分两段：第一段是“需求理解与拆解”，第二段是“用例生成与输出”。在工作流里分别配置在两个大模型节点中。
需求拆解节点提示词：
你是一名资深测试架构师。下面是产品需求文档内容。 请提取所有可测试的功能点，并按以下结构输出： 【功能模块】【功能描述】【涉及角色】【操作路径】【输入条件】【业务规则】【异常场景】【依赖关系】 要求： - 业务规则要穷举if-else分支、数值边界、时间限制、权限控制、数据一致性。 - 不要遗漏重复提交、并发操作、取消操作、弱网等异常场景。 - 只输出结构化内容，不要额外解释。 PRD内容： {{prd_text}}用例生成节点提示词：
你是资深测试开发工程师。下面是从PRD中提取的需求条目。 请设计功能测试用例，以Markdown表格输出，列名为： 用例编号 | 所属模块 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 预期结果 要求： - 覆盖正常流程、等价类、边界值、异常输入、权限控制、重复提交。 - 测试步骤必须明确操作对象和输入数据。 - 不要输出表格之外的内容。 - 如果模块较多，按模块输出，先输出模块名，再输出该模块的用例。 需求条目： {{requirement}}这两段提示词里都有硬性约束：“不要输出多余解释”“不要输出表格之外的内容”。这类约束非常重要。很多初用AI生成用例的朋友会觉得很奇怪，为什么AI总喜欢在表格前面加一段“根据您的需求文档，我生成了以下测试用例”这种废话，原因就是你没有明确禁止。AI有很强的“礼貌倾向”，你不说它就觉得应该说点什么，你明确禁止了，它就老实了。
4. 调试、发布与日常使用中的坑
4.1 大段PRD被截断怎么办
这是我在实际使用中遇到最多的一个问题。刚开始测试时，我粘贴了一份大约3万字的PRD进去，结果工作流跑了一会就报错，错误信息大概是输入参数超长。
后来我总结了三招：
第一招，换长上下文模型。把Bot模型从32k换成128k版本，承载力明显提升。如果PRD再长，还是有风险。
第二招，引导用户分模块粘贴。在Bot人设里加了一句“长文档请按功能模块分批粘贴，建议单次不超过5000字”，从源头上规避超长问题。
第三招，在工作流里加文本切片逻辑。在代码节点里写一个简单的切分函数，把大段文本切成多个小片段，再逐段处理，最后合并结果。这个方案最灵活，但要写代码，对新手有一定门槛。
目前我最常用的组合是前两招：长上下文模型加分段粘贴。稳定性足够，操作也简单。
4.2 生成的用例质量不稳定，如何通过多轮对话优化
质量不稳定是AI智能体必须面对的问题，我第一次跑出来的用例就有不少“一眼假”的情况，比如把“首页搜索”写成“输入关键词点击按钮后看结果”，步骤根本不落地。
要解决这个问题，我调整了几个地方。一是把温度降到0.3以内，减少随机性。二是在提示词里增加更细的约束，比如“测试步骤必须包含具体页面元素和输入值”“预期结果必须可验证”。三是增加一个“用例质量校验”节点，让大模型对生成结果做第二轮检查，删除不明确的步骤、补充遗漏的边界场景。
实际用下来还有个心得：把AI当实习生用。它生成的第一版就当实习生第一版，你把它叫过来口头提需求：“把搜索模块补充一个空关键词的用例”“P0用例排在前面”“前置条件写得更具体”，它都能通过对话继续修改。这就是Bot层多轮交互的价值，也是为什么不建议用纯工作流僵化到底的原因。测试起来效率最高的方式，是先让工作流跑结构，再用对话微调细节。
4.3 输出格式丢失与表格错乱
在调试的时候我遇到过一种很头疼的情况：同样的工作流，第一次输出是漂亮的Markdown表格，第二次输出表格变成了一堆竖线字符，第三次直接变成纯文本条文。
这个问题本质上是模型在不同轮次对Markdown语法的遵循程度不一致。解决办法有两个方向。一个是在提示词里把格式要求写得更死板，比如“必须输出以下格式”，然后把样例表格写进提示词里，让模型照着样例格式生搬硬套。另一个是在代码节点里做格式规范化，把生成结果统一清洗一遍，补全表格分隔符，再传给结束节点。
还有一个实用的技巧：结束节点如果配置成卡片形式，展示效果会比纯文本好很多。Coze支持把工作流的输出结果以结构化卡片的形式返回，表格也能更完整地保留。这些可以在调试页面里多尝试几次，找到最适合自己使用习惯的展现方式。
4.4 插件调用失败与知识库不生效的排查
插件是Coze里最容易出问题的地方，因为插件相当于第三方能力，你无法控制它内部实现。
有一次我调Word导出插件，工作流总是报错，把插件节点点开看日志才发现，原来我传给它的内容是Markdown文本，而那个插件接收的是文件路径类型的参数。这就是典型的参数类型不匹配。解决方法是加一个代码节点，先把文本内容转成文件或指定格式，再传给插件。
知识库不生效的问题也很常见。我一开始上传的文档是扫描版PDF，Coze知识库根本没有提取出有效文本，自然无法召回。后来把文档转成TXT再上传，效果立刻正常了。还有一点，如果知识库上传的是大量模板文档，召回时会受分块策略影响，可以在知识库配置里调整“分段长度”和“召回片段数”，让模型有更多相关上下文可用。
4.5 发布到飞书、微信等渠道的注意点
调试完成后，可以把智能体发布到不同渠道。发布的过程并不复杂，但有几个细节容易踩坑。
发布到飞书群或企业微信群时，需要先在对应开放平台创建应用，拿到App ID和App Secret，再到Coze发布配置里填写这些参数。首次配置可能需要管理员审批，建议提前跟运维沟通。发布到微信公众号则需要配置服务器回调地址，步骤相对多，但Coze界面里有引导，跟着走就行。
渠道部署完之后，最实用的建议是先用“仅团队成员可见”方式发布，找几个同事试用几天，收集反馈后再全量开放。我第一版发布时没做这个限制，结果群里大家各种乱发内容，Bot被玩坏了好几次。后来改成团队成员可见，才安心做优化。
5. 从测试用例生成出发，还能做什么
5.1 同一套架构，换个场景就是商品推荐智能体
测试用例生成智能体的架构，本质上是一个“输入需求文档，拆解结构，调用模型生成结果，格式化输出”的通用流水线。这套思路可以迁移到很多场景，商品推荐就是其中一个。
之前有朋友问我怎么做“AI商品推荐智能体”，其实套路完全一样：输入用户的一句话需求文本，工作流里用大模型节点做意图理解和关键词提取，再根据提取出的类目到数据库或商品接口查询，最后生成个性化推荐清单。区别只在于：测试用例生成用的是PRD和用例模板，商品推荐用的是用户描述和商品数据库。所以说，把Coze工作流的核心搞明白，你会发现智能体开发的门槛其实很低。
5.2 出题答题批改学习助手也是同样的底层逻辑
看到社区里有人讨论怎么在Coze中做出题答题批改学习助手，底层逻辑也很相似。这个智能体需要一个知识库存放题库和教材，一个工作流负责根据知识点出题，再有一个节点负责比对答案和生成解题解析。
完全对应得上测试用例生成的几个关键节点：知识库对应测试规范库，出题节点对应用例生成节点，批改节点对应质量校验节点。你搭好一个工作流之后，其他场景大多只是换了数据、换了提示词。我时常觉得，搭建AI智能体的核心能力不是写代码，而是“从一个具体场景出发，抽象出输入、处理、输出的结构化流程”。
5.3 用数据库沉淀用例资产，配合触发器自动生成
最后再说一个进阶方向：把每次生成的用例存到Coze数据库里，形成一个用例资产库。这样下次同类需求出现时，可以直接检索历史用例，也可以统计哪些模块用例覆盖率不足。再配合定时触发器，每周自动汇总新增需求并生成对应用例草稿，开发迭代的速度会快很多。
我目前已经在自己团队里跑通了一部分：每次工作流生成完用例，通过代码节点批量写入数据库，然后周报自动统计模块用例数量。这个能力对测试团队做“用例资产沉淀”非常有价值，也比老方法里手动整理Excel表格省力太多。
最后再分享一点个人体会。AI智能体搭建这个事，最大的门槛从来不是工具操作，而是你能不能把一个模糊的需求拆成明确的输入、处理和输出。测试用例生成这个场景难易适中，既有明确的输入（PRD），又有明确的输出（用例表格），中间又有足够多的处理细节可以反复打磨，特别适合作为Coze入门的第一课。你先把这个流程跑通，后面再碰任何智能体开发，心里就都有底了。
