最近自己连续从 0 到 1 起了几个项目，有一件事我现在感受很强：

AI 让开发变快了，但它没有顺手把“项目怎么做对”这件事一起解决掉。

代码当然更容易写了。脚手架能更快起，页面能更快铺，接口和测试样例也能更快补出来。以前会拖你好几天的很多体力活，现在半天甚至一两个小时就能往前推一大截。

但项目最后能不能成，卡点经常在更前面的几个判断上：

• 目标到底有没有收住
• 第一阶段要验证什么
• 哪条主路径最该先打通
• 哪些东西现在该做，哪些东西其实是为一个还不存在的未来买单

AI 把执行门槛降得很低，结果反而把另一个问题放大了: 人更容易在没想清楚的时候，快速堆出一个看起来很完整、其实没有焦点的项目。

问题就出在这儿。

我现在不太把“AI 时代怎么快速做项目”理解成“让 AI 多写 10 倍代码”。我更愿意把它理解成另一件事：把低判断密度的摩擦交给 AI，把决定项目生死的判断留在自己手里。

先把环境摩擦交给 AI，但别把判断也一起外包

很多项目死在开头那一堆不创造核心价值的摩擦上，功能本身反而没那么难。

装 SDK、配运行时、处理依赖冲突、修本地构建、补脚手架、把 CI 和 Docker 先搭起来，这些事都重要，但它们不值得吃掉你最好的注意力。尤其在新项目刚开始的时候，人最稀缺的不是时间，而是推进感。推进感一断，项目很容易直接冷掉。

这时候 AI 最值钱的用法，就是先帮你把这些高频、标准化、又很烦的事情推过去：

• 初始化项目结构
• 配前后端基础框架
• 生成本地运行脚本
• 处理常见依赖错误
• 补测试环境、Docker、CI 的基础模板
• 起 CRUD、接口定义和页面骨架

这些都属于环境摩擦。它们当然有工程价值，但不是你在项目早期最该亲自消耗的地方。

我现在更倾向于把自己的精力留给那些确实会影响方向的事。项目一开始，最怕的是根本跑不起来，或者跑起来了却没有一个清楚的验证目标——代码漂不漂亮反而是次要的。

所以第一步先别追求优雅，把“能运行、能往前推”建立起来再说。

真正该先想清楚的，不是项目叫什么，而是第一阶段到底要验证什么

做项目的时候，一开始常说的是“我想做一个 XX 系统”。这句话听起来像目标，其实信息量很低。

项目早期该回答的，通常是更朴素的几句话：

• 这个东西是给谁用的
• 它先解决哪一个具体问题
• 我怎么判断第一阶段算成功
• 最小闭环到底是什么

AI 会让“开始写”这件事变得非常容易，而这恰恰也是危险的地方。以前开发成本高，很多人多少还会被迫多想一会儿；现在一句 prompt 就能生成页面、接口、表结构，反而更容易在目标模糊的时候先堆出一堆东西，再试图从里面找焦点。

我现在开工前，一般会先逼自己把一句话写得非常具体：

这一个阶段，我只解决一个什么问题。

不是三件事，不是一套平台，也不是一个以后可以扩成生态的想象。就是一个问题。

因为很多项目做不出来，问题出在目标密度太高，技术反而够用。

早期不要迷恋“大项目”，优先选那些能快速进入反馈回路的场景

很多项目最后卡在验证周期太长。你做了很久，依然不知道这个方向值不值得继续。

这是 AI 时代一个很容易被忽略的错位：开发速度确实变快了，但用户价值的验证速度不会自动一起变快。你写代码的时间被压缩了，不代表你理解用户和市场的时间也被压缩了。

早期选题不能只看“酷不酷”，还得看“能不能很快得到真实反馈”。

我现在会很在意这些信号：

• 第一版做出来后，有没有人愿意试
• 试过以后，有没有人愿意反复用
• 他到底在哪一步卡住
• 哪个功能根本不重要
• 这个项目解决的问题到底成不成立

相反，那些特别依赖长周期积累、复杂运营配合、海量数据沉淀或者外部资源整合的项目，往往不适合当成快速起步的方向。它们有价值，但验证节奏太慢，撑不住早期阶段的消耗。

做项目最怕的不是暂时慢一点，而是你忙了很久，却始终没有进入真实反馈回路。那时候你看起来一直在做事，实际上只是一直在自己的判断里打转。

很多“专业感”其实来得太早了，项目不是设计出来的，是迭代出来的

项目刚开始时，很容易有一种冲动：架构一次定好，流程一次理顺，权限一次做全，扩展性一次想透。

这种冲动不难理解，但问题是，项目最早期掌握的信息，通常根本不支撑你做这么多最终决定。

于是就会出现一些很常见的早期过度建设：

• 功能还没上线，抽象先做了三层
• 用户还没来，权限模型已经设计了八种角色
• 业务规则还没稳定，配置系统先造出来了
• 主路径还没验证，扩展性已经铺满了

这些东西看起来很专业，实际却是在为一个还不存在的未来提前买单。

