Vibe Coding 实战：我用自然语言写出了一个能上线的小程序
平台：掘金 字数：约3000字 系列：技术实践 / AI编程
上周我用 Vibe Coding 做了一个真实项目：给公司做了一个内部报修小程序，提交工单 + 处理人认领 + 状态推送，三个页面。
从需求确认到可以在微信开发者工具里跑起来，我用了不到 4 小时。
以前做这种东西要多久？以前我估过工时：前端 2 天，联调 1 天，测试半天，共计 3.5 天。
这不是我在夸 AI。4 小时里有 1 小时在解决 Taro 的一个老版本兼容问题，有半小时在改 AI 生成的一段糊涂逻辑。但就算扣掉这些，纯粹在"写"代码的时间只有不到 1 小时。
什么是 Vibe Coding
2025 年 2 月，Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 负责人）在 X 上发了一条帖子：
"完全顺应感觉，拥抱指数级增长的 AI，甚至不再看代码。"
他把这种编程方式叫做 Vibe Coding——你描述意图，AI 生成代码，你只负责确认结果。
这个词今年成了柯林斯词典的年度词汇，搜索量涨了 6700%。但大多数讨论还停在"到底算不算编程"的争论里。
我觉得这个问题不重要，有没有用才是正题。
我的实战过程（附真实提示词）
项目背景
公司办公室设备报修一直是群里@运维，运维看到了回一句"知道了"，然后可能下午才来处理，没有任何跟踪记录。做一个轻量报修小程序，能解决这个问题。
第一步：用自然语言描述整个系统
我在 Cursor 里打开一个空文件夹，然后对 AI 说：
我要用 Taro + React 做一个微信小程序，功能是内部报修系统。
功能需求：
1. 报修页面：员工填写设备位置、问题描述、联系人，提交后生成工单
2. 工单列表页：按状态（待处理/处理中/已完成）分组显示，运维可以认领
3. 状态详情页：显示工单详情，支持更新状态和备注
技术约束：
- 用 Taro 4.x，React 18
- 样式用 NutUI
- 数据先用本地 mock，后续替换成接口
先帮我生成项目结构、页面路由配置和三个页面的基础框架。
生成结果不是完美的，但骨架基本对。Taro 的 app.config.ts 里路由配置有一处格式错误，手动改了 5 行。
第二步：逐页面深化
框架搭好后，我分页面推进。以报修页面为例，我的提示词：
完善 repair-form 页面：
- 表单字段：位置（下拉选择，选项：1楼/2楼/3楼/4楼）、设备类型（空调/投影仪/网络设备/其他）、问题描述（文本域，最多200字）、联系电话（校验格式）
- 提交时本地生成工单ID（格式：WX+日期+4位随机数），存入 localStorage
- 提交成功后跳转工单列表页，并高亮新提交的工单
- NutUI 组件：Form, Input, TextArea, Picker, Button
- 加入表单校验，必填字段未填时要有提示
这一步 AI 给出的代码量大概 200 行，能直接跑起来，只有一个地方的 Picker 组件用法和当前版本的 NutUI 不一致，改了不到 10 行。
第三步：真正花时间的地方
是工单列表页的状态分组逻辑。AI 生成的初版代码是这样的：
const grouped = orders.reduce((acc, order) => {
const status = order.status || 'pending'
acc[status] = acc[status] || []
acc[status].push(order)
return acc
}, {})
乍看没问题，但我要求的是按 pending/processing/done 显示三个固定 Tab，空状态也要显示，不能因为某类为空就消失。这段逻辑不能处理这种情况。
我把这个问题直接告诉 AI，它秒改。这种来回一般不超过 2 轮。
规律： AI 在"生成完整结构"上很强，在"理解业务边界"上需要你说清楚。你越清楚自己要什么，它越省事。
Vibe Coding 的实际工作流
整理下来就这几步：
1. 建立项目上下文
在项目根目录放一个 .context.md，写清楚：技术栈版本、项目背景、已有约定、不能动的地方。这个文件每次 Cursor 打开时会自动加载进上下文。
# 项目上下文
## 技术栈
- Taro 4.0.7
- React 18
- NutUI 3.x（注意：部分组件API和4.x不同，不要用4.x的用法）
- TypeScript
## 项目结构
- src/pages 存放页面
- src/components 存放可复用组件
- src/utils 存放工具函数
## 约定
- 所有页面组件用函数组件 + hooks
- 样式文件命名：同目录下 index.less
- 不使用 class 组件
没有这个文件，AI 写出来的代码经常和你现有的风格冲突。
2. 分层描述需求
不要一次性把所有需求倒给 AI。按照"结构 → 页面 → 交互 → 边界"四层推进：
- 结构层：项目架构、路由、主要数据模型
- 页面层：每个页面的基础布局和组件
- 交互层：具体的用户操作和状态变化
- 边界层：异常处理、边界条件、空状态
每层都确认完了再往下走。
3. Review 每个关键逻辑
我有个习惯：涉及数据存储、状态变更、API 调用的代码，AI 生成后我都会看一遍。不是逐行看，是看逻辑的主干对不对。10 分钟的 Review 能省掉很多莫名其妙的 Bug。
三个容易踩的坑
坑一：版本幻觉
AI 对库的版本敏感度不够高。你用的是 Taro 4，它可能给你 Taro 3 的语法。解决方法：在上下文里明确写版本，碰到组件问题先看官方文档对应版本，再告诉 AI"这个用法已经废弃了，新的是 xxx"。
坑二：重复生成
让 AI 一次生成太多内容，容易看漏问题。我现在的习惯是每次只让它处理一个页面或一个功能模块，生成后确认了再继续。
坑三：当甩手掌柜
有些开发者真的把 Review 省了，全量接受 AI 的代码，然后觉得"能跑就行"。这类代码隐患很多：边界条件没处理、日志满天飞、TypeScript 类型全是 any。
Vibe Coding 的"快"不代表可以不懂代码。只是以前你要写代码，现在你要 Review 代码。这个职责没有消失。
现在用 Vibe Coding 能做什么
以我自己的实测为准：
| 场景 | 效率提升 | 适合度 |
|---|---|---|
| 内部工具小程序 | 5x | ★★★★★ |
| 数据看板页面 | 4x | ★★★★★ |
| API 封装 + 类型定义 | 3x | ★★★★☆ |
| 复杂业务逻辑 | 2x | ★★★☆☆ |
| 老项目重构 | 1.5x | ★★★☆☆ |
内部工具是最适合 Vibe Coding 的场景，原因是需求清晰、技术栈稳定、对代码质量要求不至于极端苛刻。
最后说一句
Karpathy 在今年 4 月的访谈里说，Vibe Coding 只是"抬高了地板"，真正的战场已经移到 Agentic Engineering（智能体工程）了。他承认自己作为程序员"从未感到如此落后"。
这句话值得认真对待。Vibe Coding 不是终点，只是一个新的起点。技术的天花板没有降低，只是入场门槛变了。
如果你做过 Vibe Coding 实战，评论区说说你遇到了什么问题，或者哪个场景效果让你印象深刻。
