AI Coding 最佳实践

Vibe Coding

Vibe Coding 是 AI Coding 发展到极致（比如 Cursor + Claude 3.5 Sonnet 极度强大后）产生的一种降维打击式的玩法，非常适合做原型、Side Project。但如果是正式的商业项目，Vibe Coding 是危险的，你更需要的是成熟的 AI Coding 技巧

“Vibe Coding”（氛围编程）这个词由前特斯拉 AI 总监 Andrej Karpathy 提出，核心意思是：你不再从零开始写代码，而是通过自然语言描述需求，完全依赖 AI（如 Cursor, Copilot, Claude, GPT）生成代码。你看代码“顺眼”就保留，不对劲就让 AI 重写或微调

但如果不加以控制，Vibe Coding 很容易变成“屎山代码生成器”。以下是为你整理的 Vibe Coding 最佳实践，分为心态、工作流、提示词、质量控制四个维度：

心态转变

从构建者变成审稿人：你的主要工作不再是写逻辑，而是看 AI 写的逻辑对不对、有没有安全漏洞、符不符合产品预期

允许犯错，随时推倒重来：在 Vibe Coding 中，Ctrl+Z 是你最好的朋友。如果 AI 把代码改乱了，直接撤销，重新给 AI 一个更清晰的提示词。但是对于一些老工程或者大型工程，在 AI 的代码上做修改也是不错的选择

高效工作流

1，垂直切片，拒绝水平铺开

错误：让 AI“帮我写一个带登录、注册、个人中心的电商后台”。
正确：先让 AI“只写一个最简单的登录页面和 API 对接”。跑通之后，再写注册，再写个人中心。

2，Vibe Coding 极易翻车。每完成一个小功能（比如数据库连上了、一个API写好了），立刻 git commit。
一旦AI把后续代码改崩了，你可以随时回滚到上一状态。

3，上下文隔离，不要在一个聊天窗口里聊所有的功能。聊“支付模块”就开一个新对话，聊“UI样式”就开另一个。防止AI的上下文窗口被无关信息污染

提示词技巧

提供清晰的“上下文”：不要只说“帮我写个按钮”。

好的提示词：“我现在在一个 Next.js 14 项目中，使用 Tailwind CSS 和 shadcn/ui 组件库。请帮我写一个主要的 Call to Action 按钮，颜色是品牌蓝，带 hover 放大效果。”（指定需求和存量技术栈、框架版本）

给出现有代码：让AI修改代码时，直接把相关文件的内容扔给它，或者使用 Cursor 的 @ 引用功能，而不是靠AI去猜（划定范围，减少上下文消耗）

确认技术实现：个人建议在 AI 实现代码之前，还是需要先和 AI 对技术方案，了解他是想如何实现你这个需求，然后将生成的文档给真正的 AI 编程者

提供样例：请模仿我项目中 utils/formatter.ts 的代码风格，帮我写一个处理日期的函数

那么这些都可以总结在同一个提示词中，我们可以使用 chat 模式，和 AI 敲定技术细节，生成一个文档， 再根据文档，对 builder，让他去修改功能

质量控制与避坑

是不是只要做好以上几步就可以了呢，完全不是的，Vibe Coding 最危险的地方在于看着能跑，实则千疮百孔。你必须守住以下底线：

• 绝对不要盲目信任 AI 写的 SQL 和鉴权逻辑：SQL 注入、越权访问（比如 A 用户能删 B 用户的数据）、密码明文存储。这些核心安全模块，必须人工逐行审查
• 强制 AI 写测试：请为刚才生成的 calculatePrice 函数写单元测试，覆盖正常情况、边界值和异常输入。如果测试跑不通，说明 AI 的代码有逻辑漏洞，让它自己修
• 定期要求 AI 重构和防腐

黄金法则总结

能 Vibe 的：UI 样式调整、表单验证、CRUD接口、样板代码生成、写测试用例、正则表达式、文档编写。
不能 Vibe 的：系统架构设计、核心安全逻辑、复杂的并发处理、性能极限压榨、底层算法调优。

AI coding

对于一些大型项目来说，AI coding 是比较好的方案

接手完全不熟悉的大型项目，是程序员的噩梦。这时候 AI 极容易产生幻觉，胡说八道不存在的函数或逻辑

如果你用 Vibe Coding 的思路，100% 会把项目搞崩溃

以下是标准 SOP（标准作业程序）：

宏观摸底

目标：搞清楚这堆代码到底在干什么，用了什么技术栈。

让 AI 读取人类留下的痕迹：
把 README.md、package.json / pom.xml（依赖文件）、docker-compose.yml、agent.MD 等丢给 AI。
提示词：“基于这些配置文件，给我总结这个项目的技术栈、核心依赖，以及它是前后端分离还是单体架构？请用思维导图的形式输出。”

找一个抓手

假设你要修改“用户个人资料”页面。先在浏览器里打开这个页面，找到对应的 URL（比如 /user/profile）。

让 AI 帮你做代码跳转（全局搜索的替代品）：

在 Cursor 等工具中，使用 @codebase 或把相关文件引入。

提示词：“我想找到渲染 /user/profile 这个路由的组件，以及它调用的后端 API 接口。请帮我在代码中定位这些文件，并描述数据的流向（从请求发起到数据库查询）。”

让 AI 画时序图：

当你找到核心代码块，但逻辑太绕时。

提示词：“阅读这段 UserService.ts 代码，不要修改它。请用 Mermaid 语法画一个流程图，展示当 updateUser 被调用时，程序的执行路径和异常处理分支。”

安全干预—— 严格控制 AI 的动作范围

目标：在完全理解上下文的前提下，让 AI 动手，且只动该动的地方。

绝对禁止全局重构：

❌ 千万别说：“帮我优化这个文件的代码结构。”（它可能会把别人精心设计的兼容逻辑删掉）。
✅ 应该说：“我需要在 updateUser 函数里增加一个字段 avatar 的更新逻辑，请保持其他代码原封不动。”

锁定上下文：

只把需要修改的那个函数，以及它依赖的类型定义 喂给 AI。
提示词：“这是当前的函数（代码A），这是它的接口类型定义（代码B）。现在需求变了，要支持多选。请基于代码B的类型，重写代码A，并解释你改了哪里。”
预测破坏点（极其重要）：
提示词：“如果我按照上面的方式修改了这个函数，你觉得项目里还有哪些地方可能会因为这个改动而报错？请帮我找出来。”

阶段四：防御性验证

目标：用项目的现有规则来检验 AI 的产出。

先看测试：
如果项目有测试用例，先让 AI 看测试。
提示词：“这是 UserService 对应的单元测试文件。我打算修改上面讨论的逻辑，请根据现有的测试用例，告诉我我的修改是否会破坏原有的测试？如果会，请帮我更新测试用例。”
遵循旧项目的“方言”：
很多老项目有自己的奇葩写法。你要强行约束 AI。
提示词：“在这个项目中，我发现他们处理错误都是抛出 CustomError(code, msg)，而不是用 try-catch。请用和这个项目完全一致的代码风格来写这段代码。”

模型选择

选用合理的模型，用一些低端模型，就算你提示词写的再好，也无法避免生成垃圾代码的结果。所以稍微花点钱，去腾讯、阿里购买 coding plan 计划，是不错的选择，同时如果使用免费的模型，GLM、minmax 都是不错的选择。至于与 AI 的交互方式，无论是 cc、OpenCode 那种命令行交互方式或者是 cursor、trea 那种编译器交互都可以，看个人喜好