这个系列写到第三期我不想再重复“什么是 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 不是编程的反义词它是你和代码之间的一种新协作方式。工具负责“写”你负责“想”——而“想”这件事永远无法外包。