企业官网建设流程全解析

写用例写到怀疑人生这件事，我估计干测试的都有共鸣。产品经理的需求文档还在文档平台上躺着，排期表上已经写着“用例编写今天截止”。打开文档一看，功能描述三行字加一张截图，业务规则藏在表格里，异常分支全靠自己猜。硬着头皮手写，半天时间就耗进去，最后还要担心漏场景。后来我花了两周时间，把这条链路用 Dify 做成了自动化流水线：需求文档丢进去，出来就是一份按模块分组、覆盖功能/边界/异常/场景的测试用例清单。这篇文章把流水线的设计思路、节点配置、提示词细节、踩坑记录全部写出来，给在做测试效能建设、或者想用 AI 辅助写用例的 QA 同学一个可直接参考的落地样板。

文章适合三类人看：正在做测试效能建设、想引入 AI 写用例的 QA；用过 Dify 但只停留在聊天助手层面、没真正跑通工作流的同学；以及想对比“纯代码实现”和“可视化平台实现”的研发效能工程师。

1. 手工写用例的效率瓶颈，和选择 Dify 的完整理由

1.1 传统用例编写中那些每天都在重复的损耗

先说个真实体感。我刚接到这个自动化需求时，第一反应也是“直接拿 ChatGPT 提问不就完了”。真试过之后发现完全不行。真实场景里的需求文档包含背景、功能列表、业务规则、异常分支、埋点要求，一段话扔给大模型，它确实能生成用例，但质量极不稳定。同一份文档，问十次可能出来十种不同的用例结构，有的漏边界，有的编造需求里根本不存在的验收标准。

做得多了你会发现效率损耗主要在三处：

• 读取和理解的损耗。需求文档动辄几千字，有的还带表格、截图、历史遗留的过时描述，人的注意力被反复切分，经常看到后面忘了前面。
• 设计方法的损耗。等价类、边界值、场景法、错误推测法，这些方法论不是每次都能被完整用上。资深测试能下意识用出来，但新人照着一份文档写，漏边界值、漏异常流是高频问题。
• 格式整理的损耗。用例最终要落到 Excel、禅道、PingCode 这类管理平台，手工复制粘贴标题、步骤、预期结果，是纯体力活，但每天都要干。

这份损耗每个月累积下来，就是几十个小时。所以我才下决心把这件事实事求是地工程化——不搞什么“赋能”“提效”这种虚词，就是把一件重复劳动拆成机器能干的步骤，然后让它自动跑。

1.2 为什么最后选了 Dify，而不是自己写一套 LangChain 脚本

最开始我也认真考虑过用原生 LangChain + 代码实现，毕竟这条路可定制性最高。但仔细算了账之后放弃了。要做一个给组里同事日常使用的工具，至少得有这几个部分：文档上传和格式解析、大模型调用和提示词管理、工作流编排（文档进来之后走哪些步骤）、结果展示界面、以及后面的迭代维护。用代码实现意味着我要自己写一个带界面的小应用，还要考虑并发、部署、参数调整后的重新发布——这对于一个以测试为主的团队来说，太重了。

Dify 的价值在于它把编排工作流、知识库管理、模型接入全部可视化。你要的是一个“流程逻辑相对明确但变化频繁”的应用，这正好是可视化工作流的强项。改提示词直接在页面上改完就生效，不需要走代码发布流程，不需要重新构建应用。对于把“写用例”这种辅助工具挂在日常流程里的场景，这种快速迭代能力非常重要。

对比一下我当时的选型权衡：

我最终的结论是：测试效能的场景里，可维护性比极致灵活更重要。选 Dify 不是因为它比代码更强大，而是因为在“团队资源有限、需求多变、需要持续迭代”这几个约束下，它是性价比最高的解。

1.3 动手前先定四条硬约束，避免做到一半失控

搭流水线之前，我给自己定了四条硬约束。这四条法则后来直接影响了所有节点的设计，建议你也先想清楚再动手。

第一条，输入输出要标准。输入是一份需求文档，输出必须是一份结构化测试用例清单（JSON 或 Markdown 表格），字段要跟团队用例管理工具对齐，为后续导入做准备。

第二条，节点可复用。需求拆解节点、用例生成节点要能从流水线里独立拿出来，换个场景还能用。比如需求拆解节点可以直接用于“需求文档自动摘要”，不用重新开发。

