避坑指南

做独立开发这几年，我犯过很多错误。有些是自己摸索踩的坑，有些是看别人摔倒才明白的道理。这一章把这些教训整理出来，希望能帮你少走一些弯路。

这不是什么"成功学"。恰恰相反，这是一份"失败学"。真正有价值的经验，往往来自那些痛苦的失败，而不是偶然的成功。

产品方向的坑

没有验证就开始做

这是独立开发者最常犯的错误，没有之一。

我见过太多这样的故事。一个开发者觉得自己遇到了一个痛点，假设别人也有同样的问题，然后花几个月做出一个产品，发布后发现——没人要。

有一个在 Indie Hackers 上很有名的调查：500 个在 Product Hunt 发布的 SaaS 产品，最后 97% 月收入不到 1000 美金。这些产品不是做得不好，而是从一开始就没有找对方向。

验证的方法不复杂。在写代码之前，先去 Reddit、X、论坛上看看，你想解决的问题真的有人在抱怨吗？有没有人在用竞品？他们愿意付钱吗？甚至可以做一个简单的落地页，看看有多少人愿意留邮箱。这些事情花一两周就能做完，但能帮你避免几个月的无效劳动。

做"维生素"而不是"止痛药"

这是另一个常见的陷阱。

"维生素"是那些"有了更好"的产品。用户可能会觉得不错，但不会为它付费，因为没有它生活也能过。"止痛药"是那些解决真实痛点的产品。用户有一个困扰他们的问题，你的产品能解决它，他们愿意掏钱。

怎么判断自己做的是维生素还是止痛药？问自己一个问题：如果用户今天不用你的产品，他们会有什么损失？如果答案是"没什么损失"，那可能就是维生素。

做得太多太杂

另一个常见的问题是想一口气做一个"大而全"的产品。

有个创业者在 Reddit 分享他的教训：一开始想做一个"企业级协作平台"，一年后发现还在做 MVP，因为光是"企业级"三个字就意味着无穷无尽的功能需求。后来他把范围收缩到"给小团队用的简单任务看板"，三个月就上线了，还卖出了订阅。

这本书前面讲 MVP 的时候强调过：MVP 不是缩水版的完整产品，而是只解决一个核心问题的最小方案。做产品的正确姿势是：先做一个非常小的东西，验证有人需要，然后再慢慢加功能。不是先想好所有功能，然后一个个实现。

AI 编程的坑

作为一本讲 AI 编程的书，这个话题不能不说。AI 是强大的工具，但用不好也会掉坑里。

什么都让 AI 写

最危险的心态是把 AI 当成万能的后端团队，什么都交给它。"帮我做一个完整的 SaaS 应用"——这种 prompt 得到的通常是一堆无法维护的代码。

AI 生成的代码有几个隐藏的风险。第一是安全漏洞。斯坦福大学有一项研究发现，使用 AI 辅助编程的开发者反而更容易引入安全漏洞，因为他们对 AI 生成的代码放松了警惕。第二是技术债务。AI 每次生成的风格可能不一致，时间长了代码库会变得混乱。第三是过时的实践。AI 的训练数据可能是几年前的，它推荐的库或方法可能已经过时了。

正确的方式是把 AI 当作副驾驶，而不是司机。你要知道自己想去哪里，你要审查它给的路线，你要在必要的时候接管方向盘。

对话太长失去上下文

这是 AI 编程的一个技术性陷阱。

当你在一个对话里改了五十轮，AI 开始"忘记"之前的约定。它可能会重复引入你已经删掉的代码，或者给出和之前风格完全不同的实现。这是因为 AI 的上下文窗口是有限的，太长的对话会让早期的信息被挤出去。

解决方法很简单：完成一个功能就开一个新对话。把当前的技术栈、已有的代码结构、和你想做的事情重新告诉 AI。这听起来麻烦，但比在一个混乱的长对话里挣扎要高效得多。

另一个相关的习惯是使用规范文档。在项目根目录放一个 SPEC.md 或者 .cursorrules 文件，记录项目的技术栈、代码规范、目录结构。每次开新对话的时候让 AI 先读这个文件，它就能快速了解项目背景。

不用 Git

这个坑说出来有点难为情，但确实有人踩。

有一次我让 AI 重构一段代码，结果它把整个文件的逻辑改乱了。我想回滚，发现没有提交过。只好花两个小时手动对比恢复。从那以后我养成了习惯：让 AI 改之前先 commit，改完之后再 commit。出问题随时可以 reset。

# 开始改之前
git add -A && git commit -m "before: refactor auth"

# AI 改完且你验证过之后
git add -A && git commit -m "feat: refactor auth"

# 如果搞砸了
git reset --hard HEAD~1

这个习惯不只是为了防止 AI 搞砸。它让你可以大胆尝试，知道随时可以回滚。这种心理上的安全感会让你更敢探索。

开发节奏的坑

完美主义拖延症

"再加一个功能就发布"——这句话可能是独立开发者说的最多的谎话。

完美主义是产品上线最大的敌人。你想把所有功能都做完，想把每个细节都打磨好，想让用户一上来就获得完美的体验。但问题是，你根本不知道什么是"完美"。只有真实用户用了之后，你才知道哪些功能是必要的，哪些细节是多余的。

