很多人不是不会做，是一开始就做错了

本章主记忆点：先筛方向，再筛工具。

你看完能拿走什么

• 一组能让你立刻停下来的"方向自检清单"
• 四种最常见的"做错了"模式，可以对号入座
• 一条从"我有个想法"到"可以开始写代码"的判断路径

前置条件

无前置。 这是整个系列的第一章，你只需要带着一个"最近想做点什么"的念头进来就够了。

为什么第一章先讲这个

先讲一个很常见的场景。

一个挺靠谱的工程师，花了将近三周的晚上和周末，用 Codex + Claude 做了一个"帮写日报"的小产品。UI 做得挺漂亮，后端跑得也稳，甚至把 OpenAI 和 Claude 两个模型都接了，做了 AB 测试。

他发到几个群里："你们看看，我觉得挺好用的。"

三十多个人的群。一天之后，一个用户都没有。

他回来问:"是不是我推广得不够？"

我当时给了他一个比较直接的回答:

你这三周里面，没有一天是在做"产品"。你一直在写代码。

这事我自己踩过不下十次。所以第一章不讲工具、不讲 prompt、不讲框架，只讲一件事:

AI 让"做出来"这件事的成本跌到了几乎为零，但"选对方向"的成本没降。

以前你要花三周才能跑起来的东西，现在一天就能跑。但这件事有一个很多人没意识到的副作用:

三周做一个没人要的东西，和三天做一个没人要的东西，结果是一样的——都是零。

更麻烦的是，因为你做得快，你反而更容易把"做错了方向"误以为是"推广不够、功能不够、UI 不够好"，然后继续往下加更多功能、更好的 UI、更炫的 prompt。最后你花了六周，做了一个更好看的、仍然没人要的东西。

整个系列——后面 11 章——都建立在一个前提上:你已经过了"方向这一关"。

这一章就是这一关。

做错的四种模式:对号入座

下面这四种是我自己和身边独立开发者最常见的"做错了"。你不用觉得我在挑毛病——我四种都中过，而且不止一次。

模式 1:工具优先

表现:

• "我最近在玩 Claude Code，想做点什么"
• "LangChain 这么火，找个场景试试"
• "Codex 这么强，肯定有地方能用上"

这不是坏事——用来练手完全 OK。它变成问题是在你把练手当成产品的那一刻。

核心症状:你的起点是工具，不是人。 你在找一个"能用上这个工具的需求"，而不是在找一个"需要被解决的需求"。

自检方法——把工具名从你那句话里抹掉，看看这句话还成不成立:

text
原话:"我想用 Claude Code 做一个自动生成周报的工具"
抹掉工具:"我想做一个自动生成周报的工具"
→ 还成立吗？成立 → 过关
→ 散架了（"我想做一个什么"） → 这就是工具优先

模式 2:自己优先

表现:

• "我每天写日报太烦了，我做一个自动日报"
• "我整理笔记的方式特别乱，我做一个笔记工具"
• "我老忘记喝水，我做一个喝水提醒"

这个模式最迷惑人。因为它看起来最合理——自己是用户，自己的痛点最真实。

但让人踩坑的不是"为自己做"，而是假设"别人和我一样痛"。

你写日报的方式可能很独特，你的笔记体系可能很小众，你忘记喝水的原因可能只有你一个人是这样。你以为你在代表用户，其实你只代表你自己一个人。

自检方法——问一句话:

我认识的人里面，有几个跟我一样痛这件事？

答不出 5 个具体的人名，就先打住。不是不做，是先别急着写代码，去跟人聊一聊再说。

模式 3:技术酷炫优先

表现:

• "Agent 这套太牛了，我也做一个 Agent"
• "MCP 现在这么火，我做一个 MCP 工具"
• "向量数据库 + RAG 这套组合，我能做点啥"

AI 圈里这个模式最常见。因为每隔几周就有新概念、新框架、新玩法，你会被"这东西太酷了"的情绪不断推着走。

但**"酷"不是用户的付费理由。** 用户掏钱是因为他今天遇到了一个很具体的麻烦，而你恰好能解决它。Agent 再牛、MCP 再优雅、RAG 再精巧，对用户来说都只是手段——他不会因为你用了什么技术而掏钱。

自检方法——把你要做的东西翻译成一句"对用户来说，这帮他解决了什么麻烦？"

如果翻译不出来，或者翻译出来是"他可以体验到 Agent 的能力"，那就是技术酷炫优先。

模式 4:功能堆砌优先

表现:

• "再加一个导出功能就上线"
• "再接一个支付就完整了"
• "等我把 i18n 做完就可以发"

这个模式通常是"做了一半不敢停"的伪装。你知道真正发出去之后那一刻要面对"没人用"的风险，所以你下意识地用"还没做完"来推迟这一刻。

自检方法——问一句:"如果我现在就发出去，最坏会发生什么？"

如果最坏的答案是"被人说功能不全"——

被人说功能不全，远远比没人用好。 被人说功能不全至少说明有人用；没人用连说的机会都没有。

---

上面是四种"错的"。下面是一条"对的"。

先筛方向，再筛工具:四步路径

这条路径不保证你能做出爆款，只保证你不会把时间浪费在一个没人要的东西上。

第一步:锁定"谁"的问题

不要写"用户"这两个字。

写一个具体的人:职业、年龄段、他今天在做什么、他卡在哪里。

合格的答案长这样:

35 岁左右的独立外贸卖家，每天要给十几个国家的客户回邮件，英文、西语、法语混着用，来回翻译 3 个小时就没了。

不合格的答案长这样:

需要提高效率的职场人。

第二行你不知道在给谁做，所以你也不知道下一步该问什么。

第二步:看他现在怎么解决