第三条，必须有人工审核位。自动化生成的内容不能直接进正式用例库，中间要有一道确认关卡。我刚做出来的时候试用同事第一句话就是“这东西生成完我不检查敢直接入库吗”——不敢。所以设计上从一开始就保留了人工审核的位置。

第四条，模型可切换。系统提示词和模型调用必须解耦。今天用这家模型，明天那家发新版本，我能直接切过去，不用推翻流程重搭。这个在 Dify 里比较容易实现，模型配置是在节点级别独立设置的，后续模型涨价也能单独换某个节点所用的模型。

2. 流水线整体架构：为什么必须拆成四段，而不是一条端到端的大提示词

2.1 先看完整的数据流

整个流水线的核心其实就是一条链路：

需求文档 → 文档解析节点 → 需求条目结构化列表 → 用例生成节点 → 校验/纠错节点 → 测试用例清单

其中“需求条目结构化列表”这一步是绝对不能跳过的环节。我第一次做的时候图省事，直接把整篇需求文档扔给模型让它生成用例，效果非常差。原因后来想明白了：跳过解析，模型就没有办法区分“背景介绍”“宣传文案”和“实际功能要求”，它会把大量跟测试无关的表述也当成功能点来处理，幻觉用例满天飞。你让它输出 20 条用例，它可能把需求里最核心的功能点漏了，反而基于一句“优化用户体验”编出 5 条莫名其妙的用例。

所以架构设计上，我把流程拆成了四段，严格按照“一次只做一件事”的工程原则。

2.2 四段式设计的详细拆解

第一段：需求文档解析。目标是把一份自然语言的需求文档转成结构化的需求条目列表。输入是 Markdown 或纯文本，输出是 JSON 数组，每个元素包含模块、需求编号、需求描述、业务规则、验收标准。

第二段：需求条目理解与清洗。这一步负责识别“模糊表述”和“不可测需求”。比如文档里写“提升加载速度”，这就是不可测需求，模型不能擅自去定义“加载速度小于 3 秒”。这一段做的事情是给模型输入需求条目，让它标注出哪些条目是清晰可测的，哪些是模糊的，模糊项要打上 low confidence 标签，不做任何补全。

第三段：测试用例生成。每一个经过清洗的需求条目，进到这里生成一组测试用例。用例要覆盖功能流程、异常流程、边界值、业务规则冲突等场景。

第四段：格式校验和输出。检查 JSON 顺序、字段完整性、用例数量是否低于阈值，然后把结果整理成可导入 Excel 或用例管理平台的格式。

为什么要这么拆？因为大模型在一个步骤里同时做五件事的时候，出错率会指数级上升。让它在解析文档的同时还要检查用例覆盖度，它一定两边都做不好。这和一般软件工程“一个函数只干一件事”是同一个道理。

分段之后还有一个额外的好处是容错。比如生成阶段单个节点调用失败，我只需要重试那一个节点，不需要重新处理整份文档。这在长文档场景下能节省大量时间和费用。

2.3 模型选型与成本测算

跑了不少调用之后，我总结出几个模型选型的经验：

• 需求解析节点：用长上下文、解析能力稳定的模型。因为输入是整份文档，上下文窗口小了会截断。
• 用例生成节点：用指令遵循能力强的模型。这个节点对“能不能按照格式输出”的要求最高。
• 格式清洗节点：用便宜的模型就行，逻辑简单，不需要太强的智力。

成本方面我给一个直观的测算。假设每个月跑 100 次流水线，每次输入 5000 字左右的文档，输出 1 万到 2 万 token：

我实际跑下来，国产商用模型的性价比最优。它可能在极端复杂的语义理解上比顶级模型略弱，但用在“需求解析 + 用例生成”这种结构化程度很高的场景，差距很小，价格却只有几分之一。

还有一个参数层面的细节。很多人用大模型生成内容时喜欢把 temperature 调高，觉得“更有创造性”，但在写用例这个场景是大忌。测试用例要稳定、可复现，不能同一份需求这次生成 20 条用例、下次生成 15 条。我最后把用例生成节点的温度固定在 0.2 到 0.4 之间，输出非常稳定。

3. 第一步实操：让 Dify 真正吃透一份需求文档

3.1 知识库还是文档上传，两个方案的区别要分清

Dify 里接入文档有两种路线，很多人会混淆。第一种是把文档提前塞进知识库，让模型从里面检索相关片段；第二种是在工作流里直接上传/传入当次文档，作为上下文一次性让模型处理。

