用claude code辅助编写Chrome扩展时的权限声明遗漏

三个月前的一个周三晚上，我盯着Chrome扩展管理页面看了整整二十分钟。扩展图标是灰的，控制台干净得像刚擦过的白板，但所有API调用都返回了undefined。这个插件我让Claude Code帮忙写了三个小时，代码逻辑检查了三遍，没有任何语法错误。问题出在manifest.json的第17行，或者更准确地说，出在第17行缺少的那句话上。

这不是第一次，也不会是最后一次。当我开始系统性地记录这个现象时，发现过去半年里，我在用AI辅助开发的11个Chrome扩展中，有8个在首次加载时因为权限声明不完整而部分功能失效。最讽刺的是，Claude Code生成的代码本身没有任何功能性错误，它只是在声明环节保持了“过度的克制”。

这篇文章不是AI使用教程，也不是权限文档的翻译。这是一次深度复盘：我在什么场景下中招最多、AI为什么天然会“省掉”权限、哪些权限最容易被遗漏、以及我搭建的一套“权限审计”工作流。如果你正在用Claude Code或其他AI编程助手开发浏览器扩展，这些经验能帮你省下至少三个小时的排查时间。

一、核心结论：AI擅长写“功能性代码”，但在“声明性安全”上存在结构性的认知盲区

先说清楚一个大前提：我并不是在批评Claude Code不好用。正相反，我在2024年全年用AI辅助完成了47个前端项目模块，开发效率提升了大约60%。但效率提升的前提是，你得清楚AI的边界在哪里。

在Chrome扩展开发这个特定场景下，AI的边界可以用一句话概括：它能完美地从Context中推断“你想要什么功能”，但它很难推断“为了实现这个功能，浏览器需要给你开哪些权限”。

这背后有三层原因：

第一层，训练数据的偏见。Claude在生成代码时，被训练成倾向于“最小权限原则”。这是安全领域的金科玉律，但在扩展开发场景中，“最小权限”和“必要权限”之间存在着巨大的鸿沟。AI不知道你的扩展是要做数据持久化还是要做跨域请求，它默认认为你“可能不需要”。

第二层，声明式编程的隐性负担。Chrome扩展的manifest.json是一个声明式配置文件，它要求开发者在写代码之前就声明好所有需要的权限。但AI生成代码是“流式”的，它从第一行写到第一百行，写完功能逻辑后，manifest.json早就在上一步生成好了。它不会在写完chrome.storage.sync.set()之后，回头去manifest里补一个storage权限。

第三层，版本差异的混淆。Manifest V2和V3的权限声明格式有本质区别。V2用permissions数组包揽一切，V3把主机权限拆分到了host_permissions。训练数据里混合了大量V2时代的代码样本，AI有时会生成错误的格式，有时干脆为了避免出错而省略某些声明。

这个统计让我意识到一个关键事实：用AI写Chrome扩展时，你需要把“审查权限声明”当作一个独立的、不可跳过的质量门禁，而不是开发流程中可有可无的环节。

二、一次真实的“权限坍塌”事故全记录

2024年12月初，我接到一个需求：给一个内部知识库系统做一个Chrome扩展，功能很简单，当用户在任意网页上选中一段文本，右键点击后，扩展会把选中的文本自动保存到知识库的“临时剪藏”区域，并弹出一个通知提示保存成功。

听起来简单对吧？

我打开Claude Code，用了大约15分钟完成了需求描述和代码生成。以下是AI生成的manifest.json核心部分（我已脱敏处理）：

{
"manifest_version": 3,

"name": "Knowledge Base Clipper",

"version": "1.0",

"permissions": [

"activeTab",

"contextMenus"

],

"background": {

"service_worker": "background.js"

},

"action": {

"default_title": "Clip to KB"

}

}

再看看background.js里的核心逻辑：

chrome.contextMenus.create({
id: "clipToKB",

title: "保存选中文本到知识库",

contexts: ["selection"]

});

chrome.contextMenus.onClicked.addListener(async (info, tab) => {

if (info.menuItemId === "clipToKB") {

const selectedText = info.selectionText;

// 这里调用了知识库的API

const response = await fetch("https://kb.internal.com/api/clip", {

method: "POST",

headers: {"Content-Type": "application/json"},

body: JSON.stringify({text: selectedText, url: tab.url})

});

// 保存成功要发通知

chrome.notifications.create({

type: "basic",

title: "保存成功",

message: "选中内容已保存到知识库",

iconUrl: "icon.png"

});

// 想记住用户的使用次数

const {count} = await chrome.storage.local.get("count");

await chrome.storage.local.set({count: (count || 0) + 1});

}

});

