一直以为测试用例只能靠人肉一条条写直到我把 Coze 工作流接上需求文档生成效率和用例覆盖度直接提升了一大截。这篇文章就聊聊我搭的一套“Coze 自动生成测试用例”工作流它怎么拆解需求、按测试设计方法自动产出功能测试用例以及怎么把用例进一步变成 Playwright 可直接执行的脚本。如果你是测试工程师、QA Lead或者正在搭团队测试基建的开发这套方案能帮你把“写用例”这个重复劳动大幅压缩。下面直接进入正题我会把工作流的设计思路、节点配置、提示词模板和踩坑记录都摊开讲。1. 为什么我会用 Coze 写测试用例1.1 写用例的痛点重复、零散、靠经验做功能测试的人都有这种感觉新版本来了需求文档堆成山用例要一条条写而且很多模块长得都差不多——登录、列表、筛选、详情、编辑、删除来回就那几套逻辑。真正费时间的不是设计是把同样结构的用例反复打字还要费劲去对齐字段格式、前置条件和预期结果。更麻烦的是用例质量完全取决于写的人。资深测试知道要补边界值、异常流、权限校验新人往往只写了主流程happy path一上线就漏测。这个痛点靠“加强培训”解决不了靠“让测试多花时间”更不现实得把测试设计方法本身固化到工具里让人人都能按统一标准产出高质量用例。1.2 为什么选 Coze 而不是直接裸调大模型直接打开一个聊天窗口让大模型生成用例我也试过。效果怎么说呢——能出东西但没法用进工作流没有固定模板、格式飘忽不定、漏场景、编功能最要命的是每个人每次问出来的东西都不一样没有沉淀价值。Coze 的价值在于它把大模型能力包装成了可编排的工作流输入可以是文件、文本、URL中间可以有文档解析、知识库检索、代码执行、条件分支输出可以固定成 Markdown、JSON、表格甚至转成 Word 文档。也就是说我可以把“测试工程师写用例的思路”整个复制到工作流里变成标准流程。同一份需求文档丢进去无论谁操作、操作多少次产出的用例结构都一致质量下限被兜住了。另外 Coze 是浏览器即开即用的平台不用自己部署模型服务团队里任何人打开链接就能用。这点对测试团队特别友好不需要所有人都会写提示词只需要一两个人把工作流搭好其他成员直接上传文档等结果就行。1.3 这套方案能覆盖哪些测试场景我实际验证过三类场景功能测试用例生成给 PRD 或需求描述输出覆盖正常流、异常流、边界值的用例表格这是最常用的场景也是本文的主线。自动化脚本辅助生成在功能用例基础上让 LLM 按 Playwright 语法输出可执行脚本。不是全自动生成能直接跑的全部脚本而是把每个用例对应的操作步骤和断言逻辑先写出来人工微调后即可执行。单元测试用例设计如果给到函数源码或接口定义Coze 也能按单元测试用例设计方法分支覆盖、边界覆盖、异常输入组合生成单测用例框架。这一块我目前只做了轻量验证效果不如功能测试那么惊艳但作为补充场景也够用。下面重点讲功能测试用例生成这条主线因为它是整个工作流里收益最明显、最值得复制的部分。2. 核心思路把测试设计方法固化到工作流里2.1 工作流节点的角色划分我搭的工作流和大多数“一条链走到底”的简单流程有个重要区别它不是让一个大模型节点从需求直接吐一堆用例而是拆成了三个阶段、三个节点每个节点承担不同角色。节点阶段角色定位核心任务需求理解业务分析师从需求文档提取功能点、业务规则、字段约束、用户角色用例生成测试设计工程师基于提取出的规则按测试设计方法展开用例质量审查测试组长检查漏测项、重复项、格式规范补充边界值和异常流为什么这样拆直接让大模型“读完需求就写用例”它在超长上下文里很容易顾此失彼前面提到的字段约束写到后面忘了主流程用例生成了十几条异常流一条没有。这是我在实测中最常见的问题也是最影响可用性的点。拆成三阶段之后每个节点输入输出都是结构化的中间产物——先有功能点和规则清单再基于清单生成用例最后再让审查节点专门“找茬”补漏。相当于模拟了一个测试组长的干活流程先理解需求、再设计用例、最后自查一遍。实测这样拆解后用例覆盖度明显提升尤其是边界值和异常流。2.2 提示词里要写清楚的五要素不管工作流搭得多花哨核心还是提示词设计。提示词写得好不好直接决定用例质量。我在反复调优后把测试用例生成的提示词固定成五个要素角色定义让模型明确自己是资深测试工程师熟悉等价类划分、边界值分析、场景法、错误推测法。输入来源说明用例要基于上一节点提取的功能点和业务规则不要自己编造不存在的功能。输出结构规定每条用例必须包含用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级七个字段且步骤用编号列表。覆盖要求明确要求覆盖正常流、异常流、边界值、权限校验每条需求必须至少有正常流和异常流各一条。格式约束最终输出为 Markdown 表格方便后续转 Word 或导入测试管理平台。提示词模板我放在第 3 部分的配置里你可以直接抄。2.3 从需求描述到用例字段的映射这里再往深挖一层为什么说“先把需求转成功能清单”就能提升用例质量关键在于业务规则和字段约束是测试用例的原材料。举个例子需求文档里写“用户名支持 6-20 位字母或数字”这句话在原始文档里可能埋在好几段文字中间让模型直接生成用例它很容易只写一条“输入正确的用户名密码登录成功”就完事了。但如果先有一个节点专门做信息抽取把这句话抽成结构化规则username: 6-20位字母数字必填那生成节点就拿到了非常明确的边界值测试输入5位、6位、20位、21位、含特殊字符、为空、纯数字、纯字母……用例自然就详细了。所以在设计时我特意把“输入格式、长度、是否必填、业务状态流转、不同角色权限”这些内容单独抽出来放进一个功能清单里。这一步是整个工作流比裸聊大模型强的最关键原因。3. 实操搭建从上传需求文档到输出表格3.1 准备工作账号与材料用 Coze 工作流需要先有个账号浏览器打开平台注册即可。我建议直接在工作流编辑页面操作不用先建 Bot因为测试用例生成的核心逻辑都在工作流里Bot 只是外层封装。需要准备的材料很简单一份真实的需求文档格式可以是 txt、pdf、docx 或 markdown。强烈建议用 markdown 格式解析效果最稳定。明确的输出要求先想清楚你要的是 Markdown 表格还是 Word 文档。被测系统的基本信息比如用户角色、模块划分、常见权限规则这些可以作为固定配置写进系统提示词里。3.2 输入节点与文档解析配置工作流第一件事是接收用户的输入。我配置了两种输入方式直接粘贴需求文本适合小文档省去解析环节上传文件适合 PRD、需求说明书走文件解析节点提取文本文件解析节点配置时要注意一个细节大文档一定要做截断或分段处理。Coze 的文件解析节点会对内容长度有限制我之前传过一个 50 多页的 PRD解析出来后被截掉了后半段功能点直接少了一大半。后来我把文档按照章节拆成多个文件每个文件单独走一轮生成流程再汇总结果彻底解决了这个问题。如果你不想手动拆文档也可以在工作流里加一个文本处理节点按标题关键字如“第X章”“功能需求”自动切分文本再循环处理。这个方案更优雅但配置复杂度高一些新手可以先手动拆。3.3 LLM 节点参数与提示词模板工作流里需要三个 LLM 节点参数基本一致重点在提示词不同。我用的核心参数如下模型选择效果较好的版本具体按平台当前可用模型选效果优先温度0.2 左右。生成测试用例不是创意写作要求稳定、可控、可复现。温度过高会让每次输出的用例结构漂移同一份需求两次生成结果完全不同非常难受最大 token建议 4000 以上否则用例一多就会输出截断输出格式如果平台支持 JSON 模式建议开启方便后续节点处理第一个节点需求理解的提示词我写得很简洁你是一名资深业务分析师。请提取用户提供需求文档中的功能点和业务规则。 要求 1. 按模块归类列出所有功能点 2. 对每个功能点标注涉及的字段、输入约束长度/格式/必填性、业务状态、角色权限 3. 不要遗漏异常场景相关的规则如密码错误次数限制、超时、并发等 4. 输出格式Markdown 列表按【模块名】分组第二个节点用例生成的提示词是核心我也直接贴出来你是资深测试工程师请基于下面的功能点和业务规则设计功能测试用例。 功能点和规则 {{function_list}} 要求 1. 使用等价类划分、边界值分析、场景法、错误推测法设计用例 2. 每个功能点至少覆盖正常流、异常流、边界值 3. 涉及权限的功能需包含无权限/低权限访问用例 4. 每条用例格式如下 | 用例编号 | 所属模块 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 5. 测试步骤内部用 1. 2. 3. 编号预期结果必须可验证 6. 不要生成与输入规则无关的用例第三个节点质量审查的提示词核心是“找茬”你是一位严格的测试组长审查下面的测试用例清单。 审查重点 1. 是否有遗漏的边界值如列表为空、单条数据、最大数量、超过最大数量 2. 是否有缺失的异常流如接口超时、服务端报错、非法输入 3. 是否有重复用例或相似用例需要合并 4. 用例标题是否清晰预期结果是否具体可验证 5. 补充你发现的所有遗漏用例直接输出完整的用例清单不要只输出修改意见3.4 输出节点Markdown 表格与 Word 导出第三个节点输出的 Markdown 表格已经可以直接复制使用。但我在实际使用时发现测试团队更习惯把用例导出成 Word 或 Excel 文档去评审所以我在工作流最后加了一个输出环节把 Markdown 转成 Word。Coze 平台里文件处理能力升级后文档生成这块体验好了不少。我走的方案是用代码节点运行 Python 脚本把 LLM 输出的 Markdown 表格解析成 docx 文件关键处理包括中文字体设置为宋体、表格自动加边框、用例标题行加粗。核心代码逻辑大概是from docx import Document from docx.shared import Pt from docx.oxml.ns import qn doc Document() doc.styles[Normal].font.name Times New Roman doc.styles[Normal]._element.rPr.rFonts.set(qn(w:eastAsia), 宋体) doc.add_heading(功能测试用例, level0) table doc.add_table(rows1, cols7) table.style Table Grid # 表头写入 headers [用例编号, 所属模块, 用例标题, 前置条件, 测试步骤, 预期结果, 优先级] for i, h in enumerate(headers): table.rows[0].cells[i].text h # 按行解析markdown表格并写入不过说实话这步配置对不熟 Python 的朋友有一定门槛。如果你不想折腾代码也可以让 LLM 输出一个标准 CSV 格式的用例清单然后用 Excel 打开另存为即可不用额外写代码。两条路都可行优先级看你自己习惯。4. 进阶玩法让 Coze 输出的用例直接驱动 Playwright4.1 为什么功能用例和自动化脚本可以一起生成这是我从“生成给人看的用例”跨到“生成给机器跑的用例”的关键一步。功能测试用例和 Playwright 自动化脚本之间本质上共享同一个信息源操作步骤和预期结果。人工写自动化脚本时也是先把测试步骤翻译成 page 操作再把预期结果翻译成断言。那这个过程同样可以交给 LLM。区别在于自动化脚本对格式要求极其严格——选择器写错一个字符就定位不到元素断言方法用错就直接报错。所以这个节点不能像生成功能用例那样自由发挥必须在提示词里给出非常严格的约束。4.2 让 LLM 输出稳定可执行的 Playwright 代码我在工作流里的“脚本生成”节点是这样配置的输入上一步生成的用例清单提示词中明确指定使用 Playwright 的sync_playwrightAPI要求只使用page.goto / page.fill / page.click / page.wait_for_selector / page.inner_text这些基础稳定方法不要用复杂的 xpath优先使用id、placeholder、>from playwright.sync_api import sync_playwright def test_login_positive(): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(http://your-app/login) page.fill(#username, valid_user) page.fill(#password, valid_pass) page.click(#login-btn) page.wait_for_selector(.dashboard) assert page.inner_text(.user-info) valid_user browser.close()这一步生成的脚本说实话直接运行的概率不是 100%但已经能替代 70% 的机械编码工作。剩下的 30% 主要是元素定位修正和特殊业务逻辑处理这部分工作量和纯手写相比已经非常划算了。4.3 关于选择器稳定性的一个经验这里有个我踩过几次的坑AI 很喜欢自己去猜定位器比如page.click(text登录)、page.locator(div.login-form button)这类选择器在页面小改版后就会挂。所以我在提示词里专门加了一句所有元素必须使用配置的元素映射表中提供的 id 或>
一直以为测试用例只能靠人肉一条条写直到我把 Coze 工作流接上需求文档生成效率和用例覆盖度直接提升了一大截。这篇文章就聊聊我搭的一套“Coze 自动生成测试用例”工作流它怎么拆解需求、按测试设计方法自动产出功能测试用例以及怎么把用例进一步变成 Playwright 可直接执行的脚本。如果你是测试工程师、QA Lead或者正在搭团队测试基建的开发这套方案能帮你把“写用例”这个重复劳动大幅压缩。下面直接进入正题我会把工作流的设计思路、节点配置、提示词模板和踩坑记录都摊开讲。1. 为什么我会用 Coze 写测试用例1.1 写用例的痛点重复、零散、靠经验做功能测试的人都有这种感觉新版本来了需求文档堆成山用例要一条条写而且很多模块长得都差不多——登录、列表、筛选、详情、编辑、删除来回就那几套逻辑。真正费时间的不是设计是把同样结构的用例反复打字还要费劲去对齐字段格式、前置条件和预期结果。更麻烦的是用例质量完全取决于写的人。资深测试知道要补边界值、异常流、权限校验新人往往只写了主流程happy path一上线就漏测。这个痛点靠“加强培训”解决不了靠“让测试多花时间”更不现实得把测试设计方法本身固化到工具里让人人都能按统一标准产出高质量用例。1.2 为什么选 Coze 而不是直接裸调大模型直接打开一个聊天窗口让大模型生成用例我也试过。效果怎么说呢——能出东西但没法用进工作流没有固定模板、格式飘忽不定、漏场景、编功能最要命的是每个人每次问出来的东西都不一样没有沉淀价值。Coze 的价值在于它把大模型能力包装成了可编排的工作流输入可以是文件、文本、URL中间可以有文档解析、知识库检索、代码执行、条件分支输出可以固定成 Markdown、JSON、表格甚至转成 Word 文档。也就是说我可以把“测试工程师写用例的思路”整个复制到工作流里变成标准流程。同一份需求文档丢进去无论谁操作、操作多少次产出的用例结构都一致质量下限被兜住了。另外 Coze 是浏览器即开即用的平台不用自己部署模型服务团队里任何人打开链接就能用。这点对测试团队特别友好不需要所有人都会写提示词只需要一两个人把工作流搭好其他成员直接上传文档等结果就行。1.3 这套方案能覆盖哪些测试场景我实际验证过三类场景功能测试用例生成给 PRD 或需求描述输出覆盖正常流、异常流、边界值的用例表格这是最常用的场景也是本文的主线。自动化脚本辅助生成在功能用例基础上让 LLM 按 Playwright 语法输出可执行脚本。不是全自动生成能直接跑的全部脚本而是把每个用例对应的操作步骤和断言逻辑先写出来人工微调后即可执行。单元测试用例设计如果给到函数源码或接口定义Coze 也能按单元测试用例设计方法分支覆盖、边界覆盖、异常输入组合生成单测用例框架。这一块我目前只做了轻量验证效果不如功能测试那么惊艳但作为补充场景也够用。下面重点讲功能测试用例生成这条主线因为它是整个工作流里收益最明显、最值得复制的部分。2. 核心思路把测试设计方法固化到工作流里2.1 工作流节点的角色划分我搭的工作流和大多数“一条链走到底”的简单流程有个重要区别它不是让一个大模型节点从需求直接吐一堆用例而是拆成了三个阶段、三个节点每个节点承担不同角色。节点阶段角色定位核心任务需求理解业务分析师从需求文档提取功能点、业务规则、字段约束、用户角色用例生成测试设计工程师基于提取出的规则按测试设计方法展开用例质量审查测试组长检查漏测项、重复项、格式规范补充边界值和异常流为什么这样拆直接让大模型“读完需求就写用例”它在超长上下文里很容易顾此失彼前面提到的字段约束写到后面忘了主流程用例生成了十几条异常流一条没有。这是我在实测中最常见的问题也是最影响可用性的点。拆成三阶段之后每个节点输入输出都是结构化的中间产物——先有功能点和规则清单再基于清单生成用例最后再让审查节点专门“找茬”补漏。相当于模拟了一个测试组长的干活流程先理解需求、再设计用例、最后自查一遍。实测这样拆解后用例覆盖度明显提升尤其是边界值和异常流。2.2 提示词里要写清楚的五要素不管工作流搭得多花哨核心还是提示词设计。提示词写得好不好直接决定用例质量。我在反复调优后把测试用例生成的提示词固定成五个要素角色定义让模型明确自己是资深测试工程师熟悉等价类划分、边界值分析、场景法、错误推测法。输入来源说明用例要基于上一节点提取的功能点和业务规则不要自己编造不存在的功能。输出结构规定每条用例必须包含用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级七个字段且步骤用编号列表。覆盖要求明确要求覆盖正常流、异常流、边界值、权限校验每条需求必须至少有正常流和异常流各一条。格式约束最终输出为 Markdown 表格方便后续转 Word 或导入测试管理平台。提示词模板我放在第 3 部分的配置里你可以直接抄。2.3 从需求描述到用例字段的映射这里再往深挖一层为什么说“先把需求转成功能清单”就能提升用例质量关键在于业务规则和字段约束是测试用例的原材料。举个例子需求文档里写“用户名支持 6-20 位字母或数字”这句话在原始文档里可能埋在好几段文字中间让模型直接生成用例它很容易只写一条“输入正确的用户名密码登录成功”就完事了。但如果先有一个节点专门做信息抽取把这句话抽成结构化规则username: 6-20位字母数字必填那生成节点就拿到了非常明确的边界值测试输入5位、6位、20位、21位、含特殊字符、为空、纯数字、纯字母……用例自然就详细了。所以在设计时我特意把“输入格式、长度、是否必填、业务状态流转、不同角色权限”这些内容单独抽出来放进一个功能清单里。这一步是整个工作流比裸聊大模型强的最关键原因。3. 实操搭建从上传需求文档到输出表格3.1 准备工作账号与材料用 Coze 工作流需要先有个账号浏览器打开平台注册即可。我建议直接在工作流编辑页面操作不用先建 Bot因为测试用例生成的核心逻辑都在工作流里Bot 只是外层封装。需要准备的材料很简单一份真实的需求文档格式可以是 txt、pdf、docx 或 markdown。强烈建议用 markdown 格式解析效果最稳定。明确的输出要求先想清楚你要的是 Markdown 表格还是 Word 文档。被测系统的基本信息比如用户角色、模块划分、常见权限规则这些可以作为固定配置写进系统提示词里。3.2 输入节点与文档解析配置工作流第一件事是接收用户的输入。我配置了两种输入方式直接粘贴需求文本适合小文档省去解析环节上传文件适合 PRD、需求说明书走文件解析节点提取文本文件解析节点配置时要注意一个细节大文档一定要做截断或分段处理。Coze 的文件解析节点会对内容长度有限制我之前传过一个 50 多页的 PRD解析出来后被截掉了后半段功能点直接少了一大半。后来我把文档按照章节拆成多个文件每个文件单独走一轮生成流程再汇总结果彻底解决了这个问题。如果你不想手动拆文档也可以在工作流里加一个文本处理节点按标题关键字如“第X章”“功能需求”自动切分文本再循环处理。这个方案更优雅但配置复杂度高一些新手可以先手动拆。3.3 LLM 节点参数与提示词模板工作流里需要三个 LLM 节点参数基本一致重点在提示词不同。我用的核心参数如下模型选择效果较好的版本具体按平台当前可用模型选效果优先温度0.2 左右。生成测试用例不是创意写作要求稳定、可控、可复现。温度过高会让每次输出的用例结构漂移同一份需求两次生成结果完全不同非常难受最大 token建议 4000 以上否则用例一多就会输出截断输出格式如果平台支持 JSON 模式建议开启方便后续节点处理第一个节点需求理解的提示词我写得很简洁你是一名资深业务分析师。请提取用户提供需求文档中的功能点和业务规则。 要求 1. 按模块归类列出所有功能点 2. 对每个功能点标注涉及的字段、输入约束长度/格式/必填性、业务状态、角色权限 3. 不要遗漏异常场景相关的规则如密码错误次数限制、超时、并发等 4. 输出格式Markdown 列表按【模块名】分组第二个节点用例生成的提示词是核心我也直接贴出来你是资深测试工程师请基于下面的功能点和业务规则设计功能测试用例。 功能点和规则 {{function_list}} 要求 1. 使用等价类划分、边界值分析、场景法、错误推测法设计用例 2. 每个功能点至少覆盖正常流、异常流、边界值 3. 涉及权限的功能需包含无权限/低权限访问用例 4. 每条用例格式如下 | 用例编号 | 所属模块 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 5. 测试步骤内部用 1. 2. 3. 编号预期结果必须可验证 6. 不要生成与输入规则无关的用例第三个节点质量审查的提示词核心是“找茬”你是一位严格的测试组长审查下面的测试用例清单。 审查重点 1. 是否有遗漏的边界值如列表为空、单条数据、最大数量、超过最大数量 2. 是否有缺失的异常流如接口超时、服务端报错、非法输入 3. 是否有重复用例或相似用例需要合并 4. 用例标题是否清晰预期结果是否具体可验证 5. 补充你发现的所有遗漏用例直接输出完整的用例清单不要只输出修改意见3.4 输出节点Markdown 表格与 Word 导出第三个节点输出的 Markdown 表格已经可以直接复制使用。但我在实际使用时发现测试团队更习惯把用例导出成 Word 或 Excel 文档去评审所以我在工作流最后加了一个输出环节把 Markdown 转成 Word。Coze 平台里文件处理能力升级后文档生成这块体验好了不少。我走的方案是用代码节点运行 Python 脚本把 LLM 输出的 Markdown 表格解析成 docx 文件关键处理包括中文字体设置为宋体、表格自动加边框、用例标题行加粗。核心代码逻辑大概是from docx import Document from docx.shared import Pt from docx.oxml.ns import qn doc Document() doc.styles[Normal].font.name Times New Roman doc.styles[Normal]._element.rPr.rFonts.set(qn(w:eastAsia), 宋体) doc.add_heading(功能测试用例, level0) table doc.add_table(rows1, cols7) table.style Table Grid # 表头写入 headers [用例编号, 所属模块, 用例标题, 前置条件, 测试步骤, 预期结果, 优先级] for i, h in enumerate(headers): table.rows[0].cells[i].text h # 按行解析markdown表格并写入不过说实话这步配置对不熟 Python 的朋友有一定门槛。如果你不想折腾代码也可以让 LLM 输出一个标准 CSV 格式的用例清单然后用 Excel 打开另存为即可不用额外写代码。两条路都可行优先级看你自己习惯。4. 进阶玩法让 Coze 输出的用例直接驱动 Playwright4.1 为什么功能用例和自动化脚本可以一起生成这是我从“生成给人看的用例”跨到“生成给机器跑的用例”的关键一步。功能测试用例和 Playwright 自动化脚本之间本质上共享同一个信息源操作步骤和预期结果。人工写自动化脚本时也是先把测试步骤翻译成 page 操作再把预期结果翻译成断言。那这个过程同样可以交给 LLM。区别在于自动化脚本对格式要求极其严格——选择器写错一个字符就定位不到元素断言方法用错就直接报错。所以这个节点不能像生成功能用例那样自由发挥必须在提示词里给出非常严格的约束。4.2 让 LLM 输出稳定可执行的 Playwright 代码我在工作流里的“脚本生成”节点是这样配置的输入上一步生成的用例清单提示词中明确指定使用 Playwright 的sync_playwrightAPI要求只使用page.goto / page.fill / page.click / page.wait_for_selector / page.inner_text这些基础稳定方法不要用复杂的 xpath优先使用id、placeholder、>from playwright.sync_api import sync_playwright def test_login_positive(): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(http://your-app/login) page.fill(#username, valid_user) page.fill(#password, valid_pass) page.click(#login-btn) page.wait_for_selector(.dashboard) assert page.inner_text(.user-info) valid_user browser.close()这一步生成的脚本说实话直接运行的概率不是 100%但已经能替代 70% 的机械编码工作。剩下的 30% 主要是元素定位修正和特殊业务逻辑处理这部分工作量和纯手写相比已经非常划算了。4.3 关于选择器稳定性的一个经验这里有个我踩过几次的坑AI 很喜欢自己去猜定位器比如page.click(text登录)、page.locator(div.login-form button)这类选择器在页面小改版后就会挂。所以我在提示词里专门加了一句所有元素必须使用配置的元素映射表中提供的 id 或>
