Cookie、跟踪与隐私合规性
此技能将网站从“我们觉得我们有 Cookie 横幅”的状态推进到“这里有证据表明该站点对其服务的访问者合法行事”的状态。工作分为四个阶段：范围界定、审计、实施、验证。一个请求可能只需其中的某些部分（例如仅审计的委托在报告完成后就结束），但各阶段始终按此顺序执行，因为每个阶段都依赖于前一个阶段。
以下是驱动一切工作的三个核心理念。
行为才是关键，并且必须被测量。 监管机构和原告测试的是浏览器的实际行为：在选择之前、拒绝之后、撤销之后，存在哪些 Cookie 以及联系了哪些第三方。横幅本身证明不了什么。大多数真实发现是：横幅存在且看起来正常，但标签仍然触发了。因此，绝不要从存在某个同意工具、插件设置或代码行得出结论；而要从扫描结果得出结论。
规则取决于访问者是谁。 欧洲是选择加入（在同意之前不能有任何非必需的内容）。美国是选择退出，但夹杂着选择加入的领域和很大的诉讼风险。世界其他大部分地区介于两者之间。同一个网站对于一个受众群体可能是合规的，但对于另一个群体却可能违法，因此范围界定优先，且每个发现都必须针对指定的制度进行陈述。
一个撒谎的横幅比没有横幅更糟糕。 一个“拒绝”按钮如果无法阻止标签，就会把合规漏洞变成欺诈索赔（这几乎是加州所有执法行动的常见事实模式）。永远不要发布或保留一个装饰性的横幅。如果某些内容还无法被门控，就明确说明并移除这个承诺。
你不是用户的律师。提供清晰、实用的发现，并附上每一条发现背后的规则；指出法律不确定或事实需要法律判断的地方，并在报告中说明。也不要躲在免责声明后面：用户想知道要修复什么。
参考文件
根据委托需求阅读相关文件，而非全部。
| 文件 | 何时阅读 |
|---|---|
references/jurisdictions.md | 始终在范围界定阶段阅读。将网站受众映射到同意制度，并告知你应打开哪个法律文件。 |
references/law-europe.md | 任何欧盟/欧洲经济区、英国或瑞士的访问者。各国差异、横幅设计规则、分析豁免、执法情况。 |
references/law-us.md | 任何美国的访问者。各州法律阈值、GPC、加州具体规定、窃听诉讼、健康/儿童/金融相关。 |
references/law-rest-of-world.md | 加拿大、拉丁美洲、亚太地区、中东、非洲。 |
references/audit-playbook.md | 执行审计：扫描器使用、解读结果、检查代码和配置、诊断现有的同意工具。 |
references/failure-patterns.md | 解读扫描结果。解释大多数发现的 27 种模式。 |
references/implementation.md | 规划并实施修复：选择或修复同意工具、部署顺序、策略、GPC。 |
references/consent-signals.md | 接入特定供应商：Google Consent Mode v2、Meta、Microsoft、TikTok、TCF/GPP、Shopify、WP Consent API。 |
references/consent-tools.md | 在同意工具之间进行选择，或查找工具的 Cookie 名称、标记和 JS API。 |
references/script-blocking.md | 门控标签、嵌入内容、字体或服务器端事件；WordPress、Shopify、Next.js 和 SPA 的具体说明。 |
references/testing-tools.md | 验证：完整的测试矩阵、可访问性和性能检查、地理模拟。 |
references/report-template.md | 撰写审计报告或验证报告。 |
法律文件已于 2026-11-11 验证，并对每个声明标记了置信度标签。隐私法每月都在变化。当建议依赖于一个被标记为不确定、属于“流动变化”部分或超过几个月之久的细节时，请先对照当前的主要来源进行检查后再依赖它，并告知用户你重新检查了哪些点。
阶段 1：范围界定
在扫描之前确定以下内容。尽可能自行查找（网站、页脚、政策、代码库），然后只向你无法找到的信息询问用户。将问题控制在只有一轮。
- 哪些站点和主机。 主域名、子域名、独立的结账或应用域名、暂存环境。
- 访问者在哪里。 询问真实的受众，并对照证据进行检查：语言、货币、发货国家/地区、如果你有权限则检查分析中的地理位置数据。一个“仅限美国”的英文站点如果向全球发货，那就不只是美国。当一个站点针对某个地区的人群或为他们提供服务时，无论业务位于何处，该站点就会受到该地区法律的约束。
- 站点如何处理数据。 广告和再营销、分析、电子邮件营销、账户、电子商务、嵌入式媒体、聊天、会话回放。以及这些是否涉及敏感领域：健康、儿童或青少年、金融、精确位置、任何揭示受保护特征的信息。敏感领域会在每个司法管辖区改变答案。
- 规模（针对美国法律）。 大概的年收入和按州划分的访问者数量决定哪些州的法律适用。拥有广告 Cookie 的独立访问者算作“消费者”，因此阈值会比所有者预期的更快达到。
- 你拥有什么访问权限。 只读的公开站点、管理员登录、代码仓库、主机或 SSH、标签管理器、同意工具的控制台、广告平台账号。这决定了审计可以深入到什么程度，以及你是否可以进行实施。
- 用户希望得到什么。 仅审计报告，还是修复并验证。他们无法承受丢失的任何度量指标。付费工具的预算。
当还没有可以扫描的站点时（用户只是要求提供计划、报价或建议，没有给出 URL，或者仅凭记忆描述站点）：不要跳过测量环节，而是将其移后。把你被告知的信息视为假设，据此编写计划，并将“从每个目标区域进行扫描以确认起始点”作为计划的第一步，并在其中填入扫描器命令。说明计划的哪些部分依赖于你尚未观察到的事实。
然后打开 references/jurisdictions.md 并记下目标制度：对于每个受众，适用的制度以及将驱动发现的两三条规则。在审计之前，用几句话向用户说明这一点。如果受众未知或是全球性的，默认情况下对所有人都采取严格的选择加入制度，仅对法律明确的一小部分国家/地区进行放宽。
阶段 2：审计
遵循 references/audit-playbook.md。概要如下：
-
使用附带的扫描器扫描在线站点。 它会在一个干净的浏览器中加载站点，分别在几种不同的场景下（无交互、拒绝、接受、全球隐私控制，可选地包括撤销），记录每种情况下的 Cookie、网页存储、第三方请求和 Google 同意信号。
# 一次性设置 npm install --prefix <skill-dir>/scripts && npx --prefix <skill-dir>/scripts playwright install chromium node <skill-dir>/scripts/scan.mjs https://example.com --out ./scan-quick # 快速查看：首页 + 几个链接 node <skill-dir>/scripts/scan.mjs https://example.com --coverage types --out ./scan-us # 审计：站点地图中每种页面类型 node <skill-dir>/scripts/scan.mjs https://example.com --coverage all --out ./scan-full # 所有站点地图 URL（较慢） node <skill-dir>/scripts/scan.mjs https://example.com --coverage types --scenarios baseline,reject,accept,withdraw \ --proxy http://user:pass@de-proxy:8080 --locale de-DE --timezone Europe/Berlin --out ./scan-de对于任何将形成报告的内容，使用
--coverage types：页面模板各不相同（文章嵌入视频，产品页面加载小工具，联系页面加载验证码），而仅扫描首页会漏掉大部分内容。手工添加购物车、结账和感谢页面；它们不在站点地图中。首先阅读
summary.md顶部的“事实”表格，然后是截图，接着是你需要的每个场景的详细信息（在广告密集的站点上，详细信息会很长；搜索而非通读）。扫描器会报告其运行的地点。同意工具会根据访问者所在国家改变行为，因此一次扫描只描述那个国家的行为。 通过代理或 VPN 出口从每个目标制度进行扫描，或者在报告中明确说明哪些制度未被观察到。永远不要将基于美国 IP 的扫描结果呈现为关于欧盟访问者的证据。 -
尽你所能深入查看浏览器背后：每个标签在哪里注入的（主题、插件、标签管理器、硬编码、边缘端），同意工具是如何配置的，浏览器扫描无法看到的服务器端跟踪，以及可能会重新排序内容的缓存和脚本优化层。
有两种站点类型需要比默认运行更多的工作，操作手册也涵盖了这两种情况：一种是其优化器会保持每个脚本直到第一次鼠标移动或空闲定时器才加载（对其进行的快速扫描看起来是干净的，但实际上并非如此）；另一种是采用美国式选择退出且没有拒绝按钮的站点，其问题在于退出和 GPC 是否能覆盖到整个广告堆栈。当扫描器无法回答委托所依赖的问题时，使用相同的浏览器库编写一个简短的探测脚本，并将其与证据一起保存。
-
诊断已存在的同意工具。 通常会安装一个但只设置了一半。准确找出它失败的原因（操作手册中有一个决策序列），因为修复远更多是修理而非更换。
-
检查文档方面：隐私政策、Cookie 政策、必需的链接和措辞、表单及其同意语言、权利请求渠道、同意记录。
-
根据目标制度编写发现。 每个发现：观察到什么（附上扫描证据），对于哪个受众违反了哪条规则，严重程度如何，以及修复方法。使用
references/report-template.md。报告有两个层次：站点所有者可以执行的通俗易懂的总结，然后是为实施者提供的技术细节。
如果委托仅为审计，则在此处停止。在审计期间不要对站点做任何更改。
阶段 3：实施
遵循 references/implementation.md。要点如下：
- 首先就计划达成一致。 向用户展示将更改什么，他们会丢失或保留哪些度量指标，是否需要任何付费计划，并征得同意。移除或门控一个跟踪器会影响某些人的报告和广告效果；这是他们的决定，不是你的。
- 在安全的地方工作。 如果有暂存环境就在其上操作。在生产环境上：首先备份，一次只更改一件事，知道如何回滚，并且永远不要将站点留在横幅承诺了标签没做到的事情的状态中。
- 按依赖顺序修复：移除未使用的内容，建立一个同意工具作为同意的单一所有者，在任何标签加载之前设置同意默认值，通过同意工具门控所有标签和嵌入内容，接入供应商信号（Consent Mode 等），处理 GPC 和美国退出链接，使撤销功能正常工作，然后更新策略以匹配站点现在的实际行为。
- 更改后清除所有缓存层（页面缓存、CDN、压缩/合并的包），否则你将测试到的是昨天的站点。
阶段 4：验证
在重新扫描显示一切正常之前，没有任何东西是修复完成的。使用与审计相同的场景和观察点重新运行扫描器，并与审计运行进行比较。references/testing-tools.md 包含完整的矩阵；确认签收的最低要求是：
- 选择加入的受众：在选择之前和拒绝之后，包括在真实的鼠标和滚动输入之后，没有非必需的 Cookie 和跟踪器请求；拒绝按钮在第一层具有相同的突出程度；接受实际上加载了标签；撤销操作停止标签并移除第一方跟踪 Cookie；选择在页面之间持续有效，并且不会被再次询问。
- 选择退出的受众：退出链接和 GPC 各自在无需进一步点击的情况下停止出售/共享/定向广告标签；加利福尼亚州的访问者看到信号已被处理的确认；在涉及敏感数据的页面中，在同意之前没有任何内容触发。
- 所有地方：发出的 Google 点击上的同意信号与访问者选择的状态匹配；在缓存和未缓存的加载、移动端以及重要的页面类型（产品、结账、感谢表单）上结果相同；Cookie 策略列出了扫描发现的内容。
报告哪些通过了，哪些失败了，以及哪些无法测试（例如你没有观察点的地区，或者你没有访问权限的服务器端事件）。一个未经测试的检查应报告为未经测试，绝不要报告为已通过。
工作笔记
- 证据优于断言。 引用 Cookie 名称、请求主机、同意参数、截图。没有证据的发现只是意见。
- 未知的 Cookie 和主机是需要解决的发现，而不是忽略过去。确定它们是谁设置的以及用于什么目的，或者将其列为未解决。
- 严重程度取决于实际风险：受众是谁、涉及哪些数据、故障有多明显、该规则的执行或诉讼活跃程度如何。对于法国访问者或在美国健康页面上，广告像素在同意前触发是严重的。缺少一个印记链接则不是。
- 在法律允许的范围内保留用户的度量指标。 合规并不意味着删除分析数据。优先选择既能满足规则又能保留最多有用数据的选项：经同意门控的标签、Consent Mode、无 Cookie 或豁免配置的分析、特定区域的行为。解释其中的权衡，并让用户选择。
- 说明你没有检查的内容。 移动应用、电子邮件跟踪像素、离线数据共享、供应商合同和国际数据传输文件都是隐私合规的一部分，大多在网站扫描范围之外。指出看起来相关的部分，以免它们被假定为已完成。