AdCopilot

AdCopilot for Claude Code

这款 AI Agent 可帮你管理 Google Ads，并在同一个聊天中使用 Google Analytics、Google Search Console 和 Google Tag Manager。在 Claude Code 中审查无效支出、挖掘搜索字词、创建广告系列并修复转化跟踪。AdCopilot 会先提出每项更改。若要强制要求确认，请将 AI 客户端设置为在 AdCopilot 的写入工具执行前询问：在 Claude 中选择 Needs approval；在 Cursor 中使用 Allowlist 运行模式，并将这些工具排除在允许列表之外（Cursor 的云 Agent 不会询问）。AdCopilot 绝不会删除任何内容，负面关键字除外。此插件捆绑了托管的 AdCopilot 连接器，并提供连接器无法替你执行的操作步骤：在 Google 自有界面中需要点击什么，以及容易踩到的陷阱。

AdCopilot 由 Atromx Intelligence (https://adcopilot.cloud) 开发，与其他名为 AdCopilot 的产品无关。

此插件免费（MIT）。连接器是一项托管服务 — 方案见 https://adcopilot.cloud/pricing。

安装

每个平台都分两步：添加插件，然后登录插件附带的连接器。很多人会漏掉第二步，完成之前一切都无法使用。

AdCopilot 通过自己的 Google Cloud 项目，使用你的 Google 登录信息连接 Google Ads。如果你想为自己的软件以编程方式访问 Google Ads，请创建自己的 Google Cloud 账号，并在那里申请 Google Ads API 访问权限。

claude.ai、Cowork 和桌面应用

1. 添加插件：打开 插件目录中的 AdCopilot， 或前往 Customize，再选择 Plugins，然后搜索 AdCopilot。点击 Add。
2. 在插件中打开其 Connectors 选项卡，点击 adcopilot 旁边的 Connect，并登录。

连接器已列出 — 无需添加任何内容，也无需使用“Add custom connector”或连接器 URL：插件会为你注册连接器。如果你在安装插件前手动添加了 AdCopilot，也不会有问题：Claude 会通过 URL 关联连接器，因此你仍然只有一个 AdCopilot 连接器，就是同一个。

如果你直接从列表中点击 Try in Cowork，你会在完成第二步之前进入聊天 — 连接器会显示缺失。完成第二步，然后再次说“get me started”。

Claude Code

/plugin marketplace add AtromxIntelligence/adcopilot-claude-plugin
/plugin install adcopilot@adcopilot-claude-plugin
/mcp

最后一步会打开连接器列表。选择 adcopilot，并使用你自己的 Google 账号登录。无需执行 claude mcp add：插件会为你注册位于 https://mcp.adcopilot.cloud/mcp 的连接器。登录会关联你的 AdCopilot 工作区，因此你需要一个 AdCopilot 账号；你的 Google 产品只需在 AdCopilot 中连接一次，地址为 https://app.adcopilot.cloud，而不是在 Claude Code 中连接 — /adcopilot:setup 会告知你缺少哪些连接，并引导你前往相应页面。

Cursor

Cursor 会单独使用 AdCopilot 的连接器；此插件不会作为一个整体安装到 Cursor 中。插件中的技能是为 Claude 编写的，复制到 .cursor/skills 或 .claude/skills 后，Cursor 也能读取。在判断当前使用的是哪个客户端的地方（/adcopilot:setup、adcopilot-connect、日常习惯提示），它们会优先检查是否为 Cursor：如果是，就不会运行 claude mcp，而是到 Cursor 的 MCP 设置中查找连接器，也不会主动提供日程安排；如果 AdCopilot 的回复要求进行签到，技能就会按要求提示。

1. 添加连接器： 将 AdCopilot 添加到 Cursor 会打开 Cursor，并将连接器命名为 adcopilot。在 Cursor 中打开的 同一链接是 cursor://anysphere.cursor-deeplink/mcp/install?name=adcopilot&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vbWNwLmFkY29waWxvdC5jbG91ZC9tY3AifQ%3D%3D。 也可以将它添加到 ~/.cursor/mcp.json（适用于所有项目）或 .cursor/mcp.json （适用于单个项目）中：

   {
     "mcpServers": {
       "adcopilot": {
         "url": "https://mcp.adcopilot.cloud/mcp"
       }
     }
   }
   

2. 登录：Cursor 会在浏览器中打开 AdCopilot 页面 允许 Cursor 使用你的 AdCopilot？。点击 批准；无需粘贴 API 密钥。如果之前尝试时点击 批准 没有反应，请在 Cursor 的 MCP 设置中移除 AdCopilot，再重新添加并点击一次 批准；参见 点击批准没有反应。

3. 提问：“带我开始使用 AdCopilot”。

从 cursor.directory 添加？ 其中的 添加到 Cursor 按钮可能会将连接器命名为 server，因此 Cursor 的 MCP 列表和批准提示中会显示 server。它仍是同一个连接器。上面的链接会将它命名为 adcopilot。

Cursor 中的批准设置。 Cursor 没有 需要批准 设置；其运行模式决定相关行为，可在“设置”中的“Agent”>“批准与执行”中设置（截至本文撰写时）。在 允许列表 模式下，允许列表中的工具无需询问即可运行，其他工具则会先询问，因此请勿将 AdCopilot 的写入工具加入允许列表。在 Cursor 推荐的默认模式 自动审核 下，允许列表中的调用也会立即运行，而所有其他 MCP 调用都会交由分类器处理，分类器可能会在未经询问的情况下允许更改。运行所有操作 模式不会在执行前询问，而 Cursor 云 Agent 也不会请求你批准操作。无论使用哪种模式，AdCopilot 都会先提出每项更改建议，只会删除否定关键词，并且创建的每个广告系列都会暂停。

然后，在所有界面中

登录连接器会关联你的 AdCopilot 工作区，因此你需要拥有 AdCopilot 账户。你的 Google 产品——Google Ads、Analytics、Search Console、Tag Manager——只需在 AdCopilot 内部的 https://app.adcopilot.cloud 连接一次，无需在 Claude 中连接。因此，刚登录时可能会显示没有已连接的产品：这是服务的正常响应，并非故障。

请先运行 /adcopilot:setup。它会说明哪些内容已连接、哪些尚未连接，并将你引导至相应页面。

如果你在安装前已经手动添加了连接器（仅适用于 Claude Code；网页版没有此命令），Claude Code 会保留你的配置，并默默忽略插件的配置：运行 claude mcp list 后会显示一行不带前缀的 adcopilot:，而不会显示 plugin:adcopilot:adcopilot。请从所有配置范围中移除你添加的连接器——运行 claude mcp remove adcopilot -s user，并在添加连接器的目录中运行 claude mcp remove adcopilot -s local，因为本地注册仅适用于该目录。随后，插件的配置行就会出现，并提示你登录。

你将获得

七个可供输入的命令：

• /adcopilot:setup — 检查连接器是否已连接并登录，说明每个已连接产品能解锁哪些功能，并排查全新安装时常见的两种问题：登录已失效，以及在 Claude Code 中，安装前手动添加的连接器副本。
• /adcopilot:launch — 通过下方的 adcopilot-launch 技能创建首个搜索广告系列。
• /adcopilot:measure — 通过下方的 adcopilot-measure 技能设置转化跟踪。
• /adcopilot:daily — 每日检查：本月预算消耗进度、过去 7 天中花了钱却一无所获的搜索、Google 已拒登或限制投放的广告，以及自昨天以来账户发生的变化和操作人——按此顺序汇报，具体内容以 AdCopilot 为单次回答设置的读取量为限。
• /adcopilot:weekly — 对比上周一至周日与前一周：花费、转化次数和单次转化费用、三项最大变化，以及本周要做的三件事，内容可直接转发。
• /adcopilot:negatives — 按主题整理过去 7 天中花了钱却一无所获的搜索，并列出可屏蔽这些搜索的禁止展示词（否定关键字）；先提出建议（命令会询问要屏蔽哪些主题），添加后再读回确认。
• /adcopilot:audit — 全面审计连接器并检查本月预算消耗进度；将仅是新账户症状的发现单独列出；提出第一个修复方案，并说明执行和不执行的代价；完成后读回确认，再提出下一个方案。

Claude 会在对话需要时调用以下九项技能：

• adcopilot-connect — 设置 AdCopilot，连接你的 Google 产品，并按合适的顺序将它们相互关联；每完成一步，都会说明这一步带来了什么。

• adcopilot-measure — 端到端设置转化跟踪：Analytics 媒体资源和数据流、Tag Manager 标签、关键事件、Analytics 到 Ads 的关联与导入；最后确保只有一个主要转化，并通过真实点击加以验证。

• adcopilot-launch — 按你指定的预算和出价创建一个默认关闭的首个 Search 广告系列：包括地理位置、不展示的搜索词、广告组、带匹配类型的关键字、广告和素材；通过读取广告系列来验证可能导致资金浪费的设置；交给你启用开关，并请你在启用后告知它，以便读取第一天的投放情况；还会执行第一周的检查，在你前往任何页面之前，先读取已启用的广告系列为何没有投放。

• adcopilot-daily — Claude 定时任务或 Claude Code 日常例程在无人值守时运行的晨间检查：它只读取信息，绝不提问；开头会显示“Everything is fine”（一切正常）或“Needs attention”（需要关注），结尾会以是/否问题的形式提出一项值得执行的修复，供你打开报告时决定。你回答“是”后，它会重新读取修复涉及的内容，并再次说明要做的更改，然后才执行，因为到那时报告已有数小时之久。它还包含设置该定时任务的步骤。

• adcopilot-review — 日常使用的技能：读取账户并说明发生了什么、花费了多少、哪些地方在浪费资金以及需要更改什么；然后提出更改方案，你回答“是”后便会应用；接着读取该更改本身的结果无法显示的内容，并以相同方式提出下一项修复。它会以 full_audit 开始，因为一次视角读取就能回答手动编写十几个查询才能回答的问题；它将 AdCopilot 为回答一次问题而规划的读取次数视为可使用的资源，而非必须低于的上限，更不是每日限额。

• adcopilot-fix-checks — 修复 AdCopilot 审计标记的问题，适用于你点击审计页面或电子邮件中的“Fix all three”（全部修复这三项）或“Fix this”（修复此项）按钮后发送问题的情况。它会先说明修复成本和今天涵盖的操作，先处理检查基础（先统计结果，再处理依赖这些结果的项目），只读取每项修复所需的内容，不会再次运行审计；并将每项修复作为一个是/否问题交给你决定，任何列表最多显示五行。搜索词检查会指向不展示的搜索词，零转化关键字会建议暂停，转化跟踪检查则会说明 AdCopilot 能执行的步骤，或告知哪些操作只能在 Google Ads 中点击完成。每项更改都会在进行下一项检查前读回，并说明如何撤销。

• adcopilot-docs — 根据你当前的工作区，而非凭记忆，回答关于 AdCopilot 本身的问题：它能访问哪些产品、今天还剩多少次查询以及用完后会发生什么、你使用的套餐、它获准更改的内容、数据会发送到哪里，以及调用失败时该怎么做。套餐和价格会提供链接，绝不直接引用。它只读取一次你的工作区来作答，不会读取你的账户或启动其他技能，并会用一份列表说明 AdCopilot 能做什么。如果问题涉及读取账户即可回答的内容，它会以一个提议进行读取的问题结尾；如果问题涉及查询次数、账单、隐私或安全，则不会提供其他建议。

• adcopilot-seo — 通过 Search Console 回答 Google 搜索如何看待你的网站：哪些页面获得点击，哪些页面毫无点击；用户输入了哪些词来找到你；站点地图是否正在被读取；以及某个页面最近一次被抓取的时间。它会重点说明容易造成误判的数据——站点地图中失效的“已编入索引”列、并非排名的平均排名，以及并不代表需求的展示次数——并明确说明它无法看到的内容：没有全站覆盖情况列表，也无法读取处罚信息，因此它会请你提供 Search Console 的“Pages”（页面）导出文件，而不是凭空猜测。修改上线几天后，它会提议再次检查页面；如果已连接 Google Ads，它还会提议将你付费购买的搜索词与已为你带来自然点击的搜索词并列比较。

• adcopilot-meta — 用于询问 Meta 广告（Facebook 广告、Instagram 广告）或 Meta 与 Google 相关问题。AdCopilot 没有 Meta 集成（已列入路线图，但没有确定日期）；Meta 则为 Meta 广告提供了自己的连接器，因此此技能会先在对话中查找 Meta 的连接器。如果没有，它会说明连接器是什么以及如何添加，并提供 Meta 帮助页面 和 AdCopilot 指南的链接；对于 Meta 未发布的条款，它不会作出任何说明。如果有连接器，Meta 的数据来自 Meta 的连接器，Google 的数据来自 AdCopilot，并分别标明来源；从一方读取的信息不会发送给另一方；通过任一连接器进行的任何更改都会先提交给你决定，并且一次只处理一个平台（如需彻底阻止写入，请按本页顶部的说明，将两个连接器的写入工具都设为“询问”）。AdCopilot 绝不会向 Meta 写入数据。 当对话任务过大时，Claude 会将其交给一个 Agent：

• adcopilot-auditor — 端到端全面审计账户，并返回发现的问题、背后的数据以及值得采取的更改。它只读取并提出建议：它没有写入工具，因此无法应用任何更改；发起该任务的对话会征求你的同意。

结合上方的连接器注册信息，这些命令、技能和 Agent 就是此版本插件所包含的全部内容。

每天早晨，无需询问

上述每条命令，以及 connect、launch、measure 和 fix-checks 技能，都会在 AdCopilot 自己的回答向它们提供适用于你的 AI 客户端的设置步骤（routine.schedule）时，简短提议将每天检查账户变成日常习惯。适用条件是：账户中有已开启的广告系列、尚未报告任何日程安排，并且 AdCopilot 会为该客户端提供日程安排步骤；目前只有 Claude 符合。AdCopilot 不会为 Cursor、ChatGPT 或其他客户端提供相关步骤，因此插件不会主动为这些客户端提出设置日程的建议；在 Cursor 中，如果 AdCopilot 的回答要求提供签到或摘要建议，插件就会按 AdCopilot 的措辞提出该建议。只有在不要求你对某项修复作出是或否答复的回复中，才会单独以一个段落提出此建议：回复复述你批准的第一项修复，并以此代替对下一项修复的确认（下一项修复会在随后提出的回复中点名并给出建议）；或者在没有提出任何修复的回复结尾。当该修复针对晨间检查也会读取的某项发现时（搜索有花费却没有带来销售、广告系列预算不足、广告被拒登、指标较 7 日平均值下滑、未经请求的更改；但 Free 每天 10 次操作的情况下除外，此时检查会把更改留给聊天处理），建议会与之关联：如果检查在每个工作日早上 8:07 自动运行，就能在第一个早上发现该问题。对于其他发现或没有发现问题的情况，建议只会作为回复结尾提出，不会作出上述承诺。在 claude.ai、Cowork 或桌面应用中，它是 Claude 的定时任务；在 Claude Code 中，它是通过 /schedule 创建的例行任务，并会提议为你创建。说“安排吧”，它就会引导你完成设置步骤；说不，它就不会在该对话中再次提出，而是会询问一次你的 Claude 是否支持定时任务，并记录答案，因此回答否会暂停一周的建议，而 Claude 不支持定时任务则会彻底停止建议。它只会从 Claude 记录该答案，因为 AdCopilot 会在整个工作区中保留此信息。AdCopilot 一旦报告已有日程安排，就会永久停止提出建议——无论是你通过它记录的日程，还是已在不同日期运行并签到两次的定时任务。

你保存的指令会逐字采用 AdCopilot 自己的晨间检查流程，并填入你的账户信息。每次运行会读取约 6 到 7 次，每次读取都会计入工作区的每日操作次数；星期一时，每日检查和每周摘要加起来可能用完 Free 工作区的 10 次操作。在 Free 版以及每日限额为 10 次操作的试用版中，预算进度分析等分析操作计为 2 次，单次读取计为 1 次，因此 5 次读取大约会用掉 Free 每日 10 次限额中的 8 到 10 次，有些日子会全部用完；这种情况下，运行只会进行前 4 次读取，约 6 次操作，并把更改留给聊天处理，这样结束时提出的修复仍能在当天完成。在付费方案或仍在运行的试用版中，每次读取都计为 1 次操作。如果 AdCopilot 已经每天向你发送签到邮件，它仍会继续发送；如果你只想保留一种方式，可以在 AdCopilot 首页上的 Routine 卡片中暂停邮件。定时任务需要 Claude 方案支持；在 Claude Free 方案和 Cursor 中，如果启用了 AdCopilot 的每日签到邮件，晨间检查就由该邮件提供。 定时运行会被要求不要更改任何内容。 adcopilot-daily 提供给你的指示是只读的，不会提出任何问题；它发现的修复建议会留待你打开报告时再处理。AdCopilot 也会将定时运行限制为只读：一旦运行的第一个调用是 get_org_context，且 source: "claude-scheduled"，AdCopilot 就会在该连接上拒绝运行余下时间（最长 20 分钟）内所有会更改 Google Ads、Analytics、Tag Manager 或 Search Console 的工具调用，不管 Claude 允许什么（AdCopilot 自己的备注除外）。它只会根据第一个调用判断运行是否为定时运行，因此，跳过这个调用或发送其他来源的运行不会受到限制；运行期间在该运行自己的对话中输入的“是”也可能被拒绝，请在新对话中再说一次。Claude Code 还会额外施加一项限制：AdCopilot 将 set_campaign_status（暂停或启用广告系列的工具）标记为需要人工确认，因此，Claude Code（2.1.214 或更高版本）不会在你电脑上无人应答的运行中使用它，例如 claude -p。插件的技能只会通过该工具暂停或启用广告系列，绝不会通过 update_campaign 在更改广告系列设置时设置状态，而这个标记不会限制此类更改。Claude Code 的例行任务会在不询问的情况下运行工具，切换到 Automatically approve 的定时任务也是如此；在这些情况下，是第一个调用和指示确保运行只进行读取，因此请保持原样。在 claude.ai、Cowork 和桌面应用中，将 AdCopilot 的其他 Write/delete tools 全部设为 Blocked（仅保留下面两个 AdCopilot 工具），就能彻底阻止更改，无论是在任何聊天中还是定时运行中。

Claude 中定时任务需要的唯一设置。 在 claude.ai、Cowork 和桌面应用中，如果运行时无人应答，就会在 Claude 询问是否调用第一个工具时停止。因此，设置的第一步是在 AdCopilot 的 Tool permissions 中（选择 Customize，然后选择 Connectors，再选择 AdCopilot）：将 Read-only tools 设为 Always allow，并且在 Write/delete tools 下，将 AdCopilot 自带的两个工具“AdCopilot: what is connected and where you are”和“AdCopilot: save business notes and progress”也设为 Always allow。它们只会保存 AdCopilot 自己的备注，不会更改 Google Ads；其他所有 Write/delete 工具仍设为 Needs approval，因此 Claude 会在每次更改前询问（Cursor 没有此类界面；请参阅上面的 Cursor 中的审批）。自 AdCopilot v2.42.3 起，Claude 将前述两个工具中的第一个列在 Write/delete tools 下，而它是每次运行的第一个调用；因此，如果任务只将只读工具设为 Always allow，就会像插件截至 0.2.13 版本的设置步骤所述那样停在此处。将这两个工具设为 Always allow 就是完整的解决办法。

它不会做什么

• 开启它创建的广告系列。 它创建的每个广告系列都会设为暂停状态。你需要自行在 Google Ads 中将其开启。
• 删除否定关键词以外的任何内容。 连接器会在服务端拒绝 REMOVED 状态：广告系列、广告组、广告和关键词工具仅接受 ENABLED 或 PAUSED，而素材工具会直接拒绝删除操作。对于这些项目，最多只能暂停；这是由服务端强制执行的，而不是靠助手自觉。唯一的例外是有意为之：添加否定关键词的三种方式都各自提供了移除操作，因此可以撤回否定关键词——这正是 AdCopilot 所说的“你可以撤销”确实成立的原因。关联共享否定关键词列表则是真正的单向操作；没有取消关联工具，而且必须在 Google Ads 的“工具”、“共享库”、“排除列表”下取消关联列表。
• 趁你的 AI 客户端在调用 AdCopilot 的写入工具前询问你之前，擅自更改你的账户。 读取操作可直接执行，AdCopilot 会先提出每项更改。若要彻底阻止，请将 AI 客户端设置为在调用 AdCopilot 的写入工具前征求同意：在 claude.ai、Cowork 和桌面应用中选择 需要批准；在 Claude Code 中，不要将这些工具加入允许列表，并确保会话不处于 auto 和 bypassPermissions 模式；在 Cursor 中，使用 允许列表 运行模式，并且不要将这些工具加入允许列表（参见上文的 Cursor 中的审批；Cursor 的云端 Agent 永远不会询问）。如果关闭询问，更改现有内容、预算或已开启的广告系列都会直接生效；只有新广告系列仍会以暂停状态创建。唯一的例外是 set_campaign_status，这个工具用于暂停广告系列或将其开启：Claude Code（版本 2.1.214 或更高版本）每次使用它前都会征求同意，无论设置如何；如果运行期间无人可以答复，就无法使用它。Claude 桌面应用也可能每次使用该工具时都征求同意。此插件的技能只会通过该工具暂停或开启广告系列，绝不会通过更改广告系列设置（update_campaign）时设置状态来执行；后者与其他更改一样，会遵循你的设置。

支持

• 插件出了问题（命令、技能或本 README）：在此提交 issue。
• 连接器出了问题（登录、工具调用或账户）：[email protected]。

AdCopilot 版本

0.2.16（2026-10-23，基于 AdCopilot v2.44.1 编写；发布此版本前，v2.44.1 必须已上线；撰写本文时，生产环境中的版本是 v2.44.0）：标记此版本前必须执行以下发布检查清单；撰写本文时，除结构测试和 claude plugin validate --strict 外，清单中的步骤均未执行。 现在，目录条目的名称和描述会列出人们搜索的所有 Google 产品。客户或模型读取的内容没有变化：没有任何技能、命令、Agent、工具或 .mcp.json 的内容或行为发生变化。清单文件中的显示名称改为 "AdCopilot for Google Ads, Google Analytics (GA4), Google Search Console & Google Tag Manager"。描述以 Agent 的功能开头，其中的每项声明都已对照 AdCopilot v2.44.1 的工具核实：Keyword Planner 数据（get_keyword_ideas、get_keyword_metrics、get_keyword_forecast）、Search 和 Performance Max 广告系列的创建（create_campaign、create_performance_max_campaign）、无法在 Shopping 中展示的 Merchant Center 产品（shopping_product_issues，在 v2.44.1 中新增），以及 AdCopilot 唯一会移除的内容——否定关键字。描述保留了审批语句（包括其中关于 Cursor 的从句）和否定关键字语句，且逐字不变，因为结构测试要求两者都必须保留。关键词从 20 个增加到 28 个：keyword-planner、keyword-research、merchant-center、google-shopping、shopping-ads、seo、local-services-ads（lsa_leads 和 lsa_rate_lead，在 v2.44.1 中新增且默认启用）以及 google-ads-reports。每个文件中的标记都改为 claude-plugin/0.2.16，eval 测试样例中 get_org_context 的返回值所带的 plugin.version 也同步更新，因为结构测试要求两者都与清单文件中的版本一致；这些是对技能、命令、Agent 或 eval 文件的唯一改动。本文未运行任何 eval 测试：模型读取的内容与 0.2.15 版相同，只是版本号有所变更。 0.2.15（2026-10-23，基于 AdCopilot v2.44.0 编写，已于 2026-10-22 部署）：标记此版本前必须运行下方的发布检查清单；撰写本文时，除结构测试和 claude plugin validate --strict 外，清单中的步骤均未运行。 客户或模型读取的内容没有变化：没有任何技能、命令、Agent、工具或 .mcp.json 的内容或行为发生变化，清单中除版本号外也没有任何改动。插件目录的提交前检查清单规定，除图像或字体外的所有文件都必须小于 256 KiB，否则该版本将暂缓发布，等待审核；插件文件数不得超过 512 个。在 0.2.14 版本中，结构测试集中在一个文件 tests/test_structure.py 中，共 273,469 字节，超出该限制 11,325 字节；第二大的文件 README 为 93,719 字节，远低于限制；插件共有 242 个文件。现在，该文件已按主题拆分为六个文件：tests/test_daily_habit.py、test_unattended_run.py、test_manifest_and_marker.py、test_review_and_audit.py、test_handoff_and_approval.py 和 test_eval_cases.py，最大的文件为 66,136 字节；这些测试共用的辅助函数放在 tests/structure_helpers.py 中。测试内容原样迁移，类、测试名称和断言均未改变：迁移前后都是 252 个测试。唯一的测试内部改动是，那三个用于锁定本 README 中 0.2.14 说明的测试，现在会按说明自身的版本号查找，而不是按清单中的版本号查找，因此未更改其所锁定内容的版本发布时不必重复该说明。新增的 tests/test_plugin_size.py 会在除图像或字体外的任何文件超过 250 KiB，或插件文件数超过 480 个时失败，并指出文件名；因此，本仓库现在会自行检查该限制。插件共有 249 个文件。每个文件中的标记都更新为 claude-plugin/0.2.15，评估用例中的 get_org_context 返回值所携带的 plugin.version 也更新为此版本，因为结构测试会检查两者是否与清单中的版本一致；这些是对技能、命令、Agent 或评估文件的唯一改动。本文未运行任何评估用例：模型读取的内容与 0.2.14 版本相同，只更新了版本号。 **0.2.14（2026-10-23，基于 AdCopilot v2.44.0 编写，部署于 2026-10-22）：标记此版本前必须执行下方的发布检查清单，而撰写本文时其中尚无任何步骤执行。**更改了插件告知模型的内容，新增一个技能和两个用例，清单文件只改了版本号。首先，也是此版本率先发布的原因：从插件安排的晨间检查不再会在第一次调用后停止。从 AdCopilot v2.42.3 起，Claude 会在“写入/删除工具”下列出 get_org_context，标题为“AdCopilot：已连接的内容和你所在的位置”；而截至 0.2.13，设置只会将只读工具设为“始终允许”，因此按这种方式设置的运行会在第一次调用时等待批准，却无人能批准。现在，每日技能中 Claude 的首个设置步骤与 AdCopilot 自己的步骤一致（schedule_recipe.ALWAYS_ALLOW_STEP）：在 Customize、Connectors、AdCopilot、Tool permissions 中，将只读工具设为 始终允许，并将“写入/删除工具”下的“AdCopilot：已连接的内容和你所在的位置”以及“AdCopilot：保存业务笔记和进度”也设为 始终允许，因为它们只会保留 AdCopilot 自己的笔记，绝不会更改 Google Ads；其他所有“写入/删除工具”仍设为 需要批准，因此 Claude 在每次更改前仍会询问（Cursor 没有此设置页面；参见上文的 Cursor 中的批准）。本 README 的晨间检查部分也说明了同样的内容，而且将其他写入工具设为“已阻止”的建议会排除这两个工具，因为阻止它们会使每次运行都无法继续。设置步骤提供的指令与 AdCopilot v2.44.0 的晨间检查配方逐字相同，其中首次调用现在是：先调用 get_org_context，source 为 "claude-scheduled"，task 为 "AdCopilot morning check"。AdCopilot 只会将首次调用也注明该任务的运行计为晨间检查，因此客户自己的定时任务属于定时运行，而不是晨间检查，不再会结束晨间检查的提示；即使较旧的已保存配方副本未注明该任务，每日技能的运行也会在指令以 "AdCopilot morning check" 开头时发送该任务；若定时任务的措辞不同，则绝不会发送；现在 daily-scheduled-run 的首次调用若缺少该任务就会失败。其次（#22），所有发送插件标记的文件（source 设为 claude-plugin/0.2.14）现在都加上一句完全相同的话，说明由 Claude 定时任务或 Claude Code 例程启动、且无人可响应的定时运行，会改为发送 source: "claude-scheduled"，绝不会发送 claude-plugin。此前只有每日技能的运行会这样说明，而客户用自己的措辞设置的定时任务由审查技能响应后，会以有用户参与的对话形式到达 AdCopilot。新增用例 review-scheduled-unmarked 由 adcopilot-review 负责，覆盖的就是这种运行。本版本不会更改的内容：每日技能的运行仍不会调用 save_org_context。0.2.14 之前设置的每个定时任务，都会继续在调用此工具时要求批准；定时运行无法响应批准提示，因此如果运行要保存笔记，就会停在那里，无法完成。只有在 AdCopilot 通知已经安排检查的用户将这两个工具设为 始终允许，且该通知经过验证后，才会解除此限制。第三至第八项更改（#24）源自 2026-10-20 的一次对话，发生在一个每天有 10 次操作额度的工作区：审计页面上的“在 Claude 中修复全部三项”问题收到了三个编号选项菜单，每项检查最多还进行了三次相关读取；每日习惯提示在三项检查中的第一项之后出现；当天操作额度在客户同意的修复运行前就用完了。第三，新增技能 adcopilot-fix-checks，用于处理 AdCopilot 审计页面和电子邮件发出的提问，例如“我的 AdCopilot 对 Google Ads 账号……的审计标出了三项应优先修复的检查”，或某项检查“失败”或“发出警告”的提问；每项检查都会在方括号中注明 ID。该技能会先说明修复所需的操作次数（读取每项检查的操作次数，加上每个被暂停的关键字、以及每个新增排除词的广告系列或列表各需一次调用，再加一次回读），并说明今天能完成哪些内容；它会自行建议顺序，先处理基础项（在任何用于判断的内容之前先统计结果）；使用每项检查各自的视角读取检查结果，且不会启动新审计；每项修复都向客户提出一个是/否问题，任何列表最多显示五行；每项更改都会回读，并说明如何撤销；只有在修复已应用并回读后，才会提示客户养成每日习惯。搜索词检查（G18 及其同系列）会处理为排除词，零转化关键字（G-WS1）会处理为暂停，转化跟踪检查（G43 及其同系列）则会执行 AdCopilot 能完成的步骤，或在 AdCopilot 无法更改时告知客户在 Google Ads 中点击的位置。在即将用掉当天最后一次操作的调用前，它会说明该调用将处理什么，并先询问客户。其用例 fix-checks-three-checks 为新增用例，撰写本文时尚未运行。第四，在所有包含每日习惯提示的八个文件中（fix-checks 本身包含该段内容）以及 adcopilot-review 中，只有在回复不要求客户对修复作出是/否答复时才会提出每日习惯提示：可以是在回读客户批准的首项修复时提出，此时该提示代替下一项修复的是/否问题（下一项修复会在回复中用一行说明，并在之后的回复中提出），也可以是在没有提出修复的回复结尾处提出。若晨间检查也会读取某项问题，那么对该问题的修复仍可使提示说明晨间检查本可发现它；但对于每天只有 10 次操作、晨间检查会把更改内容留给聊天处理的工作区，未经客户要求的更改则应使用结尾处的提示。第五，每条回复只做一个决定。adcopilot-review 和 /adcopilot:negatives 都以一个关于其建议步骤的是/否问题结束，绝不提供编号菜单或要求客户选择顺序；任何列表最多显示五行，按成本从高到低排列，之后注明“以及另外 N 项”；在 Claude Code 中，它们会通过 AskUserQuestion 工具提出该是/否问题。adcopilot-review 还会说明一次调用涵盖什么，并在即将用掉短缺额度工作日最后一次操作的调用前先询问。第六，related_reads：现在所有界面最多只会运行一次与问题有关的读取（此前为三次），与 AdCopilot 自 v2.43.3 起的自身指令一致。第七，/adcopilot:negatives 不再包含 disable-model-invocation，因此客户要求屏蔽搜索词时，模型可以启动它；其描述现在说明，AdCopilot 审计中的检查由 fix-checks 技能处理，而关于广告效果的问题由 review 技能处理，这正是 0.2.12 中该标记的用途。fix-checks 的步骤会使用已读取的搜索词结果执行写入步骤，不会启动该技能，否则就会再次读取最近七天的数据。第八，在每天只有 10 次操作的工作区中，无人值守的晨间检查只会执行前四次读取，并将更改内容留给聊天处理，因此报告结尾提出的修复仍能在同一天完成：按 0.2.13 的权重计算，四次读取会用掉 Free 的 10 次额度中的 6 次，而五次读取会用掉 7 次；一次运行约需 8 到 10 次操作。每日技能的运行、设置步骤和本 README 都会说明这一点。第九（#25、#28），审计的检查数量。AdCopilot v2.44.0 的审计包含七十项检查，每项都单独列出，并根据适用于该账号的检查项计算评分。review 技能和审计器会将原先的七十三项改为七十项，并将覆盖范围表述为结果给出的数量：“适用于该账号的 M 项检查中，共 N 项”，绝不使用百分比。评估 mock 中的审计结果采用 v2.44.0 的数量；tests/test_check_count.py 会在检查项数量超过七十时失败，但评估工具快照（_tools.json）除外；这些快照会保持原样，直到从服务端完整刷新（issue #5）。第十（#26），审计发现项的修复。从 v2.44.0 起，发现项可在 recommended_actions 中附带修复：可以是可直接调用的工具（kind 为 tool），其 ID 从账号读取，审计的 negatives 为 Exact；也可以是草稿（kind 为 skeleton），其 needs 字段说明只有客户才能提供的内容，例如要屏蔽的搜索词，或要从中调拨预算的广告系列。fix-checks 和 review 技能会按原样提出可直接调用的工具，并附上其 why 字段给出的条件；对于草稿，它们会在唯一的问题中询问 needs 所列的信息，绝不会自行补全；review 技能自身的 PHRASE 规则现在仅适用于它自己编写的 negatives，因此绝不会重写审计提供的 Exact 调用。发布顺序：所有服务端部分都已上线，包括 AdCopilot v2.44.0，因此服务端无需等待此版本。从 v2.43.3 起，AdCopilot 会将运行中账号的审计问题交给 fix-checks 步骤处理；如果 Claude 调用时未带标记，或只带有 claude-plugin，AdCopilot 会告知它先加载已安装的技能，但不会把当前轮次交给它；在较旧的服务端上，技能仍会运行，但 next_step 只会给出 review 步骤。每个文件中的标记都会改为 claude-plugin/0.2.14，评估夹具的 get_org_context 响应中的 plugin.version 也会改为该值。撰写本文时，没有运行任何评估用例。 0.2.13（2026-10-20，基于 AdCopilot v2.43.1 编写，2026-10-20 17:51 UTC 部署）：下方发布检查清单要求在标记此版本前执行其中的步骤；但与 0.2.10 和 0.2.12 一样，创始人于 2026-10-20 决定发布 0.2.13（“do the plugin release”），因此没有执行真实账户步骤 1 至 6；也像 0.2.10 一样，没有运行评估套件，因为这次改动仅涉及文本。步骤 7：两次 claude plugin validate --strict 运行均通过，tests/test_structure.py 中的结构测试也通过；针对这段文本，既没有运行套件，也没有运行仅含工具的消融测试。对插件告知模型的内容做了一处更改（#23），除了版本号外，清单没有改动：Free 的加权操作数。从 v2.43.1 起，AdCopilot 按加权操作数统计 Free 工作区的调用：完整审计或账户健康评分计为 4 次，预算进度分析等分析计为 2 次，列出受众计为 2 次，其他每次调用计为 1 次；但有四个调用从未计入（AdCopilot 自己的 get_org_context 和 save_org_context、get_resource_metadata 和 list_accessible_customers），仍计为 0 次。付费计划和正在运行的试用版则每次调用都计为 1 次；如果试用版受限于 Free 的每日 10 次调用（因银行卡暂停，或等待首次扣款），则按 Free 的规则计费。每日技能根据 get_org_context 返回的 org.ops_weighted 计算成本；v2.43.1 将该字段加入了 org 区块，因为受限试用版的 plan 仍显示为 pro。现在，每日技能（运行和设置时）、本 README、/adcopilot:audit（两次调用共占用 Free 10 次额度中的 6 次）和 /adcopilot:weekly（四次读取约占用 5 或 6 次）都说明了成本；每次运行相关读取还会多占用 1 或 2 次。按该计费表，晨间检查的五次读取共计 7 次操作，一次运行约占用 Free 10 次额度中的 8 至 10 次。付费计划不受影响。只有当 AdCopilot 的加权开关不是 off 时，AdCopilot 才会发送 ops_weighted（v2.43.1 中该开关设为 free）；若将其重设为 off，每日技能会自动恢复按读取次数计数，但本 README 和两个命令会高估 Free 的成本，因此这段文本也要随开关一起回退。.gitignore 现在会排除 Python 编译缓存，tests/test_structure.py 会检查每条句子，并在有缓存被纳入版本控制时失败。每个文件中的标记都改为 claude-plugin/0.2.13，评估测试固定数据中 get_org_context 的响应所带的 plugin.version 也改为此版本。AdCopilot 可读取 0.2.7 及更高版本，且 v2.43.1 已上线，因此服务端无需等待此版本。 0.2.12（2026-10-17，与 2026-10-18 的 AdCopilot v2.41.0 对齐）：下方的发布检查清单规定，必须在标记此版本前执行其中的步骤；但应创始人要求（“release Plugin 0.2.12”），0.2.12 于 2026-10-19 被标记，未执行针对真实账户的步骤 1 至 6，与 0.2.10 一样。步骤 7：两次运行 claude plugin validate --strict 均通过；测试套件（Claude Code 2.1.303、评审模型 sonnet，针对 AdCopilot v2.42.0，2026-10-19，evals/results/rerun-v10-2026-10-19T14-27-25Z，已加入 gitignore）中，除三个习惯提议案例外，所有案例都以 0.8 通过。这三个案例的结果在不同运行间有所波动：在 v8 和 v10 两次运行中，同一个未改动的案例先通过后失败（habit-offer-chat 从 0.956 变为 0.778，habit-offer-untold 从 1.000 变为 0.690），因此创始人决定采用 v8 的措辞，而不是每个案例只运行两三次就继续迭代。仅工具消融测试通过：review-follows-related-reads 作为防护项保持有效（仅工具测试为 0.932）；meta-connector-absent、review-question-first-roomy 和 daily-scheduled-run 则分别以 +0.333、+0.292 和 +0.238 的差值通过门槛。改动只涉及插件告知模型的内容，清单中除版本号外没有其他改动。这些改动来自 2026-10-14 在一个没有每日限额的工作区中进行的一次对话；每句话都确保对 AdCopilot v2.41.0 仍然属实，而此版本发布前必须先上线该版本：下文的日期、覆盖数量和高成本搜索列表都对应该版本。

第一，读取上限。cross_reads.ads_reads_max 表示服务为当前情况预留了多少次 Google Ads 读取：这是单个答复的读取次数，不是工作区、套餐或每日限额。现在，所有提到该数值的地方都会说明这一点；只有存在 cross_reads.reads_left_today 时，才会说当天剩余时间不多；并且会把剩余的读取次数作为下一次读取提出，以陈述而非第二个问题的形式表达（“下一次读取可以显示每个广告系列的出价方式；你说一声，我就运行。”），而不会把它说成限额；在那次对话中，审查只进行了五次读取，就称自己已经达到“今日读取限额”。adcopilot-review 还会在 What breaks 下新增一条规则：只有在存在 reads_left_today，或某次调用返回了每日上限拒绝信息时，才提及每日限额、配额或今日查询次数。/adcopilot:daily 和 adcopilot-launch 不再把这个数称为上限。相关读取仍计入答复的读取次数。从 v2.41.0 起，在非计划运行日，当账户有支出但没有计入任何结果，且没有每日限额或限额至少为 6,000 时，AdCopilot 会将读取次数设为八次，而不是五次：先说明五次，再最多进行三次相关读取。其他所有日期和情况仍保持原来的次数；计划运行会跳过相关读取，仍为五次。

第二，日期和计数。adcopilot-review 和审计器会根据 full_audit 及其他分析视角提供的 date_range.end，结束各自的 search 读取，并且只说明一次日期。从 v2.41.0 起，AdCopilot 会将审计和其他分析的时间窗口截止到账户所在时区的昨天，也就是最近一个完整日期；此前则截止到 UTC 日期。在那次对话中，审计覆盖的七天截止到 10 月 12 日，而账户直到 13 日才有结果。本月预算进度（budget_pacing）和变更日志（change_history）会延伸到账户所在时区的今天，也就是当前尚未结束的一天，因此审查和审计器会分别说明这些日期，且不会用这些日期作为读取的结束日期。对于较短时间窗口内的发现，它们会在同一句中说明日期和之后出现的任何结果；覆盖情况则按照结果所给出的数量表述为“73 项检查中有 N 项得出了结果”，其余项目的原因只采用结果本身的措辞；/adcopilot:weekly 也会以相同方式标注两周及其他时间窗口的日期。

第三，成本最高的搜索。在给出搜索次数之前，审查和审计器会检查所有结果中是否列出了搜索名称。这包括 analyze_search_terms 的“没有转化的高成本搜索词”，该项由 v2.41.0 新增（按成本从高到低列出搜索词、点击次数和费用，并给出数量）；还包括 full_audit 或 analyze_waste 中的浪费支出检查列表，只要账户在该时间窗口内有计入结果，就会列出每项搜索。列出搜索时，会点出最靠前的搜索及其费用。如果列表表明账户内任何位置都没有计入结果，就称它们为成本最高的搜索，而不是已证实的浪费。如果掌握的信息只能说明搜索数量，则只说明数量；只有相关读取自身的原因说明该读取会展示这些搜索时，才会提议再读取一次。/adcopilot:daily 和 /adcopilot:negatives 也会根据同一列表点出这些搜索。

第四，adcopilot-docs 会通过一次 get_org_context 调用回答有关 AdCopilot 的问题。它不会读取账户，不会启动其他技能，也不会在本轮遵循 next_step、操作手册、cross_reads 或 question_map，甚至不会按照它们提出技能步骤（但会保留 next_step 指定的限额）。它会用一个列表说明 AdCopilot 的功能，说明每项例行操作会读取什么并提出什么建议，同时把审批权限留给那一行关于 AdCopilot 可以更改哪些内容的说明，最后只提出一个问题，针对 last_30d 标明日期的 30 天摘要中的一项事实，提出一次读取。从 v2.41.0 起，服务会先回答问题，然后才提供已安装的步骤。

第五，审批。技能、命令、Agent、清单或本 README 中的任何句子，都不会在未说明保证条件的情况下承诺每次更改前都会征得同意；现在，所有 AI 客户端的条件都相同：AdCopilot 会先提出每项更改；只有当你的 AI 客户端设置为在 AdCopilot 的写入工具执行前询问时，才会硬性拦截——在 Claude 中是 Needs approval；在 Cursor 中，则是 Allowlist 运行模式，且写入工具必须保留在允许列表之外（Cursor 的云 Agent 不会询问）。早前的 0.2.12 文本只把 Claude 的设置作为条件，而 Cursor 没有此类设置。这涵盖了插件目录中对插件的描述、命令选择器中 /adcopilot:negatives 的描述（现在不再作任何承诺），以及审计器报告中附带的那一行（现在会说明每项更改都是针对客户当前对话提出的建议）。相关读取自身的句子会说明，更改仍然只是提议。tests/test_structure.py 会检查是否在同一句中包含 “as long as” 或 “while”，否则就会因这样的承诺而失败；所有面向用户的界面都必须使用第二人称，本 README、清单、所有描述和审计器报告则必须使用第三人称；此外，任何地方出现只针对 Claude 的条件形式都会导致检查失败。技能正文中给模型的规则要求：只有在客户同意后才能应用更改；这条规则不带条件，因为无论客户端的审批设置如何，模型都会遵守它。adcopilot-docs 和本 README 还会说明 v2.41.0 带来的唯一例外及其适用范围：Claude Code（版本 2.1.214 或更高版本）在每次使用 set_campaign_status（用于暂停或启用广告系列的工具）前都会询问，不受其设置影响；如果运行时无人可回答，就无法使用该工具；Claude 桌面应用也可能每次都询问。现在，每个会暂停或启用广告系列的技能和命令都会使用该工具，而不会通过 update_campaign 中的状态来完成；v2.41.0 也接受这种状态，但不会拦截。

第六，adcopilot-measure 的描述会列出两种路径：通过 Analytics，或直接在 Google Ads 中；并会按照技能引导的流程，说明直接路径所需的条件：不使用 Analytics，并通过 Tag Manager 将转化标记添加到网站。/adcopilot:audit 现在会像其他所有界面一样，说明首先调用 get_org_context：启用相应开关后，v2.41.0 可以在首次调用跳过该步骤时添加提示。

第七，Cursor。AdCopilot 的连接器已列在 cursor.directory 上；Cursor 会从 .cursor/skills 或 .claude/skills 读取技能。因此，插件文本现在会在判断当前使用的是哪个客户端时，先检查是否为 Cursor，涵盖 /adcopilot:setup、adcopilot-connect、每日习惯段落、adcopilot-review 中关于 Cursor 的专门段落，以及 adcopilot-daily 的设置说明。在 Cursor 中，插件绝不会运行 claude mcp（Cursor 的 Agent 可以访问安装了 Claude Code 的 shell，而该命令会列出 Claude Code 的连接器）；它会在 Cursor 的 MCP 设置中查找连接器，而通过 cursor.directory 添加的连接器可能名为 server；并且会用 Cursor 的登录步骤替代插件的 Connectors 选项卡。/adcopilot:audit 中用于修复工具列表过期问题的方法，也会优先提供 Cursor 步骤（在 Cursor 的 MCP 设置中关闭再重新开启 AdCopilot），而不是 /mcp。

现在，只有在 get_org_context 提供 routine.schedule 时，才会提出每日习惯建议；AdCopilot 只会在其 overlays.schedule_offer 已设置时提供该值，适用于 Claude 和 Claude Code，不适用于 Cursor；建议措辞由 routine.schedule.offer 提供。与服务端一样，计划运行在不同日期完成两次签到后会停止提供该建议。在 Cursor 中，插件不会自行提出日程建议；但是，如果 next_step 要求提供签到或摘要建议（v2.41.0 在例行操作待处理时，仍会以其中一项结束 Cursor 轮次），插件就会按照 next_step 的要求提出建议，并以操作手册规定的步骤结束。只有在 Claude 中，用户拒绝建议才会记录到 routine.own_schedule，因为 AdCopilot 会在整个工作区保留这一回答；如果在 Cursor 中记录，就会导致 Claude 中也不再提供建议。

现在，每个命令都知道在未安装技能时该如何操作，因为 cursor.directory 会逐个安装命令：/adcopilot:setup、/adcopilot:launch 和 /adcopilot:measure 会遵循 get_org_context 中的 next_step 和操作手册；/adcopilot:audit、/adcopilot:daily、/adcopilot:negatives 和 /adcopilot:weekly 则会在此处发送 source "claude-plugin"，但不带版本号，因为对于带版本号的标记，v2.41.0 会将本轮交给负责处理账户当前情况的技能，并从 next_step 和操作手册中省略该技能的步骤；而对于不带版本号的标记，则不会指定技能，并会自行提供步骤。cursor.directory 上的命令副本仍是 0.2.11 版本，直到再次粘贴更新内容为止，因此在此之前，这些改动都不会应用到它们身上。审计器 Agent 针对 Cursor 携带 readonly: true；Cursor 的子 Agent 没有工具列表，会继承所有工具。它的读取工具列表只会在 Claude Code 中强制执行，而 Cursor 不会声明 readonly 会阻止 MCP 写入。本 README 会在 Install 下新增 Cursor 小节，并加入 Google 的披露声明，逐字照录 AdCopilot 网站上的内容。

第八，2026-10-18 的评估运行之后的四项改动。/adcopilot:negatives 携带 disable-model-invocation: true：模型不能再自行启动它；此前模型曾用它来回答哪些搜索在浪费资金的问题，而不是使用 adcopilot-review；用户输入命令后仍会照常运行。adcopilot-review 不会再提出或提及因与问题无关而跳过的相关读取，该读取 why 中的数字也不会出现在答复中。七个包含该内容的文件现在都使用相同的每日习惯建议：它是独立段落，紧跟在说明发现的段落或列表之后，绝不会附加在某个句子的末尾；措辞固定为两个句子，不使用分号，也不会在用户同意前给出设置步骤：一个只读检查会在每个工作日 8:07 自动运行；它会在第一个早晨发现问题，并以“Everything is fine”或“Needs a look”开头，随后给出一项是／否修复建议；然后，如果用户说“schedule it”，就会建议为其所在位置设置该检查。在结尾处，第一句话会说明同一项检查可以每天早上检查账户。在这些运行中，每位评审员都曾因早先的措辞不符合“建议应为一到两个句子，且不包含设置步骤”的检查项而判定失败；后续的一次运行中，只有当建议被添加在搜索相关段落末尾时，该检查项才再次失败。/adcopilot:daily 的开头会列出所有需要关注的发现。

新增了五个案例；其中三个在 2026-10-17 针对较早的 0.2.12 文本运行过一次，另外两个从未运行过（见 Evals 小节）。三个案例由 adcopilot-review 负责：review-uncapped-no-limit-words、review-question-first-roomy（针对没有每日限额的套餐，先回答问题，进行八次读取）和 review-account-day-named-searches（使用一组以账户自身昨天为结束日的日期，并点出成本最高的搜索）。两个案例由 adcopilot-docs 负责：docs-capabilities-untracked 和 docs-capabilities-routed。其中每个 get_org_context 答复都包含 v2.41.0 自身针对相应状态计算并生成的 overlays、提示、next_step、操作手册和 cross_reads；账户日期案例中的浪费支出和搜索词结果也由该版本自己的评估器生成，本月预算进度和变更日志则延伸到账户所在时区的今天。两个 docs 案例中的第一个反映了该次对话的服务答复状态：一个有支出但未计入任何结果的账户被交由 adcopilot-measure 处理；第二个则是有计入结果的账户被交由 adcopilot-review 处理。评分标准中的每个项目都有独立的 LLM 评分器，编号与评分标准一致；不涉及 review 的项目允许使用工作区答复本身给出的内容：测试套件的评审器只用一个词作答，而一次性给出所有项目时，它会把单独评估每个项目时通过的答复判为失败。

十四个各自带有 get_org_context 答复的旧案例，也会用 v2.41.0 的代码根据各自的数据重新生成答复；每个 fixture 的标头都会说明其中两项数据做了更改，而不是照搬原值：其中五个案例的 routine.weekly.status 为 skipped（此前为 off），因此当案例要求不提供结尾内容时，next_step 不会包含结尾内容；habit-recorded-stays-quiet 则新增了 routine.scheduled_first_seen_at，日期设为最后一次出现前一天，因为 v2.41.0 只有在计划运行于两个不同日期完成签到后，才会认为计划已生效。setup-signed-out 的答复是客户端的登录错误，而不是服务答复；八个案例共用的测试套件级答复 evals/mocks 则保持不变。现在，调用日志评分器会根据每次调用自身的 tool 检查调用，因为 v2.41.0 的操作手册和 question_map 会在答复中列出工具；账户日期案例的日期评分器还会检查以下情况：对后一天使用 < 界限、单日范围、双引号中的日期、包含账户所在时区今天的 DURING 范围、没有上限的开放范围（仅有 > 或 >= 界限，范围延伸至账户所在时区的今天），以及包含错误日期的 IN 列表。该文本尚未运行测试套件或仅工具消融测试，因此这些案例都还没有针对新答复运行。

每个文件中的标记都会更新为 claude-plugin/0.2.12。AdCopilot 可以读取从 0.2.7 起的任何版本，但此文本描述的是 v2.41.0，因此必须先发布该版本。 0.2.11（2026-10-13）尚未打标签，且下方的发布检查清单尚未针对该版本运行。 对插件告知模型的内容做了两处更改，清单除版本号外没有其他变动。第一，每日习惯提示从回复末尾移到紧接着晨间检查也会读取的第一项发现之后（花费了资金却没有带来销售的搜索、预算耗尽或支出速度偏离预算节奏的广告系列、被拒登的广告、指标较 7 日平均值下滑、无人要求的变更），并与该发现关联。价值说明是：每个工作日早上 8:07 自动运行的检查，本可以在问题出现的第一个早晨就发现它；检查只读取账户，并以“Everything is clear”或“Needs a look”开头，再附上一项是／否式修复建议。对于其他任何发现，即使会造成损失（跟踪故障、质量得分问题、定位问题），以及没有发现时，提示都放在回复末尾、回复中的任何问题之前；不会说检查本可以发现它，因为晨间检查不会读取这些内容。承载该文本块的七个文件，以及 adcopilot-review 自身的段落会同步更改。用户现在只要拒绝，当前对话中就不再出现该提示；系统会询问一次客户的 Claude 是否能创建定时任务，如果不能，就将 routine.own_schedule 记录为 unavailable；如果能，则记录为 declined。AdCopilot 会保留此记录一周，之后才会重新显示提示；get_org_context 只会在这一周内显示 declined，因此插件无需计算日期。提示仍然是陈述句（“回复‘schedule it’”），而不是问题，因此回复末尾不会出现两个问题。第二，每次运行的成本：大约读取六到七项，而非五项，每项都计入工作区的每日操作次数。若周一还运行周报，则可能用完当天的全部操作次数；Free 套餐为 10 次。发布顺序： 此版本基于接受 declined 的 AdCopilot 版本编写；在较旧的服务端上，该调用会因名称不被接受而遭到拒绝，因此应先发布服务端。评估提示的评测器不再要求提示出现在“末尾”，而且三个习惯用例尚未针对 0.2.11 重新运行。每个文件中的版本标记都改为 claude-plugin/0.2.11。 0.2.10（2026-10-12）于 2026-10-13 打上标签，但下方的发布检查清单并未为此版本执行；创始人选择在未执行检查的情况下打上标签，发布说明也如实说明了这一点。只改动了插件向模型传达的内容，共三处，清单文件只改了版本号。第一，处理自身文本中包含条件的发现。现在，所有向客户转达透镜发现的界面都会附带一句话：如果某条发现说“如果 X”，在检查 X 之前，它就不是一个步骤；因此，要么执行它所指明的读取并说明发现了什么，要么在自己的句子中保留这一条件，绝不能把它变成指令。共有九处包含这句话：审计 Agent、/adcopilot:audit、/adcopilot:daily、/adcopilot:negatives、/adcopilot:weekly，以及 adcopilot-review、adcopilot-daily、adcopilot-launch 和 adcopilot-measure 这四个技能。adcopilot-seo 自身的步骤只提到两个透镜并说明它们不覆盖什么，且不会运行任何透镜，因此无需加入这句话；如果它执行的原始搜索以 related_reads 结束，仍可能调用 analyze_waste 或 analyze_search_terms，但这种情况下也不包含这句话。tests/test_structure.py 会在任何提及透镜、却既未覆盖也未说明例外的文件上失败。它会查找审计 Agent 列出的十二个透镜名称；测试会确保列表包含这些名称，以及审计 Agent 同样配备了工具的 explain_conversion_gap。在无人值守运行中，这句话会与运行规则放在一起，并注明其限制：运行只会执行自身的读取，因此，如果某个条件所需的读取不在这些读取之中，就要在句子中保留该条件。审计 Agent 的只读工具列表新增了 ga4_list_conversion_events，这是转换发现可能指明的读取；列表仍然只列出明确枚举的读取。第二，full_audit 的深度。与本次检查对应的 AdCopilot v2.35.2 会运行不指定深度的调用，并默认执行快速审计；只有在该运行无法完成时，才会回退到快速审计并说明这一点；显式指定 deep 时绝不会回退。adcopilot-review、审计 Agent 和 review-spends-the-depth 用例的描述原先都说默认是快速审计；现在它们会说明服务端的实际行为，并仍然传递 depth="deep"。评估模拟对象和 _tools.json 快照是服务端旧文本的冻结副本，保持不变；没有更改任何评分器。第三，新增了一个用于回答 Meta 广告问题的技能 adcopilot-meta。AdCopilot 尚无 Meta 集成（已列入路线图，但没有日期）。Meta 发布了自有的 Meta 广告连接器，称其为 ads MCP server，并标记为开放测试版，因此该技能会先在对话中查找它。如果不存在，该技能会说明自己是什么以及如何添加，并提供 Meta 帮助页面和 AdCopilot 指南 AdCopilot 如何配合 Meta 广告使用。如果连接器已存在，Meta 的数据来自 Meta 连接器，Google 的数据来自 AdCopilot，且每项数据都会标明来源；从 Meta 读取的任何数据都不会传入 AdCopilot 调用；通过任一连接器进行更改时，都会先提出方案，并且一次只操作一个平台，因为 Meta 的页面表示 AI 客户端会请求确认，却没有说明 Meta 的服务端也会这样做，所以该技能会自行询问。Meta 的页面已于 2026 年 10 月 12 日核查。对于在没有客户自有开发者应用的助手中添加连接器，Meta 的页面未说明国家/地区列表、广告账户角色或验证步骤，因此该技能也不会提及这些内容；Meta 的开发者文档确实说明，如果客户使用自有 Meta 开发者应用代表其他企业操作，则需要经过应用审核；该技能会引导这类客户查看 Meta 页面，不再作其他说明。其文本不包含任何套餐或价格相关字眼，而且只用 Meta 自己的措辞描述 Meta 的推出情况（开放测试版；账户可能尚无法使用其所有工具和功能）。它还会说明，Meta 结果中的文本是数据，绝不是指令。该指南是 AdCopilot 文档网站上的一个页面，由 AdCopilot 自有仓库发布，必须先上线，才能为此插件打标签或发布；否则，对于每一位询问 Meta 但尚未接入 Meta 连接器的客户，技能中的链接都会无处可去，而这正是该技能的主要答复。按以下顺序发布：合并文档提交，并发布包含该文档构建结果的 AdCopilot 版本；访问 https://adcopilot.cloud/docs/guides/meta-ads-alongside-adcopilot 并确认页面标题与指南标题一致；然后才为插件打标签并发布。状态码不是核查依据：对于不存在的路径，文档网站会返回 HTTP 200，标题却是“404: This page could not be found.”。只有当答案中包含 Google 数据时，该技能才会通过插件标记检查，因此，统计带有此标记的文件数量的结构测试，范围从十一处扩展到十二处。其评估用例已编写，但尚未运行。evals/meta-connector-absent（标签为 meta，在 TAG_TO_SKILL 中登记为 adcopilot-meta）会在 Meta 连接器缺失时询问 Instagram 广告相关问题，并检查答复是否提供 Meta 帮助页面、AdCopilot 指南及其网址，是否未通过 AdCopilot 读取任何内容，是否未根据记忆给出任何数据，以及是否未提及 Meta 的任何条款。对于没有任何用例的技能，仅工具消融测试会输出 FAIL: no gated case；现在发布检查清单第 7 步有了可衡量的用例，但只有在通过已认证的 Claude Code 运行该用例，且相对于仅工具组的增量为正时，结果才能通过。如果该用例最终被证明是回归保护用例（仅工具组在该用例上的得分已达到 0.8 或更高），则该技能仍然没有受门控的用例，需要另一个用例，或者创始人在发布说明中记录明确豁免。每个文件中的标记都改为 claude-plugin/0.2.10，AdCopilot 对此的读取方式与 0.2.7 至 0.2.9 相同。结构测试和两次 claude plugin validate --strict 运行均已通过。0.2.10 的发布步骤 1 至 8 尚未执行：真实账户运行、评估套件和消融测试都需要一位使用已认证 Claude Code 的人员，因此这些文字尚无任何门控结果；0.2.8 的结果仅适用于此版本未改动的文本。 0.2.9（2026-10-12）只调整目录列表，不会改变客户运行的任何内容。 展示名称改为“AdCopilot for Google Ads, Google Analytics, Google Search Console & Google Tag Manager”，描述和本 README 的开篇都以运行 Google Ads 的 Agent 为主，并说明 AdCopilot 与其他同名产品无关；关键词从 6 个增至 20 个；清单中的 icon 指向一张 1024x1024 的 PNG（.claude-plugin/icon.png，图案与 icon.svg 相同），因为目录无法显示以路径形式提供的 SVG。针对两项目录警告进行了处理：审核员 Agent 的工具列表移除了它从未使用过的 Read（报告是它的返回值，列表仍只列出明确指定的读取工具）；.gitignore 中的一条注释不再提及运行任何内容。每个文件中的标记都更新为 claude-plugin/0.2.9，AdCopilot v2.34.10 及更高版本会像读取 0.2.7 和 0.2.8 一样读取该标记。除标记外，没有更改任何技能、命令或 Agent 正文，因此 0.2.8 的门禁结果仍适用于这些文本；0.2.9 尚未重新运行测试套件和消融实验。基于此，0.2.9 于 2026-10-13 打上标签。 0.2.8 是针对 AdCopilot v2.34.19 编写的（部署于 2026-10-09 21:04 UTC）。这是 lens 结果以 related_reads 结尾、且 get_org_context 的回答包含 question_map 的版本；该版本于 2026-10-10 发布，并于 2026-10-12 打标签，其门槛记录在下方的 0.2.8 说明中。0.2.7 是针对 AdCopilot v2.34.10 发布的（部署于 2026-10-08 08:00 UTC；连接器工具修订版 7b2eee34，于 2026-10-08 从 get_org_context 实时读取），这是首个从插件标记中读取版本的发布版本。这些组件是针对 AdCopilot v2.34.0 编写的（连接器工具修订版 7016a0aa，于 2026-10-06 实时读取）。review、docs、Search Console 和 auditor 组件都是针对该服务编写并检查的；更早的工作流是针对 v2.30.2 编写的，并针对 v2.34.0 重新检查了它们所作的声明。评估套件所模拟的工具快照（evals/mocks/adcopilot/_tools.json）固定在连接器工具修订版 0066a60e，于 2026-09-23 在 v2.14.1 下获取；但其中的 get_org_context 条目例外，它使用修订版 782ec74d 的实时架构（于 2026-10-03 读取），这样评估模型就会像真实客户端一样获得 source——每个会读取服务的用例，如果调用 get_org_context 时没有提供 source: "claude-plugin/<version>"，就会在 marks-plugin-use 评分器中失败，裸值 "claude-plugin" 也不例外，因为服务根据版本进行路由（仅工具消融测试的存根也携带相同的版本标记，因此该评分器不会给任何技能的差异分增加内容）；实时修订版独立于此插件变化，两者不同并不代表有问题。/adcopilot:audit 依赖 v2.14.1 起由 get_org_context 报告的 tools_revision，以便在对话中刷新过时的工具说明。技能、四个会读取账户信息的命令和 auditor 都会使用 source: "claude-plugin/<version>" 调用 get_org_context：插件标记后接此插件在 .claude-plugin/plugin.json 中的版本号。每个文件都会写明该值，因为技能无法在运行时读取清单；tests/test_structure.py 会检查所有副本与清单保持一致，因此升级版本时必须一并更新所有副本，否则测试会失败。AdCopilot 从 v2.29.0 起读取裸值 "claude-plugin"，以记录每个工作区的插件使用情况。斜杠后的版本号来自会依据它进行路由的 AdCopilot 发布版本（v2.34.10，于 2026-10-08 起在线）：对于标记为插件 0.2.7 或更高版本的调用，该服务会把任务交给负责当前情况的已安装技能，而不是在自己的操作手册中重复步骤——对于一个正在运行且结果已有统计的账户，会交给 adcopilot-connect、adcopilot-launch、adcopilot-measure 或 adcopilot-review。裸标记、低于 0.2.7 的版本或服务无法读取的版本都视作没有版本：调用会被记录，并像以前一样由服务自己的操作手册回答，因为 0.2.7 之前的发布版本都没有包含下文这句话。服务根据账户所处的情况进行路由，而不是根据发起调用的命令或技能来路由，因此，如果回答中的 plugin.skill 指向了另一个技能，每个调用方都会完成收到的请求，遵循 next_step 添加的任何限制，然后提供该技能的步骤：如果 /adcopilot:weekly 处理的账户尚未统计结果，它仍会撰写本周报告，并在之后提供测量步骤。该版本之前的服务无法识别带后缀的值：它不会记录插件使用情况，并会向这些工作区再次提示安装插件，因此必须先让该服务版本上线，再发布任何携带该后缀的插件版本。不带标记的调用行为不变。adcopilot-daily 的无人值守运行会改为传递 source: "claude-scheduled"；当 get_org_context 报告 routine.daily.status 为 user_set、routine.scheduled_last_seen_at 中包含日期，或 routine.own_schedule 为 saved 或 unavailable 时，每日习惯提示就会停止；这三种情况都会让服务停止提供自己的日程安排提示。设置过程会记录 routine.own_schedule 本身（saved 表示已保存，即使 AdCopilot 发送的邮件签到仍占用该日程也会被接受；如果 Claude 没有计划任务，则记录为 unavailable），因为从 0.2.7 起，当某个技能负责处理当前任务时，服务会将自己的日程安排部分交给此插件处理。AdCopilot 从 v2.30.2 起会记录该标记，并报告 routine.scheduled_last_seen_at、routine.daily.customer_id（其自身签到读取的账户）和 latest_check_in；在更早版本的服务上，该值会被忽略，且这些字段不存在，因此只有在使用 save_org_context 记录了日程时，提示才会停止，而 AdCopilot 会在自己的邮件签到（in_app）占用该日程时拒绝此操作。设置过程提供的说明会逐字采用 AdCopilot 的操作步骤（从 v2.30.2 起为 SCHEDULED_CHECKIN），而 tests/test_structure.py 会确保技能中的副本与之相同。/adcopilot:daily 和计划运行的新用例会添加用例级别的 _tools.json 条目，其中包括 analyze_search_terms、add_negative_keywords、update_campaign 和 save_org_context，这些条目于 2026-10-04 从修订版 782ec74d 实时读取；它们的 get_org_context 模拟数据也包含了新字段。整个套件的快照保持不变。review 和 Search Console 技能的用例也采用同样的做法：review-spends-the-depth 将 analyze_waste 和 analyze_search_terms 固定在修订版 7016a0aa，将 full_audit 固定在修订版 6145d0b5；seo-two-numbers-that-lie 则将五个 Search Console 工具固定在 7016a0aa；它们都于 2026-10-06 实时读取。刻意固定 full_audit 的版本，是因为整个套件快照中的旧版说明称结果会“按影响排序”，而实时说明则正好相反——先列出失败项，再按严重程度排序，而不是按影响排序；review 用例正是基于这一事实编写的，因此如果用例仍使用快照，就会根据与服务相矛盾的说明来评估技能。每个工具的 Tools revision 都是该工具自身文本的哈希，因此同一次列表响应中的工具可能会报告不同的修订版；只有 get_org_context 返回的值才是连接器的修订版。

评测，以及技能如何证明自己的价值

evals/ 中的测试套件通过 claude plugin eval . --trust-plugin --ablation none --threshold 0.8 --judge-model sonnet --concurrency 2 --max-cost-usd 20 --no-publish 运行；下方的发布检查清单会在打版本标签前运行它——由人工运行，因为它会驱动模型，而这里没有任何工作流持有用于登录 Claude Code 的凭据（参见末尾的 CI 运行什么，以及不运行什么）（评审模型并非无关紧要：同一个用例在默认评审模型下得分为 0.81，在 sonnet 下则为 0.905）。测试框架自带的有／无对比会移除整个插件——包括连接器——因此无法说明技能增加了什么；evals/ablation/tools-only.sh 会用一个技能内容被裁剪至仅剩 frontmatter 的插件副本运行相同用例，并打印每项技能相较于纯工具组的增量。若某项技能的用例在此处未显示增量，就会被删除，而非保留；门槛会检查每项技能表现最差用例的得分以及平均分，因此一个强用例不能掩盖一个无效用例——而纯工具组已经以 0.8 通过的用例，是针对连接器的回归保护，并非技能的证据，因此保持在 0.8，不计入增量。evals/**/mocks/ 下的测试夹具构成一个虚构租户：字段名称遵循实时连接器的回答，所有值都是编造的。九项技能各自至少有一个用例——整个测试套件共有三十个用例，这一点记录在 evals/ablation/delta.py 的 TAG_TO_SKILL 中——没有专属用例的技能会直接无法通过门槛，因为没有任何东西能衡量它。撰写本节时，0.2.14 的 adcopilot-fix-checks 对应的 fix-checks-three-checks，以及 adcopilot-review 对应的 review-scheduled-unmarked 尚未运行。本节文本中新增的六个用例（adcopilot-meta 对应的 meta-connector-absent；adcopilot-review 对应的 review-uncapped-no-limit-words、review-question-first-roomy 和 review-account-day-named-searches；adcopilot-docs 对应的 docs-capabilities-untracked 和 docs-capabilities-routed）尚未运行，因此它们还未证明自己的价值：其中四个（meta-connector-absent、review-uncapped-no-limit-words、docs-capabilities-untracked 和 docs-capabilities-routed）于 2026-10-17 在较早的 0.2.12 文本上运行过；meta-connector-absent 在三次运行中的得分均为 0.778，低于 0.8 的门槛，另外两个则从未运行。0.2.5 新增的四个用例（docs-safe-to-let-loose、review-spends-the-depth、seo-discovered-is-not-a-verdict 和 seo-two-numbers-that-lie）采用了与其他用例相反的评估方式：每个用例只评估技能正文新增的内容，并扣除工具描述和服务端自身 playbook 已经说明的内容。从 Cursor 这一轮开始，它们的回答采用 v2.41.0 对携带版本标记的调用所作的渲染，纯工具组的桩也会发送该标记，因此基线组是保留插件、但技能正文为空的情况：它收到的是交给已安装技能的 [PLUGIN] 移交内容，而不是未安装插件的连接所获得的完整分支；因此，增量可能包含服务端会提供给这类连接的文本。对于 review 技能，这意味着不再把“优先处理金额最大的项目”作为衡量内容——实时 playbook 对已跟踪账户就是这样表述的——而改为衡量深度级别调用、覆盖率数字、micros 规则以及双向建议。 0.2.5 的消融测试也是 gate 首次给出否决的一次，而它发现的问题值得保留：adcopilot-seo 唯一的案例在 仅工具组得分为 0.852，高于 0.8 的门槛，因此被归类为回归保护项，不计入增量；该技能也因此没有通过 gate 的案例——FAIL，“基线已覆盖所有案例”。问题不在技能，而在案例：它的七个评分项中，有六个在基线上就通过了。写成该技能知识的三个陷阱，结果发现能力不错的模型本来就会处理——即使没有提示，它也会显式传入 row_limit；不会在无人要求时调用写入工具；也知道平均排名就是平均值。只有站点地图中已失效的 indexed 字段经受住了检验（基线上 1/3，通过技能后 3/3）。规则对没有增量的技能给出的补救措施是删除，而这在这里会是错误的做法；正确的做法是设计一个针对仅工具组错误之处的案例，也就是 seo-discovered-is-not-a-verdict。因此，红色消融测试会指出某个技能，但在认定技能已经失效之前，先看看哪些评分项发生了变化。同一次运行中的两个负增量——audit-stale-tools 为 -0.095，habit-offer-code 为 -0.167——各自都只有一个 llm 评分标准，而两组在该标准下都偶尔会失败；所有确定性评分项在两组中均为 3/3 通过。这是方差，不是回归；逐项评分明细能帮助你分辨。

0.2.5 的绿色表格中，七个技能在各自通过 gate 的案例上全部为 ok：review +0.500、docs +0.370、launch +0.295（最小值 +0.292）、daily +0.294、seo +0.250、measure +0.238（最小值 +0.143）、connect +0.189（最小值 +0.078）。该结果由两次运行拼合而成，而非一次运行，这一点值得明确说明：上文的 20 个案例运行，加上针对回应它而编写的案例执行 --case 'seo-*' 后重新运行，并通过 delta.py 拼接和重新评分。使用的是同一个评审器、同一个 claudeVersion 2.1.289、同一天；两次运行之间没有提交修改 skills/、agents/、commands/ 或清单，因此较早的 20 个案例是在字节完全相同的内容上测得的。一次完整套件运行是更干净的产物，成本约为 $35；只有在上述最后一个条件成立时，拼接才是诚实的，因此在依赖该结果前，请用 git log -- skills/ agents/ commands/ .claude-plugin/ 检查。

0.2.6（2026-10-07）的测量结果不完整，具体情况如下。 三个案例重新运行，得分分别为：seo-discovered-is-not-a-verdict 1.000、seo-two-numbers-that-lie 0.926、audit-stale-tools 0.905；在 0.8 门槛下为 3/3 通过，总体得分 0.944，评审器为 sonnet，claudeVersion 为 2.1.292，成本 $2.87，用时 236s。这三个案例是唯一输入发生变化的案例：该版本修改了 skills/adcopilot-seo/SKILL.md（仅正文）、commands/audit.md 和 agents/adcopilot-auditor.md，而 skills/、commands/ 或 agents/ 下的其他内容均未更改。其余十八个案例沿用 基于 2.1.289 运行的结果，对应技能的文本字节完全相同。不存在基于 2.1.292 的完整套件运行。 因此，这份记录比 0.2.5 的产物可靠性更弱，并如实注明了这一点：沿用的分数反映的是 TEXT，不反映 BUILD；而本文件一直提醒要比较的正是 BUILD。

seo 消融测试在 2.1.292 下对两组都重新运行，因为仅正文的更改不会影响仅工具组，但构建更改可能影响所有内容：seo-discovered-is-not-a-verdict 为 1.000 对 0.750（+0.250），seo-two-numbers-that-lie 为 0.926 对 0.778（+0.148），因此 adcopilot-seo 的平均增量为 +0.199、最小增量为 +0.148，状态为 ok。只有 seo 需要这样做——tools-only.sh 不会剥离 commands/audit.md（它只处理 skills/*/SKILL.md，见第 51 行），所以该文件对两组的影响相同；audit-stale-tools 标记为 audit，不在 TAG_TO_SKILL 中，因此不属于任何技能的 gate；而 agents/ 完全不在测试套件范围内（参见 eval-coverage issue）。 还有一项比得分更重要的重新分类。 seo-two-numbers-that-lie 在 2.1.289 下的纯工具组得分为 0.852——高于阈值，是回归防护用例，因此不计入差值；这导致 adcopilot-seo 没有门控用例，并引发了 0.2.5 的首次 FAIL。在 2.1.292 下，同一用例文本、同一评审器在该组的得分为 0.778，因此它现在是一个门控用例，seo 也有两个用例。这两个分数之间，用例和技能都没有变化。因此，0.2.5 的“问题不在技能，而在用例”这一诊断只说对了一半：分类既取决于用例，也取决于 BUILD；仅升级客户端，就可能让技能通过或未通过门控。对 FAIL 采取行动前，请重新查看分类列，且绝不要将 Class 判定沿用于不同构建。

0.2.7（2026-10-08）是服务端路由所等待的版本。 标记会提供其版本号——每个交互式 get_org_context 调用（共 11 个文件中的 14 处）都会根据清单中的版本号传入 source: "claude-plugin/<version>"；从 AdCopilot v2.34.10 起，服务端会读取它：对于来自 0.2.7 或更高版本的调用，服务端会将这一轮交给负责处理该账户当前情况的已安装技能，而不是在自己的操作手册中重复该技能的步骤。本次发布的其余内容则确保这一交接安全可靠。每个“是”都会闭合一个流程：adcopilot-review 会应用修复，仅在结果未显示时才读取相关内容，说明如何撤销修复、记录修复，并以相同方式提出下一项修复；/adcopilot:audit 会在提出首项修复建议后结束；对于已完成的定时运行，用户回答“是”后会在实施更改前重新读取该修复涉及的内容；adcopilot-review 还会纳入服务端原先在账户计数分支中说明的两条规则（某项内容上线后的数周内不调整出价；当天剩余查询次数较少时，先进行适量读取，再提出建议）。路由后的这一轮仍会执行收到的请求：每个标记文件中都有一句话，根据答案的 plugin.skill 作出判断。定时运行结束时提出的问题始终针对更改本身，绝不针对依赖某项检查的更改。每日习惯提议也会在 routine.own_schedule 为 saved 或 unavailable 时停止；如今设置流程会记录此状态，因为从 0.2.7 起，当某项技能负责处理这一轮时，服务端会将自己的日程安排提议交由插件处理。 0.2.7 在 2026-10-08 的门禁第二次运行为绿色；第一次运行为红色。 第二次运行是完整套件，未拼接，一次跑完，基于提交 3bd07bd（下方的修复轮次；此后 skills/、commands/、agents/ 下的内容及清单均未更改），使用 claudeVersion 2.1.293，评审模型 sonnet：21 个案例中 21 个以 0.8 通过，总体得分 0.942，花费 $18.88，耗时 1,406s。仅工具消融测试也为绿色，全部七个技能均为 ok：review +0.500、docs +0.444、seo +0.347（最低 +0.111）、daily +0.275、measure +0.274（最低 +0.190）、launch +0.267（最低 +0.167）、connect +0.189（最低 +0.078）。其包含技能的测试组就是这次套件运行，作为 ABLATION_WITH_JSON 传入。仅工具测试组在同一提交、构建和评审模型下重新运行。由于第一次运行后，三个技能正文和 commands/audit.md 都有更改，第一次运行的测试组无法复用；副本会完整保留 commands/，因此若拼接进去，就不是上文所说的诚实拼接。ABLATION_MAX_COST_USD=20 让测试组在一次运行中完成全部 21 个案例，未拼接：$16.98，耗时 793s。没有案例为红色。五个案例的得分距及格线不到 0.05，因此这里逐一列出，以便下次构建出现回落时能够据此判断。measure-teaches 得分为 0.810，teaches-two-steps 在三次运行中有两次失败，而第一次运行中只有一次失败。setup-duplicate-server 得分为 0.825：setups-job-and-one-next-step 五次运行全部失败，而第一次运行中五次只有一次失败。仅工具测试组在两次消融测试中都五次未通过该评分标准；唯一影响此案例的改动是 adcopilot-connect 的步骤 2。这是一个线索，尚未查明原因。setup-signed-out 得分为 0.829，sign-in-once-and-stop 五次运行中有三次失败。它是一个保护项，其包含技能的得分低于仅工具组的 1.000（-0.171），第一次运行时也是如此（0.886 对比 0.943）。launch-unserved-campaign 得分为 0.833，connect-unknown-product 得分为 0.843；后者失败运行中的问题是下方评审重放所述的地址项。audit-stale-tools 在两个测试组中的得分均为 1.000，因此现在是一个保护项；/adcopilot:audit 在两个测试组中都有。0.2.6 在此构建下的得分为 0.714，该结果仍然成立，因此此修复随本次发布一同推出。seo-two-numbers-that-lie 在技能未更改的情况下从 1.000 降至 0.889：有一次运行漏掉了某次调用的标记，导致一项评分标准未达成。这就是运行三次时的波动幅度。

第一次运行基于 a2e4fd8，使用相同的构建和评审模型，21 个案例中 17 个通过，总体得分 0.927，花费 $19.20，耗时 1,482s。四个案例的 LLM 评分标准在三次运行中全部未通过：audit-stale-tools 0.714、connect-unknown-product 0.765、measure-import-trap 0.786 和 launch-unserved-campaign 0.792。其消融测试中，adcopilot-connect 和 adcopilot-measure 均未达到最低要求（各 +0.000），因为两个测试组都未通过相同的评分标准。仅工具测试组达到默认的 $15 上限后停止，此时已完成 18 个案例；剩余三个案例均不归属任何一方，以总计 $17.72 拼接补入。使用 2.1.293 在 main（0.2.6）上以 $3.05 重跑后，audit-stale-tools 的得分也为 0.714。因此，这个问题并非由分支导致，按裸标记匹配的重放文件也不是原因。其他三个案例在 main 上均通过：connect-unknown-product 0.843、launch-unserved-campaign 0.917，以及 measure-import-trap 0.929。这指向了分支，而下方的修复轮次已逐个案例证实这一点。 修复轮、当天构建并评判。 每个失败案例都先根据保存的回复进行诊断，再更改任何文本；之后使用套件的命令和 --case 单独重新运行（3 次）：measure-import-trap 1.000（首次运行时为 0.833）、connect-unknown-product 0.922、launch-unserved-campaign 0.917、audit-stale-tools 0.905，五次运行共花费 $3.83。每项修复都只涉及技能或命令文本，每项各提交一次，且没有更改评分标准。adcopilot-measure：回复把审计的行粘贴成表格，而评分标准不认可这种形式作为服务端的行；第 6 步现在要求用一个句子列出 Primary actions；当客户说标签已发布时，第 1 步会读回容器（首次运行时曾漏掉一次，2.1.288 的一次运行也出现过这种情况）。adcopilot-connect：回复使用表格，或建议的顺序提到 Tag Manager 却没提 Lantern，都会判失败；第 2 步现在要求写成句子，并在同一状态下列出每个产品。adcopilot-launch：案例中的日期是 9 月，但当前时间是 10 月，回复在指出问题前先争辩；第 8 步现在要求先说出问题发现，再在排除其他可能后只提一次日期差异。/adcopilot:audit：参见下文的评判器重放。与仅使用工具的对照组相比，正文更改无法影响该组；measure-import-trap 提高了 +0.214，connect-unknown-product 提高了 +0.157。应将这些结果视为参考，而非门槛：connect、measure 和 launch 的更改也会影响这些技能负责的其他案例，但那些案例没有重新运行，因此把这五次运行的结果拼接进门槛对照组，并不符合上文所述的诚实拼接方式。用于最终判断的全套件运行和最新消融实验记录在上文。

重放评判器，而不是凭猜测判断。 评判器只回答一个词，也不保存推理过程，因此只能推断或测量具体是哪一项评分标准未通过。我们制作了一个一次性探针插件，其中每个案例都要求 Agent（--model haiku）逐字重复一条保存的回复，并使用失败案例自身的标准原样评分；这样就能将该回复呈现给套件的评判器：构建相同、sonnet 别名相同、提示词相同，并由正则评分器确认复述完全一致。每次移除一段内容后重新评判，就能看出哪段内容会改变结果；四个案例共花费约 $7.45。结果如下。audit-stale-tools 的问题不在评判器或构建的评分逻辑： 在 2.1.292 下通过的两条 2026-10-07 回复，在 2.1.293 下获得 9 票全通过；而失败的 2026-10-08 回复则 9 票全失败，因此回复内容发生了变化。在此分支上，触发问题的是将重新连接写成带有成本条目的提议，这是提交 4a9d67e 要求的内容：仅移除这两条项目符号后，分支回复就从 0/9 票变为 6/6 票。在两个分支上，问题都是在没有审计发现的情况下争论“新近性”：仅移除“September was the campaign's first full month (it was switched on 23 August).”，main 回复就从 0/9 票变为 6/6 票。评判器对这些回复的判定临近临界线，因此 /adcopilot:audit 现在会让回复远离临界线，而不是只追着某个句子调整：缺少工具会使审计不完整；针对日期报告投放节奏；等到运行结果包含发现后再讨论新近性；把重新连接写成一个步骤，而不是一项提议。connect-unknown-product 的第 4 项要求评判器核实一个它无法核实的地址： 它要求判断某个连接地址是否属于服务端，但评判器根本看不到服务端的答案。仅移除 Search Console 地址后，一条失败的分支回复从 0/6 票变为 6/6 票，另一条从 1/3 票变为 6/6 票；若评分标准中写明案例的 https://app.example.invalid/connect/<slug> 地址，这两条回复分别得 3/6 票和 6/6 票；而同一条回复若包含记忆中的 Google 地址，仍会 6/6 票全失败。no-remembered-addresses 评分器已经会根据案例的域名检查地址。由于该案例在技能文本调整后已通过，因此评分标准保持不变；如果之后再次失败，就应修改那个句子，并以这些证据为依据。 阅读经过 --tag 或 --case 筛选的消融测试结果：运行中没有匹配用例的每项技能都会显示 FAIL: no gated case，脚本也会因此以非零状态退出。这是筛选的结果，并非回归问题。只有实际运行了用例的技能对应的行才有意义。 0.2.8（编写于 2026-10-10）遵循服务端的 related_reads。 本版本基于 AdCopilot v2.34.19 编写；该版本于 2026-10-09 21:04 UTC 部署并已上线，因此发布顺序没有问题：会发出 related_reads 的服务端先于遵循它的插件发布。改动内容：现在，每个会读取账户的 skill、命令和 Agent 都会按服务端自身关于结果以 related_reads 结尾时的指示行事——运行与问题相关的读取项，最多三个，然后根据掌握的所有信息作答；绝不重复已掌握的读取项；对于这些读取项返回的 related_reads，只提供选项，不追查；只进行读取，因此变更仍然只是提议——而 adcopilot-daily 的无人值守运行会跳过这些读取项。对于原本手动执行 search 来获取某个分析视图已有结果的流程，现在会改用该分析视图：adcopilot-review 会针对每类具体问题指定相应的分析视图，并在数字发生变化时读取 change_history；审计命令和审计 Agent 也会收到相同指示；adcopilot-launch 会用 analyze_search_terms 读取第一周的搜索词。对于分析视图无法涵盖的内容，仍保留原始 search：按天统计的两周数据、每个关键字的支出和结果、被拒登的广告、广告系列的展示份额，以及每日运行读取的变更事件——现有的每日案例会衡量这些内容。/adcopilot:weekly 现在会读取 change_history，了解谁更改了什么；也会读取广告和广告系列的状态，了解 Google 自行关闭了什么，因为变更日志不包含拒登信息。它也会有意遵循这些读取项中的 related_reads，尽管服务端自身的每周摘要没有 related_reads 链路，因为其读取项已预先确定范围：该命令由客户运行，而非按计划运行，并且仍受其已声明的读取上限约束。adcopilot-review 和审计 Agent 会提及 question_map，这是 get_org_context 为有广告系列可供读取的账户返回的表格；如果没有该表格，则回退到各自的列表。审计 Agent 的只读工具列表新增了 explain_conversion_gap，这是 conversion_setup_audit 可以提及的一项读取。新增案例 review-follows-related-reads（由 adcopilot-review 负责）：浪费分析视图会指定两项读取，一项与问题相关，另一项无关；评测会检查第一项是否运行、第二项是否未运行、回答是否使用了两项结果，以及是否未经同意就应用任何内容；其 day_of_week schema 采用服务端代码中的实时描述和签名，不含 Tools revision 行，因为没有已登录的连接便无法读取该行。0.2.8 于 2026-10-10 的门槛检查为 GREEN，结果来自一次拼接运行，具体如下。 套件使用 claudeVersion 2.1.296、评判模型 sonnet，在提交 a20a389 上运行；达到 --max-cost-usd 20 上限后停止，当时 22 个案例中已运行 20 个（$20.30，1,020s；partialReason 为 cost_ceiling）：现在 22 个案例的成本略高于 20 个案例的成本。未运行的两个案例 setup-signed-out 和 unrelated-request-stays-quiet，在同一提交、构建和评判模型上分别单独运行，每次运行的得分均为 1.000（$0.77 和 $0.19）。当天早些时候的一次尝试无效：账户的支出限额在案例运行中途切断了运行（运行记录显示 "You've hit your individual spend limit"），导致原本有效的 skill 被评为无效，此处未采用该次尝试的任何数据。全部 22 个案例均以 0.8 的门槛通过，总体得分为 0.946。 得分最低的五个案例为 measure-teaches 0.810、setup-duplicate-server 0.812、review-follows-related-reads 0.852（新案例）、habit-offer-untold 0.857 和 connect-teaches 0.867；列出每个案例是为了让下次构建时的退步能以此为参照。仅工具消融测试为绿色，七个 skill 均为 ok；启用 skill 的测试组就是该套件运行（作为 ABLATION_WITH_JSON 传入），仅工具测试组则在同一提交、构建和评判模型上重新运行（$19.20）：seo +0.324（最低 +0.148）、launch +0.318（最低 +0.292）、review +0.282（最低 +0.148）、connect +0.241（最低 +0.222）、measure +0.226（最低 +0.214）、daily +0.216、docs +0.444。audit-stale-tools 和 connect-no-analytics-account 是本次构建的守护案例（仅工具测试组以 0.8 的门槛通过）。单独运行的两个案例未纳入该消融测试的仅工具测试组；它们都不由任何 skill 的门槛检查负责。

发布

首先，明确顺序。 AdCopilot 服务端的客户必须先使用带版本标记 source: "claude-plugin/<version>"，然后才能发布会发送该标记的版本；较旧的服务端会忽略它，并停止记录插件使用情况。升级时，必须同步更新 .claude-plugin/plugin.json 和该标记的所有副本——tests/ 中的结构测试会在遗漏副本时失败。只有从 0.2.7 版起，服务端才会将已计数账户的审核交给 adcopilot-review，因此使用此类版本的客户在这种情况下看到的将是该技能的文本，而不是服务端自己的步骤。

运行它们所用的配置文件。 使用未手动添加 adcopilot 服务的 Claude Code 配置文件；默认配置文件通常符合要求，/mcp 会列出配置文件中已有的内容。

• 从此仓库之外启动。 在仓库内启动时，项目自身的 .mcp.json 会作为项目范围的服务再次读取，这正是 evals/setup-duplicate-server 所针对的问题。
• 切勿将 CLAUDE_CONFIG_DIR 指向临时目录，例如 $(mktemp -d)。Claude Code 会在其配置目录下保存每次 MCP 令牌刷新的锁。若会话轮换了 AdCopilot 的刷新令牌，却无法保存新令牌，就会再次发送已失效的令牌。AdCopilot 会将重复使用的刷新令牌视为被盗，并注销该连接。
  • 2026-10-07，一个使用临时配置文件启动的测试会话丢失了登录状态。其客户端日志显示 Token refresh error: ENOENT: no such file or directory, mkdir 和 Token persist failed: ENOENT。日志没有记录出错的目录，因此临时配置文件是最可能的原因，但并未得到证实。
• **如果需要单独的配置文件，**请为其指定一个会持久保留的目录：mkdir -p "$HOME/.claude-adcopilot-release" && CLAUDE_CONFIG_DIR="$HOME/.claude-adcopilot-release" claude。

推送版本标签之前，请在该配置文件中执行：

1. /plugin marketplace add AtromxIntelligence/adcopilot-claude-plugin

2. /plugin install adcopilot@adcopilot-claude-plugin

3. /mcp — 选择 adcopilot，并使用拥有该广告账户的 Google 账号登录。

4. 在真实账户上运行 /adcopilot:setup：它会用文字说明已连接的内容，并给出一个下一步。

5. 在同一账户上运行 /adcopilot:audit：获取完整审计和本月进度，并将全新账户的发现单独列出。

6. 在同一账户上运行计划任务：/adcopilot:daily 提出建议后，说“schedule it”，然后按照它针对你当前使用界面给出的步骤操作，并且只点击一次 Run now — 运行应能完成，无需停下来询问；不会调用任何会更改 Google Ads、Analytics、Tag Manager 或 Search Console 中内容的工具，也不会调用 save_org_context（在 0.2.14 之前设置的计划任务会先询问是否调用该工具，因此添加备注会让它停下来）；AdCopilot 报告运行完成后，下一次 /adcopilot:daily 不再提出建议。如果插件自身技能的计划任务无法在某个界面上无人值守地完成，那么该界面上步骤给出的就只有粘贴的指令。

7. claude plugin validate . --strict 和 claude plugin validate .claude-plugin/plugin.json --strict 均通过；测试套件得分达到 0.8；仅工具消融测试通过 — 每项技能相对于连接器加其自身 frontmatter 描述的增量（仅工具组保留 frontmatter，因此技能仍会触发），在平均值和基线尚未覆盖的案例中的最低值上，均至少为 0.05（ABLATION_FAIL_BELOW=0.05 evals/ablation/tools-only.sh）。仅工具组以 0.8 通过的案例，是对连接器自身行为的回归保护：配合技能时也必须仍以 0.8 通过，而且不计入技能增量。消融测试未通过则不得打标签：先修复或删除它指出的技能。

8. 在发行说明和上文中记录上述步骤运行时所用的 AdCopilot 版本和 tools_revision，还要记录测试套件运行时的 claudeVersion；该值已保存在 evals/results/<run>/aggregate-result.json 中。分数只有在同一构建版本下才可比较：2026-09-23，在 2.1.280 下，这些案例的得分分别为 audit-stale-tools 1.00、connect-teaches 1.00、measure-teaches 1.00 和 setup-duplicate-server 1.00；2026-10-02，在 2.1.288 下，插件字节级完全相同（两次的 plugins[0].version 均为 0.1.0），且评估器别名相同，但得分分别变为 0.67、0.83、0.67 和 0.77。插件没有任何改动。因此，某个案例分数下降时，这只是一个待查问题 — 是插件、测试框架，还是 sonnet 别名解析到了新的快照 — 尚不能得出结论：修改技能前，先比较两次运行的 claudeVersion，否则你会针对一个构建版本调整提示词，下一个版本又得重新调整。

   0.2.5 自身的运行结果，供下次比较：2026-10-06，在 2.1.289 下使用评估器 sonnet，全部 20 个案例均达到 0.8 阈值，总体得分 0.939，费用 $18.18，耗时 1,191 秒。当时新增的三个案例在每次运行中都得分 1.00；第四个案例 seo-discovered-is-not-a-verdict 是在消融测试之后编写的，现已与之一起记录。得分最低的四个案例是 audit-stale-tools 0.81、habit-offer-code 0.83、connect-unknown-product 0.84 和 connect-teaches 0.87 — 这些正是 2.1.280 和 2.1.288 之间得分有变动的案例；发布三版之后，audit-stale-tools 仍是其中得分最低的。

   0.2.7 自身的运行结果，供下次比较：2026-10-08，在 2.1.293 下使用评估器 sonnet，全部 21 个案例均达到 0.8 阈值，总体得分 0.942，费用 $18.88，耗时 1,406 秒（evals/results/2026-10-08T09-57-47-060Z，已加入 gitignore）。得分最低的五个案例是 measure-teaches 0.81、setup-duplicate-server 0.83、setup-signed-out 0.83、launch-unserved-campaign 0.83 和 connect-unknown-product 0.84。audit-stale-tools 首次未进入最低分案例之列：得分为 1.00。

许可证

MIT。版权所有：Atromx Intelligence Private Limited。详见 LICENSE。

CI 会运行什么，以及不会运行什么

每次向 main 推送以及每个拉取请求都会运行两个工作流，二者都不会读取密钥。

.github/workflows/checks.yml 负责发布门槛中的结构检查部分。它会通过 npm 安装固定版本（2.1.288）的 Claude Code，并运行两项 --strict 验证：claude plugin validate . --strict 和 claude plugin validate .claude-plugin/plugin.json --strict。这两项验证会读取本地文件，无需登录。它还会检查三个清单是否都能解析、每个技能和命令是否都包含 name: 和 description:、tests/ 中的结构测试是否通过（每个包含每日习惯区块的工作流中，该区块是否完全一致；无人值守运行的指令是否为只读，以及其首次调用是否标记为 claude-scheduled；交接的指令是否与 AdCopilot 的方案一致；每个文件中的插件标记是否带有清单中的版本；评估评分器是否能看到它们要评估的优惠和标记）、仓库中是否又出现了任何下载并执行模式，以及清单版本是否不低于最新标签。

.github/workflows/leak-check.yml 会对每个提交运行 gitleaks。它使用按摘要固定的 gitleaks 官方容器镜像；如果扫描发现可能的凭据，或未读取到任何提交，就会失败。GitHub 自带的密钥扫描和推送保护也已为此仓库启用，因此，如果推送中包含 GitHub 可识别的密钥类型，就会被拦截，除非推送者主动绕过拦截。

不会由任何工作流运行的是评估套件和仅工具消融测试。这两者都需要驱动模型，因此需要登录 Claude Code，而这些作业没有凭据。负责发布的人会运行它们，这意味着它们可能被跳过。因此，真正能阻止有缺陷的技能被打上标签的是上面的检查清单，而不是绿色勾号：未通过两项 --strict 验证、套件得分达到 0.8，以及仅工具消融测试通过，就不得打版本标签。

这里最初的工作流会运行所有检查，包括评估门槛和消融测试。2026-09-26，为提交插件目录而移除了它：在 runner 上安装 Claude Code 的唯一方法是通过管道执行 shell 安装脚本，而目录扫描器会将仓库中的任何下载并执行模式拦下来供审核，无论被获取的脚本由谁发布。通过 npm 安装固定版本不属于这种模式，因此 checks.yml 得以恢复。