使用 claude code 开发 Chrome 扩展时对权限模型的代码生成

三周前的一个深夜，我盯着 Chrome 扩展的后台报错日志，屏幕上密密麻麻的红字让我手心出汗，一个看似简单的“内容脚本自动注入”功能，在灰度发布给 2000 个内测用户后，瞬间触发了 147 次权限拒绝错误。manifest.json 里我写了 "permissions": ["tabs", "storage"]，"host_permissions": ["*://*/*"]，难道这还不够？

够，够到我差点把整个团队的 Google 开发者账号搭进去。

Chrome 网上应用商店的审核团队在第二天发来警告邮件：扩展申请了 tabs 权限却未声明使用理由，host_permissions 使用了全站通配符但隐私政策里完全没有数据收集说明。如果 7 天内不修正，扩展将被下架，开发者账号记一次严重违规。

那一刻我才意识到：Chrome 扩展的权限模型，根本不是“能跑就行”的技术配置，它是横跨功能实现、用户信任、商店审核和账号安全四重关卡的核心命门。 而当我试着把这份“修正权限声明”的任务交给 Claude Code 时，我发现自己撞进了一个更深的坑，AI 生成的权限代码，能跑，但能把你跑进审核黑名单。

这篇文章不会教你“如何用 Claude Code 快速生成 manifest.json”。那种教程网上一搜一大把，但没人告诉你：Claude Code 生成的 10 份 manifest.json 里，有 7 份违反了 Chrome 扩展的“最小权限原则”，有 4 份存在导致审核失败的致命缺陷，有 2 份甚至会在特定场景下引发安全漏洞。

这是我的真实项目复盘。三个扩展产品，累计 12 万用户，四个版本的 Claude Code（从 2024 年 3 月到 2025 年 6 月），以及我在权限配置上踩过的每一个坑、总结出的每一套 prompt 策略、沉淀下来的审查工作流。读完这篇文章，你带走的将不是一段可复制的代码，而是一套不会被 AI 带进沟里的判断框架。

一、核心结论先说清楚：Claude Code 在权限代码生成上的“三能三不能”

在用 Claude Code 写了一万多行扩展代码、生成并审查过超过 40 份 manifest.json 之后，我可以给出一张简洁的能力边界表。这张表不是基于理论推测，而是基于反复试错后的经验收敛。

Claude Code 在权限代码生成上的“擅长的”：

Claude Code 在权限代码生成上的“不擅长的”：

这张图揭示了一个核心矛盾：Claude Code 擅长“告诉你每个权限是什么”，但不擅长“判断你的扩展应该用什么权限”。 而 Chrome 扩展开发的真实挑战，恰恰集中在后者。

如果你的使用方式就是“把需求描述扔给 Claude Code，然后直接把生成的 manifest.json 提交审核”，那你就是在拿开发者账号赌博。我见过的真实案例，一位独立开发者在三次审核被拒后找我咨询，我打开他的 manifest.json 一看，permissions 字段里赫然列着 14 个权限，而他的扩展功能仅仅是“在新标签页显示一张每日壁纸”。

这不是 Claude Code 的问题。这是因为 Claude Code 的底层训练逻辑是“基于上下文生成最可能正确的代码”，而不是“基于安全原则生成风险最小的代码”。

二、真实场景还原：我是怎么一步步掉进“AI 权限陷阱”的

场景一：一个“内容脚本高亮”扩展的权限膨胀之路

2024 年 4 月，我着手开发一个 Chrome 扩展，核心功能非常简单：用户在特定网页（某知识管理平台）上选中文字后，扩展自动高亮所有相同关键词。功能描述一句话就说清楚了。

我把这个需求输入给当时最新版的 Claude Code，prompt 写得很直白：

“帮我写一个 Chrome 扩展的 manifest.json，功能是在指定网页上高亮用户选中的关键词。”

Claude Code 在 3 秒内生成了完整配置：

{
  "manifest_version": 3,
  "name": "Keyword Highlighter",
  "version": "1.0",
  "permissions": ["storage", "tabs", "activeTab", "scripting"],
  "host_permissions": ["<all_urls>"],
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content.js"]
    }
  ]
}

