# 一个人开发最容易浪费时间的地方是什么？

URL: https://caijiao.org/posts/127
Source: docs/posts/127.md
Description: Cakedesk 2025 年收到 44 个功能请求只完成 13 个，那 31 个就是答案。最贵的黑洞是在没被验证的页面上做精细活，10015.io 用"50 个工具才发文"的硬门槛挡住这类投入，真正该多花时间的只有确认入口这一件事。

Max Schmitt 2025 年在 Cakedesk 上发了 12 个版本，收到 44 个功能请求，完成 13 个。

44 比 13。那 31 个请求不是被拒绝的——它们被讨论过、想过、很可能还开工过一部分。这个比例大概就是一个人做产品时，时间流向的真实写照。

浪费不在"摸鱼"上。一个人给自己干活，偷懒的机会其实不多。浪费都发生在看起来很正当的事情上。

## 第一个黑洞：在没被验证的页面上做精细活

最常见的一种，是把一个还没确认有人会来的页面，打磨到像素级。

工具站尤其容易掉进去：每个工具页面都不复杂，随手就能做得更"完整"一点——加个历史记录、加个批量模式、加个结果导出。单个动作都不大，加起来能把三周吃掉。

问题在于这些投入的回报是随机的。页面本身可能压根没有流量，或者有了流量但用户根本不需要那些附加功能。做之前无法判断，做之后才知道，而那时候时间已经花掉了。

挡住它的办法不是靠自制力，是靠顺序：**先让页面被索引、跑上一个月拿到真实查询词，再决定给它加什么。** [在线工具](/tool/)集合站的价值来自页面数量，不来自某个页面有多精致。

## 第二个黑洞：把"可以加"当成"应该加"

功能请求是最有迷惑性的时间黑洞，因为它带着"用户想要"的正当性。

Cakedesk 那 31 个没完成的请求，我猜大部分不是做不了，是做了之后只有一个人受益。一个人做产品时，单个请求的权重必须被反复质疑——它不是需求调研的结果，它是一个人的一次表达。

10015.io 的处理方式值得学：它把"什么时候做什么"写成了硬门槛——50 个工具才开始写文章发社媒，64 个才上 Product Hunt，128 个才做 v2，256 个才做 v3。

![10015.io 官网首页截图](/images/2026-09/10015.io.png)

*10015.io 首页没有价格入口，整页只讲一件事：把书签栏里那堆工具链接收进一个盒子。*

这条路线图的作用不是规划，是**拒绝**。在门槛没到之前，所有"要不要现在做个 v2""要不要先发个帖试试"的念头都有一个现成的答案：不到 50 个，不做。省下来的不是时间，是反复决策的精力。

## 第三个黑洞：重做已经能跑的东西

重构是独立开发者的经典自毁方式。没有产品经理催你、没有技术债评审，重构的启动成本极低——看自己的旧代码不顺眼，就动手了。

10015.io 把 v2 推到 128 个工具之后，说明它也遇到过这个诱惑，然后用硬门槛压住了。在 128 个工具之前，架构上的不优雅是允许存在的，因为此时真正决定成败的是页面数量和入口质量。

判断标准可以是：这次重构，能不能让新增一个页面的成本下降？能，就做；只是让代码更好看，就往后排。

## 第四个黑洞：在渠道上反复试错

Cakedesk 2025 年的另一组数据值得单独看：**2024 年有效的付费渠道，2025 年失效了**，缺口靠 Google 自然流量补上。同时它的流量持平，销量却在涨——2024 年约 170 份，2025 年 239 份新授权。

一年时间在渠道上试错、再换渠道，这部分投入几乎不沉淀。

Product Hunt 那组数字也是同一类提醒：每天约 668 次发布，feature 率约 2.8%。首发是一次性资源，用在准备不足的时机上就没有第二次。10015.io 要等到 64 个工具才上，不是保守。

## 第五个黑洞：为"以后可能要"提前设计

这条和重构很像，但更隐蔽，因为它发生在写代码之前。

具体形态是：还没第二个用户，就开始设计多语言架构；还没有数据，就开始分库分表；还没有付费用户，就开始搭订阅系统。每一个都带着"以后改会很麻烦"的理由，而这个理由在多数项目里从没兑现过。

判断方法只有一句：这个设计能不能让"新增一个页面"变快？能，就做；不能，就是提前支付。10015.io 在 50 个工具之前连设计系统都没建，它把 v2 推到了 128 个之后。

## 唯一值得多花的：确认入口

把上面四类压掉之后，时间该花在哪儿？我的答案只有一个：确认用户从哪儿进来。

具体动作很机械——接入 Search Console 看实际查询词，检查 sitemap 有没有覆盖全部页面，确认结构化数据的字段是对的。这些工作没有创造性，但每一项都直接决定前三类投入有没有回报。做法在 [Google Search Central](/google-search-central/) 里写得很清楚，照着做一遍不会超过一个下午。

Cloakist 和 Sotion 是个反向的对照：功能说白了只有一句话——给任意网页接上自定义域名。Bruce McLachlan 买下时合计约 2000 美元 MRR，现在超过 12000 美元，2025 年 7 月转成了全职。功能极简，但入口和付费意愿是明确的。

## 换一种记法

Cakedesk 那 31 个没完成的请求，如果当初全做了，2025 年大概会变成"发了 6 个版本、完成 40 个请求"。听起来更努力，收入未必更高。

这个记法有个附带好处：它会自然地把你从"打磨已有页面"推向"多做新页面"。而工具站的流量恰恰是页面数量的函数——10015.io 从 1 个工具到 50 多个，每加一个就多一个独立入口，多一个能被搜到的词。

我现在的记法变了：每周记的不是做了几个功能，是**有几个新页面开始有真实查询词**。这个数字涨，其他投入才有意义。你上周新增的页面里，有几个带来了之前没有的词？
