把好项目搬上免费层：我的 Serverless 转写方法论

这个专栏的前四篇写了两个具体项目。这篇把它们背后共用的一套判断抽出来：把一个已经被验证过的自托管软件，转写成跑在免费 Serverless / 边缘平台上的版本。这件事正在成为我做开源的主要方法，值得单独交代清楚。

第一步：只搬已经被验证过的需求

转写不发明需求。入选的项目必须先满足：原项目本身受欢迎、有真实用户、解决的问题被反复提出。PrivateBin 做了多年的零知识粘贴板，微信自托管推送有成排的 fork 在求部署——需求是现成的，缺的是部署形态。

反过来，凡是核心价值依赖与大型平台长期对抗（反爬、风控、封号拉锯）的项目，再热门也不碰。转写的全部优势建立在「低维护」上，需要持续攻防的项目与这个前提根本冲突。

第二步：把免费额度原文当设计稿读

免费层不是营销话术，是硬约束，而且写在各平台的官方文档里：每天多少次请求、多少行写入、单值多大、传播延迟多少秒。转写设计的第一步，是把目标平台的额度与限制原文逐条读完，用它们反推架构：

• Binflare 选 D1 做主存储，是因为 KV 的免费写入额度差了两个数量级，且约 60 秒的全球传播延迟会击穿「阅后即焚」的语义；
• pusher 选 EdgeOne，是因为它的函数与 KV 形态刚好装得下「webhook 进、推送出」的无状态流程。

先读约束，再画架构，顺序反过来就会在实现期被平台细节反复打脸。

第三步：协议兼容优于另起炉灶

转写时最诱人的错误，是「顺手重新设计一版更好用的」。抵抗它。存量项目积累的客户端、插件、用户习惯和文档，都是现成的分发资产；与原协议兼容，意味着这些资产零成本迁移到你的版本上。Binflare 与 PrivateBin 2.x 逐项对齐数据格式与接口，换来的正是这一点：用户换地址，不换工具。

另起炉灶的版本即使更好用，也要从零教育市场——对独立开发者来说，那是最贵的一种成本。

第四步：一键部署是产品的一部分，不是文档的一部分

「自己部署」这四个字劝退了大多数潜在用户。转写版的核心交付物之一，就是把部署压成一次点击：部署按钮、自动建库、部署后自检页面（比如 Binflare 的 /setup），都要算作产品功能来开发和测试。部署过程中踩到的平台权限边界——比如受限令牌建不了表——要在产品内用架构手段绕过去（首次请求自动初始化），而不是写进 README 让用户自己解决。

一条贯穿始终的分界线

限制只属于部署，不属于产品。 防滥用的频率限制、内容上限、防护开关，都是部署者的现场选择，做成部署期配置；产品本体保持上游的完整行为与缺省值。公共演示实例可以收紧，自部署实例不该被作者的手伸进去管。这条线保证了转写版的「正统性」：它始终是原软件的一个部署形态，而不是阉割版。

接下来

这套方法会继续用在新的候选项目上，评估过程与结论也会陆续写进这个专栏——包括那些被否决的。否决记录和立项记录一样重要：它们标记了这条方法论的边界在哪里。