# 架构说明:这不只是一个检查清单

面向开发者与懂行的读者。如果你只想用它审自己的网站,看 [README](README.md) 就够了;这份文档讲的是**为什么这样设计**。

---

## 市面 AdSense 审核工具的两个结构性缺陷

几乎每一个同类工具都栽在同样两处:

1. **判定只是一个词。**「不合格」这三个字,没告诉你这个判断有多确定、对过审的实际威胁有多大、修复起来有多贵——这些本是不同的维度,却被糊成了一个词。站长拿到一个标签,却不知道该先动哪个、哪个是致命的、哪个举手就能改。

2. **完整性靠嘴上说。** 工具告诉模型「请检查每一项」,然后寄希望于它照做。它到底查全了没有,无法验证。模型可以悄悄跳过一条最麻烦的要求,而没有人会发现。

本项目在协议层解决这两个问题。

## 解法一:判断向量,而非标签

每条要求不产出一个词,而产出一个 `AUDIT_JUDGE_v1` 记录——五个维度,全部在 `[0.00, 1.00]` 区间、统一极性,外加一个明确判定:

| 维度 | 含义 | 极性 |
|---|---|---|
| `cmp` | 合规度(compliance) | 越高越合规 |
| `evd` | 证据质量(evidence) | 越高证据越足 |
| `cer` | 确定性(certainty) | 越高越确定 |
| `imp` | 过审影响(impact) | **越低越致命** |
| `fix` | 修复成本(fix cost) | 越高越好修 |

每个判定背后的「为什么」都成了可量化、可复算、可争议的数字。而且这五个数直接决定了**修复排期**:`imp` 低(致命)且 `fix` 高(好修)的问题排最前——「既卡审核又好修」的先搬走。判断向量在这里的落地价值,就是一张按性价比排序的修复清单,而不是一堆抽象分数。

判定与向量之间有强制的自洽约束:`PASS` 要求 `cmp ≥ 0.5`,`BLOCKER` 要求 `cmp < 0.5`——边界值 0.5 归 `PASS` 一侧,两个判定的合法区间互斥,不存在一个 `cmp` 值同时兼容两种判定。证据或确定性太低时,判定必须是 `UNKNOWN` 并说明缺什么访问权,而不能给一个心存侥幸的 `PASS`。

完整字段定义与判定集合见 [`skill/references/judgment-schema.md`](skill/references/judgment-schema.md)。

## 解法二:屏障聚合,而非平均

站点级结论遵循 I-Lang v5.0 的**屏障原则**:任何一个 `BLOCKER`(阻断项)一票否决整个申请,无论其他项分数多高。

这是刻意的。如果用加权平均,一个致命的硬性违规(比如 robots.txt 挡住了 Google 爬虫)会被一堆通过项稀释成一个「还不错」的总分——而现实里,那一条就足以让整个申请被拒。**平均值永远无法把一个硬性违规洗白;屏障可以保证它一票否决。**

聚合规则:

- 有任何 `BLOCKER` → `NOT_READY`
- 有任何 `HIGH`/`MEDIUM`/`UNKNOWN`(无阻断项) → `READY_AFTER_FIXES`
- 全部 `PASS`/`NA` → `READY`

## 解法三:完整性由代码强制,而非靠自觉

[`validator/audit_validator.py`](validator/audit_validator.py)(纯标准库,零依赖)做三件事:

1. **完整性:** 解析要求清单,检查审核报告是否**恰好覆盖每一个 ID 一次**——不多不少。漏掉一条要求不是「疏忽」,是一个非零退出码。
2. **schema 一致性:** 校验每条判断记录的五个维度都在合法区间,判定与向量自洽。
3. **屏障一致性:** 验证站点级结论确实由各条判定按屏障规则推导而来,而不是模型随手写的。

```bash
python3 validator/audit_validator.py --template > report.json   # 生成覆盖全部 ID 的空白骨架
python3 validator/audit_validator.py --check report.json        # 强制校验,非零退出=不合格
python3 validator/audit_validator.py --selftest                 # 验证工具本身
```

这一层是把本项目和「模型可以偷偷少填的清单」区分开的**结构性保证**。审核不是「觉得查完了」就结束,而是闸门通过才算完成。

事实来源只有一个文件:闸门从 `requirements.md` 里提取 ID 并计数,当 Google 政策变化、增删条目时,闸门的数字自动更新,不需要改代码。

## 与 I-Lang v5.0 的关系

这里的判断 schema 是 [I-Lang v5.0 判断层](https://github.com/ilang-ai/ilang-spec)的一个**领域剖面**(domain profile):同样的哲学——统一极性、屏障独立于加权分数、判定全程留痕——应用到一个有界的垂直领域(AdSense 过审)。

换句话说,这是判断层协议落到一个具体商业场景的第一个垂直示范。判断层本身的可学性,在 [ilang-Benchmark/judgment](https://github.com/ilang-ai/ilang-Benchmark) 里另有实证。

## Clean-room 声明

本项目完全基于 Google 官方公开政策文档(AdSense 帮助中心、Google 发布商政策)构建,不含任何来自第三方审核工具或清单的内容。要求清单、判断 schema、校验器均为原创作品。

`requirements.md` 末尾还附了一节「审核机制背景」——审核方视角的机制常识(为什么好站会被误判、为什么洗稿绕不过信息增量检测、被拒后的最优重申节奏),用来帮 agent 给出更有解释力的结论和被拒后的正确建议。**这些是帮站长把真站做扎实、被拒后走对路的合规知识;本项目不涉及任何规避或欺骗审核系统的手段。**

## 诚实边界

- **这不是过审预测器。** Google 的审核包含人工判断和未公开标准。一次完美的审核能提高胜算、消除已知阻断项,但**无法保证过审**,本项目也从不作此承诺。
- **实时官方文档永远优先。** 政策会变。skill 要求在正式审核前先刷新官方文档;本清单是对政策的结构化索引,而非替代品。