如果你在测试团队里待过三年以上大概率见过这样的场景需求评审一结束功能测试同学开始吭哧吭哧写Excel用例自动化测试同学拿着同一条需求另起炉灶写一套脚本。同一个功能两套产出三个维护入口需求一改两边都动——这大概就是测试开发这个岗位存在感最强也最心累的瞬间。我们几个人的小组去年就在折腾这件事目标是做一套自然语言用例生成工具测试人员直接用中文写操作步骤和预期结果AI读取用例后自动生成可执行的UI自动化脚本跑完再把结果、截图和日志回填到用例管理平台。折腾了大半年结论是这条路子真能走通但和想象中不太一样核心难点不在生成脚本而在怎么让用例文本、模型输出、执行引擎三端稳定咬合。这篇文章把我们的架构、选型、踩坑和取舍一次性写清楚给想做类似工具的团队一个参考。1. 为什么用例生成成了测试开发的新分水岭1.1 被Double Write困住的测试团队你仔细想想传统自动化测试里最耗时间的其实不是写代码而是保持两套东西一致。一条中等复杂度的UI用例功能测试写文档可能要20分钟测试开发拿到文档再做元素定位、写断言、处理等待最快也要40分钟到1小时。需求一改用例文档和脚本的同步就成了无休止的体力活。这种模式的学名叫Double Write——同一个需求被人工翻译了两次每次翻译都可能引入偏差。用例文档里说输入正确的用户名密码脚本里的测试数据可能已经过期脚本里修复了某个隐藏的弹窗问题Excel里的步骤还停留在上个版本。跑完自动化报告是绿的但没人敢说它代表的是当前需求维护成本却一分没少。1.2 自然语言用例生成改变了协作关系的底层结构我们做工具的思路特朴素能不能让测试人员就用中文把步骤和预期结果写清楚翻译工作交给大模型AI读取用例里的操作步骤、目标对象、断言条件自动生成Playwright脚本跑完自动回填结果。听起来只是省掉了写脚本但实际牵动的是一整条协作链路的变化。用例从给人看的文档变成了人和AI共同维护的可执行资产。功能测试负责把业务语义写得精确测试开发负责维护生成模板和工具链的质量标准脚本退化成用例的衍生品不再需要单独维护。自动化覆盖率不再是墙上的数字因为用例本身和脚本之间只隔着一个可复现的生成过程。1.3 为什么这件事现在才跑通自然语言生成用例七八年前就有人提当时的方案多半是关键词驱动或自然语言模板解析靠正则和词表匹配。复杂句式一出现就崩产品形态也变成填表格本质上还是换了种方式写脚本没有解决语义理解问题。现在不一样了。大模型的语义理解和代码生成能力把天花板抬了起来一句在首页搜索框输入蓝牙耳机注意先清空历史搜索记录这种带隐含前置操作的描述只有LLM才能稳定拆解成可执行步骤。当然能力变强也带来新麻烦——输出不稳定、幻觉、选择器失效、SQL方言不兼容这些我们后面挨个讲。2. 工具架构拆解一条从中文用例到可执行脚本的流水线2.1 第一层用例解析与语义结构化所有流程的第一步是把一篇中文用例变成机器可读的结构化数据。我们的输入是这样的用例编号TC-1001 前置条件用户已注册昵称为Dex 步骤 1. 打开登录页 2. 输入正确的用户名和密码 3. 点击登录 期望结果跳转到首页右上角显示用户昵称Dex页面加载时间小于2秒大模型先抽取前置条件、操作步骤、期望结果和测试数据再转成一份JSON结构。这里有个容易被忽略的点结构化输出必须用JSON Schema强约束而不是让模型自由发挥。我们最开始让模型输出一个JSON结果字段命名千奇百怪后面所有下游代码都在给解析擦屁股规范成Schema之后才算稳下来。2.2 第二层工具注册与Agent编排结构化完成之后真正干活的是Agent。我们基于LangChain搭建了编排层给Agent注册了三个核心工具web_open负责页面跳转和基础导航web_action负责定位元素并执行点击、输入、悬停、截图等UI操作query_database负责在测试执行前后查询数据库做测试数据准备或结果校验。这里最关键的不是代码而是工具描述。每个工具的description必须写清楚什么时候用、参数长什么样、什么情况下会报错。Agent拆解用例步骤时本质是在做工具选择描述写得模糊它就会把输入用户名翻译成乱调一气。我们后来把工具描述当文档一样维护每个描述不低于100字这是实践里最有效的一次调优。2.3 第三层Playwright执行引擎对接Agent生成的不是直接可以跑的裸代码而是中间表示再拼接成Playwright脚本。为什么用Playwright而不是Selenium后面选型章节细说。执行层我们做了一些封装比如统一等待策略、失败自动截图、录制trace文件这样AI生成的脚本跑挂了至少能留证据。执行不是纯黑盒跑一遍就结束。每一大步执行完结果会回传给Agent判断——页面弹窗了、元素没找到、网络超时Agent会根据实际页面反馈决定是重试、换一种定位方式还是上报失败。这就是Agent编排比固定脚本强的地方它带反馈闭环能现场动态调整。2.4 第四层结果回填与人工确认闭环脚本执行完之后系统会把测试结果、执行时长、截图、trace.zip自动关联到用例管理平台的对应用例编号上。通过率只是其中一个指标我们更关注的是生成成功率和执行稳定性的分离统计。用例解析置信度低于0.85的不允许直接生成脚本会先进人工确认队列。AI可以先产出脚本但状态标记为待审核。没有这层闸门早期一定会被幻觉用例淹没——模型编一个不存在的按钮给你生成一条看似完美的脚本跑的时候才发现元素定位全是瞎编的。3. 关键技术选型为什么是这个组合3.1 模型层DeepSeek的性价比与可配置性模型选型我们做了大概两周的对比测试包括几个主流商用模型和开源部署方案最后默认模型用的是DeepSeek。核心原因是它在代码生成和指令遵循上的表现非常稳同时API成本大概只有国外头部模型的十分之一。我们内部跑大量Prompt实验一天烧几百块也不心疼这对调优阶段太重要了。一个有意思的发现是模型能力要分场景看。用例解析这种语义理解任务各家差距不大但生成Playwright代码这种长结构化输出DeepSeek的代码格式完整度和元素定位准确率表现很突出。成本允许的话我们会把核心生成链路固定用同一个模型避免不同模型输出风格差异导致后续模板适配困难。3.2 Agent框架直接用LangChain还是自己写循环这个问题我们纠结了很久。自己写Agent循环其实不难难的是配套的工具管理、记忆管理和回调系统。LangChain的价值在于这些周边组件相对成熟尤其是工具调用的报错回传机制不用自己从零造。我们用LangChain Hub管理Prompt版本几轮调优下来回滚对比都很方便。当然它也有别扭的地方抽象层多、版本升级兼容性差。项目后期我们把编排核心从LangChain的AgentExecutor迁到LangGraph用图的方式显式管理每个节点的分流和重试条件可控性上了一个台阶。我的建议是小团队起步直接用LangChain没问题但要把Agent循环理解透别只会调库不然出了问题很难排查。3.3 执行引擎Playwright相比Selenium的根本优势执行层我们没有太多犹豫就选了Playwright。最主要的理由是定位器机制。Selenium时代大家习惯了XPath和CSS强绑定页面结构一改脚本就崩。Playwright的get_by_role、get_by_text等语义化定位器对AI生成场景是降维打击——模型生成的代码更倾向于按文本找元素而不是按层级找元素这恰好是AIGC能稳定输出的方式。自动等待也是关键。AI生成的脚本最怕时序问题Selenium的sleep在页面加载慢时极不稳定。Playwright的auto-wait机制会让操作自动等待元素可交互实测下来脚本的脆性大幅下降。配合网络事件监听还能验证点击之后有没有发起正确的请求这类接口层面的效果。3.4 数据层自然语言查达梦数据库与Dify的定位UI自动化有一个绕不开的场景测试数据准备和结果校验。我们的被测系统数据落在达梦数据库上早期测试人员写SQL经常被方言和权限折磨所以专门做了一个自然语言查数据库的小模块。技术选型上用了Dify把查询意图识别、SQL生成、权限校验和结果执行串成一条Workflow。Dify在这个场景里扮演的是带护栏的翻译层用户用自然语言说查昨天创建且状态为待审核的订单数量Dify内部先做意图分类再生成SQL交给连接达梦的执行节点运行最后把结果整理成表格回给用户。关键是SQL生成之后必须先过一层安全校验强制把查询限制在只读模式自动加行数上限杜绝测试人员误操作写库。这块后面还有坑要讲。4. 让AI稳定输出可执行代码的细节工程4.1 用例文本的标准格式是地基大模型能力和LLM指令遵循再强也架不住输入文本天马行空。我们最开始让测试同学自由写用例AI解析满意度不到70%原因不是模型不行而是人写的自然语言充满歧义。后来我们定义了一套极轻量的编写规范不约束具体措辞只约束结构必须分步骤、前置条件必须单列、预期结果必须写看得到的结果而不是正常/成功这种形容词。定完这套规范解析准确率显著提升了。这里有个反直觉的结论工具的目的是让人用自然语言写用例但这个自然语言仍然需要极轻的结构约束。它不要求你改变表达习惯只要求你别把三个步骤挤在一句话里别用页面正常总结一切。4.2 Prompt设计自然语言和Markdown哪个更容易让AI理解专门聊一下Prompt表达形式因为网上经常有人问对DeepSeek提问用自然语言还是Markdown更容易让它明白指令。我们控制变量跑过一批对比实验纯自然语言、分条数字列表、Markdown分步结构、XML标签包裹分别测用例解析和脚本生成的完成率。结果很明确在我们的场景里Markdown分步骤结构加上明确的JSON Schema约束任务成功率最高。纯自然语言的Prompt表达顺滑但模型容易漏掉边界条件XML标签的约束最强但Token占用高且会干扰代码生成类任务。Markdown是一种半结构化的表达既保留语义连贯性又给了模型清晰的层次引导。必须强调一点这是针对自动化用例生成任务的实测结论不代表所有场景都适用。4.3 Few-shot示例与输出约束缺一不可我们维护了大概20条高质量Few-shot示例覆盖登录、列表查询、增删改、表单校验、权限验证几大类。每个示例不只是用例文本加目标代码还附带完整的JSON中间结构、错误恢复分支。你会惊讶这20条示例对输出质量的拉升效果——模型看到类似案例应该长这样之后生成格式和命名习惯都会向案例靠拢。输出约束层面除了JSON Schema我们还会做一次轻量的代码静态校验检查是否出现了page.wait_for_timeout这类禁用API是否缺失expect断言定位方式是否用了绝对XPath。校验不过就回传错误信息让Agent重写这一层过滤让生成代码的可维护性提升很多。4.4 SQL生成的安全边界自然语言查数据库模块核心难点不在转SQL而在防呆。测试人员一句把昨天创建的未支付订单删掉如果模型老老实实生成DELETE并执行测试数据就全没了。所以我们明确了两道防线第一道是意图过滤。在Dify Workflow里先做意图分类只允许SELECT类查询进入SQL生成节点。见到UPDATE、DELETE、INSERT直接拦截并返回提示让用户改用数据构造工具。第二道是执行保护。达梦连接使用低权限只读账号每个查询自动加上LIMIT 50限制连接超时设为10秒。这两道防线从模型层数据库层双重兜底哪怕Prompt注入也翻不了天。5. 落地半年踩过的坑5.1 选择器稳定性是第一个滑铁卢系统上线第一周生成的脚本失败率高达40%一半以上挂在元素定位。原因是早期Prompt里让模型自由选择定位方式它大量生成绝对XPath——/html/body/div[3]/div[2]/form/input——页面一改就崩。后来我们在Prompt里明确规定定位器优先级get_by_role优先、get_by_text次之、显式语义化ID再次严禁输出绝对XPath并且代码生成后做一次扫描清洗失败率才压到10%以内。这里给同行一个忠告AI生成代码的质量上限取决于你把约束写得多死。你不告诉它别用绝对XPath它就一定会用因为它从训练数据里学到的XPath习惯根深蒂固。5.2 Agent自动修复脚本的循环失控Agent带反馈闭环之后出现了新的恐怖场景脚本执行失败Agent试图修复没修对再试一次还是不对……我们有一次没设重试上限Agent硬生生跑了四十多轮API费用刷出新高日志里全是同一个错误的反复重试。后来我们做了两个硬性限制单条用例的自动修复最多迭代三轮每一轮修复必须返回修改了什么、为什么改由防线判定修改是否在合法范围内。同时引入熔断机制同一类错误连续出现三次直接转人工并冻结自动修复能力。LLM不是不能修代码但它在调试场景里很容易陷入自信地错下去必须用工程手段踩刹车。5.3 断言太含糊导致报告形同虚设用例里验证页面正常显示确认操作成功这类描述出现了大概三成AI生成的断言就变成随便找一个文本断言页面包含XX完全失去验证意义。原因是预期结果太虚LLM没有依据去生成有颗粒度的断言。我们花了一周时间拉业务测试同学逐条回改用例把所有正常成功替换成可观察的具体结果提示登录失败并显示错误原因列表第一行显示已支付状态金额为99.9元。改完之后断言覆盖度和缺陷发现率都明显提升。这个坑的本质是AI不会替你弥补用例本身的语义缺失它只会把模糊翻译成另一种模糊。5.4 达梦数据库的兼容模式与方言差异连接达梦数据库比预想中麻烦。达梦兼容多种数据库方言同一个库不同兼容模式下SQL行为不一样。我们最初按MySQL习惯写语法结果执行报错一片后来改成达梦兼容Oracle模式很多写法才稳定下来。还有大小写敏感问题——达梦默认对未加引号的标识符做自动大写转换生成的查询条件和实体名大小写不一致会查不出数据。这块解决路径是把SQL生成模板和方言配置做了一层映射Dify Workflow里单独配置达梦方言模板SELECT字段类型转换、日期函数、分页语法都固定写法而不是让模型自由选择。同时测试连接时直接跑通一组方言验证用例作为环境预检步骤。达梦官方Python驱动dmPython和SQLAlchemy方言库需要配对好版本驱动版本不一致会连环报错。5.5 低置信度用例的人工兜底还有一个容易被忽视的工程问题解析置信度机制。模型对于含糊用例往往会硬撑着给出看似合理的结果内部不确定性很高。我们后来在结构化输出里强制模型附带一个confidence字段置信度低于阈值的用例直接标记为待人工确认。刚开始业务测试同学觉得这一步多余直到他们看到AI把输入正确密码生成成输入字符串正确密码时才意识到这一步兜底了太多边界情况。宁可让5%的用例多花人工审核时间也不要让95%的无效脚本混进自动化流水线——因为后者的排查成本是前者的十倍。6. 工具的边界它替代不了什么6.1 生成代码也必须符合团队规范很多团队以为AI生成脚本等于不用维护代码规范这是最大的误解。AI生成的代码如果不经过模板约束和静态检查很快就会变成一团风格各异、难以调试的意大利面。我们的做法是维护一套Playwright脚本模板AI只需要填充业务步骤公共逻辑全部抽到基类生成完做静态扫描不过关就重写。这套约束的代价是AI的自由发挥空间变小了但换来的长期收益非常明显脚本可读性、可排查性、可维护性都有了保障。经验是自由度只留给业务层技术层一律收死。6.2 用例作者也要学会对AI说话工具上线后我们发现测试同学也在进化。从最开始被AI解析结果整得手足无措到后来主动把模糊表述改成精确断言这个过程本质上是建立了一种人和AI协作的语感。值得强调的是这不是要把测试人员变成程序员而是让他们理解自然语言用例工具读得懂中文但读不懂没有信息量的中文。团队里现在有一条不成文的规则每一条用例写完作者要先自问如果按这句话执行能不能只看屏幕就判断对错。能才是合格的自然语言用例。这条规则帮我们把解析失败率压到了5%左右。6.3 自动化不可能覆盖全部测试价值进一步发挥的话这套自然语言链路其实还可以延伸到缺陷自动复现、变更影响面分析、测试报告自动汇总这些场景。我们后续准备把Agent从生成脚本扩展成生成完整的测试方案前置条件、数据准备、环境检查都交给AI规划。但前提是地基打牢用例规范、工具描述、模板和灰度防线这些工作量一点都不能省。说到底工具再聪明也只是把从业务意图到可执行验证这段路的搬运成本降低了。真正的测试价值创造——定义什么需要被验证、什么错误不能接受、什么变化会影响用户——依然完完全全属于测试人员自己。一个能精确描述业务规则的测试同学加上一个能稳定执行的自然语言生成工具这个组合的战斗力比纯手写脚本的传统模式高出不止一个量级。 AI自然语言用例生成：从中文用例到自动执行脚本的架构与实践
如果你在测试团队里待过三年以上大概率见过这样的场景需求评审一结束功能测试同学开始吭哧吭哧写Excel用例自动化测试同学拿着同一条需求另起炉灶写一套脚本。同一个功能两套产出三个维护入口需求一改两边都动——这大概就是测试开发这个岗位存在感最强也最心累的瞬间。我们几个人的小组去年就在折腾这件事目标是做一套自然语言用例生成工具测试人员直接用中文写操作步骤和预期结果AI读取用例后自动生成可执行的UI自动化脚本跑完再把结果、截图和日志回填到用例管理平台。折腾了大半年结论是这条路子真能走通但和想象中不太一样核心难点不在生成脚本而在怎么让用例文本、模型输出、执行引擎三端稳定咬合。这篇文章把我们的架构、选型、踩坑和取舍一次性写清楚给想做类似工具的团队一个参考。1. 为什么用例生成成了测试开发的新分水岭1.1 被Double Write困住的测试团队你仔细想想传统自动化测试里最耗时间的其实不是写代码而是保持两套东西一致。一条中等复杂度的UI用例功能测试写文档可能要20分钟测试开发拿到文档再做元素定位、写断言、处理等待最快也要40分钟到1小时。需求一改用例文档和脚本的同步就成了无休止的体力活。这种模式的学名叫Double Write——同一个需求被人工翻译了两次每次翻译都可能引入偏差。用例文档里说输入正确的用户名密码脚本里的测试数据可能已经过期脚本里修复了某个隐藏的弹窗问题Excel里的步骤还停留在上个版本。跑完自动化报告是绿的但没人敢说它代表的是当前需求维护成本却一分没少。1.2 自然语言用例生成改变了协作关系的底层结构我们做工具的思路特朴素能不能让测试人员就用中文把步骤和预期结果写清楚翻译工作交给大模型AI读取用例里的操作步骤、目标对象、断言条件自动生成Playwright脚本跑完自动回填结果。听起来只是省掉了写脚本但实际牵动的是一整条协作链路的变化。用例从给人看的文档变成了人和AI共同维护的可执行资产。功能测试负责把业务语义写得精确测试开发负责维护生成模板和工具链的质量标准脚本退化成用例的衍生品不再需要单独维护。自动化覆盖率不再是墙上的数字因为用例本身和脚本之间只隔着一个可复现的生成过程。1.3 为什么这件事现在才跑通自然语言生成用例七八年前就有人提当时的方案多半是关键词驱动或自然语言模板解析靠正则和词表匹配。复杂句式一出现就崩产品形态也变成填表格本质上还是换了种方式写脚本没有解决语义理解问题。现在不一样了。大模型的语义理解和代码生成能力把天花板抬了起来一句在首页搜索框输入蓝牙耳机注意先清空历史搜索记录这种带隐含前置操作的描述只有LLM才能稳定拆解成可执行步骤。当然能力变强也带来新麻烦——输出不稳定、幻觉、选择器失效、SQL方言不兼容这些我们后面挨个讲。2. 工具架构拆解一条从中文用例到可执行脚本的流水线2.1 第一层用例解析与语义结构化所有流程的第一步是把一篇中文用例变成机器可读的结构化数据。我们的输入是这样的用例编号TC-1001 前置条件用户已注册昵称为Dex 步骤 1. 打开登录页 2. 输入正确的用户名和密码 3. 点击登录 期望结果跳转到首页右上角显示用户昵称Dex页面加载时间小于2秒大模型先抽取前置条件、操作步骤、期望结果和测试数据再转成一份JSON结构。这里有个容易被忽略的点结构化输出必须用JSON Schema强约束而不是让模型自由发挥。我们最开始让模型输出一个JSON结果字段命名千奇百怪后面所有下游代码都在给解析擦屁股规范成Schema之后才算稳下来。2.2 第二层工具注册与Agent编排结构化完成之后真正干活的是Agent。我们基于LangChain搭建了编排层给Agent注册了三个核心工具web_open负责页面跳转和基础导航web_action负责定位元素并执行点击、输入、悬停、截图等UI操作query_database负责在测试执行前后查询数据库做测试数据准备或结果校验。这里最关键的不是代码而是工具描述。每个工具的description必须写清楚什么时候用、参数长什么样、什么情况下会报错。Agent拆解用例步骤时本质是在做工具选择描述写得模糊它就会把输入用户名翻译成乱调一气。我们后来把工具描述当文档一样维护每个描述不低于100字这是实践里最有效的一次调优。2.3 第三层Playwright执行引擎对接Agent生成的不是直接可以跑的裸代码而是中间表示再拼接成Playwright脚本。为什么用Playwright而不是Selenium后面选型章节细说。执行层我们做了一些封装比如统一等待策略、失败自动截图、录制trace文件这样AI生成的脚本跑挂了至少能留证据。执行不是纯黑盒跑一遍就结束。每一大步执行完结果会回传给Agent判断——页面弹窗了、元素没找到、网络超时Agent会根据实际页面反馈决定是重试、换一种定位方式还是上报失败。这就是Agent编排比固定脚本强的地方它带反馈闭环能现场动态调整。2.4 第四层结果回填与人工确认闭环脚本执行完之后系统会把测试结果、执行时长、截图、trace.zip自动关联到用例管理平台的对应用例编号上。通过率只是其中一个指标我们更关注的是生成成功率和执行稳定性的分离统计。用例解析置信度低于0.85的不允许直接生成脚本会先进人工确认队列。AI可以先产出脚本但状态标记为待审核。没有这层闸门早期一定会被幻觉用例淹没——模型编一个不存在的按钮给你生成一条看似完美的脚本跑的时候才发现元素定位全是瞎编的。3. 关键技术选型为什么是这个组合3.1 模型层DeepSeek的性价比与可配置性模型选型我们做了大概两周的对比测试包括几个主流商用模型和开源部署方案最后默认模型用的是DeepSeek。核心原因是它在代码生成和指令遵循上的表现非常稳同时API成本大概只有国外头部模型的十分之一。我们内部跑大量Prompt实验一天烧几百块也不心疼这对调优阶段太重要了。一个有意思的发现是模型能力要分场景看。用例解析这种语义理解任务各家差距不大但生成Playwright代码这种长结构化输出DeepSeek的代码格式完整度和元素定位准确率表现很突出。成本允许的话我们会把核心生成链路固定用同一个模型避免不同模型输出风格差异导致后续模板适配困难。3.2 Agent框架直接用LangChain还是自己写循环这个问题我们纠结了很久。自己写Agent循环其实不难难的是配套的工具管理、记忆管理和回调系统。LangChain的价值在于这些周边组件相对成熟尤其是工具调用的报错回传机制不用自己从零造。我们用LangChain Hub管理Prompt版本几轮调优下来回滚对比都很方便。当然它也有别扭的地方抽象层多、版本升级兼容性差。项目后期我们把编排核心从LangChain的AgentExecutor迁到LangGraph用图的方式显式管理每个节点的分流和重试条件可控性上了一个台阶。我的建议是小团队起步直接用LangChain没问题但要把Agent循环理解透别只会调库不然出了问题很难排查。3.3 执行引擎Playwright相比Selenium的根本优势执行层我们没有太多犹豫就选了Playwright。最主要的理由是定位器机制。Selenium时代大家习惯了XPath和CSS强绑定页面结构一改脚本就崩。Playwright的get_by_role、get_by_text等语义化定位器对AI生成场景是降维打击——模型生成的代码更倾向于按文本找元素而不是按层级找元素这恰好是AIGC能稳定输出的方式。自动等待也是关键。AI生成的脚本最怕时序问题Selenium的sleep在页面加载慢时极不稳定。Playwright的auto-wait机制会让操作自动等待元素可交互实测下来脚本的脆性大幅下降。配合网络事件监听还能验证点击之后有没有发起正确的请求这类接口层面的效果。3.4 数据层自然语言查达梦数据库与Dify的定位UI自动化有一个绕不开的场景测试数据准备和结果校验。我们的被测系统数据落在达梦数据库上早期测试人员写SQL经常被方言和权限折磨所以专门做了一个自然语言查数据库的小模块。技术选型上用了Dify把查询意图识别、SQL生成、权限校验和结果执行串成一条Workflow。Dify在这个场景里扮演的是带护栏的翻译层用户用自然语言说查昨天创建且状态为待审核的订单数量Dify内部先做意图分类再生成SQL交给连接达梦的执行节点运行最后把结果整理成表格回给用户。关键是SQL生成之后必须先过一层安全校验强制把查询限制在只读模式自动加行数上限杜绝测试人员误操作写库。这块后面还有坑要讲。4. 让AI稳定输出可执行代码的细节工程4.1 用例文本的标准格式是地基大模型能力和LLM指令遵循再强也架不住输入文本天马行空。我们最开始让测试同学自由写用例AI解析满意度不到70%原因不是模型不行而是人写的自然语言充满歧义。后来我们定义了一套极轻量的编写规范不约束具体措辞只约束结构必须分步骤、前置条件必须单列、预期结果必须写看得到的结果而不是正常/成功这种形容词。定完这套规范解析准确率显著提升了。这里有个反直觉的结论工具的目的是让人用自然语言写用例但这个自然语言仍然需要极轻的结构约束。它不要求你改变表达习惯只要求你别把三个步骤挤在一句话里别用页面正常总结一切。4.2 Prompt设计自然语言和Markdown哪个更容易让AI理解专门聊一下Prompt表达形式因为网上经常有人问对DeepSeek提问用自然语言还是Markdown更容易让它明白指令。我们控制变量跑过一批对比实验纯自然语言、分条数字列表、Markdown分步结构、XML标签包裹分别测用例解析和脚本生成的完成率。结果很明确在我们的场景里Markdown分步骤结构加上明确的JSON Schema约束任务成功率最高。纯自然语言的Prompt表达顺滑但模型容易漏掉边界条件XML标签的约束最强但Token占用高且会干扰代码生成类任务。Markdown是一种半结构化的表达既保留语义连贯性又给了模型清晰的层次引导。必须强调一点这是针对自动化用例生成任务的实测结论不代表所有场景都适用。4.3 Few-shot示例与输出约束缺一不可我们维护了大概20条高质量Few-shot示例覆盖登录、列表查询、增删改、表单校验、权限验证几大类。每个示例不只是用例文本加目标代码还附带完整的JSON中间结构、错误恢复分支。你会惊讶这20条示例对输出质量的拉升效果——模型看到类似案例应该长这样之后生成格式和命名习惯都会向案例靠拢。输出约束层面除了JSON Schema我们还会做一次轻量的代码静态校验检查是否出现了page.wait_for_timeout这类禁用API是否缺失expect断言定位方式是否用了绝对XPath。校验不过就回传错误信息让Agent重写这一层过滤让生成代码的可维护性提升很多。4.4 SQL生成的安全边界自然语言查数据库模块核心难点不在转SQL而在防呆。测试人员一句把昨天创建的未支付订单删掉如果模型老老实实生成DELETE并执行测试数据就全没了。所以我们明确了两道防线第一道是意图过滤。在Dify Workflow里先做意图分类只允许SELECT类查询进入SQL生成节点。见到UPDATE、DELETE、INSERT直接拦截并返回提示让用户改用数据构造工具。第二道是执行保护。达梦连接使用低权限只读账号每个查询自动加上LIMIT 50限制连接超时设为10秒。这两道防线从模型层数据库层双重兜底哪怕Prompt注入也翻不了天。5. 落地半年踩过的坑5.1 选择器稳定性是第一个滑铁卢系统上线第一周生成的脚本失败率高达40%一半以上挂在元素定位。原因是早期Prompt里让模型自由选择定位方式它大量生成绝对XPath——/html/body/div[3]/div[2]/form/input——页面一改就崩。后来我们在Prompt里明确规定定位器优先级get_by_role优先、get_by_text次之、显式语义化ID再次严禁输出绝对XPath并且代码生成后做一次扫描清洗失败率才压到10%以内。这里给同行一个忠告AI生成代码的质量上限取决于你把约束写得多死。你不告诉它别用绝对XPath它就一定会用因为它从训练数据里学到的XPath习惯根深蒂固。5.2 Agent自动修复脚本的循环失控Agent带反馈闭环之后出现了新的恐怖场景脚本执行失败Agent试图修复没修对再试一次还是不对……我们有一次没设重试上限Agent硬生生跑了四十多轮API费用刷出新高日志里全是同一个错误的反复重试。后来我们做了两个硬性限制单条用例的自动修复最多迭代三轮每一轮修复必须返回修改了什么、为什么改由防线判定修改是否在合法范围内。同时引入熔断机制同一类错误连续出现三次直接转人工并冻结自动修复能力。LLM不是不能修代码但它在调试场景里很容易陷入自信地错下去必须用工程手段踩刹车。5.3 断言太含糊导致报告形同虚设用例里验证页面正常显示确认操作成功这类描述出现了大概三成AI生成的断言就变成随便找一个文本断言页面包含XX完全失去验证意义。原因是预期结果太虚LLM没有依据去生成有颗粒度的断言。我们花了一周时间拉业务测试同学逐条回改用例把所有正常成功替换成可观察的具体结果提示登录失败并显示错误原因列表第一行显示已支付状态金额为99.9元。改完之后断言覆盖度和缺陷发现率都明显提升。这个坑的本质是AI不会替你弥补用例本身的语义缺失它只会把模糊翻译成另一种模糊。5.4 达梦数据库的兼容模式与方言差异连接达梦数据库比预想中麻烦。达梦兼容多种数据库方言同一个库不同兼容模式下SQL行为不一样。我们最初按MySQL习惯写语法结果执行报错一片后来改成达梦兼容Oracle模式很多写法才稳定下来。还有大小写敏感问题——达梦默认对未加引号的标识符做自动大写转换生成的查询条件和实体名大小写不一致会查不出数据。这块解决路径是把SQL生成模板和方言配置做了一层映射Dify Workflow里单独配置达梦方言模板SELECT字段类型转换、日期函数、分页语法都固定写法而不是让模型自由选择。同时测试连接时直接跑通一组方言验证用例作为环境预检步骤。达梦官方Python驱动dmPython和SQLAlchemy方言库需要配对好版本驱动版本不一致会连环报错。5.5 低置信度用例的人工兜底还有一个容易被忽视的工程问题解析置信度机制。模型对于含糊用例往往会硬撑着给出看似合理的结果内部不确定性很高。我们后来在结构化输出里强制模型附带一个confidence字段置信度低于阈值的用例直接标记为待人工确认。刚开始业务测试同学觉得这一步多余直到他们看到AI把输入正确密码生成成输入字符串正确密码时才意识到这一步兜底了太多边界情况。宁可让5%的用例多花人工审核时间也不要让95%的无效脚本混进自动化流水线——因为后者的排查成本是前者的十倍。6. 工具的边界它替代不了什么6.1 生成代码也必须符合团队规范很多团队以为AI生成脚本等于不用维护代码规范这是最大的误解。AI生成的代码如果不经过模板约束和静态检查很快就会变成一团风格各异、难以调试的意大利面。我们的做法是维护一套Playwright脚本模板AI只需要填充业务步骤公共逻辑全部抽到基类生成完做静态扫描不过关就重写。这套约束的代价是AI的自由发挥空间变小了但换来的长期收益非常明显脚本可读性、可排查性、可维护性都有了保障。经验是自由度只留给业务层技术层一律收死。6.2 用例作者也要学会对AI说话工具上线后我们发现测试同学也在进化。从最开始被AI解析结果整得手足无措到后来主动把模糊表述改成精确断言这个过程本质上是建立了一种人和AI协作的语感。值得强调的是这不是要把测试人员变成程序员而是让他们理解自然语言用例工具读得懂中文但读不懂没有信息量的中文。团队里现在有一条不成文的规则每一条用例写完作者要先自问如果按这句话执行能不能只看屏幕就判断对错。能才是合格的自然语言用例。这条规则帮我们把解析失败率压到了5%左右。6.3 自动化不可能覆盖全部测试价值进一步发挥的话这套自然语言链路其实还可以延伸到缺陷自动复现、变更影响面分析、测试报告自动汇总这些场景。我们后续准备把Agent从生成脚本扩展成生成完整的测试方案前置条件、数据准备、环境检查都交给AI规划。但前提是地基打牢用例规范、工具描述、模板和灰度防线这些工作量一点都不能省。说到底工具再聪明也只是把从业务意图到可执行验证这段路的搬运成本降低了。真正的测试价值创造——定义什么需要被验证、什么错误不能接受、什么变化会影响用户——依然完完全全属于测试人员自己。一个能精确描述业务规则的测试同学加上一个能稳定执行的自然语言生成工具这个组合的战斗力比纯手写脚本的传统模式高出不止一个量级。