Chrome 的 window.showDirectoryPicker() 有个很反常的地方：网页不再只能等你上传文件，也可以在你主动授权后，读写一个本地文件夹。
开发者 Steve Harrison 最近用 Claude 做了两个原型。一个是本地照片管理器，可以浏览图片、建文件夹、移动照片；另一个是受 Apple Shake 启发的节点式合成工具，可以在源图上画多边形并做简单合成。
我更在意的不是“Claude 几轮提示复刻了 Lightroom、Aperture 或 Shake”。那说过头了。
真正有意思的是：浏览器正在靠近一种新形态——界面在网页里，文件还在用户自己的硬盘目录里。用现在常见的说法，就是 local-first。
这个 API 改的是文件关系，不是安全边界
showDirectoryPicker() 属于 File System Access API 这一类能力。它的关键动作很简单：用户在浏览器里主动选择一个目录，网页才拿到这个目录的访问权限。
这不是网页可以绕过授权扫你的硬盘。
权限入口仍在用户手里。网站能碰到的，也只是被授权的目录。对普通用户来说，实际动作也很清楚：只给项目文件夹、素材文件夹、笔记文件夹授权，不要把整个用户主目录随手交出去。
过去网页处理本地文件，常见做法是上传、拖拽单个文件，或者把数据塞进浏览器自己的存储里。目录级授权的变化在于，它更贴近真实工作流。
Markdown 笔记是一类典型例子。很多人本来就按文件夹放 .md 文件，换编辑器也能打开。照片、视频素材、合成工程也是同一逻辑：文件天然按目录管理，没必要默认进云端。
| 场景 | 旧做法 | 目录访问后的变化 | 现实限制 |
|---|---|---|---|
| 本地 Markdown 笔记 | 上传、同步，或放进浏览器沙盒 | 网页编辑器可直接读写本地笔记目录 | 目录权限、离线体验、浏览器支持要处理好 |
| 照片管理器 | 桌面软件导入图库 | 网页 UI 可整理本地照片文件夹 | 预览、元数据、缓存、批量操作仍要工程打磨 |
| 视频编辑 / 合成工具 | 依赖本地专业软件 | 可和 WebGPU、浏览器编辑器组合 | 大文件、稳定性、插件生态、色彩链路难度高 |
这里要压住一个判断：它打开的是门，不是拆掉了墙。
目前不能把它写成所有浏览器都完整支持。更稳妥的看法是：如果目标用户主要在 Chrome 或 Chromium 生态里，这条路线值得试；如果你要覆盖 Safari、Firefox 或企业里复杂的浏览器环境，就不能把它当成唯一底座。
最适合先动的，是本地优先的轻量创作工具
这类 API 对谁最有用？不是所有软件。
更直接受影响的，是 Web 开发者、小团队工具作者，以及做内部创作流程的人。他们过去想做一个本地优先的照片整理器、素材管理器或 Markdown 编辑器，常常要选 Electron、Tauri，或者写原生客户端。
现在，如果用户群足够 Chrome-first，纯网页方案开始值得进入原型阶段。
这会改变一些很具体的选择：
- 个人开发者可以先做网页原型，不急着打包桌面客户端。
- 小团队如果只服务内部 Chrome 环境，可以把素材管理、标注、轻量剪辑工具先放到网页里试。
- 要卖给广泛用户的软件，仍不该轻易放弃 Electron、Tauri 或原生方案。
原因不复杂。网页分发轻，打开 URL 就能用，更新也快。Electron 和原生客户端则在系统能力、跨浏览器一致性、后台任务、文件关联、稳定性上更强。
这不是路线鄙视链，而是成本表。
| 路线 | 适合谁 | 好处 | 代价 |
|---|---|---|---|
纯网页 + showDirectoryPicker() | Chrome-first 的内部工具、原型、小团队产品 | 分发轻，迭代快，数据可留在本地目录 | 浏览器兼容受限，权限体验要解释清楚 |
| Electron / Tauri | 需要桌面体验的跨平台工具 | 系统能力更深，可控性更强 | 安装、更新、资源占用和发布成本更高 |
| 原生客户端 | 高负载专业创作软件 | 性能、稳定性、系统集成更可控 | 开发成本高，跨平台压力大 |
照片、视频编辑、节点合成被拿来讨论，并不偶然。
这几类工具都有同一个矛盾：素材很大，用户未必愿意上传；界面又很复杂，网页前端已经能做出不错的交互。再加上 WebGPU 这类浏览器端计算和渲染能力，文件访问和图形能力开始凑到一张桌上。
但凑到一张桌上，不等于已经能上席。
机会卡在产品化，不卡在演示视频
Harrison 的两个原型由 Claude 生成，这件事也重要。它说明 AI 编程把原型门槛压低了：一个人可以很快试出“网页 + 本地目录”的交互形态。
但原型不是生产级软件。
成熟照片管理器要处理 RAW、色彩管理、缩略图缓存、EXIF、批量操作、崩溃恢复。成熟合成工具要处理节点图复杂度、实时预览、工程文件、插件生态和长时间稳定运行。
这些问题不是一句“AI 会写代码”就能抹平。
接下来最该看三件事，每一件都很硬：
- Chrome 之外的浏览器是否跟进跟进到什么程度。
- 用户是否愿意给网页目录级权限产品能不能把风险讲明白。
- WebGPU、离线缓存、本地文件访问能否组成稳定链路而不是各自好看。
如果这三件事只成一件，它更像技术演示。如果能扣上两三件，部分轻量创作工具就会开始变形：从“下载安装一个软件”，变成“打开网页，文件还在本地”。
对开发者来说，眼下更现实的动作不是迁移全部产品，而是挑一个低风险模块试水。比如 Markdown 笔记、素材整理、图片筛选、内部标注工具。
对创作工具用户来说，也不用急着换阵地。更合理的态度是观望，但知道一个新选项已经出现：以后有些工具不必在“云端 SaaS”和“厚重桌面软件”之间二选一。
开头那道门缝，真正通向的不是浏览器接管硬盘，而是网页软件重新学会尊重本地文件系统。
这件事的分量就在这里。