First App in Bolt.new
第一次在 Bolt.new 里做东西，最容易犯的错不是技术选错，而是目标写太大。很多人嘴上说“先做个 demo”，实际写进去的需求却像在招一个全栈工程团队: 登录、支付、后台、埋点、权限、仪表盘全要。然后第一轮生成完，他自己都不知道应该先点哪里。
所以我现在更倾向把 first app 理解成一件很具体的事: 先做一个别人看一眼就知道用途，而且真的能点完主流程的小东西。
报名页、预约页、待办页、FAQ 搜索页、简单 dashboard 都很适合。只要有一个页面、一个输入动作、一个立刻能看到的结果反馈，其实就够了。第一版的价值不在“看起来像 SaaS 成品”，而在于它能不能证明方向是对的。
开始前先把边界写死
我觉得最有用的准备，不是先研究栈，而是先写清楚两句话：
- 第一版只证明什么
- 第一版明确不做什么
第二句往往更重要。你不写，它就会自动膨胀。Bolt 不是不会克制，而是你不给边界，它就只能替你猜。
prompt 不用花，得够具体
下面这种写法通常就够稳：
Build a booking page prototype.
Stack: React + Tailwind.
Data: local mock data only.
Features: create booking, list bookings, cancel booking.
Constraints: mobile-first, no auth, no backend.
Acceptance: user can create one booking and see it in the list.
这个 prompt 的好处，不是格式漂亮，而是它把 demo 和 production skeleton 分开了。Bolt 不用替你猜“到底是先做给人看，还是已经准备上线”。
生成完先别急着修好看
我通常第一眼只看三件事：能不能打开，主流程能不能走通，文件结构是不是还讲得明白。只要这几点成立，第一轮就算成功。
原型阶段最怕的不是不好看，而是你已经没法解释它到底怎么工作。很多人就是在这一步翻车的: 页面很多，按钮也不少，可你问他这个产品最重要的流程是什么，他要想半天。
跑不起来时的处理方式
first app 出问题，很多时候还是基础问题。依赖没装对，某个生成文件不完整，环境变量漏了，或者上一轮提示太激进，直接把本来能跑的结构改乱了。
这种时候我反而不建议“重来一版”。更稳的做法是让它先解释原因，再最小修：
Explain the cause first.
List the files you need to change.
Fix with minimal changes.
Do not rewrite the whole project.
这句话的作用很实际，它能拦住那种“一看到问题就全盘重构”的冲动。
第二轮不要贪
第二轮最好只选一个方向。要么补交互，比如 validation、loading、empty state；要么补结构，比如拆组件、整理文件；视觉通常放后面再修。如果你一轮同时改结构、风格、状态和部署，原型很快就会失控。
一个很土但很准的检查办法
如果你拿不准 first app 到底算不算合格，就把链接扔给一个完全不知道背景的人。看他能不能在一分钟内说出这页面是干什么的、下一步该点哪里。说不出来，说明第一版还没收干净。
这件事听起来很粗糙，但比你自己在本地盯着页面看半小时有用得多。
