feat(tools): 白模关卡自动生成Python脚本——Level Builder

两阶段流水线：搭建指南Markdown → JSON → UE5 Actor
- 解析器：4种表格变体+范围展开+坐标表达式计算
- 配置：37种BSP资产映射+13种材质+7区域定义
- 验证：265个Actor全部通过，0错误
- Builder：UE5 Python API自动放置Actor+材质+Outliner
- 报告：自动生成搭建报告Markdown

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.claude/agent-memory/game-dev/MEMORY.md

@@ -0,0 +1 @@
+- [Level Builder Tool](level-builder-tool.md) — 白模关卡自动生成 Python 脚本（tools/level-builder/，265 Actor 解析验证通过）

.claude/agent-memory/game-dev/level-builder-tool.md

@@ -0,0 +1,44 @@
+---
+name: level-builder-tool
+description: 白模关卡自动生成 Python 脚本工具，位于 tools/level-builder/
+metadata:
+  type: project
+---
+
+# Level Builder 工具
+
+## 位置
+`tools/level-builder/`
+
+## 功能
+两阶段流水线：解析搭建指南 Markdown → JSON → UE5 Actor
+
+## 使用方式
+```bash
+# 解析
+python tools/level-builder/main.py parse -i docs/technical/关卡-v01-搭建指南.md -o output/level_v01.json
+
+# 验证
+python tools/level-builder/main.py validate -i output/level_v01.json
+
+# 报告
+python tools/level-builder/main.py report -i output/level_v01.json -o output/搭建报告.md
+```
+
+## UE5 构建
+在 UE5 编辑器 Python 控制台中：
+```python
+exec(open(r"tools/level-builder/main.py").read())
+# 然后 main(["build", "-i", "output/level_v01.json"])
+```
+
+**Why:** 替代手动白模关卡搭建流程，从策划执行案/搭建指南自动生成关卡
+**How to apply:** 收到白模搭建任务时，优先运行此工具而非手动操作
+
+## 依赖
+- UE5 PythonScriptPlugin 已在 .uproject 中启用
+- 37 种 BSP 资产映射（config/asset_mapping.py）
+- 当前解析搭建指南（parsers/build_guide_parser.py），未来扩展执行案解析器
+
+## 数据
+- v0.1 解析结果：265 个 Actor（STR:123, PROP:53, BND:61, INTR:10, COLL:9, LGT:8, PLAY:1）

.claude/agents/game-designer.md

@@ -35,7 +35,7 @@ memory: project
 
 ```
 概念草案（灵魂）→ 系统设计案（骨架）→ 执行案（血肉）
-  concept.md         <system>.md           <system>-execution.md
+  概念草案.md         <系统名>.md           <系统名>-执行案.md
   "这个游戏是什么"   "有哪些系统，如何关联"  "程序实现的交互规则"
 ```
 
@@ -43,29 +43,29 @@ memory: project
 
 ```
 docs/design/
-  concept.md                              # 概念草案（原型阶段开始后冻结）
+  概念草案.md                              # 概念草案（原型阶段开始后冻结）
   prototype/                              # 原型阶段产出
     README.md                             # 设计文档索引
-    <system>.md                           # 系统设计案
-    <system>-execution.md                 # 执行案
-    scene-v<XX>-<name>.md                 # 场景设计（索引中链接）
-    brainstorm-YYYY-MM-DD-<topic>.md      # 头脑风暴记录
+    <系统名>.md                           # 系统设计案
+    <系统名>-执行案.md                    # 执行案
+    场景-v<XX>-<名称>.md                  # 场景设计（索引中链接）
+    头脑风暴-YYYY-MM-DD-<主题>.md         # 头脑风暴记录
   production/                             # 批量生产阶段（从 prototype/ 复制）
 
 GameConfig/                               # 数值配置表
-  <name>.csv / <name>.json
+  <名称>.csv / <名称>.json
 ```
 
 ### 文件命名规范
 
 | 文档类型 | 格式 | 示例 |
 |---------|------|------|
-| 头脑风暴 | `brainstorm-YYYY-MM-DD-<topic>.md` | `brainstorm-2026-06-01-vision-pillars.md` |
-| 系统设计案 | `<system>.md` | `interaction-system.md` |
-| 执行案 | `<system>-execution.md` | `player-controller-execution.md` |
-| 场景设计 | `scene-v<XX>-<name>.md` | `scene-v01-suburban.md` |
-| 关卡执行案 | `level-v<XX>-<name>-execution.md` | `level-v01-suburban-execution.md` |
-| 配置表 | `<name>.csv` 或 `<name>.json` | `marble-params.csv` |
+| 头脑风暴 | `头脑风暴-YYYY-MM-DD-<主题>.md` | `头脑风暴-2026-06-01-愿景支柱.md` |
+| 系统设计案 | `<系统名>.md` | `交互系统.md` |
+| 执行案 | `<系统名>-执行案.md` | `玩家控制器-执行案.md` |
+| 场景设计 | `场景-v<XX>-<名称>.md` | `场景-v01-城郊小街.md` |
+| 关卡执行案 | `关卡-v<XX>-<名称>-执行案.md` | `关卡-v01-城郊小街-执行案.md` |
+| 配置表 | `<名称>.csv` 或 `<名称>.json` | `弹珠参数.csv` |
 
 ---
 
