非程序员做 App,第一步真的不是写代码

而是太早开始写代码。

这句话听起来有点反直觉。

因为现在有了 Cursor/Codex/CC，各种 Agent，很多人会天然觉得：既然写代码的门槛被拉低了，那第一步当然就是先做起来。

但我自己真正开始做第一个 App 以后，反而越来越觉得，对大多数人来说，第一步如果太早进入 coding，后面通常只会更乱。

不是因为代码不重要。

而是因为在你真正开始写之前，有几件事如果不先想清楚，代码只会把混乱放大。

1. 为什么“先写代码”这件事特别有诱惑

因为它看起来最像“真的开始了”。

你打开 Cursor，写一个页面，跑一个界面，点亮一个按钮，当下会立刻获得一种推进感。

这很容易上头。

尤其是对刚开始做产品的人来说，代码是最直观的反馈。

你今天做没做事，好像一眼就能看见。

但问题也在这里。

很多时候，那种推进感只是表面的。

你确实写了东西，但你未必真的离“做出一个对的 App”更近了。

2. 在写代码之前，真正该先想清楚的 3 件事

第一件事：这个 App 到底是帮谁解决什么问题

很多人脑子里的产品想法，其实更像一句模糊愿望。

比如：

• 想做一个更高效的工具

• 想做一个更好看的记录类 App

• 想做一个 AI 结合某个场景的产品

这些都不算错，但都不够落地。

因为你还没有回答一个更关键的问题：

谁会在什么情况下，愿意打开它？

如果这个问题不清楚，后面的页面、功能、交互很容易越做越散。

第二件事：第一版到底只做什么

第一个 App 最容易死在“想做的太多”。

你会觉得这个功能也重要，那个入口也应该有，用户体系、设置页、分享机制、数据同步，好像都很合理。

但第一版真正重要的，不是完整，而是闭环。

你要先回答的是：

1. 用户第一次打开以后，最核心的一步是什么

2. 他完成哪一个动作，就已经算体验到价值了

3. 为了让这个动作成立，最少需要哪些页面和功能

如果你没先把这一版的范围砍清楚，后面的开发就不是在做产品，而是在堆东西。

第三件事：你准备怎么跟 AI 协作

很多人以为，自己不会写代码没关系，反正可以把想法丢给 AI。

但真做起来就会发现，AI 最怕的不是复杂需求，而是模糊需求。

如果你说：

• 做得高级一点

• 交互自然一点

• 界面简洁一点

它当然会产出东西。

但这些东西很可能只是“像个产品”，而不是“你要的产品”。

所以在真正进入 coding 前，你至少要先想好：

1. 我接下来会怎么描述页面

2. 我会怎么定义优先级

3. 我会怎么约束 AI 不要乱发挥

这一层没想好，后面的返工几乎是必然的。

3. 太早写代码，后面最常见会发生什么

我自己现在回头看，太早进入 coding，最容易带来 4 个后果。

第一，方向反复变

做着做着才发现，自己想解决的问题根本没想明白。

于是页面推翻，功能改写，结构重来。

第二，功能越做越多

因为没有一版清楚的边界，所以每个想法看起来都值得加。

最后 App 变得越来越重，核心反而越来越不清楚。

第三，返工特别频繁

不是模型不行，而是你每一次都在用新的理解重写旧的东西。

第四，情绪掉得很快

因为你会有一种很强的挫败感。

明明花了很多时间，眼前也有不少代码和页面，但整体就是没有“成型”的感觉。

这种无效推进，比单纯不会写代码更容易让人放弃。

4. 如果现在重来一次，我会怎么开始第一个 App

如果让我重新开始，我会先做这 4 步，再打开 Cursor。

第一步：先写一句最笨但最清楚的话

比如：

这个 App 是给谁用的，帮他在什么场景里更快完成什么事。

别怕土，先求清楚。

第二步：只写一条最核心用户路径

不要先画完整产品。

先写：用户从打开 App 到完成关键动作，中间会经过哪几步。

第三步：先砍掉 70% 的想法

只保留第一版非做不可的部分。

你现在舍不得砍，后面就会花更多时间返工。

第四步：把需求写成 AI 能执行的话

不是写感觉，而是写任务。

不是说“做高级一点”，而是说：

• 页面目标是什么

• 必须有哪些元素

• 不要出现什么

• 当前只改哪一部分

走完这 4 步，再开始写代码，整个节奏会稳很多。

最后

我现在越来越觉得，非程序员做 App，真正难的不是把代码写出来。

真正难的是，在一开始就把问题想清楚、把范围收住、把第一版压到足够小。

代码当然重要。

但对第一个 App 来说，太早写代码，很多时候只是让混乱更早发生。

如果你也想做一个 App，你现在第一步最想做的是哪件事？

• 先找 idea

• 先写 PRD

• 先画原型

• 还是先打开 Cursor 试着做一版

下一篇我会接着写：一个 App 从想法到原型，到底要过哪 5 关。