这个代码看起来逻辑流畅，没有任何语法问题。但我安装到Chrome之后，出现了以下症状：

1. 右键菜单能正常显示，这说明contextMenus权限没问题。
2. 选中文本后点击菜单项，没反应，知识库的API没有被调用。
3. 控制台没有任何报错，这才是最让人困惑的地方。

我开始逐行排查。首先怀疑是fetch请求被跨域拦截了。在Service Worker的控制台里手动执行fetch("https://kb.internal.com/")，返回的是Failed to fetch。找到了，跨域请求被Browser的CORS策略阻止了，但Chrome对Service Worker里的跨域报错处理得很沉默，没有扔出可见的异常，只是让请求静默失败。

再往下查，chrome.notifications.create也没有任何反应。我查Chrome扩展文档，发现notifications是需要显式声明的权限。AI生成的manifest里没有。

继续查，chrome.storage.local同样需要storage权限。manifest里也没有。

最终我手动修复后的manifest.json是这样的：

{
"manifest_version": 3,

"name": "Knowledge Base Clipper",

"version": "1.0.1",

"permissions": [

"activeTab",

"contextMenus",

"notifications",

"storage"

],

"host_permissions": [

"https://kb.internal.com/*"

],

"background": {

"service_worker": "background.js"

},

"action": {

"default_title": "Clip to KB"

}

}

新增了三项：

• notifications：让通知API生效
• storage：让本地存储API生效
• host_permissions：允许访问内部知识库的域名

这个案例暴露了AI在权限声明上的三个典型盲区：对跨域需求的无感知、对UI反馈类API的忽视、对持久化需求的不敏感。Claude Code在处理这段代码时，显然“理解”了功能逻辑，它知道要用fetch发请求、用notifications发通知、用storage存数据，但它没有将这些功能需求“反向映射”成权限声明。

三、为什么AI天然会“省掉”权限：从训练机制到行为模式的深度分析

在经历那次“100分钟排查”之后，我开始系统性地研究AI在权限声明上的行为模式。我在2024年12月到2025年2月期间，用不同的提示词让Claude Code生成了36个不同类型的Chrome扩展框架，记录每一次manifest.json的权限声明情况。以下是我的观察结论。

3.1 AI的“安全审慎”如何异化为“功能阉割”

先看一组对比数据：

在36次测试中，AI最常声明的权限是：activeTab（出现36次，覆盖率100%）和contextMenus（在涉及右键菜单时出现，覆盖率约40%）。而最常被遗漏的权限前三名是：storage（遗漏率78%）、host_permissions（遗漏率73%）、notifications（遗漏率100%）。

为什么storage和notifications这么容易被漏掉？因为这些API在代码层面表现为“方法调用”，chrome.storage.local.get()看起来就像是在调用一个内置对象的方法，而非请求一项特权。而activeTab之所以从未被遗漏，是因为AI在写扩展骨架时，几乎总会写一句“需要获取当前标签页信息”，这让它在生成manifest时自动带上了这项权限。

AI的“理解”存在一个根本性的不对称：它对“主动获取”类权限敏感（如获取标签页、创建菜单），对“静默使用”类权限迟钝（如存储数据、发送通知、跨域请求）。

3.2 流式生成的“回头看”缺失

Claude生成代码时，manifest.json通常是第一个被生成的文件。然后它会基于这个manifest开始写service worker、content scripts、popup等。整个过程是线性的、向前的。

问题在于，当AI在写background.js时“突发灵感”加了一个chrome.storage.local.set()，它不会触发“哎呀我之前声明的权限不够”这种回溯式思考。这不是技术能力的缺失，是生成范式的结构性特点。

我做过一个实验：在提示词里明确要求“请在生成所有代码后，重新检查一次manifest.json，确保所有权限都已声明”。结果在10次测试中，只有3次AI真的补全了缺失权限。另外7次，它要么忽略了这条指令，要么在“检查”时只是重新读了一遍manifest，没有实际和代码做交叉验证。

我的经验是：永远不要指望AI自己发现自己漏了权限。 你必须在对话的某个环节，把权限审查作为一个独立任务，用明确的清单和对照方式去执行。这点我会在第六部分详述。

3.3 V2与V3规范的“语义漂移”

还有一个让人头疼的问题是Manifest版本差异带来的混乱。

