目录
个人开发中最常见的受挫，并非技术力不足，而是"做得太精细，永远完不成"。这个也想加、那个也想加，登录功能耗一周，设置页面耗三天，界面微调把周末熔掉——然后在发布之前热情就烧尽了。即便如今AI能替你写代码，这个陷阱依旧不变。反而因为"有AI很快就能做"而贪心，越堆越多、最终沉没的情形越来越多。
出路只有一条。用MVP（Minimum Viable Product＝实用最小化产品）以最快速度推向世界。把功能收敛到仅仅一个，几天内公开一个能跑的东西，实际让人用起来。这篇文章将实践性地带你走完单人创作者（solo maker）以AI为搭档、"用AI一个人做出来并公开"的全过程，从如何砍范围到如何发布。无论走氛围编程还是AI编辑器，抵达的终点都一样——不是"完美的半成品"，而是"粗糙但能用的公开物"。
30秒看结论
纠结的话看这里就够
※想要全局地图的人，请从 用AI做个人开发路线图 开始。本文是其中"以最快速度跑完第一圈"这一部分的深挖。
1. MVP是什么＝能传达价值的最小产品
MVP这个词，因创业者埃里克·莱斯的著作《精益创业（The Lean Startup）》而广为人知。把他的定义讲白了，MVP就是"用最小的力气，去学习一个想法是否真的被需要的产品"（出处：Eric Ries, The Lean Startup - Principles）。要点在于"为了学习"这个目的。不是为了营收，也不是为了自我满足，MVP是一台用最短路径确认"这东西，需要吗？"的装置。
很多个人开发者在这里会误解。"最小≠敷衍"。MVP不是随便做小的东西，而是把一个价值以最小形态送达的东西。请记住下面的区别。
塞了10个功能，个个半吊子。按钮排了一堆，却回答不了"那这到底有什么好处？"。价值传达不出去，所以没人用。
功能只有一个，但那一个是"能用"的。能真切感到"某件事一瞬间就搞定了"。周边（登录、设置、装饰）可以往后放，但核心价值已经完成。
比如要做一款"自动化繁琐工作的工具"，MVP就集中在那个自动化本身这一点上。用户注册、历史保存、漂亮的仪表盘都不需要。输入 → 转换 → 出结果，这条直线跑得顺畅，那就是一款像样的MVP。反过来，注册页和资料编辑都做得完美，关键的转换却还跑不起来——这就不是MVP，只是"半成品"。
💡 口头禅："删掉这个功能，产品的存在意义会不会随之消失？"──会消失就是核心。不会消失，这次就砍掉。只留一个核心、把它最小化后的东西就是MVP。
2. 把功能收敛到一个＝如何砍范围
MVP里最难、也最见效的，是砍掉范围的勇气。一有想法，脑子里就会同时长出10个功能。想把它们全做出来，才做不完。这里要备好一套机械地砍掉"有了会开心"的判断标准。
砍还是留的判断标准（做成卡片随身带）
只留下"没有它价值就不成立"的功能。其余全放到以后。核心定为一个。
连作者自己今天都不会用的功能，别人更不会用。"总有一天谁会用"的功能砍掉。
管理后台或统计，起步阶段就用表格或手工代替。用户看不见。不做。
实现看起来要花一周以上的功能，对MVP太重。拆成更小的形态，或者砍掉。
"有了会开心"的原则上全砍
要砍的对象，往往是同一批老面孔。下面是MVP里基本上可以砍掉的清单。"没有就不好看"这种情绪，公开之后有的是机会填补。
起步阶段最好做成无需登录即可使用。认证等价值被验证后再说。
选项越多，做起来越重。把初始值写死，连设置页一起砍掉。
使用情况用访问统计就够。专用仪表盘不需要。
先免费发布确认需求。定价交给变现・价格设计之后再说。
先做一种语言、PC或手机其中一端即可。有了反应再扩展。
"看起来像样"就够了。逐像素调整是陷阱。
🤖 让AI当砍范围的搭档：把想法告诉它，问"要把它做成最小的MVP，请列出该留的1个功能，以及要砍的功能"，脑子里那10个就会被一口气理顺。让它追问"做到最小会是什么样？""这个，公开真的必需吗？"很有效。想先把规格定下来的人，也可参考 规格驱动开发（spec-driven）。
3. 用AI最快地做出来（入门／实战两条路）
范围收敛到一个功能后，终于要动手做了。这里AI的威力被最大化。不过根据你的编码经验，最短路径会分成两条。无论哪条，做到"能跑"都只需几天。中途换路、或者混着用都可以。
几乎不写代码。用语言把"想做的东西"讲清楚，让AI整个组起来，这就是氛围编程的风格。只在浏览器里就能完成的AI应用构建器——v0・Bolt・Lovable——可以从提示词生成界面和功能，一路做到发布。如何选择见 v0 / Bolt / Lovable 对比。先读 新手也能用AI做应用吗 降低心理门槛。
用AI编辑器写代码。以 Claude Code 或 Cursor 为搭档，高速地跑设计、实现、修改。适合多少能读点代码的人，强项是日后易于扩展和维护。诀窍是把收敛后的那1个功能的规格用Markdown交给它，指示"先只把这一点跑起来"。想从基础动手学，课程 「AI编程入门」 是捷径。
两条路都通用的"最快跑法"
路线不同，用AI最快做出来的诀窍却一样。不是一大发狠，而是小步多圈地跑。
先跑起来的不是外观或周边，而是"输入→处理→结果"的那条直线。核心一动，那就是MVP的骨架。
对AI"全都做出来"地甩包袱就会崩。一次指示一个功能→验证运行→再下一个。坏在哪也好定位。
进入能跑的状态就用Git勤提交（入门构建器则用历史/快照）。坏了也能回退的安心感会带来速度。
一个人没有审查角色。"请列出这段代码里危险的输入、遗漏的考量"，让AI自己来审计。
🔑 公开前的最低限度安全：即便是MVP，API密钥、私钥不要直接写进代码（放到环境变量）／保护他人的数据 这两点绝对要做到。哪怕是AI生成的代码，也要亲自确认密钥没有埋进源码。这里不是可以砍掉的范围。
4. 判定"完成"＝MVP的Done
停不下打磨的人，是没有"完成"的定义。目标无限，就会一直"再改一点"。所以在开始MVP之前，把Done的界线写在纸上。越过这条线，就不再动它、直接进入发布。
MVP的Done＝满足这4点就算"完成"
从输入到结果，别人能从头执行到尾，中途不卡住。
空值、怪值不会导致白屏或崩溃。友好的错误提示就够。不必覆盖所有情况。
首页有"这是做什么用的"一句话和用法。不用解释就能上手。
密钥在环境变量里。他人的数据不会混入。处于公开也不出事的状态。
反过来，要想开：下面这些"不是Done的条件"——动画是否顺滑、在所有浏览器上完美显示、对所有意外输入的应对、代码是否优美。这些都可以在公开后一边看用户反应一边改。"Done清单全部打勾后，就不再动它"——这样对自己许下承诺，是停止过度打磨的唯一方法。
⏳ 时间盒也有效：先把截止日固定为"这周末之前公开"，再把范围砍到能塞进这段时间里。让时间可变，它就会无限拉长。固定时间、让功能可变，正是MVP的思路。
5. 发布＝无论如何先公开、让1个人用
MVP真正的目标是"公开出去，让自己以外的1个人用起来"。抵达这里，想法才第一次接触到现实的反应。很多个人开发者把这最后一步一拖再拖，"再改好一点再说"，结果永远不公开。粗糙就粗糙，这周，发出去。
最轻量的公开方式
AI应用构建器直接就有发布按钮。实战路线用托管的免费额度就足够。自定义域名之后再说。
先把URL发给一个真的可能会用的人，问一句"这个，怎么样？"。面向大众的宣告之后再做也不迟。
别在旁边解释，观察他在哪里卡住。卡住的地方正是最该优先改的点。行为比感想更诚实。
为什么"1个人"就够
不必一上来就凑100人。仅仅1个人真正去用、卡住、或者高兴的样子，能带来的信息，比在脑子里想100个小时还要浓。1个人说"这个方便"，就有需求的萌芽。1个人说"这里我没看懂"，那就是下一个要改的最优先点。作者的想象几乎必然与现实错位——公开，正是为了用最小的力气找出这份错位。到了扩大人数阶段的获客，见 如何招募最初的100人。
📚 想动手一气呵成做到底，推荐免费课程。我们准备了可以按章实践"收敛想法→用AI做→公开"的入门课程「用AI做个人开发」。把本文当"MVP的模板"、把课程当"实践的操作手册"搭配使用，就能不迷路地跑完第一圈。
6. MVP之后＝看反应决定下一步
公开成功后，MVP的使命就完成了一半。剩下一半是"读懂反应，决定下一手"。到这时，先前砍掉的"有了会开心"的功能才轮到出场——不过，不是全部，而是只加反应真正要求的那些。
反应的3种模式，以及下一步动作
核心价值命中。接下来只加一个被人说"没有它就不方便"的功能。到这时才开始考虑注册和保存。变现・价格设计也从这个阶段起步。
价值传达到了但偏弱。改进一处卡点或"差一点的地方"再给人看。方向是打磨核心，而非加功能。
虽然难受，但这也是大丰收。就当"几天就搞清楚了，太好了"。换个切入点，或转向别的想法。舍弃的判断也是越快越划算。
MVP思路的高明之处，在于把失败的成本降到最小。如果花几周把全部功能都精雕细琢完，才发现"没人用"，那损失就大了。但用MVP，投进去的只是几天。能搞清楚"这不行"，也是用AI一个人做的最大好处。这样才能把时间集中投给命中的那个想法。
把这个"做小→发布→靠反应决定"的一圈，反复跑到你的产品有了手感为止。想看全局流程、以及养育阶段（获客、变现、运营），回到母舰 用AI做个人开发路线图 即可。第一圈，就在这个周末。那是一切的开始。
常见问题
Q. MVP做几天比较合适？
A. 没有固定标准答案，但个人开发建议把几天～一周作为上限尺度。拖得越久，越接近"做得太精细"的陷阱。先把天数固定，再把功能砍到能塞进去，这是诀窍。先定"这周末公开"，再倒推安排。
Q. 没有编程经验也能做MVP吗？
A. 能做。走🌱入门路线，用AI应用构建器（v0 / Bolt / Lovable）或氛围编程，几乎不写代码就能做到公开。先读新手也能用AI做应用吗，从收敛到一个功能的小项目起步最稳妥。
Q. 功能收敛到一个，显得寒酸，心里不安。
A. 那就对了。MVP比拼的不是"很多功能"，而是"一个价值确实能用"。哪怕看起来寒酸，只要那一点戳中，人们就会用。反过来，功能堆满但核心弱的产品，往往连公开都没做到就消失了。这份不安，公开出去让1个人用一用，大半就会消散。
Q. 一个人做，质量和安全让我不安。
A. 审查角色交给AI。让它审计"请列出这段代码的bug、危险输入、缺失的测试"，把提出的问题一个个改掉。此外即便是MVP，"把API密钥挪到环境变量""保护他人的数据"这两点也务必遵守。这两条不能从范围里砍掉。
Q. MVP之后，什么时候该加功能？
A. 从用户说"没有它就不方便"的功能开始加，而不是你自己觉得"有了会开心"的功能。公开后看反应，只把实际被要求的东西一个个加上去——守住这个顺序，就不会把时间熔在没人用的功能上。养育阶段的全貌见个人开发路线图。
