小工具从想法到上线：一次副业项目的完整复盘

去年我利用晚上和周末的时间，做了一个给开发者用的小工具，从有想法到真正有人稳定使用，前后折腾了几个月。中间走的弯路比顺路多，但整个过程对”一个东西怎样才算做完了”的理解，比之前几年上班攒的经验都深。这篇按时间线复盘，写法上偏个人经验，不指向任何具体产品，只讲那些可以复用的判断和动作。

一、需求从哪来：解决自己的问题

最初的念头很小。我日常经常要做一类重复操作，比如批量处理一批文件：重命名、转格式、按规则归档。现有办法要么是每次手写一次性脚本，要么是大而全的工具但配置繁琐。我想：这类需求月月遇到，做个顺手的脚本集总行吧？

这一步有个关键心得：做给自己用，是副业项目最可靠的起点。需求真不真不用调研，痛点深浅自己知道，验收标准就是”我自己愿不愿意继续用”。很多副业项目死在第一步，就是因为做的是”我觉得别人会需要”的东西——没有渠道验证之前，这基本等于猜。

需求收敛时我逼自己回答了三个问题：

1. 这个问题我多久遇到一次？频率低到一年一次的，不值得做成工具。
2. 现有方案到底卡在哪里？是找不到，还是找到了但难用，还是根本不存在？这决定我的机会有多大。
3. 如果做出来只解决我自己的问题，我还愿意花时间维护吗？愿意，说明这是个好起点；不愿意，说明我在指望别人的需求激励自己，那多半撑不下去。

三个问题过完，我砍掉了最初想法里一半的内容——那些是”顺便也支持一下”的部分，砍掉之后剩下的核心是一个非常具体、我自己每周都会用到的场景。

二、MVP 划多大：小到可以周末做完

确定核心场景后，我给自己定了个原则：第一版必须小到可以在几个周末内做完，且做完之后我自己会用第二次。

MVP 的边界我用排除法划：不做图形界面、不做配置文件、不做批量并发、不做错误恢复，只做一条命令行能跑通的主路径。输入是一种最常见的情况，输出是一种最常见的情况，其他情况报错退出。

这个范围小得可怜，但有个巨大优点：完成度百分之百。做完那周我就拿它处理了一次真实文件，跑通后的成就感把项目推进到了下一个月。

常见的死法是 MVP 定大了：第一版就想做界面、多格式、云端同步，三个月过去还在搭架子，热情耗尽。宁可第一版寒酸，也要让它”能被用”——被用过的东西才有迭代方向。

三、技术选型：按维护成本倒推

选型这块我纠结过一阵，最后的决策框架不是”哪个技术先进”，而是”三年后我还会维护它吗”。副业项目最大的敌人是维护成本，选型要为这个让路。

我考虑过三种形态：

对我的场景，最终选了脚本为主的路线，外加一层极薄的命令行入口。理由是我判断真实用户主要是开发者（跟我自己一样），命令行可接受；而桌面端的打包签名、服务端的运维值班，都不是我一个业余时间能扛的。这里没有标准答案，关键是想清楚成本落在谁头上、落在什么时间——桌面端的成本在每一个发布周期，服务端的成本在每一个深夜告警。

语言上我用了最熟的那个，没追新。副业项目的产出是工具本身，不是技术展示。

四、打包、分发与版本号

第一次”发布”的狼狈我印象很深：同事想用，我直接把脚本目录打包发过去，对方环境里缺依赖、路径不对、编码报错，来回折腾了一个多小时。这件事让我意识到分发是产品的一部分。

之后我补了三件事：

安装的最短路径。一条命令能装上，装完能直接跑，安装卡住是用户流失最快的地方。

语义化版本号。从 0.1.0 开始，主版本号变表示不兼容改动。版本号是与用户沟通的最小语言：”你哪个版本”能立刻收窄排查范围。宁可小版本多发几次，不攒大版本。

变更记录。每个版本写三五行改了什么，它还逼我在收尾时想清楚”这个版本到底交付了什么”。

五、用户反馈渠道：别高估沟通量

我一开始担心没人用，后来发现更常见的是有人用但不吱声。沉默的用户占绝大多数，愿意提有信息量反馈的更少。

我把反馈门槛降到接近零：工具里加一句”遇到问题把这条命令的输出发我”，仓库开着 issue，另留一个邮箱作反馈入口。三条通道各有用途：issue 适合可追踪的问题，邮箱适合不愿公开的人，工具内提示适合懒得找渠道的人。

收到反馈后有个原则我踩过坑才学会：不要立刻照单全收。第一个用户提的需求往往是他的特例，照做会把工具做成”为一个人定制”。先追问”背后的场景是什么”，通用需求进主线，特例劝他自己加个脚本。

六、维护成本控制：设一个”维护预算”

项目有人用之后，维护就开始消耗时间：修 bug、回答问题、适配新环境。副业项目有个危险信号是维护时间悄悄超过开发时间，热情被例行公事磨光。

我设了个粗糙的预算：每周给这个项目的时间不超过一个晚上。超出预算的需求一律进待办列表，不承诺时间。听起来冷漠，但它是项目能活下来的前提——无限承诺的副业项目死得最快，死了对谁都没好处。

另一个控成本的动作是自动化琐事：测试补到主路径全覆盖，改坏了本地立刻发现；issue 模板先收齐版本、系统、复现步骤，来回追问少一半。

七、什么情况下该停

这是最不愿意写但最重要的一节。副业项目需要一条”停”的判据，否则会变成无限拖延的半成品。

我的判据三条，满足任意一条就认真考虑停：

1. 连续两个月我自己一次都没用过。自己都不用的东西，没有存在的地基。
2. 维护成本持续超过它带来的时间节省。工具的意义是省时间，倒贴就本末倒置了。
3. 核心问题被更好的通用方案解决了。生态在演进，官方工具、大厂工具某天覆盖了我的场景，体面地归档就是最好的结局。

真到停的时候，把仓库归档、README 里写清楚”为什么不继续了、后来者可以看哪里”，不要直接删库。停止更新不等于失败——它是一次有明确结论的实验。我那个项目目前还在半活跃状态，但上面三条判据我写在 README 的开头，提醒自己随时可以诚实地下结论。

复盘整个过程，最大的感受是：把一个小东西从想法做到有人用，锻炼的是完整闭环——需求、范围、实现、分发、反馈、维护、终结。上班时我们多数人只负责这个闭环中的一两段，而闭环的每一环都有自己的手艺。哪怕项目最后停了，这些手艺是带得走的。