在V2时代，所有权限都放在一个permissions数组里。要访问某个域名，就写<all_urls>或具体域名。到了V3，主机权限被单独拆出来放在host_permissions里，而且格式从数组的简单字符串变成了更结构化的表达。

AI训练数据中混杂了大量V2的示例。当它被要求“写一个Chrome扩展”时，有时候会生成一个混合格式的manifest，比如把域名放在permissions里（V2写法），同时又在最外层声明了manifest_version: 3。这种“格式混血”会导致Chrome在安装时静默忽略某些权限，而不是报错。

我在实际开发中遇到过最离谱的情况是：AI生成了一个V2格式的permissions包含"https://api.example.com/"，安装后扩展能正常工作，因为Chrome 120以前的版本对V3扩展中的V2权限格式还能“兼容性读取”。但到了Chrome 122，这个兼容性被移除了，扩展突然不再能访问那个API。用户反馈回来，我查了两天才找到根因。

四、最容易失踪的权限清单：从代码调用反推声明需求的对照表

经过前三次“事故”后，我建立了一套“代码反查”机制：每当AI生成完扩展代码，我就用grep命令搜索所有chrome.*方法调用，然后对照Chrome官方文档，确认每一项是否在manifest中声明。现在我把这种反向映射整理成了一张对照表。

4.1 核心权限对照（最常见遗漏项）

4.2 AI最容易“错位”声明的三个场景

除了完全遗漏，还有一类问题是“声明了但不匹配”。这比遗漏更隐蔽，因为manifest看起来该有的都有了，但扩展就是不工作。

场景一：activeTab与host_permissions的混淆

activeTab是AI最喜欢的权限，因为它能覆盖“用户主动点击扩展图标时”的场景，又不需要声明具体域名。但activeTab只在以下条件同时满足时才生效：

• 用户调用了扩展的action（点击图标或使用快捷键）
• 或者用户通过右键菜单触发了扩展

如果你的扩展需要在后台静默处理某个页面的内容，比如页面加载完成后自动注入CSS，activeTab是不够的，必须声明host_permissions匹配目标URL模式。

AI常常生成这样的代码逻辑：“在页面加载完成后修改页面样式”，却只声明了activeTab。代码看起来没问题，但chrome.scripting.executeScript在非用户触发的情况下会失效。这是一种“半工作状态”，用户在某个页面点扩展图标能work，但自动触发的逻辑永远不会执行。

场景二：tabs权限的过度使用与不足

tabs权限有不少子能力：tabs.query()通常只需要tabs权限声明即可；但要用tabs.Tab对象里的url字段，有时需要host_permissions配合才能读取到完整的URL。

AI的常见错误是：声明了tabs，但在background脚本里读取跨域标签页的详细信息时失败。因为从Chrome 86开始，为了保护隐私，标签页的url和title在未获得相应的host_permissions时可能返回空值或undefined。

场景三：<all_urls>的滥用与替代方案

AI有时会走向另一个极端：为了“不出错”，直接声明<all_urls>。这在功能上确实能解决问题，但它会让Chrome Web Store的审核更严格，且在用户安装时显示一个“此扩展可以读取和更改您在所有网站上的所有数据”的警告。这是很多用户卸载扩展的首要原因。

更好的做法是精准匹配域名模式。如果你的扩展只需要访问两个API域名，就在host_permissions里精确写这两个域名。这种声明不仅更容易通过审核，用户看到的权限提示也更友好。

五、我的“权限审计工作流”：10分钟检查清单的演化史

经过前几次“排查两小时、修复五分钟”的痛苦经历后，我给自己定了一条铁律：每次AI生成完扩展代码后，立即执行一个标准化的权限审计流程，不跳任何一步。 到现在，这个流程已经迭代到了第三个版本。

5.1 V1版本：手动对比（效率低但基础扎实）

第一版流程非常“手动”，打开Chrome扩展的官方权限列表页面，然后逐行检查AI生成的代码，把所有chrome.*API调用记录在一个文本文件里，再去manifest里核对。

这个版本的好处是让我对权限体系有了很深的理解。坏处是太慢了，小型扩展也要15分钟，复杂扩展要半小时以上。

5.2 V2版本：Shell脚本自动化扫描

2024年11月，我把手动检查的过程写成了一段Shell脚本。逻辑很简单：

#!/bin/bash
echo "=== Chrome扩展权限审计 ==="

echo ""

1. 扫描所有chrome.* API调用

echo "## 代码中检测到的Chrome API调用："

