在家里测试了，15G的数据，还是弧段数据而非正常点线面数据，500M的缓存，缓存生成时间5分钟。我感觉够用了。现在500M到1G的点线面数据，缓存也就20M左右，已经相当小了。15G数据在QGIS里几乎是没法渲染的，画一半就停止了，无法拖拽，下图是渲染效果，GIF比较大请耐心等待。
现在优化的思路有几个：
- 最底层够用就行，看的大致清晰即可，使用Visvalingam-Whyatt化简，然后加上融合，抽稀等各种方案，GIS毕竟是一门工程学，我只是想拿AI试试手，现在感觉表现不错。
- 跳层构建，只考虑偶数层，因为我们只需要视觉效果，单纯的快，抽偶数层也能将数据减少的更小
- 逐层考虑密度，虽然导致上层不可避免的栅格化，但是抽稀力度够大，而且粗层级也不需要特别清晰
- 线层融合，尽量不抽得太狠，否则容易断线，需要构建简单拓扑，类似MapShaper思路，不过因为我们的瓦片映射到整数坐标了，构建更简单些
- 小面抽稀，小面显示是铺底色，把面边线删除，这样不会导致大片稀疏小面缩小后完全不见得情况，也不会大片合并起来看着很怪
用AI折腾了这么久，有一些小心得：
首先，AI有很多种工作流，要看AI的能力，也要看人的能力。如果AI能力强，建议用长链任务（也就是如果你有钱），这样效率比较高，而且因为AI智能高，反馈好，用起来也舒服。
如果你跟我一样是穷人，那么推荐人机反馈方案，大致流程如下：
- 首先，和AI一起，将任务方案写出来
- 然后，对任务进行拆解，拆解的越细越好
- 再对拆解后的任务逐一进行分析，分析清楚其中的关键点
- 逐步推进，推进过程中，将进度和关键方案，以及过程skill落入文档（非常重要）
- 因为你用的AI很傻，所以出问题了，直接开新任务，别犹豫（此时你的进度文档和过程skill就非常重要），减少上下文长度非常重要，虽然大部分的AI 编程代理会自动压缩上下文，但是上下文过长，会让你的AI变得更傻
- 原则问题必须要落盘，比如你的系统，你的脚本环境，编译器位置，代码编码以及规范格式，这些东西一定要写到agent.md或者claude.md之类的地方
- 拆解的任务出问题了，按进度回滚，所以需要有版本管理工具，尽量做到每次处理落盘
- 傻AI的注意力，以及命令服从性较差，因此，不要想着一步登天，能拆多细拆多细，否则返工的时间会让你崩溃
- 给AI的提示词中尽量包括明确的命令信息，对于指令遵循较差的AI，在agent.md里写清楚，只遵循指令做事，在交互时要反复强调，看到超出范围及时制止行为
- 如果是人工交互，那么方案基本上都需要你交互进行，也就是，本人需要对你所做的东西有至少五分了解。建议是先用网页版AI（Deepseek,Google Gemini,Qwen等）对已有的工具、库、环境、skill等东西进行一番搜查，然后再动手，网页版的智商会比API的智商要高（有高人调教过），搜索也更详细，建议如果你连五分了解都没有，先用网页版出方案，理清思路和实现，再考虑本地实现。
- 你如果实在不清楚但是想做，花钱请高智商AI吧，现在REA逆向也基本不咋用动脑子。
