name

ilang-adsense-auditor

description

用 I-Lang v5.0 判断层审核一个网站是否具备申请 Google AdSense 的条件。每条要求输出一个结构化判断向量,站点结论遵循屏障规则(一个阻断项即一票否决),完整性由代码强制,保证没有任何一条要求被跳过。当用户想知道网站能否申请 AdSense、能否通过审核、能否投放广告,或需要诊断 AdSense 被拒、"网站尚未准备好"、"内容价值偏低"等问题时,使用本 skill。

iLang AdSense 审核器

核心规则

Google 官方 AdSense 与发布商政策文档是唯一事实来源。本 skill 把这些文档转化为一套结构化、判断向量式的审核,但无法保证过审——Google 的审核包含人工判断和未公开标准。每份报告都必须诚实说明这一点。

正式审核前,若能联网,先刷新 references/requirements.md 中列出的官方文档。如果实时 Google 文档与本 skill 冲突,以实时文档为准。

这套审核与众不同之处

两个协议层面的保证,不是文风偏好:

判断向量,而非标签。 每条要求产出一个 AUDIT_JUDGE_v1 记录(见 references/judgment-schema.md):五个维度在 [0.00, 1.00] 区间——合规度、证据、确定性、过审影响、修复成本,外加一个判定。每个判定背后的「为什么」都是可量化、可争议的数字。
完整性由代码强制,而非靠自觉。 审核不是「觉得查完了」就结束,而是 validator/audit_validator.py --check 通过才算完成。它读取要求清单,确认每个 ID 恰好被覆盖一次,校验每个向量,并验证站点结论确实由各条判定推导而来。跳过一条要求是一个非零退出码,不是一次疏忽。

审核前必读

references/requirements.md —— 29 条要求清单,含 ID、官方依据、默认严重度。通读全文。每个 ID 都必须评估。
references/judgment-schema.md —— AUDIT_JUDGE_v1 向量、判定集合、屏障聚合规则。
references/usage.md —— 调用与请求模板(用户问怎么用本 skill 时读)。

审核流程

确认审核目标。
- 线上 URL/域名、代码仓库路径,或两者兼有。
- 审核类型:申请前、被拒后、或广告投放清理。
- 站点类型:普通站、CMS/博客、目录站、电商、工具/应用、UGC、视频站、或登录墙产品。这决定了哪些要求判 NA。
从清单出发,而非凭直觉。 先生成骨架,让任何 ID 都无法被悄悄漏掉:
```
python3 validator/audit_validator.py --template > report.json
```
现在每条要求 ID 都是一行、等待被判断。
逐条收集证据。
- 抓取首页与代表性内容页。
- 检查 robots.txt(尤其 Mediapartners-Google)、sitemap、canonical URL、跳转、HTTP 状态、登录墙,以及主内容是否无需 POST 状态即可渲染。
- 检查隐私政策、关于/联系/所有权信号、导航、内容深度与原创性、广告/联盟密度、纯嵌入页,以及违禁/受限内容风险。
- 若有仓库访问权,检查模板/路由/内容来源,而不仅是渲染后的首页。
把每条要求判成一个向量。 对每个 ID,填一条 AUDIT_JUDGE_v1 记录:
- 诚实设定五个维度。证据 evd 低或确定性 cer 低时,判定必须是 UNKNOWN,并说明缺什么访问权——绝不能给一个心存侥幸的 PASS。
- 判定要与向量自洽(PASS 不能带 cmp < 0.5;BLOCKER 不能带 cmp > 0.5)。
- 仅当要求确实不适用时才用 NA,并说明是何种站点条件使其无关。
按屏障规则推导站点结论(不要用平均):
- 有任何 BLOCKER → NOT_READY。
- 有任何 HIGH/MEDIUM/UNKNOWN(无阻断项) → READY_AFTER_FIXES。
- 全部 PASS/NA → READY。
交付前先校验。
```
python3 validator/audit_validator.py --check report.json
```
若非零退出,审核就是不完整或不自洽的。先修好,再写给人看的报告。
产出报告。给站长的顺序,不是给机器的顺序。

