职责可以做得很小
可以规定成“在这个页面上，只协助这一个操作”。这比让 AI 理解整套庞大的业务系统，要窄得多。
01 · WHY AN EXTENSION
不改变现在的工作方式，
只添加一点小小的改进。
Chrome 扩展可以在你已经在用的 Web 服务上添加一个小功能，而不必重做那个服务。
而现在，借助 AI，这种小体量的软件比以前更容易做出来。
- 01 做得小。
- 02 由人确认。
- 03 在浏览器里用。
这三步，以及它们的顺序，就是本页要说的全部。顺序一变，说的就是另一回事了。
02 · 在人与服务之间
Chrome 扩展位于人和 Web 服务之间。
Web 服务是按照它自己的需要做出来的。只有你的岗位才需要的那一道手续，通常没法让服务方替你加上。
扩展不去重做那个页面，而是待在你的浏览器里，在当前显示的页面之上叠加一个用于确认或整理的小功能。
人
书写、粘贴、添加附件、发送。做判断的是这里。
浏览器（扩展运行的地方）
扩展进入的就是这里：叠加在正在显示的页面之上。
Web 服务
保持原样。不需要改造、不需要改配置、也不需要迁移。
扩展运行在你的浏览器里，并不是在改动服务本身。
代价是，它能做的事止步于浏览器。改写服务自身的数据、替换核心业务处理，都不适合交给扩展。
03 · AI × EXTENSION
用 AI 写的“小软件”，和 Chrome 扩展很合得来。
AI 正在大幅降低写软件的成本。
但这并不意味着让 AI 整个做出一套“什么都能干的大系统”就是最优解。交出去的范围越大，事后要确认的范围也越大。
相比之下，满足下面这些条件的小软件，和 AI 开发更合得来：
- 目的只有一个
- 作用的页面很明确
- 输入和输出都很小
- 所需权限很明确
- 行为可以由人确认
Chrome 扩展正是容易满足这些条件的形态。在一个页面上，只协助一个操作。做到这一步，它就已经是一件可用的工具。
这不是说“有了 AI 谁都能轻松做扩展”。写的量少了，但要做什么、能不能发布，这些判断依然留给人。合得来的原因，是要判断的对象可以保持得足够小。
04 · DEVELOPMENT LOOP
用 AI 生成，由人确认之后再使用。
实际的流程不是一条直线，而是一个短循环。而且这个循环里，有一段是刻意不自动化的。
AI 负责的部分
工作中的一个小麻烦
“在这个页面上，我每次都要确认这个。”缩小到一句话能写完为止。
AI Agent / AI Coding
不是一口气全做完，而是把功能拆开，一小块一小块地实现。
一个小小的 Chrome 扩展
一个目的，一个页面。到这一步，它还只是“能跑”而已。
确认权限、代码与行为（由人／由机制）
生成出来的东西不会就这样被使用。要先经过这里，才往下走。
- manifest 权限
- 有无外部通信
- 保存位置
- 真实浏览器中的行为
人使用的部分
在 Chrome 里使用
还是那个浏览器，还是那个页面。使用者的步骤基本不变。
反馈
用起来才会发现的别扭之处。其中大多数，看代码是看不出来的。
改进
要改的范围很小，所以“改不改”这个判断也很轻。
改完之后，又回到重新定义麻烦。这一圈转得快，正是这种做法的好处。
这张图里重要的是它没有写的部分。它没有写“AI 会全自动地、安全地做好一切”。在生成与使用之间，有人在看。
为什么这种形态和 AI 开发合得来
浏览器就是运行环境
如果功能能在浏览器内部闭环，就不必另外搭建庞大的服务器基础设施。当然，并非所有需求都是如此。
权限是看得见的
Chrome 扩展会在 manifest 里声明所需权限。面对 AI 写出来的代码，这是一条可以用来追问“它会访问什么”的边界。
行为容易确认
输入、点击、复制、发送。涉及的操作相对清晰，所以你可以在真实的浏览器里自己动手确认。
可以小步改进
不必一次做完一个庞然大物，而是转动“做出来 → 用起来 → 遇到问题 → 改掉”这个短周期。
05 · 不需要大改造
不需要大规模的系统变更。
更换业务系统，在费用、周期和牵涉的人数上都很大。为了“每次在这个页面都要确认一下”这种程度的麻烦，去选择那种规模的变更并不现实。
扩展是把现有页面原样留着，在它之上再加一层。对使用的人来说，步骤基本还是原来的。
- 有些场景可以在服务方不作任何改造的情况下开始
- 可以保留现在的页面和操作来试用
- 不合适就卸掉，回到原来的状态
这并不等于“什么都可以用扩展解决”。发生在浏览器之外的处理，以及牵涉服务方数据一致性的需求，都不在扩展的职责范围内。
AI × CHROME EXTENSION × ENTERPRISE
三层叠起来，才成为能持续下去的形态。
每一层单独也说得通，但按这个顺序叠起来，就变成了不会止步于“做完了”的推进方式。
LAYER 01
AI
以短周期做出小功能。把需求拆开交给它实现，再由人确认。
LAYER 02
Chrome Extension
为现有的 Web 工作添加功能。不重做服务，直接送到页面之上。
LAYER 03
Enterprise Management
面向需要的对象进行许可、分发与管控。发给谁、允许什么，由管理员决定。
把这三层组合起来，就成了这样一种推进方式：不全面重做既有系统，而是持续地追加细小的业务改进。
06 · 个人、团队、企业
个人开始，团队使用，企业管理。
如果大部分工作都发生在浏览器里，那么想省掉的那道手续也在浏览器里。所以一个人试出来的形态，可以照原样推广到团队，必要时推广到组织。使用的单位变了，工具的形态没变。
个人
装进自己的浏览器，让自己的活儿轻一点。不需要别人同意，当天就能试。
团队
每天盯着同一个页面的几个人一起用。效果和副作用都很快显现，所以能很快判断要不要继续。
企业
划定对象来分发，并以策略进行管理。判断的依据，是它申请的权限和对实际行为的说明。
07 · CHROME ENTERPRISE
在企业里，管理员可以许可、分发和管控。
Chrome 扩展未必是“各人自己随便装”的东西。通过 Google 管理控制台（Chrome Enterprise Core），可以把策略下发到组织的 Chrome。要不要在工作中使用扩展，可以在这个前提上讨论。
- 选择整体方针。在管理控制台里，可以选择“全部允许并用黑名单拦截”“全部阻止并只放行白名单”“白名单之外再接受用户申请”等方针。
- 逐个指定。通过 ExtensionInstallAllowlist / ExtensionInstallBlocklist / ExtensionInstallForcelist / ExtensionSettings 等策略，决定每个扩展的处理方式。
- 按权限判断。可以依据扩展申请的权限来决定放行与否，也可以让它在特定站点上停止运行。
- 受理申请。用户提交的扩展申请，管理员可以许可、阻止，或者直接强制安装。
- 在组织内分发。有办法只面向自己的 Google Workspace 域发布（面向组织的 Chrome 应用商店）。
具体能做到哪一步，取决于所签约的版本和管理设置。在做决定之前，请与贵司的管理员以及 Google 的官方文档确认。以下是 Google 的页面。
允许或阻止应用与扩展程序support.google.com
受理扩展程序申请的工作流support.google.com
Chrome Enterprise 策略列表chromeenterprise.google
面向组织的发布方式（Enterprise publishing options）developer.chrome.com
08 · 我们也是这样做的
Legacy Tools 也是按这个形态做的。
本站发布的是八款 Chrome 扩展。每一款都只针对一个场景——发送前确认一次、粘贴前替换一下——而不是通用的业务系统。
做法也和本页写的一样：先把麻烦写成一句话，再把功能拆开交给 AI 实现，装进自己的 Chrome 里用，确认权限、通信和保存位置之后才发布。
做完八款之后明白的是：能交给 AI 的部分，和只能由人来定的部分，界线其实很清楚。比起做得多快，决定做什么、能不能发布，反而更花时间。
09 · 权限与本地处理
“是扩展所以安全”并不成立。正因如此才要确认。
Chrome 扩展既可以申请读取页面内容的权限，也可以申请接触输入内容的权限。形态是扩展，本身并不构成安全保证。把这一点含糊过去，就没法认真讨论在工作中使用它。
不过，确认的手段是有的。所需权限会在 manifest 中声明，并在安装时显示出来。装进去之前，你可以先读一遍它会访问什么。
- 它在哪些站点上运行
- 它保存什么，保存到哪里
- 它是否向外部发送
- 每次更新，申请的权限有没有变多
本站这八款的设计，是让处理在浏览器内部完成，不把你输入的内容发到外部。各产品的权限与处理范围，在技术透明页面上按产品列出。
10 · 与既有管控的关系
它不能取代 DLP 或日志审计。
企业里已经有一整套关于信息处理的机制：DLP、日志、审计、访问控制。扩展不是它们的替代品。
位置不同。多数管控是在数据经过通路时、或经过之后才起作用；扩展介入的是更靠前的地方——人按下发送键的前一刻。
所以是并用的关系。前面能察觉的次数变多了，后面的管控依然必要；反过来，即便后面有管控，要不要发送的判断仍然由人做出。
而且，扩展本身也是被管控的对象。允许哪些扩展、发给谁，如 07 所写，由管理员决定。“来路不明的扩展会越装越多”这份担心，和“用扩展改进工作”这件事，可以在同一套策略下并存。
11 · 从一件事开始
先从一项工作开始。
不必从全公司推行的计划开始。一个页面、一个操作、一个团队。这个规模下，不合适还能退回去。
-
1
把麻烦写成一句话
在哪个页面、做什么的时候、要确认什么。这句话一直含糊，做出来的东西也会含糊。
-
2
先看看现成的够不够用
做同样事情的扩展，也许已经有人发布了。那样的话，与其自己做，不如确认它的权限和行为再选它，更快。
-
3
做得小，然后自己用
一个页面，一个操作。做到能跑之后，就在真实的浏览器里自己用一用。有些别扭之处，光读代码是读不出来的。
-
4
确认之后，再扩大
确认了权限和行为，再拿给团队。要在组织里用，分发和策略的事就在这一步谈。顺序反过来，之后想退回去就难了。
本页能说的就到这里。既不是“有 AI 就能轻松做”，也不是“是扩展所以安全”。Chrome 扩展容易被设计成职责小、作用范围小的东西，因此和“由 AI 实现、由人确认”这种做法合得来。要主张的，只有这一点。