# 做了这么多网站以后，我总结出的独立开发原则

URL: https://caijiao.org/posts/146
Source: docs/posts/146.md
Description: 站点声誉滥用（4.6.4）让我放弃了在一个教程站下挂一批理财内容的念头；10015.io 到 50 个工具才发第一篇文章，到 64 个才上 Product Hunt——这条阈值我一直在抄。

Google 的垃圾内容政策里有一节叫"站点声誉滥用"（4.6.4），说的是借宿主站已有的声誉发布与之无关的内容。我第一次读到这条的时候，正打算在一个技术教程站下面开一批理财栏目。

那个计划放弃了。后来我越来越觉得，那次放弃比我做成过的任何一个站都值钱——因为它让我开始把"内容放在什么语境里"当成第一原则，而不是最后一件事。

## 内容要长在它自己的技术语境里

教程站讲的东西是"怎么做出来"，理财内容讲的是"怎么赚到钱"。把后者挂在前者下面，读者困惑只是表层问题。真正的风险在政策层面：4.6.4 针对的就是这种寄生关系，而它的处罚单位是整站。

这条原则落到执行上很具体：一个页面能不能被挂进某个站，看它和这个站的主题是不是同一件事的延续。讲 [WebAssembly](/webassembly/) 的站可以讲编解码和性能，因为那是同一件事的另一面；它不能讲信用卡返现，因为那件事和它没有技术上的承接关系。

Google 在 [Search Central](/google-search-central/) 的文档里把这几类问题分得很细，值得在有第二个站的想法之前先读一遍，而不是等流量掉了再回头找原因。

我后来给自己留了一个很简单的自检：把这篇文章整段搬到另一个主题的站上，读起来还成立吗？成立，说明它没有真正属于这里；不成立，说明它长在这个语境里。多数凑数内容都经不起这一搬。

## 250 个页面套同一个模板，不叫规模化，叫复制

规模化内容滥用（4.6.5）和"几乎没有付出努力就生成的内容"（4.6.6）是两条相邻的线，它们针对的不是"页面多"，是"页面之间没有实质差别"。

我的判断方法：把两个页面的正文并排放，如果去掉专有名词之后几乎一样，那它们就是复制。每个页面至少要有一处只属于它的具体信息——一个具体输入、一个具体输出、一段具体用法、一个真实的边界条件。

Omni Calculator 的做法值得学：它把计算器抽象成配置，页面由模板生成，但每份配置里写的是真实的公式、单位和说明，不是把同一个段落换个名词填进去。模板化不等于模板填空。

还有一件事要记住：Helpful Content System 在 2025 年升级成了整站级别的信号。一批凑数页面不再是它们自己没流量那么简单，它们会参与整站评估。这也是我后来给"不做清单"留位置的原因。

## 能放进浏览器的计算，别放进服务器

10015.io 的 50 多个工具几乎全在客户端跑，极少请求服务端。这不只是省服务器钱——每挪走一个服务端组件，就少一份需要长期维护的东西：没有数据库要迁移，没有队列要盯，没有定时任务要确认它跑过。

![10015.io 官网首页截图](/images/2026-09/10015.io.png)

*10015.io 首页只有 Explore Tools 和 Product Finder 两个按钮，没有第三种动作。*

浏览器能扛的活比多数人以为的多：图片压缩、格式转换、音视频编解码，都能用 [WebAssembly](/webassembly/) 跑。判断边界很简单——几秒内能算完、结果不需要留在服务端给别人取用，就留在前端。

## 50 个工具之前不发文章，64 个之前不上 Product Hunt

这条阈值是我从 10015.io 抄来的，它写在官网的路线图里：50 个工具开始写文章发社媒，64 个上 Product Hunt，128 个做 v2，256 个做 v3。

它背后的逻辑我认同得很实在：渠道打开的是水龙头，不是水源。只有三五个页面的时候，你花力气带来的访问留不下任何东西；到 50 个页面，用户搜一个具体动作进来，发现还有几十个能用的，他才会记住这个域名。

Product Hunt 的数字也支持这种耐心：每天约 668 次发布，被 feature 的比例约 2.8%。一次没上榜是常态，把它当成一次收集反馈的机会就够了。

## 一个人能维护的边界，就是产品的边界

Max Schmitt 一个人做 Cakedesk，2025 年发了 12 个版本，收到 44 个功能请求，完成 13 个。Andy Cloak 一个人做 Data Fetcher，做到 600 个付费客户、MRR 23000 美元。

这两个例子能成立，是因为它们的边界很清楚：没有需要 24 小时响应的环节，没有必须由人工介入才能完成的流程，没有第二个人才能维持的协作机制。

所以我给自己定了一条：任何需要"我每天必须出现"才能运转的设计，都不做。要自动能跑，要出事有告警，要别人照着文档能在一天内部署起来。

## 90% 的人每周都在用 AI 写代码，但没人替你决定写什么

JetBrains 的调研里，90% 的专业开发者每周至少用一次 AI 编码 agent。它已经是默认工具，争论该不该用没有意义。

有意义的是分工：它适合写页面模板、写样板代码、写测试、写配置片段——这些有明确模式的活。它不该替你决定做哪 50 个页面、判断哪个词值得覆盖、看完数据后决定改什么。

生成得快从来不是瓶颈，判断错了才致命。

## 成本要算时间，不算机器

terrific.tools 做了 12 个月才等到第一个完整变现月，广告 174.41 美元加桌面版 125 美元。Stripe 的统计里，独立创始人早期收入的中位数下降了 23%，前 10% 上升了 19%，差距 61 倍。

这个差距不可能来自谁的服务器更便宜。它来自时间被放在哪里——放在能积累的东西上（页面、外链、闭环完整的产品），还是放在不产生复利的事情上（换框架、调优一台没多少访问量的机器）。

这几条原则没有一条是关于"怎么做得更快"的。做过十几个站之后我唯一比较确定的事是：让一个站活下去的那些东西，和让它更快上线的那些东西，几乎从不重合——前者慢、笨、需要反复回到同一个页面上去磨，后者快，但往往只是把问题推到三个月后。

---

*文中政策条款编号引自 Google 搜索垃圾内容政策；10015.io 路线图来自其官网 Roadmap 页面。*