在动手读任何一章之前，先回答三个问题。这三个问题分别对应本教程的三条主线：业务是什么、系统长什么样、新人从哪入手。
一问：何谓"LLM 测试用例生成"------一份策划文档的旅程
想象你是一家游戏公司的测试工程师。周一早上，策划给你发来一份 60 页的 Word 文档《挂机二期功能设计》，
里面有正文规则、数值表格、界面截图、流程图，还有大段的版本说明和设计意图。你的任务：在下个版本测试之前，
把它变成测试要点 （要测什么）和测试用例（怎么测、每一步做什么、期望结果是什么）。
一个熟练的测试工程师做这件事大概要 3~5 天。而一个版本迭代周期里，这样的文档可能有十几份。
本系统做的事情就是把这趟旅程自动化：
策划文档 (docx/xlsx)
│ ① 转换：变成结构化 Markdown（convert2md 服务）
▼
结构化 Markdown (*_SRC_*.md)
│ ② 理解：提取"功能实体"树------文档里到底定义了哪些可被测试的功能（generator 服务）
▼
实体集合 (*_ENT_*.json)
│ ③ 要点：对每个功能生成四象限测试要点（generator 服务）
▼
测试要点 (*_PNT_*.json)
│ ④ 用例：对每条要点展开成带步骤和断言的测试用例（generator 服务）
▼
测试用例 (*_CAS_*.json)
│ ⑤ 评估：对照原文给生成质量打分（evaluator 服务）
▼
评估报告 (*_EVAL_*.json)大模型（LLM）在这趟旅程里干什么？ 它是"读文档、写用例"的那个脑力角色------理解一段策划规则、
判断哪些是可测试的功能、写出一条边界条件的测试用例，这些都是传统代码做不了的语义任务。
但请注意一个贯穿全教程的重要认知：LLM 只出现在少数几个关键节点上，整条流水线的大部分是确定性代码 。
什么时候信 LLM、什么时候用代码兜住 LLM 的不可靠，恰恰是本工程最有价值的工程经验。
二问：系统长什么样------四服务鸟瞰
整个系统是四个独立运行的 FastAPI 服务加两个共享包：
| 服务 | 端口 | 一句话职责 |
|---|---|---|
| convert2md | 8000 | 把 docx/xlsx 转成结构化 Markdown（含图片理解） |
| generator | 8001 | 实体提取 → 测试要点 → 测试用例（LLM 使用最重） |
| evaluator | 8002 | 给产物打分（规则 + LLM 双轨） |
| dashboard | 8080 | 统一工作台：界面、任务编排、产物归档 |
外加共享层：model_core（LLM 客户端、统一实体标准、提示词库）和 modules/common（阶段映射、
词表、日志）------四服务共用的"轮子"都放这里，谁也不许自己造副本。
服务之间没有直接调用关系 ：生成链由 dashboard 的前端逐阶段驱动（浏览器 → 各服务），
数据则通过约定好的目录结构传递（下一章详讲）。这是一种刻意的松耦合设计。