给用例智能体加上"看图"能力，再搭一个需求问答机器人

测试工作里有两件常做的事：对着需求写用例，被同事问需求细节。这次都让智能体干：先给用例智能体加一个"看图"分支，原型图截图也能出测试用例；再搭一个基于知识库的需求问答机器人，问啥答啥。

01 给智能体加上"看图"能力，靠三个节点

原来的智能体只认文档，现在加一条图片分支，核心是三个节点配合：

选择器节点：就是个 if-else。判断用户上传的是文档还是图片，是文档走文档分支，是图片走图片分支。

图片分支：OCR 插件把图里的文字抠出来，返回的是一段段碎片；代码节点再把这些碎片拼成完整内容——就几行代码的事。

变量聚合节点：把"文档分支"和"图片分支"的结果合并成一份，交给后面的大模型。它只取第一个不为空的值，没跑的分支不会报错。

搞定之后，智能体三种输入都能出 excel 用例：需求文档、图片（原型图/截图）、飞书在线文档。

02 关键选择：OCR 还是视觉大模型

OCR：只负责把字抠出来，快、便宜、结果稳定。但它看不懂排版、布局、交互逻辑——原型图如果主要是页面设计、没多少文字，OCR 直接没辙。

视觉大模型：能理解整个页面，模块、按钮、跳转逻辑都能推断，适合原型图。但贵：输出单价是文本模型的 4~8 倍，一张图还能顶几千上万字的输入量。

怎么选：文字型截图用 OCR，省钱；原型图、UI 稿要测排版和交互，上视觉模型。行业里现在也流行混着用——便宜的 OCR 处理大多数，视觉模型专啃难例。

03 再搭一个需求问答机器人

场景很常见：新人熟悉项目需求、需求评审前预习、写用例时核对细节。与其翻文档，不如问机器人。

这次用对话流，不是工作流。工作流适合跑数据流水线；问答是聊天场景，对话流天生适配，自带用户输入和会话历史。

三个节点就够：开始节点接收用户问题 → 知识库检索节点（把需求文档放进知识库，按问题召回相关片段）→ 大模型节点（把召回内容和问题一起喂进去，组织答案）。

04 知识库检索不准，三步调

先按默认配置跑：混合搜索、最多召回 5 条、最小匹配度 0.5。

召回不准的时候，三步走：一，调知识库的数据清洗和分段策略；二，把文档重新上传一遍，确认处理完成没报错；三，调整检索节点——召回数量调大、匹配度调小，让更多内容进来。

每调一次，都重新做一次召回测试，看结果质量再决定下一步。

05 内部文档放进 Coze，安全吗

官方承诺：上传的内容不会用于模型训练、不会做数据分析、不会分享——直接泄密的风险不高。

但该守的规矩要守：优先用企业版（隔离能力更强）；只传必要的内容，别整库全量同步；敏感信息先脱敏再传；包含内部知识库的智能体绝对不要设为公开；定期检查知识库权限和发布状态。

安全级别很高的文档就别上云了，本地部署 Dify 加本地知识库更踏实。

06 测试圈现在玩到什么程度了

知识库问答是企业落地最多的场景之一。有行业观点认为，知识库建设往往占智能客服项目工作量的六七成——难点不在模型，在把散落的文档整理成能用的知识。

RAG 的核心价值是两个：时效性——库存、活动规则随时在变，预训练模型不知道；私有知识——公司内部文档，大模型根本没学过。

现在的进化方向是"Agentic RAG"：让 AI 像人查资料一样，先搜、发现缺口、再搜，直到拼出完整答案。平台也在跟进：Coze 已经支持三方知识库连接器，能接企业自建和本地知识库。

写在最后

OCR 抠字、视觉模型看 UI、知识库管私有知识——工具一直在换，测试要做的判断没变：什么场景用什么工具，省下来的时间花在人该干的事上。