grep -roh 'chrome\.[a-zA-Z]*\.[a-zA-Z]*' . | sort -u

echo ""

echo "## manifest.json中已声明的权限："

2. 提取manifest中的permissions和host_permissions

grep -A 20 '"permissions"' manifest.json | grep '"' | head -20

echo ""

echo "## 建议检查项："

3. 关键词匹配提醒

grep -rl 'chrome.storage' . > /dev/null && echo "⚠️  检测到chrome.storage调用，请确认manifest中已声明'storage'权限"

grep -rl 'chrome.notifications' . > /dev/null && echo "⚠️  检测到chrome.notifications调用，请确认manifest中已声明'notifications'权限"

grep -rl 'fetch(' . > /dev/null && echo "⚠️  检测到fetch调用，请确认manifest的host_permissions中已声明目标域名"

这个脚本把我从手动核对中解放了出来。但它有两个局限：一是无法准确提取host_permissions中的域名模式（因为它不知道fetch的目标URL是什么），二是它只能提醒“需要注意”，不能直接给出修复建议。

5.3 V3版本：“生成-审计-修复”一体化流程

到2025年1月，我把权限审计彻底融入到了开发对话中。具体做法是这样的：

第一步：在生成代码前，先定义权限需求矩阵

在给Claude Code下任务时，我会在提示词末尾加一段：

【权限声明要求】
这个扩展需要使用以下Chrome API，请在manifest.json中正确声明：

chrome.storage.local（需要 permissions: ["storage"]）

chrome.notifications（需要 permissions: ["notifications"]）

fetch到 https://api.example.com（需要 host_permissions: ["https://api.example.com/*"]）

chrome.tabs.query（需要 permissions: ["tabs"]）

请确保manifest.json包含所有上述权限，Manifest版本为V3。

这个策略的效果立竿见影。在前面提到的实验中，明确列出所需权限后，AI的声明完整率从45%跃升到92%。

第二步：代码生成完成后，执行交叉验证

我不再依赖AI的自我审查，而是用自己的脚本做一次快速扫描。脚本会：