@@ -83,10 +83,10 @@ GameConfig/                               # 数值配置表
 2. **一次一个问题** — 使用 AskUserQuestion 提供选项或开放提问。绝不一次性抛出所有问题。
 3. **要具体场景** — 如果回答模糊，问"你能描述一下那个时刻的画面吗？"
 4. **及时总结共识** — 每个子话题讨论后，总结并确认双方理解一致。
-5. **记录结果** — 写入 `brainstorm-YYYY-MM-DD-<topic>.md`。
+5. **记录结果** — 写入 `头脑风暴-YYYY-MM-DD-<主题>.md`。
 
 ### 头脑风暴记录
-- 位置：`docs/design/<stage>/brainstorm-YYYY-MM-DD-<topic>.md`
+- 位置：`docs/design/<stage>/头脑风暴-YYYY-MM-DD-<主题>.md`
 - 性质：非正式会议笔记，无固定格式，记录要点和共识。
 - 目的：下次会话阅读，避免重复讨论。
 
@@ -113,7 +113,7 @@ GameConfig/                               # 数值配置表
 ## 阶段特定行为
 
 ### 草案阶段
-- 产出 `docs/design/concept.md`，包含 7 个必填字段：
+- 产出 `docs/design/概念草案.md`，包含 7 个必填字段：
   1. 一句话描述
   2. 玩家核心游玩内容与感受
   3. 核心受众画像
@@ -122,8 +122,8 @@ GameConfig/                               # 数值配置表
   6. 市场定位与三大卖点
   7. 参考
 - 极轻量；可以反复推翻。
-- **用户确认并进入原型阶段后：concept.md 冻结。** 不再修改。
-- 偏离概念的内容应记录在系统设计案中并说明原因，不修改 concept.md。
+- **用户确认并进入原型阶段后：概念草案.md 冻结。** 不再修改。
+- 偏离概念的内容应记录在系统设计案中并说明原因，不修改概念草案.md。
 
 ### 原型阶段
 - 灵活性：核心行为必须完整，非核心可略过。
@@ -343,8 +343,7 @@ GameConfig/                               # 数值配置表
 ## 阅读参考文档
 
 开始工作前，阅读相关参考文档：
-- `.claude/refs/development-workflow.md` — 流水线定义、阶段划分、质量标准
-- `docs/design/concept.md` — 已冻结的概念草案（只读参考）
+- `docs/design/概念草案.md` — 已冻结的概念草案（只读参考）
 - 已有的设计文档 `docs/design/<stage>/` — 产出新文档前了解当前状态
 - 项目管理工具 — 查看分配给你的任务和流水线状态
 
@@ -361,7 +360,7 @@ GameConfig/                               # 数值配置表
 ### 产出时机
 
 关卡执行案在 **③执行案阶段** 产出，与系统执行案同步。产出前先阅读：
-- 对应的场景设计案 `scene-v<XX>-<name>.md`（氛围愿景）
+- 对应的场景设计案 `场景-v<XX>-<名称>.md`（氛围愿景）
 - `.claude/refs/level-execution-template.md`（文档模板）
 - `.claude/refs/blockout-asset-reference.md`（BSP 资产参考卡）
 
@@ -369,13 +368,13 @@ GameConfig/                               # 数值配置表
 
 1. **混合坐标体系**：区域用场景绝对坐标（原点在西南角），区域内物件用相对偏移坐标
 2. **BSP 资产建议是方向性指引**：引用资产类别名和组合方式（如 "Wall_400x300 × 2"），不写文件路径
-3. **交叉引用**：交互物引用 `interaction-system-execution.md` 编号，收集品引用 `collection-system-execution.md` 编号
+3. **交叉引用**：交互物引用 `交互系统-执行案.md` 编号，收集品引用 `收集系统-执行案.md` 编号
 4. **不越界**：不写引擎组件名、文件路径、Blueprint 类名
 5. **标识色**：每个区域指定 `MI_Dev<颜色>` 标识色材质，供白模阶段区分
 
 ### 完整规范
 
-参见 `docs/design/prototype/level-design-workflow.md`。
+参见 `docs/design/prototype/关卡设计工作流.md`。
 
 ---
 

.claude/agents/game-dev.md

@@ -20,7 +20,7 @@ memory: project
 
 | 文档 | 路径 | 用途 |
 |------|------|------|
-| 技术设计方案 | `docs/technical/<system-name>-tech.md` | 回应执行文档每条规则的实现方案 |
+| 技术设计方案 | `docs/technical/<系统名>-技术方案.md` | 回应执行文档每条规则的实现方案 |
 | C++ 源码 | `Source/` | 引擎级系统、性能关键路径 |
 | 蓝图资产 | `Content/Blueprints/` | 游戏逻辑、UI、交互 |
 | DataAsset | `Content/Data/` | 数据驱动的配置资产 |
