Vibe Coding 实战：Spec、Skills、Plan 三步，让 AI 不再乱写代码

上一篇我们聊过：从 CRUD 到 AI 应用工程师：80% 的工作，其实还是工程-CSDN博客。

那工程里有一块，几乎每个转型的人都要碰——用 AI 写代码。

我管这套打法叫 Vibe Coding。名字听着有点玄学，做法其实很土：用人话跟 AI 聊需求，让它写代码，你们一起改到能跑为止。

听起来简单？真上手就知道，很多人第一天就翻车：AI 今天用 Next.js，明天换 Vue；同一个项目里风格打架；改 A 文件，B 文件悄悄坏掉；复杂功能写到一半，逻辑全乱。

问题通常不在 AI 笨，在于你把 AI 当成了许愿池。

Vibe Coding 和传统编程，差在哪？

传统编程，你是执行者：需求清楚 → 自己查文档 → 自己写 → 自己测 → 自己改。

Vibe Coding，你是带新人干活的 Tech Lead：AI 是那个聪明、手快、但容易自作主张的实习生。

这个比喻很重要。你不会对一个实习生说「帮我做个用户系统」就撒手不管；你会给他员工手册、参考资料、任务清单，改完还要 code review。

Vibe Coding 的核心，就是把这三样东西补齐：Spec（立规矩）、Skills（给资料）、Plan（定计划）。

很多人转型痛苦，是因为还在用「我自己写」的习惯去「指挥 AI 写」——需求一句带过，上下文零提供，出了错就骂 AI 智障。

换种说法：不是 AI 不好用，是你还没学会当 Lead。

工具怎么选？别贪多，够用就行

市面上的 AI 编程工具四类：编辑器（Cursor、Trae）、命令行（Claude Code、Codex CLI）、插件（Copilot）、零代码平台（v0、bolt.new）。

日常开发我推荐 Cursor，原因很实际：

1. Agent 模式：上下文给够，多文件联动改代码，准确率明显比纯 Chat 高
2. 规则体系：用户规则、项目级 .cursor/rules，配一次长期生效
3. 社区成熟：踩坑经验、插件、最佳实践都多

模型不用追全。我自己体感：Claude 系列稳定、长上下文；Gemini UI 审美好；GPT 快、适合小任务。 国内 DeepSeek、Qwen 也能用，但处理复杂业务还得 Claude。

命令行工具（Claude Code、Codex CLI）适合脚本、批处理；零代码平台适合原型，真要进生产还得回 IDE。

结论：Cursor + 一个你顺手的模型，够用了。工具越多，切换成本越高。

第一步 Spec：立规矩，别每次都从零纠正

没规则时，AI 的随机性很强：这次用 fetch，下次上 axios；这个文件用函数式，那个文件 class 满天飞。每次对话都要手动纠正，效率极低。

Spec 就是给 AI 的「员工手册」，项目级、长期有效。

Cursor 里怎么配？

规则放在 .cursor/rules/，用 .mdc 格式。Cursor 会把它们拼进每次对话的 prompt 开头，持续影响 AI 行为。

简单项目可以用根目录的 AGENTS.md；复杂项目建议拆成多条规则。

三个模板，够覆盖大部分场景

1. 项目结构规范（必配）

告诉 AI：代码放哪、模块怎么分、新文件该建在哪。
AI 生成项目时最容易「乱放文件」——根目录堆一堆、utils 和 components 分不清。结构规范能直接减少后期重构。

示例要点：

• src/app/ 放路由和页面
• src/components/ 放可复用组件
• src/lib/ 放工具函数和 API 封装
• 新 API 路由统一放 src/app/api/

2. 代码风格规范

团队协作时尤其重要：缩进、命名、import 顺序、是否用分号。
不然 AI 改过的文件和你改过的文件，git diff 全是无意义格式化，历史没法看。

3. 功能实现规范

放长期有效的架构约束：组件怎么拆、API 返回格式、错误怎么处理、日志怎么打。

比如统一 API 响应：

{
  "success": true,
  "data": {},
  "error": ""
}

所有接口必须 try-catch、必须返回这个结构——写进规则，AI 就不会每次发明一种新格式。

如果项目大部分是 AI 生成的，结构规范不是可选项，是必选项。 我吃过亏：前期图快没配规则，后期改一个 bug 牵出一串风格不一致的文件，补规则比重写还痛苦。

第二步 Skills：给资料，别让它瞎猜

Spec 解决「按什么规矩干」；Skills 解决「它懂不懂你的项目」。

1. Codebase Indexing：等索引跑完再聊

Cursor 打开项目后会自动做代码索引——拆片段、转向量、建 searchable 的代码库。

进度到 100% 再开始复杂对话，否则 AI 对项目结构是半盲的，@ 文件、跨文件引用都容易偏。

2. 内部文档：@Docs 喂给它

项目里用内部 SDK、私有 API、公司规范文档，Cursor 默认不知道。

路径：Settings → Indexing & Docs → Add Docs，等状态变绿，对话里 @Docs 引用。

我做过一个内部集成DeepSeek AI 的功能，没加文档时 AI 瞎编函数名；加了官方 doc 索引，一次生成就能跑。外部知识不会自动进 AI 脑子，你得主动喂。

