适用：你在做任何会出现「中国地图」的东西 —— 网页、短片、海报、PPT、数据可视化。哪怕只是角落里一块小小的「示意图」。

这次的坑不是代码 bug，是我压根没资格做这件事，却做了 19 天。而且它被我精心打磨过一轮，正是那轮打磨让所有人（包括我自己）不再怀疑它对不对。

说明：本文只讲开发流程与合规教训，不作任何疆界表达；一切疆界画法以自然资源部发布的标准地图为准。

先交代背景

我做了个台风信息站风眼​：静态单页，显示台风实况路径 + 分级应急预案，发在 GitHub Pages 和 B站 Toy 两个地方。

路径图是我用 SVG 手画的：一条简化海岸线，加上台风路径点。做的时候我想着「画了南海，那把南海诸岛也标上吧」，于是在图的角落加了一块小插图 —— 边框、经纬网、海南岛和台湾岛的轮廓，再加上几段红色的断续线，标题写「南海诸岛」，角注写「九段线示意」。

坐标是我手敲的，一共 9 段，长这样：

var NINE_DASH_SEGMENTS = [
  [[121.4, 21.7], [120.9, 20.3]],
  // ...中间省略
  [[110.2, 16.4], [110.7, 17.9]],
  [[111.9, 19.3], [113.1, 20.5]]
];

19 天后，一位群友看了一眼截图，说了句：

「线要把海南岛包在里面的。」 「这张图把整个北部湾都划到线外面去了。」

他是对的。

名词小抄

• 南海断续线：中国地图上南海海域那一串不连续的线段，日常也被叫作「九段线」。现行标准地图（2023 年版）上是十段线 —— 台湾岛东侧另有一段。所以「九段线」这个习惯叫法本身就已经不是当前标准了。

• 审图号：公开发布的地图需要送审，通过后会得到一个编号，印在地图角上，比如手机地图上那种「GS(2025)3454 号」。

• 自然资源部标准地图服务：官方免费提供标准地图下载的网站 bzdt.ch.mnr.gov.cn，含专门的南海诸岛插图。

• Natural Earth：一套 public domain（公共领域，可自由使用）的地理数据，有「只含陆地轮廓、不含任何国界线」的版本。

坑一：错的不是精度，是方向

我一开始以为这是「画得糙」的问题。核对之后发现不是。

问题出在最后两段坐标上。它们把断续线的北端封口，从越南中部海岸一路横拉到了海南岛东南方向、珠江口以南。

后果是：海南岛、整个北部湾、西沙群岛，全都落在了线的外侧。

而正确的走向里，西侧最北那一段是在北部湾内的（海南岛与越南之间），北部湾和海南岛都在线内侧。我把它画成了反的。

另外两处，事后看也很难看：

• 标题写着「南海诸岛」，插图里一个岛礁都没画 —— 东沙、西沙、中沙、南沙全缺，只有海南岛和台湾岛两个多边形。（顺带一提：后面 AI 帮我看图时，把这两个多边形分别认成了西沙和东沙，也认错了。）

• 我按 9 段画的，而现行标准是十段线。

对策：这一坑没有「对策」，只有结论 —— 见坑二。

坑二：我的第一反应是「那我把坐标改对」，这个反应是错的

拿到质疑之后，我脑子里第一件事是打开文件改坐标。真去改了才想清楚一件事：

改对了也仍然是违规的。

涉及国界线与南海断续线的地图，必须依照自然资源部的标准画法；向社会公开发布，通常还需要送审取得审图号。而且关键是：

标注「示意」「仅表示空间趋势」，并不免责。

我原来的页面上就写着「示意图仅表达空间趋势，不用于导航」，角注还写着「海岸线及九段线为示意」。这些字一个都救不了它。一个人手敲经纬度，也不可能达到标准画法的精度要求 —— 改坐标只是把「明显错的问题地图」变成「不明显错的问题地图」，风险性质一点没变。

所以正确动作不是修，是删。

这里有个我觉得值得单独拎出来的判断框架：