1. 提取所有chrome.*和fetch(调用
2. 与manifest.json中声明的权限池做对比
3. 输出一个“疑似遗漏列表”

第三步：用Claude做针对性修复

把“疑似遗漏列表”再送回给Claude Code：“manifest.json中似乎缺少了以下权限声明：[列表]，请帮我补上，并确保格式符合Manifest V3规范”。

这三步走下来，我从发现问题到完成修复的平均时间从100分钟下降到了约12分钟。

六、optional_permissions：一个被AI严重低估的优雅方案

在分析AI生成的36个测试扩展时，我发现了一个有趣的现象：没有任何一个扩展使用了optional_permissions。

这很值得深思。因为在Chrome扩展的最佳实践中，optional_permissions是平衡“功能需求”和“用户信任”的关键工具。它允许扩展在安装时不请求某些权限，而是在用户首次使用相关功能时动态申请。

6.1 AI为什么不生成optional_permissions？

我分析有三个原因：

第一，训练数据中的示例较少。大多数Chrome扩展教程和示例代码为了简洁，都直接在permissions里声明所有权限。用optional_permissions的示例本身就少得多。

第二，生成复杂度更高。使用optional权限意味着不仅要修改manifest，还要在代码中编写权限请求逻辑（chrome.permissions.request()）、处理用户拒绝的情况、以及检查权限是否已授予（chrome.permissions.contains()）。这对AI来说是需要额外“思考”的步骤。

第三，AI的“一步到位”倾向。Claude倾向于生成“可以直接用”的完整方案。声明所有权限虽然会让安装提示更吓人，但能让扩展“开箱即用”。这种倾向忽略了用户体验的一个重要维度，安装时的信任建立。

6.2 什么情况下应该用optional_permissions？

基于我的实际项目经验，以下场景特别适合用optional权限：

• 非核心功能：比如一个阅读辅助扩展，“保存到云端”功能需要storage权限和API访问权限，但“本地高亮标注”功能只需要host_permissions。可以让用户先安装基础版本，在使用云存储功能时再请求权限。
• 高敏感权限：webRequest、cookies这类能读取用户浏览数据的权限，用optional模式能显著降低用户的安装顾虑。
• 特定域名访问：如果你的扩展可以适配多个网站，可以在用户访问某个特定网站时，按需请求该域名的host_permissions。

6.3 如何使用optional_permissions（附AI协作策略）

第一步，在manifest.json中声明：

{
"permissions": ["activeTab", "contextMenus"],

"optional_permissions": ["storage", "notifications"],

"optional_host_permissions": ["https://api.example.com/*"],

}

第二步，在需要使用optional权限的地方，先检查再请求：

async function ensureStoragePermission() {
const hasPermission = await chrome.permissions.contains({

permissions: ['storage']

});

if (hasPermission) {

return true;

}

const granted = await chrome.permissions.request({

permissions: ['storage']

});

return granted;

}

// 使用前先确认权限

async function saveToStorage(data) {

const canProceed = await ensureStoragePermission();

if (canProceed) {

await chrome.storage.local.set(data);

} else {

// 用户拒绝了权限，做降级处理

console.warn('用户未授予storage权限，数据将不会持久化');

}

}

如果你在用Claude Code，可以直接这样描述需求：

“请在manifest中把storage和notifications声明为optional_permissions，并在代码中加上权限检查和请求的逻辑。如果用户拒绝授予权限，使用console.warn做降级处理，不要让扩展崩溃。”

我测试过10次这样的提示，AI 8次能正确生成完整的optional permission逻辑，2次忘了写用户拒绝时的降级处理，还是需要人工检查，但总体质量比让它“自己考虑用什么权限”高得多。

七、Manifest V3的隐秘变化：你还在用V2的思维声明权限吗？

2024年1月，Chrome团队宣布V2扩展将从2025年6月开始逐步淘汰。但截至2025年初，我接触的开发者中仍有大约40%还在用V2的思维写manifest。迁移到V3不仅是格式变化，权限声明也有几个“暗坑”。

7.1 host_permissions：从内嵌到独立

V2时代，域名权限直接写在permissions里：

// V2写法
{

"permissions": ["https://*.example.com/*", "storage", "tabs"]

}

V3要求单独声明：

// V3写法
{

"permissions": ["storage", "tabs"],

"host_permissions": ["https://*.example.com/*"]

}

AI在这个点上经常出错。因为训练数据里混合了两种格式，有时候生成的manifest把域名放在permissions里，但同时声明了manifest_version: 3。在Chrome 120之前，浏览器能兼容这种格式错误，但从Chrome 122开始，这种错误直接被忽略，不报错，但也不生效。

解决方案：永远在提示词里明确指定“请使用Manifest V3格式”，并且在审计脚本中加入对host_permissions格式的专项检查。

7.2 background.service_worker与持久化权限的关系

V3把background从持久化页面（persistent page）改成了Service Worker（SW）。SW会被浏览器在不使用时休眠。这意味着：

• 如果你在SW里使用了chrome.storage.local，数据不会丢失，storage是持久化的，和SW是否休眠无关。
• 但如果你在SW里使用了全局变量来存储状态，SW休眠后这些变量会丢失。必须用storage来持久化。

很多AI生成的代码在SW里使用全局变量，同时忘记了声明storage权限。这是一个连锁反应：因为SW会休眠，所以需要用storage，但因为AI没考虑SW休眠的问题，所以它也没意识到需要storage权限。

7.3 scripting.executeScript：V3的新权限项

V3里，chrome.scripting.executeScript需要单独的scripting权限。在V2里，这个功能是通过chrome.tabs.executeScript实现的，只需要tabs权限。AI偶尔会混用V2和V3的API名称，导致声明的权限和实际调用的API不匹配。

例如：代码里写了chrome.scripting.executeScript（V3 API），但manifest里只声明了tabs（V2思维）。或者是反过来，声明了scripting，但代码里还在用旧的chrome.tabs.executeScript。

八、不同体量项目在权限声明策略上的取舍

并不是所有项目都需要同级别严格的权限审计。根据我的经验，项目的复杂度和用户规模决定了你应该投入多少精力在权限管理上。

8.1 个人工具类扩展（用户<100，功能单一）

这类扩展的目标是“能用就行”。你在意的不是Chrome Web Store的审核，也不是用户对权限警告的恐惧，而是开发效率。

推荐策略：使用第四节里的“代码反查清单”做一次快速检查，确认没有遗漏即可。optional_permissions在这种场景下是过度设计，增加了代码复杂度，但收益很小。

时间投入：5分钟权限检查，容许首次安装后发现有遗漏再修复。

8.2 团队协作工具（用户100-1000，功能中等复杂）

到了这个量级，权限声明开始影响真实用户。安装时的权限警告会直接导致部分用户放弃安装。

推荐策略：

• 核心功能必须的权限放permissions
• 增值功能相关的权限放optional_permissions
• 在安装引导页解释为什么需要这些权限

时间投入：15分钟权限架构设计 + 5分钟代码级审计。

我在2024年给一个内部CRM扩展做权限优化时，把storage和notifications从permissions移到了optional_permissions，安装转化率提升了约22%。用户看到“这个扩展不需要任何特殊权限”时，点击“添加扩展”的犹豫期明显缩短。

8.3 公开发布的扩展（用户1000+）

面向公众的扩展，权限声明是用户信任的第一道门槛。我用过的一个关键原则是“最大克制”，声明绝对必要的、只声明精准匹配的。

推荐策略：

• 做一次完整的“权限最小化审计”：检查每个声明的权限是否真的被代码调用
• 使用host_permissions而不是<all_urls>（除非扩展的定位确实是全站工具）
• 考虑在首次使用权限时用optional_permissions动态申请
• 准备一份隐私说明，解释每个权限的用途

时间投入：完整审计可能需要1-2小时，但对于千级用户的产品来说，这笔时间投资完全值得。

九、AI辅助Chrome扩展开发的完整checklist

我把前面分散在各个章节的检查点整合成一个可直接使用的开发流程。每当你用AI生成一个扩展的代码后，按顺序执行以下检查：

阶段一：代码生成前的提示词准备

• [ ] 在提示词中明确列出扩展需要使用的所有Chrome API
• [ ] 指定Manifest版本为V3
• [ ] 说明哪些权限可以设为optional
• [ ] 如果有跨域请求，明确列出目标域名

阶段二：代码生成后的自动扫描

• [ ] 运行grep脚本，提取所有chrome.*调用
• [ ] 运行grep脚本，提取所有fetch(和XMLHttpRequest调用
• [ ] 与manifest.json中的permissions和host_permissions做对比
• [ ] 标记所有“代码中有调用但manifest中无声明”的项

阶段三：手动核对高遗漏率项

以下五项检查不看脚本结果，手动逐项确认：

• [ ] storage：是否有数据需要持久化？
• [ ] notifications：是否需要向用户发送系统通知？
• [ ] host_permissions：是否有跨域fetch/XHR请求？目标域名是否精确？
• [ ] tabs：是否需要读取或修改其他标签页？
• [ ] scripting：是否需要动态注入脚本？

阶段四：安装后的功能测试

• [ ] 加载扩展后，开启Service Worker的控制台
• [ ] 逐项触发所有功能，观察控制台是否有静默错误
• [ ] 特别注意：fetch跨域失败、storage读取返回undefined、notification无反应，这三类是最常见的“无声故障”
• [ ] 如果使用了optional_permissions，测试用户授予和拒绝两种路径

这个checklist我在2025年已经用了超过50次，它把权限相关的bug从“占扩展问题总数的35%”降低到了“不到5%”。

十、未来展望与个人反思

写了这么多，我想在最后说几句“超出技术细节”的话。

我们正在进入一个“AI生成代码、人类负责审查”的新范式。这个范式改变了开发者的核心技能构成。以前，你的价值在于“能写出正确的代码”；现在，你的价值越来越多地转向“能判断AI生成的代码在哪些维度上是错的”。

权限声明只是这个大趋势上的一个小切片。AI在代码语法、算法逻辑、数据处理上的表现越来越好，但在“声明式安全”、“用户体验的隐性约束”、“平台规范的边缘情况”这些维度上，它仍然有系统性的盲区。

这些盲区恰恰是开发者不可替代的价值所在。你不会因为有了计算器就不用学算术了，同样，你不会因为有了AI就可以放弃对平台规范、安全策略、用户体验这些“底层逻辑”的理解。正相反，AI越强大，这些深层知识就越成为区分“会用的”和“真正懂行的”之间的分水岭。

我现在的做法是：把AI当作一个极其高效的初级工程师，它产出代码的速度是我的10倍，但我会像审查初级工程师的代码一样审查它的输出，带着对平台机制的理解，带着对人类用户需求的感知，带着对“它能做什么”和“它不知道自己在做什么”的清醒认知。

如果你也在用Claude Code或其他AI工具开发Chrome扩展，我的建议很简单：下次生成代码后，不要直接点“添加到Chrome”。拿出10分钟，对照第六部分的checklist做一次权限审计。这10分钟可能会帮你避免一个小时后在排查“为什么一切都看起来正常，但扩展就是不动”时的抓狂。

工具给你效率，但你得给工具方向。权限声明这件事，工具不懂什么叫“只做必要的事”，但你懂。