不上传文件还不够：本地 AI 工具的三层隐私防线

很多本地 AI 工具都会把“文件不上传”写在首页，但如果只停在这句口号，用户仍然很难判断数据是否真的留在设备上。对处理合同、课件、演示文稿等敏感资料的工具体验来说，隐私不是一种界面文案，而是一套可以从数据流、依赖边界和复现实验三个层面验证的工程约束。

以浏览器端的 PPTX 对比工具为例：用户拖入新旧两版文件，页面读取内容、解析 OOXML，最后展示画布尺寸、页数和文本差异。最容易想到的实现，是把文件交给服务端处理；而真正坚持本地处理，则需要让输入、解析和展示全部发生在当前标签页内。

第一层防线是数据流最小化。文件通过 File API 读入内存后，直接转换成 ArrayBuffer，再交给 JSZip 解压。整个过程不调用上传接口，不把文件切片发送到第三方，也不把原始内容写入 localStorage、IndexedDB 或日志。核心代码可以简单到只有几行：

const buffer = await file.arrayBuffer();
const zip = await JSZip.loadAsync(buffer);

这并不意味着只要出现这几行代码就安全。还需要检查网络面板：用户选择文件后，页面有没有发出额外的请求？错误上报是否携带文件名和文本片段？预览图片是否被临时上传？这些细节往往比“是否有一个上传按钮”更接近真实的数据边界。

第二层防线是依赖边界。即使业务文件没有上传，页面加载的第三方脚本仍可能看到 DOM、读取内存或发起网络请求。因此，涉及敏感文件的工具应尽量自托管 JSZip 等依赖，为外部资源添加完整性校验，并通过 CSP 限制连接目标。例如可以把 `connect-src` 收紧到本站，把不需要的远程访问直接关掉。对个人工具来说，还可以在页面加载完成后断开网络，再次执行一次完整比对；如果结果不变，说明核心流程不依赖远端服务。

第三层防线是可验证性。隐私承诺必须能被普通开发者检查，而不是只靠信任。一个可交付的本地工具至少应做到：源码公开、依赖清晰、没有隐藏的上传域名；README 明确列出数据处理流程和已知限制；提供可重复的测试文件；在浏览器开发者工具中可以看到“选择文件后没有上传请求”。如果产品承诺“文件不离开设备”，那么即使服务端发生异常，核心功能也不应该受影响。

还需要承认边界：浏览器会缓存页面资源，操作系统可能生成临时文件，截屏和剪贴板也不等于零风险。因此更准确的说法不是“绝对安全”，而是“在明确威胁模型下，应用不主动持久化或外传用户文件”。这种诚实比夸张承诺更可信。

我在实现一个纯前端 PPTX 对比工具时，最终把验收标准压缩成四句话：文件只在当前页面解析；业务代码不调用上传接口；依赖和网络目标可审计；断网后核心比对仍可完成。这样做并不会让架构变得复杂，反而减少后端、存储和权限管理带来的攻击面。

对本地 AI 工具而言，“不上传文件”应是起点而不是终点。把数据流收紧，把依赖边界讲清，把隐私承诺变成可复现的验证步骤，用户才能真正知道自己的资料为什么安全，以及安全到什么程度。