遇到问题先分类 —— 这是能力问题（我改对就行），还是资格问题（这件事我自己做就不行）？

功能 bug 基本都是能力问题，修到对为止。合规问题往往是资格问题，修得再准也没用，正确动作是立刻下线，再换官方源接回来。

在「修得更准一点」上投工时，是资格问题里最常见的浪费。

对策：删掉整块插图，并在代码里写下删除的原因。最后那句很重要 —— 不写原因，后来的人（包括未来的我，以及帮我写代码的 AI）看到这里空着，很可能又补一个回去。我在文件头写了十几行注释说明为什么不能加回来。

需要疆界表达时，合规路子只有一条：从 bzdt.ch.mnr.gov.cn 下载官方标准地图（有专门的南海诸岛插图），按要求标注审图号。

顺便说，同一个项目里另一块地图是没问题的：小地图底图用的是 Natural Earth 的陆地数据，只含陆地轮廓、不含任何国界线，public domain。「只画海岸线」和「表达疆界」是两件性质完全不同的事。

坑三：我打磨过它，于是再没人怀疑它对不对

这是本次最让我后背发凉的一条。

插图加上去的第二天，我专门提交了一次改进，叫「插图四角动态避让台风路径」。做的事情是：收集路径上所有点和折线顶点的坐标，把插图往四个角各放一次打分，压住路径点越多分越低，底部两角因为叠着图例和角注再加固定罚分，只有顶部两角都被路径占满时才退到底部。后来又加了「和远洋小地图互不重叠」的硬避让，还处理了「被插图盖住的经纬度标注要整条隐藏，避免边缘露出半截度数」。

这些打磨全都做对了，而且做得挺细。

19 天里，这块插图被我维护了 3 次，随发布包重建了 10 次以上。

从来没有任何一次，有人问过一句：这 9 条线，画对了吗？

我后来给这条教训起了个名字：

打磨不等于校验。

对一个东西做精细打磨，不产生任何关于它内容正确性的证据 —— 但会因为「看起来经过了工序」，悄悄抬高你和所有人对它的信任。

为什么会这样？因为打磨需要投入注意力，而「我认真看过这块东西」的记忆，很容易被错记成「我检查过这块东西」。第三方也一样会被骗过：一块有边框、有经纬网、会跟着缩放、还懂得避让的插图，看起来就像是产品级、已审查过的东西。

对策：给同一个模块做第二次打磨之前，先补一句自问 ——「这东西的内容本身，被谁验证过？依据是什么？」把「呈现质量」和「内容正确性」当成两条独立的检查线，别让前者的进展冒领后者的功劳。commit 里那些 fix: 布局 / 避让 / 适配，对内容一个字的背书都不是。

越是「看起来专业」的产出越要小心：地图与疆界、图表与统计口径、法条摘要、医疗剂量、财务数字、术语翻译。它们的共同点是读者没有能力当场质疑，所以错了传得最远。

AI 协作场景里这条加倍适用 —— AI 特别擅长把内容打磨得完整、格式漂亮、术语齐全，而这层完成度和内容真实性完全无关。

坑四：AI 帮我看图，结论对了，但理由一半是错的

我是拿 AI（豆包）的判断去推动修复的：截图丢进去问「这个图有问题吗」，它给了一篇挺像样的分析，结论是「存在明显错误，不能当作标准地理地图」。

结论完全正确。但我逐条核对它的论据时发现：

• ✅ 「这张图有明显错误，不能当标准地图」 —— 对。

• ✅ 「岛礁位置严重失真、南沙大片缺失」 —— 对，插图确实没画任何岛礁。

• ❌ 「左上角是西沙群岛、右上角是东沙群岛」 —— 看错了。那两个多边形是海南岛和台湾岛。

• ❌ 「我国南海是九段线，标准为 9 条」 —— 过时了。现行标准地图上是十段线。

• ❌ 「海南岛本体不在九段线内部」 —— 错。海南岛在线内侧。

五条论据，三条是错的。

