1. 从“写代码”到“聊代码”：vibe coding 到底改变了什么

第一次听到 vibe coding 这个词，我脑子里冒出来的画面是：一个人戴着耳机，跟着节奏敲键盘，代码像流水一样出来。后来真上手用了一段时间，才发现它说的不是“边听歌边写代码”这种表面状态，而是一种把 AI 当成结对搭档、用自然语言驱动开发流程的工作方式。你不再是从零开始一行行敲，而是先把自己的意图、约束、期望结果讲清楚，让 AI 生成第一版，然后你在这个基础上做判断、做修正、做取舍。

这件事对写代码的人来说，冲击是实打实的。以前我们讲“编程能力”，核心是语法熟练度、算法功底、调试经验。现在这些依然重要，但多了一层：你能不能把需求描述清楚，能不能判断 AI 给的方案哪里对、哪里不对，能不能在它跑偏的时候及时拉回来。我见过不少新手，用 AI 辅助编程之后上手速度明显变快，因为他们不用先花两周啃语法细节，而是直接从一个能跑起来的小项目开始，边做边补基础。也见过一些老手，一开始很排斥，觉得“AI 写的代码不可靠”，但试过之后发现，把重复性的 CRUD、样板代码、单元测试交给 AI，自己专注在架构设计和业务逻辑上，效率确实上来了。

vibe coding 的核心不是“让 AI 替你写代码”，而是把人的精力从机械劳动里解放出来，放到真正需要判断力的地方。它适合谁？我觉得三类人最值得试：一是刚入门、需要快速建立正反馈的新手；二是有经验、但被重复性工作拖住的老手；三是做独立项目、人手有限、需要一个人当三个人用的开发者。接下来我会从整体思路、核心细节、实操流程、常见问题几个角度，把我自己踩过的坑和总结出来的方法完整讲一遍。

2. 整体设计与思路拆解：为什么这样用 AI 才顺手

2.1 先想清楚：AI 是副驾驶，不是自动驾驶

很多人用 AI 辅助编程，第一步就错了：直接把一句“帮我写个电商网站”丢给 AI，然后等着它吐出一个完整项目。结果要么是生成一堆跑不起来的代码，要么是结构混乱、改都没法改。问题不在于 AI 能力不够，而在于你把本该自己做的决策全推给了它。

我的做法是：把任务拆到“一次对话能说清楚”的粒度。比如我要做一个用户登录功能，我不会说“帮我写登录”，而是会拆成：数据库表结构怎么设计、密码怎么加密存储、登录接口的输入输出是什么、异常情况怎么处理、前端怎么调用。每一块单独和 AI 对话，拿到结果后自己组装。这样做的好处是，每一段代码你都能看懂、能验证、能修改，而不是面对一个黑盒。

提示：AI 生成代码的质量，和你给它的上下文丰富度强相关。你给的信息越具体，它跑偏的概率越低。

2.2 工具选型：别追新，选顺手的

市面上的 AI 编程工具大致分几类：一类是集成在编辑器里的插件，比如各种 IDE 的 AI 助手；一类是独立的对话式工具，适合做方案讨论和代码片段生成；还有一类是命令行工具，适合做批量处理和自动化。我自己的组合是：编辑器插件负责行内补全和局部修改，对话工具负责方案设计和疑难排查，命令行工具负责重复性任务。

选工具的时候，我建议重点看三个指标：响应速度、上下文长度、对项目结构的理解能力。响应速度决定你愿不愿意频繁用它；上下文长度决定它能不能理解你整个项目的脉络；对项目结构的理解能力决定它生成的代码能不能直接放进你的工程里。这三个指标比“支持多少种语言”重要得多，因为语言支持是基础能力，前三个才是影响日常体验的关键。

2.3 提示词设计：把 AI 当成一个聪明但没背景的新同事

和 AI 沟通，最忌讳的是“默认它知道”。它不知道你的项目用什么框架、什么版本、什么代码规范、什么命名习惯。所以我的提示词模板通常包含四块：背景、任务、约束、示例。

背景部分说明项目技术栈和当前状态；任务部分说清楚要做什么；约束部分列出必须遵守的规则，比如“不要引入新依赖”“保持现有代码风格”“函数不超过 30 行”；示例部分给一个参考，让 AI 知道你想要什么风格。这个模板看起来麻烦，但用几次之后你会发现，前期多花两分钟写清楚，后期能省半小时改代码。

2.4 验证策略：不信任，但验证