3. Reference：照猫画虎

要写新功能，项目里往往已有类似实现——别从零描述，直接 @ 参考文件。

比如要写 /api/posts，就：

@Files src/app/api/users/route.ts
参考这个文件，帮我写 /api/posts 路由

AI 会模仿该文件的结构、错误处理、命名风格。比写一大段「请用 RESTful、要 validation、要 logging」管用得多。

Skills 的本质：减少 AI 的猜测空间。 能指到现有代码，就别只用自然语言描述。

第三步 Plan：定计划，复杂任务别一把梭

Spec 和 Skills 配好了，简单功能通常能一次搞定。
复杂任务——重构模块、做多页面联动、新子系统——直接让 AI 开写，写到一半逻辑必乱。

Plan 解决的就是：任务太大，AI 上下文撑不住。

做法一：先写 Markdown 计划，再 @ 执行

复杂需求先在另一个对话（或自己）里产出设计文档，存进项目，例如 docs/user-system-plan.md，内容至少包括：

• 目标：要达成什么
• 任务拆分：分几步、每步改哪些文件
• 具体修改点：接口签名、数据结构、边界情况

然后对 Cursor 说：

@Files docs/user-system-plan.md
按这个计划逐步实现，先做第 1 步

AI 按步骤走，比「帮我做一个完整的用户管理系统」可控得多。

做法二：Cursor Plan 模式

更复杂的，切 Plan 模式：AI 先输出详细方案和 To-do 列表，你审完点 Build 再执行。

我习惯：涉及 3 个以上文件、或动到核心逻辑的改动，一律先 Plan。 多花 5 分钟看方案，省后面 2 小时修烂摊子。

改完必须 Review

Plan 模式跑完，点 Review 看 diff。
AI 可能「完成任务」的同时引入隐蔽问题——删了错误处理、改了不该改的配置。复杂修改不 review，等于没做 code review 就 merge。

思维转变：PM 定 What，架构师定 How

Spec / Skills / Plan 是操作层；底下还有两层思维，决定你给的指令质量。

PM 思维：把 What 和 Why 说清楚

烂提示：

帮我写一个博客发布功能

AI 只能自由发挥：有没有 Markdown？要不要预览？标题空怎么办？发布失败提示啥？

好提示像产品文档：

实现博客发布功能：

1. 用户输入标题、正文、标签
2. 支持 Markdown，发布前可预览
3. 成功后跳转文章详情页
4. 标题为空显示错误提示
5. 提交过程要有 Loading 状态

补上用户故事、验收标准、边界情况，AI 才不至于给你半套系统，你再一遍遍补需求。

架构师思维：把 How 和约束框死

功能说清楚还不够，复杂项目要把技术方案讲明白：

基于 FastAPI，Pydantic 做校验，SQLite 存数据。
所有 API 必须 try-catch，返回统一 JSON：
{ "success": bool, "data": {}, "error": "" }

还要交代：数据要不要持久化、偏好的框架、错误怎么处理。
约束越清楚，AI 越不会在实现里「创造性发挥」。

Vibe Coding 里，你写的 prompt 质量 ≈ 传统开发里你写的技术方案质量。

一套可复制的日常流程

新项目或新功能，我大致按这个顺序：

1. Spec：配好结构、风格、API 规范（15–30 分钟，一次投入长期受益）
2. 等索引完成，有内部 SDK 就加 Docs
3. 简单功能：@ 相似文件 + 清晰 PM 式需求，直接 Agent 改
4. 复杂功能：先写 plan.md 或开 Plan 模式，审方案再 Build
5. 改完 Review，重点看错误处理、边界、有没有动到不该动的文件

别跳步。很多人第 1 步就嫌麻烦跳过，后面全在填坑。

常见翻车与对策

「AI 每次风格都不一样」
→ Spec 没配或配太泛。补项目结构和代码风格规则。

「它根本不懂我们项目的 SDK」
→ Skills 缺失。加 Docs 或 @ 现有调用示例。

「写到一半逻辑全乱」
→ 任务太大，没 Plan。拆步骤，或开 Plan 模式。

「改完能跑，上线就出问题」
→ 没 Review，边界和错误处理没写进需求。PM 思维补验收标准和异常场景。

最后说两句

Vibe Coding 不是「少写代码偷懒」，是把精力从敲键盘挪到定规矩、给上下文、拆任务。

Spec 立规矩，Skills 给资料，Plan 定计划——三步走完，AI 才像那个「刚毕业的高材生」：给对手册和参考资料，按清单干活，改完你过目。

模型半年一换，Cursor 功能也会更新，但这套分工逻辑不会过时：你越是 Lead，AI 越是工具；你越是甩手掌柜，AI 越是随机数生成器。

如果你已经在用 Cursor，不妨自查：你的项目里有结构规范吗？索引跑满了吗？上次复杂改动，是先 Plan 再 Build，还是一把梭？

系列下一篇预告：用 AI 写代码，先学会当 PM 和架构师——把 What/Why/How 写清楚，比多背十条 Prompt 模板有用。