选型时的判断标准很简单：如果需求文档是零散的、每次内容都不一样，直接用工作流传入当次文档，不要绕道走知识库检索。知识库检索适合沉淀“不变的、可复用的内容”——比如公司的测试用例编写规范、历史优秀用例模板、需求文档的标准写法示例。这些不变的内容进知识库，当次需求文档走工作流传入，两者是配合关系，不是替代关系。

我最终采用的是混合方案：

• 当次需求文档：通过工作流开始节点的文件上传或文本输入传入。
• 历史优秀用例模板、测试设计规范：放进 Dify 知识库，在用例生成节点的提示词里引用。

混合方案跑了一个月之后，我最明显的感受是：模型写出的用例格式越来越像团队风格，从一开始的“泛化 AI 味”逐步收敛到团队的表述习惯，因为知识库里的优秀模板在持续给它做示范。

3.2 文档切分策略：用 Markdown 标题分段是需求文档的最佳解

这部分如果你是走知识库路线，就特别值得注意。需求文档的天然结构通常是这样的：

• 一级标题：背景
• 二级标题：功能列表
• 三级标题：模块 A
• 四级标题：需求条目

这种结构是典型的层级化文本，最合适的分段方式就是按标题层级来切。Dify 知识库的分段设置里，分隔符建议加一个\n##，这样每个二级标题下的内容会成为独立片段。段落长度可以设到 1000 字符左右，重叠设 100 字符。这样切出来的片段语义完整，检索时命中率高，不会出现把“背景”和“功能描述”切到同一个片段里的尴尬。

如果走工作流传入文档的路线，我强烈建议你在进 Dify 之前先做一次格式预处理，把 PDF、Word、飞书文档统一转成干净的 Markdown。我踩过太多次直接在 Dify 里解析 PDF 的坑：表格错位、换行丢失、分页符变成乱码。最终的方案是做了个小脚本，先把所有文档统一转成 Markdown，再进流水线。这一下就把后续的解析成功率从不到 80% 提到了接近 98%。

3.3 需求解析节点的提示词设计：地基质量决定上层能用多久

需求解析节点是整个流水线质量的地基。这个节点的任务是把文档转成结构化的需求条目 JSON，输出字段如下：

• module：所属模块
• requirement_id：需求编号
• requirement：一句话需求描述
• business_rule：业务规则约束
• acceptance_criteria：验收标准

我实际在用的提示词如下，你可以直接拿来改（删除线部分是注释，使用时删掉）：

你是一名资深的测试架构师，现在需要把产品需求文档解析为结构化的可测试需求条目。 解析规则： 1. 只抽取可作为测试依据的功能性描述，忽略背景介绍、宣传文案、非功能性泛泛表达。 2. 每条需求输出以下字段： - module：所属模块 - requirement_id：需求编号，按 REQ-001、REQ-002 格式递增 - requirement：一句话描述该需求，不超过50字 - business_rule：业务规则约束，如果原文没有就填“无” - acceptance_criteria：验收标准，原文有就提取，没有就填“无” 3. 输出为 JSON 数组，不要输出任何其他解释文字。 4. 如果某段描述中包含“快速”“方便”“优化体验”“流畅”“稳定”等模糊词汇， 请标注 confidence=low，不要擅自定义具体指标，如实描述原文。

这段提示词里最关键的是第 4 条。实际需求文档里，“更快更稳更流畅”这类话到处都是，模型最容易在这里开始编造“响应时间小于 200 毫秒”“崩溃率低于 0.1%”——这些数字它从哪来的？完全是它自己脑补的。我调优过程中专门花了两版迭代来堵这个 bug。经验就是：必须显式告诉模型“不要补全模糊指标”，否则它一定会补。

3.4 解析节点之后的 JSON 清洗，必须做一个代码节点

Dify 里 LLM 节点返回的内容经常是带格式的文本，而不是真正可用的 JSON。最常见的情况是模型输出被包在```json和```代码块标记里，或者前面多了一句“好的，以下是解析结果：”这类废话。这是 Dify 工作流里最容易踩的坑。

解决办法是在 LLM 节点后面加一个代码节点，专门负责从 LLM 输出中提取 JSON 数组，并做一次格式校验。我用的是 Python 代码节点：