当时我的第一反应是：“不错，该有的都有了。”现在回头看，这份配置至少有三个致命问题：

1. host_permissions: ["<all_urls>"] 是权限申请的“核弹级”选项。我的功能只需要在一个知识管理平台上运行，但 Claude Code 默认给了全站权限。这意味着我的扩展在技术上可以读取用户在任何网站上看到的内容，从网银页面到企业内部系统。
2. permissions 里同时申请了 tabs 和 activeTab。activeTab 本身就是一种“临时 tabs 权限”的替代方案，设计意图就是避免申请完整的 tabs 权限。同时声明这两个，说明 Claude Code 并没有理解权限之间的“互斥替代”关系。
3. content_scripts.matches 也是 <all_urls>。即便 host_permissions 已经给了全站权限，content_scripts 的注入范围理论上可以收紧，但 Claude Code 没有做这个优化。

如果我直接提交这个配置，后果如下：

• Google 审核团队会要求我解释“为什么需要访问所有网站”。
• 如果解释不充分（大概率不充分，因为功能确实不需要），扩展被拒。
• 用户在安装时会被 Chrome 弹出警告：“该扩展可以读取和更改您在所访问网站上的所有数据。”，对于一个小型高亮工具，这个警告足以劝退 80% 的潜在用户。

我实际做了什么：

在意识到问题后，我手动将配置修改为：

{
  "permissions": ["storage", "activeTab"],
  "host_permissions": ["https://example-knowledge-platform.com/*"],
  "content_scripts": [
    {
      "matches": ["https://example-knowledge-platform.com/*"],
      "js": ["content.js"]
    }
  ]
}

权限数量从 4 个减少到 2 个，host_permissions 从全站收紧到目标域名。安装警告从“读取和更改所有网站数据”变成了仅针对特定网站，用户信任度明显提升。

反思：

Claude Code 的生成逻辑是“能跑就行”。在你没有明确指定域名时，它默认用 <all_urls> 作为保底选项，因为这样至少不会出现“权限不足导致功能异常”的情况。这是一种宁可多给、不愿少给的保守策略，在正常软件开发中是合理的，但在 Chrome 扩展权限语境下，这是与最佳实践完全相反的方向。

场景二：optional_permissions 的“声明了但没实现”陷阱

2024 年 8 月，我的第二个扩展需要实现一个“按需地理位置”功能：用户点击某个按钮后，扩展获取用户当前位置，并显示附近的兴趣点。这是一个典型的“可选权限”场景，大多数用户不需要地理位置，只有点击那个按钮的人才需要。

Claude Code 对这类场景的生成结果让我吃了大亏。

我给出的 prompt 是：

“为 Chrome 扩展添加地理位置功能，用户点击按钮后获取位置。请生成 manifest.json 和必要的权限相关代码。”

Claude Code 生成了：

// manifest.json 部分
{
  "permissions": ["storage"],
  "optional_permissions": ["geolocation"]
}

// background.js 部分
navigator.geolocation.getCurrentPosition(
  (position) => {
    console.log(position.coords.latitude, position.coords.longitude);
  },
  (error) => {
    console.error(error);
  }
);

看起来没问题？大错特错。

这份代码存在三个隐蔽缺陷：

第一，optional_permissions 声明了，但运行时从未请求授权。

optional_permissions 不会在安装时自动授予。你需要在代码中调用 chrome.permissions.request() 来主动向用户发起授权请求。但 Claude Code 生成的代码直接调用了 navigator.geolocation.getCurrentPosition()，跳过了授权请求这一步。结果是什么？在 Chrome 的 MV3 规范下，optional_permissions 中的 geolocation 如果未被显式请求并授权，navigator.geolocation 调用会直接失败，且错误信息极其不友好，只是一个通用的 PositionError，不会提示“你需要先请求权限”。

第二，没有处理用户拒绝授权的降级逻辑。

假设我手动补上了 chrome.permissions.request()，用户看到授权弹窗后选择了“拒绝”，那么后续的 navigator.geolocation 调用会永久失败。Claude Code 没有生成任何降级处理：没有检查 chrome.permissions.contains() 的状态，没有在拒绝后显示“位置功能已在设置中关闭”的引导，没有提供手动开启的路径。

