一个被误读的概念
「Vibe Coding」最近很火，容易被理解成：闭着眼睛让 AI 写，能跑就行。
更健康的定义是：
开发者用自然语言精确描述意图、约束与验收标准，AI 负责大量实现细节；人负责产品方向、架构边界、测试与合并。
代码仍然要写——只是你写的大多是 spec、测试、review comment，而不是每一行 boilerplate。
和传统开发差在哪
| 传统 | Vibe Coding |
|---|---|
| 人写每一行 | 人写意图 + 关键逻辑 |
| 文档后补 | spec 先给 AI |
| 搜索 Stack Overflow | @ 仓库 + 对话 |
| CR 同事 | CR AI 的 diff |
它不是替代软件工程，而是把工程前移到「说清楚要什么」。
最小可行流程
- 写一段 spec（用户故事 + 非目标 + 边界）；
- @ 相关文件，说明不能动哪些模块；
- 让 AI 先出计划，你确认后再 apply；
- 跑测试 / lint / 手点关键路径；
- 小 commit，方便回滚。
这和你用 Cursor Agent、Claude Code 的流程是一致的——Vibe Coding 是方法论，工具是载体。
好 prompt 长什么样
## 目标
给公开文章列表增加「刷新中」骨架态，避免重复请求。
## 约束
- 只改 frontend/src/hooks/usePublicResource.ts 与调用方
- 不引入新依赖
- 保持现有 API 类型
## 验收
- 快速切换路由时不闪空白
- pnpm typecheck 通过
Vibe 在「 vibe / 感觉」吗？ 不，在 spec 的 vibe 是否够具体。
反模式
- ❌ 「帮我做一个淘宝」
- ❌ 不跑测试就 push
- ❌ 一次让 AI refactor 50 个文件
- ❌ 生产密钥贴进 chat
- ❌ 把 AI 输出当权威，不查官方文档
适合 Vibe Coding 的任务
- CRUD、表单、列表、SEO meta；
- 样式微调、组件拆分；
- 测试样板、迁移脚本草稿；
- 文档、changelog、i18n 文案。
不适合的任务
- 核心安全模块从零设计；
- 高性能内核无 profiling 优化；
- 法律合规文本最终定稿。
和本博客的关系
这个站点本身就在实践 Vibe Coding：Nest 后端 + Umi 前端 + Agent 模块 + Cursor Rules。文章不是复制粘贴知识库，而是 理解 → 重写 → 实践验证。
小结
Vibe Coding = Spec-driven + AI 实现 + 人验收。先把意图说清楚，再选 Cursor / Claude Code / API——顺序不能反。
概念参考社区讨论与 liyupi/ai-guide 目录结构；本文为作者原创表述。