pbf/NavSea_Audit_Logic_And_Evolution_2026-04-01.md

# NavSea Audit Logic And Evolution

Last Updated: 2026-04-01

## Goal

这份文档统一说明两件事：

1. 当前 `pbf` 项目应该采用什么审计口径
2. 审计方法是如何一步步升级到现在这个状态的

当前最重要的原则只有一条：

- 审计第一优先级不是“看起来像不像”
- 而是“不能丢对象”

只有对象保真先过关，后面的渲染审计和视觉复原才有意义。

## Current Audit Order

当前正式口径按下面 3 层执行，顺序不能反过来。

### 1. Object Preservation Audit

目标：

- 先判断原始对象有没有在 delivery / final 里被等价保留下来
- 优先抓：
  - `missing object`
  - `wrong relayer`
  - `over-merged object`
  - `raw class lost`

判断标准：

- 优先用 `fid`
- 没有 `fid` 时，再退回 `geometry + stable legacy properties`
- 至少要保留：
  - 原始 `source_layer`
  - 原始危险物/航标细分类
  - 能追回原始对象的锚点

这是“硬门槛”：

- 如果对象已经丢了
- 或者对象被归并成别的对象
- 那么不允许进入“渲染已通过”的判断

### 2. Render Audit

目标：

- 在“对象没丢”的前提下，检查它有没有被正确渲染

重点看：

- icon 是否存在
- text 是否存在
- fill / line / outline 是否存在
- source-layer 是否消费正确
- style layer 是否命中正确

这一层回答的是：

- 原始版渲染了多少对象
- 现在渲染了多少对象
- 哪些对象从“有 icon/text”变成了“没有”

### 3. Visual / AOI Audit

目标：

- 用固定页面和固定热点去验证“现在具体是怎么画出来的”

当前固定页面：

- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`

这一层只做两件事：

- 校准 backend render audit 的盲区
- 验证 style 修改是否真的把用户看到的问题修掉了

这一层不能替代前两层。

## Current Ground Truth

截至 2026-04-01，当前项目的真实状态是：

### A. 20nm Visual Baseline

固定视觉审计页：

- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`

用途：

- 肉眼确认
- 点击拾取
- AOI 热点截图审计

它是当前唯一固定的视觉基线。

### B. 10nm Object-Level Backend Baseline

当前最可信的对象级 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)

原因：

- 这条线还能较可靠地对象回对
- `missing / extra / mismatch` 的意义相对稳定

### C. 20nm Backend Audit Limitation

当前 `20nm` backend render audit 能提供信号，但不能独立作为严格对象级放行依据。

它能告诉我们：

- 哪一层整体有问题
- 哪类 icon/text 大量不一致

但它不能稳定告诉我们：

- 某一个具体 `fid` 是否等价保留下来了

例如：

- `icon_missing_in_engineering | p航行危険障害物 | 664`
- `extra_icon_in_engineering | navigation_hazard_point | 664`

这说明“这一层出问题了”，但不能自动定位到：

- `fid=13025299` 这种具体对象为什么消失

### D. Current 20nm Object-Preservation Entry Point

当前已经补上一条专门的对象保真审计：

- [`navsea_object_preservation_audit.py`](/root/sourceserver/pbf/navsea_object_preservation_audit.py)

当前最重要的结论是：

- 旧 `delivery_20nm` 的危险物对象虽然几何还在，但原始 `分類番号` 全部丢失
- 当前 `final_20nm` 的危险物对象和原始 `分類番号` 已经完整保留下来

代表报告：

- [`report/object_preservation_20nm/object_preservation_delivery_20nm.md`](/root/sourceserver/pbf/report/object_preservation_20nm/object_preservation_delivery_20nm.md)
- [`report/object_preservation_20nm/object_preservation_final_20nm.md`](/root/sourceserver/pbf/report/object_preservation_20nm/object_preservation_final_20nm.md)

## Audit Evolution

下面是审计方法升级到现在的过程。

### Phase 0: General Engineering Audit

最早主要是：

- 原始版 vs engineering 版
- 看总体 render compatibility

代表报告：

- [`NavSea_Original_vs_Engineering_Render_Audit_Karatsu_10nm.md`](/root/sourceserver/pbf/NavSea_Original_vs_Engineering_Render_Audit_Karatsu_10nm.md)
- [`NavSea_Original_vs_Engineering_Render_Audit_Kyushu.md`](/root/sourceserver/pbf/NavSea_Original_vs_Engineering_Render_Audit_Kyushu.md)

这一阶段解决的是：

- 整体链路能不能跑
- 原始 layer 和工程 layer 有没有大体对上

问题：

- 太偏“工程验证”
- 还不是 delivery 收口口径

### Phase 1: Delivery Render Audit

开始转向：

- 原始版 vs 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_20nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md)

这一阶段的升级点：

- 开始看真正 delivery 产物
- 开始统计：
  - `exact_match`
  - `mismatch`
  - `missing_in_engineering`
  - `extra_in_engineering`

问题：

- `20nm delivery` 这条线在去旧字段后，trace-back anchor 不够
- 所以 `20nm` 很快变成“层级粗审可用，对象精审不稳”

### Phase 2: FID-Only / Refresh Variants

为了继续挤出更多对象级信息，出现了几种变体：

- `fidonly`
- `refresh`
- `r7`

