ARTICLE · 1239770
把小工具做成一个文件,像发 PDF 一样发出去
把小工具做成一个文件，像发 PDF 一样发出去
做个小工具最大的摩擦不在写代码，在于怎么交给别人用：要么租台服务器部署上线，要么让对方装客户端再配连接地址。Capsule 把这个环节压成了一步——工具连同它的数据被打进一个 .capsule 文件，通过微信、AirDrop 或邮件发出去，对方双击打开就能用，不需要服务器、不需要注册账号，数据留在他自己的机器上。
一个 .capsule 文件里装的是三样东西：界面（标准 HTML/CSS/JS 写的）、素材资源，以及一个内嵌的 SQLite 数据库。所以你能做的工具范围很具体——清单、计算器、客户追踪、课程表、食谱、展品目录这类「有输入有记录、但不需要联网协作」的东西。
Capsule 官网对单文件应用形态的图示，官网 withcapsule.app
👉 滑动
👉 滑动看它的四条设计取舍
01
界面 + 素材 + SQLite 数据都在同一个 .capsule 里。
02
代码跑在隔离 webview，配严格 CSP，读不到本地文件、发不出静默请求。
03
数据是标准 SQLite 表，任何 SQLite 工具都能查、能导。
04
每条数据带 UUID 和时间戳，副本分歧时用内置三路合并。
01
PART
装：桌面客户端或直接用网页版
去 withcapsule.app 下载对应平台的客户端（macOS 的 dmg、Windows、Linux 都有），不想装就直接用它网页版打开同一批文件。做工具有三条路：在应用里用描述让它的 Agent 生成、从模板起步、或者自己写标准 HTML/CSS/JS。想用 ChatGPT、Claude、Gemini 来写，把官网那份 prompt.txt 的说明喂给模型即可。做完得到一个 .capsule，发出去对方双击运行。
02
PART
原理：把「部署」换成「文件」，代价在协作
它真正解决的问题是把部署这个环节删掉。常规做法里，工具和数据分居两地——代码在服务器上，数据在数据库里，于是你必须一直养着那台服务器。Capsule 把两者焊在一起，于是「分发」退化成了「传文件」，而「运行」退化成了「双击」。
代价也随之而来，而且它很值得提前想清楚。文件一旦被复制就分叉了：A 改了自己那份、B 改了自己那份，两边都以为自己拿着最新的。项目方给的答案是机制层面的——每条数据带 UUID 和时间戳，写入按原子事务提交，所以丢进 Dropbox、iCloud、OneDrive 同步不会出现半个文件；副本真分歧了就上内置的三路合并。这能让「两份都改过」不至于变成事故，但冲突善后和实时协作是两件事，中间差着一整个架构决策。
安全边界它标得算清楚：文档代码跑在隔离 webview 里并配严格 CSP，读不到你的本地文件系统，也发不出静默请求；数据是标准 SQLite 表，你可以拿任意 SQLite 工具打开看。绕不过去的是信任成本——HN 上有位叫 dzink 的用户反馈，Mac 版下载后系统提示「Capsule 已损坏，应推出磁盘映像」，同时点出这种容器同样适合塞恶意载荷。任何「收到文件双击就跑」的形态都会长期背着这个包袱，这是形态本身的代价，不是哪一家的 bug。
03
PART
用：谁最该用，谁现在别碰
最该用的是这种场景：你要把一个小工具交给不会装软件的人——比如把记账表发给家人、把展品目录发给客户——对方只需要有 Capsule，点开就用，数据还留在自己机器上。第二类是对数据位置敏感的人：文件在你手里，不在某家服务器上。
现在别碰的情形也很明确：需要多人同时编辑同一份数据的（上面的分叉问题还没被真正解决）；只想要手机端体验的——移动端标着「即将支持」，你在微信里发个 .capsule 到对方手机，他打不开；以及必须审计客户端源码的团队，因为客户端是闭源的，开放的只是文件格式。
04
PART
代价与对比：它和单文件老玩法
把三个摆一起能看清一件事：单文件不是新技术，是被云默认挤到边缘的老技术，现在被「不想维护服务器」这个需求重新捞了回来。Capsule 的新变量只有一个——它能用 AI 生成和迭代应用，这让「做一个工具」的门槛降到了「描述一遍需求」。
一句话判断：判断你要不要用它，只需回答一个问题——这个工具的数据，是只有你一个人改，还是会有人和你同时改？前者它很合适，后者再等它把协作补上。
官网 withcapsule.app，HN 上那篇发布帖里 166 条讨论值得翻一遍，场外质疑比功能列表有用。
有什么想法可以随时留言沟通！
喜欢就先收藏，万一找不到了呢！⭐