AI 还会把这种错觉进一步放大。它太擅长生成“像样的完整结构”了。目录、分层、领域对象、后台页面、管理台，甚至一套权限体系，它都能很快给你摆出来。问题是，完整感不等于正确性，生成得快也不代表你已经把问题想清楚了。

我现在更接受一种更笨、但往往更稳的推进方式：

先做最小可用闭环，让它跑起来；
先让真实用户碰到它，再看哪里别扭；
等问题真的出现，再重构、再抽象、再分层。

拒绝的不是设计，是过早设计。

很多后来看起来顺手的结构，都是第二轮、第三轮被真实问题逼出来的，第一天根本想不明白。

比起先列功能清单，我现在更愿意先把主交互路径想清楚

我现在做新项目时，会比以前更早地去想页面和交互，目的是尽快把主路径想清楚，视觉完整倒是其次。

因为对大多数项目来说，用户实际感受到的就是用起来顺不顺，架构好坏他根本无感。

他第一眼看到什么，接下来该点哪里，能不能在最短路径内完成关键动作，哪一步最容易困惑、退出、放弃，这些东西经常比“系统里一共有多少功能”更早决定一个项目有没有价值。

所以我现在更喜欢先问：

这个系统最关键的动作链路是什么？

比如工具类产品，很可能是“输入 -> 处理 -> 查看结果”；
比如内容类产品，很可能是“浏览 -> 筛选 -> 消费 -> 留存”；
比如后台系统，多数就是“录入 -> 查询 -> 处理 -> 追踪”。

主路径一旦定下来，页面、按钮、状态、接口、异常提示都会更容易收拢。反过来，如果一开始先列一大堆功能，项目很容易长成另一种样子：页面不少，功能很多，但用户不知道这个系统最重要的动作到底是什么。

AI 很适合帮你快速画页面、写组件、搭原型。这个阶段我也会大量用它。但“这条交互到底在服务什么目标”这件事，我现在不会交给它拍板。因为页面不是摆设，交互也不是装饰，它们本质上是在帮用户完成某个任务。

数据库这一步，最好还是自己亲自收口

这件事我现在很坚持。

前端页面、接口代码、脚手架、测试样例，这些很多都可以放心让 AI 先起草。第一版不完美，后面通常还能比较便宜地改。

数据库不一样。

表一旦进入真实使用，后面的修改成本会陡然上升。字段语义、约束边界、关系稳定性、历史兼容、查询路径、更新路径，这些东西都会开始带历史包袱。

如果这一步只是让 AI 随手生成几个表，先把项目推起来，后面大概率会碰到这些问题：

• 字段命名混乱，语义不统一
• 一张表塞了太多责任
• 关联关系模糊，查询越来越别扭
• 状态字段设计草率，业务一变就兼容不了
• 看着能用，但一重构就牵一发而动全身

所以我不是反对 AI 参与数据库设计。它当然可以帮忙列方案、补字段、检查范式、生成 migration。问题是，最后那一下收口，最好还是自己来做。

因为有几个问题，最终只能由你来回答：

• 这个实体在业务上到底是什么
• 它和别的实体是什么关系
• 哪些字段是核心事实，哪些只是衍生视图
• 状态流转边界到底在哪里
• 后面最可能沿着什么方向演化

项目早期，代码写错了通常还能补救；表设计错了，后面经常只能带着历史包袱往前挪。

AI 时代最容易出现的幻觉，是你一直在优化，所以以为自己一直在推进

这几年我开始警惕一种很强的错觉：因为 AI 把“继续优化一下”变得太容易了，所以人很容易把打磨误当成推进。

你可以不断让它：

• 再美化一下界面
• 再重构一下代码
• 再抽象一下结构
• 再补几个边界情况
• 再加一版更完整的权限模型
• 再做一个更通用的方案

这些动作都不一定错。问题在于，如果项目还没有进入真实世界，它们很可能只是围着一个未经验证的假设反复打磨。

项目早期最稀缺的，很多时候就是“先把它交出去”的决心。

第一版最重要的任务是出现。优秀留给后面。它要尽快进入真实环境，接受真实反馈，把问题暴露出来。只有完成，后面的完善才有意义；如果一直没有完成，很多优化都只是想象中的优化。

所以我现在会反复提醒自己一件事：先把主路径打通，先把第一版交出去，先让反馈进来。

优雅、抽象、完整、扩展，这些都重要。但它们更适合建立在一个已经能运行、能使用、能验证的东西上，而不是建立在项目开头那种“我先把一切想完整”的冲动上。

回头看这几个项目

AI 时代变快的，其实是“从一个想法到一个可验证版本”的距离，写代码只是其中一小段。

距离一缩短，真正重要的问题反而更显出来了。你有没有把精力留给高判断密度的地方，你有没有把项目收进一个可验证的问题里，你有没有先打通主路径再谈完善，你有没有在最该亲自收口的地方把判断握在自己手里。

AI 当然是一个很强的执行助手，我现在也离不开它。只是我不太愿意把它理解成替我做决定的人。

它适合负责加速。
但方向、取舍、边界和验证节奏，最后还是得由人来定。

这可能才是我现在最相信的一种项目构建方式：把低价值摩擦交给 AI，把高价值判断留给自己。先把东西做出来，再让它慢慢变好。