如何设计基于OCR和LLM的方案并落地实施？

当产品经理甩过来一份50页的需求文档，要求"这周把测试用例写完"时，你会怎么做？手动复制粘贴到Excel？还是让AI直接读图生成用例？ 随着AI技术的普及，OCR（光学字符识别）与LLM（大语言模型）的结合，彻底打破了“手写用例”的效率瓶颈。今天给大家分享一套可落地的《自动生成用例：基于OCR+ LLM的设计方案》，从背景、痛点、架构、关键设计到落地建议，帮你快速实现用例自动生成，解放双手。 💡 文章篇符较长，建议先点赞收藏，慢慢看 一、背景：测试用例编写的痛点？ 测试用例编写是软件测试中最"体力活"的环节。据统计，一个中等复杂度的需求，测试工程师平均需要花费： 环节 耗时占比 痛点 理解需求文档 30% 文档格式混乱，PRD、原型图、流程图分散 提取测试点 40% 需要人工识别边界条件、异常场景 编写用例格式 20% 重复劳动，复制粘贴到用例管理工具 评审与修正 10% 遗漏场景、描述不清 传统AI方案的局限： 早期的"AI生成用例"大多基于纯文本输入，比如把需求文档的Word/PDF文字提取出来喂给ChatGPT、DeepSeek。但现实中，大量关键信息藏在图片里——产品原型图、流程图、手绘草图、甚至Excel截图。 我们曾遇到过一个案例：某金融系统的"转账限额规则"只存在于一张复杂的Excel配置表截图中，文字提取工具完全失效，测试工程师只能肉眼识别37个单元格，手动编写142条用例，耗时2天。 这就是OCR+LLM方案的出发点：让AI不仅能"读文字"，还能"看懂图"。 利用OCR与LLM的结合： OCR负责“读懂”设计稿/原型图中的视觉元素（按钮、输入框、弹窗等）， LLM负责“理解”产品逻辑、补齐测试场景、生成标准化用例。两者协同，实现“输入设计稿，输出可评审用例”的闭环。 除此之外，随着产品迭代速度加快，每次需求变更都需要重新修改、补充用例，传统手写方式无法适配敏捷开发的节奏，而自动生成方案可快速响应需求变更，大幅提升测试效率，让测试工程师将精力聚焦在核心场景优化、缺陷排查上，而非重复的用例编写工作。 二、解决什么问题？ 这个方案设计初衷主要为了解决三类场景： 场景1：原型图/设计稿 → 功能用例 产品经理给的是Axure/墨刀导出的PNG，包含页面元素、交互说明、业务规则。传统方式需要测试工程师对着图一条条写，现在让AI直接看图生成。 场景2：流程图/时序图 → 流程用例 复杂的业务状态流转（如订单从"待支付"到"已完成"的7个状态），流程图里画得很清楚，但文字提取会丢失箭头逻辑。OCR需要识别节点和连接关系。 场景3：配置表/规则表 → 组合用例 权限矩阵、费率表、风控规则等，往往以Excel截图或表格图片形式存在。需要识别行列关系，并应用组合测试/正交试验法生成用例。