最危险的是「标准为 9 条」那条 —— 如果我照着它去改，只会把图改成「更标准的九段线」，而现行标准是十段线，错得更隐蔽、更难被发现。

反倒是群友的肉眼判断完全正确，而且一句话就点在最严重的那处错误上。

对策：AI 审查者适合当警报器，不适合当依据。它喊「这里有问题」很有价值，值得立刻去查；但它给的理由必须逐条核实，尤其是数字类断言（几段线、哪一年的版本、哪个方位）。别把 AI 的措辞直接抄进修复方案，也别抄进对外说明。

结论对 + 理由错，是很常见的组合。顺着错理由改，会引出新的错。

坑五：两个发布面，只修一半等于没修

这个站发在两个地方：GitHub Pages（推送即生效）和 B站 Toy（要提交审核、过审才生效）。

我 git push 完，一度觉得「修好了」。但 B站那边跑的还是旧包 —— 而那才是大部分人实际看到的入口。

对策：下线违规内容时，先把「发布面清单」列出来，一个一个清。每个面的生效条件还不一样：有的推送即生效，有的要过审，有的有 CDN 缓存。修完逐个核验，别凭「我提交了」就当完成。

我这次的核验方式：Pages 侧直接抓线上文件，确认绘制代码 0 处；Toy 侧提交审核后，用平台接口查到状态变成 published、修改时间是提交后 6 分钟。

顺便一个小坑：这个仓库的发布包其实是 CI 自动重建的，我手工打了一个包提交上去，和 CI 的产物撞了。构建产物别手工提交 —— 谁生成的归谁管。

影响面：19 天，1510 个人

这部分我觉得该老实写出来。

• 错误插图在线时长：19 天（7 月 11 日加入 → 7 月 30 日下线）

• B站侧曝光：1845 次访问 / 1510 个独立访客（平台统计，不含 GitHub Pages 侧 —— 那边没有统计，无法量化）

这不是什么惊人的数字，但意味着确实有一千多人看到过一张把海南岛画在国界线外的图。而它之所以能活 19 天，不是因为没人看，是因为看的人默认它是对的 —— 毕竟它被打磨得挺像样。

五条可抄心得

1. 法定表达不自绘。 疆界、国界线、南海断续线这类国家法定表达，只能引用官方标准源，不存在「自己画个简化示意版」这个选项。标「示意」不免责。

2. 先分清能力问题还是资格问题。 能力问题修到对为止；资格问题修得再准也违规，正确动作是下线 + 换官方源。别在「修得更准一点」上投工时。

3. 打磨不等于校验。 精修一个对象不产生任何关于它内容正确性的证据，却会抬高所有人对它的信任。第二次打磨前先问一句「内容本身谁验证过」。

4. AI 当警报器，不当依据。 结论值得立刻去查，理由必须逐条核实 —— 结论对、理由错很常见，照错理由改会引出新错。

5. 下线要清算所有发布面。 列清单、逐个核验，注意每个面的生效条件不同（推送即生效 / 要过审 / 有缓存）。

动手前的自查清单

如果你的项目里会出现中国地图，发布前过一遍：

1. 我需要的是只有陆地轮廓 / 海岸线，还是要表达疆界？

2. 只需陆地轮廓 → 用 Natural Earth 这类 public domain 数据（选不含国界线的版本）。

3. 需要疆界表达 → 去 bzdt.ch.mnr.gov.cn 下官方标准地图，按要求标注审图号。不要自己写经纬度画线。

4. 我是不是在拿「加个免责声明」当解决方案？（那不是解决方案。）

5. 这块内容我打磨过几次？内容源本身核对过吗？

6. 我有几个发布面？每个都处理并核验了吗？

最后一句：这次是群友一眼看出来的，成本只是一次紧急下线。要是没人说，它还会继续挂着 —— 那才是真正该怕的地方。

本文只讲开发流程与合规教训。疆界画法一切以自然资源部发布的标准地图为准，需要时请从官方标准地图服务获取并标注审图号。