AI 编程，怎么从玩具到产品？
最近帮朋友看了几个用 AI 做的项目，发现一个有意思的现象：
代码能跑，功能也有，但就是...不能用。
不是技术问题，是别的问题。
图：文章配图
一个典型的场景
朋友兴冲冲地发来一个链接："你看我用 AI 做的，三小时搞定！"
打开一看：
- 页面是有的，圆角卡片、渐变按钮、紫色配色——一眼 AI 味
- 登录功能点了没反应
- 数据是写死的假数据
- 只能在他电脑上跑
我问："这个怎么给用户用？"
他愣了一下："...还没想到那一步。"
这不是个例。我观察了很多用 AI 做的项目，发现大部分都卡在同一个地方：从 demo 到产品的鸿沟。
vibe coding 的五个坑
仔细分析这些项目，问题可以归结为五个：
1. 需求是个谜
"帮我做一个任务管理应用"——这是大多数人给 AI 的提示词。
问题是，AI 不知道：
- 任务要不要分优先级？
- 要不要支持多人协作？
- 数据存本地还是云端？
- 要不要提醒功能？
AI 只能猜。猜对了是运气，猜错了就是返工。
本质问题：没有 Spec 思维。需求不清晰，AI 再聪明也白搭。
2. UI 一眼假
为什么 AI 生成的界面总有一种说不出的"AI 味"？
- 圆角用得太多太大
- 渐变色滥用
- 紫色 + 蓝色的万年配色
- 布局千篇一律
不是 AI 不会设计，是你没告诉它什么是好设计。
本质问题：缺乏设计规范。AI 只是在模仿它见过的"平均水平"。
3. 后端是空的
前端页面做得再漂亮，点击登录按钮——没反应。
因为：
- 没有用户系统
- 没有数据库
- 没有 API 接口
- 没有服务器
很多人以为 AI 编程就是做前端页面。但一个能用的产品，后端才是大头。
本质问题：不懂架构选型。不知道用什么技术栈，干脆就不做了。
4. 部署是玄学
代码写完了，然后呢？
- 域名怎么买？
- HTTPS 怎么配？
- 服务器怎么选？
- 数据库怎么部署？
对于没有运维经验的人，这些问题每一个都是拦路虎。
本质问题：不了解部署。代码能跑和产品能用是两回事。
5. 改一行崩全部
好不容易跑起来了，想加个小功能。
改了一行代码，整个项目报错。
AI 生成的代码往往是"一次性"的——能跑，但不能改。因为：
- 没有模块化
- 没有类型检查
- 没有测试
- 到处是硬编码
本质问题：缺乏工程化。代码是写给机器跑的，不是给人维护的。
怎么破？
分析完问题，解决思路就清晰了。下面是我总结的五个具体方法：
方法 1：先写 Spec，再写代码
我之前写过一篇关于 Kiro Spec 工作流的文章，核心观点是：
vibe coding 最大的问题是：它让开发变成了"碰运气"，而不是"可控的工程"。
解决方案是在让 AI 写代码之前，先让它帮你梳理需求。具体来说，生成三个文件：
- requirements.md —— 需求文档（用 EARS 语法写用户故事和验收标准）
- design.md —— 技术方案（架构、流程、注意事项）
- tasks.md —— 任务清单（todolist，便于跟踪）
这和大厂的研发流程、敏捷开发的拆解方式如出一辙，但 Kiro 把它和 AI IDE 深度结合，极大提升了落地效率。
什么是 EARS 需求语法？
EARS（简易需求语法）最早用于喷气发动机控制系统，后来被软件工程广泛采用。它用简单句式约束需求，避免"模糊表达"：
| 类型 | 句式 | 示例 |
|---|---|---|
| 普遍性 | The system shall... | 系统应当支持用户登录 |
| 事件驱动 | When [trigger], the system shall... | 当用户点击登录按钮，系统应当验证凭证 |
| 状态驱动 | While [state], the system shall... | 当用户已登录时，系统应当显示用户头像 |
| 可选功能 | Where [feature], the system shall... | 如果启用了双因素认证，系统应当发送验证码 |
| 复杂条件 | If [condition], then the system shall... | 如果密码错误超过 3 次，系统应当锁定账户 |
需求清晰了，AI 才能精准输出。
怎么在其他 AI IDE 里用？
即使没有 Kiro，其他 AI IDE 也能复刻这套流程：
- Claude Code：在项目下建立
CLAUDE.md，写入 Spec 工作流规则 - Cursor：使用
.cursor/rules/project.mdc - Augment：使用
.augment-guidelines
整个流程下来，AI 不再是"黑箱"式地帮你生成代码，而是和你像搭档一样，步步确认、逐步推进。
方法 2：用 Skill 约束 AI 的设计输出
不要让 AI 自由发挥，给它一套设计规范。
这里介绍一个概念：Skill（技能）。
Skill 是一种可复用的提示词模板，封装了特定领域的专业知识。比如 Anthropic 官方开源的 frontend-design Skill，专门用来解决"AI 味"问题：
有了这个 Skill，AI 生成的 UI 就不会那么"AI 味"了。
方法 3：选 BaaS，不要从零搭
后端是大多数人的拦路虎。但其实不需要自己搭。
什么是 BaaS？
BaaS（Backend as a Service）是一种云服务模式，把后端能力封装成 API，开发者只需调用 SDK：
| 能力 | 传统方式 | BaaS 方式 |
|---|---|---|
| 数据库 | 安装 MySQL，配置连接，写 SQL | 调用 db.collection('users').add() |
| 用户系统 | 写注册/登录/权限逻辑 | 调用 auth.signIn() |
| 文件存储 | 搭建 OSS，配置权限 | 调用 storage.upload() |
| API 接口 | 写 Express/Nest.js 路由 | 云函数自动生成 HTTP 端点 |
这比自己用 Express/Nest.js 从零搭建简单 10 倍。
国内外主流 BaaS 平台：
- 国外：Supabase、Firebase
- 国内：CloudBase（腾讯云开发）
BaaS 的核心理念是：开箱即用。创建项目时，数据库、认证、存储就已经准备好了，不需要你操心底层基础设施。
方法 4：用平台托管，不碰服务器
部署也不需要自己折腾。
现在有很多平台可以帮你搞定部署：
| 平台类型 | 代表产品 | 特点 |
|---|---|---|
| 静态托管 | Vercel、Netlify、Cloudflare Pages | 前端项目一键部署，自动 HTTPS |
| Serverless | AWS Lambda、Cloudflare Workers | 函数即服务，按调用计费 |
| BaaS 全栈 | CloudBase、Supabase、Firebase | 前后端一体，数据库+函数+托管 |
| 容器平台 | Railway、Render、Fly.io | 支持任意语言，更灵活 |
如果你用的是 BaaS 平台（比如 CloudBase），部署就更简单了——前端静态托管、后端云函数、数据库，都在一个平台里，不用到处开账号。
把代码推上去，平台自动帮你搞定一切。
方法 5：工程化思维
让 AI 生成代码时，要求它：
| 要求 | 具体做法 |
|---|---|
| 模块化 | 一个文件做一件事，职责清晰 |
| 类型化 | 用 TypeScript，类型即文档 |
| 可测试 | 关键逻辑有单元测试 |
| 可配置 | 环境变量、配置文件，不要硬编码 |
这样生成的代码才能维护和迭代。
我的实践
说了这么多方法，我自己是怎么做的呢？
经过一段时间的摸索，我沉淀出一套方案，把上面五个方法整合在一起：
1. Spec 工作流 — 每次开始一个项目，先让 AI 帮我生成 requirements.md → design.md → tasks.md。需求清晰了，后面写代码就顺了。
2. Skill 技能体系 — 整理了一套设计规范，封装成 Skill。每次生成 UI 时调用，就不会有 AI 味了。
3. BaaS 架构 — 后端用云开发平台，不碰服务器。数据库、云函数、用户登录、文件存储——都是现成的。
4. MCP 协议 — 用 MCP 让 AI 直接调用云服务。创建数据库、部署函数、配置域名——都不用手动操作了。
这套方案我打包成了 CloudBase AI Toolkit，开源在 GitHub。
写在最后
vibe coding 不是不能用，而是只能用来做 demo。
从 demo 到产品，需要的不是更强的 AI，而是工程化的思维：
- 需求要清晰（Spec 工作流）
- 设计要规范（Skill 技能体系）
- 架构要合理（BaaS 服务）
- 开发要智能（MCP 协议）
- 代码要可维护（工程化）
AI 是工具，但工具需要正确的使用方式。
就像有了电钻，不代表人人都能做木工。关键是你知道怎么用，用在哪里。
记住：AI 不是替代人，而是让人更强大。
如果你也有 AI 编程的实践经验，欢迎交流。