AI写代码：为何有人做玩具，有人做产品？

随着大模型能力的持续进化，越来越多人加入了 Web Coding（用 AI 写代码做产品）的阵营。无论你之前是不是技术出身，都可以通过与 Claude Code、Codex 这类 AI 工具协作，做出属于自己的工具或产品。

但一个耐人寻味的现象是：同样是让 AI 帮忙写软件，有人产出的只是一次能跑、二次崩溃的「玩具」，有人却能做出可持续迭代的生产级产品。 差距到底在哪？据 B 站创作者分享的实战经验，答案往往不在模型强弱，而在于「第一步」怎么走。

两种截然不同的AI编程提问方式

很多没写过代码的朋友，第一次打开 AI 窗口时会脱口而出：「帮我做一个任务管理系统」「帮我做一个博客系统」。在如今模型能力极强的情况下，AI 确实能给你生成一堆代码，甚至真的能跑起来。

但问题在于——这种项目往往是「抽卡」式的结果。同一个需求，换个模型、换个时间点，有时做得好，有时做得一塌糊涂。更关键的是，这样生成的项目通常没有清晰的架构，AI 会把文件随意散落在各处，缺乏规范的工程组织。最终你得到的，只是一个「毕业设计级别的 Demo」。

AI在没有框架约束下生成的代码往往缺乏工程规范

另一种思维方式则完全不同：先定框架，再让 AI 往框架里填功能。 这样得到的才是真正可用于生产的程序。换句话说，Web Coding 的第一步不是「让 AI 做什么」，而是「先选好语言和框架」。

为什么「先选框架」是AI编程的关键第一步

这其实和传统软件开发是一个道理。专业程序员做项目从来不是从 Hello World 一行行手搓，而是基于成熟框架起步，安装现成的路由、中间件等组件，然后在此基础上迭代业务逻辑。

作者建议的选型顺序是这样的：

第一步：选开发语言

先明确你要做的是什么类型的应用——是网页、桌面客户端，还是后端服务？不同场景对应不同的合适语言。语言的选择决定了整个技术栈的走向。

第二步：选框架

语言确定后，每种语言都有各自适用的框架：有的框架擅长做前端网站，有的适合做 App，有的专注后端 API。选定框架后再让 AI 干活，相当于你给 AI 提供了一个稳固的「地基」，而不是让它从零搭架子。

框架为AI编程带来的四大核心价值

作者系统地总结了框架带来的四大价值，这也是「玩具」和「产品」的分水岭：

1. 约定项目目录结构。 框架会规定文件应该放在哪里，避免 AI 把代码零散地丢得到处都是，保证工程的可维护性。

框架约定了清晰的项目目录结构

2. 提供标准化抽象层。 框架通常内置 ORM、中间件、依赖注入等能力。以 ORM 为例，它让你用写程序的方式读写数据库，而不必直接在代码里手写 SQL 语句，既安全又优雅。

3. 内置工程化能力。 数据库迁移、测试框架、应用打包管理等一整套工程实践，都是成熟框架的标配。这些正是产品级软件与玩具的本质区别。

4. AI 对主流框架天然熟悉。 这一点在 AI 时代尤为重要。AI 在训练时不仅学习了各种编程语言，还大量吸收了优秀开源框架的代码。因此 AI「出生时」就对这些知名框架非常熟练。用社区繁荣、生态成熟的框架，AI 写起来会更游刃有余，出错率也更低。

ORM（对象关系映射） 是理解第二点「标准化抽象层」的关键概念。ORM 是一种编程技术，它在面向对象的编程语言与关系型数据库之间建立映射桥梁。有了 ORM，开发者可以像操作普通对象一样操作数据库中的数据，例如直接写 user.save() 而无需手写 INSERT INTO users ... 这样的 SQL 语句。主流框架内置的 ORM（如 Django 的 ORM、Rails 的 ActiveRecord、Laravel 的 Eloquent）不仅提高了开发效率，还能有效防止 SQL 注入等安全漏洞。数据库迁移（Migration） 同样值得一提：它是一种版本控制数据库结构变更的机制，允许团队以可追溯、可回滚的方式管理数据库表结构的演化，而不是直接在数据库里手动改表——这正是生产级项目与 Demo 项目在工程规范上的典型差距之一。