AI 生成的代码，我从来不直接合并到主分支。我的流程是：先跑通，再审查，最后补测试。跑通是底线，确保功能可用；审查是看逻辑有没有隐患，比如边界条件、异常处理、性能问题；补测试是防止以后改坏了。这三步里，审查最花时间，但也最重要。我见过太多人因为“AI 写的应该没问题”而跳过审查，结果上线后出各种奇怪 bug。

3. 核心细节解析与实操要点：把 AI 用出效率的关键

3.1 上下文管理：让 AI 记住你的项目

AI 的上下文窗口是有限的，项目一大，它就会“忘事”。我的做法是维护一个项目摘要文件，里面记录技术栈、目录结构、核心模块职责、命名规范、常用工具函数。每次开新对话，先把摘要贴进去，再提具体需求。这样 AI 就能在正确的背景下工作，生成的代码也更贴合项目实际。

另外，我会把常用的提示词存成模板，比如“生成单元测试”“重构这个函数”“解释这段代码”。用的时候直接调用，不用每次重新组织语言。这个习惯看起来小，但积累下来能省很多时间。

3.2 代码审查：重点看这五个地方

AI 生成的代码，我审查时重点看五个地方：边界条件、异常处理、资源释放、并发安全、依赖引入。边界条件是最容易出问题的地方，比如空数组、超大输入、特殊字符；异常处理看它有没有吞掉错误或者只打印不处理；资源释放看文件、连接、锁有没有正确关闭；并发安全看共享状态有没有保护；依赖引入看有没有偷偷加了不必要的包。

这五个地方检查完，基本能过滤掉大部分隐患。剩下的就是业务逻辑正确性，这个需要你自己对需求足够清楚。

3.3 提示词进阶：用“角色 + 步骤 + 格式”提高命中率

基础提示词能解决大部分问题，但遇到复杂任务，我会用进阶模板：角色设定 + 步骤拆解 + 输出格式。比如“你是一个有十年经验的后端工程师，请按以下步骤设计一个短链接服务：第一步分析需求，第二步设计数据结构，第三步给出接口定义，第四步说明扩展性考虑。输出用 Markdown 表格呈现。”

角色设定让 AI 调用相关领域的知识；步骤拆解让它按逻辑推进，不会跳步；输出格式让结果更易读。这个模板我用在方案设计、代码重构、技术选型上，效果比一句话提问好很多。

3.4 多 AI 协作：让不同的 AI 做不同的事

我有时候会同时用两三个 AI 工具，让它们做不同的事。比如一个负责生成代码，一个负责审查代码，一个负责写文档。这样做的好处是互相制衡，生成的那个可能忽略的问题，审查的那个能发现。当然，这会增加操作成本，所以只用在关键模块上。

注意：多 AI 协作时，要确保它们拿到相同的上下文，否则审查结果可能不准确。

3.5 版本控制：每次 AI 修改都单独提交

用 AI 改代码，我坚持一个习惯：每次 AI 生成的修改都单独提交，提交信息写清楚是 AI 生成还是人工修改。这样做的好处是，出问题的时候能快速定位是哪次修改引入的，也方便回滚。我见过有人把 AI 的修改和人工修改混在一起提交，结果出问题后排查了半天。

4. 实操过程与核心环节实现：一个完整功能的开发记录

4.1 需求拆解：把“做一个待办清单”拆成可执行任务

假设我要做一个待办清单应用，支持增删改查和本地存储。我不会直接让 AI 写整个应用，而是拆成这些任务：数据结构设计、添加待办、删除待办、编辑待办、标记完成、本地存储读写、界面渲染。每个任务单独和 AI 对话，拿到代码后自己组装。

拆解的原则是：每个任务都能独立验证。比如“添加待办”这个任务，我拿到代码后可以立刻测试：输入一条待办，看它有没有正确添加到列表里。这样即使某个任务出问题，也不会影响其他部分。

4.2 数据结构设计：先定契约，再写实现

数据结构是整个应用的基础，我会先和 AI 讨论清楚。提示词大概是：“我要做一个待办清单应用，请帮我设计待办项的数据结构，要求包含唯一标识、标题、完成状态、创建时间、更新时间。用 JSON 格式给出示例，并说明每个字段的类型和用途。”

AI 给出的结果我会审查：唯一标识用什么生成、时间戳用什么格式、字段命名是否清晰。确认后，这个结构就成为后续所有功能的契约，添加、删除、编辑都围绕它来写。

4.3 核心功能实现：添加待办的完整过程

