我用 AI 从零开发了一款 WebGL 幻想地图生成器
内容提要
该项目开发了一个WebGL幻想地图生成器，能生成并编辑包含地形、国家、城市等复杂关联的完整世界。它从性能测试起步，重写为独立应用，支持编辑、存档和AI修改。开发中强调任务清单管理、真实浏览器验证和旧数据兼容。作者认为，AI写代码虽快，但人的关键作用在于定义目标、审查结果和做产品决策。
延伸解读
性能优化需区分瓶颈
作者最初认为将SVG换成WebGL就能解决卡顿，但通过性能分析发现，大量DOM节点（如标签、图标）才是主要瓶颈。即使将几何迁移到GPU，若标签等仍留在DOM中，性能问题不会自动消失。这提醒开发者，性能优化前应先测量，找出真正的瓶颈，而非凭直觉重写。
AI开发需严格任务管理
项目通过维护唯一权威任务清单、明确验收条件、禁止范围蔓延，有效防止了AI过度实现。复杂任务分阶段进行，并在真实浏览器中验收，而非仅依赖测试脚本。这种管理方式确保了长期项目的可控性，也体现了人在定义目标和审查结果中的关键作用。
旧数据兼容是长期挑战
项目强调旧存档兼容的重要性，因为用户珍视已编辑的地图。曾遇到运行时缓存类型变化导致功能失败的问题，修复需覆盖多种导入路径并保证事务回滚。这提示开发者，在迭代中必须考虑数据迁移和回填，否则新功能可能破坏旧数据，影响用户体验。
AI修改需分层安全架构
允许AI直接修改内部数据易产生不一致，项目采用分层模型：空间层判断目标、领域层检查规则、执行器创建事务、AI规划器组合授权动作。预检凭证绑定版本和指纹，异常时完整回滚。这种设计虽慢，但保障了自动化修改的长期可靠性，值得借鉴。
Q&A
这个 WebGL 幻想地图生成器项目是如何开始的？
项目始于 2026 年 5 月，最初是为了解决 Fantasy Map Generator 的 SVG 地图在复杂场景下性能不佳的问题。作者没有立即重写，而是先建立了一套性能分析工具，测量原项目在 10k、50k、100k 地图下的性能瓶颈，确认问题后，才决定用 WebGL2 重写。
这个地图生成器能生成哪些内容？
它能生成完整的世界，包括地形（高度、气候、河流、生物群系、自然资源）、文化、宗教、国家、省份、城市、道路、经济、贸易、外交、军事和事件地区等。生成后还可以编辑这些对象，并支持撤销重做、预检和保护锁定对象。
项目是如何管理 AI 开发过程的？
项目采用严格的任务清单管理，只有进入清单的需求才能实施，每个任务有明确的范围和验收条件，达到即停止。复杂任务分阶段进行：调查、实现、审查、真实验收。文档作为项目记忆，新会话通过固定入口逐步读取。
项目在处理海岸线平滑时遇到了什么问题？
海岸线平滑容易破坏拓扑结构，导致针状尖刺、缝隙、错侧填充，甚至河口与海岸分离。项目建立了边界拓扑实验室，用固定夹具复现失败形态，并采用复用共享边界、检查线面同侧关系、局部不安全时回退等方案，同时保护沿岸城市、道路等对象不被移动。
项目如何保证 AI 修改地图的安全性？
项目采用分层模型：空间层判断目标 cell，领域 inspector 判断业务规则，执行器创建可撤销事务，AI planner 只组合授权动作。高影响操作先只读预检，预检结果绑定地图版本和输入指纹，地图变化后凭证失效。执行异常则完整回滚。
项目在性能优化方面有哪些发现和措施？
性能调查发现主要瓶颈是 DOM/SVG overlay 中的标签，而非 WebGL 绘制。优化措施包括：连续交互期间只更新相机和根变换，空闲后再完整提交；增加几何缓存与颜色复用。优化后 loadMap 中位耗时下降约 28.4%，点击生成到地图出现下降约 27.5%。
项目如何处理旧存档兼容问题？
项目将旧数据适配作为默认要求，新增字段或修改结构时必须考虑迁移、回填和旧样本验证。例如，某个运行时缓存从 JavaScript Map 变成普通对象后，恢复时调用 .get() 失败，修复时覆盖了浏览器缓存、完整 JSON 导入、旧导出文件和云端存档，并确保复杂操作失败时完整回滚。
项目在云盘和桌面打包方面有什么尝试和结论？
项目尝试了 Dropbox、Google Drive 和 Pake 桌面打包。云盘授权只在 sessionStorage 保存短期令牌，不使用 refresh token。Pake 生成的桌面版在 WebView2 中授权失败，因此放弃，改用 Chrome 的“安装为应用”功能，因为它保留浏览器环境和用户会话。