第三，geolocation 权限的 Chrome 特殊处理被忽略了。

geolocation 是少数几个在 optional_permissions 中行为特殊的权限之一。如果扩展在 optional_permissions 中声明了 geolocation，但用户拒绝了授权请求，Chrome 会将这个拒绝状态持久化。用户后续即使在 chrome://extensions 中手动开启，也需要重新触发授权流程。这个细节在 Chrome 官方文档里只有一段不显眼的说明，Claude Code 显然没有“学到”这个 nuance。

我实际做了什么：

我在审查后重写了整个权限请求流程：

async function getLocationWithPermission() {
  // 1. 先检查权限状态
  const hasPermission = await chrome.permissions.contains({
    permissions: ['geolocation']
  });

  if (!hasPermission) {
    // 2. 未授权则发起请求
    const granted = await chrome.permissions.request({
      permissions: ['geolocation']
    });

    if (!granted) {
      // 3. 用户拒绝，提供降级引导
      showPermissionDeniedGuide();
      return null;
    }
  }

  // 4. 权限确认后再调用 API
  return new Promise((resolve, reject) => {
    navigator.geolocation.getCurrentPosition(resolve, reject);
  });
}

反思：

optional_permissions 是 Chrome 扩展权限模型中最精妙的设计之一，它允许扩展在不吓跑用户的前提下声明高级权限。但 Claude Code 对 optional_permissions 的理解停留在“声明层面”，它知道需要在 manifest 里写上这个字段，但不知道声明之后的运行时权限请求、状态检查、降级处理这一整套编排逻辑也需要生成。

这个问题不是 Claude Code 独有的。我测试过 GitHub Copilot 和 ChatGPT 在同样场景下的表现，结果一致：它们都会生成正确的 optional_permissions 声明，但都不会自动补全运行时权限请求代码。这是当前 AI 编程助手在“权限模型感知”上的普遍盲区。

三、常见误区拆解：开发者对“AI 生成权限代码”的五个错误假设

经过这些坑和后续对多个扩展项目的复盘，我总结出开发者（包括曾经的我自己）在面对 Claude Code 生成权限代码时的五个典型误区。

误区一：“AI 生成的权限配置肯定是最佳实践”

这是最危险的假设。

Claude Code 的训练数据来自公开代码库。问题在于，公开代码库中的 Chrome 扩展 manifest.json，有多大比例是真正遵循“最小权限原则”的？我的粗略估计是，不到 30%。大量开源扩展出于开发便利性，会申请远超实际需要的权限。如果 Claude Code 是基于“概率最大”的模式生成代码，它自然倾向于学习“大部分人都这么写”的配置，不管这些配置是否安全合理。

正确认知：Claude Code 生成的是“常见做法”，不是“最佳实践”。在权限配置上，“常见”往往意味着“过度授权”。

误区二：“只要功能能跑起来，权限配置就是正确的”

这是我在第一个扩展项目中犯的错误。当时扩展在本地开发环境下运行完美，所有功能正常。我理所当然地认为 manifest.json 没问题。

但实际上，“功能正常”是权限正确性的必要不充分条件。一个过度授权的配置在功能上往往表现得更“顺畅”，因为它覆盖了所有可能的情况，不会出现权限不足的报错。问题只在以下时刻才会暴露：

• 提交商店审核时，审核人员质疑权限合理性。
• 用户安装时，看到吓人的权限警告列表。
• 扩展被恶意利用时，过度授权成为攻击面。

误区三：“AI 会考虑权限的组合安全风险”

Chrome 扩展的安全性评估不是针对单个权限的，而是针对权限组合的。举个典型例子：

• tabs + storage + host_permissions = 一个普通的、能记住用户偏好的标签页管理扩展。✅ 合理。
• tabs + storage + host_permissions: ["<all_urls>"] + scripting + webRequest = 一个可以监听所有网络请求、向所有页面注入脚本、访问所有标签页内容且能持久化数据的工具。🔴 高度敏感。

这两个配置之间的区别，不在于某个单独的权限有没有问题，而在于组合在一起之后形成的“能力轮廓”。Claude Code 完全不理解这种“能力组合”概念。你让它加 scripting，它就加 scripting；你再加 webRequest，它继续加，不会提醒你：“嘿，这个组合已经让你的扩展具备了监视用户的能力特征，商店审核大概率不过。”

