【免费下载链接】claude-adsClaude-first paid-media operations skill for Claude Code across 12 ad platforms (Google, Meta, YouTube, LinkedIn, TikTok, Microsoft, Apple, Amazon, Reddit, Pinterest, Snapchat, X): source-grounded audits, deterministic scoring, versioned JSON reports, and capability-gated account changes.项目地址https://gitcode.com/gh_mirrors/cl/claude-ads点击查看免费下载本篇技术指南围绕当前仓库control-plane/RELEASE_REQUIREMENTS.md展开完整解析 Claude Ads面向 Claude Code、覆盖 12 个广告平台的付费媒体运营技能集在发布候选release candidate阶段必须通过的六类门禁与一套独立的评审证据协议。读者读完将掌握每个发布门禁的具体判定条件、证据新鲜度窗口、模型评估与 Ed25519 签名校验的完整链路以及scripts/review_evidence.py、scripts/release.py等命令如何把这些规则落地为可运行的失败关闭fail-closed检查。门禁总览累积式门禁与降级触发RELEASE_REQUIREMENTS.md开宗明义地指出所有门禁是累积的cumulative。也就是说发布候选必须在产品契约、证据、安全隐私、评估、安装打包、合并发布六条线上同时满足要求缺一不可任何一条不满足都不能发布。更重要的是文档明确给出了降级demotion触发条件——一个原本符合条件的发布候选会在以下任一情形发生时被降级承重load-bearing来源过期出现新的关键critical安全或隐私发现已声明的能力失去对应的测试证据必需的远程 CI 未通过。这意味着“曾经通过”不等于“现在可发布”发布资格会随证据时效、安全态势和 CI 状态的漂移而动态变化。这一点与control-plane/README.md中记录的 Doctrine 一脉相承“Staleness, security failures, or broken evaluations demote maturity”过期、安全失败或评估损坏都会使成熟度降级。一、产品与契约门禁承诺与实现必须一致第一类门禁约束的是“产品对外说的话”核心目的是防止文档、契约、实现与证据四者之间出现脱节一致化文档买方buyer、承诺promise、命令、输出、边界、隐私默认值以及变更权限mutation authority必须在文档中保持一致的表述避免同一概念在不同文件里语义漂移。公开 Schema 版本化所有公开 JSON Schema 必须带有语义化版本和配套 fixtures破坏性变更breaking changes必须升级主版本号并附迁移说明。仓库中control-plane/schemas/下的契约均采用 JSON Schema Draft 2020-12且$id使用稳定的urn:ai-marketing-hub:claude-ads:schema:*标识符标识符而非网络地址见control-plane/README.md。能力状态与实现对齐声明的能力状态必须与实现、adapter、fixture 和测试证据匹配能力清单见control-plane/manifests/capability-manifest.json。这一点与 README 的 Doctrine 第二条“No implementation, fixture, and test, no capability claim”完全对应——计划中的能力只能标记为declared或disabled只有经过验证的行为才能标记为fixture-verified或live-verified。完整审计声明任何“完成一次完整审计complete-audit”的声明都必须报告模块完整度module completeness与证据覆盖率evidence coverage不允许笼统宣称“已审计”。输出隔离健康度health、证据置信度evidence confidence、监管风险暴露regulatory exposure与机会opportunities必须作为相互独立的输出防止混为一谈。注册表单一处置每个目录 IDcatalog ID必须有且只有一个类型化typed的注册表处置项只有启用了的版本化评分配置enabled versioned profile才允许提供健康控制项与类别权重。健康控制项必须满足经过验证的承重声明、非零的被评审严重度non-zero reviewed severity、显式输入、状态稳定。被禁用的 profile 必须失败关闭fail closed——即不产出任何健康分数。这条“禁用即无健康分”的规则在control-plane/manifests/control-registry.json与control-plane/manifests/scoring-profiles.json中落实control-plane/README.md明确说明“所有十二个评分 profile 当前均处于禁用状态直到每个控制项获得来源支持、严重度决策、类型化输入、权重与回归证据的联合批准”。因此当前目录仅用于发现类发现discovery findings不用于账号健康评分。二、证据门禁无来源无当前声明证据门禁是 Claude Ads “source-first”研究纪律的直接体现核心口号可概括为 Doctrine 第一条“No source, no current claim”无来源无当前声明。具体规则如下承重声明的双要素每个承重的平台、API、政策、法规、基准benchmark或创意规格creative specification声明都必须有一个声明 IDclaim ID和至少一个带日期的来源 IDdated source ID。对应的账本为control-plane/manifests/claim-ledger.json与control-plane/manifests/source-ledger.json。来源层级官方、监管机构、标准组织或一手来源primary sources优先从业者practitioner证据必须显式标注并且不能单独作为强制性政策或合规行为的依据。新鲜度窗口不同类别来源的刷新周期不同文档给出了明确的时间表证据类别刷新窗口说明API、政策、功能、创意规格30 天逾期即过期法规regulation事件驱动 生效日期前 30 天检查双重保障基准benchmarks每季度定期重跑基础方法foundational methods12 个月长期稳定性过期即阻塞逾期未刷新的承重来源会阻塞发布直到刷新或将依赖它的声明与能力一起降级。也就是说来源过期不能“带病发布”只能选择“补药”或“停药”。这套机制与scripts/release.py中的_check_grounding_and_capabilitiesevaluate_release_gate内名为source-capability-integrity的检查相衔接把“文档规则”变成了每次gate命令都会执行的代码级校验。三、安全与隐私门禁写操作默认关闭安全与隐私门禁把“广告操作安全”细化为可测试的工程约束写操作默认禁用所有对账号的写操作mutation默认关闭且必须按平台进行能力门控capability-gated by platform。这与 Doctrine 第三条“No approval and rollback, no account mutation”呼应——没有审批与回滚能力就不允许动账号。变更生命周期全覆盖变更mutation的生命周期测试必须覆盖预览preview、审批approval、应用apply、重复应用repeated apply、验证verify、失败failure、审计audit与回滚rollback。这正是claude_ads_core/schemas/v1/mutation-plan.schema.json等契约所约束的流程结构。对抗性防御以下攻击面必须通过对抗性测试adversarial testsURL、重定向、DNS、浏览器子资源browser-subresource、输出路径、符号链接、归档archive以及解析器差分parser-differential。这些要求对应control-plane/REQUIREMENT_INDEX.md中的REQ-SEC-001网络与浏览器访问须抵抗 SSRF、重定向、rebinding、解析器差分与恶意子资源与REQ-SEC-004输出与归档路径必须受控、规范化、符号链接安全且防目录穿越。不可信内容不可提升权限不可信内容如外部抓取的页面、文档不能改变指令instructions或变更权限mutation authority防止提示注入扩大攻击面。敏感数据缺席密钥与个人数据不得出现在受跟踪文件、fixtures、报告、日志、任务包task packets、归档与 Git 历史中。scripts/release.py中内置了SECRET_PATTERNS覆盖私钥、AWS key、GitHub token、Google/OpenAI API key、Slack token、JWT 等模式与PRIVATE_PATH_PATTERNS覆盖/home/、/Users/、C:\Users\、~路径等每次打包前会对全部受跟踪文件做扫描。数据生命周期闭环数据分类、脱敏redaction、保留retention、加密与删除行为必须被文档化并测试。对应的策略文件为control-plane/manifests/data-lifecycle-policy.json及其 schemacontrol-plane/schemas/data-lifecycle-policy.schema.json每次运行的取值则使用claude_ads_core/schemas/v1/data-lifecycle.schema.json。四、评估门禁本地检查永远不能替代外部模型运行评估门禁是六类门禁中工程上最“重”的一环它把“模型行为可信”拆解成一组严格到近乎苛刻的条件本地套件必须全绿Schema、评分、归一化、缺失数据处理、去重、路由与报告渲染套件必须全部通过每个目标平台都必须有脱敏导出 fixtures 与失败用例见tests/fixtures/exports/与tests/fixtures/native_exports/覆盖 12 个平台路由与安全回归必须100% 通过。模型评估阈值模型评估整体overall至少达到90%且不允许任何 P0 安全失败不允许对保留的 v1 行为产生非预期回归。规范模型门canonical model gate的取证要求规范模型门必须消费完整的外部 Claude Code 运行证据且同时覆盖两个主体——候选提交exact candidate commit与固定的保留 v1 主体pinned retained-v1 subject。两者必须满足使用相同的 CLI 与模型快照每个用例使用全新的进程不复用对话no conversation reuse无变更权限no mutation authority评估者独立于运行执行者evaluator independent of the run executor。失败关闭清单以下任一情形都必须失败关闭fail closed证据缺失、过期、非 Claude 产出、自评分self-graded、哈希不匹配、部分证据、运行环境不可比。本地的 schema、套件与评估者检查永远不能替代两次外部模型运行中的任何一次。证据处理纪律原始响应raw responses必须保持私有只保留脱敏后的确定性门报告redacted deterministic gate report且该报告作为被忽略ignored的外部发布证据——它不得改变其所验证的确切 Git 主体也不得进入产品归档product archive。双签名机制每次模型运行需要独立的运行者runner与评估者evaluator两把 Ed25519 签名覆盖确切主体、运行时、用例收据case receipts、评分判据rubric judgments与结果。信任排除trust exclusions通过两个环境变量提供CLAUDE_ADS_MODEL_EVAL_TRUST_BUNDLE_JSON外部模型评估信任包CLAUDE_ADS_MODEL_EVAL_IMPLEMENTATION_PRINCIPALS_JSON实施主体implementation principals名单用于排除“自己评自己”。同时仓库本地repository-local、伪造、过期、角色错配、自签名或自评审self-review的证据一律失败关闭。这条规则的代码实现位于evals/model_eval_gate.py其契约文档为evals/model-eval-contract.jsonschema 为evals/schemas/model-gate-report.v2.schema.json。新鲜上下文验证最终由一个全新上下文的验证器fresh-context verifier根据产物artifacts与测试输出来确认“完成声明”而不是依据实现对话本身——防止“我做过”的自述成为证据。scripts/release.py的evaluate_release_gate通过_load_local_module(root, evals/model_eval_gate.py, ...)加载并调用verify_release_report将其包装为名为canonical-model-evaluation的独立检查项任一失败都会让release_gate_satisfied变为false。五、安装与打包门禁可复现构建与精确锁定的依赖安装与打包门禁的目标是“从干净检出到发布归档全程可复现、可校验、无副作用”多平台解释器矩阵Python wheel 的解析、安装、升级与卸载必须在声明的 Linux、macOS、Windows 解释器组合CPython 3.11 / 3.12上测试通过。注意文档特别澄清这不是跨平台 Playwright 浏览器或 WeasyPrint PDF 功能的声明——两者是独立的外部运行时需要单独的主机/负载证明host/payload attestation。安装副作用约束安装不得静默修改全局 Python 环境也不得执行未经核验的网络内容。卸载白名单卸载只移除所有权清单ownership-manifest中的条目不留“孤儿文件”unowned files。可复现构建从干净检出必须能可复现地构建发布归档、发布清单、SHA-256 校验和、SBOM 与许可证声明license notices。锁定策略运行时与开发锁文件使用精确版本外加每个声明的目标平台发布者 wheel 哈希的并集安装脚本使用--require-hashes --only-binary:all:运行pip check并且当解释器目标不在矩阵内时在变更发生前即失败。这些细节可以在requirements.lock、requirements-dev.lock、install.sh/install.ps1中找到对应实现。SBOM 边界CycloneDX 发布 SBOM 只包含应用与运行时闭包单独的开发锁/依赖清单development lock/inventory只作为审计证据不属于应用依赖。构建 SBOM 的代码位于scripts/release.py的build_sbom与_build_sbom_from_inventory且发行物会绑定确切 Git 提交。外部运行时建模Playwright 浏览器负载与 WeasyPrint 原生/系统库在control-plane/manifests/external-runtime-dependencies.json中建模明确排除在 Python 锁/SBOM 之外浏览器执行需要单独的主机/负载证明真实的 PDF 渲染只在 Ubuntu 全量测试任务上做冒烟测试而不是跑满整个 wheel 矩阵。路径可移植性归档路径必须可移植不得包含非法、绝对或目录穿越traversal名称。scripts/release.py的validate_portable_path实现了这一检查拒绝绝对路径、反斜杠、空段、./..、控制字符、Windows 保留名、尾随空格/点等对应control-plane/REQUIREMENT_INDEX.md的REQ-PKG-001。六、合并与发布门禁远程 CI 与独立评审双保险发布候选走到合并环节还需要满足最后一组条件远程 CI 不可替代集成提交上必需的 GitHub Actions 检查必须通过本地成功不能替代缺失、跳过或因计费billing-blocked而不可用的远程 CI。四重独立评审集成分支必须接受独立的代码code、证据evidence、安全security、隐私privacy与许可licensing评审——共五种评审类型。评审证据的可验证性评审证据必须符合独立评审 schemacontrol-plane/schemas/independent-review-evidence.schema.json绑定确切的提交与树commit and tree并在外部供应的 Ed25519 公钥下完成验证。待定模板pending templates与仓库本地信任根不能满足此门禁——这正是control-plane/manifests/reviews/下五个模板code.review.template.json、evidence.review.template.json、security.review.template.json、privacy.review.template.json、licensing.review.template.json只是模板、不是批准的原因。生态处置账本无关键阻塞生态处置账本ecosystem disposition ledger即control-plane/manifests/ecosystem-dispositions.json中不得残留关键critical阻塞项tests/release/test_repository_review_release_gate.py对账本检查的失败关闭行为做了完整测试如test_repository_review_gate_rejects_open_critical_blocker。合并且打 v2 标签只有全部门禁通过后被评审的分支才允许合并并打上v2 标签。私有优先仓库可见性保持私有公开发布必须单独走control-plane/PUBLISHING_POLICY.md定义的公开发布门禁涉及可见性分类、历史扫描、许可核验、干净构建与 CI 矩阵重跑等七步。七、独立评审证据协议签名、环境变量与验证命令模板 vs 批准control-plane/manifests/reviews/下的文件是待定、未签名pending, unsigned的模板不是批准。已完成的评审证据必须存放在检出与发布归档之外scripts/review_evidence.py的verify_independent_reviews甚至会显式拒绝指向仓库内部目录的 evidence-dir因为发现项与证据定位符可能属内部信息。以code.review.template.json为例模板的decision固定为pendingsubject.commit_sha、tree_sha、reviewer.id等全部为nullevidence_refs与findings为空数组authentication为null。schema 中的allOf规则保证了这一点pending状态的评审必须是空壳而approved状态的评审必须填满 commit/tree、评审者身份、时间戳、证据引用与 Ed25519 签名。签名协议独立评审者把评审文档绑定到完整的提交 ID 与树 ID40 位十六进制小写schema 中约束为^[0-9a-f]{40}$并使用 Ed25519 对规范化 UTF-8 JSON签名。规范化规则与scripts/review_evidence.py的_canonical_review_payload实现完全一致仅移除authentication.signature_b64url字段键按字典序排序sort_keysTrue使用separators(,, :)无多余空白即 no insignificant whitespace不做 ASCII 转义ensure_asciiFalse。签名signature_b64url为 64 字节 Ed25519 签名的 base64url 编码schema 中约束为^[A-Za-z0-9_-]{86}(?:)?$。信任输入三个环境变量环境变量作用CLAUDE_ADS_REVIEW_TRUST_KEYS_JSON外部评审者公钥信任包符合control-plane/schemas/review-trust-bundle.schema.json含key_id、public_key_b64url、reviewer_id、allowed_review_types、valid_from、valid_until、revokedCLAUDE_ADS_IMPLEMENTATION_PRINCIPALS_JSON实施主体 ID 列表用于排除自评实施者不得评审自己CLAUDE_ADS_REVIEW_EVIDENCE_DIR存放已签名评审 JSON 的外部证据目录私钥在任何情况下都不得进入检出目录、验证器、日志或产物。验证命令在仓库根目录执行python scripts/review_evidence.py --root .review_evidence.py的main从CLAUDE_ADS_REVIEW_EVIDENCE_DIR读取证据目录也可用--evidence-dir指定还支持--commit-sha/--tree-sha显式绑定主体随后执行全量校验。以下任一情形都会失败关闭fail closed外部状态缺失缺 trust bundle、实施主体名单或证据目录主体不匹配评审文档绑定的 repository/commit/tree 与当前主体不一致证据过期或重复reviewed_at超出control-plane/manifests/review-policy.json中freshness.maximum_age_days130 天的窗口、评审 ID 或评审类型重复存在 pending / rejected 决策只有approved才能通过无效或越权密钥key 不存在、已撤销、评审者与 key 绑定的reviewer_id不符、评审类型不在allowed_review_types内、签名时间不在 key 的有效期内、key 非外部供应自评评审者出现在实施主体名单中存在 open 的 critical/high 发现项存在 accepted-risk 发现项但无单独的 owner 门禁schema 只允许open/resolved/accepted-risk三种状态而_validate_review_document对 accepted-risk 一律拒绝。此外_load_policy会先校验control-plane/manifests/review-policy.json必须满足五种评审类型全齐、决策必须是approved、模板不算证据templates_are_evidence: false、要求精确绑定 commit 与 tree、信任密钥必须来自环境变量且禁止仓库本地信任根、至少两名不同评审者、freshness 窗口在 130 天、禁止 open 的 critical/high、accepted-risk 需要独立 owner 门禁——任何一条弱化都会让整个发布评审失效。验证成功后验证器输出一个脱敏的摘要报告含评审 ID、类型、评审者、key、时间戳与各文档的 SHA-256 摘要该摘要可进入发布元数据原始评审文档不得进入发布归档。八、把门禁串起来发布门评估命令control-plane/README.md给出了把全部门禁一次性跑通的命令python scripts/release.py gate \ --model-report 规范模型门报告路径 \ --review-evidence-dir 外部签名评审目录 \ --github-run-id GitHub Actions 运行 ID同时通过环境变量提供信任输入export CLAUDE_ADS_REVIEW_TRUST_KEYS_JSON... # 评审者公钥信任包 export CLAUDE_ADS_IMPLEMENTATION_PRINCIPALS_JSON... # 实施主体名单 export CLAUDE_ADS_MODEL_EVAL_TRUST_BUNDLE_JSON... # 模型评估信任包 export CLAUDE_ADS_MODEL_EVAL_IMPLEMENTATION_PRINCIPALS_JSON... # 模型评估实施主体从scripts/release.py的evaluate_release_gate第 1813 行起可以看到一次gate运行会并行执行以下独立检查每项失败都会被记录在案并最终把release_gate_satisfied置为falserepository-audit仓库审计受跟踪文件数、敏感文件/密钥模式/私有路径扫描、SKILL.md frontmatter 一致性、插件与市场清单一致性等clean-subject工作树干净、主体可解析source-capability-integrity来源与能力完整性ecosystem-dispositions生态处置账本无关键阻塞canonical-model-evaluation消费evals/model_eval_gate.py的verify_release_report核对候选提交与保留 v1 主体的外部运行证据independent-reviews复用scripts/review_evidence.py完成五种类型的外部签名评审校验remote-ci核对 GitHub Actions 运行 ID 对应的必需任务全部为success任务集合在代码中固定为若干具名 job缺失或非成功即失败。输出符合control-plane/schemas/release-gate-report.schema.json任何输入缺失、过期、未签名、主体错配、不完整或未成功报告都失败关闭。release.py还提供audit、package、verify子命令分别用于只做审计、可复现打包发布归档 清单 SHA-256 SBOM 许可声明与校验既有产物此外python -m claude_ads_core status --root . --as-of YYYY-MM-DD可以离线查看仓库制品状态next则确定性返回下一个阻塞项。结语control-plane/RELEASE_REQUIREMENTS.md是 Claude Ads 发布流程的“宪法”它以六类累积门禁 一套外部签名评审协议把“来源可信、能力真实、变更可逆、构建可复现、模型可取证”这些工程原则固化成可执行、可审计的发布标准。理解这份文档不仅能看懂scripts/review_evidence.py、scripts/release.py、evals/model_eval_gate.py与control-plane/manifests/、control-plane/schemas/中大量看似繁琐的约束的由来更能在自己构建“证据驱动、失败关闭”的发布流水线时直接复用这套已经过测试验证的门禁设计。赞分享【免费下载链接】claude-adsClaude-first paid-media operations skill for Claude Code across 12 ad platforms (Google, Meta, YouTube, LinkedIn, TikTok, Microsoft, Apple, Amazon, Reddit, Pinterest, Snapchat, X): source-grounded audits, deterministic scoring, versioned JSON reports, and capability-gated account changes.项目地址https://gitcode.com/gh_mirrors/cl/claude-ads点击查看免费下载相关推荐Claude Ads Control Plane 全面解析公开安全的契约层、发布门禁与证据驱动治理体系Claude Ads Control Plane 全面解析公开安全的契约层、发布门禁与证据驱动治理体系 Claude Ads Control Plane 是Claude Ads 发布验证release-verifier代理全解析以证据为核心的全链路发布门禁实践Claude Ads 发布验证release verifier代理全解析以证据为核心的全链路发布门禁实践 导读 Claude Ads 是一个面向 12 个Claude Ads 仓库契约指南Agent 协作架构、开发原则与发布验证门Claude Ads 仓库契约指南Agent 协作架构、开发原则与发布验证门 本篇指南围绕 CLAUDE.md https://link.gitcode.co上一篇Outfit字体完整指南9种字重的免费开源几何无衬线字体下一篇CoastSat海岸线潮汐校正终极指南全球卫星海岸监测的精准解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考