import json, re def main(text: str) -> dict: # 去掉可能的 ```json 或 ``` 代码块标记 cleaned = re.sub(r'```json|```', '', text).strip() # 从头找到一个 [ 开始截取，避免模型在前面加了多余解释 start = cleaned.find('[') end = cleaned.rfind(']') + 1 if start == -1 or end == 0: return {"success": False, "error": "未找到JSON数组"} arr = json.loads(cleaned[start:end]) return {"success": True, "requirements": arr}

这段代码看着简单，但它解决的是一个会持续出现的真实问题。Dify 的 LLM 节点哪怕你提示词里写了“不要输出解释”，部分模型还是会偶尔不听话。有了这个代码节点兜底，流水线的稳定性立刻上了一个台阶。

4. 第二步实操：需求条目到测试用例的核心转换

4.1 把测试设计方法论写进提示词，而不是指望模型自学

进入核心步骤了。很多人写“让 AI 生成测试用例”的提示词，就是一句“请把这段话转成测试用例”，输出结果通常惨不忍睹——全都是同质化的正向流程用例，格式像流水账，边界值和异常流几乎空白。

要让模型输出专业用例，不能靠它“自学”，而要把测试设计方法论显式地写进提示词。我在用例生成节点的提示词里，把所有要用的测试设计方法拆开列出，并要求模型对每条需求逐项推理：

• 等价类划分：为输入项设置合法值、非法值、边界内值、边界外值，保证每个分区都有用例覆盖
• 边界值分析：取上点、内点、离点三种典型值，作为测试输入
• 场景法：设计主成功场景、备选场景、异常回退场景
• 错误推测：针对常见输入异常、状态冲突、依赖未满足等情况补充用例

不用要求每条需求都生成所有类型的用例，但模型必须自己判断这条需求适合哪些类型。比如一个输入框相关需求，重点就放在等价类和边界值；一个订单状态流转的需求，重点放在场景法。这样输出出来的用例组才有针对性，而不是套路化的八股文。

4.2 用例生成节点的完整提示词模板，可直接抄

我给一个目前在用的模板。这个模板经过了多轮调整，核心是把需求条目、业务规则和任务要求一次性传给模型，并要求它先列测试要点，再生成用例——这一步对提高用例质量很有用，相当于强制模型先思考再输出。

【需求条目】 module: 用户中心 requirement_id: REQ-003 requirement: 用户修改手机号时，需要验证新手机号通过短信验证码校验 business_rule: 1. 新手机号不能与当前绑定手机号相同；2. 验证码有效期5分钟；3. 每天最多发送5次短信； acceptance_criteria: 修改成功后，旧手机号立即失效；用户需要在30天内重新登录。 【任务】 1. 请先列出该需求的核心测试要点，再生成测试用例。 2. 用例必须覆盖功能流程、异常流程、边界情况。测试设计方法包括等价类划分、边界值分析、场景法、错误推测。 3. 每条用例包含字段： - case_id - case_title - preconditions - steps（步骤数组） - expected_result - priority（P0/P1/P2） - case_type（function/boundary/exception/scenario） 4. 输出为 JSON 数组，不要输出任何解释文字。

这里有两个容易忽略的细节。

第一，preconditions（前置条件）字段特别重要。前置条件写清楚了，执行用例的人才知道“要从哪个页面开始、需要准备什么数据”。我在提示词里要求步骤中必须写清具体测试数据，比如“准备一个新手机号 1381234、一个当前手机号 1395678”。数据显式化程度越高，这份用例越接近“初级工程师可以照着执行”的状态，而不是一份要求人脑补的提纲。

第二，case_type 字段在后期统计覆盖率时非常有用。它让模型在生成时就有分类意识，结果能直接拉一个统计图：看一个需求的用例里异常流占比多少、边界值有没有覆盖到，哪些需求只有正向用例、没有异常用例，一目了然。

4.3 输出结构设计要和用例管理工具字段对齐

用例生成节点出来的结果，我建议直接输出为 JSON，并且字段跟团队的用例管理工具一一对应。以禅道为例，导入 CSV 或 Excel 时需要用例标题、前置条件、步骤、预期结果、优先级、类型这些字段。如果输出 JSON 和导入模板字段完全对齐，就可以直接写个脚本把 JSON 转成 CSV 导入，整条链路彻底自动化。

我给自己定的输出格式约束如下：

• case_title：不超过 30 字，必须包含“模块-操作-预期”中的核心三要素
• steps：步骤数不超过 8 步，每步必须简明可执行
• priority：对齐团队 P0/P1/P2 三分法，P0 是核心流程，P1 是重要功能，P2 是一般情况
• case_type：覆盖 function/boundary/exception/scenario 四种类型

