让 AI 做一个图片压缩工具，或者把表格转换成另一种格式，本来只是想省一点重复操作。

如果它给出的方案里，已经出现了服务器、数据库、对象存储和一串账号，你可以先不急着注册。

有些功能确实需要这些东西。但也有一些工具，从读取文件到生成结果，都能在自己的电脑上完成。浏览器不只是一个显示网页的窗口，它也能干活。

要不要服务器，取决于工具运行时需要什么，不取决于它是不是 AI 写的。

9 月 7 日，开发者 Simon Willison 公开了一个视频压缩工具的制作记录。他录了一段手机演示视频，想压缩后放到博客，于是让 Claude Code 帮他做了个网页。

这个工具页面可以读取视频，按不同参数生成几份结果，让人比较画质和体积，再下载合适的一份。页面明确说明，转码在浏览器中进行，视频不上传。

这里有个容易忽略的区别：AI 参与了工具的开发，但每次压缩视频时，并不需要再问一次大模型。

负责压缩的是 FFmpeg，一套成熟的音视频处理软件。这个网页使用的是它的浏览器版本 ffmpeg.wasm。

你可以把这种工作方式理解为：AI 帮忙把操作界面和处理程序接好，工具做好以后，按已经确定的规则运行。

用 AI 造出来的工具，不一定是一个持续调用 AI 的工具。

平常我们看到“选择文件”，很容易把它理解成“上传”。其实这是两件事。

按照 MDN 对 File API 的说明，网页可以读取用户主动选择或拖进去的文件。这里的 API 是浏览器提供的编程接口，不是需要付费接入的云端模型服务。读到文件以后，是留在浏览器里处理，还是通过网络发出去，要看后面的代码。

因此，一个挂在网上的工具，可以只负责把程序送到你的浏览器。程序加载完成后，计算使用的是你这台设备的处理器和内存。

网址来自网络，不代表每一份输入文件都必须交给远程服务器。

这也解释了为什么“发给朋友一个网址”和“文件留在各自电脑上”并不矛盾：大家打开的是同一个工具，处理的可以是各自选择的本地文件。

不过，有选择文件按钮，不能证明网站不上传；页面写着“本地处理”，也不等于已经做过隐私审计。是否外发仍然需要看实现和网络请求，陌生网站尤其如此。

普通网页通常用 JavaScript 处理交互和计算。再复杂一些的现成程序，也可以通过 WebAssembly 进入浏览器。WebAssembly 常缩写为 Wasm，可以先把它理解为一种让编译后的程序在浏览器里运行的技术。

ffmpeg.wasm 官方文档介绍的就是这种做法：把 FFmpeg 及相关库移植过来，让音视频处理在用户端完成。

所以，做工具时不必只有“调用一个收费接口”这条路。裁切图片、生成二维码、整理文本、按明确规则处理表格，都可以先评估现成的本地计算方案。具体能支持哪些格式、文件有多大，还得逐项确认。

这不意味着功能越复杂越适合塞进网页。

视频压缩很吃算力。Simon 的工具就提醒用户，它的单线程浏览器转码比原生 FFmpeg 慢，长视频要多等一会儿。ffmpeg.wasm 的官方 FAQ也提示了性能和资源占用的取舍。

省掉服务器计算，并没有让计算凭空消失，只是换成自己的设备承担。电脑风扇转起来、手机发热、页面处理大文件变慢，都应该进入方案评估，而不是等做完才发现。

先看任务是不是主要围绕一份现成文件展开。

比如，你已经有图片，只需要调整尺寸；已经有表格，只需要按规则去重并导出。输入在手里，处理规则清楚，结果拿走就结束，这类需求值得先问一句：能不能只在本机完成？

如果需要的能力依赖外部系统，情况就不同了。

几个人要共同编辑同一份数据，需要某种共享和同步机制；工具要读取一个网站的实时数据，需要能访问对应的数据源；要调用某家厂商的云端模型，自然需要连到它的服务。这里不一定都得自己租一台服务器，但不能把远程服务这一层假装省掉。

还有一种常见情况：功能能在本地做，但当前设备不适合做。

宝玉在 8 月 24 日的 BaoCut 开发复盘里，讲过一个真实需求：用户有两台电脑，希望在办公电脑上操作，让算力更强的另一台电脑负责转录。

这提供了另一个思路。计算位置不只有“当前网页”和“买云服务”两个选项，也可以是本机桌面程序，或者自己控制的另一台电脑。选哪种，要看算力、使用频率和连接成本。

不要为了省服务器，把所有重任务硬塞给手机；也不要因为要做个网页，就先给自己配一套云端系统。

一个工具可以不上传你的文件，却仍然需要联网下载程序、字体或处理引擎。

如果第一次打开时没有把这些资源准备好，断网后就可能用不了。即使某次断网还能继续处理，也只能说明当时需要的资源已经在手上，不能顺便证明它在所有情况下都不会外发数据。

如果离线可用是硬需求，就把这件事单独写进需求。比如：安装或首次加载完成后，关闭页面、断开网络，再重新打开，是否还能完成核心任务？更新资源时又怎么处理？

MDN 的离线网页教程介绍了用 Service Worker 缓存所需资源的方法。但这是额外设计出来的能力，不是“写成 HTML”就自动获得的能力。

同样，页面卡住也不一定要靠搬上云解决。Web Worker可以把耗时计算放到后台线程，减少对界面操作的干扰。它不会让弱设备突然变强，却可能让处理期间的进度显示、取消按钮保持可用。

对使用者来说，这些差别最后会落到很具体的体验上：能不能看到进度，能不能中止，失败后能不能重新选文件，原文件会不会被覆盖。

不用先背熟这些技术名词。可以在开始开发前，把问题说得更具体一点：

这个工具主要由我自己使用。先判断核心功能能不能完全在本机完成，不要默认接云端 AI、数据库或文件上传服务。请说明哪些计算在本地，哪些功能必须联网，预计会遇到什么文件大小、性能和浏览器限制。先给方案，不注册服务、不购买资源。

方案确定后，再用不含隐私的样本验证。除了看“能不能出结果”，还要检查结果有没有漏内容，文件能否正常打开，较大的样本是否会卡死，失败提示是否说清原因。

如果要求文件不外发，还需要核对实际网络请求和相关代码。仅仅把网络断掉试一次，不足以代替这项检查。

对于多数个人小工具，先确定处理范围、守住原文件、把结果导出来，比一开始就补齐账号系统和后台管理更有用。以后真有多人协作或远程算力需求，再增加对应部分。

跟着做一个 · LOCAL / BROWSER TOOLS