一个有源码、有 API、却仍经历"失败 → 重写 → 数据损毁"的前端复刻案例。
这是一篇写给 AI 工程师的文章:一半讲技术，一半讲 GLM5.1 的能力边界
一、引子: 截图三件套的失效时刻
前端复刻有三件套——截图对比、outerHTML 扒结构、F12 抄 CSS。在小红书详情页、SaaS 落地页这种"静态视觉为主"的页面上，这套打法过去几年被验证过无数次。社区里甚至有 abi/screenshot-to-code(73k stars)这种里程碑项目，专门把截图喂给 GPT-4 Vision，直接生成 React/Vue 代码
但当我在 2026 年 4 月决定复刻原神大世界交互式地图(v3.yuanshen.site)时，这三件套失效了
失效的原因不是AI生成的页面丑，而是这个页面根本不是"一张图":
原网页
-
10 万+ 动态标记点:每个标记都有自己的图标、状态、点击弹窗、所属物品分类
-
自定义坐标系:不是 WebMercator 经纬度，而是游戏像素坐标 + Leaflet CRS.Simple 投影
-
Vue2 + Quasar + Leaflet 深度耦合:560 行单文件 IndexPage.vue、14 个 API 文件、魔改过的 markercluster 插件
-
服务端按需查询:每次操作都向后端发 5-8 个 API 请求，过滤逻辑在 Java 后端
更麻烦的是，这是一次"有源码、有 API、却仍然一波三折"的复刻——空荧酒馆团队开源了完整的前端代码(kongying-tavern/map_front_v3)，后端有公开 OAuth2 接口，理论上 AI 只要做"翻译+集成"就够了
这篇文章要讲的，就是这次复刻的全过程:从 GLM-5.1 在架构选型上的误判，到三次 Phase 2 重写，再到 Python 数据管道里 5 个 CRITICAL 数据损毁被发现。它不是 GLM-5.1 复刻过的唯一项目，却是暴露问题最多的一个。这些问题在三个月后，以 Terminal Bench 2.1 从 58.7 跃升到 81.0 的形式，在 GLM-5.2 身上得到了系统性回应
二、项目背景: 三方关系与数据规模
在讲技术细节之前，必须先理清这个项目背后的三方关系——这决定了后续所有架构决策的边界
2.1 三个主角
| 空荧酒馆 (kongying-tavern) | 原神地图社区团队 | 原创地图数据维护，运营 yuanshen.site，开源了 v3 前端(MulanPSL-2.0) |
| v3.yuanshen.site | 空荧酒馆官方 Web 地图 | 这是我们复刻的目标，Vue2 + Quasar + Leaflet |
| qiuxiang/ky-genshin-map | 第三方独立开发者 | 完全独立重写(Preact + 自研 canvaskit-map)，MIT 协议，数据停在 5.0.1 |
关键结论:ky-genshin-map 与 v3.yuanshen.site 零代码共享。我们 UI/交互参考 map_front_v3，数据走空荧酒馆 API
2.2 真实的工程规模
很多人对"复刻一个网页"没概念，以为就是抄抄 HTML。看几个数字:
| 标记点 | 105，231 个 | 全提瓦特大陆每个宝箱、神瞳、特产的位置 |
| 物品分类 | 3，926 个 | 跨越 14 个类型(神瞳/宝箱/食材/矿物…) |
| 区域树 | 37 个 | 蒙德/璃月/稻妻/须弥/枫丹/纳塔 + 子区域 |
| 图标 | 1，087 个 PNG | 含中文文件名、哈希名、数字名三种命名 |
| 瓦片 | 12，750 张 | z10-z13 四级缩放，带负坐标，~300MB |
| data.json | 39 MB | 全量点位单体文件 |
项目文件分布
/root/code/ssbh/capturegenshin/
├── GitHub（仅代码）
│ ├── src/ 、 package.json 、 vite.config.ts …
│ └── GenshenMap-python/
│ └── map_sync.py ← 同步脚本
│
├── COS img.capturegenshin.com.cn（所有爬取资源，前端运行时直连）
│ ├── map/
│ │ ├── data.json ← 40MB 全量点位
│ │ ├── version.json ← 版本号（前端 IndexedDB 缓存对比用）
│ │ ├── regions.json ← 瓦片几何配置
│ │ ├── icons/ ← 图标 PNG
│ │ ├── pictures/ ← 点位截图
│ │ └── tiles/twt642/ ← 12750 张瓦片
│ └── gi/（nanoka 数据，结构类似）
│
├── 夸克（所有文档）
│ ├── AGENTS.md
│ ├── 原神大地图复刻规划方案.md
│ ├── 原神大地图复刻开发记录.md
│ └── HANDOFF-原神大地图.md
│
└── 只在本地（敏感信息，无线上备份）
├── application-local.yml ← 个人密钥
├── .env ← API key
└── deploy-docker/ ← 部署配置含密码
这不是"做个组件"的工作量，是"搭一个数据管道 + 渲染引擎 + UI 系统"的小型工程。而 AI 要在这其中做对架构决策(选 deck.gl 还是 Leaflet)、翻译(Vue2 → Vue3)、数据建模(Python 转换脚本)三层工作，任何一层失误都会连锁影响下游
三、第一次尝试: deck.gl 的"看起来很美"
2026 年 4 月，我用 GLM-5.1 启动了第一次复刻。当时的技术选型现在回看很典型——AI 倾向于选择"看起来更现代"的方案:
| 地图引擎 | deck.gl | "WebGL 渲染，10 万+ 标记点无压力，空荧酒馆自己的 v4/v5 也用 deck.gl" |
| 坐标系统 | OrthographicView | "正交投影，像素坐标直接映射，比 Leaflet hack CRS 更自然" |
| 数据策略 | Python 一次性同步 → COS 静态 JSON | "前端直连 COS，零后端依赖" |
| UI 参考 | map_front_v3 | "源码可读，翻译 Vue2 → Vue3" |
这套方案看起来无懈可击。Phase 0(数据基础设施)、Phase 1(地图渲染 MVP)确实也很顺利——deck.gl 的 OrthographicView + TileLayer + ScatterplotLayer 在当天就跑起来了，瓦片能加载，标记点能点击，弹窗能显示
但顺利只持续到 Phase 1.5。从这一刻开始，12 个意外踩坑接连出现，每一个都不是 GLM-5.1 在选型时能预见到的:
| 1 | 空荧酒馆 API 实际上是两个服务(公共+管理后台)，area 接口要走不同域名 | 没意识到同一个团队会有两套 API |
| 2 | item/get/list 批量传 areaId 会 500，必须逐个叶子区域拉(28 个请求) | 后端 IN 查询限制 |
| 3 | 瓦片 ID 不是文档里的 twt40 而是 twt642 | 静默废弃的旧 ID |
| 4 | 瓦片源不是 tiles.yuanshen.site(那是个 AList 文件浏览器)而是 assets.yuanshen.site | 域名语义误导 |
| 5 | 瓦片坐标有负值，旧脚本只覆盖正坐标 | 非标准坐标系 |
| 6 | deck.gl v9 的 getTileData 参数结构变化(坐标在 tile.index 里) | 版本迁移陷阱 |
| 7 | 瓦片范围远不足:原 4080 张 → 实际 12750 张 | 文档与实际严重不符 |
| 8 | 批量下载脚本被 shell 600s 超时杀掉，需 nohup 后台跑 | 工程实战细节 |
| 9 | 标记点偏移 683 像素(API 坐标不是瓦片像素坐标，需要 MARKER_OFFSET) | 投影变换隐藏在源码里 |
| 10 | 40MB data.json 写 localStorage 静默失败(5MB 配额) | 浏览器配额陷阱 |
| 11 | COS 图标 double-encode 问题(中文文件名 404) | COS 路径自动 decode 行为 |
| 12 | referrerpolicy="no-referrer" 导致图标 403 | 翻译时照抄源码的副作用 |
这 12 个坑合计耗费约 8 小时纯踩坑时间，超过了实际编码时间。其中最有戏剧性的是 #9 MARKER_OFFSET:
用户反馈"黄点点和地图没有正确对应上"。我让 GLM-5.1 找原因，它去翻了空荧酒馆的 Gitee 源码，找到 center: [3568， 6286] 这个 fallback 值，套上去——用户反馈"比以前好一点还是差一些"。
用户后来的一句话点醒了我:"你直接打开浏览器，我交互，你找网络请求不就行了"。
用 Playwright 打开 v3.yuanshen.site 监听所有 JSON 响应，一分钟后就发现真实配置文件不叫 web-map.json 而是 webapp.json，里面的 center 是 [3568， 6969]——Y 值差了 683。这 683 像素的偏差，是 GLM-5.1 读 fallback 默认值就读 fallback 默认值、没想到去抓真实运行时配置的典型表现。
这些坑每一个都不复杂，但累加起来暴露了一个核心问题:GLM-5.1 在选 deck.gl 时，没有意识到自己选了一个"渲染强但生态弱"的引擎。这个误判的代价，在 Phase 2 才彻底爆发
四、Phase 2 三次重写: AI 翻译源码为何这么难
Phase 2 的目标是把 map_front_v3 的 4 个核心 UI 组件(AreaSelector/ItemSelector/PopupWindow/SwitchList)翻译成 Vue3。听起来简单——源码摆在那，照着翻译就行
第一次失败: AI 自己发明了简化版
我让 GLM-5.1 实现这 4 个组件。它很快交差，vue-tsc 类型检查通过，vite build 成功。但打开页面一看——4 个 runtime bug:非响应式 let 变量、O(n²) 复杂度的 filter、controlled viewState 冻结、CSS 缺失。全部 git restore 回退
第二次失败: 类型过了，样式错了
第二次我强调了"严格翻译，不要自由发挥"。GLM-5.1 又交了一版，这次类型检查、构建、LSP diagnostics 全绿。但用户打开页面后只说了一句话:
"我不是给你源码了吗，源码就长你写的这样?"
这句话后来成了我对 AI 协作的核心反思——AI 认为"代码能跑"= 复刻成功，但用户认为"看起来一样"才算复刻成功。GLM-5.1 写出来的组件，逻辑上没错，但视觉上和原网站差距巨大:布局比例不对、动画缺失、交互细节走样
第三次:逐组件忠实翻译，勉强渲染
第三次我换了策略——每个组件单独派给一个 subagent，明确给出源码路径和"逐行翻译，不要简化"的约束。4 个 subagent 全部完成，组件终于渲染出来了。但紧接着，7 个 Bug 又冒出来:
| 1 | ItemSelector 宽 6416px(应 ~400px) | rem 缩放不生效，需动态设 html font-size |
| 2 | 10 万个点位一次性渲染卡顿 | selectedItemIds.size === 0 时返回全部 markers |
| 3 | 物品列表全量显示 3926 个 | itemsByTypeId 没按地区过滤 |
| 4 | 选璃月后列表为空 | 只检查 selectedChildAreaId，顶级地区时为 null |
| 5 | COS 中文图标 404 | double-encode 缺失 |
| 6 | 即使图标存在也 403 | 翻译时照抄了源码的 referrerpolicy="no-referrer" |
| 7 | 地区面板死循环不显示 | areaFirstChild computed 依赖未初始化的 areaSelectedTop |
更糟糕的是，渲染成功后做了一次系统对比，发现 20 个剩余问题——其中 8 个是架构级的，12 个是纯 UI 实现。这意味着 GLM-5.1 即使把每个组件都翻译对了，也只能解决 12/20 个问题
4.4 AI 翻译源码的真实难点
为什么"有源码 + 有 API"还会这么难?复盘下来，核心是 AI 在三个层面的薄弱:
代码风格 ≠ 视觉还原:GLM-5.1 翻译时关注"逻辑等价"，但 rem 单位、CSS 缩放、Quasar 组件特性这些非显性约定容易被忽略
缺乏"参考实现":面对开源代码，AI 倾向"看懂了就自己重写"，而不是"逐字符对照"。这种倾向在简单项目里是优势(代码更现代)，在复杂项目里是灾难(丢失关键细节)
跨文件上下文断裂:map_front_v3 的状态散落在 Pinia store + 模块级 ref + 组件 data 三处，翻译时如果只看单文件，会丢失响应式联动
这三点后来在业界研究里也被反复印证——zychenpeng/clone-engine-research 的实测显示，4 个 SOTA 工具在 27 个含动画/动态行为的页面上，捕获率为 0。AI 对运行时行为的盲区是系统性的
五、失败根因: 8 个架构级问题的本质
Phase 2 三次重写后，我做了一次彻底的对比审计，发现剩下的 20 个问题里，有 8 个是架构级问题，无法靠"继续编码"解决。这是整个项目最关键的洞察
5.1 引擎能力差异(5 个 A 类问题)
deck.gl 是个渲染引擎，Leaflet 是个地图应用生态。这两者的差距在 map_front_v3 这种重度依赖 Leaflet 生态的项目里被无限放大:
| 标记点点击弹窗 | layer.bindPopup(dom， offset) 自动定位 | 手动管理 DOM 弹窗 + 监听视图变化 |
| 标记点聚合 | L.markerClusterGroup 一行配置 | 无原生聚合，需自行实现 |
| 图层独立管理 | mapLayerMap，每物品独立 layergroup | 一个 ScatterplotLayer 管全部 |
| 标记完成状态 | layer.setIcon(divIcon) 直接交换 DOM | 维护两份标记集合并切换 |
| CSS 控制显隐 | 修改 DOM class 即可 | 走数据层过滤或图层参数 |
这 5 个差异直接转化为 5 个架构级 bug:弹窗无法跟随标记、聚合要重写、图层管理要重写、标记状态视觉反馈要重写、地下点位显隐要重写
5.2 数据架构差异(3 个 B 类问题)
| 数据量 | 每次请求几十~几百个标记 | 40MB 全量 JSON 一次加载 |
| 按地区过滤 | API 参数实现 | 前端遍历 105231 条做 filter |
| 标记完成计数 | API 返回 count 字段 | data.json 没有 count 字段 |
5.3 关键洞察: AI 擅长"代码生成"，不擅长"技术选型"
把这 8 个问题归到一起，根因只有一条:GLM-5.1 在选 deck.gl 时，看的是"渲染性能"这一个维度，没看"生态完整度"这个更重要的维度。
这不是 GLM-5.1 独有的问题。abi/screenshot-to-code、v0.dev、Cursor Composer 在公开评测里都展现了类似的倾向——优先选"看起来更现代/性能更强"的方案，忽略生态依赖。在简单项目里这种倾向是优势(代码更现代化)，但在重度依赖特定库生态的项目里就是灾难
用户当时的一句话精准概括了问题本质:
"虽然我把后端 API 的数据都转换成了 JSON 放到 COS，但是没有转换全部后端，所以只有地图和全部点位显示了，但是其他功能都没有。"
这句话点醒了我:后端不只是 CRUD，还有业务逻辑层(计数、分类、过滤权限、传送点系统)。前端全量 JSON 只能复刻"最外层的数据展示"，复刻不了服务端的逻辑层
继续在 deck.gl 上修复 Phase 2，最多只能解决 12/20 个问题。是时候推翻重来了
六、架构重写
第三次尝试的策略是整体迁入 map_front_v3 的 Leaflet 代码，直连空荧酒馆 API 先跑通，跑通后再把数据迁移到自建 COS。这次决策的依据很朴素:第一次失败是因为换引擎导致 8 个架构问题，这次保留引擎，这些问题全部消失
6.1 Leaflet 跑通的瞬间:一行 CSS 的故事
新方案第一步是把 Leaflet 集成进 Vue3 项目。GLM-5.1 翻译了 map.js/map_obj.js/config.js/layer.js，TypeScript 化，CRS.Simple 投影配置好，API 直连代理配好——一切看起来都对了
打开页面，看到的是一个诡异的大椭圆形暗角圆环:白色背景，边缘是 radial-gradient 过渡，没有任何瓦片、标记或 UI 元素可见。后端 API 全部正常返回 200，Leaflet 实例成功创建，DOM 里 .leaflet-map-pane 也存在，但就是没有任何瓦片渲染在视口里
用户原话:"我的页面一整个大的椭圆形大圆导致是什么东西"
排查花了 15 分钟，试了 CRS 投影配置、mapPane transform、settings.center 覆盖、merge 顺序……全部没用。最后用 Playwright 检查 DOM，发现所有 .leaflet-pane 元素的 position 都是 static——而 Leaflet 默认应该是 absolute
根因找到了:MapPage.vue 缺少一行 import 'leaflet/dist/leaflet.css'
Leaflet 的 CSS 里定义了 .leaflet-pane { position: absolute; } 和 .leaflet-map-pane { transform-origin: 0 0; }。没有这个 CSS，所有 pane 保持默认的 position: static，translate3d transform 无法正确偏移内容，瓦片全部渲染在视口外。而 map_front_v3 的 map.js 里这行 import 是有的——GLM-5.1 翻译时把它当作"side-effect import"忽略了，因为 TS 编译器对这种不导出值的 import 不报错也不警告
加上这一行，150/150 瓦片瞬间全部可见
这个 Bug 后来成了我心中"AI 翻译开源项目"的标志性案例:一个 30 个字符的 import，让 GLM-5.1 卡了 15 分钟。AI 能读懂代码逻辑，但读不懂"这行看似无用的 import 其实是必需的副作用"
6.2 Vue2 → Vue3 的真实翻译工作量
Leaflet 跑通后，UI 组件迁入反而比想象中顺利。核心思路是忠实翻译，不发明:
| Vue2 Options API + JS | Vue3 Composition API + TypeScript |
| Quasar 全家桶(q-scroll-area/q-img/q-slide-transition) | 原生 HTML + Vue 内置组件 |
| Pinia store(14 行，8 个字段) | 等价的 Pinia store，字段一一对应 |
| 模块级 ref() 散落各处 | 统一到 src/map/*.ts 模块 |
| Leaflet 1.7.1 | Leaflet 1.7.1(版本完全一致) |
值得说一下的是那个 14 行的 Pinia store。它名义上是状态管理，实际上是个跨组件事件总线——8 个字段(area_list/selected_area/selected_child_area/changeitem/selected_item_list/teleport_list/change_mark/layer_count)都是组件间通信用的。这种"伪 store"在 Vue2 时代很常见，翻译到 Vue3 时不要试图改造它，保持等价反而最稳
6.3 这次重写暴露的 AI 真实能力
回看第三次重写，GLM-5.1 的表现可以分两档:
| 单文件组件翻译(Vue2 → Vue3 语法层面) | ⭐⭐⭐⭐ 良好 |
| Bug 定位与修复(给出现象和上下文) | ⭐⭐⭐⭐ 良好 |
| TypeScript 类型补全 | ⭐⭐⭐⭐⭐ 优秀 |
| 跨文件响应式联动分析 | ⭐⭐ 一般 |
| 工程级 side-effect 识别(leaflet.css 这种) | ⭐ 薄弱 |
| 技术选型时的生态评估 | ⭐ 薄弱 |
也就是说，GLM-5.1 在"明确边界的编码任务"上表现优秀，但在"需要全局工程视角的判断"上薄弱。这与三个月后 GLM-5.2 在 Terminal Bench 2.1 上提升 +22.3 分的方向完全吻合——那个评测衡量的正是 Agent 在长程任务中的工具调用稳定性和工程判断
七、Python 数据管道:5 个 CRITICAL bug 的警示
如果说出局架构重写是 GLM-5.1 的"高光时刻"，那 Python 数据管道就是它的"至暗时刻"
7.1 背景:为什么需要 Python 数据管道
新方案最终要把空荧酒馆的 API 数据全部爬下来，转成静态 JSON 上传到自己的腾讯云 COS，前端直连 COS 零后端依赖。这意味着 Python 脚本要承担原 Java 后端的全部数据转换工作
数据流向:空荧酒馆公共 API → Python 脚本拉取 → 本地处理 → 上传 COS → 前端直连
这套管道由两个脚本组成:map_sync.py(398 行，从 API 拉取并初步转换)和 split_data.py(208 行，把单体 data.json 拆分成前端可直连的多个 JSON 文件)
7.2 5 个 CRITICAL 数据损毁的发现
项目跑起来后，用户陆续反馈:"地图点位当时也不对"、"为什么爬下来的数据和公共 API 完全不同"、"进度条永远是 0%"
我让 GLM-5.1 做了一次彻底的代码审计，发现了5 个 CRITICAL 数据损毁，全部在 Python 脚本里。这 5 个 bug 不是简单的语法错误，而是 AI 在写转换函数时做了过度的简化，丢掉了前端依赖的关键字段
| 1 | map_sync.py 第 261 行 transform_markers | item_ids = [it["itemId"] for it in item_list if "itemId" in it] | 只取 itemId，丢掉了 count 字段 → 前端进度条永远 0%，标记计数永远 0/N |
| 2 | split_data.py 第 86 行 build_icons | if name.lstrip("-").isdigit(): icon_ids.add(int(name)) | 只接受纯数字文件名，中文/哈希图标全过滤掉 → 显示灰色 fallback |
| 3 | map_sync.py 第 266 行 transform_markers | "title": m.get("markerTitle"， "") | 存为 title 字段，前端读 markerTitle → 弹窗标题永远显示"点位信息" |
| 4 | map_sync.py transform_items | 只存 id/name/icon/typeIds/areaId/markerIds | 没存 specialFlag 和 sortIndex → 传送点开关完全失效，排序顺序不确定 |
| 5 | map_sync.py 第 220 行 transform_areas | "children": [c["id"] for c in a.get("children"， [])] | 子地区存为 [int， int， …]，后续 split_data.py 把它当 dict 列表遍历 → TypeError 崩溃，即使不崩，子地区结构也全部丢失 |
7.3 为什么这 5 个 Bug 这么致命
这 5 个 bug 的可怕之处在于:Python 脚本能跑、JSON 能生成、上传到 COS 能访问、前端能加载、地图能渲染——但所有功能都是错的
不是 404 错误，不是类型错误，不是逻辑错误——是数据语义错误。前端代码完全正确，但拿到的数据已经丢了字段，所以表现成"功能性的残废":进度条转不动、标题永远一样、传送开关没反应、子地区消失
而且这种 bug 极难排查。前端开发者打开浏览器看，所有请求都是 200，所有数据都正常返回，所有图标都能加载——但用户反馈"功能不对"。直到追溯到 Python 脚本层，才发现是数据转换时丢字段了
7.4 AI 写 Python 数据管道的真实难点
这 5 个 bug 复盘下来，根因都是同一个:GLM-5.1 写转换函数时，没有先读前端代码确认依赖哪些字段，而是基于 API 返回结构"自行精简"
这是一种典型的"AI 工程化短板":
| 看到 API 返回 itemList 里每个 item 都有 itemId，认为只需要 ID | 丢 count |
| 看到 icon 文件名大多是数字，认为可以用 isdigit 过滤 | 丢中文/哈希名 |
| 看到 API 字段叫 markerTitle，觉得 title 更短就改名 | 字段名不匹配 |
| 看到 itemList 字段，觉得 specialFlag 是"标记位"不重要 | 丢业务标记 |
| 看到子地区有 id，觉得存 id 就够了 | 丢结构 |
AI 写代码"能跑"≠ 数据正确。这是这次复刻最深刻的教训
7.5 业界印证:数据管道是 AI 的系统性盲区
这不是 GLM-5.1 独有的弱点。Medium 上一篇《I Replaced a Production Data Pipeline with AI Agents》讲了类似的经历:AI Agent 在处理可预见的路径时表现良好，但在遇到非预期数据格式、边缘情况和级联故障时会失败
更广泛地说，LLM 在"数据管道"这类任务上的薄弱源于三个结构性原因:
训练数据偏向前端/UI 代码，后端数据建模的真实生产案例少
缺乏"数据下游消费者"的视角，只看转换函数本身，看不到字段被谁用
过度追求代码简洁，而生产数据管道最忌讳"为了简洁丢字段"
这 5 个 CRITICAL bug 最后通过 split_data.py 的新数据(从原始 API 数据重跑)覆盖修复了，但根因教训值得所有用 AI 写数据管道的人警惕
八、最终复刻效果
九、结语: GLM5.1 能力边界与 GLM-5.2 的进化
8.1 GLM-5.1 在这次复刻里的真实得分卡
| 单文件组件翻译 | ⭐⭐⭐⭐ | Vue2 Options API → Vue3 Composition API |
| Bug 定位与修复(给定现象) | ⭐⭐⭐⭐ | "大椭圆" Bug 最终定位到 leaflet.css |
| TypeScript 类型补全 | ⭐⭐⭐⭐⭐ | 全程零类型错误 |
| Python 脚本编写(基础逻辑) | ⭐⭐⭐ | API 拉取脚本可用，但有 5 个 CRITICAL 字段丢失 |
| 技术选型时的生态评估 | ⭐ | 选 deck.gl 没意识到生态差异，导致 8 个架构级问题 |
| 跨层数据流分析 | ⭐ | Python 数据管道丢字段，前端表现异常但定位不出来 |
| 工程级 side-effect 识别 | ⭐⭐ | leaflet.css 这种 side-effect import 容易漏 |
| 忠实翻译 vs 自由发挥的判断 | ⭐⭐ | 倾向"看懂了就重写"，而非"逐字符对照" |
简而言之，GLM-5.1 在"明确边界的编码任务"上接近顶尖水平，在"需要全局工程视角的任务"上有明显短板。这跟智谱官方对 GLM-5.1 的定位("专为长程复杂工程任务而生"，200K 上下文)相比，显然还有提升空间
8.2 GLM-5.2 的针对性进化
2026 年 6 月 13 日，GLM-5.2 发布。官方技术博客和论文标题《GLM-5: from Vibe Coding to Agentic Engineering》精准概括了这一代的核心变化。下面这张对比表，把这次复刻案例的痛点直接对应到 GLM-5.2 的改进点上:
| 发布时间 | 2026-03-27 | 2026-06-13 | — |
| 上下文长度 | 200K | 无损1M(IndexShare 技术，5x) | 5 个 CRITICAL bug 跨 Python/前端两层，需要长上下文联动分析 |
| SWE-Bench Pro | 58.4 | 62.1(+3.7) | 通用工程能力 |
| Terminal Bench | 58.7 | 81.0(+22.3) | Agent 工具调用稳定性，直接影响长程复刻任务 |
| 推理控制 | 单档 Thinking | High/Max 双档，Max 档会优先搜索自己核实到的结果,减少人为失误判断的影响,不再"你说啥就是啥" | GLM-5.1 接受 fallback 默认值不主动核实(MARKER_OFFSET 因此偏了 683 像素) |
最值得关注的是 Terminal Bench 从 58.7 跃升到 81.0——这个评测专门衡量 Agent 在长程任务中的工具调用稳定性，而本案例中 GLM-5.1 最薄弱的恰恰是"跨文件、跨语言、跨数据流的工程判断"。+22.3 分的提升，如果按比例换算，意味着类似复杂度的复刻任务成功率会有质变
8.3 良性循环
最后说点个人感受
这个原神地图模块，只是我用 GLM-5.1 复刻过的众多网页之一。每一个项目都暴露了不同的 AI 能力边界:静态页面复刻暴露 CSS 还原能力，动态地图复刻暴露架构决策能力，数据管道复刻暴露跨层分析能力。这些问题单独看都是"AI 的失败"，合在一起看却是"AI 进化的路线图"
这不是单向的"厂商升级、用户受益"，而是一个良性循环: 智谱把模型做得便宜又好用，吸引更多开发者拿它去做真实的项目；开发者在生产环境里踩的每一个坑，都会以使用数据、反馈报告、开源代码的形式，成为下一代模型的训练养料；模型变强了，又吸引更难的项目入场，产生更高质量的反馈。我们这些在 GLM-5.1 时代用 AI 做过复杂复刻的人，既是受益者，也是贡献者——某种程度上，我用 GLM-5.1 复刻原神地图时踩的这些坑，就是喂给 GLM-5.2 的"训练粮"
致谢:感谢空荧酒馆团队开源 map_front_v3，让这次复刻有源可参。感谢智谱 GLM 团队，GLM5.2已经很厉害了，现在可以考虑下服务稳定性了，这个案例的所有代码、文档、复盘、会话素材提取都由 GLM-5.1 协助完成，文章本身由 GLM-5.2 协助定稿
声明:原神(Genshin Impact)商标及游戏素材版权归 miHoYo/HoYoverse 所有。地图数据为空荧酒馆社区众包，非米哈游官方提供。本项目仅作技术研究与个人使用
