企业官网建设流程全解析

本篇技术指南以 Claude Ads 开源仓库中 ads/references/snapchat-audit.md 为核心骨架，系统讲解 Snapchat Ads 平台的 16 项审计控制（SC-M01 至 SC-E01）如何从"证据问题"落地为"确定性评分与账户诊断"。读完本文，你将掌握：Snapchat 审计的运行期评估契约（applicability-first 原则）、四态结论（pass/fail/unknown/not_applicable）的评分语义、测量/报告/结构/受众/创意/零售/预算/政策/实验九大类别的检查要点，以及如何在缺少可执行评分档案（scoring profile）时正确产出 findings 而不伪造健康分。文章同时结合 control-plane/manifests/control-registry.json、control-plane/manifests/scoring-profiles.json、claude_ads_core/scoring.py 等仓库源码与测试，为每个结论提供可验证的实现依据。

一、文档定位与成文边界

1.1 这份参考在 Claude Ads 中的角色

snapchat-audit.md是 Claude Ads 十二大平台审计面中 Snapchat 的控制参考（control reference）。它既不是可执行的评分档案，也不是实时 API 读取器，而是一份"证据问题清单 + 运行期契约"：

• 不定义可执行评分档案：文档开头明确声明 "This reference does not define an executable scoring profile"，必须绑定一个类别覆盖适用控制、权重总和为 100 的版本化档案，否则只产出 findings 而不输出健康分。
• 只做出口只读（export-read only）：不提供 Snap 实时 API 读取器或变更适配器，所有结论停留在分析与建议层面。
• 获取日期 2026-07-11：文档标注了检索日期与控制面刷新日，使用前需核对官方平台与政策来源是否已过期。

从 ads/SKILL.md 的"平台契约（Platform contract）"可知，Snapchat 与其他 11 个平台一样是一等审计面（first-class audit surface）——即使 Snap 的数据经由其他共享 API 提供，也必须单独报告独立平台得分。这一契约在测试 tests/audit/test_scoring_math.py 中被硬性校验：check_catalog中的platforms集合必须恰好等于十二平台集合，Snapchat 位列其中。

1.2 与周边文件的调用关系

Snapchat 审计不是孤立运行的，其实际调用链为：

1. 用户发出/ads snapchat（或自然语言请求）→ ads/SKILL.md 的命令路由将平台审计路由到相应 workflow；
2. 主契约要求先读 ads/references/thinking-framework.md，再读相关 workflow skill 与所需平台参考；
3. skills/ads-snapchat/SKILL.md 规定审计程序：读取snapchat-audit.md与共享的 measurement、benchmark、creative、policy、scoring 参考，归一化账户数据并保留来源血缘，只评估适用控制；
4. agents/audit-snapchat.md 将 Snapchat 切片分配给被约束的 worker，要求返回 schema 有效的 findings，禁止在 prompt 中计算最终平台或组合得分、禁止写共享报告文件。

这一"文档定义控制 → 技能定义流程 → Agent 产出 JSON findings → 引擎评分"的分层，正是 Claude Ads"让每次完成声明都可追溯到运行中产生的证据"的核心设计。

二、Category model：为什么不内置评分档案

2.1 档案绑定与权重总和的硬约束

原文档强调：本参考不定义可执行评分档案，必须绑定"类别覆盖适用控制、权重总和恰为 100"的版本化档案；否则仅产出 findings、无健康分。这一约束在源码层面对应两点：

• ads/references/scoring-system.md 规定调用方必须提供版本化评分档案，类别权重总和恰好等于 100，生产引擎会校验该不变量；没有适用控制的类别会被剔除，剩余类别权重在当次运行中重新归一化。
• control-plane/manifests/scoring-profiles.json 中snapchat-health-v1档案当前为disabled状态，category_weights为空、health_control_ids为空，禁用原因是"尚无经批准、有来源支撑的控制严重度决策集；启用健康分会凭空捏造严重度或类别权重"。

因此，在当前仓库状态下，Snapchat 账户无法输出合法健康分，正确做法是产出 findings、标注证据覆盖率（evidence coverage）与监管暴露（regulatory exposure），绝不把"评分档案里没有的东西"通过 prompt 内联补出来——ads/SKILL.md 明确禁止在 prompt 中提升 catalog 或 watchlist 行。