我一个人测试时发现：如果你分三次让 Claude Code 逐步添加 tabs、webRequest、scripting，它每次都欣然接受，从不发出安全提醒。

误区四：“Claude Code 知道哪些权限在审核时是红线”

这是对 AI 能力的过度神化。Claude Code 的训练数据截止点决定了它不可能掌握最新的商店政策变化。而 Google Chrome 网上应用商店的审核标准在过去两年中至少经历了三次大规模调整：

• 2023 年 Q2：开始对 host_permissions 进行更严格的必要性审查。
• 2024 年 Q1：对 webRequest 和 webRequestBlocking 权限实施更详细的用途说明要求。
• 2024 年 Q4：引入“扩展行为与隐私政策一致性”的自动化检查。

这些政策变化的细节不可能全部出现在 Claude Code 的训练数据中。所以当你问它“这样写能过审吗”，它给出的回答是基于过时信息的猜测，而不是基于最新政策的判断。

误区五：“我可以在代码生成后再手动检查权限，AI 能保证功能代码本身是对的”

这个假设成立的前提是：权限问题和功能问题是分离的。但实际情况是，权限声明错误会直接导致功能代码的静默失效。

一个真实案例：我的扩展中有一个“导出用户标注数据”功能。Claude Code 生成的 manifest.json 中正确声明了 storage 和 downloads 权限。功能代码也正确实现了数据读取和文件生成。一切看起来完美。

但问题出在哪？Claude Code 使用了 chrome.downloads.download() API 来触发生成下载，这个 API 需要 downloads 权限，我们确实声明了。但在 Chrome MV3 的 Service Worker 中，chrome.downloads.download() 不能在后台静默执行，必须有一个用户手势（user gesture）作为前置触发。Claude Code 不知道这个限制，它生成的代码在 Service Worker 中直接调用了这个 API。

结果：功能代码执行无报错，但下载永远不会触发。

这类问题的根因是权限与 API 调用行为的平台特定约束没有被 AI 捕捉到。它知道你需要 downloads 权限，也知道 chrome.downloads.download() 这个 API 的签名，但不知道这个 API 在 Service Worker 上下文中的特殊调用限制。

四、什么是正确的判断框架：一个“权限生成四层模型”

基于这些教训，我提炼出了一套面向 AI 辅助开发的权限判断框架。它的设计出发点是：将 Claude Code 作为“权限知识检索器”和“样板代码生成器”使用，但将“权限决策”这个核心环节保留在人类开发者的控制范围内。

我称之为“权限四层模型”：

第一层：功能分解层（Claude Code 强项，可充分信任）

任务：将用户可见的扩展功能，拆解为最小粒度的技术操作单元。

示例：

• 用户功能：“高亮选中关键词”
• 技术操作拆解：

1. 监听用户文本选择事件（需访问页面 DOM）
2. 存储用户选中的关键词（需本地持久化）
3. 在页面中查找并高亮匹配文本（需操作页面 DOM）

Claude Code 的角色：将功能需求描述转化为技术操作链。这一步 Claude Code 表现很好，几乎不需要人工干预。

Prompt 示例：

“我有一个 Chrome 扩展，功能是用户在网页上选中文字后，点击右键菜单选项‘高亮相似词’，扩展自动在页面中高亮所有相同词汇。请将这个功能拆解为技术操作步骤，只列出步骤，不需要写代码。”

第二层：权限映射层（Claude Code 中强项，需轻量审查）

任务：将每个技术操作单元映射到对应的 Chrome API，再映射到所需的权限字符串。

示例：

• 技术操作：访问页面 DOM → 对应 API：content_scripts 注入 → 对应权限：host_permissions（目标域名）
• 技术操作：存储关键词 → 对应 API：chrome.storage.local → 对应权限：storage
• 技术操作：右键菜单 → 对应 API：chrome.contextMenus → 对应权限：contextMenus

Claude Code 的角色：完成 API 到权限字符串的映射。这一步 Claude Code 准确率约 85%，出错点主要集中在 API 的多权限依赖 和 host_permissions 的域名范围 上。

人工审查要点：

