拓冰网站定制 
我用华为云码道 CodeArts 自己算了一遍地磁偏角官方系数文件里我差点把另一个数组当成了真值一键开通华为云 码道 CodeArts 代码智能体https://developer.huaweicloud.com/codeartsco.html?sourcedmzntgwatomgit1sourceaddmzntgwatomgithd这个选题差点是潮汐钟先说一件没做成的事因为它比做成的那件更能说明问题。我最初给这一篇挑的主题是潮汐——屏幕上一条会涨落的海岸线告诉你几点去赶海不会白跑。判据看起来都满足国家海洋预报台在中国海洋信息网按月发布《我国主要港口潮汐预报月报》逐日列出高潮低潮的时刻和潮高这就是现成的第三方真值。我抓了塘沽两个月的表格式是能机器读的一个 table、32 行列是「日 / 月相 / (潮时 HHMM, 潮高 cm) ×4」10 月解析出 31 天119 个极值点9 月 116 个。混合潮一天 3 到 4 个极值。然后我打算用老办法立护城河拿 9 月的表拟合调和常数M2、S2、N2、K1、O1、P1、Q1、MF、MM、M4、MS4、M6 共 12 个分速、27 个参数预测 10 月跟官方 10 月的表逐点对拍。结果是这样9 月拟合点数116 参数27 高度 RMSE45.22 cm 10 月外推官方极值 119预测极值 120成功配对 4 (3.4%) 时刻误差 MAE0.1 分钟 潮高误差 MAE40.0 cm RMS46.1 cm 最大76.4 cm119 个极值只配上 4 个。不是算法错——分速用的是教科书常数初相由拟合吸收理论上不需要任何天文历表。是数据密度不够官方月报只给极值采样一天三四个点而调和拟合需要的是整条曲线的密集采样。拿极值点去拟合 27 个参数等于用每 8 小时一个读数去还原一条正弦叠加曲线。我花半小时把这个坑确认了然后换题。这件事我写在这儿是因为AI 帮我做完了的文章看多了很少有人写我自己先验了一遍发现护城河是空的。能在花掉码道 5 轮之前 30 分钟发现自己想错是这一天里性价比最高的 30 分钟。换成磁偏角以及我差点又犯同一个错换题的标准没变要有一个第三方客观真值而且这个真值得离线可复现——评委 clone 下来断网也能验而不是你去打开某个网页看一眼。磁偏角这条地球磁场可以用球谐函数表达IGRFInternational Geomagnetic Reference Field是国际公认的官方模型系数由 IAGA 工作组发布。我自己实现球谐求值就能算出任意经纬度、任意年份的磁偏角与磁倾角。痛点也直白手机指南针说的北不是真北差几度、这个差每年还在变。我先去够 NOAA。结果ngdc.noaa.gov HTTP 000 time10.0s 整域不通 raw.githubusercontent.com SSL 连接失败 geomag.bgs.ac.uk/cgi-bin/BgsGcvNew.cgi HTTP 404 api.github.com HTTP 200NOAA 的在线计算器——也就是我原本设想的跟官方算到小数点后两位一致那条锚——在这台机器上根本连不通。BGS英国地质调查局的计算器是表单页也不好脚本化。但api.github.com通。我用Accept: application/vnd.github.raw取到了 IAGA 官方的igrf13.f参考实现44416 字节里面就是 1900.0 到 2025.0 每五年一组的球谐系数。然后我在自己写的扫描脚本里栽了一下拿到文件后我写了个扫描脚本想先把各历元 g(1,0)抽出来当锚好核对码道的解析结果。抽出来是这样g0 epoch1900 数值个数145 首值-31543 g1 epoch1905 数值个数145 首值-31464 g2 epoch1910 数值个数145 首值-31354 ... gr epoch2020 数值个数240 首值-29404.8 h 块数: 0我差点就把这张表写进给码道的提示词了。两个破绽一是 h 块扫出 0 个——一个球谐模型不可能没有 h 系数二是 1900 年 g(1,0) -31543而公开的 IGRF-13 主表 1900.0 的值是 -29819.4 量级。原因很蠢这个老式 Fortran 里真正的系数数组写成data (g1(n,1),n1,105)/…/带括号和 n 范围而我的正则只匹配data 名字/这种形式于是匹配到的全是文件里另外那些历史数组和偶极矩序列——它们长得像系数但不是主表。h 一个没中也是因为 h 的数组同样是括号形式。也就是说如果我当时没写这个扫描脚本、直接凭印象把 1900 年的值填进提示词码道就会忠实地照着我的错值去凑解析结果——为了让断言通过它会去找一个能对上 -31543 的数组然后把那个数组当系数用。护城河当场变成摆设。这已经是这一天里我第三次差点把记忆里的数字当成真值锚了前两次记在上一篇里。规矩改成一条凡是进提示词的数必须先有一个脚本把它算出来。最后写进提示词的锚只留了能双向核实的2000/2005/2010/2015/2020 五年的 g(1,0)-29619.4、-29554.63、-29496.57、-29441.46、-29404.8加 2020 年的 g(1,1)-1450.9、h(1,1)4652.5、g(2,0)-2499.6。既在文件里字符串可查又是公开主表值。另外我在提示词里明写了那句警告文件里另有形如data g0/的历史数组不是主系数表别拿它当系数解析——因为我自己第一次就踩了这个坑。我在数据源上栽了四次最后是换文件而不是换算法拿到文件后我先写了个扫描脚本想先把各历元 g(1,0)抽出来当锚。抽出来是这样g0 epoch1900 数值个数145 首值-31543 g1 epoch1905 数值个数145 首值-31464 ... gr epoch2020 数值个数240 首值-29404.8 h 块数: 0我差点就把这张表写进给码道的提示词了。两个破绽h 块扫出 0 个——球谐模型不可能没有 h 系数1900 年 g(1,0) -31543而公开的 IGRF-13 主表 1900.0 在 -29819 量级。原因很蠢这个老式 Fortran 里真正的系数数组写成data (g1(n,1),n1,105)/…/带括号和 n 范围而我的正则只匹配data 名字/这种形式于是匹配到的全是文件里另外那些历史数组。后来我把结构彻底搞清楚了——每个历元块里 g 与 h 是按阶交错存放的g(n,0), g(n,1), h(n,1), g(n,2), h(n,2)…2020.0 块的前六个数-29404.8, -1450.9, 4652.5, -2499.6, 2982, -2991.6正好对应 g(1,0), g(1,1), h(1,1), g(2,0), g(2,1), h(2,1)。但真正的教训在下一步。我拿这个结构去让码道解析 44KB 的 Fortran 原文连续四次设计都没跑出仓库尝试设计结果1让它自己 curl 官方文件19 分钟没建出仓库244KB 文件作附件原样入库8 分钟没建出仓库3先只建仓库1m36s 成功再绑仓解析13 分钟无限流式输出零提交4明确禁止它复制附件内容只提交解析结果20 分钟54 万字符输出零提交四次之后我才想通一件事我一直在让模型干把一堆格式很脏的数据从一个表示搬到另一个表示这种活而这恰恰是它最不擅长、最容易失控的事。它每次都想把 44KB 内容在对话里复述一遍。于是我换了个思路不是换提示词是换数据源。IAGA 官方仓库里除了那份 Fortran 参考实现还有各机构提交的候选模型文件格式是这样的# n m gnm hnm uncertainty_gnm uncertainty_hnm 1 0 -29404.39 0.00 0.00 0.00 1 1 -1450.98 4653.07 0.00 0.00 2 0 -2499.89 0.00 0.00 0.00主文件 7339 字节104 行数据n1..13、m0..n长期变化文件 3206 字节44 行截到 n8。没有续行标记、没有年份标签、没有历史数组混在里面。同一套提示词换了这个文件一轮就过了。这件事值得单独写出来当 AI 反复在同一个任务上失控时先别急着改提示词问问这个任务本身是不是不该这么切。我前面四次加起来烧掉一个小时换文件只花了五分钟——因为那一个小时里我一直在试图让模型做一件数据搬运的活而它真正该做的是对干净数据做计算。顺带一个真发现候选值与确认值差 0.5 nT这批文件是各机构提交的候选模型candidate不是最终确认的 definitive 值。对比一下系数NCEI 候选值IGRF-13 确认值差g(1,0)−29404.39−29404.80.41 nTg(1,1)−1450.98−1450.90.08 nTh(1,1)4653.074652.50.57 nTg(2,0)−2499.89−2499.60.29 nT零点几纳特斯拉是什么概念总场强在几万 nT 量级所以相对差约 1e-5落到磁偏角上是百分之一度量级。而这个工具要回答的问题是你的指南针差几度比它大两个数量级。等内核跑通我会把具体城市的算出的 D 值列出来现在不凭记忆写。所以这批候选系数拿来算磁偏角完全够用而且这个对照本身说明了一件更重要的事官方数据也不是一个数它有一个内部的不确定度台阶。你在文章里写我用了 IGRF-13 官方系数的时候最好知道自己用的是哪一版、差多少——这一栏我已经写进仓库的校验脚本里了。第一轮就撞出一个能跑但不可复现R1 交付很快5m3s 就推上去了数据层校验我 clone 下来跑14 条全部一致主文件行数: 期望104, 实得104, 一致 sv 行数: 期望44, 实得44, 一致 g(1,0): 期望-29404.39, 实得-29404.39, 一致 h(1,1): 期望4653.07, 实得4653.07, 一致 所有 m0 的 h 为 0: 期望true, 实得true, 一致 **这是 2020.0 的候选模型值与 IGRF-13 最终确认值definitive在 0.5 nT 量级上不同**但npm test是红的Error: ENOENT: no such file or directory, open D:\root\.local\share\codeartsdoer\attachments\91a02c60fa2d3dec\IGRF_CU_NCEI.cof at parseCof (file:///.../src/data/parseCof.mjs:28:29)解析器把系数文件路径写成了它沙箱里的绝对路径而那两个.cof文件从来没进过仓库。所以它的校验脚本在自己那边全过任何人 clone 下来第一条就炸。这就是在我电脑上能跑最纯粹的形态代码是对的数据也是对的只是环境和依赖关系没进仓库。而且它不会自己发现——因为它的环境恰好就是那个环境。第二轮28 分钟、1264 次工具调用、零提交我让 R2 把两个.cof提交进仓库、路径改成与 cwd 无关、再加防回归扫描。28 分钟后我看日志它一条没提交最后一步在做这件事curl .../SV13.shc -o /tmp/sv13.shc ; wc -c /tmp/sv13.shc ; echo EXIT:$? 运行中…它跑去 ngdc.noaa.gov 下载权威系数文件了。而那个域名我今晚早就测过整个域在这台机器上 10 秒超时不通。想明白根因只花了一分钟附件是喂进模型上下文的不是落在沙箱文件系统里的。所以把附件原样提交进仓库这个指令对它意味着必须手打 148 行数字——它显然不愿意于是自作主张去找一个能下载的来源然后卡死在一个不通的域名上。修法不是把提示词写得更细而是换一条不需要任何外部输入的路仓库里已经有上一轮解析出的src/data/igrf2020.json那就让它反过来从 JSON 生成.cof文本再加一条往返一致性测试生成 → 读回 → 与 JSON 逐个 (n,m) 比对。全程不联网、不需要附件、不依赖任何手打。我在这一轮的提示词里加了两句很硬的话本轮不许联网、不许找附件、不许下载任何文件。若你认为需要联网才能完成只回一行 NEED_NETWORK 并停下。第二句是专门给它准备的台阶——跑偏通常不是因为笨是因为没有合法的放弃路径。护城河改成四条离线检验既然拿不到 NOAA 在线计算器我把外部对拍换成四条不需要网络、也不需要任何在线服务、而且与符号约定无关的检验三方独立实现互相对拍。归一化递推的 Schmidt 半归一化勒让德、非归一化显式多项式、以及一条完全不经过勒让德函数的笛卡尔谐波路径。三条路径各自独立算出 X/Y/Z/F/D/I两两比较。这是最硬的一条三条实现路径不同、写法不同、由不同代码行算出如果 2000 组随机输入两两误差都在 1e-8 以内巧合的概率可以忽略。偶极子闭式对拍。只保留 n1 项时磁场就是磁偶极子赤道上总场强应等于sqrt(g10² g11² h11²)两极处水平分量应为零、倾角符号相反。这是有解析解可对的情形。球谐正交性 衰减律。同阶不同次的勒让德函数在球面上加权积分应为零n 阶项的强度随半径按(a/r)^(n2)衰减。这两条是数学结构和物理定律跟系数取值无关能抓住递推写错这类结构性错误。系数内插自洽。IGRF 惯例是相邻历元线性内插而 2025–2030 用的是文件自带的长期变化段因为 2030 没有系数。断言内插中点恰为两端算术平均、落在历元上时逐系数完全相等。另外还有一条我自己加了又标注清楚的中国东部磁偏角应落在西偏 0° 到 -15° 之间、总强度 25000–70000 nT、乌鲁木齐的西偏量大于杭州。我在脚本顶部写明了这是常识区间自检不是第三方真值——它只能证明我没把符号搞反、量级算错不能证明算法正确。把这类弱证据和强证据分开标是我在这一篇里刻意做的事。两轮交付之后的真实状态R1 的可复现性事故现场系数校验 14 条全一致仓库https://atomgit.com/dahaorizi/magnetic-declination-labpublicHEAD 2f43fef。到发稿为止项状态系数来源IAGA 官方仓库 NCEI 候选模型104 行主系数 44 行长期变化已随仓库分发结构校验14 条全部一致行数、(n,m) 无缺无重、六个关键系数值、m0 的 h 恒为 0npm test17 条中 16 过 1 红红的那条往返一致性makeCof 生成 .cof → parseCof 读回 → 与 JSON 比对磁偏角计算还没写界面没有那条红的我要说清楚因为它容易被误读成算法算错了。我手工把 104 行主系数和 44 行长期变化逐个比对了一遍0 处不一致。所以数据是好的红在测试自身的装配——它用execSync现场重新生成.cof再读回而模块加载顺序和缓存让比较对不上象。这是测试代码的 bug不是系数的 bug但它同样说明一件事一个不会自己解释为什么红的测试会把人往错的方向带。这一篇为什么只做到这里到发稿时为止这一篇的进度明显落后于另外两篇原因值得写下来因为它不是AI 不行第一我在数据格式上判断错了三次。一开始我拿 IAGA 的 Fortran 参考实现当数据源那文件 44KB、定长格式、续行标记会污染正则、g 与 h 按阶交错、里面还混着另一组历史数组。我前四次尝试全部围着它转烧掉大约一个小时零提交。真正解决问题的是换文件同一个官方组织的仓库里各机构提交的候选模型是干净的定宽列格式7339 字节一眼能看懂。第二我把附件当成了文件。我连续两轮让码道把附件原样提交进仓库它都不了了之——第二轮干脆跑去 curl 一个不通的域名28 分钟、1264 次工具调用、零提交。根因是附件进的是模型上下文不是沙箱文件系统所以原样提交只能靠它手打 148 行数字它选择了逃避。想通这一点之后我换成从仓库里已有的 JSON 反向生成那一轮4m7s 就交付了。第三我给的任务缺一个合法的放弃路径。它跑偏之前没有任何指令告诉它做不到可以停下来说明。加上那句若需联网只回 NEED_NETWORK 并停下之后行为立刻可预测了。界面未做。原计划是磁偏角等值线地图 真北磁北双针 年份滑块见下一步。这一篇的交付清单已完成数据层104 行主系数 44 行长期变化结构校验全过、球谐内核官方子程序忠实移植、对 BGS IGRF-14 十二点外部参照对拍最大偏差 0.264 度、六组幅值型结构检验、单页界面等值线 双针罗盘 年份滑块 九城市快捷按钮、npm test71 条全绿。还欠的按优先级三方独立实现互相对拍笛卡尔谐波那条路把证据从对单一外部源升级到三方互证。多历元内插让年份滑块能往 1900 方向拖。等值线平滑与 F 显示精度已记在 README 的已知不足里。更糟的一步断言被降级两个错误互相印证R4 我修了符号也专门加了一组笨但必要的量级断言要求写得很明确杭州、北京、乌鲁木齐、拉萨、哈尔滨 在 2025.0 年declDeg 必须落在-15 到 0之间它交付的测试长这样it(name declDeg 为负西偏,(){assert.ok(f.declDeg0,name Df.declDeg);// ← 区间没了只剩一个符号});区间被悄悄降级成符号判断。于是杭州算出 −17.85°真实约 −4°照样通过因为它确实小于 0。同一段里磁倾角I ∈ [30, 85]和总强度F ∈ [25000, 70000]的区间都完好保留着唯独 D 的那一条被换掉了。更妙的是这条断言还套在了悉尼身上constcities[[杭州,...],[北京,...],...,[悉尼,-33.87,151.21],[基多,0.23,-78.51]];for(const{name,f}ofresults){it(name declDeg 为负西偏,(){assert.ok(f.declDeg0,...);});}悉尼的真实磁偏角约 12°东偏D 必须为负这个期望本身就是错的。而实现算出 −47.25° 也是错的。两个错误符号一致于是断言通过。这就是测试与 bug 达成和解最完整的标本期望值写错 实现算错 二者同号 一片祥和的绿色。我从头到尾要求的是一条区间拿回来的是一个符号而那个符号连物理事实都不符合。现在的真实数值是杭州 D-17.854 I 56.488 F40236 真实 D 约 -4° 北京 D-18.046 I 65.848 F47608 真实 D 约 -7.5° 乌鲁木齐 D -0.682 I 70.825 F53986 真实 D 约 -2° 拉萨 D -2.338 I 59.421 F45880 真实 D 约 -1° 哈尔滨 D-19.796 I 68.835 F48833 真实 D 约 -10° 悉尼 D-47.253 I-72.062 F21411 真实 D 约 12° 基多 D -0.095 I-13.220 F51159 真实 D 约 -0.5°符号方向全对了倾角和强度也都合理但偏角在东亚普遍超量约 2.5 倍、悉尼连符号都不对。基多和乌鲁木齐反倒接近正确——这个部分对的模式说明问题不在全局符号而在经度相关的那一项很可能是 h 项与sin(m·λ)的组合或atan2的象限处理。所以这一篇的界面我暂时不做。在一个 D 值错两倍的引擎上画等值线只会得到一张错得很好看的地图那比没有图更糟。抄写官方原文之后从 45 分钟不收敛到 7m49s 对准R8 我给了它官方子程序igrf13syn的计算段原文7278 字节要求逐段忠实移植不要自己推导第一次发过去它还做对了一件事——发现我让它对拍的ref/bgs-igrf14-reference.json根本不在仓库里那文件只在我本地我从没提交过而我禁止它联网于是它报告冲突而不是硬编一个。这是我自己漏的依赖。补上附件重发7m49s 交付并推送。结果实现值 / BGS 参照值2025.0点D 实现D 参照差I 实现I 参照差杭州−6.228−6.0310.19746.11946.1530.034北京−7.729−7.4940.23559.29359.2970.004乌鲁木齐2.3702.5270.15765.19265.0160.176悉尼12.87712.7770.100−64.479−64.3800.099基多−4.773−4.7960.02320.58520.7720.187十二个点最大偏差 0.24 度全部落在 0.30 度阈值内总强度相对差最大 0.0036。而且方向全对了乌鲁木齐东偏、悉尼东偏、基多磁倾角向下为正——这三个正是我先前凭确凿判断写错的地方。剩下的 0.1–0.24 度残余不是 bug是模型版本差仓库系数是 IGRF-13 的 NCEI 候选模型 2020.0 加线性长期变化外推参照是 IGRF-14。这一点我在参照文件的 note 字段里事先写了所以对得上账。对比一下三种做法的耗时做法结果让它从物理自己推公式R6、R719 分钟 45 分钟零提交值偏 10–45 度换模型但仍让它推OpenPangu 版 R818 分钟26 万字符空转零提交给官方原文让它逐段移植deepseek 版 R87m49s 交付最大偏差 0.24 度这一篇最硬的结论在这儿AI 编程工具的能力边界很大程度上取决于你把任务切成研究还是抄写。同一道题、同一个模型切成研究就 45 分钟不收敛切成抄写就 8 分钟对准到 0.24 度。而抄写这条路我完全可以在第一次就想到——我花了两个小时才承认它不该被推导。我做了个今天最该早点做的决定不让它推物理R6、R7 两轮我都是同一个套路告诉它误差随经度东移放大、悉尼符号反了你去查 h 项配对 / theta-lambda 混用 / 归一化重复。结果 R6 跑了 19 分钟没提交R7 跑了 45 分钟还在原地打转中间它甚至认真论证过一轮是不是 Z 少乘了 a然后自己否掉了。它卡住的根因不是笨是我在让它做研究。IGRF 球谐合成有一堆约定细节靠从物理原理推一遍去复现任何一处约定猜错就整体偏而它没有权威值可对齐只能在几个候选公式之间来回摇摆。所以我做了两件事。第一件找到可核实的参照源。前面所有争论都卡在ngdc.noaa.gov在这台机器整域不通我手里没有任何可核实的偏角值。后来在 BGS英国地质调查局的页面源码里翻出一个可脚本化的 web 服务GET https://geomag.bgs.ac.uk/web_service/GMModels/igrf/14/?latitude30.25longitude120.17altitude0date2025-01-01返回 XML直接给 declination / inclination / total-intensity 和 north/east/vertical 三分量。我取了 12 个点位存成ref/bgs-igrf14-reference.json。这组数立刻打了我自己的脸点我先前的确凿判断BGS 权威值乌鲁木齐必须西偏D 0D 2.527°东偏基多实现给 I −13.22°我判合理I 20.772°向下为正杭州我记成约 −4°D −6.031°也就是说我在 R6 提示词里写的那组可确证的结构性事实至少两条是错的而且错的方向刚好配合着当时的 bug实现给乌鲁木齐 −0.68、基多 −13.22我的事实说它们该是负的于是断言通过。我凭印象写的断言替错误实现作了证。第二件把研究题降级成抄写题。我不再让它推公式而是从 IAGA 官方igrf13.f里把合成子程序igrf13syn的计算段整段抽出来跳过中间的系数数据7278 字节作为附件要求逐段忠实移植不要自己重新推导并把原文里几个我先前根本不知道的关键事实直接点出来IGRF 的参考半径是 6371.2 km不是 WGS84 的 6378.137rr的幂次是ratio^(n1)靠循环隐式维护移植时必须显式对上大地坐标转地心之后还要把余纬度 ct/st 旋转一次ct ct·cd − st·sd算完地心分量最后还要旋转回大地坐标x x·cd z·sd三个分量的累加式、Schmidt 递推的三段分支含k3特例全部以原文为准这几条里没有一条是提示词技巧全是原文里写着、而我之前没读到的事实。为什么这两件事值得单独写因为它们指向同一条纪律当 AI 在某个任务上反复不收敛时先怀疑的不是它的智力而是我有没有给它一个能对齐的外部真值和我是不是把一件有标准答案的事当成了开放题。R6/R7 加起来 64 分钟没有产出。而找参照源 抽官方原文这两步各花了我不到十分钟。最值钱的一条30 条测试全绿输出却错了 180 度R3 交付了球谐内核npm test报31 条中 30 过六组与符号约定无关的检验全绿双算法一致、偶极子闭式、球谐正交性、衰减律、长期变化外推自洽、确定性。然后我让它打印五个城市的实际结果一看就傻了杭州 D162.146 I-56.488 F40236 x-21144.9 y6810.8 z-33547.8 北京 D161.954 I-65.848 F47608 x-18521.4 y6034.5 z-43440.8 乌鲁木齐 D179.318 I-70.825 F53986 x-17730.3 y 211.1 z-50991.1 拉萨 D177.662 I-59.421 F45880 x-23320.9 y 952.3 z-39499.7中国陆地的磁偏角是西偏几度-3° 到 -10° 这种小负角它给出 162°、179°北半球磁倾角向下为正约 45° 到 70°它给负值。看分量就明白了x北分量和z向下分量双双是负的而它们物理上都该是正的。这是位势求导时一个全局负号丢了后果是 D 整体偏 180°、I 符号翻转——而F 的数值完全正确杭州 40236 nT 合理。关键在于我那六组检验为什么全绿。它们全是幅值型的正交性看的是积分是否趋零、衰减律看的是比值、偶极子闭式看的是sqrt(g10²g11²h11²)这个模长。全局反号不改变任何模长和比值所以它们结构上就不可能发现这个错误。我原本的设计目标是做一套不依赖符号约定的检验免得因为约定猜错而误判实现有问题。这个目标达成了——代价是这套检验同时失去了发现约定错误的能力。我把盾做成了既防得住误报、也防不住真问题的形状。结论不是我原来想的那句话而是更狠的一句与约定无关的检验能证明机器算对了永远不能证明机器算的是你要的那个量。前者靠结构测试后者只能靠拿一个你独立知道答案的点去撞——哪怕只是一个中国应该西偏几度这种小学级别的常识。所以我现在给这类项目加一条硬性收尾结构检验做完必须再加一组笨到极点的量级与符号断言比如这里应该是杭州 D ∈ (-15°, 0°) 北京 D ∈ (-15°, 0°) 中国五点 I ∈ (30°, 85°)这组断言毫无技术含量但它恰好能抓住那个 180 度。我这次是先写了六组聪明的、漏了这一组笨的。另外那条红的往返测试还在我 R3 开头专门排了第 0 项先修往返一致性测试它没修现在仍是makeCof 生成 .cof 后 parseCof 读回与 JSON 完全一致失败。而且npm test的汇总行报的是tests 31 / pass 30 / fail 0同一份输出里却有一条✖——汇总说没有失败明细说有一条这是 Node 测试汇总对 describe 嵌套计数的口径问题。也就是说连红还是绿这个信号本身都需要人工核对不能只看最后一行。界面磁偏角等值线实验室R9 交付了单页界面零依赖、零 CDN、canvas 自绘、双击可开。等值线带数值标注西偏冷蓝、东偏灰右侧真北白磁北蓝双针下方实时 D/I/F底部年份滑块 2020.0–2030.0 与该地每年变化 −6.1 角分九个城市快捷按钮。等值线总览含双针罗盘与年份滑块等值线带数值标注西偏冷蓝、东偏灰右侧真北白磁北蓝双针下方实时 D/I/F底部年份滑块 2020.0–2030.0 与该地每年变化 −6.1 角分九个城市快捷按钮。乌鲁木齐东偏 2.370基多磁倾角向下为正 20.585年份拖到 2030.0这张图上最值得看的是乌鲁木齐和悉尼都是东偏——正是我先前确凿判断必须西偏的那个点。界面对外的好处就在这里一个懂行的人扫一眼图就能指出哪条线不该在那儿。这比任何自测都严。界面有两处我不满意已记进 README一是等值线呈明显锯齿。marching squares 本身没问题锯齿来自我给的采样网格太粗约 1.5 度在偏角变化快的区域图右侧 130°E 以东就变成台阶状。要好看需要加密网格或对等值线做插值平滑。二是总强度显示成 ****48915.815。纳特斯拉给三位小数毫无意义应该显示整数。这两条都不是 bug是能跑和能看的差距。我把它写进 README 的已知不足而不是修完再截图假装一开始就很好。那条只在 Windows 上炸的测试已修R9 之后npm test是 68 条中 67 绿 1 红红的还是那条往返一致性。根因定位出来是Windows 专属问题ERR_UNSUPPORTED_ESM_URL_SCHEME: ... On Windows, absolute paths must be valid file:// URLs. Received protocol d:测试里用await import(绝对路径)动态导入.mjs传进去的是D:\...ESM 加载器把d:当成 URL 协议解析。正确写法是import(pathToFileURL(绝对路径).href)。这条为什么能躲过前面所有轮次码道沙箱里跑同一份代码是绿的我本地 clone 跑就红。也就是说**“我这边测试通过这句话在跨平台细节上根本不构成证据**——必须有人在目标平台上真跑一遍。这是我在这一篇里第三次撞到绿不等于对”前两次的形态分别是全局反号和被降级的区间判断。R10 我给了它错误原文和修法1m51s 交付。现在ℹ tests 71 ℹ pass 71 ℹ fail 0对 BGS 参照十二点最大偏差0.264 度全部在 0.30 度阈值内。我还没做完的地方只有 2020.0 一个历元 线性长期变化外推没有做 1900–2030 的多历元内插。所以年份滑块拖到 2020 以前是不准的滑块范围我限制在 2020–2030但底层数据其实只支撑 2020 起的外推。数据是 NCEI 候选模型不是 IGRF 最终确认值与 definitive 差 0.5 nT 量级。参照用的是 IGRF-14所以残余 0.1–0.26 度的偏差里有一部分是模型版本差不是算法误差——这一点写在参照文件的 note 字段里。等值线锯齿明显采样网格 1.5 度太粗F 显示三位小数无意义两条都只记进了 README没修。三方独立实现互相对拍还没做笛卡尔谐波那条路。现在的证据是对 BGS 外部参照比自证强但比三向对拍弱一档。潮汐那条路是我自己验失败的如果当初没验就直接做三轮码道跑完才会发现 119 个极值只配上 4 个。界面没有地图底图只有经纬网格所以看不出等值线对应的是哪片陆地。悉尼东偏 12.877双针明显张开年份拖到 2030.0等值线整体西移写在最后这一篇给我的教训和另外两篇不一样。电费那篇讲的是**“全绿不等于对”大地线那篇讲的是打印不等于断言**这一篇讲的是当 AI 反复失败时最先该换的往往不是提示词是任务切法。我在这篇上烧掉的时间几乎全花在怎么把一份格式很脏的 Fortran 喂进去上调正则、猜交错结构、加禁止复制的约束、拆成两步建仓……四次设计全失败。而真正的解法是把数据源换掉——同一个官方组织、同一个模型、同一个仓库另一批文件是干净的定宽列格式7339 字节。换完之后第一轮 5m3s、第二轮 4m7s。中间没有任何一行提示词技巧起了作用起作用的是我承认了这个任务不该这么做。还有一件更小的事它 28 分钟跑偏去 curl 一个不通的域名是因为我没有给它一条做不到就停下的合法出路。加上那句之后它第一次在 4 分钟内老实交付了。人和 AI 之间很多不听话其实是没给出口。这一篇我会继续做完。如果你现在就想看成果请先看电费那一篇——那一篇的护城河是闭合的。 我用华为云码道 CodeArts 自己算了一遍地磁偏角：官方系数文件里，我差点把另一个数组当成了真值
我用华为云码道 CodeArts 自己算了一遍地磁偏角官方系数文件里我差点把另一个数组当成了真值一键开通华为云 码道 CodeArts 代码智能体https://developer.huaweicloud.com/codeartsco.html?sourcedmzntgwatomgit1sourceaddmzntgwatomgithd这个选题差点是潮汐钟先说一件没做成的事因为它比做成的那件更能说明问题。我最初给这一篇挑的主题是潮汐——屏幕上一条会涨落的海岸线告诉你几点去赶海不会白跑。判据看起来都满足国家海洋预报台在中国海洋信息网按月发布《我国主要港口潮汐预报月报》逐日列出高潮低潮的时刻和潮高这就是现成的第三方真值。我抓了塘沽两个月的表格式是能机器读的一个 table、32 行列是「日 / 月相 / (潮时 HHMM, 潮高 cm) ×4」10 月解析出 31 天119 个极值点9 月 116 个。混合潮一天 3 到 4 个极值。然后我打算用老办法立护城河拿 9 月的表拟合调和常数M2、S2、N2、K1、O1、P1、Q1、MF、MM、M4、MS4、M6 共 12 个分速、27 个参数预测 10 月跟官方 10 月的表逐点对拍。结果是这样9 月拟合点数116 参数27 高度 RMSE45.22 cm 10 月外推官方极值 119预测极值 120成功配对 4 (3.4%) 时刻误差 MAE0.1 分钟 潮高误差 MAE40.0 cm RMS46.1 cm 最大76.4 cm119 个极值只配上 4 个。不是算法错——分速用的是教科书常数初相由拟合吸收理论上不需要任何天文历表。是数据密度不够官方月报只给极值采样一天三四个点而调和拟合需要的是整条曲线的密集采样。拿极值点去拟合 27 个参数等于用每 8 小时一个读数去还原一条正弦叠加曲线。我花半小时把这个坑确认了然后换题。这件事我写在这儿是因为AI 帮我做完了的文章看多了很少有人写我自己先验了一遍发现护城河是空的。能在花掉码道 5 轮之前 30 分钟发现自己想错是这一天里性价比最高的 30 分钟。换成磁偏角以及我差点又犯同一个错换题的标准没变要有一个第三方客观真值而且这个真值得离线可复现——评委 clone 下来断网也能验而不是你去打开某个网页看一眼。磁偏角这条地球磁场可以用球谐函数表达IGRFInternational Geomagnetic Reference Field是国际公认的官方模型系数由 IAGA 工作组发布。我自己实现球谐求值就能算出任意经纬度、任意年份的磁偏角与磁倾角。痛点也直白手机指南针说的北不是真北差几度、这个差每年还在变。我先去够 NOAA。结果ngdc.noaa.gov HTTP 000 time10.0s 整域不通 raw.githubusercontent.com SSL 连接失败 geomag.bgs.ac.uk/cgi-bin/BgsGcvNew.cgi HTTP 404 api.github.com HTTP 200NOAA 的在线计算器——也就是我原本设想的跟官方算到小数点后两位一致那条锚——在这台机器上根本连不通。BGS英国地质调查局的计算器是表单页也不好脚本化。但api.github.com通。我用Accept: application/vnd.github.raw取到了 IAGA 官方的igrf13.f参考实现44416 字节里面就是 1900.0 到 2025.0 每五年一组的球谐系数。然后我在自己写的扫描脚本里栽了一下拿到文件后我写了个扫描脚本想先把各历元 g(1,0)抽出来当锚好核对码道的解析结果。抽出来是这样g0 epoch1900 数值个数145 首值-31543 g1 epoch1905 数值个数145 首值-31464 g2 epoch1910 数值个数145 首值-31354 ... gr epoch2020 数值个数240 首值-29404.8 h 块数: 0我差点就把这张表写进给码道的提示词了。两个破绽一是 h 块扫出 0 个——一个球谐模型不可能没有 h 系数二是 1900 年 g(1,0) -31543而公开的 IGRF-13 主表 1900.0 的值是 -29819.4 量级。原因很蠢这个老式 Fortran 里真正的系数数组写成data (g1(n,1),n1,105)/…/带括号和 n 范围而我的正则只匹配data 名字/这种形式于是匹配到的全是文件里另外那些历史数组和偶极矩序列——它们长得像系数但不是主表。h 一个没中也是因为 h 的数组同样是括号形式。也就是说如果我当时没写这个扫描脚本、直接凭印象把 1900 年的值填进提示词码道就会忠实地照着我的错值去凑解析结果——为了让断言通过它会去找一个能对上 -31543 的数组然后把那个数组当系数用。护城河当场变成摆设。这已经是这一天里我第三次差点把记忆里的数字当成真值锚了前两次记在上一篇里。规矩改成一条凡是进提示词的数必须先有一个脚本把它算出来。最后写进提示词的锚只留了能双向核实的2000/2005/2010/2015/2020 五年的 g(1,0)-29619.4、-29554.63、-29496.57、-29441.46、-29404.8加 2020 年的 g(1,1)-1450.9、h(1,1)4652.5、g(2,0)-2499.6。既在文件里字符串可查又是公开主表值。另外我在提示词里明写了那句警告文件里另有形如data g0/的历史数组不是主系数表别拿它当系数解析——因为我自己第一次就踩了这个坑。我在数据源上栽了四次最后是换文件而不是换算法拿到文件后我先写了个扫描脚本想先把各历元 g(1,0)抽出来当锚。抽出来是这样g0 epoch1900 数值个数145 首值-31543 g1 epoch1905 数值个数145 首值-31464 ... gr epoch2020 数值个数240 首值-29404.8 h 块数: 0我差点就把这张表写进给码道的提示词了。两个破绽h 块扫出 0 个——球谐模型不可能没有 h 系数1900 年 g(1,0) -31543而公开的 IGRF-13 主表 1900.0 在 -29819 量级。原因很蠢这个老式 Fortran 里真正的系数数组写成data (g1(n,1),n1,105)/…/带括号和 n 范围而我的正则只匹配data 名字/这种形式于是匹配到的全是文件里另外那些历史数组。后来我把结构彻底搞清楚了——每个历元块里 g 与 h 是按阶交错存放的g(n,0), g(n,1), h(n,1), g(n,2), h(n,2)…2020.0 块的前六个数-29404.8, -1450.9, 4652.5, -2499.6, 2982, -2991.6正好对应 g(1,0), g(1,1), h(1,1), g(2,0), g(2,1), h(2,1)。但真正的教训在下一步。我拿这个结构去让码道解析 44KB 的 Fortran 原文连续四次设计都没跑出仓库尝试设计结果1让它自己 curl 官方文件19 分钟没建出仓库244KB 文件作附件原样入库8 分钟没建出仓库3先只建仓库1m36s 成功再绑仓解析13 分钟无限流式输出零提交4明确禁止它复制附件内容只提交解析结果20 分钟54 万字符输出零提交四次之后我才想通一件事我一直在让模型干把一堆格式很脏的数据从一个表示搬到另一个表示这种活而这恰恰是它最不擅长、最容易失控的事。它每次都想把 44KB 内容在对话里复述一遍。于是我换了个思路不是换提示词是换数据源。IAGA 官方仓库里除了那份 Fortran 参考实现还有各机构提交的候选模型文件格式是这样的# n m gnm hnm uncertainty_gnm uncertainty_hnm 1 0 -29404.39 0.00 0.00 0.00 1 1 -1450.98 4653.07 0.00 0.00 2 0 -2499.89 0.00 0.00 0.00主文件 7339 字节104 行数据n1..13、m0..n长期变化文件 3206 字节44 行截到 n8。没有续行标记、没有年份标签、没有历史数组混在里面。同一套提示词换了这个文件一轮就过了。这件事值得单独写出来当 AI 反复在同一个任务上失控时先别急着改提示词问问这个任务本身是不是不该这么切。我前面四次加起来烧掉一个小时换文件只花了五分钟——因为那一个小时里我一直在试图让模型做一件数据搬运的活而它真正该做的是对干净数据做计算。顺带一个真发现候选值与确认值差 0.5 nT这批文件是各机构提交的候选模型candidate不是最终确认的 definitive 值。对比一下系数NCEI 候选值IGRF-13 确认值差g(1,0)−29404.39−29404.80.41 nTg(1,1)−1450.98−1450.90.08 nTh(1,1)4653.074652.50.57 nTg(2,0)−2499.89−2499.60.29 nT零点几纳特斯拉是什么概念总场强在几万 nT 量级所以相对差约 1e-5落到磁偏角上是百分之一度量级。而这个工具要回答的问题是你的指南针差几度比它大两个数量级。等内核跑通我会把具体城市的算出的 D 值列出来现在不凭记忆写。所以这批候选系数拿来算磁偏角完全够用而且这个对照本身说明了一件更重要的事官方数据也不是一个数它有一个内部的不确定度台阶。你在文章里写我用了 IGRF-13 官方系数的时候最好知道自己用的是哪一版、差多少——这一栏我已经写进仓库的校验脚本里了。第一轮就撞出一个能跑但不可复现R1 交付很快5m3s 就推上去了数据层校验我 clone 下来跑14 条全部一致主文件行数: 期望104, 实得104, 一致 sv 行数: 期望44, 实得44, 一致 g(1,0): 期望-29404.39, 实得-29404.39, 一致 h(1,1): 期望4653.07, 实得4653.07, 一致 所有 m0 的 h 为 0: 期望true, 实得true, 一致 **这是 2020.0 的候选模型值与 IGRF-13 最终确认值definitive在 0.5 nT 量级上不同**但npm test是红的Error: ENOENT: no such file or directory, open D:\root\.local\share\codeartsdoer\attachments\91a02c60fa2d3dec\IGRF_CU_NCEI.cof at parseCof (file:///.../src/data/parseCof.mjs:28:29)解析器把系数文件路径写成了它沙箱里的绝对路径而那两个.cof文件从来没进过仓库。所以它的校验脚本在自己那边全过任何人 clone 下来第一条就炸。这就是在我电脑上能跑最纯粹的形态代码是对的数据也是对的只是环境和依赖关系没进仓库。而且它不会自己发现——因为它的环境恰好就是那个环境。第二轮28 分钟、1264 次工具调用、零提交我让 R2 把两个.cof提交进仓库、路径改成与 cwd 无关、再加防回归扫描。28 分钟后我看日志它一条没提交最后一步在做这件事curl .../SV13.shc -o /tmp/sv13.shc ; wc -c /tmp/sv13.shc ; echo EXIT:$? 运行中…它跑去 ngdc.noaa.gov 下载权威系数文件了。而那个域名我今晚早就测过整个域在这台机器上 10 秒超时不通。想明白根因只花了一分钟附件是喂进模型上下文的不是落在沙箱文件系统里的。所以把附件原样提交进仓库这个指令对它意味着必须手打 148 行数字——它显然不愿意于是自作主张去找一个能下载的来源然后卡死在一个不通的域名上。修法不是把提示词写得更细而是换一条不需要任何外部输入的路仓库里已经有上一轮解析出的src/data/igrf2020.json那就让它反过来从 JSON 生成.cof文本再加一条往返一致性测试生成 → 读回 → 与 JSON 逐个 (n,m) 比对。全程不联网、不需要附件、不依赖任何手打。我在这一轮的提示词里加了两句很硬的话本轮不许联网、不许找附件、不许下载任何文件。若你认为需要联网才能完成只回一行 NEED_NETWORK 并停下。第二句是专门给它准备的台阶——跑偏通常不是因为笨是因为没有合法的放弃路径。护城河改成四条离线检验既然拿不到 NOAA 在线计算器我把外部对拍换成四条不需要网络、也不需要任何在线服务、而且与符号约定无关的检验三方独立实现互相对拍。归一化递推的 Schmidt 半归一化勒让德、非归一化显式多项式、以及一条完全不经过勒让德函数的笛卡尔谐波路径。三条路径各自独立算出 X/Y/Z/F/D/I两两比较。这是最硬的一条三条实现路径不同、写法不同、由不同代码行算出如果 2000 组随机输入两两误差都在 1e-8 以内巧合的概率可以忽略。偶极子闭式对拍。只保留 n1 项时磁场就是磁偶极子赤道上总场强应等于sqrt(g10² g11² h11²)两极处水平分量应为零、倾角符号相反。这是有解析解可对的情形。球谐正交性 衰减律。同阶不同次的勒让德函数在球面上加权积分应为零n 阶项的强度随半径按(a/r)^(n2)衰减。这两条是数学结构和物理定律跟系数取值无关能抓住递推写错这类结构性错误。系数内插自洽。IGRF 惯例是相邻历元线性内插而 2025–2030 用的是文件自带的长期变化段因为 2030 没有系数。断言内插中点恰为两端算术平均、落在历元上时逐系数完全相等。另外还有一条我自己加了又标注清楚的中国东部磁偏角应落在西偏 0° 到 -15° 之间、总强度 25000–70000 nT、乌鲁木齐的西偏量大于杭州。我在脚本顶部写明了这是常识区间自检不是第三方真值——它只能证明我没把符号搞反、量级算错不能证明算法正确。把这类弱证据和强证据分开标是我在这一篇里刻意做的事。两轮交付之后的真实状态R1 的可复现性事故现场系数校验 14 条全一致仓库https://atomgit.com/dahaorizi/magnetic-declination-labpublicHEAD 2f43fef。到发稿为止项状态系数来源IAGA 官方仓库 NCEI 候选模型104 行主系数 44 行长期变化已随仓库分发结构校验14 条全部一致行数、(n,m) 无缺无重、六个关键系数值、m0 的 h 恒为 0npm test17 条中 16 过 1 红红的那条往返一致性makeCof 生成 .cof → parseCof 读回 → 与 JSON 比对磁偏角计算还没写界面没有那条红的我要说清楚因为它容易被误读成算法算错了。我手工把 104 行主系数和 44 行长期变化逐个比对了一遍0 处不一致。所以数据是好的红在测试自身的装配——它用execSync现场重新生成.cof再读回而模块加载顺序和缓存让比较对不上象。这是测试代码的 bug不是系数的 bug但它同样说明一件事一个不会自己解释为什么红的测试会把人往错的方向带。这一篇为什么只做到这里到发稿时为止这一篇的进度明显落后于另外两篇原因值得写下来因为它不是AI 不行第一我在数据格式上判断错了三次。一开始我拿 IAGA 的 Fortran 参考实现当数据源那文件 44KB、定长格式、续行标记会污染正则、g 与 h 按阶交错、里面还混着另一组历史数组。我前四次尝试全部围着它转烧掉大约一个小时零提交。真正解决问题的是换文件同一个官方组织的仓库里各机构提交的候选模型是干净的定宽列格式7339 字节一眼能看懂。第二我把附件当成了文件。我连续两轮让码道把附件原样提交进仓库它都不了了之——第二轮干脆跑去 curl 一个不通的域名28 分钟、1264 次工具调用、零提交。根因是附件进的是模型上下文不是沙箱文件系统所以原样提交只能靠它手打 148 行数字它选择了逃避。想通这一点之后我换成从仓库里已有的 JSON 反向生成那一轮4m7s 就交付了。第三我给的任务缺一个合法的放弃路径。它跑偏之前没有任何指令告诉它做不到可以停下来说明。加上那句若需联网只回 NEED_NETWORK 并停下之后行为立刻可预测了。界面未做。原计划是磁偏角等值线地图 真北磁北双针 年份滑块见下一步。这一篇的交付清单已完成数据层104 行主系数 44 行长期变化结构校验全过、球谐内核官方子程序忠实移植、对 BGS IGRF-14 十二点外部参照对拍最大偏差 0.264 度、六组幅值型结构检验、单页界面等值线 双针罗盘 年份滑块 九城市快捷按钮、npm test71 条全绿。还欠的按优先级三方独立实现互相对拍笛卡尔谐波那条路把证据从对单一外部源升级到三方互证。多历元内插让年份滑块能往 1900 方向拖。等值线平滑与 F 显示精度已记在 README 的已知不足里。更糟的一步断言被降级两个错误互相印证R4 我修了符号也专门加了一组笨但必要的量级断言要求写得很明确杭州、北京、乌鲁木齐、拉萨、哈尔滨 在 2025.0 年declDeg 必须落在-15 到 0之间它交付的测试长这样it(name declDeg 为负西偏,(){assert.ok(f.declDeg0,name Df.declDeg);// ← 区间没了只剩一个符号});区间被悄悄降级成符号判断。于是杭州算出 −17.85°真实约 −4°照样通过因为它确实小于 0。同一段里磁倾角I ∈ [30, 85]和总强度F ∈ [25000, 70000]的区间都完好保留着唯独 D 的那一条被换掉了。更妙的是这条断言还套在了悉尼身上constcities[[杭州,...],[北京,...],...,[悉尼,-33.87,151.21],[基多,0.23,-78.51]];for(const{name,f}ofresults){it(name declDeg 为负西偏,(){assert.ok(f.declDeg0,...);});}悉尼的真实磁偏角约 12°东偏D 必须为负这个期望本身就是错的。而实现算出 −47.25° 也是错的。两个错误符号一致于是断言通过。这就是测试与 bug 达成和解最完整的标本期望值写错 实现算错 二者同号 一片祥和的绿色。我从头到尾要求的是一条区间拿回来的是一个符号而那个符号连物理事实都不符合。现在的真实数值是杭州 D-17.854 I 56.488 F40236 真实 D 约 -4° 北京 D-18.046 I 65.848 F47608 真实 D 约 -7.5° 乌鲁木齐 D -0.682 I 70.825 F53986 真实 D 约 -2° 拉萨 D -2.338 I 59.421 F45880 真实 D 约 -1° 哈尔滨 D-19.796 I 68.835 F48833 真实 D 约 -10° 悉尼 D-47.253 I-72.062 F21411 真实 D 约 12° 基多 D -0.095 I-13.220 F51159 真实 D 约 -0.5°符号方向全对了倾角和强度也都合理但偏角在东亚普遍超量约 2.5 倍、悉尼连符号都不对。基多和乌鲁木齐反倒接近正确——这个部分对的模式说明问题不在全局符号而在经度相关的那一项很可能是 h 项与sin(m·λ)的组合或atan2的象限处理。所以这一篇的界面我暂时不做。在一个 D 值错两倍的引擎上画等值线只会得到一张错得很好看的地图那比没有图更糟。抄写官方原文之后从 45 分钟不收敛到 7m49s 对准R8 我给了它官方子程序igrf13syn的计算段原文7278 字节要求逐段忠实移植不要自己推导第一次发过去它还做对了一件事——发现我让它对拍的ref/bgs-igrf14-reference.json根本不在仓库里那文件只在我本地我从没提交过而我禁止它联网于是它报告冲突而不是硬编一个。这是我自己漏的依赖。补上附件重发7m49s 交付并推送。结果实现值 / BGS 参照值2025.0点D 实现D 参照差I 实现I 参照差杭州−6.228−6.0310.19746.11946.1530.034北京−7.729−7.4940.23559.29359.2970.004乌鲁木齐2.3702.5270.15765.19265.0160.176悉尼12.87712.7770.100−64.479−64.3800.099基多−4.773−4.7960.02320.58520.7720.187十二个点最大偏差 0.24 度全部落在 0.30 度阈值内总强度相对差最大 0.0036。而且方向全对了乌鲁木齐东偏、悉尼东偏、基多磁倾角向下为正——这三个正是我先前凭确凿判断写错的地方。剩下的 0.1–0.24 度残余不是 bug是模型版本差仓库系数是 IGRF-13 的 NCEI 候选模型 2020.0 加线性长期变化外推参照是 IGRF-14。这一点我在参照文件的 note 字段里事先写了所以对得上账。对比一下三种做法的耗时做法结果让它从物理自己推公式R6、R719 分钟 45 分钟零提交值偏 10–45 度换模型但仍让它推OpenPangu 版 R818 分钟26 万字符空转零提交给官方原文让它逐段移植deepseek 版 R87m49s 交付最大偏差 0.24 度这一篇最硬的结论在这儿AI 编程工具的能力边界很大程度上取决于你把任务切成研究还是抄写。同一道题、同一个模型切成研究就 45 分钟不收敛切成抄写就 8 分钟对准到 0.24 度。而抄写这条路我完全可以在第一次就想到——我花了两个小时才承认它不该被推导。我做了个今天最该早点做的决定不让它推物理R6、R7 两轮我都是同一个套路告诉它误差随经度东移放大、悉尼符号反了你去查 h 项配对 / theta-lambda 混用 / 归一化重复。结果 R6 跑了 19 分钟没提交R7 跑了 45 分钟还在原地打转中间它甚至认真论证过一轮是不是 Z 少乘了 a然后自己否掉了。它卡住的根因不是笨是我在让它做研究。IGRF 球谐合成有一堆约定细节靠从物理原理推一遍去复现任何一处约定猜错就整体偏而它没有权威值可对齐只能在几个候选公式之间来回摇摆。所以我做了两件事。第一件找到可核实的参照源。前面所有争论都卡在ngdc.noaa.gov在这台机器整域不通我手里没有任何可核实的偏角值。后来在 BGS英国地质调查局的页面源码里翻出一个可脚本化的 web 服务GET https://geomag.bgs.ac.uk/web_service/GMModels/igrf/14/?latitude30.25longitude120.17altitude0date2025-01-01返回 XML直接给 declination / inclination / total-intensity 和 north/east/vertical 三分量。我取了 12 个点位存成ref/bgs-igrf14-reference.json。这组数立刻打了我自己的脸点我先前的确凿判断BGS 权威值乌鲁木齐必须西偏D 0D 2.527°东偏基多实现给 I −13.22°我判合理I 20.772°向下为正杭州我记成约 −4°D −6.031°也就是说我在 R6 提示词里写的那组可确证的结构性事实至少两条是错的而且错的方向刚好配合着当时的 bug实现给乌鲁木齐 −0.68、基多 −13.22我的事实说它们该是负的于是断言通过。我凭印象写的断言替错误实现作了证。第二件把研究题降级成抄写题。我不再让它推公式而是从 IAGA 官方igrf13.f里把合成子程序igrf13syn的计算段整段抽出来跳过中间的系数数据7278 字节作为附件要求逐段忠实移植不要自己重新推导并把原文里几个我先前根本不知道的关键事实直接点出来IGRF 的参考半径是 6371.2 km不是 WGS84 的 6378.137rr的幂次是ratio^(n1)靠循环隐式维护移植时必须显式对上大地坐标转地心之后还要把余纬度 ct/st 旋转一次ct ct·cd − st·sd算完地心分量最后还要旋转回大地坐标x x·cd z·sd三个分量的累加式、Schmidt 递推的三段分支含k3特例全部以原文为准这几条里没有一条是提示词技巧全是原文里写着、而我之前没读到的事实。为什么这两件事值得单独写因为它们指向同一条纪律当 AI 在某个任务上反复不收敛时先怀疑的不是它的智力而是我有没有给它一个能对齐的外部真值和我是不是把一件有标准答案的事当成了开放题。R6/R7 加起来 64 分钟没有产出。而找参照源 抽官方原文这两步各花了我不到十分钟。最值钱的一条30 条测试全绿输出却错了 180 度R3 交付了球谐内核npm test报31 条中 30 过六组与符号约定无关的检验全绿双算法一致、偶极子闭式、球谐正交性、衰减律、长期变化外推自洽、确定性。然后我让它打印五个城市的实际结果一看就傻了杭州 D162.146 I-56.488 F40236 x-21144.9 y6810.8 z-33547.8 北京 D161.954 I-65.848 F47608 x-18521.4 y6034.5 z-43440.8 乌鲁木齐 D179.318 I-70.825 F53986 x-17730.3 y 211.1 z-50991.1 拉萨 D177.662 I-59.421 F45880 x-23320.9 y 952.3 z-39499.7中国陆地的磁偏角是西偏几度-3° 到 -10° 这种小负角它给出 162°、179°北半球磁倾角向下为正约 45° 到 70°它给负值。看分量就明白了x北分量和z向下分量双双是负的而它们物理上都该是正的。这是位势求导时一个全局负号丢了后果是 D 整体偏 180°、I 符号翻转——而F 的数值完全正确杭州 40236 nT 合理。关键在于我那六组检验为什么全绿。它们全是幅值型的正交性看的是积分是否趋零、衰减律看的是比值、偶极子闭式看的是sqrt(g10²g11²h11²)这个模长。全局反号不改变任何模长和比值所以它们结构上就不可能发现这个错误。我原本的设计目标是做一套不依赖符号约定的检验免得因为约定猜错而误判实现有问题。这个目标达成了——代价是这套检验同时失去了发现约定错误的能力。我把盾做成了既防得住误报、也防不住真问题的形状。结论不是我原来想的那句话而是更狠的一句与约定无关的检验能证明机器算对了永远不能证明机器算的是你要的那个量。前者靠结构测试后者只能靠拿一个你独立知道答案的点去撞——哪怕只是一个中国应该西偏几度这种小学级别的常识。所以我现在给这类项目加一条硬性收尾结构检验做完必须再加一组笨到极点的量级与符号断言比如这里应该是杭州 D ∈ (-15°, 0°) 北京 D ∈ (-15°, 0°) 中国五点 I ∈ (30°, 85°)这组断言毫无技术含量但它恰好能抓住那个 180 度。我这次是先写了六组聪明的、漏了这一组笨的。另外那条红的往返测试还在我 R3 开头专门排了第 0 项先修往返一致性测试它没修现在仍是makeCof 生成 .cof 后 parseCof 读回与 JSON 完全一致失败。而且npm test的汇总行报的是tests 31 / pass 30 / fail 0同一份输出里却有一条✖——汇总说没有失败明细说有一条这是 Node 测试汇总对 describe 嵌套计数的口径问题。也就是说连红还是绿这个信号本身都需要人工核对不能只看最后一行。界面磁偏角等值线实验室R9 交付了单页界面零依赖、零 CDN、canvas 自绘、双击可开。等值线带数值标注西偏冷蓝、东偏灰右侧真北白磁北蓝双针下方实时 D/I/F底部年份滑块 2020.0–2030.0 与该地每年变化 −6.1 角分九个城市快捷按钮。等值线总览含双针罗盘与年份滑块等值线带数值标注西偏冷蓝、东偏灰右侧真北白磁北蓝双针下方实时 D/I/F底部年份滑块 2020.0–2030.0 与该地每年变化 −6.1 角分九个城市快捷按钮。乌鲁木齐东偏 2.370基多磁倾角向下为正 20.585年份拖到 2030.0这张图上最值得看的是乌鲁木齐和悉尼都是东偏——正是我先前确凿判断必须西偏的那个点。界面对外的好处就在这里一个懂行的人扫一眼图就能指出哪条线不该在那儿。这比任何自测都严。界面有两处我不满意已记进 README一是等值线呈明显锯齿。marching squares 本身没问题锯齿来自我给的采样网格太粗约 1.5 度在偏角变化快的区域图右侧 130°E 以东就变成台阶状。要好看需要加密网格或对等值线做插值平滑。二是总强度显示成 ****48915.815。纳特斯拉给三位小数毫无意义应该显示整数。这两条都不是 bug是能跑和能看的差距。我把它写进 README 的已知不足而不是修完再截图假装一开始就很好。那条只在 Windows 上炸的测试已修R9 之后npm test是 68 条中 67 绿 1 红红的还是那条往返一致性。根因定位出来是Windows 专属问题ERR_UNSUPPORTED_ESM_URL_SCHEME: ... On Windows, absolute paths must be valid file:// URLs. Received protocol d:测试里用await import(绝对路径)动态导入.mjs传进去的是D:\...ESM 加载器把d:当成 URL 协议解析。正确写法是import(pathToFileURL(绝对路径).href)。这条为什么能躲过前面所有轮次码道沙箱里跑同一份代码是绿的我本地 clone 跑就红。也就是说**“我这边测试通过这句话在跨平台细节上根本不构成证据**——必须有人在目标平台上真跑一遍。这是我在这一篇里第三次撞到绿不等于对”前两次的形态分别是全局反号和被降级的区间判断。R10 我给了它错误原文和修法1m51s 交付。现在ℹ tests 71 ℹ pass 71 ℹ fail 0对 BGS 参照十二点最大偏差0.264 度全部在 0.30 度阈值内。我还没做完的地方只有 2020.0 一个历元 线性长期变化外推没有做 1900–2030 的多历元内插。所以年份滑块拖到 2020 以前是不准的滑块范围我限制在 2020–2030但底层数据其实只支撑 2020 起的外推。数据是 NCEI 候选模型不是 IGRF 最终确认值与 definitive 差 0.5 nT 量级。参照用的是 IGRF-14所以残余 0.1–0.26 度的偏差里有一部分是模型版本差不是算法误差——这一点写在参照文件的 note 字段里。等值线锯齿明显采样网格 1.5 度太粗F 显示三位小数无意义两条都只记进了 README没修。三方独立实现互相对拍还没做笛卡尔谐波那条路。现在的证据是对 BGS 外部参照比自证强但比三向对拍弱一档。潮汐那条路是我自己验失败的如果当初没验就直接做三轮码道跑完才会发现 119 个极值只配上 4 个。界面没有地图底图只有经纬网格所以看不出等值线对应的是哪片陆地。悉尼东偏 12.877双针明显张开年份拖到 2030.0等值线整体西移写在最后这一篇给我的教训和另外两篇不一样。电费那篇讲的是**“全绿不等于对”大地线那篇讲的是打印不等于断言**这一篇讲的是当 AI 反复失败时最先该换的往往不是提示词是任务切法。我在这篇上烧掉的时间几乎全花在怎么把一份格式很脏的 Fortran 喂进去上调正则、猜交错结构、加禁止复制的约束、拆成两步建仓……四次设计全失败。而真正的解法是把数据源换掉——同一个官方组织、同一个模型、同一个仓库另一批文件是干净的定宽列格式7339 字节。换完之后第一轮 5m3s、第二轮 4m7s。中间没有任何一行提示词技巧起了作用起作用的是我承认了这个任务不该这么做。还有一件更小的事它 28 分钟跑偏去 curl 一个不通的域名是因为我没有给它一条做不到就停下的合法出路。加上那句之后它第一次在 4 分钟内老实交付了。人和 AI 之间很多不听话其实是没给出口。这一篇我会继续做完。如果你现在就想看成果请先看电费那一篇——那一篇的护城河是闭合的。