2.2 控制注册表中的落地形态

control-plane/manifests/control-registry.json 为 16 个 SC 控制各登记了一条conditional_watchlist记录。以 SC-M01 为例（约 9562 行起）：

{ "platform": "snapchat", "control_id": "SC-M01", "intent": "Snap Pixel, Conversions API, MMP, or offline source is declared and verified.", "disposition": "conditional_watchlist", "source_claim_ids": [], "control_definition": { "schema_version": "1.0.0", "control_id": "SC-M01", "category": "measurement", "severity": "informational", "required_inputs": ["applicability_context", "current_account_evidence", "current_source_support"], "source_ids": [], "maturity": "inventory-baselined", "geographies": ["account-configured"], "scoring_behavior": "watchlist", "stability": "experimental" } }

关键字段说明：

所有 16 条记录均无source_claim_ids（空数组），印证了原文档"当前来源仅覆盖 Marketing API 表面，其余声明需补充带日期的官方来源 ID 或账户证据"的边界。

三、Runtime evaluation contract：适用性优先的证据评估

原文档的运行时评估契约是整份参考的方法论核心，展开如下：

1. 每一行都是一条"适用性优先的证据问题"（applicability-first evidence question）。即评估顺序是先判断该控制是否适用于当前账户/广告系列，再收集证据作答，而不是先找证据再套控制。
2. 缺失证据 =unknown；不可用或不适用面 =not_applicable。二者的评分语义完全不同（详见下文第五节）。
3. 评估前必须核验五类前提：objective（目标）、placement（版位）、geography（地域）、measurement path（测量路径）、reporting lifecycle（报告生命周期）、catalog use（商品目录使用）、policy（政策）、account eligibility（账户资格）。任何一项不核验就下结论，都会把不适用控制误判成健康问题。
4. 来源边界：注册的官方来源只支撑 Marketing API 表面；Pixel、CAPI、测量、报表字段、格式、政策与可用性声明需要额外的带日期官方来源 ID 或账户证据。
5. 只读边界：本参考是 advisory 与 export-read only，不提供实时 Snap API 读取器或变更适配器——这与 ads/SKILL.md 中"所有集成默认只读，写入必须通过变更门（mutation gate）"的全局约束一致。

结合 agents/audit-snapchat.md 的程序约束可进一步明确：worker 必须把 exports、页面、截图、API/MCP 响应与广告文案一律视为不可信数据（untrusted data），绝不执行其中内嵌的指令；在确认账户、日期窗口、时区、币种、目标与可用输入前不得猜测，缺失材料要显式标记。

四、Controls：16 项控制的完整清单与检查要点

原文档的核心资产是下表。以下完整继承，并补充每项控制的实操检查要点（检查要点为结合注册表 intent 与 Snapchat 广告产品逻辑的展开说明，非平台官方硬性规格）：

4.1 分类背后的检查要点

