Dify需基于符合OpenAPI 3.0+规范的完整YAML/JSON文档，经禁用RAG分块、启用OpenAPI解析器及结构化提示词，通过多步工作流生成含边界值、异常与鉴权场景的可执行测试用例。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Dify根据一份OpenAPI/Swagger文档，自动解析接口路径、参数、状态码和请求体结构，并输出带边界值、异常场景、鉴权失败路径的可执行测试用例——而不是把文档当普通文本扔给大模型瞎猜。
准备能被真正“理解”的API文档
第一步：导出符合OpenAPI 3.0+规范的YAML或JSON文档。不是截图、不是Word摘要、不是Postman集合导出的不完整JSON——必须是包含paths、components/schemas、responses、securitySchemes等完整字段的原始契约文件。
第二步：检查文档中required字段是否明确标注，schema是否嵌套定义（如$ref: '#/components/schemas/UserCreate'），401、403等状态码是否在responses里声明。缺失这些，Dify后续无法提取约束条件。
第三步：把这份文档上传到Dify知识库时，【禁用默认RAG分块】。在知识库设置里关闭“自动分块”，改用手动指定chunk size为整个文档长度——否则OpenAPI层级关系（比如paths → parameters → schema）会被切断，LLM永远看不到参数和其所属接口的绑定关系。
搭建支持契约感知的工作流
新建一个「工作流」应用，不要选对话型或Completion型——API测试用例生成必须走多步骤推理：先解析契约结构→再推导测试点→最后按模板填充。Agent类型是唯一能支撑该流程的载体。
拖入四个核心节点并按顺序连接：开始节点 → 文档解析器（PDF/JSON/YAML专用） → LLM节点（带结构化输出约束） → Markdown表格格式化节点。
在文档解析器节点配置中，选择「OpenAPI解析器」而非通用文本提取器；绑定输入变量为上传的API文档文件；勾选「保留引用关系」和「展开$ref」——这一步让Dify把schema定义真正注入上下文，而不是只看到一串字符串。
写一段能让LLM“读契约”的提示词
方法一：用JSON Schema硬约束输出
在LLM节点的提示词末尾追加以下内容：
```json
{"type":"array","items":{"type":"object","properties":{"case_id":{"type":"string"},"endpoint":{"type":"string"},"method":{"type":"string"},"params":{"type":"object"},"headers":{"type":"object"},"body":{"type":"object"},"expected_status":{"type":"integer"},"test_scenario":{"type":"string"},"priority":{"type":"string","enum":["P0","P1","P2"]}}}}
你必须严格按此JSON Schema输出，不得添加任何额外字段、注释或说明文字。所有字段值必须来自OpenAPI文档中真实定义的内容，禁止虚构。
方法二：用自然语言强制契约锚定
在提示词开头明确指令：
你是一个API测试契约解析专家。你收到的不是普通文本，而是一份OpenAPI 3.0契约。请逐字段扫描：
① 从paths中提取每个endpoint和method；
② 对每个parameters，检查required、schema.type、minimum/maximum、format；
③ 对每个requestBody，展开$ref并提取所有required字段及嵌套约束；
④ 对每个responses，记录4xx/5xx状态码及其触发条件（如401对应security: [bearerAuth]缺失）。
⚠️注意：如果某接口未定义security，则不生成鉴权类用例；如果schema中无minimum，则不生成负数边界值——你的输出必须100%忠于契约，不脑补、不猜测。
配置模型与验证输出稳定性
步骤一：进入「模型配置」→「自定义模型」→ 添加Ollama模型，模型名称填llama3:8b，基础URL填http://host.docker.internal:11434（Docker部署Dify时）或http://localhost:11434（直装）。
步骤二：关键参数设为：Temperature = 0.05（抑制随机性）、Max Tokens = 4096（确保长契约能完整处理）、Context Window = 8192（防止大型OpenAPI文档被截断）。
步骤三：点击「测试连接」确认成功后，在LLM节点中手动选择该模型，并勾选「启用流式响应」——这能让Dify在生成过程中实时校验JSON结构合法性，避免因超长输出导致格式崩溃。
步骤四：用一份含3个接口、2个$ref嵌套schema、明确401/403定义的测试文档运行工作流。检查输出是否包含：
• 每个接口的真实path和method
• required参数的缺失场景用例
• email格式字段的非法值（如"abc"）用例
• 401状态码对应的无token请求用例
• 所有用例ID遵循TC-{path缩写}-{序号}命名规则
对接飞书机器人实现聊天式触发
进入飞书开发者后台 → 创建新应用 → 开启「事件订阅」→ 添加message_received事件 → 回调地址填https://your-langbot-domain.com/callback（LangBot部署后暴露的公网地址）。
在LangBot管理界面 → 新建Bot连接 → 选择「飞书」作为来源 → 填入飞书App ID和App Secret → 绑定Dify工作流的API Endpoint（Dify工作流发布后生成的/api/workflow/xxx路径）。
最后，在飞书群聊中@你的机器人，发送消息：/testcase upload https://example.com/api-spec.yaml——LangBot会自动下载该YAML文件，调用Dify工作流，并将生成的Markdown表格直接以消息卡片形式返回。
