核心目标

让 NL2CGA 从"LLM 从零生成代码"升级为"模板选择 + 参数填充"模式，实现 Library 92 个模板的价值落地。

任务清单

• W1D1-3 Library 文件索引器：Python 扫描 library/ 目录，建立 92 个模板的元数据索引（路径 / 参数 / 描述 / 编译状态）
• W1D4-5 LLM 模板选择 Prompt：修改 System Prompt，让 LLM 从 92 个模板中选择最匹配的风格（提供模板名称列表 + 关键词映射）
• W2D1-3 LLM 参数填充 Prompt：将用户描述的特征（如"尖顶"/"圆顶"/"玻璃幕墙"）映射到模板的 attr 参数值
• W2D4-5 集成测试：10 种不同风格的生成测试，编译通过率目标 >90%

交付物

• nl2cga_service.py 集成模板选择 + 参数填充逻辑
• 模板元数据索引文件 library/index.json
• 更新后的 LLM System Prompt 文档

验收标准

• 用户输入"中式传统民居" → 系统选择 chinese_traditional.cga → 填入 floorCount=默认 → 编译通过
• 用户输入"哥特式教堂，三层尖顶" → 系统选择 christian.cga → 填入 spireHeight=30, floorCount=3 → 编译通过
• 10 组测试用例，编译通过率 ≥ 90%

风险与依赖

• ⚠️ LLM 对 92 个模板的选择准确率可能不高 → 需要多轮 few-shot + 关键词强化
• ⚠️ 参数填充可能超出模板 attr 范围 → 需要边界检查 + 默认值回退
• ✅ 依赖 Phase 1（已完成）：92 个模板骨架 + import 内联器

核心目标

建立全球建筑 CGA 代码资产库的完整骨架，为后续模板填充和 NL2CGA 调用提供基础设施。

已完成工作

• ✅ base/ 6 个通用组件（roof/facade/structure/material/decoration/utils）
• ✅ config/ 3 个全局配置（global_params/lod_settings/style_mapping，60+ 常量）
• ✅ 8 大分类 82 个 .cga 骨架文件 + 3 个示例场景
• ✅ main.cga 总调度入口（248 行，自动路由 8 大分类）
• ✅ Python import 内联器（绕过引擎 import 限制）
• ✅ 92/92 文件编译验证通过

交付物

• /www/wwwroot/nl2cga-service/library/ 完整目录结构
• main.cga 统一调度入口
• cga_import_resolver.py import 内联器
• Library README.md 架构文档

核心目标

将 92 个骨架模板升级为有实际差异化内容的可运行代码，每个风格能渲染出独特的建筑外观。

任务清单

• W1-2 residential/modern_contemporary/ 深度填充（10 个风格）
  • 板楼/塔楼： Flat 屋顶 + 玻璃幕墙 + 阳台模块
  • 别墅： 差异化屋顶/庭院/车库/露台
  • 保障房： 简化立面 + 统一配色
• W3 religious_monumental/christian.cga + public/education.cga
  • Christian: 尖拱窗/飞扶壁/玫瑰窗/高耸比例/彩色玻璃
  • Education: 对称布局/大入口/走廊/教室窗
• W4 base/roof.cga + base/facade.cga LOD 实现
  • L0: 纯色方块（~100 面）
  • L1: 基本形状 + 贴图（~1000 面）
  • L2: 完整细节 + 装饰（~10000 面）
• W5-6 其余 70+ 模板基础填充
  • 每个风格至少 3 个差异化参数（屋顶角度/墙色/窗型）
  • 添加标志性元素（伊斯兰圆顶/佛教 tiers/工业大跨度）

交付物

• 92 个模板全部有实际可运行的差异化代码
• LOD 系统完整实现（L0/L1/L2）
• 每种分类的渲染效果对比截图

验收标准

• 8 大分类各选 1 个代表风格，渲染结果 visually distinguishable（肉眼可区分）
• L0/L1/L2 面数比例约 1:10:100
• 编译通过率 100%（92/92）

风险与依赖

• ⚠️ 工作量巨大（70+ 文件）→ 采用"先质量后数量"策略，优先填充高频风格
• ⚠️ 风格参数需要建筑知识 → htraeye 提供关键参数参考值
• ✅ 依赖 Phase 1（已完成）

核心目标

在 cgajs-engine 的 evaluator 中实现原生 import 支持，让 main.cga 无需 Python 内联即可直接编译运行。

任务清单

