diff --git a/STEP_RECORD.md b/STEP_RECORD.md index 7c8e359..dba37be 100644 --- a/STEP_RECORD.md +++ b/STEP_RECORD.md @@ -4,852 +4,131 @@ Last Updated: 2026-03-31 Repo: `/root/sourceserver/pbf` Remote: `ssh://git@nas:2222/tei/pbf.git` -## Current Checkpoint +## Active Baseline -当前已经完成： +当前唯一固定使用的视觉审计页面： -- Git 远端已切换到 `nas` -- 已补交接文档： - - [`PROJECT_HANDOFF_2026-03-31.md`](/root/sourceserver/pbf/PROJECT_HANDOFF_2026-03-31.md) - - [`GIT_REMOTE_SWITCH_TO_NAS_2026-03-31.md`](/root/sourceserver/pbf/GIT_REMOTE_SWITCH_TO_NAS_2026-03-31.md) -- 已补项目协作约定文件： - - [`AGENTS.md`](/root/sourceserver/pbf/AGENTS.md) - - [`.codex/README.md`](/root/sourceserver/pbf/.codex/README.md) - - [`.codex/SESSION_START.md`](/root/sourceserver/pbf/.codex/SESSION_START.md) - - [`.codex/RESUME_PROMPT.md`](/root/sourceserver/pbf/.codex/RESUME_PROMPT.md) -- 已完成一次新的 delivery 审计，并确认哪条审计线可用 -- 已把 `Karatsu 20nm` 的最新展示页和左右对比页切到更贴近旧视觉的 compare style -- 已确认 `Karatsu 20nm` 当前“和旧版差很大”的问题，既有 style 原因，也有 delivery 数据覆盖范围与旧版上下文不一致的原因 -- 已确认 `domain-compatible` 线上“最接近旧版”的那份 style，与仓库当前同名文件并不一致 -- 已正式确定：下面开展工作的视觉复原基准线，统一使用 `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` -- 用户于本轮再次明确重定向：下一步视觉复原重新以 `/home/wwwroot/pbf-delivery-karatsu-20nm` 为目标 PBF，并继续结合 render audit 推进 +- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` -## Fixed Compare Baseline +当前页面版本体系： -从现在开始，下面开展工作的固定比较基线是： +- `HTML: compare-r10-20260331-2213` -- 页面： +当前页面支持 2 个 profile，但仍是同一张 HTML： + +1. 唐津 20 海里 + - `Style: karatsu-style-r7-20260331-2045 (style.navsea-delivery-karatsu-10nm.json)` + - `PBF: karatsu-pbf-20nm-20260325-1757 (pbf-delivery-karatsu-20nm)` + +2. 九州 + - `Style: kyushu-style-r1-20260331-2205 (style.navsea-delivery-kyushu.json)` + - `PBF: kyushu-pbf-reencoded-20260325-1105 (pbf-delivery-kyushu-reencoded)` + +访问方式： + +- 默认唐津： - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` -- 目标 PBF： - - `/home/wwwroot/pbf-delivery-karatsu-20nm` - - `http://192.168.200.184/pbf-delivery-karatsu-20nm/{z}/{x}/{y}.pbf` - -这条线的定义是： - -- 后续视觉复原统一围绕 `20nm delivery` 继续推进 -- render audit 的粗审排差，也统一以这条线配合当前对比页来使用 +- 九州模式： + - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html?profile=kyushu` 工作规则： -- 不再新增新的 compare 页面 -- 后续视觉比较统一只看上面这一张固定页面 -- 对比页必须保持左右联动和点击拾取功能可用 -- 对比页每次可见修改都必须 bump 版本号，并显示在“重新加载”按钮附近 -- 当前固定对比页版本号： - - `20nm-r7-20260331-2044` -- 这个版本号同时作为 style / tile reload 的 cache-busting 基准 +- 不再新增 compare 页面 +- 视觉确认统一只看这一个 URL +- 页面必须保持： + - 左右联动 + - 点击拾取 + - HTML / Style / PBF 三层版本可见 -## Detail PBF JP Field Inventory +## Current Truth -已对 `pbf-domain-karatsu-10nm/detail` 全量 47 个瓦片做扫描。 - -结论： - -- `detail` 包里现在仍然有日文字段 -- 不只是属性值里有日文，属性键名里也还有日文 -- 此外还有一批“标准英文键名，但值仍是日文”的追踪/语义字段 - -当前确认的“日文属性键名”如下： - -- `bathymetry_line` - - `水深値(m)` -- `facility_boundary_area` - - `分類番号` -- `facility_boundary_outline` - - `分類番号` -- `facility_boundary_point` - - `Sガイドページ` - - `分類番号` - - `名称` -- `place_label_land` - - `分類番号` - - `日本語地名` - - `縮尺選択コード` - - `英文字地名` - - `表示重要度` -- `place_label_sea` - - `分類番号` - - `日本語地名` - - `縮尺選択コード` - - `英文字地名` - - `表示重要度` -- `seabed_line` - - `分類番号` -- `seabed_text_point` - - `分類番号` - - `名称` - - `表示位置` - -另外，以下英文键名目前也仍大量承载日文值： - -- `source_layer_jp` -- `canonical_object_type` -- `render_layer` -- `semantic_key` -- `detection_key` -- `at` -- `chart_label_text` - -这说明后续“去掉 PBF 里的日文字段”不能只删日文键名，还要区分： - -- 纯追踪字段是否保留 -- 样式当前真正依赖的是哪些日文字段 -- 哪些日文值需要先有标准字段映射后才能安全移除 - -## Latest PBF Batch Discovery - -按 `/home/wwwroot` 目录修改时间梳理，当前机器上几组关键 PBF 的时间顺序是： - -- `2026-03-25 17:57:29 +0800` - - `/home/wwwroot/pbf-delivery-karatsu-20nm` - - 文件数：`154` -- `2026-03-25 11:05:38 +0800` - - `/home/wwwroot/pbf-delivery-kyushu-reencoded` - - 文件数：`7617` -- `2026-03-25 09:15:01 +0800` - - `/home/wwwroot/pbf-delivery-karatsu-10nm` - - 文件数：`59` -- `2026-03-18 10:48:30 +0800` - - `/home/wwwroot/pbf-domain-karatsu-10nm/safety` - - 文件数：`59` -- `2026-03-18 10:48:35 +0800` - - `/home/wwwroot/pbf-domain-karatsu-10nm/detail` - - 文件数：`47` - -当前判断： - -- 如果按“这台机器上最后做出来的一批唐津相关 PBF”来理解，最像的是： - - `/home/wwwroot/pbf-delivery-karatsu-20nm` -- 如果按“当前固定 compare 基线正在使用的 PBF”来理解，则是： - - `/home/wwwroot/pbf-domain-karatsu-10nm/safety` - - `/home/wwwroot/pbf-domain-karatsu-10nm/detail` - -## 20nm Delivery Current Working Baseline - -用户本轮已明确： - -- 下一步视觉复原，先按： - - `/home/wwwroot/pbf-delivery-karatsu-20nm` -- 配套左右对比页继续复用： - - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` -- 这张页面就是下面开展工作的基准线 - -当前确认： - -- 这张页面已经具备点击拾取功能 -- 点击左右任一地图对象，都可以查看： - - `source` - - `source-layer` - - `render layer` - - feature properties -- 因此这张页面可以继续作为 `20nm delivery` 线的人工视觉审查页 - -本轮生成的对比截图： - -- `/tmp/navsea-compare-karatsu-20nm-review.png` - -截图结论： - -- 右侧 `20nm delivery` 目前仍与左侧原始版差距明显 -- 差异仍主要集中在： - - `baseline / bathymetry / depth contour` - - 陆域/道路上下文层次 - - 标注与航标文本/图标 - -### 20nm Compare Page Root Cause Fix - -本轮已经定位并修正了一个关键问题： - -- 之前 `navsea-compare-karatsu-20nm.html` 右侧使用的是： - - `style.compare-delivery-karatsu-10nm.json` -- 这份 compare style 大量读取： - - `class_code` - - `display_code` - - `label_position_code_legacy` - - `depth_value_m_legacy` -- 但 `20nm delivery` 这批 PBF 实际提供的主字段是： - - `chart_*` - - `canonical_*` - - `place_name_*` - - `name_ja` - -结论： - -- 右侧此前“大面积只剩线、不见面、不见符号”的主因，是样式读取字段与 PBF 实际 schema 不匹配 - -本轮已修正： - -- [`src/pbf/navsea-compare-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-compare-karatsu-20nm.html) - - 右侧样式从： - - `./domain/style.compare-delivery-karatsu-10nm.json` - - 切回： - - `./domain/style.navsea-delivery-karatsu-10nm.json` - -修正后结果： - -- 右侧海区面、陆域面、道路和主要符号层已恢复显示 -- 当前差距虽然仍然明显，但已经从“schema 读错导致的整体失真”回到“正式 delivery style 本身与原始版仍有视觉差距”的层面 - -这意味着下一步可以更聚焦地修： - -- `style.navsea-delivery-karatsu-10nm.json` -- 而不是继续在不兼容的 compare style 上浪费时间 - -### 20nm Content-Equivalence Clarification - -关于“`20nm delivery` 和原始 `newpec` 的内容是不是一致、现在看起来不同是不是因为 style”，当前可以做如下判断： - -- 不能严格说“已经证明对象级完全一致” -- 但可以说：主要对象覆盖和实例规模是高度对应的 - -当前依据： - -- 刷新的 20nm render audit 里： - - 原始 feature 实例数 = `258317` - - delivery feature 实例数 = `258317` -- 抽样瓦片 `11/1761/821` 中，关键层实例数一一对应： - - `P基本線 = 95` ↔ `baseline_area = 95` - - `P基本線ククリ = 175` ↔ `baseline_outline = 175` - - `L海底地形 = 210` ↔ `bathymetry_line = 210` - - `L等深線 = 86` ↔ `depth_contour = 86` - - `P陸域 = 23` ↔ `land_area = 23` - -因此： - -- 从“主要几何/对象覆盖有没有带上”这个角度看，`20nm delivery` 与原始 `newpec` 是高度对应的 -- 当前视觉差距，style 的确是主因，而且是当前最值得优先修的部分 - -但仍需保留一条实话： - -- 不能把它简化成“100% 只有 style 问题” -- 因为 builder 的 mapping audit 里仍有大量： - - `render_rule_unresolved` -- 这说明 delivery 端的一些 `chart_*` 语义生成仍然存在启发式/未完全命中规则的情况 - -一句话结论： - -- 当前更接近真实情况的表述是： - - `20nm delivery` 的主要内容大体和原始版对上了 - - 当前看起来差很多，主因是 style - - 但不是已经排除所有 data / semantic 映射问题 - -### 20nm Visual Restore Round: Fishery + Nav Mark Findings - -本轮针对用户肉眼指出的两类问题做了定点排查： - -- 红圈里的港区/灯标类标识大量“看起来像丢了” -- 鱼礁/渔具定置区视觉表达明显丢失 - -当前确认： - -- 这些对象并不是没进 `20nm delivery` PBF -- 它们大多已经在瓦片里，但在样式层和部分编码层被“画错了” - -抽样瓦片： - -- `11/1763/821` -- `11/1764/821` - -确认结果： - -- 原始 `p航路標識群` 与 delivery `navigation_marks` 数量对应 -- 原始 `P漁具定置箇所` 与 delivery `fixed_fishing_gear_area` 数量对应 -- 原始 `p投錨注意障害物` 与 delivery `anchor_caution_hazard_point` 数量基本对应 - -关键诊断： - -- `fixed_fishing_gear_area` 之前只被画成了绿色半透明面 - - 这和原始 `P漁具定置箇所` 的 `fill-daytime-910` 图案填充 + 紫色边线差异很大 - - 这正是“鱼礁看起来都没了”的主因之一 -- `navigation_marks` 里大量对象被 builder 粗归并成： - - `lighthouse` - - `light_beacon` - - `buoy` -- 原始图则是按 `表示用番号` 精细区分图标 - - 例如： - - `港湾灯台` 对应 `symbol-daytime-301` - - `防波堤灯台` 对应 `symbol-daytime-302` - - `灯 (Lt)` 常见为 `symbol-daytime-303` -- delivery 之前把这些类型大量画成通用 `301 / 310` - - 所以肉眼会感觉“标识丢了”或“和原图不像” - -本轮已做的样式修复： +当前继续收敛的主 style 文件： - [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json) - - `fixed_fishing_gear_area` - - 改回 `fill-daytime-910` 图案填充 - - 新增紫色 outline，贴近原始 `P漁具定置箇所` - - `navigation_marks` - - `港湾灯台 -> symbol-daytime-301` - - `防波堤灯台 -> symbol-daytime-302` - - `灯 (Lt) -> symbol-daytime-303` - - `沿岸灯台 (15M over) -> symbol-daytime-300` - - `r4` 版本附加修复： - - 关闭 `nav-light-flare` - - 关闭 `nav-light-arc` - - 即不再显示灯塔外侧的环/扇形 - - `nav-marks / anchor-hazard-points / hazard-points` 增加 `icon-ignore-placement` - - 目的：优先保证灯塔、小灯和碍航点符号本体出图 - - `r6` 版本关键修复： - - render-based 对比确认：右侧大面积 icon 缺失不是肉眼误判 - - 根因定位为 delivery style 的 sprite 与左侧原始版不一致 - - 左侧线上原始样式使用： - - `https://tile.mapple-on.jp/newpec-symbols-20251001/sprite` - - 右侧 delivery style 原先使用本地： - - `http://192.168.200.184/newpec/sprite/sprite?v=111` - - 将 delivery style 的 sprite 切到与左侧同一套后，`r6` 渲染截图已确认： - - 灯塔/小灯/大量点图标明显恢复 - - 本轮用于机器复核的截图： - - `/tmp/navsea-compare-r6.png` - - `r7` 版本修正： - - 用户确认“不要灯塔外圈，但红绿标识仍要保留” - - 因此前一轮把 `nav-light-flare` 和 `nav-light-arc` 一起关闭属于误伤 - - 当前策略改为： - - 恢复 `nav-light-flare` - - 继续关闭 `nav-light-arc` - - 即保留红绿小标识，不恢复灯塔环/扇形 - - 当前后台审计状态补充： - - 已用当前 `r7` 样式重新跑： - - [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.r7.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.r7.md) - - 结果与前一版 `20nm refresh` 基本完全一致 - - 这说明当前 `20nm` render audit 脚本对以下问题是“盲”的： - - sprite 资源是否实际可加载 - - 浏览器里 symbol icon 是否真正渲染成功 - - 换句话说： - - 当前 20nm 后台 render audit 更像“样式表达式审计” - - 不是浏览器级最终出图审计 -### Strict Audit Unification +当前九州 delivery style： -本轮已新增统一审计脚本： +- [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json) -- [`navsea_strict_audit.py`](/root/sourceserver/pbf/navsea_strict_audit.py) -- [`strict_audit_hotspots_20nm.json`](/root/sourceserver/pbf/strict_audit_hotspots_20nm.json) +关于当前问题，已经确认： -它会把两部分合并到同一份报告里： - -- 浏览器真实出图截图差异 -- 当前 20nm backend render audit 摘要 - -但当前实际工作方式已经进一步收紧为： - -- 后台 render audit 是主审计 -- 小范围 AOI 图像审计是校准审计 -- 不再只看整屏大 diff -- 只盯后台最容易误判的热点区域： - - 航标 / 灯塔 / 红绿标识 - - 鱼礁 / 碍航点 - - 远处 symbol / 小灯 - -当前产物： - -- [strict_audit_summary.md](/root/sourceserver/pbf/report/strict_audit/strict_audit_summary.md) -- [strict_audit_summary.json](/root/sourceserver/pbf/report/strict_audit/strict_audit_summary.json) -- [compare_full.png](/root/sourceserver/pbf/report/strict_audit/compare_full.png) -- [compare_left.png](/root/sourceserver/pbf/report/strict_audit/compare_left.png) -- [compare_right.png](/root/sourceserver/pbf/report/strict_audit/compare_right.png) -- [compare_diff.png](/root/sourceserver/pbf/report/strict_audit/compare_diff.png) -- [report/strict_audit/hotspots](/root/sourceserver/pbf/report/strict_audit/hotspots) - -当前 `r7` strict audit 结论： - -- compare version: - - `20nm-r7-20260331-2044` -- visual changed ratio: - - `0.899848` -- changed pixels: - - `230361 / 256000` -- backend render audit 总体仍是： - - `extra_in_engineering = 258317` - - `missing_in_engineering = 258317` - -当前热点 AOI 排名： - -1. `southwest_lighthouse_cluster` - - changed ratio: `0.972315` -2. `takashima_main_harbor_marks` - - changed ratio: `0.783759` -3. `takashima_inner_nearshore_hazards` - - changed ratio: `0.744246` -4. `east_breakwater_marks` - - changed ratio: `0.617833` - -这份统一审计的意义是： - -- 以后不再只靠整屏图像差异判断问题 -- 可以用少量热点小框去校准后台 render audit 的盲区 -- 当用户肉眼说“这里还不对”时，可以直接把那个区域加入热点审计并复跑 - -线上已同步： - -- `/mnt/sda1/www/newpec/domain/style.navsea-delivery-karatsu-10nm.json` - -仍需继续确认/修的点： - -- `灯標` 等对象仍然只有较粗语义字段，无法仅靠当前 style 完全恢复原始 `表示用番号` 级别图标 -- 如果这轮样式修复后仍有明显“标识不像原图”的对象，下一步需要回到 builder： - - 保留/补出更细的 legacy display code - - 再重建 `pbf-delivery-karatsu-20nm` - -## 20nm Delivery JP Status - -已对 `/home/wwwroot/pbf-delivery-karatsu-20nm` 全量 `154` 个瓦片做扫描。 - -结论： - -- 这批 `20nm delivery` PBF 不是“几乎没有日文” -- 更准确地说： - - 日文字段键名已经清理得比较干净了 - - 但日文属性值仍然很多 - -当前确认： - -- 日文属性键名：`0` -- 但含日文值的字段：`139` 组 - -典型仍含日文值的字段包括： - -- `canonical_object_type` -- `detection_key` -- `semantic_key` -- `chart_label_text` -- `name_ja` -- `name_subtext_ja` -- `place_name_ja` - -典型例子： - -- `baseline_outline.canonical_object_type = P基本線ククリ` -- `bathymetry_line.canonical_object_type = L海底地形` -- `place_label_land.place_name_ja = 佐賀県 / 長崎県 / 佐賀市` -- `navigation_marks.name_ja = 長崎県大島大橋橋梁灯 / 鷹島肥前大橋橋梁灯` +- `20nm pbf` 本身最近没有被重建改坏 +- 鱼礁、灯塔、灯台等对象在 `20nm pbf` 里仍然存在 +- 当前“看起来又丢了”的主因优先判断为： + - style 表达式 / icon 选择问题 + - 不是 compare HTML 切错 + - 也不是 20nm pbf 最近重建 一句话判断： -- `20nm delivery` 已经基本摆脱“日文键名” -- 但还远没有摆脱“日文语义值” +- 当前主矛盾是 `style` +- 不是 `PBF 不见了` -## 20nm Delivery Build Chain +## Audit Method -当前已经查明，这套： +当前认可的可信审计方法： -- `/home/wwwroot/pbf-delivery-karatsu-20nm` +1. `20nm compare` 肉眼审图 +2. 小范围 AOI 图像对比 +3. compare 页点击拾取 +4. `10nm rerun` 对象级 backend audit -是由： +当前小范围试验方法文档： -- [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py) +- [`NavSea_20nm_Small_Scope_Audit_Method.md`](/root/sourceserver/pbf/NavSea_20nm_Small_Scope_Audit_Method.md) -这条交付 builder 代码链生成的。 +当前 pilot 热点配置： -直接证据： +- [`strict_audit_hotspots_20nm_pilot.json`](/root/sourceserver/pbf/strict_audit_hotspots_20nm_pilot.json) -- 存在构建审计文件： - - `/home/wwwroot/pbf-delivery-karatsu-20nm.mapping_audit.json` - - `/home/wwwroot/pbf-delivery-karatsu-20nm.mapping_audit.md` -- 其中明确记录： - - `bundle_id = navsea-core` - - `output_root = /home/wwwroot/pbf-delivery-karatsu-20nm` - - `tile_jobs = 154` - - `written_tiles = 154` +当前 pilot 报告： -代码链条： - -1. `navsea_tile_builder.py` - - 从原始 `newpec` 瓦片读取 source feature - - 从 MySQL `pbf_analysis` 库读取 `pbf_relayer_candidates` - - 通过 [`navsea_mapping_registry.py`](/root/sourceserver/pbf/navsea_mapping_registry.py) 做 source-layer / render-rule / field-name 映射 - - 输出 delivery PBF -2. `tasks/pbf/mappings/navsea_field_name_rules_v1.yaml` - - 控制哪些字段保留在 delivery -3. `NavSeaMappingRegistry` - - 控制 `source_layer_jp -> output_layer` - - 控制 render rule / field-name rule 的匹配 - -可高置信还原的构建形态是： - -```bash -./.venv/bin/python navsea_tile_builder.py \ - --center-lat 33.4425 \ - --center-lon 129.9697 \ - --radius-nm 20 \ - --zmin 0 \ - --zmax 14 \ - --output /home/wwwroot/pbf-delivery-karatsu-20nm \ - --fid-key 'thisMyWorld@2026' \ - --fid-key-id navsea-fid-key-v1 \ - --bundle-id navsea-core -``` - -说明： - -- 上面这条命令是依据 builder 参数、Karatsu 中心点、输出目录、mapping audit 结果做的高置信还原 -- 当前 shell history 里没有直接留下这次 `20nm delivery` 的完整原始命令行，所以这部分属于“高置信重建”，不是逐字历史回放 - -## Latest Audit Clarification - -关于“最新审计是否就是拿这批 PBF 做的”，需要分两层说： - -- 是： - - `2026-03-31` 确实产出了基于 `Karatsu 20nm delivery` 的审计文件： - - [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md) - - [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md) -- 但不是当前最可靠、最可采信的继续修复基线： - - 当前最可靠的仍然是： - - [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md) - -原因： - -- `20nm delivery` 这批 PBF 已经丢失了对象级回对锚点 -- 所以它可以做“看起来对不对”的粗审 -- 但不能做可信的对象级 render audit - -### 20nm Refresh Audit - -本轮已重新刷新一份 `20nm delivery` render audit： - -- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.md) -- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.json`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.json) - -刷新结果延续原判断： - -- `extra_in_engineering = 258317` -- `missing_in_engineering = 258317` - -仍然说明： - -- 这份审计可以继续作为“粗审 / 分层排查”参考 -- 但由于缺少对象级回对锚点，不能把它当成严格可信的对象级等价审计 - -当前最值得作为视觉复原优先级的 20nm 问题组： - -- `baseline_outline` / `P基本線ククリ` - - `87709` -- `baseline_area` / `P基本線` - - `50421` -- `depth_contour` / `L等深線` - - `36460` -- `bathymetry_line` / `L海底地形` - - `35940` -- `onshore_structure_line` / `L陸上構造物陸` - - `10544` -- `land_area` / `P陸域` - - `7961` - -Style 语义专项里仍最重要的是： - -- `depth_numeric_missing` on `L海底地形` - - `24168` -- `depth_numeric_missing` on `L等深線` - - `11929` -- `safety_icon_missing` on `p航路標識群` - - `1885` - -## Latest Audit Status - -### 0. Latest Visual Compare Adjustment - -已完成： - -- [`src/pbf/navsea-delivery-karatsu-20nm-latest.html`](/root/sourceserver/pbf/src/pbf/navsea-delivery-karatsu-20nm-latest.html) -- [`src/pbf/navsea-compare-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-compare-karatsu-20nm.html) - -当前这两个页面已经从： - -- `style.navsea-delivery-karatsu-10nm.json` - -切到： - -- `style.compare-delivery-karatsu-10nm.json` - -目的： - -- 先用现成的“兼容旧视觉”样式，把 20nm 右侧画面尽快拉近原始版 -- 在不强行覆盖当前 delivery style 主文件的前提下，先验证视觉方向 - -当前线上页面： - -- `http://192.168.200.184/newpec/navsea-delivery-karatsu-20nm-latest.html` -- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` - -说明： - -- 这一步优先解决“肉眼差距太大”的问题 -- 下一步仍要把有效改动逐步收敛回正式 delivery style - -### 0.1 Latest Visual Diagnosis - -这一步又补做了两轮验证： - -- 抽查 `20nm delivery` 瓦片后，确认它并非缺层；样例瓦片包含 19 个语义层，包括： - - `land_area` - - `baseline_area` - - `baseline_outline` - - `depth_contour` - - `navigation_marks` -- 使用 headless Chrome 抓取了最新左右对比页截图，确认“视觉差距大”不是猜测，而是可以稳定复现 +- [`report/strict_audit_pilot/strict_audit_summary.md`](/root/sourceserver/pbf/report/strict_audit_pilot/strict_audit_summary.md) +- [`report/strict_audit_pilot/strict_audit_summary.json`](/root/sourceserver/pbf/report/strict_audit_pilot/strict_audit_summary.json) 当前结论： -- 如果把 compare style 里的 raster 全关掉，右侧会失去旧版那种陆地道路与陆域上下文，显得过于“空” -- 如果 raster 全强度打开，又会变成偏白、偏现代的底图，看起来仍明显不像左侧原始版 -- 这说明 `20nm delivery` 的问题不是单一样式开关，而是： - - style 侧：底图强度、海陆底色、线面层级 - - data/coverage 侧：旧版陆域上下文比当前 delivery `land_area` 更完整 +- 不再只看整屏 diff +- 不再只看 `20nm` backend 总量数字 +- `20nm` backend 仍不适合当严格对象级审计 -当前已收敛到一个折中版： +## Current Audit Status -- [`src/Domain/style.compare-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/Domain/style.compare-delivery-karatsu-10nm.json) - - 背景从纯白改为海图区底色 - - raster 保留，但柔化为弱底图： - - `raster-opacity: 0.42` - - `raster-saturation: -0.45` - - `raster-brightness-min: 0.15` - - `raster-brightness-max: 0.92` - - `raster-contrast: -0.12` +### 20nm Visual Pilot -当前判断： +当前 3 个热点： -- 这版比“raster 全开”更接近旧版 -- 也比“raster 全关”更接近旧版 -- 但它仍只是过渡收敛，不是最终解决 +1. `takashima_main_harbor_marks` + - changed ratio: `0.783759` +2. `takashima_inner_nearshore_hazards` + - changed ratio: `0.744246` +3. `east_breakwater_marks` + - changed ratio: `0.617833` -### 0.2 Domain-Compatible Baseline Discovery +这说明： -今天又确认了一个非常关键的事实： +- 视觉仍然没有收敛到“可推广”状态 +- 主港航标区仍是第一优先级观察点 -- 用户指出最接近旧版的是： - - `http://192.168.200.184/newpec/domain/navsea-compare-legacy-domain-compatible.html` -- 这张页面右侧使用的是： - - `style.domain-legacy-compatible-karatsu-10nm.json` -- 但线上 deployed 的这份 style，和仓库当前的同名文件并不是同一份内容 +### 10nm Object-Level Backend Audit -当前已确认的差异方向： - -- 线上 deployed 版仍大量保留旧样式风格： - - legacy layer id - - legacy 字段名 - - 例如 `分類番号`、`英文字地名`、`日本語地名` -- 仓库当前版则已经 recode 成标准命名： - - `class_code` - - `place_name_en` - - `place_name_ja` - -这意味着： - -- “最接近旧版”的那张图，并不是我们最近在调的 `delivery compare style` -- 它本质上更接近“旧样式最小改动映射到 Domain PBF”的验证线 -- 这也是为什么直接沿着 `20nm delivery + compare-delivery style` 去调，视觉上总对不上用户记忆里的“最佳版本” - -为避免这个基线丢失，已经把线上 deployed 版快照回收到仓库： - -- [`src/Domain/style.domain-legacy-compatible-karatsu-10nm.deployed-2026-03-31.json`](/root/sourceserver/pbf/src/Domain/style.domain-legacy-compatible-karatsu-10nm.deployed-2026-03-31.json) - -后续视觉回归时，应该优先把它当成“最接近旧版的真实基线”来对照，而不是只看仓库当前的 recode 版本。 - -### 1. Karatsu 20nm delivery - -已产出： - -- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md) -- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md) - -当前判断： - -- 这两份结果不能直接作为真实对象级审计依据 -- 原因是 `/home/wwwroot/pbf-delivery-karatsu-20nm` 里的交付瓦片已经没有： - - `fid` - - `fid_legacy_raw` - - `source_layer_jp` -- 现有审计脚本失去对象回对锚点后，会出现全量： - - `missing_in_engineering` - - `extra_in_engineering` - -结论： - -- `20nm delivery` 现在是“可交付口径”，但不是“可审计口径” - -### 2. Karatsu 10nm delivery - -已产出： - -- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md) -- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.json`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.json) - -这次使用了可回对口径： - -- `--fid-key 'thisMyWorld@2026'` -- `--match-on-fid-only` - -审计结果： - -- `exact_match`: `118747` -- `mismatch`: `12721` -- `missing_in_engineering`: `3304` -- `extra_in_engineering`: `3299` - -当前可采信判断： - -- `Karatsu 10nm delivery` 是当前最可靠的继续修复基线 - -## Highest-Priority Problem Groups - -按当前 10nm 审计结果，优先处理： - -1. `baseline` 相关 - - `P基本線ククリ` - - `P基本線` - - `L基本線` - -2. `depth / bathymetry` 相关 - - `L等深線` - - `L海底地形` - - `depth_numeric_missing` - -3. `navigation marks` 相关 - - `p航路標識群` - - `safety_icon_missing` - -## Concrete Next Step - -下次继续时，建议按这个顺序推进： - -- 固定只用： - - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` - 作为唯一视觉基线 -- 固定只用： - - `/home/wwwroot/pbf-delivery-karatsu-20nm` - 作为当前 delivery PBF -- 先围绕 strict audit 热点逐组修： - - `southwest_lighthouse_cluster` - - `takashima_main_harbor_marks` - - `takashima_inner_nearshore_hazards` - - `east_breakwater_marks` -- 每修一轮就重跑： - - [`navsea_strict_audit.py`](/root/sourceserver/pbf/navsea_strict_audit.py) -- 目的不是追求整屏 diff 立刻变小，而是让后台 render audit 对热点问题的判断逐步和肉眼一致 - -当前真正的下一步是： - -- 把用户指出的新问题优先落进热点 AOI -- 用热点截图和点击拾取结果对照右侧实际图层与属性 -- 再决定是继续修 [`style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)，还是回到 builder 补更细的 delivery 语义字段 - -## Important Notes - -- 当前仓库工作区仍然不是干净状态，存在其他未提交改动 -- 继续提交时必须只暂存本次修改文件 -- `nas` 主机名在这台机器上已经可用，但依赖本机： - - `/etc/hosts` - - `~/.ssh/known_hosts` - -## Delivery Field Policy - -本轮已进一步明确字段处置原则： - -- 总目标： - - `尽可能减少日文` -- 处理策略不是“一律删除”，而是区分： - - 业务语义字段 - - 审计/追踪字段 - -当前建议： - -- `canonical_family` - - 保留 - - 已经是英文值，例如 `surface` -- `canonical_object_type` - - 不直接删除 - - 改成稳定英文值 - - 例如： - - `P陸域 -> land_area` -- `semantic_key` - - 若进入正式交付版，优先删除 - - 若保留在审计版，则值也必须改成英文 - - 例如： - - `source:P陸域 -> source:land_area` -- `detection_key` - - 若进入正式交付版，优先删除 - - 若保留在审计版，则值也必须改成英文 - - 例如： - - `surface:P陸域 -> surface:land_area` - -因此当前项目对这类字段的理解是： - -- `有业务语义的字段尽量英文化` -- `纯审计追踪字段尽量从 release PBF 删除` -- `如果 audit PBF 仍要保留追踪字段，也不能再保留日文值` - -## Karatsu 10nm Rerun Checkpoint - -本轮已按当前 builder 代码，重新构建： - -- `/home/wwwroot/pbf-delivery-karatsu-10nm` - -实际构建命令： - -```bash -./.venv/bin/python navsea_tile_builder.py \ - --center-lat 33.4425 \ - --center-lon 129.9697 \ - --radius-nm 10 \ - --zmin 0 \ - --zmax 14 \ - --output /home/wwwroot/pbf-delivery-karatsu-10nm \ - --fid-key 'thisMyWorld@2026' \ - --fid-key-id navsea-fid-key-v1 \ - --bundle-id navsea-core -``` - -构建结果： - -- `tile_jobs = 59` -- `wrote = 59` -- `skipped = 0` -- 最新 mapping audit： - - `/home/wwwroot/pbf-delivery-karatsu-10nm.mapping_audit.json` - - `/home/wwwroot/pbf-delivery-karatsu-10nm.mapping_audit.md` - -线上可直接查看： - -- 最终交付页： - - `http://192.168.200.184/newpec/navsea-final-delivery-karatsu-10nm.html` -- 瓦片： - - `http://192.168.200.184/pbf-delivery-karatsu-10nm/{z}/{x}/{y}.pbf` - -本轮还补跑了一份可回对的对象级 render audit： +当前最可信的对象级 backend 审计报告： - [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.md) - [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.json`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.json) -这次口径仍然是： - -- `--fid-key 'thisMyWorld@2026'` -- `--match-on-fid-only` - 当前结果： - `exact_match = 121855` - `mismatch = 12912` - `missing_in_engineering = 5` -- `extra_in_engineering = 0` 这说明： -- 10nm 当前这次重建后的对象规模与原始版是一一对上的 -- 旧版那种成千上万 `missing/extra` 的问题当前不再是主要矛盾 -- 现在 10nm 更像是“视觉/语义 mismatch 修复”阶段，而不是“对象丢失/多出”阶段 +- 当前 10nm 已经不是“对象大面积丢失/多出”的阶段 +- 现在主要是 visual / semantic mismatch 修复 -当前仍然最大的 mismatch 组： +当前 mismatch 最大几组： - `P基本線ククリ = 7873` - `P基本線 = 2876` @@ -858,277 +137,57 @@ Style 语义专项里仍最重要的是： - `p投錨注意障害物 = 374` - `p航行危険障害物 = 296` -本轮抓取的页面实渲染截图： +## Delivery Field Policy -- `/tmp/navsea-final-delivery-karatsu-10nm-20260331.png` +总目标： -## Visual Audit Baseline Clarification +- `尽可能减少日文` -用户本轮再次明确： +当前字段处置规则： -- 视觉审计仍然固定使用： - - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` +- `canonical_family` + - 保留 + - 已经是英文 -这意味着： +- `canonical_object_type` + - 不直接删除 + - 改成稳定英文值 -- `20nm compare` 继续是唯一视觉审计基线 -- 本轮重建的 `10nm` 结果只用于： - - builder 验证 - - 对象级 backend render audit -- 不能因为 `10nm` 审计更严格，就把视觉基线自动切走 +- `semantic_key` + - 正式 release PBF 优先删除 + - audit 版若保留，也改成英文值 -后续默认分工： +- `detection_key` + - 正式 release PBF 优先删除 + - audit 版若保留，也改成英文值 -- `20nm compare` - - 肉眼审图 - - 点击拾取 - - AOI 热点校准 -- `10nm rerun` - - 严格对象级 render audit - - 检查 `missing / extra / mismatch` +一句话： -## Small Scope Image Audit Pilot +- 业务语义字段英文化 +- 审计追踪字段从正式交付版尽量移除 -本轮已把“小范围图像对比测试”正式跑通，目的有两个： +## Current Priority -- 整理出当前继续收敛的唯一 `style.json` -- 建立一个更可信的视觉审计方法 +当前继续修的优先顺序： -当前固定的 style source of truth： +1. 鱼礁 / 障害点 icon 表达 +2. 灯 / 灯台 / flare 表达 +3. `baseline` 相关 mismatch +4. 九州沿用同一张 compare 页后的热点审计 -- [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json) +如果 style 修到一定程度仍然不对，再回到 builder 看： -虽然名字里仍是 `10nm`，但当前 `20nm compare` 右侧实际就是用它，因此： +- 是否需要补更细的 delivery 语义字段 -- 后续继续收敛这一个 delivery style 文件 -- 不再新增新的主 delivery style 文件来分散口径 - -本轮新增的小范围热点配置： - -- [`strict_audit_hotspots_20nm_pilot.json`](/root/sourceserver/pbf/strict_audit_hotspots_20nm_pilot.json) - -它只保留 3 个最代表当前问题的热点： - -1. `takashima_main_harbor_marks` -2. `takashima_inner_nearshore_hazards` -3. `east_breakwater_marks` - -试验版输出： - -- [`report/strict_audit_pilot/strict_audit_summary.md`](/root/sourceserver/pbf/report/strict_audit_pilot/strict_audit_summary.md) -- [`report/strict_audit_pilot/strict_audit_summary.json`](/root/sourceserver/pbf/report/strict_audit_pilot/strict_audit_summary.json) -- [`report/strict_audit_pilot/hotspots`](/root/sourceserver/pbf/report/strict_audit_pilot/hotspots) - -本轮 pilot 结果： - -- `takashima_main_harbor_marks` - - changed ratio: `0.783759` -- `takashima_inner_nearshore_hazards` - - changed ratio: `0.744246` -- `east_breakwater_marks` - - changed ratio: `0.617833` - -当前判断： - -- 这 3 个热点足够小，也足够稳定 -- 它们比整屏 diff 更适合指导 style 迭代 -- 其中： - - `takashima_main_harbor_marks` 适合作为第一主观察点 - - `east_breakwater_marks` 适合作为回归保护点 - -本轮也补了一份方法文档： - -- [`NavSea_20nm_Small_Scope_Audit_Method.md`](/root/sourceserver/pbf/NavSea_20nm_Small_Scope_Audit_Method.md) - -当前认可的“可信审计方法”是： - -- `20nm compare` 肉眼审图 -- 小范围 AOI 图像对比 -- compare 页点击拾取 -- `10nm rerun` 对象级 backend audit - -而不是： - -- 只看整屏图像 diff -- 或只看 `20nm` backend 总量数字 - -## 20nm Regression Root Cause Check - -本轮用户再次反馈： - -- 当前 `20nm compare` 右侧看起来又有退化 -- 主要体感是： - - 鱼礁丢了 - - 灯的标识又丢了 - -本轮已做排查，结论是： - -- 当前问题不是最近重建 `20nm pbf` 导致的 -- 也不是 compare HTML 最近又被切到了别的页面 -- 当前最应优先怀疑的是： - - `style.navsea-delivery-karatsu-10nm.json` 里的图标/过滤表达式 - -排查依据： - -1. 线上部署时间 - - `/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html` - - `2026-03-31 20:45:52 +0800` - - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-karatsu-10nm.json` - - `2026-03-31 20:45:52 +0800` - - `/home/wwwroot/pbf-delivery-karatsu-20nm` - - `2026-03-25 17:57:29 +0800` - -2. 这说明 - - `20nm pbf` 没有在这之后被重新构建 - - 当前线上 compare 仍然是 `r7` - - 当前右侧仍然使用： - - `./domain/style.navsea-delivery-karatsu-10nm.json` - -3. 直接解码当前 20nm 瓦片后确认： - - 鱼礁对象还在 - - 灯塔/灯台对象还在 - -典型样本： - -- `/home/wwwroot/pbf-delivery-karatsu-20nm/11/1762/821.pbf` - - `anchor_caution_hazard_point` - - 存在： - - `canonical_object_type = 魚礁` - - `chart_symbol_code = fish_reef` - - `navigation_marks` - - 存在： - - `canonical_object_type = 港湾灯台` - - `chart_symbol_code = lighthouse` - - `name_ja = 鷹島灯台` - -因此当前判断： - -- `鱼礁/灯标对象并没有从 20nm pbf 里消失` -- `HTML` 这边也没有把页面切错 -- 问题主要在当前 delivery style 的具体表达方式 - -当前 style 里和这两组最相关的层： - -- 鱼礁 / 障害点： - - `anchor-hazard-points` - - `anchor-hazard-points-428` - - `fishery-areas` - - `fishery-areas-outline` -- 灯 / 灯台： - - `nav-light-flare` - - `nav-light-arc` - - `nav-marks-harbor-lighthouses` - - `nav-marks-breakwater-lighthouses` - - `nav-marks-small-lights` - - `nav-marks-light-beacons` - - `nav-marks` - -当前最值得注意的一点： - -- 鱼礁点目前在 style 里被并到： - - `anchor-hazard-points-428` - - 统一使用： - - `symbol-daytime-428` -- 这很可能就是“数据还在，但视觉上不像原图、看起来像丢了”的直接原因之一 - -一句话结论： - -- 这轮退化不是最近改坏了 `20nm pbf` -- 主问题仍然是当前 `style.navsea-delivery-karatsu-10nm.json` -- 下一步应继续优先修： - - 鱼礁 icon 选择 - - 灯/灯台图标和 flare 的具体表达 - - 而不是先回头怀疑 HTML 或重新构建 20nm pbf - -## Same Compare Page For Kyushu - -用户已明确： - -- 继续使用同一张 compare 页做视觉确认 -- 不新增新的 compare 页面 - -本轮已将： +## Key Files +- [`AGENTS.md`](/root/sourceserver/pbf/AGENTS.md) +- [`STEP_RECORD.md`](/root/sourceserver/pbf/STEP_RECORD.md) - [`src/pbf/navsea-compare-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-compare-karatsu-20nm.html) - -升级为“同一张页面支持区域切换”。 - -当前行为： - -- 默认仍是： - - `唐津 20 海里` -- 同页新增： - - `九州` - -当前线上页面仍是： - -- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` - -但现在支持： - -- 默认： - - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` -- 九州模式： - - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html?profile=kyushu` - -页面可见版本号已提升为： - -- `20nm-r8-20260331-2208` - -本轮也已把九州 style 对齐到当前唐津 `r7`/`r8` 这套表达： - +- [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json) - [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json) - -当前这份九州 style 的关键变化： - -- sprite 已不再沿用旧本地 sprite -- 直接对齐当前唐津 delivery style 的图层表达 -- 只保留： - - `name = NavSea Delivery Kyushu` - - 九州 tile URL： - - `http://192.168.200.184/pbf-delivery-kyushu-reencoded/{z}/{x}/{y}.pbf` - -线上已部署： - -- `/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html` -- `/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json` - -一句话理解： - -- 以后还是用同一个 compare URL -- 只是这张页面现在能切： - - 唐津 20 海里 - - 九州 - -### Compare Page Version Visibility - -本轮继续增强了同一张 compare 页的版本可见性。 - -当前页面不再只显示一个模糊的“总版本号”，而是拆成 3 个层级： - -- `HTML` -- `Style` -- `PBF` - -也就是页面顶部现在可见： - -- `HTML: compare-r10-20260331-2213` -- `Style: ...` -- `PBF: ...` - -当前规则： - -- 唐津模式显示： - - `Style: karatsu-style-r7-20260331-2045 (style.navsea-delivery-karatsu-10nm.json)` - - `PBF: karatsu-pbf-20nm-20260325-1757 (pbf-delivery-karatsu-20nm)` -- 九州模式显示： - - `Style: kyushu-style-r1-20260331-2205 (style.navsea-delivery-kyushu.json)` - - `PBF: kyushu-pbf-reencoded-20260325-1105 (pbf-delivery-kyushu-reencoded)` - -这样后续视觉确认时，不需要再猜“页面到底连的是哪套 style / pbf”。 +- [`NavSea_20nm_Small_Scope_Audit_Method.md`](/root/sourceserver/pbf/NavSea_20nm_Small_Scope_Audit_Method.md) ## Quick Resume Prompt -下次开机如果要快速接上，可以先看这份文件，再按下面这句继续： - -`继续处理 STEP_RECORD.md 里记录的 20nm 固定 compare 基线，围绕 navsea-compare-karatsu-20nm.html 这一个页面和 pbf-delivery-karatsu-20nm 这套 PBF，按 strict audit 的热点 AOI 逐组修视觉问题，并用小范围图像审计去校准后台 render audit。` +`继续围绕同一个 compare 页 navsea-compare-karatsu-20nm.html 修 delivery style。默认先看唐津 profile，按 pilot 热点先修鱼礁和灯标；需要看九州时就在同一张页面切到 kyushu profile。视觉确认用 20nm compare，严格对象级 backend 审计看 10nm rerun。`