这个系列写到第三期，我不想再重复“什么是 vibe coding”——前两期已经把基本概念和工具操作讲过了。真正让我想写这一期的，是上个月发生的一件事。
一个做运营的朋友用 AI 工具花了一个下午，做出一个“会议纪要转待办清单”的小页面。他兴奋地截图给我看，然后问了一个问题：“我现在算会编程了吗？”
我盯着这个问题想了很久。严格说，他不算会传统意义上的编程——他不会读每一行代码的含义，遇到报错主要靠截图问 AI。但他确实做出了一个能用的工具。这个状态听起来很美，但里面藏着一个很容易被忽略的真相：vibe coding 降低了“写出代码”的门槛，却没有降低“做出可靠产品”的门槛。它只是把难度从“怎么写”转移到了“怎么描述、怎么验证、怎么控制边界”。
这一期，我想把这件事拆开讲清楚。
1. 先搞清楚 vibe coding 真正改变了什么
1.1 从“手写每一行”到“描述你想要什么”
Vibe coding 的核心变化，是人和代码之间的关系变了。
传统开发流程里，程序员要理解每一行代码在做什么。变量、函数、循环、条件判断、状态管理，所有这些都要在脑子里形成一个模型，才能把一个功能写出来。这是一个“从内到外”的过程——先理解，再输出。
Vibe coding 把这个过程反转了。你不再需要先理解每一行代码才能让它工作。你只需要描述目标，AI 帮你把目标翻译成代码。你站在“需求侧”，AI 站在“实现侧”。你给出方向、反馈、调整，它负责写出具体内容。
但注意，“不需要先理解每一行”不等于“完全不需要理解”。这句话的真实含义是：你不需要从底层语法学起，但你需要理解“这一段代码大致在做什么”“这个改动会影响哪一块”“这个报错大概是哪一层的问题”。前者叫编程能力，后者叫工程判断力。vibe coding 降低的是前者的起步成本，没有替代后者的养成过程。
1.2 它真正解决的问题是“需求转代码”的翻译成本
过去几十年，编程领域一直在做一件事：降低从想法到代码的翻译成本。
最早的编程需要懂汇编指令，后来高级语言出现了，人可以写更接近自然语言的代码；再后来，框架和库出现了，很多重复劳动被封装起来；然后是低代码平台，把常见功能做成可拖拽的组件。
Vibe coding 是这条路上的一个新台阶。它把“翻译”这件事本身交给了大模型——你说中文，它生成 JavaScript、Python、TypeScript，或者直接生成一个可部署的页面。从这个角度看，vibe coding 真正降低的不是“代码难度”，而是“从想法到可运行原型的时间成本”。
这个区别很重要，因为它决定了你怎么用这个工具。
如果你理解成“我不用学编程了”，你会在第一个复杂需求面前撞墙。但如果你理解成“我把写第一版的时间从几天压缩到几十分钟，接下来要把更多时间花在验证和修改上”，那你就找到了正确的使用姿势。
2. 小白上手前，先建立一个正确的心理模型
2.1 把 AI 当成“一个上手很快但容易忘事的实习生”
这个类比可以贯穿整个使用过程。
你给实习生安排任务时，不会只说一句“帮我做个网站”就转身离开。你会告诉他：这个网站给谁用、要有什么核心功能、有哪些页面、用什么风格、数据从哪来、出错了怎么办。你还会让他先做一版，你看完再改。
Vibe coding 里，AI 就是那个实习生。它知识面很广，生成速度快，但它不了解你的项目背景，也记不住你两小时前说的每一句话。它可能理解错需求，可能用了一个不合适的库，可能把错误处理写得很草率——像实习生一样，需要你把需求说清楚，需要你检查它的输出，需要你告诉它哪里不对。
把 AI 当“实习生”还有一个重要含义：你不会让实习生在没有监督的情况下直接上线生产系统。同样，你也不应该让 AI 生成的代码在没有检查的情况下直接部署。
2.2 小白最容易犯的三个认知错误
第一，把 vibe coding 当成“许愿池”。以为描述得越好，AI 就能越神奇地直接给你一个完美产品。实际上，AI 擅长的是“分步实现”，不是“一次性凭空造物”。期望越高，失望越大。
第二，一上来就做太复杂的项目。很多小白第一次写需求就描述一个“像淘宝一样的购物平台”，AI 确实能生成很多代码，但这些代码大概率是拼凑出来的骨架，跑起来漏洞百出，而且你自己根本看不懂，后续修改无从下手。
第三，不检查、不测试、生成完就直接用。AI 生成的代码可能有逻辑错误，可能有安全隐患，可能依赖了某个版本容易变化的库。当你把它当“实习生”而不是“神”时，你就自然会去检查。
2.3 一个适合小白的心理模型：先跑通，再完善，最后才谈发布
Vibe coding 最大的价值是压缩了“第一版”的产出时间。所以你要用好这个节奏：
- 第一版：目标不是完美，而是“能跑”。生成一个可以打开、可以操作的最小版本。
- 第二版：让它处理真正的数据。把你的真实文件、真实输入喂进去，看结果对不对。
- 第三版：补边界。用户输错了怎么办，数据量大了怎么办，页面刷新后状态还在不在。
- 第四版：才考虑发布给别人用。
绝大部分 vibe coding 翻车，都是因为把第一版和第二版合并，甚至直接跳到第四版。
3. 从零到第一个小工具：一条不会翻车的操作路径
3.1 环境准备：不需要从装编译器开始
很多小白卡在第一步的原因，是以为 vibe coding 也需要先装一堆开发环境。其实是反过来的——vibe coding 的第一步，恰恰是让你先不碰环境，直接在浏览器里完成原型。
常见的做法有两种，它们适合的阶段不同：
| 方式 | 优点 | 适合阶段 | 需要什么 |
|---|---|---|---|
| 在线 AI 开发平台 | 零安装、打开网页就能用、生成后直接预览 | 验证想法、做小工具、做页面原型 | 浏览器 + 账号 |
| 本地 AI 编程工具 | 和本地文件深度交互、适合长期迭代项目 | 已有可运行原型后继续深入开发 | 安装编辑器 + 基本运行环境（如 Node.js 或 Python） |
这里有一个判断标准：如果你只是想做一个小页面、一个小工具、一个原型展示，先用在线平台；如果你要做的是一个需要长期迭代、和你的电脑文件深度交互的项目，那就要切换到本地工具。
3.2 用“需求卡”替代“一句话描述”
小白在描述需求时最常见的问题，是过于笼统。比如：
- 笼统版：“帮我做一个记账软件。”
- 合理版：“做一个网页版的记账工具。用户能输入每笔消费的金额、类别和日期，页面显示所有记录的列表，并自动算出本月总支出。数据保存在浏览器本地，不需要登录。界面用简洁的卡片风格。”
区别在哪里？合理版给出了四样东西：目标、输入、输出、边界约束。这就是“需求卡”的核心要素。
我在给新手建议时，一般会让对方先写一张需求卡：
| 字段 | 要写清楚什么 | 示例 |
|---|---|---|
| 一句话目标 | 这个东西是给谁用的，解决什么问题 | 给自己做一个网页版记账工具 |
| 核心功能 | 列出 2 到 3 个最重要的功能，不要超过 5 个 | 记一笔、看列表、算总数 |
| 输入示例 | 用户会输入什么，格式是什么 | 金额数字、类别下拉框、日期选择器 |
| 输出示例 | 预期看到什么结果 | 列表按日期倒序，顶部显示总金额 |
| 边界约束 | 不需要做什么、有什么限制 | 不需要登录，不需要云端同步，数据只存浏览器 |
这张卡不用写很长，但写完之后，你给 AI 的描述就有了完整的骨架。你会发现，AI 的生成质量会明显提升——因为它不再需要猜你的需求。
一个小技巧：把这张需求卡保存在一个文本文件里，每次开启新对话时都可以重新粘贴给它。这就是最简单的“项目记忆”。
3.3 一个可复用的三轮迭代模板
生成完第一版后，不要急着加新功能。按照下面三轮来检查和推进：
第一轮，验证“能不能跑”。运行起来，点击一下，看有没有报错。有报错就把完整错误信息贴回给 AI，让它修复。
第二轮，验证“对不对”。用你自己的真实数据操作一遍。比如记账工具，你输入几笔真实的消费，看它算的总支出对不对。不对就指出具体问题，让 AI 修正逻辑。
第三轮，验证“边界”。故意给一些异常输入：金额填负数、日期为空、快速连续点击按钮。看程序会怎么反应。不要期待这一步做得完美，但你要知道现在系统最脆弱的地方在哪里。
记住这个顺序，不要反过来。很多人一拿到第一版就急着加酷炫功能，结果核心逻辑还没验证，后面越改越乱。
4. 真正的分水岭：需求拆解和上下文管理
4.1 为什么 AI“记不住”你说过的话
这是小白最容易困惑的地方：明明我一开始就跟它说了项目背景，为什么聊到后面它又忘了？
原因是，AI 对话有上下文长度限制。你聊得太久，早期内容会被截断或压缩。这不完全是因为平台限制，更可能是因为大模型处理文本时，会优先关注最近的内容。这和人很像——你今天早上跟同事说过的话，到了下午开会时，对方可能也需要你重新提醒一遍重点。
所以，管理上下文不是技术问题，是你的工作习惯问题。
4.2 学会把大需求拆成“一小时内能完成”的小步骤
一个复杂的项目，如果一次性让 AI 生成，它会输出一大堆代码。这些代码之间是否一致、是否能协同工作，很多时候完全没有保障。
更稳的做法，是拆成小块，一块一块地完成。比如做一个记账工具，可以拆成：
- 第一步：做出页面框架，能显示一个空的消费列表。
- 第二步：加一个“添加消费”的表单，提交后列表里多一条数据。
- 第三步：加金额统计，自动算总数。
- 第四步：加本地保存，刷新页面数据不丢。
- 第五步：加删除和编辑功能。
每一块，都是一个独立的“本轮任务”。每一轮完成后停下来，验证一下，再进入下一轮。
这样做的原因有两个。第一，每一轮的任务越聚焦，AI 生成的代码越准确，出错的概率越低。第二，当某个环节出了问题，你能很快定位——问题是这一轮引入的，而不是一个无法定位的大杂烩。
4.3 用“项目说明文件”对抗上下文丢失
我推荐小白在项目文件夹里维护两个文件：
第一个叫project.md（项目说明）。里面写清楚：项目是做什么的、目标用户是谁、核心功能有哪些、用了什么技术栈、目前的完成进度、已经确认的交互方式。每完成一个重要功能，就更新一下。
第二个叫progress.md（进度记录）。里面写清楚：今天完成了什么、改了哪几个文件、遇到了什么问题、下一步要做什么。不必写长篇大论，bullet point 就够。
然后，每次开启新对话时，把这两个文件的内容粘贴给 AI，再说一句“这是项目目前的状态，我们继续下面这个任务：……”。
你可能会觉得麻烦，但这恰恰是大项目能持续开发的关键。AI 对话没有持久记忆，你的文件就是它的记忆。
5. 平台怎么选：Vercel AI 这类工具的定位与边界
5.1 选平台看四个维度
很多小白会问：“我到底该用哪个工具？”我的建议是，不要纠结于哪家最强，而是看四个维度：
- 生成能力：它能生成什么类型的代码？网页、接口、完整应用，还是只写代码片段？
- 运行反馈：生成之后能不能立刻预览、立刻测试？还是一个代码块扔给你自己跑？
- 部署路径：做出来的东西怎么给别人看？是平台自带发布，还是要自己搞服务器？
- 使用成本：免费额度够不够，付费之后值不值得，有没有隐形成本，比如每次对话都在消耗积分。
这四个维度没有绝对的优劣，只有是否匹配你的场景。
5.2 Vercel AI 平台适合做什么
Vercel AI 这一类平台，本质上更偏向“从描述到可部署界面”。你描述一个页面或功能，它生成代码，并且提供预览和部署能力。它解决的不只是“写代码”，而是“把代码变成可以访问的产物”。
常见用法是：
- 做一个产品落地页或官网原型。
- 做一个交互式表单或数据展示工具。
- 快速验证一个产品想法，做出来的东西可以直接分享链接给朋友看。
- 前端界面原型先行，后续再交给专业开发者继续深化。
但要注意它的边界。这类平台通常更适合前端、界面、交互原型类任务。如果你要做的是复杂后端逻辑、大量数据处理、特殊算法、需要特定云服务集成的商业系统，那就不能用“描述一下”的期望来完成，你需要真正的代码能力来做底层的调度和调试。
另外，用这类平台生成的代码，依然要理解它部署到了哪里、数据存到了哪里、免费额度和配额是怎么计算的。这些越早知道越好，不要等做出一个“爆款工具”后才发现额度不够用了。
5.3 鸿蒙场景下的 vibe coding：先确认工具链，再谈效率
“鸿蒙 vibe coding”这个方向，最近关注度在上升。从直觉上看，AI 辅助开发对鸿蒙开发者肯定有帮助，尤其是 ArkTS/ArkUI 这类相对较新的技术栈，很多开发者需要快速查阅最佳实践、生成组件代码。
但我的建议是：在鸿蒙这个特定生态里，vibe coding 的成熟度会比 Web 开发领域低一些。原因不难理解：AI 模型生成的质量，取决于它见过多少对应代码。Web 开发有海量开源代码可供训练，而鸿蒙应用开发的开源样本和社区示例相对少。所以你在鸿蒙场景下用 vibe coding，生成结果可能不如 Web 场景稳定。
这不是说不能用，而是说你要调整预期：
- 先用小段代码、单个组件做验证，不要一上来就让它生成整个页面或整个应用。
- 官方的开发文档和示例仓库仍然是最可靠的材料，AI 生成的代码要和官方文档对照着看。
- 遇到编译报错，优先看官方错误码和社区问题记录，AI 可能不一定了解鸿蒙编译器的所有细节。
- 把 AI 当作“快速生成骨架和示例”的辅助，把官方文档当作“验证标准”。
这套方法，其实也适用于任何“新框架 + AI 辅助”的组合。
6. 从“能跑”到“能长期用”：需要补的工程课
6.1 单次跑通，只能说明流程没断
不少人的项目死在同一个地方：开发的时候一切正常，过了几天再打开，跑不起来了。或者功能能用，但数据保存到一半就出错了。
原因可能有很多：依赖版本变化了、某个服务接口失效了、当时 AI 生成的代码本身就没有考虑异常恢复。这些问题的共性，是没有把“能跑”变成“可靠”。
6.2 四件事必须补上
如果你的项目打算用超过一个月，或者打算给身边人用，下面四件事就不能省。
第一，日志。别把你的程序当成黑盒。至少要让程序在关键时刻输出一条记录，比如“数据已保存”“请求失败，原因是……”。出问题时，这条记录就是你找到线索的地方。
第二，敏感信息保护。不要把密码、密钥、访问令牌写死在代码里。写死之后，一旦代码公开，你的账号就等于暴露了。这个习惯要从第一天开始培养。
第三，异常处理。不要假设用户永远输入正确的内容。程序要能处理“输入为空”“格式不对”“请求失败”“存储空间不足”这类常见异常。至少，让它报错时给出一个人类能看懂的提示，而不是白屏或崩溃。
第四，版本记录。学会用 git 或最简单的版本工具。每次完成一个功能，就提交一次。这样当后来改坏了，你可以退回去。不需要学得很深，会提交和回滚就够了。
6.3 一遇到问题，按这个顺序排查
我总结了一个适合 vibe coding 新手的排查链路：
- 先看现象：程序是报错、白屏、没反应，还是结果不对？把现象原原本本写下来。
- 再看输入：你给 AI 的描述，或者你喂给程序的数据，格式对不对、字段全不全？
- 再看环境：运行环境有没有变化？依赖装了吗？版本对吗？端口被占用了吗？
- 再看参数：代码里的配置、路径、模型名、超时时间、并发数，和你的实际环境一致吗？
- 最后看工具边界：这个平台或模型，是不是本来就不支持你现在的用法？
遇到问题的时候，不要急着重新生成一遍，先按这个顺序走一遍，通常能解决大部分问题。剩下的，再考虑是把这个 bug 描述给 AI 让它修，还是去查官方文档。
7. 什么人适合 vibe coding，什么场景要谨慎
7.1 不同类型用户的使用策略
Vibe coding 不是一个人人都适合的工具，它是一条有边界的技术路径。
适合的人：
- 产品经理、运营、设计师，想快速验证想法、做原型。
- 编程初学者，想通过做真实的小工具来建立对代码的直觉。
- 独立开发者，想快速把多个想法变成可测试的 MVP。
- 有一定代码经验的人，用 AI 做脚手架生成、常见模板生成，提高起步速度。
不太适合的人：
- 完全不想检查、不想理解、不想维护的人。只要“能出来就行”，遇到问题就换一个工具重做，这样永远无法积累可用的项目。
- 需要处理大量复杂业务逻辑、高并发、强一致性的系统级项目，这类项目不能靠 vibe coding 主导，它的价值在于辅助，而不是替代。
- 在意每一行代码质量和长期架构的人，在正式的生产代码里，纯 vibe coding 产出的代码通常还需要人工审查和重构。
7.2 一个可复用的判断框架：四问法
在开始一个项目之前，问自己四个问题：
- 这个项目需要长期维护吗？如果只是临时一次性原型，放心 vibe coding；如果要用一年，就要在早期补工程化流程。
- 这个项目涉及的领域，AI 见过足够多的示例吗？Web 页面、常见工具、数据处理，AI 很熟；一个高度专业、代码样本极少的业务系统，AI 的效果就难说。
- 出了安全问题，承担得起吗？涉及用户个人信息、支付、权限控制的系统，必须先有专业审查，不能只靠 vibe coding。
- 你自己愿意学习最基本的排查和验证方法吗？如果不愿意，项目做再大也是空中楼阁。
这四个问题，比“哪家 AI 更强”更值得花时间思考。
7.3 长期价值：vibe coding 是新的起点，不是终点
最后，回到开头那个问题：“我现在算会编程了吗？”
我的答案是：你学会了用工具做出东西，这和传统意义上的“会编程”不完全一样，但它同样有真实价值。你完成了从“有想法”到“有产物”的跨越，这已经超过了大多数人。
但如果你想让这种能力持续生长，下一步不是继续找更智能的工具，而是补三样东西：
- 最基本的代码阅读能力。不要求你手写，但至少能看懂 AI 生成的代码大致在做什么。
- 最基本的项目组织能力。会用文件记录需求、进度和问题，会做版本管理。
- 最基本的验证和测试习惯。每改一步，就跑一遍，确认没有破坏别的地方。
这三样能力，不会因为你用了 AI 就消失，恰恰相反，它们会让你的 AI 用得更好。
Vibe coding 不是编程的反义词，它是你和代码之间的一种新协作方式。工具负责“写”，你负责“想”——而“想”这件事，永远无法外包。