这些约束写在提示词里，模型会遵守。实际跑下来，我只需要一个简单的 Python 脚本把 JSON 转成禅道 CSV 模板，然后一键导入，整条“需求文档 → 测试用例”链路就真的彻底全自动了。

5. 工作流编排：把节点串成一个可用、可扩展的流水线

5.1 Dify 工作流里完整的节点连接顺序

Dify 里编排这个流水线，核心节点顺序如下：

1. 开始节点（Start）：接收文件上传或文本输入。
2. 文档解析节点（LLM）：输出需求条目 JSON 数组。
3. 代码节点（Code）：解析 JSON、格式校验、剥离代码块标记。校验失败走失败分支。
4. 迭代节点（Iteration）：按批次处理需求条目，每批 5~8 条。
5. 用例生成节点（LLM）：输入该批需求条目，输出用例 JSON 数组。
6. 汇总节点（Code）：把每批生成的用例数组合并成一个完整数组。
7. 人工审核配置节点（Code）：统计用例总数，判断是否需要人工介入。
8. 结束节点（End）：输出 Markdown 表格或完整 JSON。

这里有一个新手最容易掉的坑：Dify 工作流里，LLM 节点返回的 JSON 经常是字符串，不是真正的对象。如果你在后面直接连一个 LLM 节点想继续处理它，会发现数据是“一堆带格式的文本”，没法用。原因是模型输出被包装成了带代码块标记的字符串。你必须用代码节点先解析一次，把它变成真正的对象，后面才能继续流转。我这部分实际排障时花了不少时间，建议你用同样思路提前预防。

5.2 人工确认分支：设计成“半自动”而不是“全自动”

我一直在强调自动化的目标不是取代人，而是把人从重复劳动里解放出来。在流水线里，这体现在“人工确认分支”的设计上。

我在用例生成节点后面加了一个代码节点，用来统计本次用例数量和覆盖情况。如果发现用例数量低于某个阈值（比如一个需求条目的用例少于 3 条）、输出的 JSON 非法、或者有需求条目被标记为低置信度，就走“需要人工确认”的分支；如果一切正常，走正常输出分支，直接给出结果。

这个设计带来的使用体验是：平时流水线自动跑，不用人盯着看；只有异常情况才需要人介入处理。这比“每次都让人审核所有输出”更能让团队接受，也比“完全不管质量直接入库”更稳妥。实际用下来，人工需要介入的频率大约在 20% 左右——也就是说 80% 的文档，流水线可以全自动跑完直接输出可用结果。

更进一步，我建议把“人工确认”做成一页小报告，内容包含：这条需求生成了多少条用例、覆盖了哪些类型、哪些需求条目被标注为低置信度。审核人看报告的时间被压缩到一分钟以内，真正做到了“让机器做粗加工，人做精审核”。

5.3 长文档怎么处理：分批迭代比一次硬塞更稳定

长文档在 Dify 工作流里有一个隐藏的坑：即使模型支持长上下文，把整份上万字的需求一次塞进某个 LLM 节点，输出质量也会明显下降，而且费用高。实际测试感受是，超过一定长度后模型会“上下文漂移”——开头看到的内容记得，看到中间就忘了前面，输出开始出现重复或遗漏。

解决方法是把需求条目切分成小组，通过迭代节点分批处理。Dify 里的迭代节点类似编程里的 for 循环，每次从数组中取一批数据送进下游节点，处理完再取下一批。

我实际用的分批策略：每个批次放 5~8 条需求条目。这个数量是实测出来的折中值——太少浪费接口调用次数，太多模型会开始丢细节。假设一次解析得到 40 条需求条目，就分成 5 个批次，分别生成一组用例后再合并。这样单次调用的输入 token 和输出 token 都在可控范围内，效果也最稳。

还有一个细节值得提：迭代节点的输出需要用一个汇总节点把它们 merge 成完整数组，否则你会得到多个独立的数组，而不是一份完整的结果。这个步骤很多人会漏，直到最后发现结果对不上才回头补。

6. 实测效果、翻车现场和调优清单

6.1 我用几份真实需求文档跑的效果数据

说数据最有说服力。我拿了三份真实需求文档做测试，分别是：

