vibe coding 最擅长的是需求清楚、数据简单、只有自己用、不用长期维护的场景，这种场景下从零让 AI 写反而更快，因为不用先理解一套别人的代码结构。一旦出现用户输入不规范、权限不对、部署失败、需求反复迭代这类情况，从零写的代码就开始崩，这时候引入一个成熟框架，等于把别人已经处理过的边界情况直接拿来用。判断标准不是“哪个更先进”，而是你这次要解决的是不是单点小问题：是，就从零写；不是，就先找一个贴近需求的框架再让 AI 在上面改。

出处 1 2

很多人用不好 AI coding，卡住的不是 prompt，而是对编程环境和上线流程不熟：terminal 没打开过、IDE 的窗口关系看不懂、Git 和部署服务不知道怎么串起来。这些门槛无论你从零写还是用框架都会遇到，所以与其纠结起点，不如先把“改完能跑起来、能部署上线”这条链路走通一次。有人用两句 prompt、十分钟做出并部署了一个小工具，靠的正是平台把 API 调用和自动部署这两步包掉了，而不是靠选对了框架。

出处 3 2

成熟开源框架在账号、权限、支付状态这类通用环节上，通常比个人从零写更可靠，因为已经有人踩过大量边界情况。但它严谨的是“必须可靠运转的基础设施”，不是“这个产品到底该做什么”。立正举过一个例子：一个会员系统背后有数万行代码和大量文档，即使码力很强的人也要花好几天才做稳定，而这些修改往往不是因为第一版写得差，而是很多正确决定在看到错误版本之前根本不存在⁠1。所以框架能帮你省掉一部分通用工程，但省不掉“先看到错误版本才知道该怎么做”的过程。

demo 只需要在展示那一刻是对的，产品要在用户、业务和外部依赖不断变化时一直是对的⁠1。这部分叫 ownership：付款失败、退款、权限变化、重复账号、需求迭代，都要有人判断正确行为并持续负责。AI 能把写代码的显性成本压得很低，但一个自建系统如果每周从你这里拿走几小时注意力，它可能比每月几百美元的现成服务更贵⁠1。对你想做的长期产品，值得先问：哪些部分体现你的独特优势、值得长期拥有，哪些只是必须可靠运行的通用件⁠1。