报告开头必须是一段人话结论,让一个不懂技术、第一次申请 AdSense 的站长立刻看懂。这一段里不出现向量数字、不出现字段名,只回答三个问题:
- 能不能现在申请?(能 / 修完再申请 / 先别申请)
- 卡在哪几个地方?(用大白话点出阻断项,几个就是几个)
- 按什么顺序修?(先修哪个、再修哪个——排序规则见下)
这一段之后,才是给想深入的人看的技术明细:
- 发现列表,按严重度排序(先阻断项、再高危、再中危),每条含:要求 ID、问题、证据、官方依据、精确修复方案,以及它的判断向量。
- 最后一张表覆盖全部 29 条要求 ID,含判定与向量。
修复顺序怎么排(这是判断向量对新手的真正价值): 不是按严重度机械排,而是按「性价比」——imp(过审影响,越低越致命)高、fix(修复成本,越高越省事)也高的先修。也就是「既卡审核、又好修」的问题排最前面,让站长用最小的力气先搬走最挡路的石头。判断向量在这里不是哲学摆设,是一张修复排期表。

如果结论是 NOT_READY,报告结尾必须包含一句被拒后节奏提醒(依据见 requirements.md 的「审核机制背景」,注意那是社区经验归纳、非官方规则,表述时不得冒充 Google 官方说法):劝站长把问题修完再提交,并明确警告——不要在没有实质修改的情况下立即点「重新审核」,反复无修改重交只会让后面每一次审核都更难过。一次交对,胜过交十次。

实施指引

优先给出具体的、锚定证据的发现,而非泛泛而谈:

robots.txt 第 3 行 Disallow 了 Mediapartners-Google —— 而非「爬虫问题」。
文章页大多是抓取来的片段,没有任何原创评述 —— 而非「内容单薄」。
/reviews 页首屏之上的联盟广告块超过了主内容 —— 而非「广告太多」。
隐私政策完全没有提及 Google/第三方广告 cookie —— 而非「隐私政策不完整」。

只要还有任何 BLOCKER 未解决,或任何 HIGH 既未修复也未被站长明确接受,就不要建议提交申请。

审完之后:主动提出帮站长改(代修闭环)

能用到这个 skill 的人,几乎都是还没过审的新手站长——他们要的不是一份诊断书,是把网站改到能过。所以审核报告不是终点。

在任何拥有文件或服务器访问权的运行环境里(比如 Claude Code、Codex、OpenClaw、WorkBuddy 这类能读写站长代码仓库或 VPS 的 agent),给出报告后,必须主动问一句:「需要我直接帮你改好吗?」 然后按上面那张修复排期表的顺序动手:性价比最高(既卡审核又好修)的先改。

每改一处,对应一条要求 ID,说清楚改了什么、为什么这样改能解决对应的判断。
改完可以重跑一遍审核,让站长看到判定从阻断项变成通过——这比任何解释都直观。
涉及删内容、改主题、动 robots.txt 这类有风险的操作,先讲清后果、征得同意再动手。

如果运行环境没有文件/服务器权限(比如纯聊天窗口),就把每处修复写成站长能照着做的具体步骤:改哪个文件、加哪几行、放在什么位置。给的是「怎么改」,不是「哪里错」。

跨平台运行:能跑校验器就跑,不能跑就诚实降级

本 skill 的完整性闸门靠 audit_validator.py(纯 Python 标准库)。不同 agent 平台的执行能力不一样:

能执行 Python 的环境(Claude Code、Codex、OpenClaw、Hermes、WorkBuddy、Claude 网页版的代码执行等):正常跑 --check,闸门是硬性的。
不能执行代码、只能读文档的环境(如飞书 aily 的部分技能形态):无法运行校验器。此时降级为模型自查——对照 requirements.md 的 29 条 ID 逐条核对,确认每一条都被评估、没有遗漏。但必须在报告里诚实标注这是降级模式:「本次审核未经过 audit_validator.py 的代码级完整性校验,29 条要求由模型逐条自查覆盖。」

绝不能在降级模式下假装闸门通过了。诚实标注降级,本身就是这个 skill 的诚实原则的一部分。

完整性闸门(不可妥协)

在能执行代码的环境里,审核只有在 audit_validator.py --check 通过后才算完成。这是把本 skill 与「模型可以偷偷少填的清单」区分开的结构性保证。绝不要在一份未通过闸门的报告上给出过审结论。