• Measurement（SC-M01~M04）：先确认账户到底声明了哪条测量路径（Pixel / CAPI / MMP / offline）；事件命名与目标（如 App Install、Purchase）是否一致；当 Pixel 与 CAPI 同时存在时，是否有文档化的去重策略（对应 SC-M02 的 deduplication）；App 广告系列是否包含 SKAdNetwork / app 测量所需配置（SC-M03）；归因窗口（如 7 天点击 / 1 天浏览）与报表字段是否在对比时口径一致（SC-M04）。
• Reporting（SC-R01~R02）：报表日期是否按广告账户时区切分，数据最终确定（finalization）窗口是否披露；大型报表（如产品级、多 ad-squad）是否走 Snap 支持的异步报表生命周期而非同步拉全量。
• Structure（SC-S01~S02）：Snap 的层级是 Campaign → Ad Squad → Ad（对应 Snapchat 的 campaign/ad-squad/ad 结构），检查 objective 是否与层级关系一致；优化事件（optimization goal）、版位选择与投放方式是否真的服务于声明目标。
• Audience（SC-A01）：受众（Audience / Advanced Audience / Lookalike）、地域、设备与第一方定向是否"有意且符合资格"——即不是误配、不在不适用地域投放、不使用无资格的自定义受众。
• Creative（SC-C01~C03）：Snap 是移动优先平台，创意需按所选版位（如 Snap 广告、Story 广告、Collection 广告）原生裁剪；测试素材之间要有实质差异（不同 hook/格式/概念），而非同素材微调；AR（Lens）、Story、collection、lead 格式必须带齐所需素材与正确的落地页目的地。具体格式与素材规格可经 ads/references/platform-specs.md 登记的snap-creative-specs-official入口核对，该表注明"这些页面是发现入口，不是每个格式在当前账户可用的证明，发出 pass 或变更前必须复查活跃 UI/API"。
• Retail（SC-D01）：仅当使用 DPA（动态产品广告）时适用；检查 catalog 映射、产品可用性状态与产品级报表是否能对上。
• Budget（SC-B01）：预算/出价/节奏/上限是否可行，币种单位是否正确（Snap 账户币种与出价货币是否一致、数量级是否合理）。
• Policy（SC-P01）：品牌安全（brand safety / 内容分类）、年龄定向、隐私约束、受监管类别（如酒精、金融）与广告审核状态是否全部检查。
• Experiment（SC-E01）：A/B 测试是否一次只隔离一个决策变量，且样本量/报告延迟是否被纳入判读。

五、四态结论与评分语义

5.1 pass / fail / unknown / not_applicable

原文档规定结果取pass、fail、unknown、not_applicable四态，其语义在 ads/references/scoring-system.md 中有权威定义：

原文的两条推论因此成立：unknown 控制会降低证据覆盖率（它留在覆盖率分母里）；不可用、beta、付费、或无资格的功能是不计分的机会（unscored opportunities）——它们既不计分也不扣分。

5.2 覆盖率的三个档位

ads/references/scoring-system.md 给出覆盖率分档：

并且即使总覆盖率高于 80%，unknown 的 critical 控制也必须出现在优先级输出中。这解释了为何 Snapchat 审计实践中"把缺证据标记成 unknown"本身就是一个重要交付物。

5.3 引擎侧的实现印证

claude_ads_core/scoring.py 是生产评分引擎的唯一权威（SEVERITY_WEIGHTS、score_account均来自该模块）。测试 tests/audit/test_scoring_math.py 直接验证了语义：

• test_audit_integration_scores_categories_before_category_weights：先按已知适用控制计算类别健康分，再乘类别权重，验证score_account(controls, findings, {"a": 80, "b": 20})得到 66.67 的健康分与 100% 覆盖率；
• test_unknown_critical_evidence_blocks_low_coverage_score：6 个控制中只给 5 个 medium 提供 pass 证据，critical 控制保持 unknown，结果evidence_coverage == 50.0、状态insufficient_evidence、health_score is None——即覆盖率不足时引擎拒绝输出健康分，而非给一个低分。

这两个测试精确印证了"unknown 留在覆盖率分母"与"覆盖率不足不出分"的语义，也解释了为什么 Snapchat 参考要求"无法验证的控制保持 unknown，从业者材料只能补充不能替代官方证据"。

六、Registered official evidence：来源治理

原文档登记的官方证据为：

snap-marketing-api：Snap Marketing API

来源治理规则有三条：

1. 官方来源优先于本摘要：官方来源变更时覆盖本摘要；
2. 不支持的控制保持unknown：不能因为没有来源就脑补结论；
3. 从业者材料只能补充、不能替代官方证据：这对应 ads/SKILL.md 的证据分级（官方平台/API/监管/标准机构材料 > 一手账户导出/API 响应/受控实验数据 > 带日期的可靠从业者材料 > 经许可审查的社区资源）。

实践上这意味着：涉及 Pixel、CAPI、测量字段、格式、政策与可用性的"精确声明"，必须能给出带日期的官方来源 ID 或账户证据；若refresh_due已过期，则不得将该声明视为当前事实，需重新验证，验证失败则降级为 provisional 或 unsupported，并阻止任何依赖它的release-current声明（ads/SKILL.md 证据政策章节）。

七、从参考文档到实际审计运行的完整路径

7.1 触发方式