AI 不是凭空解决问题的。用户手上已有的解决办法，就是你真正的竞争对手。

还是上面那个外贸卖家的例子，他现在可能是这样的:

• 用 DeepL 手动翻译
• 收藏了一些常用句式
• 让 ChatGPT 帮他起草
• 忍着，硬写

每一条都可能成为你产品的天花板。

这里有一条铁律:用户换工具的成本，往往比你想象的高得多。 他要学新界面、要改工作流、要重建对新工具的信任。如果你的新方案不能让这些成本值回来，他就是不会换。

第三步:看他凭什么换

这一步最短，但最关键。

你要能用一句话说清楚:换到你的方案之后，他的哪件事从"3 小时"变成"10 分钟"，或者从"经常出错"变成"几乎不错"。

不要写"更智能""更便捷""更高效"这种形容词。写一个数字，或者一个具体的动作。

好答案:

他上传一次客户的历史邮件，我的工具自动学这个客户的语气和偏好。之后每次回邮件他只要点一下确认，10 秒内发出去。

差答案:

更智能的多语言邮件助手，提升跨国沟通效率。

第四步:算账

最后一步是冷酷的——把切换成本算一遍。

对用户来说的成本:

• 学你的工具要多久
• 每个月付多少钱
• 如果你哪天不做了，他切回去要花多少事

对你来说的成本:

• 每个用户每个月大约消耗多少 AI token
• 你的定价能不能覆盖这些成本，还留得下毛利
• 你需要多少个用户才能活下去

这四件事加在一起如果算不过账，这个方向就先放一放——不管你多喜欢它。

一个具体的复盘

2024 年底，我想做一个"给独立开发者用的项目看板"。因为我自己做独立开发的时候同时跑 3 个项目，每次切换都很痛。

我开心了一个下午，开始画线框、写 spec，准备用 Next.js + Supabase 直接开干。

然后我停下来，用上面这四步自己过了一遍:

• 第一步 谁:30-40 岁的独立开发者，同时在做 2-4 个项目。✓ 具体的人写得出来。
• 第二步 现在怎么解决:Notion / Linear / 一个 markdown 文件 / 记在脑子里。✗ 用户已经有办法了，而且有些办法还挺好用。
• 第三步 凭什么换:我当时写的是"更适合独立开发者的节奏"。✗ 这是形容词，不是动作，说不清具体好在哪里。
• 第四步 算账:我估算每个用户每月至少要 5 美元才能覆盖成本。✗ 但独立开发者的项目管理是 Notion 免费就能搞定的事，5 美元的付费墙太高了。

算完之后我把这个想法砍了。

不是因为它不好，是因为我过不了第三步和第四步。

然后我回到第一步重新想:这群人每天真正卡 3 小时以上的事是什么？——不是管项目，是"怎么跟 AI 把需求说清楚"。后面 Ch 3 要讲的 VDF 需求表达公式，就是从这条线出来的。

这件事我大概花了 40 分钟。但它救了我至少两周。

本章主记忆点

先筛方向，再筛工具。

方向错了，工具再好也是白忙。方向对了，工具差一点也能先跑起来。

顺序不能反。

执行步骤

把下面这五件事做完，这一章才算真的读完——不是"看完"。

1. 停手。 不要再往你当前那个 AI 项目上敲新代码。哪怕它已经跑起来了。
2. 写三行字。 原本想做的功能是什么、想用的工具是什么、目标用户是谁。一张便签或一个空白文档就够。
3. 对号入座。 把"做错的四种模式"翻回去一条一条比，老实回答:我中了哪个，或者都没中。
4. 走四步路径。 不管你中没中，都把"先筛方向"的四步完整走一遍。不要在脑子里过，要落到纸上或文档里。
5. 得出一个明确的结论。 要么是"这个方向过关了，可以继续写代码"，要么是"这个方向过不了，我先放一放"。不要停在"大概差不多"。

验证方式

走完上面 5 步之后，拿下面这张 3 行清单对一下。三行都答得上来，这一关你过了。有一行答不上来，回到对应那一步重做。

• 用户:这个方案是给谁用的？（写一个具体的人，不是"用户"）
• 切换理由:他为什么会从现在的办法换过来？（写一个动作或数字，不是形容词）
• 第一个动作:你接下来要做的第一件具体的事是什么？（不是"开发"，是比如"发朋友圈问 10 个做外贸的朋友他们现在怎么处理客户邮件"）

常见问题

Q:我现在手上这个项目已经写了一半，走完这五步发现方向过不了，是不是要全扔？

A:不一定全扔。很多时候你会发现"方向大体对，但第三步或第四步过不了"——这种情况通常只要调整用户画像或者改一两个功能的优先级就能救回来。只有当第一步和第二步都错的时候，才需要彻底换方向。

Q:我真的找不到 5 个跟我一样痛的人怎么办？

A:两个选项。一是先不写代码，去小红书、知乎、相关社群里发一条帖子问问——通常两三天就能验证"这个痛到底是不是我一个人的"。二是换一个更大的痛点——你平时还在为哪些事烦？那个可能才是方向。

Q:为什么不一开始就讲工具？

A:因为 80% 的独立开发者卡住的地方不在工具，而在"我做的这东西到底有没有人要"。工具问题后面会讲（审美、系统思维、需求表达、Demo-First 都有），但这些都建立在"方向是对的"这个前提上。方向错了，工具学得再好也是在给一个没人要的东西打磨。

为什么值得收藏这一章

这一章不是只看一次的章，是每次开新项目都要回来过一遍的门。

每次你冒出一个新想法、想要开一个新项目的那一刻，回到这里重新走一遍"四种模式"和"四步路径"。你会发现 80% 的想法都过不了这道门——这是好事，你省下的每一周都是真金白银。