如何科学地为AI编程选择框架

面对满屏的技术选型表格，不懂技术的人容易犯难。作者给出的建议非常务实：在动手前，先和 AI 开诚布公地聊。

把你的需求和技术背景全部告诉AI

把你的业务需求、你个人的技术能力、你对技术栈的了解，全都告诉 AI。AI 会基于这些信息，为你量身定制一套适合的技术栈。这样，你的第一句话就不再是「帮我做一个博客系统」，而是「用某某技术帮我实现某某功能」——目标明确，落地精准。

除了咨询 AI，选框架时还有几个客观维度值得关注：

Star 数：反映社区认可度；
代码提交频率：判断项目是否还在活跃维护；
Issue 数量与活跃度：看社区讨论是否繁荣。

通过多维度数据交叉判断，才能选出一个真正成熟可靠的框架。

完整的 Web Coding 工作流

作者提炼出了一套清晰的AI编程协作流程：

花时间和 AI 一起选框架、做技术选型；
初始化项目；
定义数据模型和程序流程；
让 AI 基于约定生成正确代码，放到正确目录；
验证结果、跑测试，然后循环迭代。

其核心原则一句话概括：你负责架构和方向，AI 负责实现和填充。

框架并非万能：三种例外情况

有意思的是，框架优先并不是铁律。作者也指出了几种可以「直接干活」的场景：

其一，一次性的简单任务。 比如做个数据处理脚本，明显是用完即弃的活儿，就没必要一上来就搞架构。

其二，尊重团队的技术熟悉度。 如果你本身是 Java 工程师，就没必要盲目追求别的技术；前端出身就用 Node.js。你熟悉哪个，哪个就是最好的，不必迷信「某语言性能更强」。

选择你最熟悉的技术栈就是最好的选择

实战案例：用AI搭建个人网站的完整过程

作者以自己最近做的个人网站为例。他并没有直接说「帮我做一个个人网站」，而是：

把 Obsidian 里的文档内容交给 AI；
告诉 AI 自己偏好的技术栈和设计风格；
AI 分析后建议用静态网站生成器来开发；
作者又把喜欢的 UI 库 shadcn 的链接发给 AI；
最终 AI 基于 shadcn 和现有内容，初始化出网站框架，再通过持续沟通迭代完成。

这个流程完美印证了「先框架、再 Coding」的理念。

静态网站生成器（Static Site Generator，SSG） 是此案例中的关键技术选型。与传统动态网站每次请求都需要服务器实时查询数据库、渲染页面不同，SSG 在构建阶段就将所有页面预先生成为纯 HTML 文件，部署后直接由 CDN 分发。这使得网站加载速度极快、安全性高、几乎零运维成本，非常适合内容更新频率不高的个人网站、博客、文档站。常见的 SSG 框架包括 Next.js（React 生态）、Astro、Hugo、Jekyll 等。shadcn/ui 是一个基于 Radix UI 和 Tailwind CSS 构建的组件库，与传统组件库不同，它采用「复制代码到本地」而非作为依赖包安装的方式，让开发者完全拥有组件代码的所有权，方便按需定制。由于 shadcn 在开源社区拥有极高人气，AI 对其组件 API 和用法也相当熟悉，是当前 AI 辅助前端开发的热门选择。

结语：AI 是放大器，框架决定放大方向

最后，作者用一句话总结了整个方法论的精髓：

AI 是我们的放大器。框架决定了它是放大你的工程能力，还是放大你的混乱。

对于每一个想用 AI 做产品的人来说，与其急着让 AI「帮我做个什么系统」，不如先停下来，花点时间和 AI 一起把框架和方向想清楚。这一步的投入，恰恰是玩具与产品之间那道看不见却决定性的分水岭。