刚把需求评审会开完又领回来一份十几页的产品需求文档。这种场景做测试的人应该都不陌生快速扫一遍文档手动拆出功能点再琢磨正常流、异常流、边界值最后在Xmind里一个一个节点点出来。熟练的话一份中等规格的需求文档画完导图起码得花上两三个小时遇上需求描述含糊的时间还得往上翻。我试着把这条链路用Coze加Python串了一遍做成一个半自动化的流程需求文档丢进去AI先把功能点、测试点、优先级全部拆好再用脚本落成Xmind文件。实测下来从拿到文档到产出导图时间能压到几分钟以内而且结构比手工整理的更完整。这篇就把完整思路、配置过程、关键代码和踩过的坑一次说清。1. 先把问题说清楚测试点梳理为什么值得自动化1.1 需求文档到测试点到底卡在哪很多人觉得测试点梳理就是“读文档、列条目”听起来不难实际上手就知道别扭在哪需求文档不是专门给测试看的。产品经理写的是业务逻辑、交互说明、页面流转里面藏着大量隐含信息。比如一个“导出报表”功能正常路径是一句话但测试得想到文件格式、空数据导出、大数据量导出、权限校验、文件名规则、并发导出这些分支。这些分支不一定白纸黑字写在文档里基本靠测试人员脑补。脑补就有一个覆盖度问题新人容易漏老手也难免看走眼。第二个痛点是结构整理。测试点不是一锅粥得按模块、子功能、具体场景去组织最后落到Xmind里还要考虑层级合理、标签清晰、优先级可识别。手工整理的时候经常是导图画到一半发现某个模块漏了或者某个测试点不知道该挂在哪个父节点下面来回调整很费时间。第三个问题是重复劳动。需求变更一次测试点就要跟着改一轮。版本迭代多了维护Xmind的时间比新写一版还长。所以这个项目瞄准的不是“让AI替你思考”而是“让AI帮你把需求文档里的测试点先拆出来再由脚本稳定地落成结构文件”。AI的产出不一定百分百精准但作为第一版初稿覆盖面已经很可观人工只需要做增删改工作量直接降一大截。1.2 Coze在这个场景里适合做什么大模型本身就能分析文本那为什么还要绕一圈用Coze直接打开网页版对话框把文档粘进去不就行了单次对话确实可以但问题是不可复用、不可接入工具链。每次都要手动复制粘贴、复制结果、再手动整理自动化程度很低。Coze的价值在于把大模型的调用、提示词、任务流程固化成一个可重复调用的“服务”。同一份提示词、同一个工作流换一份文档扔进去就能出结果结果格式是稳定的后面接Python脚本也就顺理成章。Coze工作流本身是把多个节点串起来。以这个需求为例典型的工作流是“接收输入参数 → 大模型分析文档 → 输出结构化测试点”。如果后续还接了数据库存储、文档解析插件、定时任务都能在可视化界面里配置。对测试团队来说这等于把一个“资深测试专家”的拆解思路沉淀成了团队资产谁拿到都能用。1.3 整体方案一条能落地的技术链路这事的完整链路是需求文档Word/PDF/Markdown → Python脚本提取文本 → 调用Coze工作流或Bot接口 → 拿到结构化测试点数据 → Python脚本转换格式 → 生成Xmind文件 → 人工检查微调 → 分发到测试组。分工上Coze负责大脑需求理解、测试点推理、结构化输出Python负责手脚文档解析、接口调用、文件生成。AI做不了稳定的文件格式转换Python做不了需求语义理解两者配合才是这个方案能跑通的关键。这个方案适合谁日常要做功能测试、经常画测试点思维导图的测试工程师以及带团队想统一测试设计规范的测试负责人。前者拿来省时间后者拿来做标准沉淀。团队里只要有一个人能跑通Python脚本其他人直接用生成好的文件就行。2. 方案选型为什么是Coze加Python加Xmind2.1 Coze工作流对比直接调大模型API方案调研阶段我对比过几条路线方案优点缺点直接调大模型API灵活、可控、成本与模型绑定提示词要自己管理输出格式不稳定要写大量后处理代码Coze工作流可视化编排、内置模型选择、输出格式可通过提示词固定、无需关心部署依赖平台复杂逻辑节点调试稍麻烦本地部署开源模型数据不出内网、完全可控需要GPU资源效果不一定追得上前沿模型我最后选了Coze核心原因是它把“提示词版本管理”和“工作流编排”这两件事直接从代码里解放出来了。在Coze上调整提示词团队里不懂代码的测试同学也能操作不用每次改个措辞都来找开发。而且Coze提供标准的API接口Python侧只需要做简单的HTTP请求比直接接大模型API去解析流式输出省事得多。这里要注意一个细节很多人分不清“Coze Bot”和“Coze工作流”的区别。Bot是一个完整的智能体自带人设、开场白、技能适合面向用户的交互场景。工作流是Bot内部的一个流程编排能力更像一个可调用的函数。我这个方案实际用的是工作流能力但对外暴露方式也是一个Bot这个后面实操部分会讲清楚。2.2 Xmind文件格式这件事没你想的那么玄生成Xmind文件第一步得搞清楚Xmind文件内部是什么结构。Xmind文件本质上是一个ZIP压缩包里面装着结构化数据。Xmind 2020之后的版本核心数据存在content.json里以JSON格式描述整棵思维导图的树形结构。简单理解一个主题节点就是一个JSON对象子节点挂在children.attached下面。我用最小能打开的Xmind文件结构说明一下{ id: root-id, class: topic, title: 测试点总览, children: { attached: [ { id: child-id-1, class: topic, title: 登录模块, children: { attached: [] } } ] } }id字段要唯一class固定是topictitle就是节点显示的文字。知道这个结构之后Python生成Xmind文件就变成了两件事组织JSON结构再压缩成ZIP。zipfile标准库就能完成不需要额外安装重量级依赖。这个认知很重要。网上有很多教程让你装专门的Xmind生成库那些库要么年久失修要么只支持旧版Xmind格式反而容易踩坑。手写一个简单地生成器一套代码管住结构出问题也好排查。2.3 方案全景Coze负责思考Python负责执行这条流水线各环节的职责划分得很清楚Coze平台承载工作流管理大模型提示词接收文档内容输出JSON或Markdown格式的测试点清单。Python脚本负责从需求文档提取文本、调用Coze接口、把AI输出解析成层级数据、生成Xmind文件。Xmind文件最终交付物供测试组直接查看或继续编辑。我做这个项目时还考虑到一点团队里用Xmind的版本可能不一致。老版本的Xmind 8和2020之后的版本对ZIP内部JSON的解析要求略有差异。所以实际操作中我给Python脚本留了一个开关默认生成新版Xmind的JSON格式如果同事反馈打不开可以一键切换成“生成Markdown文件再手动导入Xmind”的模式。Xmind本身就支持Markdown导入标题层级就是导图层级兼容性最好。3. 核心细节拆解提示词设计与输出约束3.1 给AI的提示词究竟该怎么写这个项目里提示词质量直接决定测试点质量。我第一版用的提示词很简陋就一句“分析下面的需求文档列出测试点”结果输出非常飘有的给的是页面元素描述而不是测试场景有的是长篇大论毫无结构。后来我把提示词按“角色 任务 输入格式 输出要求 示例约束”五段式来组织效果好很多。参考模板如下你是一名有十年经验的测试工程师擅长功能测试设计。 请基于我提供的需求文档内容整理出完整、可执行的测试点清单。 要求 1. 先按功能模块分组再在模块下列出测试点。 2. 每个测试点必须覆盖正常流程、异常流程、边界值、权限/安全性等维度。 3. 测试点用一句话描述清楚“测什么、验证什么”。 4. 输出格式为JSON结构为 { module: 模块名, points: [ {case: 测试点描述, priority: P0/P1/P2, type: 功能/边界/异常/权限} ] } 5. 整个输出必须是一个合法的JSON数组不要添加任何多余说明文字。 6. 如果需求文档中信息不足对于必须考虑但未明确的测试点可以结合行业常识补充并在描述中标注“隐含需求”。 需求文档内容 {{input_text}}这里面几个设计点值得展开。要求4把输出格式限定为JSON数组这是为了后面Python解析方便。如果AI输出的是大段散文解析只能靠正则硬抠总会有边界问题。要求5是尽力让输出纯净少了它AI经常在JSON前面加一段“好的我已经分析完了”之类的废话。要求6是为了对抗信息缺失。需求文档不是完美的如果严格执行“只测文档上写的内容”很多隐含逻辑根本出不来。加上这句之后AI会主动补充常见场景虽然偶尔会过度发挥但同一份测试点清单人工审起来比反复和产品确认要快。3.2 从AI输出到Xmind结构中间层做什么AI输出JSON数组后不能直接变成Xmind。中间要有一个转换层职责有两个校验和层级映射。校验这一环很多人忽略。大模型的输出偶然会出现JSON截断、字段缺失、重复数据。如果脚本直接拿解析失败的数据去生成文件轻则导图不完整重则整个文件打不开。我在这层做了三件事用json.loads尝试解析解析失败时截取最接近合法JSON的段落再试一次检查必填字段是否存在对完全解析不出来的情况直接返回错误信息而不是硬生成文件。层级映射要解决的是“模块、子模块、测试点”怎么落到Xmind的树上。我定义的映射规则是根节点需求标题或“XX模块测试点”。第一层功能模块JSON里的module。第二层测试分类type字段如功能、边界、异常、权限。第三层具体测试点case字段。为什么不直接把所有测试点平铺挂在模块下面因为Xmind导图层级太浅信息挤在一块可读性差。按测试类型分一层一眼就能看出某个模块的边界用例覆盖够不够。3.3 需求文档的清洗与分段策略大模型对输入长度是有限制的一份几十页的产品需求文档很可能超长。一开始我把整份Word文本一股脑塞给Coze结果报错信息提示“输入超长”。后来我做了两步处理。第一步是文本提取。Word文档用python-docx读取PDF用pdfplumberMarkdown直接读原文。提取后用正则清洗掉重复的空行、无意义的制表符和图片占位符。第二步是分段。如果文本长度超过预设阈值比如8000字符按章节标题切段然后把段落分发到多次调用。这里有个取舍分段会让AI丢失部分上下文更容易漏掉跨模块的公共逻辑。我的对策是每次分段时保留该段所在章节的一级标题作为前缀让AI至少知道这段内容属于哪个模块。实操中发现大多数中等规格的需求文档单次调用就能完成只有那种几十页的大型需求才需要分段。所以脚本里分段逻辑要写成可选开关默认关闭。4. 实操全流程从Coze配置到本地脚本落地4.1 在Coze上搭建需求分析工作流Coze平台的界面版本更新频繁但核心搭建逻辑是稳定的。第一步是创建应用或Bot进入工作流编排页面。工作流我配置了三个节点开始节点定义输入参数我设置了两个字段一个是doc_title需求标题一个是doc_content需求文本。大模型节点引用前面写的提示词模板把doc_content注入到提示词的{{input_text}}位置。模型我选了当前平台默认的强模型如果想控制成本普通需求用中档模型也够。结束节点输出大模型节点的结果定义为result。整个工作流核心就是这三步。很多教程会把工作流配置得很复杂加各种分支和插件但在这个场景里没必要。测试点分析是一个单一任务复杂流程反而提高了出错率。工作流测试通过后要发布成API或者挂到Bot下面。发布后Coze会生成一个API调用凭证和Bot ID这些参数后面Python脚本要用。4.2 用Python调用Coze接口Coze的API设计和主流大模型服务商类似都是HTTP请求加Bearer Token认证。下面这段代码可以完成一次对话调用import requests def ask_coze(bot_id, user_input, pat_token): api_url https://api.coze.cn/v3/chat headers { Authorization: fBearer {pat_token}, Content-Type: application/json } payload { bot_id: bot_id, user_id: qa_auto, stream: False, messages: [ {role: user, content: user_input} ] } resp requests.post(api_url, headersheaders, jsonpayload, timeout120) resp.raise_for_status() data resp.json() # 实际返回结构以平台文档为准一般取响应中的message内容 return data[data][content]user_input这里传的不是原始需求文档而是把提示词和文档拼接后的完整请求。接口调用有两点要注意。一是超时时间要设置得足够长大模型分析长文档可能耗时几十秒甚至一分钟默认的请求超时很容易误判失败。二是要做异常重试网络抖动、平台限流是常态我写了简单重试机制最多重试三次每次间隔递增。4.3 把测试点写成Xmind文件的核心代码拿到AI输出的JSON后生成Xmind文件的核心逻辑分两层一层是把JSON数组转成树形结构另一层是用zipfile写ZIP。先看树形转换这一层。我定义了一个递归函数把包含子节点的字典列表转成Xmind的topic格式import uuid def build_topic(title, childrenNone): topic { id: str(uuid.uuid4()), class: topic, title: title } if children: topic[children] {attached: children} return topic def convert_to_xmind_tree(data_list, root_title): root build_topic(root_title) for module in data_list: module_title module.get(module, 未命名模块) module_node build_topic(module_title) # 按测试类型分组作为第二层 groups {} for point in module.get(points, []): ptype point.get(type, 功能) groups.setdefault(ptype, []).append(point) for ptype, points in groups.items(): type_node build_topic(ptype) for p in points: case_title f{p.get(case, )} [{p.get(priority, P2)}] type_node[children][attached].append(build_topic(case_title)) module_node[children][attached].append(type_node) root[children][attached].append(module_node) return root这里把优先级直接拼在测试点标题后面技术上比用“优先级”标签更简单。Xmind当然支持标签功能但手写标签需要额外的数据字段文件结构也复杂一些。为了稳定起见我选择了标题后缀这种朴素方式。几轮验证下来Xmind打开完全正常团队同事也没觉得难用。再来看ZIP打包import json import zipfile def save_xmind(root_topic, output_path): content_json json.dumps({id: root_topic[id], class: sheet, title: root_topic[title], rootTopic: root_topic}, ensure_asciiFalse, indent2) metadata_json json.dumps({ creator: {name: Xmind, version: 1.0} }, ensure_asciiFalse) with zipfile.ZipFile(output_path, w, zipfile.ZIP_DEFLATED) as zf: zf.writestr(content.json, content_json) zf.writestr(metadata.json, metadata_json)经过测试这种最小结构就能被Xmind正常打开。有些版本的Xmind还会生成manifest.json和缩略图但我实测不做也不影响。有一个细节值得提ensure_ascii一定要设成False否则中文全部变成\uXXXX转义序列Xmind虽然能正常显示但文件体积变大、人类无法直接阅读排查问题时会很痛苦。4.4 完整脚本串起来跑一遍除了上面两个核心函数完整脚本还要包含文档解析和主流程控制。整个脚本的调用关系是# 主流程伪代码 doc_path 需求文档.docx bot_id your_bot_id pat_token your_pat_token text extract_text(doc_path) # 提取需求文本 prompt build_prompt(text) # 拼接提示词 ai_output ask_coze(bot_id, prompt, pat_token) # 调用Coze data_list parse_ai_output(ai_output) # 解析JSON root_topic convert_to_xmind_tree(data_list, XX项目测试点) save_xmind(root_topic, 测试点.xmind)text前面几步都用了几段真实需求文档测试其中一段是一份带有用户注册、登录、密码找回的账务系统需求。AI生成的测试点覆盖了必填项校验、密码强度、短信验证码错误重试、找回流程中用户不存在等场景整体质量在可用水平之上。个别缺失的边界场景人工补一下就能进评审会。4.5 实测效果一份文档从“拿到”到“可用”要多长时间我拿一份12页、约8000字的Web后台需求文档做了完整测试。从脚本执行到Xmind文件生成总共耗时1分40秒其中Coze大模型分析占大头Python脚本本身不到2秒。生成的导图包含6个模块、63个测试点层级结构是“根节点 → 模块 → 测试类型 → 具体测试点”。人工从零画一份相同规格的导图我自己的水平大概需要90分钟而且大概率漏掉两三个边界场景。这个效率差异足够说明问题了。5. 常见问题与排查技巧实录5.1 AI分析结果不稳定有时候漏模块有时候编需求这是整个方案里最需要关注的问题。大模型不是数据库输出天然有随机性。同一份文档跑两次结果可能不同。我试过提高“温度参数”temperature和降低它。温度太高输出发散甚至编造不存在的功能温度太低输出保守隐含需求补充得少。实际操作中我把温度控制在0.3到0.5之间再配合提示词明确说“结合文档信息和行业常识合理推断不要编造”。对“漏模块”的问题最有效的手段是让AI先输出“文档里提到的所有功能模块清单”再逐模块展开测试点。把“先列提纲、再逐项分析”这个步骤拆进提示词里结构化程度明显提升。另一个经验是Coze工作流里的模型版本会影响效果。同一份提示词换成更强的模型后输出质量提升明显。如果条件允许优先选择最新最强的模型来跑分析任务成本高一点但省去大量人工修补时间。5.2 Coze接口返回报错认证失败、超时、限流认证失败最常见的原因是Token配置错误。Coze的Token在平台个人访问令牌页面生成复制时容易多复制空格或者只复制了一半建议用环境变量保存而不是硬编码在脚本里。超时问题前面提过HTTP请求超时要设长。Coze接口处理长文档可能超过30秒我用的是120秒超时暂时够用。限流问题出现在批量跑任务的时候。一次性提交十几个文档接口开始报429或者“rate limit”错误。解决方法是在脚本里加入令牌桶或者简单延时每次请求完了time.sleep(1)到3秒。5.3 生成的Xmind文件打不开或打开后空白这个坑我踩过。Xmind文件虽然本质是ZIP但对内部文件的组织顺序有要求而且不同版本要求略有差异。最稳妥的做法是自己先验证用Python重新打开生成的ZIP确认content.json存在且能被json.loads正常解析。如果打开后空白大概率是content.json里根节点结构不对。我排查过的一个案例是class字段写成了root导致Xmind不认识。正确值应该是sheet包裹rootTopictopic节点的class固定为topic。还有一种兼容性方案不直接生成Xmind而是让Python把AI的输出整理成Markdown文件然后用Xmind的“导入 → Markdown”功能。这个方案的好处是不依赖Xmind内部格式只要Markdown语法正确就能导入可以作为兜底方案提供给打不开文件的同事。5.4 需求文档里有表格和图片提取的时候丢了需求文档里的表格往往包含关键的业务规则比如权限配置表、字段约束表。直接用python-docx读取段落会漏掉表格内容。我的处理方式是单独遍历文档中的表格对象把每个表格转成近似Markdown表格格式的文本再拼接到正文后面。图片的情况更复杂。大模型本身具备多模态能力Coze也支持图片输入但流程会复杂很多而且测试点分析对截图的依赖程度没有很高的业务规则依赖高。当前版本我的策略是先提示用户把关键业务截图用文字补充说明如果确实需要图片分析下一步再扩展Coze工作流接入图片输入节点。5.5 总结几条能直接用的避坑清单按重要级排列Coze发布API后bot_id和Token分开存储不要写死在代码库防止泄露。提示词里输出JSON的要求一定要写在最后离输入文本最近的位置模型对这部分记忆更清晰。Python解析AI输出时先做JSON修复再写文件不要省这一步。Xmind文件生成后用zipfile读回校验一次再交付成本极低。建议保留一份固定格式的需求文档模板给产品同学用。格式规范的文档AI分析的准确率会高出不少。AI的产出只能当初稿正式进测试评审前必须有测试负责人审核一遍尤其是涉及支付、权限、安全相关的高优场景。这个方案运行了一段时间后我又加了一个小的功能把AI返回的原始JSON存到本地留档这样如果后续发现某个测试点缺失还能回溯到底是AI漏了还是人工删了。整个过程做下来我的体会是把AI接入测试设计流程重点不是让AI取代测试人员而是先把重复性最高的初稿工作自动化把时间留给更值得人肉去思考的需求判断和风险确认。最后分享一个小技巧如果你和我一样经常要和Coze返回的JSON格式作斗争可以在提示词末尾加上一句“请直接输出JSON不要使用代码块包裹”这个改动立竿见影能省掉不少后处理的时间。