Dropbox 的 MVP 是一个演示视频。Twitter 最早的版本功能简陋到现在看都不敢相信。这些后来成功的产品，在最开始的时候都是"半成品"。

如果你已经做了三个月还没发布，问问自己：是真的没准备好，还是在害怕用户的负面反馈？很多时候是后者。

Shiny Object Syndrome

这是另一个杀手。

你在做一个项目，做到一半，突然看到别人做了一个很火的产品。你心想：这个方向好像更有前途。于是你放下手头的项目，开始做新的。新项目做到一半，又看到另一个机会……

一年下来，你有十个半成品，没有一个能用的。

这种症状在独立开发者圈子里太常见了。有人在 X 上分享自己的教训：五年里他做了二十多个项目，没有一个达到每月 1000 美金的收入。后来他强迫自己在一个项目上坚持一整年，不管遇到什么诱惑都不换方向。那一年他终于做出了一个每月赚 5000 美金的产品。

解决方法没有什么秘诀，就是给自己设定一个时间锁。比如：这个项目我至少做六个月，不管中间看到什么机会都不换。六个月之后再评估。

营销的坑

"Build it and they will come"

"产品足够好，用户自然会来。"

这是技术人最容易犯的错误。我们擅长写代码，不擅长卖东西，所以把所有精力都放在产品上，以为产品好了自然有人用。

但现实是，你的产品再好，如果没人知道它存在，就等于它不存在。

有一个经验法则：花在营销上的时间应该至少和花在开发上的时间一样多。如果你这周写了 20 小时代码，那也应该花 20 小时在营销上——写博客、发社交媒体、做 SEO、联系潜在用户。

很多成功的独立开发者会在产品还没做完的时候就开始 build in public，在社交媒体上分享开发过程。这样产品上线的时候，已经有一批关注者了。

在错误的渠道花时间

不是所有营销渠道都适合你的产品。

B2B 产品在 TikTok 上推广效果可能很差，但在 LinkedIn 上可能很好。面向开发者的产品在 Hacker News 上可能有不错的反响，但在 Facebook 上可能无人问津。

有人花三个月运营 Instagram，粉丝涨到几千，但一个付费用户都没有。后来发现，他的目标用户根本不用 Instagram。

在投入大量时间之前，先搞清楚你的用户在哪里。他们用什么社交平台？他们在哪些论坛活跃？他们怎么搜索解决方案？然后把精力集中在那几个渠道上。

心态的坑

Solo Founder Burnout

这是最隐蔽但最危险的坑。

独立开发者没有老板催你，没有同事可以分担，所有的压力都在自己身上。很容易陷入一种状态：每天工作十二小时，周末也在写代码，休息的时候满脑子都是产品。一开始你觉得这是"passion"，但几个月后你发现自己开始讨厌这件事。

Burnout 的迹象：对原本喜欢的工作失去兴趣。效率明显下降，以前一天能做完的事现在要三天。容易烦躁，对用户的反馈过度敏感。开始怀疑自己当初的选择。

2024 年的调查显示，超过一半的创业者经历过 burnout。这不是弱者的问题，这是结构性的风险。

预防的方法：设定工作边界。比如晚上九点之后不工作，周日必须休息。找一个可以倾诉的人，可以是朋友、家人、或者线上社区的同行。定期运动，保持身体健康。如果感觉不对劲，认真考虑找心理咨询师聊聊。

把自我价值和产品绑定

这是一个心理陷阱。

你花了几个月心血做一个产品，发布后如果反响不好，很容易觉得是自己这个人失败了。你把自己的价值和产品的成败绑定在一起，每一个差评都像是对你个人的否定。

但产品失败不等于你失败。所有成功的创业者背后都有一堆失败的项目。Y Combinator 的创始人都说过，他们投资的创业者平均要失败两三次才能成功。失败是过程的一部分，不是终点。

学会把自己和产品分开。产品是你做的东西，不是你这个人。用户不喜欢你的产品，只是说明这个产品需要改进，或者这个方向不对。它不是对你这个人的评判。

最后：失败是常态

写这一章不是为了吓你。恰恰相反，我希望你了解这些坑之后，能更从容地面对它们。

大多数独立开发的项目会失败。这不是因为创业者不够努力或不够聪明，而是因为做产品本来就很难。市场难以预测，用户需求在变化，竞争环境复杂。失败是这个游戏的一部分。

知道会有坑，提前做好准备，踩到坑的时候不要太自责，爬起来继续走。这可能是这一章能给你的最重要的东西。

最后用一句在 Indie Hackers 社区流传很广的话结尾：

"你的第一个产品大概率会失败。你的第二个产品可能也会失败。但如果你一直在学习、一直在尝试，总有一天会做出 work 的东西。大多数人的问题不是能力不够，而是放弃得太早。"

这是《Prompt to Product》的最后一章。希望这本书对你有帮助。祝你做出自己的产品，赚到自己的第一桶金。

如果你在开发过程中遇到问题，欢迎来 推特/X找我聊。Build in public, fail in public, learn in public. 我们一起成长。