副项目开源三个月，GitHub 上 1.2k star，被 40 多个项目引用，issue 区保持着"三天内必回"的节奏。这篇文章复盘一个独立开发者运营开源副项目的完整过程——从 README 的第一版，到第一批十个真实用户是怎么来的，以及那些"早知道就好了"的运营真相。
先想清楚：你开源的是代码，运营的是预期
开源副项目最常见的死法不是代码烂，是预期失控：作者以为"先做个简单的"，用户以为"这玩意能上生产"，两边对着一个半成品互相失望。所以动笔写 README 之前，先回答三个问题：
- 这个项目替谁解决什么问题：一句话能说清，说不清就是需求没想好；
- 生产可用还是玩具：在 README 顶部用一行文字明示，不丢人，藏着才丢人；
- 你准备投入多少：业余维护就写清楚响应时效，别让用户以为有 SLA。
我们的项目是评论系统后端——对，就是博客在用的那套。README 第一行就写："A comment backend built on Cloudflare Workers + D1. Production-ready for personal blogs, self-host friendly."生产可用，但场景限定在个人博客。这个限定后来帮我们挡掉了至少一半"能不能用在电商详情页"类需求。
README 是项目的第一张脸
README 改过四版，转化率变化很明显。最终稳定的结构：
- 一句话定位加三个 badge（license、Cloudflare Workers、version）：五秒内让人知道是什么、什么状态；
- Demo 或截图：评论区组件的一张 GIF，比五百字描述都管用；
- 五分钟上手指南：clone 到跑起来不超过五条命令，我们的实测是 4 条；
- 配置表：每个环境变量一行，默认值、是否必填；
- 架构一段话加目录树：让人十秒内建立代码地图；
- Roadmap：明确近期做什么、不做什么，管理预期比隐藏预期体面得多。
有个反直觉的数据：README 从"技术说明书"风格改成"快速上手"风格后，clone 到首次成功部署的比例从大约 15% 涨到 40% 以上。用户不会读你的架构设计，他们只想尽快看到东西跑起来。
第一批真实用户：不靠运气，靠定向
"把项目发到网上然后等人来"是最低效的路径。我们第一批 40 多个引用项目的来源，复盘下来有四条，按效果排序：
| 渠道 | 动作 | 效果 |
|---|---|---|
| V2EX 分享节点 | 一篇"为什么我自己写了套评论系统"的复盘帖，带真实数据 | 当天 300+ star，但留存一般 |
| GitHub 定向回复 | 搜索"评论系统推荐"类 issue 和 discussion，认真对比后提及自己的项目 | 转化最高，来的都是精准用户 |
| 技术社群深度文 | 把踩坑写成文章（Turnstile 灰度、D1 索引那些） | 长尾，持续带量 |
| awesome 列表 PR | 向相关 awesome-selfhosted 列表提交条目 | 一次提交，长期被动流量 |
最有效的第二条值得展开：不要到处发链接，而是找到"正在寻找解决方案的人"。他们已经在问"有没有自建评论系统推荐"了，你的项目正好能答——这时候出现，是解题，不是广告。第一批十个真实用户里，有六个来自这种定向回复，他们后来贡献了大部分早期 issue 和两个 PR。
用户来了之后：issue、PR 与范围控制
有了用户，维护就不再是纯技术问题。我们的三条运营纪律：
- issue 分级响应：崩溃、安全类当天回，功能请求进 Roadmap 讨论，使用问题引导到 Discussions。响应速度比解决速度更影响观感；
- PR 三问：这个改动服务的是核心场景吗？作者会长期维护吗？能写测试吗？三个都 yes 才合，否则礼貌拒绝——合一个没人维护的 PR，等于给自己埋雷；
- 范围写进 Roadmap：被请求最多的三个功能，如果不在路线图上，就明确写"暂不支持"，比含糊其辞省掉 80% 的反复追问。
踩过最大的坑是"好心合 PR"：一个用户提交了 Markdown 编辑器增强，代码能跑但引入了两个新依赖，两个月后他不再维护，CI 挂了一次，最后是我花了三小时回滚。从那以后 PR 三问一条没松过。
还有一个早期没重视、后来补上的东西：LICENSE。第一版随手选了 MIT，被评论"你这是鼓励别人闭源收割"——技术社区对许可证的敏感度比想象中高。我们最终维持 MIT，理由写进了 README：个人博客场景下，限制商用对项目传播的伤害大于收益。这个选择不一定对，但"想清楚并写下来"本身比选什么更重要。
Release 时的 changelog 也是运营的一部分。我们的规矩是每个版本在 GitHub Releases 里写清 Added、Fixed、Breaking 三段，Breaking 置顶加粗。三个月下来，issue 区重复提问明显减少——很多"怎么配"的问题，答案其实就在 changelog 里，只是以前没人知道去看。
三个月的数据切片
| 指标 | 数值 |
|---|---|
| star | 1.2k（约 30% 来自 V2EX 首帖，后续靠长尾） |
| 被引用项目 | 43 个（GitHub dependents 口径） |
| 真实部署 | 约 20 个（从 issue 区自报和遥测插件估的） |
| issue 关闭率 / 平均响应 | 91% / 1.8 天 |
| 外部 PR 合并 | 5 个，全部通过三问 |
注意 star 与真实部署的比例：1.2k star 对应约 20 个部署，转化率不到 2%。这是开源项目的常态——star 是关注度不是使用量，别用 star 数自我感动，issue 区才藏着真实需求。
结论
独立开发者运营开源副项目，技术只占一半，另一半是预期管理：README 管理能力预期，Roadmap 管理路线预期，issue 响应管理维护预期。第一批用户不来自流量运气，来自定向地出现在"正在找答案的人"面前。而最后也是最重要的一条：开源是放大器，不是起点——项目本身先在自用场景里活下来，再谈开源。顺序反了，大概率是开一个没人用的仓库，给自己上一课。