代表报告：

- [`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_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.r7.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.r7.md)

这一阶段的升级点：

- 尽量靠 `fid`
- 尽量把样式改动后的 20nm 页面状态也纳入

问题：

- 仍然是“20nm 全局层级信号大于对象级信号”
- 能看出层整体有问题，但很难直接精确锁到某个对象

### Phase 3: 10nm Rerun As Trusted Backend Baseline

这是一次关键收口。

代表报告：

- [`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)

这一阶段的升级点：

- 明确承认：
  - `20nm` 不是当前最可信对象级 backend baseline
  - `10nm rerun` 才是

意义：

- 后端对象级判定终于有了一条相对稳定的参考线

局限：

- 它解决的是“对象级 backend 可信度”
- 不能代替 `20nm compare` 的视觉确认

### Phase 4: Unified Strict Audit

为了解决“后台数字和肉眼感受不一致”，引入了 strict audit。

核心脚本：

- [`navsea_strict_audit.py`](/root/sourceserver/pbf/navsea_strict_audit.py)

代表报告：

- [`report/strict_audit/strict_audit_summary.md`](/root/sourceserver/pbf/report/strict_audit/strict_audit_summary.md)
- [`report/strict_audit_final_20nm/strict_audit_summary.md`](/root/sourceserver/pbf/report/strict_audit_final_20nm/strict_audit_summary.md)

这一阶段的升级点：

- 把浏览器真实截图差异
- 和 backend render audit 摘要
- 放进同一份报告

问题：

- 一开始还是偏整屏 diff
- 太粗，不能指导具体修复

### Phase 5: Small Scope AOI Audit

这是最近一次重要升级。

方法文档：

- [`NavSea_20nm_Small_Scope_Audit_Method.md`](/root/sourceserver/pbf/NavSea_20nm_Small_Scope_Audit_Method.md)

热点配置：

- [`strict_audit_hotspots_20nm_pilot.json`](/root/sourceserver/pbf/strict_audit_hotspots_20nm_pilot.json)
- [`strict_audit_hotspots_20nm.json`](/root/sourceserver/pbf/strict_audit_hotspots_20nm.json)

这一阶段的升级点：

- 不再只看整屏 diff
- 改成看固定热点 AOI
- 每个热点绑定 backend focus

意义：

- 更适合修 style
- 更适合校准 icon/text/sprite/runtime 盲区

当前问题：

- 热点覆盖还不全
- 例如 `荒曽根/大曽根` 这块危险物区当前就不在热点里

## Why Serious Missing-Object Issues Still Escaped

像 `fid=13025299` 这种“左边有、右边没有等价对象”的情况，之所以还能漏过，是因为当前审计仍有 3 个盲点。

### 1. 20nm Backend Audit Is Layer-Level, Not Fid-Level Enough

它会报：

- 这一层整体少了 icon
- 这一层整体多了 icon

但不自动报：

- 哪个 `fid`
- 哪个 `class_code`
- 是“丢对象”还是“错误归并”

### 2. Hazard Semantics Are Too Coarse In Builder

当前 builder 对：

- `p航行危険障害物`
- `p投錨注意障害物`

的语义推断太粗，很多对象只剩：

- `fish_reef`
- `wreck`
- `obstruction`
- `hazard_mark`

这会导致原始 `409` 这种细分类在 delivery 线中失真。

### 3. AOI Visual Audit Coverage Is Incomplete

当前热点更偏：

- 高岛主港
- 高岛近岸
- 东侧防波堤

还没有覆盖：

- `荒曽根 / 大曽根` 这类危险物密集区

## Current Official Audit Logic

从现在开始，项目内应统一采用下面这套逻辑。

### Audit Gate 1: Object Preservation Gate

必须回答：

- 原始对象是否还在
- 是否仍能等价追踪
- 是否被错误归并成别的对象

建议新增专项：

- `hazard object preservation audit`
  - 按 `fid`
  - 按原始 `source_layer`
  - 按原始 `分類番号`

### Audit Gate 2: Render Gate

只有对象保真过了，才进入这层。

必须回答：

- 原始渲染了多少对象
- 现在渲染了多少对象
- 哪些对象有 icon/text/fill/line 差异

### Audit Gate 3: AOI Visual Gate

最后才是：

- 固定 compare 页
- 固定 AOI 热点
- 点击拾取核对

目的：

- 验证用户肉眼看到的问题是否已经真的修掉

## Recommended Next Upgrade

当前最该补的不是新的 style，而是新的审计能力。

建议下一步按这个顺序升级：

1. 新增 `hazard preservation audit`
   - 专门检查：
     - `p航行危険障害物`
     - `p投錨注意障害物`
   - 输出：
     - 原始 `fid`
     - 原始 `分類番号`
     - delivery `class_code`
     - 是否 still equivalent

2. 增加 `fid watchlist audit`
   - 可以直接追像 `13025299` 这种 fid
   - 输出 raw / delivery / final 的对照

3. 扩充 AOI 热点
   - 把 `荒曽根 / 大曽根` 危险物区加入热点配置

4. 最后再改 builder
   - 为 `409` 这类对象增加显式保真规则

## Current One-Sentence Rule

当前项目的正式审计规则可以压成一句话：

- 先审“对象有没有丢”，再审“渲染有没有错”，最后才审“视觉像不像”。