• W1 Import 路径解析器（Node.js fs / 浏览器 fetch 双适配）
• W1-2 findRule() 扩展：支持跨 imported scripts 规则查找
• W2 命名空间隔离：import alias → alias.ruleName 调用映射
• W2-3 循环导入检测 + 错误报告优化
• W3 374 测试回归 + main.cga 全分类编译测试

交付物

• src/parser/import-resolver.ts 引擎层 import 解析模块
• 修改后的 src/api/engine.ts（compile 方法集成 import 解析）
• 更新后的 CLI wrapper（支持 basePath 参数）
• 374+ 测试全部通过报告

验收标准

• main.cga 直接编译通过（不经过 Python 内联）
• 所有 92 个模板文件通过编译
• 现有 374 测试零失败
• 编译性能下降 < 10%

风险与依赖

• 🔴 高风险：evaluator.ts 是引擎心脏，任何改动都可能影响所有编译请求
• 🔴 必须在 beta 分支完成，全量测试通过后才能部署 prod
• ⚠️ 浏览器环境文件读取需 fetch → 需要服务器提供 .cga 文件访问端点
• ✅ 依赖 Phase 1（已完成），可独立进行

核心目标

建立全球建筑风格的知识库，让 LLM 生成的代码更准确、更有建筑学依据。

任务清单

• W1-2 全球建筑风格知识库
  • 60+ 风格的关键参数（屋顶角度/柱网比例/窗墙比/典型高度）
  • 每个风格的视觉特征描述（如"哥特式 = 尖拱 + 飞扶壁 + 玫瑰窗 + 高耸"）
  • 参数范围与默认值（如中式庑殿顶 roofAngle = 25~35）
• W3 地域上下文
  • 气候影响（热带大檐/寒带厚墙/干旱区土坯）
  • 文化符号（伊斯兰几何纹/中式斗拱/欧洲柱式）
  • 材料偏好（北欧木材/地中海石材/东亚木构）
• W3-4 Prompt 模板体系 + 代码精修器
  • 按建筑类型分类的 System Prompt（住宅/宗教/工业各一套）
  • 代码精修器：去冗余 / 补全 import / 修正语法 / 统一缩进

交付物

• building-style-knowledge.json 风格知识库
• regional-context.json 地域上下文
• 分类 Prompt 模板（6 套）
• code-refiner.py 代码精修器

验收标准

• 相同提示词"生成哥特式教堂"，LLM 生成的代码包含尖拱/飞扶壁参数的比例 ≥ 80%
• 编译通过率 ≥ 95%（vs 当前约 60%）
• 50 组盲测：专家能正确识别生成建筑的风格的准确率 ≥ 70%

风险与依赖

• ⚠️ 建筑知识准确性 → 需要 htraeye 审核关键参数
• ⚠️ LLM 知识注入后 token 消耗增加 → 需要测试成本
• ✅ 依赖 Phase 0（模板选择 Prompt）+ Phase 2（模板有实质内容）

核心目标

开放 CGA Library API，让第三方可以直接调用生成建筑，构建 SDK 生态。

任务清单

• W1-2 CGA Library API
  • GET /v1/library/styles — 列出所有 92 个风格
  • GET /v1/library/styles/{id} — 获取风格详情 + 参数列表
  • POST /v1/library/search — 按关键词搜索风格
  • GET /v1/library/components — 列出 base/ 组件
• W3 参数化组装 API
  • POST /v1/assemble — 传入 buildingType + style + 参数 → 返回完整 CGA 代码
  • 支持 import 展开 / 单文件输出 / LOD 选择
• W4 Python / JS SDK
  • pip install cgajs-sdk Python SDK
  • npm install @cgajs/sdk JS SDK
  • 示例：3 行代码生成建筑 GLB 模型

交付物

• Library API 文档（Swagger/OpenAPI）
• cgajs-sdk Python 包
• @cgajs/sdk npm 包
• SDK 示例项目（GitHub repo）

验收标准

• 第三方通过 API 调用，3 步内生成并下载 GLB 模型
• Python SDK 在 PyPI 发布，JS SDK 在 npm 发布
• API 响应时间 < 2s（含 import 展开 + 编译）

风险与依赖

• ⚠️ SDK 维护成本 → 先发布 MVP，社区反馈驱动迭代
• ⚠️ API 认证与限流 → 复用现有 API Key 体系
• ✅ 依赖 Phase 0（调用链）+ Phase 3（引擎 import）或 Python 内联方案