这本教程是什么：面向新加入本项目的工程师的入门教材——带你从零理解本系统的业务（游戏策划文档如何变成测试用例）
和实现（四个服务怎么协作、LLM 在其中扮演什么角色、用了哪些技术栈）。

读者假设：会 Python 开发（写过 FastAPI 更好），但不熟悉游戏测试业务，也没有大模型（LLM）应用开发经验。
两样都不会没关系，本教程从零讲起。

开篇 测试用例生成三问

在动手读任何一章之前，先回答三个问题。这三个问题分别对应本教程的三条主线：业务是什么、系统长什么样、新人从哪入手。

一问：何谓"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 服务加两个共享包：

外加共享层：model_core（LLM 客户端、统一实体标准、提示词库）和 modules/common（阶段映射、
词表、日志）——四服务共用的"轮子"都放这里，谁也不许自己造副本。

服务之间没有直接调用关系：生成链由 dashboard 的前端逐阶段驱动（浏览器 → 各服务），
数据则通过约定好的目录结构传递（下一章详讲）。这是一种刻意的松耦合设计。