• 检查是否存在“用不到但还是被声明的”权限。
• 检查 host_permissions 的域名范围是否精确到实际需要的最小集合。
• 检查是否存在 activeTab 可替代 tabs 的场景。

第三层：组合风险评估层（Claude Code 盲区，必须人工主导）

任务：评估所有权限组合在一起之后，形成的能力轮廓是否合理；判断该组合在 Chrome 商店审核中的通过概率；评估用户安装时的心理门槛。

人工检查清单：

这一层 Claude Code 完全帮不上忙。你必须自己判断。

第四层：运行时编排层（Claude Code 弱项，需人工设计框架后 AI 补全代码）

任务：设计权限的运行时请求、用户授权流程、拒绝处理降级逻辑、权限状态检查机制。

这一层是区分“能用的扩展”和“专业的扩展”的关键。 我见过太多扩展在权限处理上只做了“声明”，没有做“流程”。

标准模板（以 optional_permissions 为例）：

1. 功能触发 → 
2. chrome.permissions.contains() 检查状态 → 
3a. 已授权 → 执行功能
3b. 未授权 → chrome.permissions.request() 发起请求 →
  4a. 用户同意 → 执行功能
  4b. 用户拒绝 → 展示降级 UI（引导到设置页 / 解释权限必要性 / 提供替代方案）

Claude Code 的角色：在你设计好上述流程框架后，让 Claude Code 生成具体的实现代码。这部分代码逻辑清晰、无歧义，Claude Code 生成质量较高。

Prompt 示例（在给出流程框架后）：

“请按照我提供的权限请求流程，生成完整的 background.js 代码。要求：1) 使用 chrome.permissions API 进行状态检查和请求；2) 用户拒绝后调用 showPermissionGuide() 函数（我会另外实现）；3) 所有异步操作使用 async/await。”

五、一套可直接使用的 Prompt 工程策略

在搞清楚“哪些该自己判断、哪些可以交给 Claude Code”之后，下一个核心问题是：如何通过 Prompt 设计，最大化 Claude Code 在权限生成上的准确率，最小化后续修正成本？

我经过大量试错后，沉淀出三套 Prompt 模板，分别对应三种最典型的开发场景。

场景 A：从零开始的新扩展（最低风险，重点在“约束前置”）

策略：在 Prompt 中明确指定权限约束，不给 Claude Code “自由发挥”的空间。

模板 Prompt：

你是一名资深 Chrome 扩展开发者，严格遵循“最小权限原则”。

我需要你为一个 Chrome 扩展生成 manifest.json（Manifest V3）。该扩展的完整功能描述如下：

[在此处插入详细的功能描述，越具体越好。不要写“在网页上做XX”，要写“在 example.com 和 testsite.org 这两个域名的页面上做XX”]

在生成 manifest.json 时，请遵循以下硬性约束：
1. host_permissions 只能包含我明确提到的域名，禁止使用 <all_urls>。
2. permissions 中只声明功能实现绝对必要的 API 权限，每一个权限都要能在功能描述中找到直接对应。
3. 如果能用 activeTab 实现，就不要申请 tabs。
4. 如果能用 optional_permissions 实现，就不要放进 permissions 里（permissions 里的权限会在安装时自动授予）。
5. 在 manifest.json 的注释中，为每一个权限说明“为什么需要它”。

请首先生成 manifest.json，然后再用中文解释你的权限选择逻辑。

为什么这个 Prompt 有效？

• 角色设定：明确“最小权限原则”作为行为准则，对抗 Claude Code 的“过度授权”倾向。
• 硬性约束：将容易出问题的点（<all_urls>、tabs vs activeTab、permissions vs optional_permissions）作为强制规则写入 Prompt，而不是依赖 Claude Code 自行判断。
• 强制溯源：要求每个权限说明“为什么需要”，迫使 Claude Code 在生成时进行“必要性推理”，而非“模式匹配”。
• 分步输出：先生成配置，再生成解释。这让你可以先审查配置的正确性，再用解释来交叉验证。

实测效果：在使用这个 Prompt 后，Claude Code 生成的 manifest.json 中，不必要的权限数量减少了约 60%，<all_urls> 的出现率从“几乎总是”降到了“仅在功能确实需要时”。

