用户分析（画像 · 工作流 · 痛点）

层：参考（画像/痛点溯源，优先级证据）｜更新触发：新观察材料｜注册表：README

状态：骨架稿，待补充。带 [TODO] 的内容需要作者依据真实观察/访谈填充。痛点编号与 PROGRESS.md 需求池的 G 编号对应，用于需求的优先级溯源。

用户一：建筑史 / 遗产保护研究者（核心用户）

目标：将测绘数据转化为参数化模型与可出版图纸；保证方法可复现、可引用。
工作流：
1. 现场测绘 / 借用测绘图 → 提取开间、进深、柱高、柱径等尺寸
2. 按「缝」体系整理轴线与构件数据（JSON）
3. 运行管线生成模型与三视图
4. 图纸修整 → 出版 / 汇报 [TODO: 观察到的实际流程细节]
痛点：
- P-a：AutoCAD/SketchUp 手工绘图重复劳动大，改一个尺寸要全图重排 [TODO: 求证]
- P-b：现有多数参数化工具（Grasshopper 等）门槛高、难版本化、难复现
- P-c：古建术语与坐标体系缺乏公开编码标准，各自为政 [TODO: 与论文相关工作对照]
对应需求：P-a → 尺寸标注 [P0]、整排 pattern（开放问题 1）；P-b → JSON 数据层、CLI/Makefile、CI；P-c → coding-system.md 本身；构件筛选（G15）← 工作流步骤 2/3 中"核对某缝上的构件"场景 [TODO: 求证使用频率]

目标：低成本获得考据可信的中国古建 3D 资产，导入 Blender / 游戏引擎。
工作流：
1. 浏览仓库示例（预览图 / STL / OBJ）
2. 调整 D 与构件数据批量生成变体
3. Blender 中减面 / UV / 材质 → 引擎 [TODO: 验证该流程是否成立]
痛点：
- P-d：市面中国古建资产风格混杂、缺乏尺寸依据
- P-e：程序化生成的 mesh 面数高，需可控细分（FN 参数已有，缺文档说明）
对应需求：P-d → 构件类型扩展（G3–G6）；P-e → 构建缓存（G8）、断面参数化、FN 文档化 [TODO: 是否新增 G 编号]

2026-09 README 目标读者扩展时新增，定位介于研究者与游戏开发者之间。

目标：快速获得"有出处、有依据"的古建模型，用于个人创作、3D 打印或社交分享；不接触 JSON 与命令行。
工作流：
1. 打开 Web 工作台 → 调整 D → 看预览
2. 下载 STL / 预览图
3. Blender 微调 / 3D 打印 / 分享 [TODO: 求证真实动线]
痛点：
- P-f：不会写 JSON，工作台的 D 输入是唯一交互入口，能力边界窄
- P-g：不知道模型"对不对"——需要通俗的出处/考据说明（编码体系的学术严谨性对这类用户是信任背书而非使用门槛）
- P-h：分享友好的格式偏好（GLB/glTF？当前仅 STL/OBJ）[TODO: 评估]
对应需求：P-f → G12 Web 数据编辑、G15 构件筛选；P-g → README 示例输出、图纸可读性；P-h → 导出格式扩展（如 GLB，另立需求项前先求证）