Appearance
第一个 Vibe Coding 项目
用一个 Todo App 把 Vibe Coding 的工作节奏跑一遍。不追求代码完美,目标是感受"描述→生成→验证→继续描述"这个循环。
你需要准备什么
- 装好 Cursor(cursor.com 下载)
- 一个空文件夹
- 大概 30 分钟
不需要提前搭环境,让 AI 帮你决定用什么技术栈。
第一步:描述你想要什么
打开 Cursor,按 Cmd+I(Mac)或 Ctrl+I(Windows)打开 Agent 面板,输入:
帮我创建一个 Todo App。要求:
- 可以添加新任务
- 可以标记任务完成
- 可以删除任务
- 用 React,不需要后端,数据存 localStorage你不需要告诉它用什么组件库、文件怎么组织、状态怎么管理。这些交给它决定。
等它生成完,你会看到它创建了若干文件,并告诉你怎么运行。按照指示运行项目。
第二步:运行并验证
运行起来之后,做三件事:
- 添加一个任务,看它有没有出现在列表里
- 标记完成,看样式有没有变化
- 刷新页面,看数据有没有丢失
如果这三件事都正常,基础功能跑通了。不需要去读代码,先确认行为正确。
如果出了错,把错误信息复制到 Cursor 里,描述你看到的现象:
运行 npm start 之后,浏览器控制台报错:
TypeError: Cannot read properties of undefined (reading 'map')
刷新页面时出现。让它修复,再跑一次。这是正常的迭代,不是说明你做错了什么。
第三步:继续往下描述
基础功能跑通之后,加一个新需求:
给任务加上优先级,分三级:高、中、低。
添加任务时可以选择优先级,列表里用不同颜色标注。
高优先级排在最前面。注意这里的描述方式:不是"加一个 priority 字段",而是直接描述用户看到的行为。AI 会处理实现细节。
生成之后,重复验证步骤:添加不同优先级的任务,看排序和颜色是否符合预期。
第四步:加一个更复杂的需求
优先级功能跑通后,再加一步,感受任务变复杂时怎么描述:
给任务加上截止日期。要求:
- 添加任务时可以选填截止日期
- 列表里在任务名称旁边显示截止日期(格式:MM/DD)
- 今天截止的任务用橙色高亮
- 已过期但未完成的任务用红色高亮这个需求比之前的更细——你给了颜色规则、格式要求、条件判断。这正是描述得越具体、AI 生成越准确的体现。
如果 AI 生成后某个颜色判断不对,不要直接去改代码,先这样描述:
已过期任务没有显示红色,我测试了一个昨天截止的未完成任务,
颜色没变化。日期判断可能有问题,帮我修复。从你观察到的行为出发,让 AI 自己找到代码里哪里的逻辑有问题。
这个过程里你在做什么
你在做三件事:描述需求、验证结果、判断是否继续。
你没有在做的事:决定代码怎么写、选择具体的 API、处理实现细节。
这就是 Vibe Coding 的角色分配。如果你发现自己开始想"它这里用 useState 不对,应该用 useReducer",那是你在用习惯的方式工作,不是在用这套节奏工作。除非你发现结果不对,否则先不要去改实现细节。
怎么描述需求才有效
通过这几步练习,你大概已经感受到描述方式很重要。几个实用规则:
从用户行为出发,不从技术实现出发
不好的描述:给 Todo 对象加一个 dueDate 字段,类型是 Date
好的描述:添加任务时可以选填截止日期,显示格式是 MM/DD
前者告诉 AI 怎么实现,但如果你的判断不对,AI 就会照错误的方向走。后者描述你想看到的结果,AI 会自己决定数据结构。
给足条件,不要只给"支持 XX 功能"
不好的描述:支持任务过滤
好的描述:在列表上方加三个 Tab:全部、进行中、已完成。点击对应 Tab 只显示该状态的任务
条件越具体,AI 需要猜测的地方就越少。
出问题时描述现象,不要描述猜测
不好的描述:我觉得是 state 更新的问题,帮我看一下 useState
好的描述:添加任务后列表没有刷新。我点击添加按钮,任务名称框清空了,但列表没有变化。刷新页面后任务出现了
AI 很难从"我觉得是 XXX 问题"出发,但它能从"我做了 A,期望看到 B,实际看到 C"精准定位。
常见卡点
AI 生成的代码跑不起来
先不要自己改,把完整的错误信息给它,描述你做了什么操作,它通常能修复。如果连续修了两三次还是不行,可以让它重新用不同方案实现这个功能:
这个方案一直有问题,帮我换一种实现方式,
不用 X 库,改用原生 Y 来实现同样的功能不知道怎么描述下一步需求
想一下"用户会做什么操作",从用户行为出发描述,比从技术角度描述更容易得到准确的结果。
生成的代码量很大,不知道该不该读
先不要读,先运行,先验证行为。行为对了,不需要立刻读完每一行。等你需要改这部分代码的时候再读,效率更高。
改一个地方,另一个地方坏了
这在 AI 辅助编程里很常见。把两个问题分开描述:先描述你看到的新问题,让 AI 修复,再检查之前的功能是否还正常。不要在一次对话里同时修多个问题。
跑完这个项目你学到了什么
不是 React,不是 localStorage API,而是这套工作节奏:
- 把目标描述清楚
- 让 AI 生成完整方案
- 验证行为,不先读代码
- 出问题时描述现象,而不是猜实现
- 跑通后继续描述下一步
这个循环在更复杂的项目里结构完全一样,只是任务拆解和上下文管理会更讲究。
下一步是 Cursor 深度使用,了解 Chat / Edit / Agent 三种模式的区别,以及如何通过 Rules 和 Context 控制让 AI 更准确地理解你的意图。