Vibe Coding 这个概念第一次听的时候，很多人以为又是某个社区为了热度造出来的新词。但真正用过一段时间之后，你会发现它其实描述了一种和以前完全不一样的写代码方式：你把自己的意图、偏好、甚至是一种“感觉”用自然语言丢给 AI 模型，然后让模型去生成、修改、维护代码，你再以审阅和验收者的身份介入。说得直接一点，以前我们是“写代码的人”，现在更像是“给代码下需求的人”。
这篇文章我会从 Vibe Coding 到底是什么讲起，再把国内外主流工具路线做个横向拆解，然后重点聊聊我实际踩过的坑、总结出的方法和适合普通程序员的上手路径。如果你正在纠结要不要拥抱这个方向，或者已经在用但总觉得效率不够高，这篇文章应该能给你一些参考答案。
1. Vibe Coding 是什么：概念本质与范式转变
1.1 一个词背后的三个层次
“Vibe Coding”字面意思是“跟着感觉编码”。很多人把这个词理解成随缘写代码，那太片面了。从我自己的实践来看，这个词其实包含了三个递进的层次：
第一层是“工具形态”的变化。代码编辑器不再是单纯的文本编辑器，而是变成了一个对话界面。你可以用自然语言描述需求、补充说明、纠正错误，这些指令不再需要符合某种严格的语法规范，模型会自动把它们转换成代码。这一层是最直观的变化。
第二层是“协作方式”的变化。你不再是独自面对一个空窗口，而是和一个具备大量知识背景的 AI 模型协作。它负责生成骨架、重复代码、样板逻辑，你负责定义方向、审查正确性、把关边界条件。这一层是角色分工的变化。
第三层是“思维模式”的变化。以前写代码必须先想清楚数据结构、接口设计、异常路径，然后一步步敲进去。Vibe Coding 允许你先用模糊的语言描述“我想要一个什么东西”，让模型把想法变成可运行的原型，再通过不断反馈让它逼近真正的需求。这种“从模糊到清晰”的工作流，才是这个理念真正革命性的地方。
我见过不少开发者把 Vibe Coding 等同于“用 AI 写代码”，这个理解不能说错，但会错过它的核心价值。真正会用的人，不是在偷懒，而是在用一种更高效的方式把“想法”快速变成“代码”，再用自己的判断力把它打磨成稳定、可维护的产品。
1.2 为什么是“Vibe”而不是“Specification”
技术圈里其实早就存在“规范先行”的开发方法，先写详细设计文档，再按文档编码。那为什么不叫“Specification Coding”呢？这里面有几个很微妙但非常重要的原因。
第一，现实中的需求往往是模糊的。产品的初始想法通常是“我想做一个能根据用户历史的点击推荐内容的系统”，这句话在传统开发流程里需要被拆解成几十个具体的技术文档，然后才能开工。而 Vibe Coding 允许你先把这个模糊想法原封不动丢给模型，让它先给你一个粗糙版本，你看到了具体的东西之后，再继续提出“这里改一下”“那个逻辑不对”之类的反馈。这种方式更符合人类大脑真实的工作方式：我们很多时候是“看到才想起”，而不是“想好再看到”。
第二，Vibe 这个词强调“氛围感”和“整体性”。在设计一个用户界面的时候，你可以说“长得要很极简，留白多一些，有点苹果官网的感觉”，这种描述在传统开发流程里几乎没有意义，但在 Vibe Coding 中很有意义。模型已经见过海量的界面设计，能够把你的风格期望转换成对应的 CSS、组件结构甚至视觉参数。这不是规范文档能做到的事情，因为“感觉”这种东西很难被形式化描述。
第三，Vibe Coding 的核心理解在于“模糊的正确优于精确的错误”。传统编程追求精确，人类的意图一旦被形式化成错误的规格说明，最后做出来的东西会很离谱。Vibe Coding 反而鼓励你在一开始保持模糊，通过和模型的快速反馈循环，逐步收敛到正确的目标。这种方式大幅降低了前期规划的成本，也难怪很多独立开发者和小团队会这么热衷它。
1.3 关注点转移：从“怎么实现”到“实现什么”
这套理念带来的一个直接结果，就是程序员的核心关注点被迫发生位移。
以前我们花大量时间研究“这个功能怎么实现”：如何解析这份数据、如何设计数据库表、如何处理边界条件。Vibe Coding 出现之后，模型已经能够处理大部分“怎么实现”的细节，哪怕它生成的代码不完美，至少能在一个较高起点上开始工作。这就逼着开发者把精力转移到了更上游的地方：“我们到底要做什么”“这样设计是否合理”“用户的真实诉求是什么”。
举一个我在实际项目中遇到的例子。某跨平台系统需要一个文件上传模块，我用传统方式写，需要考虑文件读取、分片、上传进度、断点续传、失败重试、安全校验，前前后后大概需要两三天才能稳定。换成 Vibe Coding 之后，我直接告诉编辑器里的模型“帮我写一个支持分片上传的前端模块，要求显示进度条、失败自动重试，用当前项目的技术栈”，十分钟之后就拿到了一个能跑的版本。之后我只做了一件事：检查它的逻辑，发现它在文件类型校验上不够严格，于是我追加了一条需求“加一个白名单校验，且优先判断扩展名和文件头是否匹配”。
这个过程里，我的注意力几乎全部集中在“需求定义”和“验收确认”上，而不是那些重复且机械的实现细节。这件事让我意识到，Vibe Coding 不是让程序员变得懒惰，而是把程序员从“打字姿势的熟练工”变成“需求工程和代码质量的把关人”。
2. 国内外主流路线：工具生态与最优解拆解
2.1 国际阵营的典型路线
海外工具的发展路线，总体上是沿着“深度集成编辑器”的方向走的。这个路线有几个非常鲜明的特点。
第一个特点是“存在感必须低”。好的国际阵营工具会嵌在编辑器里，你不需要在浏览器和 IDE 之间来回切换，通过快捷键呼出对话面板，一边看代码一边聊天。它的位置就在你的上下文旁边，选中的代码可以直接进对话，生成的代码可以直接落盘。这种极低的使用摩擦，是它们能被高频使用的关键原因。
第二个特点是“上下文感知能力”很强。这类工具会读取当前打开的文件、局域网内的相关模块、甚至整个项目的结构索引。你在对话里说“这个函数为啥总报错”，它能精准定位到当前函数，而不是泛泛地回答。推动这个特性的背后是这个思路：AI 编程的成败，很大程度上取决于模型对上下文的利用能力，而国际主流编辑器显然把重心压在“如何自动构建高质量的上下文”上。
第三个特点是“多文件联动”越来越成熟。早期的 AI 辅助只能改一个文件，项目稍大就废了。现在的头部方案已经支持让模型在多个文件之间做修改和联动，比如新增一个 API 之后，自动更新类型定义、调用端、测试文件。这已经非常接近“初级工程师”的完整工作范围，而不单单是一个自动补全工具了。
如果你把国际市场的主流工具拉出来对比，会发现它们在底层模型迭代上并没有拉开质差距，真正的胜负手在工程化能力：响应延迟、并发稳定性、代码索引准确度、以及是否能跟现有的代码评审流程无缝衔接。选择这类工具的关键词，我总结为“编辑器深度整合 + 项目级上下文 + 多文件协作”。
2.2 国内阵营的典型路线
国内工具的路线和国际同行有明显区别。它们往往不是从编辑器插件切入，而是从“独立的对话式开发平台”切入。
这种平台通常以 Web 页面或独立客户端的形式存在，你新建一个项目后，把需求描述给它，它会像一位远程协作者一样生成整套工程结构，包括前端页面、后端接口、数据库配置。它的工作模式更接近“你提需求，我交付整个版本”的项目外包形态，而不是“坐在你旁边，帮你改这一行代码”的结对编程形态。
国内工具的另一个特点是强于“中文理解”和“场景适配”。很多中文表达里的细腻语义、行业术语、甚至是不同区域的互联网产品习惯，它们处理起来会更顺手。比如你说“要做一个有点年轻化的小红书风格社区”，它们能理解你要的不是一个普通论坛，而是有着种草逻辑、图文卡片、兴趣标签分类的社区产品。这种理解力在纯英文语料训练出来的模型上，往往会差一些。
第三个特点是“落地链路更重”。很多国内平台并不满足于只帮你写代码，还会帮你把部署、上线、运维的流程一并收进来，搭建所谓“从需求到上线一条龙”的能力。对于不懂太多工程概念的初学者来说，这种设计确实很友好，你只需要表达想法，平台帮你搞定从代码到服务的整个过程。
综合来看，国内外的产品路线并没有绝对的谁优谁劣，它们的选择和发展差异是由用户结构决定的。国际阵营的核心用户们比较习惯已有工程化流程，所以工具的定位是被嵌进现有流程里的“超级工作者”；国内的核心用户里，有很大一部分是小团队、创业者、非专业开发者，他们真正需要的不是工具，而是做完事的服务，所以平台的形态自然更重更完整。
2.3 如何选型：几个实际判断标准
关于选型，我给不出“用哪个一定最好”的简单答案，因为这类工具迭代太快，今天的最优解可能下个月就过时。但我总结了四个判断标准，你可以照着套：
第一，看它跟你的工作流合不合拍。如果你已经有很成熟的 Git 分支模型和代码评审流程，那么一个“只修改你选中代码”的低侵入工具，往往比全自动生成一堆代码的平台更适合你。反过来，如果你是从零搭一个快速原型，或者你的团队没有严格的工程规范，那一个能生成完整项目的独立平台反而提升更快。
第二，看它的上下文能力上限。别只看演示视频，你要实际造一个大型项目，丢给它一个跨模块的小需求，看它能不能准确定位到相关文件。很多工具在 demo 项目上表现完美，一放到真实的生产级代码库里就“找不到北”，这是因为它的上下文管理能力不足以应对大量代码文件。
第三，看它的收费模式和隐私边界。现在的主流方案基本都是订阅制，有的按 token 计费，有的按会员计费，这会直接影响你的使用频率。对比的时候别只看单价，还要把“你能承受多少次回复消耗”算进去。隐私这块特别重要，涉及商业机密的项目，务必确认工具是否支持私有化部署，或者至少有严格的数据脱敏机制。
第四，看它产出的代码质量能不能被你控制。好的工具应该支持“约束输入”，比如提供自定义指令、禁用某些依赖、指定代码风格。如果这个工具输出什么你就得用什么，那你在长期项目里一定会被它的坏习惯恶心到。
提示：选型最忌讳“脑补试用”。建议把三类典型任务（新项目生成、现有项目改 bug、跨模块重构）分别测试一遍，再花一整天实际写业务，真实体感会比任何榜单都有说服力。
3. 从概念到落地：Vibe Coding 的实操方法和踩坑记录
3.1 新项目的正确启动姿势
我见过不少人用 Vibe Coding 做新项目，结果一小时就被搞崩溃。排查下来，大部分问题都出在“太急”上。他们拿到工具后第一件事就是丢一句话“帮我做一个电商系统”，然后期待模型像魔法一样变出一个完整产品。这是不可能的，甚至会得到一个结构混乱、技术栈混杂、完全没法演进的代码。
正确的启动姿势应该是分四步走。
第一步，明确技术栈和目录边界。在开始之前，要把“用什么框架、什么语言、什么构建工具、目录结构怎么规划”这些基础约束先想清楚，并把这些约束一并告诉模型。比如“用 React 和 TypeScript，使用当前最新的项目模板，页面组件放 src/pages，公共组件放 src/components”。这一步能极大程度避免模型给你生成一个想当然的项目结构。
第二步，先让模型生成“项目骨架”而不是“全部页面”。只需要一个能跑起来的空壳，包括路由框架、基础布局、状态管理、网络请求封装。这一步跑通了，后面的开发才有地基。
第三步，按“垂直切片”的方式逐页开发。每一次对话只做一个用户可感知的功能，比如“先做登录页，接一个 mock 接口，登录成功后跳转首页”。千万别一上来就铺开所有模块，那样上下文负担极重，模型越到后面越容易“精神错乱”。
第四步，在第一个切片开发完之后，立刻检查并建立“代码风格基线”。你可以让模型根据现有代码风格生成一份规范说明，也可以自己定几条规则，在后续的所有交互里反复强调。Vibe Coding 最容易被忽略的一个特点就是：模型是跟着你的每一次输入走，你留下的每个指令都会影响它后续的行为，所以一开始就把风格定好非常重要。
我用这个流程做过不少从零到一的产品原型，实测下来的体会是：前半小时花在搭骨架和定规范上的时间，会在后面节省至少三小时收拾烂摊子的时间。
3.2 Prompt 设计：怎么把需求说清楚
很多人在 Vibe Coding 里得不到理想结果，不是工具不行，而是不会好好说话。这里不是说你要会什么魔法咒语，而是要学会一套给 AI 下需求的结构化方法。
我把一个高质量的“AI 代码需求说明书”拆成五个要素：角色、任务、约束、输入、输出。
- 角色：让模型的视角先对齐。“你是一个有十年经验的资深前端工程师”，这种开场并不矫情，它真的能激活模型更有深度的回答模式。
- 任务：要用动词开头，一句话说清楚。“帮我实现一个用户注册表单”和“帮我分析一下这个页面的问题并给出修改方案”，任务一个偏执行一个偏分析，模型心态会完全不同。
- 约束：这是最容易被忽略的部分。你要主动把别人不知道的事情告诉它，比如“不用加国际化”“这个项目不兼容 IE 了”“数据库表结构不能动”“遵守现有目录结构”。约束越详细，越能避免模型自行发挥。
- 输入：把相关的代码、报错信息、截图描述都贴上去。别指望模型能像人一样主动翻你的项目找线索，它只有在看到具体材料时才能给出具体回答。
- 输出：明确你要的产出形态。“给我一份代码 diff”“直接改到当前文件里”“分步骤说明然后再给完整结果”。这个要素决定了模型是只动嘴还是真的动手。
这五要素听起来简单，但我发现大部分开发者在真实操作时总喜欢漏掉“约束”这个环节。他们默认模型“应该理解我的项目用的是什么技术栈”，但模型不是透视眼，它看不到你心里的假定版本。她会按照最通用的方式去生成代码，结果就是风格错位、依赖冲突、结构混乱。
3.3 迭代节奏与代码版本管理
Vibe Coding 的另一个大坑出现在“迭代节奏”上。
传统编码的速度，受到打字速度和思考速度的双重约束，所以我们对代码变更的频率有天然的生理感知。但 Vibe Coding 的迭代速度非常快，你一句话发出去，可能十秒钟就返回一整片代码改动。这种速度感会带来一种虚假的安全感：反正改得快，多试几次不就行了？
我踩过这个坑。某次重构一个某跨平台系统的权限模块，我连续让模型调整了五次方案，每一次都是“集成新的方案再推翻旧的方案”。第六次的时候，我发现代码里已经残留了前几轮不同方案的碎片逻辑，整个权限判断流程变得极其难读。
后来我给自己定了几条硬规矩：
第一，每次对话前，先明确本轮目标最多只改动一个关注点。比如“本轮只重构接口鉴权函数，不动调用方代码”。不要同时要求改多个模块，多点开花的结果往往是全线崩坏。
第二，每次改动落地之后，立刻做一个可运行验证。跑一下测试，开一下调试器，确认这个改动没破坏现有功能，再进行下一轮。千万不能让模型连续输出几十轮再回头看，那绝对是一场灾难。
第三，对每次有实质意义的改动，都手动创建一个 Git checkpoint。Vibe Coding 还有一个麻烦：当你让它“回退一下那个改动”时，它不会像 Git 那样精准回退到某个时间点，而是会生成一份“它认为修改前应该是这样”的代码。这种“幻觉式回退”极其危险。所以，任何关键节点都要用 Git 做真实保存，不要依赖模型自己的记忆。
我们团队后来定了一个约定：每次模型完成一轮有效改动，立刻运行测试并提交一个 commit，commit message 里附上“本次需求描述的关键短语”。这样即使后面模型折腾坏了，我们还能清晰地回退到任意版本，也可以复盘每次需求描述的质量。
3.4 踩坑清单：无效循环、幻觉代码与上下文丢失
光讲成功经验太片面，这里把我实际遇到的高频问题整理成一个速查表，你遇到同类问题可以直接对照。
| 常见问题 | 具体表现 | 我试过有效的解决办法 |
|---|---|---|
| 无效循环 | AI 不断修改同一个逻辑，每次改动只是换个写法，问题没解决 | 立刻切断当前对话，手动定位根因；再开新对话，带上根因分析让它一次改到位 |
| 幻觉代码 | 生成了看似合理但引用不存在的函数或依赖 | 在生成后跑一次编译或 lint，别放过任何报红；重要依赖让模型提供安装命令而不是直接引入 |
| 上下文丢失 | 对话长了之后，它忘了最初的架构约束 | 每做 5 次交互就主动总结“当前进度和剩余任务”，以文本形式重新粘到对话里，或直接新开一段对话 |
| 结构分裂 | 生成的新模块和现有模块风格、依赖版本格格不入 | 规定“新代码必须参考 src/utils 目录下现有文件的写法”；或在项目根目录放一份 style guide 让它遵守 |
| 逻辑正确但边界缺失 | 主流程对，异常处理、空值判断、并发问题全没有 | 在初始需求里强制加一句“请考虑所有边界条件和异常场景，并在代码注释里标明”；或专门用一轮对话让模型“攻击自己的代码找漏洞” |
| 死代码堆积 | 反复修改后，旧的被替换但残留片段仍然存在 | 定期让模型“检查并清理当前文件里没有引用的函数和状态”，再配合手动确认 |
其中“无效循环”是我遇到最耗费心力的问题。早期我特别容易陷入这种状态：让模型改，它改了，但它改的方式是换一种写法，测试还是不过。再改，再换一种写法，还是不过。整个过程消耗了几十次对话，毫无进展。
后来我改变策略，遇到这种僵局，先不跟模型纠缠。直接用调试工具定位到具体的错误点，然后打开一个新对话，把所有相关错误信息、调用栈、我自己的分析一起丢过去，让模型“先解释问题根因，再给出修改方案”。这一招把解决问题的成功率提高了非常多。核心逻辑是：模型跟人一样，在错误的上下文里容易陷入惯性思维，换个对话，等于让“新人”重新审视问题。
4. Vibe Coding 的程序员未来：生存还是进化
4.1 核心竞争力的位移：从编码能力到评审能力
每次 AI 技术有突破，都会有人喊“程序员要失业了”。我在这个行业待了这么多年，见过太多新技术带来的恐慌，但 Vibe Coding 带来的变化确实和以前不太一样。
以前我们说“会用搜索，懂点框架”就能在简历上加分，现在这些基础能力都在被 AI 快速抹平。一个会用 Vibe Coding 的新手，可以在几个小时内产出以前需要资深工程师花几天的页面原型。这种生产效率的提升是实实在在的。但在我看来，被抹平的是“手艺”，不是“内功”。
什么是手艺？知道某个语言的关键字语法、能背出某个框架的 API、会调某个库完成某个功能。这些能力在过去是吃饭的饭碗，但在 Vibe Coding 时代，模型对这些知识的掌握远超人脑。如果你只具备这类能力，确实会感受到生存压力。
什么是内功？面对一个模糊的业务问题，能抽丝剥茧地定义出真正需要解决的问题的能力。能读懂一段混乱的代码，定位到风险源头的能力。能在模型给出“看起来很合理”的答案时，识别出潜在性能陷阱和安全隐患的能力。能设计出清晰架构、让系统在演进中保持可控的能力。这些模型做起来非常困难，而它们恰恰是程序员的真正护城河。
我把这个转变叫做“从打字者到审稿人”。审稿人不需要亲手把每个句子写出来，但必须知道什么是好的文章，必须能一眼看出逻辑漏洞。未来程序员的日常节奏，很可能就是让模型写稿、自己审稿、指出问题、循环迭代。
4.2 哪些岗位受影响最大，哪些岗位反而升值
Vibe Coding 对不同岗位的冲击程度完全不同，这一点非常值得关注。
在冲击最大的名单里，首先是“只做重复性业务开发”的初级岗位。这类岗位的日常工作就是按照既定规范，写 CRUD 接口、套页面模板、实现没有太多复杂逻辑的业务功能。这些工作恰恰是 AI 模型最擅长的，它不但快，而且不容易犯低级拼写错误。如果这类岗位没有增加系统设计、架构评审、疑难问题排查的成分，确实会逐步被压缩。
其次是“外包型代码生产”模式。那种整天接需求、实现接口、交付代码的纯执行角色，也会受到很大影响。甲方提交需求给 AI，AI 生成代码，一个人可以完成多个人的工作量，甲方对单纯写代码岗位的需求自然下降。
反过来看，有几个方向的岗位正在升值。
第一是“系统架构与领域设计”岗位。AI 可以帮你写代码，但写一个模块跟设计一个可对话的系统是完全不同量级的问题。能把业务复杂性问题抽象成清晰模块边界的人，能指导 AI 逐块落地的人，价值会越来越高。
第二是“AI 应用工程化”岗位。Vibe Coding 并不是模型输入一句话就能大规模稳定运行，它需要有人做工具链、评估基准、代码审查自动化、模型回退策略。这些基础设施不会自己从天上掉下来，需要专业工程师去搭。
第三是“复杂遗留系统维护”岗位。老旧的业务系统往往有着几十年积累的坏味道、隐晦的命名、没有文档的业务约束，AI 模型面对这些历史包袱经常一筹莫展。能读懂技术债、在危险环境里小心翼翼做修改的工程师，是稀缺资源。
我的总体判断是：程序员不会消失，但“只会按教程敲代码的程序员”会逐渐被淘汰。真正留存下来的，是能够驾驭 AI、用更抽象方式去控制复杂系统的思考者。
4.3 面向未来的学习路径
说完了冲击和机会，再聊点实用的：如果你现在是一名程序员，该怎么调整自己的学习方向？
我根据自己的体会，列了一个新学习清单：
第一，把“系统设计基础”放回学习优先级的最前面。过去很多初级开发者养成了“先写代码再想架构”的习惯，因为反正代码是自己写的，塌了可以自己修。在 Vibe Coding 时代，AI 生成的代码往往能在局部快速工作，但全局结构如果不先想清楚，项目很快就会演化成一堆不可控的拼图。理解分层架构、事件驱动、领域建模这些概念，比多背几个 API 重要得多。
第二，锻炼“代码评审能力”。这是 Vibe Coding 时代最重要的新基本功。你可以从每天读自己写的旧代码开始，试着找出其中“为什么当时要这么写”的线索，再去看团队其他人的代码，练习快速识别坏味道。以后你主要的工作就是给 AI 写评审意见，那你要先能看出问题在哪。
第三，学会提问和表达。以前“沟通能力”这个词在程序员圈子里总被当成软技能，被很多人忽略。在 Vibe Coding 时代，表达清楚需求边界、能准确描述上下文、能讲清期望产出，直接决定了 AI 生成的代码质量。你提出的问题越清晰，得到的代码越接近你想要的东西。
第四，刻意练习“解耦和抽象”。让 AI 帮你写代码，很容易写出一大坨“面条代码”，因为模型天然倾向于把所有逻辑揉在一个函数里，这让它觉得更省事。渐渐你会发现，控制 Vibe Coding 的核心竞争力，其实是你对代码耦合度的嗅觉。多做小步重构、多练习把一个大函数拆成多个清晰小模块，这种品味是模型学不走的。
注意：不要系统性地用 AI 来逃避你不想学的基础知识。如果你完全不懂计算机网络、数据结构、操作系统，你连 AI 生成的路由配置哪里不安全都无从判断。越是依赖 AI 的时代，基础知识的底子反而越值得打牢，因为它是你判断能力的来源。
5. 我用 Vibe Coding 的真实体会与几条扩展思路
5.1 几种特别适合 Vibe Coding 的场景
Vibe Coding 不是万能的，我试过之后明确了它适合什么、不适合什么。
适合度最高的场景，是“探索型原型开发”。你脑子里有一个模糊的产品概念，但不确定用户体验好不好、信息架构合不合理，这时候 Vibe Coding 是无可替代的。你可以用十几分钟生成一个可点可点的原型，放进浏览器里真实感受，再决定要不要投入资源正式开发。这个反馈速度，以前只有资深团队配合复杂脚手架才能达到。
第二类适合场景，是“测试代码和脚本生成”。写单元测试是很多开发者的痛，给它一个接口定义，让模型生成各种边角测试用例，再手动补充特殊场景，效率提升非常明显。我做某图像处理 Demo 的时候，让模型一次性生成了十几组图像边界处理测试，它覆盖到的空值、尺寸溢出、通道不一致等场景，比我手写时能想到的还全。
第三类是“跨语言代码翻译”和“技术债解释”。遇到一段老到没人懂的历史代码，让模型用通俗语言解释逻辑，再生成“等价功能的新技术栈实现”，可以帮你节省大量考古时间。
不适合的场景也很典型：核心交易逻辑、安全敏感代码、性能极度敏感的底层逻辑。不是说 AI 不能处理这些，而是说出错成本太高的时候，你至少要保留完全掌控的能力，不能让模型在你没看懂的领域自由发挥。
5.2 一个我习惯使用的工作流
最后分享一个我目前比较稳定使用的工作流模板，不算权威，但至少帮我少踩了很多坑。
第一步是建立“项目宪法”。我会在项目根目录放一个 AI 可读的说明文件，里面写清楚技术栈、目录约定、命名风格、禁用的依赖、测试要求等。每次和模型对话时，第一句就让它先读这个文件，保证上下文对齐。
第二步是“小块迭代、及时验证、即时提交”。每轮只做一个小任务，做完立刻运行测试和 lint，通过就提交代码。这个不用多解释，前面已经讲透了。
第三步是“使用评审对话做反向检查”。代码生成后，我会专门开一段对话，把代码贴进去，告诉模型“请你以资深评审专家的身份，找这段代码里的 bug、安全隐患、性能问题和风格问题”。这个环节相当于给 AI 一个自我纠错的机会，往往能找出不少我在审稿时漏掉的问题。
第四步是“维护一个经验反馈库”。我会把每次让模型踩到的问题和对应的修正指令记录下来，形成一份自己的“AI 协作经验库”。以后再遇到同类场景，直接把这些反馈句子复制进对话里，让模型一上来就避开坑。这有点像训练一个属于自己的行为偏好集，是我觉得最值得长期投入的一件事。
5.3 往后可以怎样扩展
Vibe Coding 这个东西，现在还在早期。我可以看到几个大概率会持续演进的方向，也顺带说说我的感想。
首先是工具链会继续变得“上下文更强”。模型不再只是听你说几句话，它能自动去索引代码库、翻阅历史 commit、理解整个产品文档，甚至感知到当前代码和远端服务的运行状态。当模型拥有足够完整的上下文时，它能做的不只是写代码，还可能帮你做整个模块的技术方案设计。
其次是“多智能体协作”会浮出水面。一个模型负责前端，一个模型负责后端，还有个模型负责测试，它们在共享的上下文里协作完成一个完整功能。这听上去很科幻，但我已经看到一些原型产品在往这个方向做。你要做的不是管理代码，而是管理一群 AI 员工的产出和协作。
还有一块是“代码生成质量的度量”。当代码越来越依赖 AI 生成后，如何定义“好代码”会变成一个更紧迫的问题。那些能制定代码质量基线、能设计自动评估体系的人，会站在下一波浪潮的前沿。
我自己的心态也在慢慢调整。以前我会因为“代码不是自己亲手写的”而感到心虚，后来想通了：程序员从来不是靠手速挣钱的，靠的是发现问题和解决问题的能力。Vibe Coding 把我们从这个行业里最机械的那部分劳作中解放出来，变量更大了，挑战也更真实了。
有一个特别切身的体会：过去写一百行代码可能需要一小时，而且你会心疼它们沉没的时间成本。现在用 Vibe Coding，我可以很轻松地让 AI 生成五种实现方案，逐个看它们各自的取舍，再组合出最适合需求的那一段。这种“低成本试错”的自由度，是我这几年写代码以来最爽的一次体验升级。
如果让我给还在犹豫的人一句建议，那就是：别把它当玩具，也先别急着定义它是什么，动手用起来，用真实项目去感受它的边界和潜力。至少从我的经验看，这里面带给程序员的不是失业焦虑，而是一个重新梳理自身价值的机会。