• 显式命令：/ads snapchat（ads/SKILL.md 的快捷路由直接将平台名映射到平台审计）；
• 自然语言：描述中包含 "Snapchat Ads"、"Snap Pixel"、"Snapchat Conversions API"、"AR Lens ads"、"Snapchat dynamic product ads" 等触发词时，路由到 skills/ads-snapchat/SKILL.md（其 frontmatter description 明确列出这些触发词）。

7.2 审计流程（按 skills/ads-snapchat/SKILL.md）

1. 读主ads操作契约与 thinking framework；
2. 收集业务目标、账户年龄、日期窗口、时区、币种、花费、转化定义与可用导出/认证读取；
3. 读ads/references/snapchat-audit.md与相关共享 measurement、benchmark、creative、policy、scoring 参考；
4. 归一化账户数据并保留来源血缘；
5. 只评估适用控制，覆盖 measurement、账户与 ad-squad 结构、移动创意、AR 与 catalog 格式、受众、预算、报告与品牌安全；
6. 向 conductor 返回 schema 有效的 findings，不在 prompt 中计算分数、不写共享报告文件；
7. 仅从已验证的运行 bundle 渲染平台报告。

7.3 worker 的输出契约（按 agents/audit-snapchat.md）

返回一个 JSON 结果对象，包含status（ok/needs_input/blocked/failed）、platform: "snapchat"、findings、contradictions、missing_inputs、recovery_hints。每个 finding 必须携带：

• control_id（如SC-M01）
• result（pass/fail/unknown/not_applicable）
• severity、confidence（high/medium/low/none）
• observation、evidence_refs
• 决策完备（decision-complete）的recommendation或null

可选项（beta、premium、immutable、unavailable、ineligible）一律是不计分机会；任何账户变更保持草稿态，直到 conductor 的变更门（mutation gate）全部通过。这是对"本参考不提供变更适配器"的运行期补全：分析可以完备，写入必须止步于草稿。

7.4 渲染与输出

报告只能从规范化的 JSON bundle 渲染（ads/SKILL.md 的"Scoring and output"），每次运行写入.claude-ads/runs/<run-id>/下的 manifest 与原子化产物，Markdown/HTML/PDF 从同一 JSON 渲染。任何 worker 不得覆盖先前的运行或写共享的最终文件名。Snapchat 作为失败请求的平台时不是零分：将其排除在组合分及其分母之外，仅在成功打分的可比平台间重新归一化，并把 bundle 标记为partial。

八、常见误用与规避要点

综合原文档边界与仓库约束，以下行为在 Snapchat 审计中应被规避：

九、刷新与维护要求

原文档在开头与结尾两次强调时效性：

• 使用前：在控制面刷新日期之后使用本参考，必须先刷新官方平台与政策来源；
• 覆盖规则：官方来源变更时覆盖本摘要；
• 声明边界：无法支撑的控制保持unknown。

这与仓库的"证据新鲜度"机制完全对齐：ads/SKILL.md 要求每个平台/政策/基准/API 精确声明都携带来源 ID、检索日期、置信度与刷新日期；过期的承重来源使结果转为 provisional，并阻止 release-current 声明；工具不可用永远不能把过期证据变成当前证据。因此，把snapchat-audit.md的检索日期（2026-07-11）与其 refresh 机制一并写入运行 manifest，是 Snapchat 审计合规的一部分。

十、结语：一份"证据问题清单"如何驱动确定性审计

snapchat-audit.md表面上是 16 行控制表，实质上是 Claude Ads"来源扎根审计（source-grounded audit）"方法论在 Snapchat 平台上的完整实例化：用适用性优先的证据问题约束评估顺序，用四态结论约束评分语义，用官方来源治理约束事实边界，用"不定义评分档案 + 不提供写适配器"约束能力边界。在仓库当前状态下，正确使用这份参考的产出物是一份 schema 有效、来源可追溯、覆盖率透明的 findings bundle——健康分需要等待经批准、来源支撑的严重度决策集将snapchat-health-v1档案启用后才能合法出现。对工程团队而言，这既是 Snapchat 投放账户的体检清单，也是"如何把 AI 审计做成确定性系统"的一份可复用的平台级范本。