以“添加待办”为例，我的提示词是：“基于以下数据结构 [贴入结构]，用 JavaScript 写一个添加待办的函数。要求：接收标题作为参数，生成唯一标识，设置创建时间和更新时间，返回新的待办对象。不要修改原数组，返回新数组。函数不超过 20 行。”

AI 生成的代码我会检查：唯一标识生成方式是否可靠、时间格式是否统一、有没有副作用。确认后，我会补一个简单的测试用例，验证添加后数组长度加一、新项字段完整。

4.4 本地存储：让数据持久化

本地存储这块，我让 AI 生成读写两个函数。提示词里会强调：“读取时如果数据不存在或格式错误，返回空数组；写入时捕获异常并提示用户。” 这两个边界情况是实际使用中最容易出问题的，提前让 AI 处理掉，能省很多调试时间。

4.5 界面渲染：把数据映射到 DOM

界面渲染我让 AI 生成一个渲染函数，接收待办数组，清空列表后重新渲染。提示词里会说明：“用模板字符串生成 HTML，对用户输入做转义，防止 XSS。” 转义这一点很重要，很多人用 AI 生成代码时会忽略安全问题，结果留下隐患。

4.6 组装与联调：把碎片拼成完整应用

所有模块生成完后，我会自己写一个入口文件，把添加、删除、编辑、渲染、存储串起来。这一步我一般不交给 AI，因为涉及模块间的协调和事件绑定，自己写更可控。组装完成后，跑一遍完整流程：添加几条待办、编辑、标记完成、刷新页面看数据是否还在。

4.7 参数计算示例：分页逻辑的实现

再举一个涉及参数计算的例子。假设要做分页，我让 AI 生成一个分页函数。提示词：“写一个分页函数，接收数组、页码、每页数量，返回当前页的数据和分页信息。页码从 1 开始，如果页码超出范围，返回最后一页。分页信息包含总页数、当前页、是否有上一页、是否有下一页。”

AI 生成的代码我会验算：总页数用Math.ceil(total / pageSize)，当前页用Math.min(Math.max(page, 1), totalPages)做边界限制。这些计算逻辑我会自己心算一遍，确认没问题再用。

5. 常见问题与排查技巧实录：踩过的坑和解决方法

5.1 AI 生成的代码跑不起来怎么办

这是最常见的问题。我的排查顺序是：先看报错信息，再看依赖版本，最后看代码逻辑。报错信息通常能直接定位问题；如果报错说某个 API 不存在，很可能是 AI 用了新版本语法或旧版本 API，需要调整；如果报错不明显，我会把代码和报错一起贴回给 AI，让它自己分析。

提示：贴报错时，把完整的错误堆栈和你的运行环境一起给 AI，它能更准确地判断。

5.2 AI 总是理解错需求怎么办

这通常是提示词不够具体。我会补充三样东西：输入示例、输出示例、边界说明。比如“输入是一个字符串，输出是一个对象，字符串为空时返回 null”。有了具体示例，AI 跑偏的概率会大幅降低。

5.3 生成的代码风格和项目不一致怎么办

两个办法：一是在提示词里贴一段项目现有代码作为风格参考；二是生成后用格式化工具统一处理。我一般两个都用，先让 AI 参考风格，再用 Prettier 或 ESLint 自动格式化。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个技巧：让 AI 先写测试，再写实现。这样你能先确认它理解对了需求，再让它写代码。第二个技巧：关键函数让 AI 写两版，对比后取长补短。第三个技巧：每次对话结束前，让 AI 总结这次讨论的结论，方便下次接着聊。第四个技巧：不要一次性让 AI 改太多文件，改一个验证一个，出问题好定位。

6. 我个人的使用体会与后续扩展方向

用 AI 辅助编程这段时间，我最大的感受是：它放大的是你的判断力，而不是替代你的思考。你越清楚自己要什么，它越能帮到你；你越模糊，它越容易带你跑偏。所以我现在花在“想清楚”上的时间比以前多了，花在“敲代码”上的时间少了，整体效率反而更高。

后续我打算在几个方向继续深入：一是把常用的提示词和流程固化成脚本，减少重复劳动；二是尝试让 AI 参与代码审查和文档生成，把整个开发链路串起来；三是整理一套适合团队使用的 AI 协作规范，让多人协作时也能保持一致。这些还在摸索中，等有成熟经验了再单独写一篇分享。

最后分享一个小技巧：每次用 AI 解决一个难题后，把对话记录存下来。过一段时间回头看，你会发现很多问题有共性，这些记录本身就是最好的学习材料。