@@ -88,10 +88,10 @@ memory: project
 ```
 
 **必须按序阅读的输入**：
-1. 执行文档 (`docs/design/<stage>/<system-name>-execution.md`) — 行为规则细节
-2. 系统设计文档 (`docs/design/<stage>/<system-name>.md`) — 全局上下文
+1. 执行文档 (`docs/design/<stage>/<系统名>-执行案.md`) — 行为规则细节
+2. 系统设计文档 (`docs/design/<stage>/<系统名>.md`) — 全局上下文
 3. 配置表 (`GameConfig/`) — 可调参数
-4. 概念文档 (`docs/design/concept.md`) — 方向参考（需要理解设计意图时查阅）
+4. 概念文档 (`docs/design/概念草案.md`) — 方向参考（需要理解设计意图时查阅）
 
 **技术设计文档**：按 `.claude/skills/requirements-analysis/` 中定义的需求分析 skill 产出。
 
@@ -124,14 +124,14 @@ memory: project
 当版本开发涉及场景搭建时，白模搭建是 ⑥程序实现的首要子任务。
 
 **输入**：
-- `level-v<XX>-<name>-execution.md` — 关卡执行案（空间指南）
-- `scene-v<XX>-<name>.md` — 场景设计案（氛围参考）
+- `关卡-v<XX>-<名称>-执行案.md` — 关卡执行案（空间指南）
+- `场景-v<XX>-<名称>.md` — 场景设计案（氛围参考）
 - 系统执行案（交互物/收集品清单）
 - `Content/BlockingStarterPack/` — BSP 资产
 
 **输出**：
 - `Content/Maps/LVL_<SceneName>V<XX>.umap` — 白模关卡文件
-- `docs/technical/level-v<XX>-build-report.md` — 搭建报告（偏差记录）
+- `docs/technical/关卡-v<XX>-搭建报告.md` — 搭建报告（偏差记录）
 - **在对应任务 Issue 下以评论发布搭建报告**（包含偏差清单、资产替代、缩放记录、比例验证结果，使 PM 和策划能直接在 Issue 中查看）
 
 **搭建流程**：
@@ -147,10 +147,10 @@ memory: project
 **Outliner 结构**：按区域分文件夹（Z1_家/Structure/、Z1_家/Props/、...），Global/ 放边界和光照。
 
 **搭建报告**：逐区域对照文档要求记录偏差，包含资产替代清单、缩放记录、未实现项、比例验证结果。**报告必须同时**：
-1. 写入 `docs/technical/level-v<XX>-build-report.md`（本地文件）
+1. 写入 `docs/technical/关卡-v<XX>-搭建报告.md`（本地文件）
 2. 以评论形式发布到对应任务 Issue（内容与本地文件一致，供 PM 和策划直接查看）
 
-**完整规范**：参见 `docs/design/prototype/level-design-workflow.md` 第四章。
+**完整规范**：参见 `docs/design/prototype/关卡设计工作流.md` 第四章。
 
 ### 工作流 C：代码实现（步骤⑥子任务 6b-6f）
 
@@ -292,22 +292,21 @@ memory: project
 ## 关键文件路径
 
 ### 你产出和维护：
-- `docs/technical/<system-name>-tech.md` — 技术设计文档
-- `docs/technical/notes/*.md` — 架构决策、技术选型笔记、经验教训
+- `docs/technical/<系统名>-技术方案.md` — 技术设计文档
+- `docs/technical/笔记/*.md` — 架构决策、技术选型笔记、经验教训
 - `Source/` — C++ 代码
 - `Content/Blueprints/` — 蓝图
 - `Content/Data/` — DataAsset 配置
 
 ### 你阅读：
-- `.claude/refs/development-workflow.md` — 流水线定义、质量标准
 - 项目管理工具 Issues — 查看分配给你的任务和流水线状态（参见 `.claude/skills/gitea-collab.md`）
-- `docs/plans/<stage>-roadmap.md` — 版本划分、范围
-- `docs/design/concept.md` — 游戏方向参考
-- `docs/design/<stage>/<system-name>.md` — 系统设计概览
-- `docs/design/<stage>/<system-name>-execution.md` — 行为规则（你的主要输入）
+- `docs/plans/<阶段>-路线图.md` — 版本划分、范围
+- `docs/design/概念草案.md` — 游戏方向参考
+- `docs/design/<stage>/<系统名>.md` — 系统设计概览
+- `docs/design/<stage>/<系统名>-执行案.md` — 行为规则（你的主要输入）
 - `GameConfig/*.csv` / `*.json` — 可调参数
-- `docs/plans/reviews/<task-id>-review.md` — PM 质量门审查结果
-- `docs/art/style-guide.md` — 视觉方向参考（集成美术时阅读）
+- `docs/plans/reviews/<任务ID>-审查记录.md` — PM 质量门审查结果
+- `docs/art/美术风格指南.md` — 视觉方向参考（集成美术时阅读）
 
 ---
 

.claude/agents/game-pm.md

@@ -30,9 +30,6 @@ memory: project
 
 ## 2. 参考文档与项目管理工具
 
-开始工作前，必须先阅读：
-- `.claude/refs/development-workflow.md` — 流水线定义、阶段划分、质量门标准（**首先阅读**）
-
 ### 项目管理工具
 
 进度管理（任务列表、流水线状态、角色汇报）全部通过项目管理工具追踪。当前使用 **Gitea**（Issues + Milestones），具体 CLI 命令、认证方式和标签体系详见：
@@ -40,9 +37,9 @@ memory: project
 > **`.claude/skills/gitea-collab.md`** — Gitea 协作工具完整参考
 
 **保留在本地的文档**（不在项目管理工具中管理）:
-- `docs/plans/prototype-roadmap.md` — 阶段路线图（信息量太大）
-- `docs/plans/reviews/<task-ID>-review.md` — 审查记录（详细结构化文档）
-- `docs/plans/work-log.md` — 工作日志
+- `docs/plans/原型阶段-路线图.md` — 阶段路线图（信息量太大）
+- `docs/plans/reviews/<task-ID>-审查记录.md` — 审查记录（详细结构化文档）
+- `docs/plans/工作日志.md` — 工作日志
 - 所有设计文档 (`docs/design/`)、技术文档 (`docs/technical/`)、美术文档 (`docs/art/`)
 
 **重要规则**：你的记忆只是参考信息，不能替代实际状态验证。"记忆说文件 X 存在" ≠ "X 现在存在"——使用前必须验证。
@@ -87,7 +84,7 @@ memory: project
 
 ### 审查后强制操作（无论谁执行审查）
 
-- [ ] 在 `docs/plans/reviews/<task-ID>-review.md` 写了审查记录
+- [ ] 在 `docs/plans/reviews/<task-ID>-审查记录.md` 写了审查记录
 - [ ] 在对应 Issue 上发布了审查结论评论（通过/不通过 + 摘要）
 - [ ] 更新了 Issue 的 gate:* 标签（通过→pass，不通过→fail）
 - [ ] **通过时**：关闭 Issue 并附完成说明
@@ -108,9 +105,8 @@ memory: project
 2. **获取活跃任务列表** → 所有进行中的任务
 3. **读取流水线追踪器状态** → 理解流水线位置
 4. **读取近期角色汇报** → 了解最新进展
-5. **检查本地审查记录**（如有）：检查 `docs/plans/reviews/` 中的近期质量门审查
-6. **交叉核对**流水线检查清单，确认当前流水线位置和阻塞点
-7. **向用户报告**：当前进度、阻塞点、建议的下一步行动
+5. **交叉核对**流水线检查清单，确认当前流水线位置和阻塞点
+6. **向用户报告**：当前进度、阻塞点、建议的下一步行动
 
 > 具体 CLI 命令参见 `.claude/skills/gitea-collab.md`
 
@@ -190,7 +186,7 @@ memory: project
 ### 必须获得用户确认：
 - 关闭 Issue（完成任务）和创建新 Issue
 - 创建新里程碑或关闭现有里程碑
-- 修改 `roadmap.md` 或 `prototype-roadmap.md`
+- 修改 `路线图.md` 或 `原型阶段-路线图.md`
 - 质量门不通过后退回工作
 - 重大偏差处理（回退或开新版本）
 - 阶段转换
@@ -234,8 +230,8 @@ memory: project
 |------|------|---------|
 | 任务追踪 | **项目管理工具 Issues**（唯一真实来源） | 任务状态变化 |
 | 流水线进度 | **Pipeline Tracker** | 流水线步骤变化 |
-| 阶段路线图 | `docs/plans/<stage>-roadmap.md` | 阶段开始、迭代调整 |
-| 审查记录 | `docs/plans/reviews/<task-ID>-review.md` | 每次质量门审查 |
+| 阶段路线图 | `docs/plans/<阶段>-路线图.md` | 阶段开始、迭代调整 |
+| 审查记录 | `docs/plans/reviews/<task-ID>-审查记录.md` | 每次质量门审查 |
 
 > 审查记录格式参见 `.claude/skills/quality-gate-review.md`
 
@@ -338,5 +334,5 @@ memory: project
 # PM Agent 记忆索引
 
 - [流水线阶段判断 2026-06-03](pipeline-status-20260603.md) — v0.1 处于阶段④执行案完善中，质量门未通过
-- [Roadmap 对齐问题](roadmap-alignment.md) — roadmap.md 缺少 v0.5-v0.7，需与 game-vision.md 对齐
+- [Roadmap 对齐问题](roadmap-alignment.md) — 路线图.md 缺少 v0.5-v0.7，需与游戏愿景.md 对齐
 - [设计文档质量审查](design-doc-review.md) — 交互系统技术越界、收集系统缺v0.1执行细节、边界情况不足

.claude/agents/game-reviewer.md

@@ -31,7 +31,6 @@ memory: project
 开始工作前，必须先阅读：
 - `.claude/skills/quality-gate-review.md` — **4 道质量门标准、阶段对应标准、审查流程**（核心技能）
 - `.claude/skills/gitea-collab.md` — Gitea CLI 命令和操作规范
-- `.claude/refs/development-workflow.md` — 流水线定义和阶段划分
 
 ---
 
@@ -56,7 +55,7 @@ memory: project
 ### 步骤 4：执行强制操作
 **必须**完成以下所有操作（缺一不可）：
 
-1. ✅ 在 `docs/plans/reviews/<task-ID>-review.md` 写审查记录
+1. ✅ 在 `docs/plans/reviews/<task-ID>-审查记录.md` 写审查记录
 2. ✅ 在对应 Issue 上发布审查结论评论（通过/不通过 + 摘要）
 3. ✅ 更新 Issue 的 gate:* 标签
 4. ✅ **通过时**：关闭 Issue（附完成说明）
@@ -72,7 +71,7 @@ node scripts/gitea.js --role pm issue comment <number> --body "## 质量门审
 
 **质量门**：[执行案/程序设计/美术资产/程序实现]
 **审查日期**：YYYY-MM-DD
-**审查记录**：docs/plans/reviews/<task-ID>-review.md
+**审查记录**：docs/plans/reviews/<task-ID>-审查记录.md
 
 ### 结论
 [一句话总结]
@@ -89,7 +88,7 @@ node scripts/gitea.js --role pm issue comment <number> --body "## 质量门审
 
 **质量门**：[执行案/程序设计/美术资产/程序实现]
 **审查日期**：YYYY-MM-DD
-**审查记录**：docs/plans/reviews/<task-ID>-review.md
+**审查记录**：docs/plans/reviews/<task-ID>-审查记录.md
 
 ### 结论
 [一句话总结]

.claude/refs/development-workflow.md

@@ -66,7 +66,7 @@
 
 #### 产出
 
-**玩法草案文档**（`docs/design/concept.md`），包含以下 7 个字段：
+**玩法草案文档**（`docs/design/概念草案.md`），包含以下 7 个字段：
 
 1. **一句话描述** — 用一句话说清楚这是什么游戏
 2. **玩家核心游玩内容与感受** — 玩家在游戏中的核心操作和活动，以及游戏希望带给玩家的情感基调、视觉风格和整体感受
@@ -76,7 +76,7 @@
 6. **市场定位与三大卖点** — 游戏在市场中的定位（品类、平台、价位），以及最能吸引玩家的三个核心卖点
 7. **参考** — 灵感来源（其他游戏、电影、书、某种经历）
 
-**美术风格指南**（`docs/art/style-guide.md`）— 确定视觉方向。
+**美术风格指南**（`docs/art/美术风格指南.md`）— 确定视觉方向。
 
 **技术可行性评估** — 评估核心玩法在目标引擎/平台上的实现可行性。
 
@@ -107,7 +107,7 @@
 
 | 层级 | 定位 | 比喻 | 特点 |
 |------|------|------|------|
-| **草案** (concept.md) | 给游戏**定调** | 灵魂 | 回答"这个游戏是什么"，简略但方向明确 |
+| **草案** (概念草案.md) | 给游戏**定调** | 灵魂 | 回答"这个游戏是什么"，简略但方向明确 |
 | **设计案** | 给游戏**定骨架** | 骨架 | 基于草案的原则展开系统设计，定义有哪些系统、系统关系、核心行为 |
 | **执行案** | 给游戏**填血肉** | 血肉 | 细化到程序可直接实现的交互规则和行为细节 |
 
@@ -123,7 +123,7 @@
 
 #### 阶段路线图
 
-原型阶段开始时，产出**阶段路线图**（`docs/plans/prototype-roadmap.md`）：
+原型阶段开始时，产出**阶段路线图**（`docs/plans/原型阶段-路线图.md`）：
 
 - 计划分几个版本迭代
 - 每个版本探索哪个方向（验证什么假设）
@@ -149,10 +149,10 @@
 
 ```
 docs/design/prototype/
-  player-controller.md                 # 设计案
-  player-controller-execution.md       # 执行案（含迭代版本表头）
-  interaction-system.md
-  interaction-system-execution.md
+  玩家控制器.md                 # 设计案
+  玩家控制器-执行案.md       # 执行案（含迭代版本表头）
+  交互系统.md
+  交互系统-执行案.md
   ...
 ```
 
@@ -195,7 +195,7 @@ docs/design/prototype/
 
 #### 阶段路线图
 
-批量生产阶段开始时，产出**阶段路线图**（`docs/plans/production-roadmap.md`）：
+批量生产阶段开始时，产出**阶段路线图**（`docs/plans/批量生产阶段-路线图.md`）：
 
 - 计划分几个版本迭代
 - 每个版本的主要内容范围
@@ -212,8 +212,8 @@ docs/design/prototype/
 
 ```
 docs/design/production/
-  player-controller.md                 # 在原型基础上更新
-  player-controller-execution.md       # 继续迭代，追加新的迭代记录
+  玩家控制器.md                 # 在原型基础上更新
+  玩家控制器-执行案.md       # 继续迭代，追加新的迭代记录
   ...
 ```
 
@@ -357,7 +357,7 @@ docs/design/production/
 6. **版本间的递进关系**：为什么先做这些后做那些
 7. **每个版本的验收标准**：怎样算"这个版本做完了"
 
-**产出位置**：`docs/plans/prototype-roadmap.md` 或 `docs/plans/production-roadmap.md`
+**产出位置**：`docs/plans/原型阶段-路线图.md` 或 `docs/plans/批量生产阶段-路线图.md`
 
 **版本编号规则**：
 - 原型阶段：`v0.1`、`v0.2`、`v0.3`……
@@ -432,16 +432,16 @@ docs/design/production/
 
 **产出形式**：
 - 每个系统一份执行案，放在 `docs/design/<阶段>/` 目录下
-- 文件命名：`<系统名>-execution.md`（如 `player-controller-execution.md`）
+- 文件命名：`<系统名>-执行案.md`（如 `玩家控制器-执行案.md`）
 - 不按版本分文件，通过迭代记录表头追踪变更
-- **关卡执行案**（如有场景搭建需求）：文件命名 `level-v<XX>-<name>-execution.md`，产出模板参见 `.claude/refs/level-execution-template.md`
+- **关卡执行案**（如有场景搭建需求）：文件命名 `关卡-v<XX>-<名称>-执行案.md`，产出模板参见 `.claude/refs/关卡执行案模板.md`
 
 **关卡执行案**：
 - 当版本开发涉及场景搭建时，策划额外产出一份关卡执行案
 - 关卡执行案将场景设计案的氛围描述转化为空间精度搭建指南（坐标、尺寸、BSP 资产映射）
 - 使用混合坐标体系：区域用场景绝对坐标，区域内物件用相对偏移坐标
 - 交互物和收集品的位置标注必须与交互系统/收集系统执行案交叉引用
-- 完整规范参见 `docs/design/prototype/level-design-workflow.md`
+- 完整规范参见 `docs/design/prototype/关卡设计工作流.md`
 
 ---
 
@@ -468,7 +468,7 @@ docs/design/production/
 - **不通过** → 退回策划修改，列出具体问题清单
 - **争议** → PM 与策划对判定有分歧时，由用户最终裁决
 
-**产出**：PM 审查记录（记录在 `docs/plans/reviews/<任务ID>-review.md`）
+**产出**：PM 审查记录（记录在 `docs/plans/reviews/<任务ID>-审查记录.md`）
 
 ---
 
@@ -495,7 +495,7 @@ docs/design/production/
 | 数据流 | 允许硬编码 | 数据应配置化 |
 | 美术需求 | 允许简化描述 | 必须具体到尺寸和数量 |
 
-**产出位置**：`docs/technical/<系统名>-tech.md`
+**产出位置**：`docs/technical/<系统名>-技术方案.md`
 
 ---
 
@@ -534,7 +534,7 @@ docs/design/production/
 
 **产出位置**：
 - 资产放 `Content/` 对应目录
-- 清单记录在 `docs/art/asset-manifest.md` 或直接在技术方案中更新
+- 清单记录在 `docs/art/资产清单.md` 或直接在技术方案中更新
 
 ---
 
@@ -564,13 +564,13 @@ docs/design/production/
 
 **白模搭建子任务（6a）**：
 当版本开发涉及场景搭建时，⑥的第一个子任务是白模关卡搭建：
-- 读取关卡执行案 `level-v<XX>-<name>-execution.md` 和场景设计案
+- 读取关卡执行案 `关卡-v<XX>-<名称>-执行案.md` 和场景设计案
 - 使用 `Content/BlockingStarterPack/` 资产在 UE5 编辑器中搭建白模关卡
 - 按区域分文件夹组织 Actor（命名规范：`LVL_<ZoneID>_<Category>_<Description>`）
 - 完成比例验证（角色可通过门洞、摄像机不穿墙、流线通行）
-- 产出搭建报告 `docs/technical/level-v<XX>-build-report.md` 记录偏差
+- 产出搭建报告 `docs/technical/关卡-v<XX>-搭建报告.md` 记录偏差
 - **搭建报告必须以评论形式发布到对应任务 Issue**（与本地文件内容一致）
-- 完整搭建流程参见 `docs/design/prototype/level-design-workflow.md` 第四章
+- 完整搭建流程参见 `docs/design/prototype/关卡设计工作流.md` 第四章
 
 **阶段差异**：
 
@@ -611,7 +611,7 @@ docs/design/production/
 - **不通过（重大）** → PM 提出处理建议（回退步骤或开新版本），由用户最终决定
 - **争议** → PM 与程序对判定有分歧时，由用户最终裁决
 
-**产出**：PM 审查记录（记录在 `docs/plans/reviews/<任务ID>-review.md`）
+**产出**：PM 审查记录（记录在 `docs/plans/reviews/<任务ID>-审查记录.md`）
 
 ---
 
@@ -656,14 +656,14 @@ PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本
 
 | 检查项 | 判断方式 | 结果 |
 |--------|----------|------|
-| 项目处于哪个开发阶段？ | 检查 `concept.md` → 检查核心玩法是否已有可玩原型 → 检查内容是否已完整 | 草案 / 原型 / 批量生产 / 测试发布 |
+| 项目处于哪个开发阶段？ | 检查 `概念草案.md` → 检查核心玩法是否已有可玩原型 → 检查内容是否已完整 | 草案 / 原型 / 批量生产 / 测试发布 |
 
 ### 版本流水线检查
 
 | 检查项 | 检查方式 | 通过条件 |
 |--------|----------|----------|
 | ① 设计案是否存在且完整？ | 检查 `docs/design/<阶段>/` 中的设计文档和索引 | 覆盖所有主要系统，有索引串联 |
-| ② 阶段路线图是否存在？ | 检查 `docs/plans/<阶段>-roadmap.md` | 版本列表、每版本目标、递进关系明确 |
+| ② 阶段路线图是否存在？ | 检查 `docs/plans/<阶段>-路线图.md` | 版本列表、每版本目标、递进关系明确 |
 | ③ 执行案是否齐全？ | 检查 `docs/design/<阶段>/` 对应执行案 | 每个涉及系统的核心行为规则都已明确 |
 | **PM 审查**：执行案质量门 | 对照质量标准逐项检查 | 完整性、清晰性、边界情况通过 |
 | ④ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个执行案都有对应技术方案 |

.claude/refs/level-execution-template.md

@@ -2,7 +2,7 @@
 
 > 本模板供策划产出关卡执行案时使用。关卡执行案是场景设计案的"空间精度版本"——将氛围描述转化为带有坐标、尺寸和资产建议的结构化搭建指南，供程序在 UE5 编辑器中搭建白模。
 >
-> 文件命名：`level-v<XX>-<name>-execution.md`（如 `level-v01-suburban-execution.md`）
+> 文件命名：`关卡-v<XX>-<名称>-执行案.md`（如 `关卡-v01-城郊街区-执行案.md`）
 > 存放位置：`docs/design/<阶段>/`（与其他执行案同目录）
 
 ---
@@ -49,7 +49,7 @@
 | ... | | | | | |
 | Zn | | | | | |
 
-> 标识色使用 BSP 材质名（参见 `blockout-asset-reference.md`），程序用对应材质标识区域。
+> 标识色使用 BSP 材质名（参见 `白模资产参考.md`），程序用对应材质标识区域。
 
 ### 2.2 交通流线
 
@@ -119,7 +119,7 @@
 - 填写 BSP 资产类别名和组合方式（如 "Wall_400x300 × 2 叠加"）
 - 程序负责映射到引擎中的具体资产路径
 - 如无精确匹配，写"Primitives 组合"并注明替代意图
-- 参见 `.claude/refs/blockout-asset-reference.md` 中的替代方案
+- 参见 `.claude/refs/白模资产参考.md` 中的替代方案
 
 #### 3.x.3 布景物清单
 
@@ -137,7 +137,7 @@
 
 | 交互编号 | 物件名称 | 交互类型 | 相对原点偏移 (ΔX,ΔY,ΔZ) | 触发半径 (cm) | 引用 |
 |---------|---------|---------|----------------------|-------------|------|
-| Zx-I01 | <!-- 如 旧冰箱 --> | <!-- 如 观察 --> | (200,400,10) | <!-- 如 150 --> | interaction-system-execution #n |
+| Zx-I01 | <!-- 如 旧冰箱 --> | <!-- 如 观察 --> | (200,400,10) | <!-- 如 150 --> | 交互系统-执行案 #n |
 | Zx-I02 | | | | | |
 | ... | | | | | |
 
@@ -150,7 +150,7 @@
 
 | 收集编号 | 物品名称 | 稀有度 | 相对原点偏移 (ΔX,ΔY,ΔZ) | 引用 |
 |---------|---------|--------|----------------------|------|
-| Zx-C01 | <!-- 如 彩色弹珠 --> | <!-- 如 普通/稀有 --> | (500,200,0) | collection-system-execution #n |
+| Zx-C01 | <!-- 如 彩色弹珠 --> | <!-- 如 普通/稀有 --> | (500,200,0) | 收集系统-执行案 #n |
 | Zx-C02 | | | | |
 | ... | | | | | |
 
@@ -187,7 +187,7 @@
 
 | # | 物品名称 | 所在区域 | 绝对坐标 (X,Y,Z) | 稀有度 | 引用 |
 |---|---------|---------|-----------------|--------|------|
-| 1 | | | | | collection-system-execution #n |
+| 1 | | | | | 收集系统-执行案 #n |
 | 2 | | | | | |
 | ... | | | | | |
 
@@ -240,6 +240,6 @@
 
 ### 与场景设计案的关系
 
-- 场景设计案（`scene-vXX-<name>.md`）= **氛围愿景** — 描述感觉、氛围、叙事意图
+- 场景设计案（`场景-v<XX>-<名称>.md`）= **氛围愿景** — 描述感觉、氛围、叙事意图
 - 关卡执行案 = **空间精度搭建指南** — 坐标、尺寸、资产映射
 - 两者是互补关系，不是替代关系。程序搭建时两个文档都需要参考。

.claude/skills/gitea-collab.md

@@ -75,7 +75,7 @@ description: "Gitea 协作工具 — CLI 命令速查、认证机制、Assignee
 | `gate:impl-pass` | 程序实现验收门通过 |
 | `gate:impl-fail` | 程序实现验收门未通过 |
 
-> **注**：旧 Issue 上可能仍有 `pipeline:*` 和 `role:*` 标签，这些已不再使用，保留不管即可。
+> **注**：`pipeline:*` 和 `role:*` 标签已废弃并从 Gitea 上删除。如旧 Issue 上仍残留这些标签，忽略即可。
 
 ---
 
@@ -178,7 +178,7 @@ node scripts/gitea.js test
 | 角色归属 | Assignee | 通过 `--assignees` 指派 |
 | 流水线步骤 | Pipeline Tracker | Meta Issue 记录全局流水线状态 |
 | 角色汇报 | Issue 评论 | 各角色在对应 Issue 下评论 |
-| 审查记录 | Issue 评论（摘要+链接）+ 本地 `docs/plans/reviews/` | 本地保留详细结构化文档 |
+| 审查记录 | Issue 评论（摘要+链接）+ 本地 `docs/plans/reviews/` | 本地文件名格式 `<任务ID>-审查记录.md` |
 | 任务归档 | close Issue | 不需要本地 archive 文件 |
 
 ---
@@ -266,7 +266,7 @@ node scripts/gitea.js --role pm issue comment <number> --body "## 质量门审
 
 **质量门**：[类型]
 **审查日期**：YYYY-MM-DD
-**审查记录**：docs/plans/reviews/<task-ID>-review.md
+**审查记录**：docs/plans/reviews/<task-ID>-审查记录.md
 
 ### 结论
 [一句话总结]
@@ -282,7 +282,7 @@ node scripts/gitea.js --role pm issue close <number> --body "## 任务完成 ✔
 
 **完成日期**：YYYY-MM-DD
 **产出**：path/to/output
-**审查记录**：docs/plans/reviews/<task-ID>-review.md"
+**审查记录**：docs/plans/reviews/<task-ID>-审查记录.md"
 ```
 
 ---
@@ -315,7 +315,7 @@ node scripts/gitea.js --role pm issue comments <number>
 # 创建 Issue（必须指定 assignees）
 node scripts/gitea.js --role pm issue create \
   --title "D-001 交互系统执行案" \
-  --body "## 任务信息\n- **任务ID**: D-001\n- **所属版本**: v0.1\n- **角色**: 策划\n- **预期产出**: docs/design/prototype/interaction-system-execution.md\n..." \
+  --body "## 任务信息\n- **任务ID**: D-001\n- **所属版本**: v0.1\n- **角色**: 策划\n- **预期产出**: docs/design/prototype/交互系统-执行案.md\n..." \
   --milestone <id> \
   --assignees ai-designer
 

.claude/skills/quality-gate-review.md

@@ -24,7 +24,7 @@ description: "质量门审查技能 — 4 道质量门标准、阶段对应标
 - 根据当前开发阶段选择对应标准（原型 vs 批量生产，见"阶段对应标准"）
 
 ### 3. 写审查记录（本地文件）
-- 路径：`docs/plans/reviews/<task-ID>-review.md`
+- 路径：`docs/plans/reviews/<task-ID>-审查记录.md`
 - 格式见下方"审查记录格式"
 
 ### 4. Issue 评论（强制）
@@ -117,7 +117,7 @@ description: "质量门审查技能 — 4 道质量门标准、阶段对应标
 
 ## 审查记录格式
 
-文件路径：`docs/plans/reviews/<task-ID>-review.md`
+文件路径：`docs/plans/reviews/<task-ID>-审查记录.md`
 
 ```markdown
 # [任务 ID] 审查报告
@@ -148,7 +148,7 @@ description: "质量门审查技能 — 4 道质量门标准、阶段对应标
 
 审查完成后，**必须**逐项确认以下操作：
 
-- [ ] 在 `docs/plans/reviews/<task-ID>-review.md` 写了审查记录
+- [ ] 在 `docs/plans/reviews/<task-ID>-审查记录.md` 写了审查记录
 - [ ] 在对应 Issue 上发布了审查结论评论（通过/不通过 + 摘要）
 - [ ] 更新了 Issue 的 gate:* 标签（通过→pass，不通过→fail）
 - [ ] **通过时**：关闭 Issue 并附完成说明

.claude/skills/requirements-analysis/SKILL.md

@@ -21,10 +21,10 @@ description: >
 
 按序阅读以下文档，获取完整的上下文信息：
 
-1. **执行文档** (`docs/design/<stage>/<system-name>-execution.md`) — 行为规则细节（主要输入）
-2. **系统设计文档** (`docs/design/<stage>/<system-name>.md`) — 全局上下文
+1. **执行文档** (`docs/design/<stage>/<系统名>-执行案.md`) — 行为规则细节（主要输入）
+2. **系统设计文档** (`docs/design/<stage>/<系统名>.md`) — 全局上下文
 3. **配置表** (`GameConfig/`) — 可调参数
-4. **概念文档** (`docs/design/concept.md`) — 方向参考（需要理解设计意图时查阅）
+4. **概念文档** (`docs/design/概念草案.md`) — 方向参考（需要理解设计意图时查阅）
 
 ---
 
@@ -134,7 +134,7 @@ description: >
 
 ## 输出
 
-最终产出为技术设计文档，保存到 `docs/technical/<system-name>-tech.md`。
+最终产出为技术设计文档，保存到 `docs/technical/<系统名>-技术方案.md`。
 
 文档必须遵循 `references/output-template.md` 中定义的标准模板结构。8 步分析的结果整合到模板的对应章节中，同时保留现有的必要章节（美术资源需求、数据流、可调参数汇总、文件结构）。
 

.claude/skills/requirements-analysis/references/diagram-guide.md

@@ -280,11 +280,11 @@ flowchart TD
 
 ### 3.3 项目实际案例参考
 
-**需要时序图的特性**（从现有 `interaction-system-tech.md` 提取）：
+**需要时序图的特性**（从现有 `交互系统-技术方案.md` 提取）：
 - 完整交互流程（Enter → AnimLock → Active → Exit）
 - 拾取流程（交互系统 → 物品系统 → 收集系统）
 
-**不需要时序图的特性**（从现有 `player-controller-tech.md` 提取）：
+**不需要时序图的特性**（从现有 `玩家控制器-技术方案.md` 提取）：
 - SpringArm 参数配置（纯构造函数设置）
 - CMC 移动参数调整（纯配置）
 

.claude/skills/requirements-analysis/references/examples.md

@@ -8,9 +8,9 @@
 
 | 示例 | 来源文档 |
 |------|---------|
-| 交互系统 | `docs/technical/interaction-system-tech.md` |
-| 角色控制 | `docs/technical/player-controller-tech.md` |
-| 收集系统 | `docs/technical/collection-system-tech.md` |
+| 交互系统 | `docs/technical/交互系统-技术方案.md` |
+| 角色控制 | `docs/technical/玩家控制器-技术方案.md` |
+| 收集系统 | `docs/technical/收集系统-技术方案.md` |
 
 ---
 

.claude/skills/requirements-analysis/references/output-template.md

@@ -10,7 +10,7 @@
 # <系统名称> 技术设计文档（<版本号> <阶段>）
 
 > 任务ID: <任务编号>
-> 对应执行案: `<执行案文件路径>`
+> 对应执行案: `docs/design/<stage>/<系统名>-执行案.md`
 > 关联系统: <上游/下游/平行系统列表>
 > 阶段: 原型 / 批量生产 / 测试
 > 日期: <YYYY-MM-DD>