维护项目的快感，让我忘了做产品

国庆假期，本来打算把量化项目往前推一推。结果打开 GitHub：

hancic-blog：6 个 commit，3 个是「更新 CHANGELOG」「调整 lint 配置」「修正一处 import 顺序」。

zhiwei：8 个 commit，全是「重构告警去重逻辑」「拆分公共模块」「把一段 prompt 抽成可复用组件」。

bluebird：5 个 commit，两个 fix typo，一个把 README 重写了一遍。

19 个 commit。假期过半，量化项目一动没动。

我没刻意把「GitHub 活跃」当成「做产品」，但不知不觉就是这样做的——问题出在工程师的洁癖：见一处 lint 警告想顺手修，见一处重复想抽公共模块，见 CI 配置不优雅想重写一遍。

老话叫「将军赶路，不追小兔」——本来要赶的路是量化项目，路边每只小兔（lint、重复、CI 不优雅）都忍不住想追一下。假期过半，军没赶、兔没抓到，量化项目一动没动。

但追兔这件事单拿出来都挺爽：

• 调 eslint 规则：20 分钟，写完立刻能 commit、push，立刻看到绿对勾
• 抽一个公共模块：2 小时，写完感觉"代码优雅不少"，PR 上去被 merge，得到一句 LGTM
• 把一段 prompt / workflow 抽成可复用模块：1 小时，写完读着顺，自己看着都舒服
• 改 README：1 小时，写完自己读着顺

每一件事都是真的在做，写出来也不算糊弄。但合在一起，它们回答的问题不是"用户被解决了吗"，而是"我自己爽了吗"。

这是两种工作，长得一模一样，但反馈周期差了不止一个量级。

我想了一段时间才敢承认这件事：

真正有价值的工作和反馈速度是反相关的。

• 调一个 lint 规则、改一行 README：秒级反馈，长期价值几乎为零
• 抽公共模块、写开发规范：分钟到小时级反馈，长期有价值但经常过度
• 真正触及"这个产品到底解决谁的什么问题"的设计决策：周到月级反馈，长期价值最大
• 让一个项目被真正用起来：甚至不知道反馈什么时候来

反馈越快的事，门槛越低，越容易做——代价是：做着做着，你会以为自己一直在做事。

工程师尤其容易陷进去，因为我们训练出来的本能就是"把事情做对、做规范、做漂亮"。这套训练在团队协作里很有用，搬到 side project 上就成了慢性自杀——永远在打磨工具，永远不上主菜。

我说这些的时候，已经在骗自己。

我太清楚这条规律了。看别人"明明在维护、却没产品"我能一眼看出来；轮到自己，每次"今天没写新模块，但是抽了个公共组件、改了 lint、写了个 README"——心里就想：今天也没闲着嘛。

而且这类工作有个特别坏的特点：它给我的感觉太好了——好到我做完一次，会主动再去找下一次。 一次 PR 被合并，胜过一个月用户增长；一个重构被自己 review 通过，胜过一轮产品上线。这些回报是实打实的、立等可取。相比之下，"让产品被真正用起来"要承担的不确定性、孤独感、被忽视的可能，都太重了。

所以我现在能做的诚实只有一件事：承认我看见这条规律，但还没准备好为"慢反馈"支付代价。 我依然会花很多时间在边角料上——但至少现在我知道自己在干什么了。

我不想给方案——"少做边角料、多做产品"这种话连自己都骗不过。

我只想承认三件事：

我在维护，不是在做产品。 维护让我爽，但维护不等于做产品。 这件事我之前一直在混着用，今天才把它分开。