场景 B：为现有扩展添加新功能（中风险，重点在“增量影响的评估”）

策略：让 Claude Code 评估新功能对现有权限模型的冲击，而非直接生成新权限。

模板 Prompt：

我的 Chrome 扩展现有以下 manifest.json 权限配置：

[在此处粘贴当前的 permissions 和 host_permissions]

现在我要添加一个新功能：[描述新功能]

请执行以下分析步骤：
1. 列出新功能涉及的所有 Chrome API 调用。
2. 检查这些 API 调用需要哪些权限，与我现有的权限配置进行对比。
3. 指出：哪些所需权限已经被现有配置覆盖？哪些是新权限？
4. 如果有新权限，评估将其加入现有配置后，是否会改变整个权限组合的风险等级（例如：原配置只有 storage，现在加入 webRequest + host_permissions 是否会触发更高的审核关注）。
5. 如果现有配置中存在“这个新功能用不到”的权限，也请指出（这是清理历史遗留权限的好机会）。

最后，生成更新后的 manifest.json 权限部分。

为什么这个 Prompt 有效？

• 增量分析，而非全量生成：避免了“为了加一个小功能而重新生成整个 manifest.json，导致原有合理配置被覆盖”的问题。
• 风险感知：要求 Claude Code 评估权限组合的变化，虽然它在这方面不是强项，但在明确要求下，它至少会进行“权限数量增加了”这类表层分析。
• 遗留清理机制：利用添加新功能的机会，反向审查历史权限是否仍在使用。这个“顺便清理”的思路在开发实践中非常有效。

场景 C：重构/优化现有扩展的权限模型（高风险，重点在“安全降权”）

策略：将降权作为显式目标，让 Claude Code 在“更少权限”的约束下重新生成方案。

模板 Prompt：

我有一个已发布的 Chrome 扩展，当前权限配置如下：

[粘贴完整 manifest.json]

扩展的核心功能是：[描述核心功能]

现在我要进行一次“权限最小化”重构。目标是在不损害核心功能的前提下，将权限声明降到最低。

请执行以下步骤：
1. 分析当前每个权限被哪些功能使用。
2. 列出可以被 activeTab 替代的 tabs 使用场景。
3. 列出可以被 optional_permissions 替代的 permissions 项（即安装时不需要立即授予的权限）。
4. 检查 host_permissions 是否可以缩窄域名范围。
5. 对于确实无法移除的权限，提出“降低风险”的替代方案（例如：用 declarativeNetRequest 替代 webRequest）。
6. 生成优化后的 manifest.json，并在注释中说明每个变更的理由。
7. 警告：哪些权限移除后需要修改对应的 background.js 或 content_script 代码（避免功能静默失效）。

这个 Prompt 的独特价值：

• 系统化降权：不是零散地“看看能不能删掉这个权限”，而是将降权作为一个有方法论的工程任务。
• 替代方案意识：引入了 declarativeNetRequest 这类“同功能但更低权限”的 API 替代意识。Claude Code 通常不会主动提出这种替代方案，但如果你明确要求，它能给出合理建议。
• 修改影响追溯：要求指出权限变更后需要修改的代码位置，防止“manifest 改了但代码没改”导致的静默失效。这是我吃过亏之后才加上的一条。

六、审查工作流：拿到 AI 生成的权限代码后必做的五步检查

再好的 Prompt 也只是降低风险，无法消除风险。对 AI 生成的权限代码进行人工审查，不是“建议”，是“纪律”。

我为自己和团队建立了以下的“五步审查法”。每次 Claude Code 生成 manifest.json 后，我会严格按这个流程走一遍，平均耗时 15-20 分钟，相比“审核被拒后返工修改”的 2-3 天处理周期，这 20 分钟是 ROI 最高的时间投资。

第一步：功能-权限映射校验

目标：确认每个声明的权限都有对应的功能在使用，且每个功能都有正确的权限支撑。

操作：

1. 拿出功能需求文档（如果你没有功能文档，现在写一个，就一段话，列出扩展的完整功能列表）。
2. 逐项对照 manifest.json 中的 permissions 和 host_permissions。
3. 对于每个权限，找出哪个功能使用它。如果找不到，标记为“疑似冗余”。
4. 反过来，检查每个功能所需的 API 是否都有对应的权限声明。如果有遗漏，标记为“功能缺失风险”。

