2026-06-21 回顾
再次询问 Godot 官方文档 JSONL 转换流程
向 Qwen 粘贴了 2026-06-21-initial-rag-classifier-architecture.md 的模式内容，询问将 Markdown 文档转换为 JSONL 的 Python 代码方向。
最初问题的核心是简单的转换脚本。
- 需要一个把 Markdown 输入转换为 JSONL 的 Python 代码
- 如果能一起提供运行命令就更好了
- 想通过调用 Qwen API 来生成 JSONL 内容
- 保存为 JSONL 时必须保证模式不被破坏，因此需要检查逻辑
- 想使用正则表达式或模式验证来确认 JSONL 格式
- 在调用 API 时希望模型判断应映射到哪个表
- 如有必要，需要生成
docs_chunks、api_mapping、label_prototypes的完整模式
从 CLI 脚本到 Web 工具的思路扩展
随后判断仅用简单的 CLI 转换器难以查看整个流程，于是考虑了 Web 调用的结构。
- 如果可以在网页上输入 API key 那就好了
- 支持 Markdown 文件上传或文件夹上传会更好
- 能在网页上直观看到转换前后的 diff 或变更内容会更好
- 与其仅生成结果文件，不如让人能够审查转换过程和判定结果
在提出这些问题时，感觉 JSONL 转换器不应只是批处理脚本，而应是让人审查并批准的数据加工工具。
再次确认单文件可能映射到多个表的问题
最重要的补充问题是：一个 Markdown 文件不一定只映射到一个表。
例如，一个 migration 文档可以同时生成以下三种 JSONL：
- 官方说明块
docs_chunks.jsonl - API 变更规则
api_mapping.jsonl - 转换/分类示例
label_prototypes.jsonl
因此转换器不能只接受一个文件并生成单一 JSONL，而是需要先调用 Qwen 判断需要哪些表记录，如果出现多条响应，则必须能够在同一个文件中生成两个或更多的 JSONL 记录。
今日确定的设计方向
- 将 Markdown 到 JSONL 的转换划分为
分类 → 生成 → 验证 → 保存四个阶段。 - Qwen 可以负责阅读正文并判断所需的目标表。
- 但不应盲目信任 Qwen 的响应，最终是否保存应由本地模式验证器决定。
- 正则表达式仅用于最基本的格式检查，实际字段验证更适合使用 JSON Schema 或 Pydantic 等结构化验证方式。
- 默认前提是单个 Markdown 文件可能产生多个 JSONL 输出。
- Web UI 不只是简易的便利功能，而是一个让人检查并批准自动生成记录的审查层。
下一步工作备忘
- 为
docs_chunks、api_mapping、label_prototypes编写 JSON Schema 初稿。 - 设计提示词，使 Qwen 在接收单个 Markdown 文件后能够判别目标表候选。
- 当 Qwen 的响应包含多个表记录时，制定按文件分离保存的规则。
- 首先在 CLI 中实现逐行验证 JSONL 的脚本。
- 然后在 Web UI 中扩展，实现上传、转换、diff、验证结果、批准/驳回的完整流程。
留下的问题
- 将表映射判别交给 Qwen，但在什么情况下必须由人必定批准？
api_mapping的候选是直接生成后立即写入数据库，还是仅保存为candidate状态？- Web UI 中的 diff 是相对于原始 Markdown 的 JSONL diff，还是相对于之前的 JSONL 版本的 diff？
- 文件夹上传时，如何对失败的文件和部分成功的文件进行重试？