第一份是电商后台的“优惠券创建”功能需求。文档一共 6000 多字，包含背景、功能列表、业务规则、接口字段说明。人工编写这份用例大约需要两个小时。丢进流水线后，解析出 15 条需求条目，最终生成 54 条用例，其中功能用例 20 条、边界用例 14 条、异常用例 12 条、场景用例 8 条。最关键的是需求文档里“每人限领一张”“叠加规则不能同时使用”“满减券和折扣券互斥”这些容易漏的业务约束，全都被捕捉到了。

第二份是 App 端登录流程的改造需求。这份文档体量小一些，但有一个隐蔽的“多端登录互踢”规则藏在需求细节里。人工写用例很容易漏掉这个场景。但因为我在提示词里强制要求了“错误推测”和“场景法”，模型把它挖出来了，生成了一条“同一账号在设备 A 登录后，设备 B 再次登录，设备 A 被踢下线”的场景用例。这正好体现了流水线的核心价值——用模型的长文本理解能力补足人的注意力盲区。

第三份是一个政务类系统的字段校验需求，大部分是输入框、下拉框、日期格式这类内容。这类需求最大的工作量在等价类和边界值。流水线生成的用例在“日期格式错误”“数字超上限”“必填项为空”这些场景上覆盖得很干净，几乎可以直接用。

6.2 翻车场景复盘：长文本截断、模糊词幻觉、格式解析失败

所有 AI 应用都要经历“看起来很美好→实际跑起来全是问题”的阶段，这条流水线也不例外。我把踩过的坑全部列出来，希望你能绕过去。

第一坑：长文本截断导致 JSON 残缺。某些模型的单次输出 token 上限设置得比较保守，比如默认 2000。当我一个批次塞了太多需求条目、要求输出 20 条用例时，输出就会在中间被截断，返回一个残缺的 JSON 数组。这个问题处理起来不复杂：

• 把输出 token 上限调大，至少 4000；
• 减小每批需求条目数量，控制在 5~8 条；
• 在汇总节点加一个 JSON 合法性校验，不合法就自动重试一次。

第二坑：模糊词幻觉。这个前面已经提到过，但值得再强调。需求文档里的“快速”“流畅”“稳定”“好用”这些词，模型一定会脑补出具体指标。我见过最离谱的一次，模型给“优化首屏加载速度”生成了一条“首屏加载时间应小于 300ms”的验收标准——需求文档里根本没有这个数字。这个问题的根治方案是提示词里显式加入 confidence=low 规则，并在后续用例生成节点里过滤掉低置信度条目，不让他们进入用例生成环节。

第三坑：表格解析失败。需求文档里经常有“计费规则”“字段映射表”这类表格。Dify 直接解析 PDF 时，表格经常错位、拆分、甚至整行丢失。我后来统一走了“先转 Markdown 再进工作流”的预处理路径，表格以 Markdown 表格形式传进去，准确率才上来。

6.3 调优清单和参数组合，照着抄就行

最后给出我落地的参数组合，给读者一个可以直接抄写的参考：

如果你也在公司内部做类似的事情，我再给一个建议：流水线跑通之后，把平时积累的“优秀用例模板”和“测试设计规范”沉淀到知识库里。Dify 知识库不只用于 RAG 检索，它还能充当团队的标准活文档。以后新人来了，直接让他看流水线是怎么搭的、模板是怎么写的，比看十页规范文档都管用。

6.4 最后再分享一个实用技巧：把“生成用例模板”这件事本身也做成反馈闭环

流水线不是搭完就结束了，要持续迭代。我每个季度会把流水线生成的用例拿到测试团队过一遍，让大家把“生成质量差”的用例标注出来。这些反馈不直接回填到模型，而是用来优化知识库里的用例模板和提示词里的规则。例如有一次，团队反馈系统生成的“字段长度边界值”用例没有把“字符类型”和“字节类型”区分开，我就在提示词里加了一条规则：“边界值分析需区分字符长度和字节长度，特别是有中文输入的场景”。

这个小改动让它后续生成的用例在中文系统里准确率高了很多。流水线的价值在于，它不只把现有的文档转换成了用例，还能把团队的反馈持续沉淀成生成模板，让工具越用越聪明。这一点是手工写用例完全做不到的。

我个人在这一整轮调试中的最大收获是：AI 生成测试用例这件事，难点从来不是“生成”，而是“可控”。你花 80% 的精力去堵模型胡说八道的口子、拆解流程、设计校验分支，这些做好了，模型才能真正成为你团队里的得力助手。把这条思路跑通了，它就不再是一个新鲜玩具，而是一件每天都能帮你省时间的趁手工具。