获课：shanxueit.com/13015/

第一步：用大白话描述"要什么"

我从一个最宽泛的提示开始："帮我做一个网页工具，左侧是一个输入框，我把文字贴进去点保存，它就会出现在右侧的列表里，按时间倒序排列，每条记录可以加标签和删除。"

AI 给出了初版代码——一个单页 HTML，所有数据存在 localStorage 里。界面很简陋，但核心逻辑完整。我把它打开，试了几条数据，确实能跑通。这时我没有急着往后走，而是停下来真实使用它两天，把所有不舒服的地方随手记下来：标签是手动输入的，每次都要重复打字；删除操作没有二次确认，误删了一条重要记录；列表不支持搜索，历史数据一多就翻不过来。

第二步：把"不舒服"翻译成指令

第二轮开发的核心原则是"只说问题，不提方案"。我不需要告诉 AI 用正则提取关键词或用 IndexedDB 做索引，我只需要表达痛点：

"标签能不能自动从文字里提取高频词？删除按钮加一个二次确认弹窗，另外列表顶部加一个搜索框，只筛选包含关键词的记录。"

AI 生成了新的代码版本，这一次改动明显更有架构感——它主动引入了简单的中文分词逻辑来提取标签候选，搜索框也做了防抖处理。最让我惊喜的是，它居然保留了之前所有的 localStorage 数据结构，新旧数据无缝兼容。我没有告诉它要兼容，它自己读懂了上下文。

这个阶段我反复进行了三轮"使用-吐槽-迭代"。每次改动范围都不大，但体验的提升是指数级的。第三轮我提出"希望每条记录可以编辑内容，而不是删掉重建"，AI 给出了双击进入编辑态的交互，并且自动处理了焦点管理和保存快捷键。

第三步：卡壳时刻与"人肉 debug"

当然，整个过程并非一路顺滑。最头疼的一次是样式问题——在 Chrome 上一切正常，但在微信内置浏览器里，右侧列表在滚动时会出现大面积空白。我不懂 CSS 的兼容性陷阱，于是把现象描述给 AI："在微信浏览器里滚动会闪白，其他浏览器正常。"

AI 给出的第一个修复方案是加 -webkit-overflow-scrolling: touch，无效。我继续反馈"还是闪白"，它又建议用 transform: translateZ(0) 开启硬件加速，依然无效。我差点放弃，准备去网上搜答案。但转念一想，我把"闪白"换成更精确的描述"滚动时整个容器重绘了"，AI 立刻意识到是 overflow 和 position 的层叠上下文冲突，给出了 isolation: isolate 的解决方案——这次终于生效了。

这段经历让我意识到一个关键点：Vibe Coding 并不省掉 debug 过程，省掉的是"实现"过程，但"诊断"依然要靠你。你对问题的描述越精确，AI 解决得就越快。

第四步：部署与收尾

功能稳定后，我让 AI 帮我写一个一键部署到 Vercel 的脚本，并自动配置环境变量。整个部署过程在 15 分钟内完成，唯一的手动操作是注册了一个域名。

从第一个提示到正式上线，总计耗时 4 个晚上，每个晚上约 2 小时。同样的功能如果按传统方式开发，保守估计需要两周。更关键的是，我在整个过程中学到的不是某个具体的 API 语法，而是一种把想法翻译成结构化的能力——这比记住任何框架都要持久。

复盘：Vibe Coding 真正改变了什么

这次实战让我对 Vibe Coding 有了清晰的认识。它的本质不是"让 AI 替你写代码"，而是把开发者的角色从"实现者"变成了"架构师和产品经理"。你不再需要记住函数名和参数顺序，但你需要比以往更清楚自己要什么、什么好用、什么出了问题。

它也有明显的边界。我做的应用足够简单，不需要复杂的并发控制、权限体系和分布式缓存。如果换成需要精细性能调优或安全审计的系统，AI 的局限性会迅速暴露——它不是替你绕过难题，而是替你加速那些"你已经知道该怎么做但懒得亲手写"的部分。

最后想给想尝试 Vibe Coding 的朋友三个建议：第一，从"为了自己用"开始，因为你最清楚痛点在哪里；第二，持续对话而不是一次性提完所有需求，每一步都在上一个版本的基础上生长；第三，接受粗糙，先上线再迭代，完美是交付最大的敌人。

这个小工具至今还在我的浏览器里每天使用着。它没有复杂的架构图，没有漂亮的代码注释，但它完成了它该做的事，并且只用了不到五个晚上——这在两年前，是我完全不敢想象的事情。