先能用，再好用：从烂尾复盘到两周上线，全栈项目的‘原型

先能用，再好用：从烂尾复盘到两周上线，全栈项目的“原型—快速迭代”方法论

全栈学习路径的文章已经很多了：怎么选技术栈、怎么搭环境、怎么记文档，几乎每个方向都有人写。但一个更扎心的问题很少有人正面讨论——为什么很多全栈项目做着做着就烂尾了？

本文不打算铺开讲“从入门到精通”，而是聚焦一个具体的方法论：先做原型，再快速迭代。它的出发点来自博客作者韩祺在《Web 全栈入门指南 | 知与行》中对三个项目的对照复盘，再结合 wow-fullstack 教程中“先跑通、后完善”的项目结构，把这套方法落成一份可复用的清单。

一、烂尾项目长什么样？

先看反面案例。博客作者的第一个项目是管理问卷、调查对象、生物样本的系统，花了半年，最后仍然烂尾。烂尾的原因当然不止一个，但其中最致命的是：

对着幻想出来的需求写程序。没有真实用户，所有功能都来自自己的想象，写到一半发现“好像没人需要这个”，动力随之崩塌。
全程缺少反馈。没有上线的压力，也没有外部输入，开发过程变成了一种孤独的自我消耗——用作者的话说，就是“会有迷失的感觉”。
在非核心功能上过度投入。环境、部署、边缘特性反复打磨，核心功能却迟迟没有跑起来。

半年投入换来的失败听起来很惨，但作者也提到一个“功不唐捐”的观察：三个看似不同领域的项目——管理问卷样本、管理日记文件、管理订单会员——功能重叠度其实很高。比如前者用条形码定位调查对象，后者用条形码定位产品，这部分程序小改一下就能复用。所以烂尾不等于白干，但前提是：下一个项目别再掉进同一个坑。

二、“先能用，再好用”具体怎么做？

作者把“先做原型，再快速进行迭代”总结为八个字：先能用，再好用。第三个项目因为运用了这套理念，两周左右就上线了。需要说明的是，作者自己也坦言“这只是原因之一，但确实占了很大的比重”——方法论不是魔法，但它确实改变了开发过程的状态。

拆开来看，它包含三个关键动作：

1. 核心功能先上线，别等“完美”

第三个项目是一个为经营化妆护肤品生意的亲戚做的商家管理工具，覆盖产品、订单、会员的管理。作者的做法是：先把核心功能点写完，直接上线。没有经过漫长的封闭开发期，产品很早就接触到了真实使用者。

这一步的关键心理转变是：接受初版的粗糙。“能用”的标准不是“功能齐全”，而是核心链路能跑通——用户能添加产品、记录订单、管理会员，就够了。

2. 跟随真实需求迭代，而不是想象需求

上线之后，有意思的事情发生了：用户几乎每周给他提两三次需求，而且“这些需求其实很多自己都压根没有想到”。

这就是原型迭代的复利所在：需求不再来自闭门造车，而是来自真实使用场景。开发者要做的不是预先设计完美方案，而是建立一条快速的反馈—响应通道。作者描述这种状态是“全程都是清晰有反馈的，不会有迷失的感觉”——这恰恰是第一个项目烂尾时最缺的东西。

3. 用 LLM 落地“异想天开”的需求

一个典型案例：用户希望产品品类可以自动分好类。搁在几年前，这是个“有点异想天开”的需求——要么放弃，要么写一套复杂的规则引擎。但现在 LLM 技术初露头角，作者直接使用 ChatGPT 来做分类，原本不可能的需求变成了可以快速落地的小功能。

另一个例子：扫码产品一键添加的功能，背后利用中国物品编码网来填写产品信息。这类“借力”思路——用现成的外部服务和 API 替代自研——正是快速迭代方法论的重要一环：不造不必要的轮子。

三、对照 wow-fullstack：“先跑通、后完善”的项目结构

方法论听起来有点虚，但它在开源项目里其实有具体的工程形态。Datawhale 的wow-fullstack教程（GitHub 仓库 datawhalechina/wow-fullstack）就体现了这种“先跑通、后完善”的思路：

环境验证前置：教程让你先用浏览器访问后端，确认能看到{"Hello":"World"}，再确认 FastAPI 的接口文档页面正常——“两个都没问题，就说明后端一切正常”。先确认最小可用链路，再往后走。
测试数据先行：通过python seed.py一键填充管理员账号和基础数据，方便立刻进入测试状态；再用python check_password.py验证数据有效性。核心逻辑没有数据也能先“动起来”。
教程与代码分离：教程覆盖 Element Plus、FastAPI 入门、Vue3、TypeScript 以及各种自动化专题，均为 Markdown 文档，代码可直接拷贝使用。学习者可以先跑通示例，再按需深入。
文档兜底重复劳动：配套开发文档、用户手册，把环境搭建、启动命令这类“几周用一次、每次查半小时”的操作固化下来。

这个结构对个人项目同样适用：每次迭代都从“跑通最小链路”开始，而不是从“重构完美架构”开始。