Claude Code 常见疏漏：

• 功能需要 contextMenus，但 manifest 里没声明（常见于 code generation 中被忽略的边缘权限）。
• 声明了 cookies 权限，但扩展内没有任何使用 chrome.cookies API 的代码。

第二步：域名范围精确性检查

目标：确保 host_permissions 和 content_scripts.matches 中的域名范围尽可能窄。

操作：

1. 检查是否存在 <all_urls>。如果有，暂停审查，回到功能分析，确认是否有任何功能确实需要访问“所有网站”。
2. 如果扩展只操作特定网站，检查域名匹配模式是否精确。例如：*://*.example.com/* 是否比 *://example.com/* 更合适？是否应该用 https:// 而非 *://？
3. 检查 content_scripts 的 matches 是否与 host_permissions 一致，不一致可能导致“声明了权限但脚本未注入”或“注入了脚本但未声明权限”的问题。

常见疏漏：

• host_permissions 写了 https://example.com/*，但 content_scripts.matches 写了 <all_urls>，后者覆盖前者。
• 使用了 *:// 前缀，意味着同时匹配 http 和 https。如果目标网站只支持 https，应该在模式中限定。

第三步：权限组合风险评估

目标：评估权限组合的整体安全轮廓和审核风险。

操作：使用前面提到的“组合风险检查表”，逐一扫描以下高风险组合：

• scripting + <all_urls> → 🔴 慎用。
• webRequest + host_permissions → 🔴 必须说明数据用途。
• tabs + host_permissions + storage → 🟡 是否能解释清楚数据流向。
• 权限总数 > 5 → 🟡 逐个审查必要性。
• cookies + <all_urls> → 🔴 极高关注。

标准：如果存在任何高风险组合，在你准备好“如何向审核人员解释”之前，不要提交。这个解释需要回答三个问题：

1. 为什么这个组合是实现功能的唯一方式？
2. 你如何使用这些权限访问的数据？
3. 你采取了什么措施保护这些数据？

第四步：运行时逻辑完整性检查

目标：确保 optional_permissions 声明的权限有对应的运行时请求代码，确保权限请求、检查、降级三个环节完整。

操作：

1. 搜索代码中是否对每个 optional_permissions 项都有 chrome.permissions.request() 调用。
2. 搜索代码中是否有 chrome.permissions.contains() 的状态检查。
3. 搜索是否有 chrome.permissions.onRemoved 的监听（当用户在设置中移除权限时做清理）。
4. 检查是否有权限被拒绝后的用户引导 UI。

Claude Code 的典型遗漏：

• 有 optional_permissions: ["geolocation"]，但代码里直接调用了 navigator.geolocation，跳过了权限请求。
• 有 optional_permissions: ["notifications"]，但没有处理用户关闭系统通知权限后的降级。

第五步：文档与政策一致性核查

目标：确保权限声明与隐私政策、商店描述一致。

操作：

1. 检查隐私政策中是否列出了扩展所有使用的数据权限（特别是 host_permissions 涉及的数据访问）。
2. 检查商店描述中是否说明了“为什么需要某些敏感权限”。Google 鼓励开发者在描述中加入“权限说明”段落。
3. 检查扩展是否在“首次使用某个权限时”向用户解释了用途（这是商店推荐的用户教育实践）。

这一条是很多技术导向的开发者会忽略的，但它是审核失败的常见原因之一。Google 的审核不只是看代码，也看“用户是否能理解这个扩展会做什么”。

七、不同扩展类型的权限配置策略对比

不同类型的 Chrome 扩展，在权限配置上面临的挑战和策略完全不同。我根据自己的开发经验，将常见扩展类型分为四类，每类给出针对性的 Claude Code 使用策略和权限配置原则。

内容增强型的 Claude Code 协作实例

这类扩展最常见，也最容易在权限上“过度”。我的经验是：在 Prompt 中明确列出目标域名清单，一个都不能多。

正确做法：

“host_permissions 只包含以下三个域名：example.com、testsite.org、demo-app.io”

错误做法：

“功能是在几个网站上修改样式，你帮我配一下权限”（Claude Code 大概率给出 <all_urls> 或过于宽泛的通配符）

数据采集型的高危红线

如果你在开发这类扩展，我的建议是：不要用 Claude Code 生成最终的权限配置。 把它当成一个“草稿生成器”，生成后你必须手动逐条审查。

为什么？因为数据采集型扩展的权限组合天然具有“用户监视工具”的能力特征。一个典型的错误配置案例：

我见过一个“网页内容变化追踪”扩展的 manifest：

• permissions: ["storage", "tabs", "scripting", "webNavigation"]
• host_permissions: ["<all_urls>"]

这个组合的实际能力是：静默访问用户打开的所有网页、获取页面内容、向所有页面注入脚本、对所有导航事件进行监听。 而扩展制作者的初衷仅仅是“监控某购物网站的商品价格变化”。

修正后应该是：

• permissions: ["storage", "alarms"]
• host_permissions: ["https://shop.example.com/*"]
• optional_permissions: ["notifications"]

权限从 4 个减少到 2 个（+1 个可选），域名从全站缩窄到一个具体购物网站。核心监控逻辑不依赖 tabs 或 scripting，而是通过定时 alarms 触发后台 fetch 请求来实现，更安全、更可控、审核更容易通过。

八、总结与行动建议：把 Claude Code 当作权限生成的“初稿助手”，而非“终稿作者”

写到这里，我想用一个比喻来总结整篇文章的核心观点：

Claude Code 在权限代码生成上的角色，应该像建筑工地上的“混凝土搅拌机”，它能高效地生产基础材料，但“这个地基该打多深、钢筋该配多粗、结构能不能抗八级地震”，必须由建筑工程师来判断。

把搅拌机当成建筑师，盖出来的楼迟早会塌。

你现在可以立刻执行的三件事：

第一，如果你正在开发一个新扩展：

• 使用本文第五节的“场景 A Prompt 模板”让 Claude Code 生成初版 manifest.json。
• 使用第六节的“五步审查法”逐条检查。
• 在确认无误前，绝不提交审核。

第二，如果你有一个已发布的扩展：

• 现在就打开你的 manifest.json。
• 对照第三步的“组合风险评估检查表”，看看是否存在被忽略的高风险组合。
• 使用“场景 C Prompt 模板”尝试一次权限最小化重构。

第三，如果你是技术团队的负责人：

• 将“五步审查法”固化为团队的 Code Review Checklist。
• 在 PR 流程中增加一条：任何涉及 manifest.json 权限变更的提交，必须附带“权限变更说明”（新增/移除原因、影响分析、降权考量）。
• 使用本文的“四层决策模型”培训团队成员：哪些环节可以信任 AI，哪些环节必须人工判断。

最后一点，关于 AI 编程助手在安全敏感领域的未来

我在写这篇文章的过程中，反复思考一个问题：Claude Code 这类 AI 编程助手，什么时候才能在权限配置上做到“真正可靠”？

我的判断是：在 AI 具备“安全后果推理能力”之前，它都无法胜任这个任务。

当前的 AI 编程助手基于“模式匹配 + 概率生成”，它能学会“geolocation 权限对应 navigator.geolocation API”这样的映射关系，但它无法理解“给一个只在特定网站运行的内容增强扩展加上 <all_urls> 权限，会让用户的银行账户信息暴露在扩展的访问范围内”这样的安全后果。

这不是能力升级能解决的问题，这是范式问题。除非 AI 具备了因果推理和后果预测的能力，否则在权限配置这类“错误后果严重且不可逆”的场景中，人类的判断将始终是不可替代的最后防线。

而作为开发者，我们最好的策略不是“希望 AI 变得更聪明”，而是让自己变得更警惕，同时让 AI 在“它擅长的环节”发挥最大价值。

生成样板代码？交给 AI。理解权限语义？请教 AI。但决定“这个扩展应该申请哪些权限”的，永远应该是你自己。

*如果你在 Chrome 扩展权限配置或商店审核中遇到过其他隐蔽的坑，欢迎在评论区分享。以及，如果你希望获得本文所有 Prompt 模板和一键复制的审查 Checklist，可以关注后回复关键词“扩展权限”。*