3 个 Vibe Coding 小窍门：让 Claude/Cursor/GPT 写代码更稳、更快、更少返工

你有没有遇到过这种情况：

需求一句话丢给 agent，它“唰”地写完一堆代码
你一跑就报错
你改一处又崩两处
最后你怀疑人生：这玩意到底是在省时间，还是在吃时间？

问题通常不在模型。

问题在流程。你少了“护栏”。

下面这 3 招，都是老派软件工程的朴素招数，但放到 vibe coding 里，效果特别猛。✅

1）先做 Plan，再让 Agent 编码（别上来就让它写）

很多人用 AI 编程的方式是：

“帮我实现一个登录功能。”

然后 agent 就开始激情输出。

写得越快，翻车越快。因为它默认补全了太多细节：接口长什么样、状态怎么存、错误怎么处理、你要不要加埋点……全靠猜。

更稳的玩法是：先让它出计划，你只做评审，然后才开工。

你可以这样做（可直接复制）

Plan 提示词：

你先不要写代码。
请先输出实现方案（Plan），包括：
1) 需求澄清：你有哪些假设？有哪些不确定点需要我确认？
2) 技术方案：模块拆分、关键数据结构、接口设计
3) 任务拆解：按步骤列出要改哪些文件/新增哪些文件
4) 风险点：最可能踩坑的地方
等我确认 Plan 后你再开始编码。

评审 Plan 时你盯这 3 件事

边界条件：异常怎么处理？空值怎么办？超时怎么办？
接口契约：输入输出是什么？错误码/异常策略是什么？
改动范围：哪些文件会动？会不会牵一发而动全身？

评审通过再让它写，返工会明显少很多。你会感觉：代码不是“生成”，而是“施工”。🧱

2）用 TDD 驯服 Agent：先写测试，让它自己“撞墙”

你想要的是“稳定可用的功能”。

agent 更容易给你的是“看起来很像能用的功能”。

TDD 的思路很简单：让 agent 先写测试，并且确认测试会失败；再写实现让测试通过。

这招对 vibe coding 特别狠，因为它把“正确性”从嘴炮变成了自动验证。

适合的场景

你在做一个函数/模块，输入输出清晰
你在修 bug（复现用例能写成测试）
你不想每次都手动点 UI、手动跑流程

一套可执行流程

让 agent 写测试用例（覆盖正常、异常、边界）
跑测试，确认是红的（失败）
让 agent 写最小实现让测试变绿
再补测试，继续迭代

提示词模板

你先不要实现功能。
请先为这个需求编写测试（列出测试点 + 给出可运行的测试代码）。
要求：
- 覆盖正常/异常/边界
- 先确保当前代码跑测试会失败（红）
等我确认后，你再编写实现代码让测试通过（绿）。

小提醒：别把测试写成“形式主义”

常见翻车点：

测试只测“能跑”，不测“对不对”
测试没断言关键输出
测试依赖外部网络/真实数据库，跑一次等半天

你的目标是：测试快、断言狠、失败原因清晰。

你会发现 agent 在 TDD 约束下会老实很多：它没法靠“差不多”蒙混过关。😄

3）建一个项目级规则文件：让 Agent 每次都按你的习惯来

你有没有这种崩溃：

你刚说完“别用 any”，它下一段就 any 满天飞
你刚说“统一用 pnpm”，它回头给你 npm install
你刚说“接口返回要带 code/msg/data”，它又开始自由发挥

原因很简单：对话是短期记忆，项目规范是长期资产。

解决方案：把关键规则写成项目级规则文件，让 agent 每次工作都先加载。

放哪里？写什么？

你可以在项目根目录放一个：

AGENT_RULES.md
PROJECT_RULES.md
CONTRIBUTING.md

名字不重要，关键是内容“可执行”。

一个好用的规则文件模板

# 项目规则（Agent 必读）

## 目标
- 优先保证可维护性，其次才是速度
- 所有变更必须可测试、可回滚

## 技术栈约束
- 包管理：pnpm
- 语言：TypeScript，禁止使用 any
- 代码风格：eslint + prettier，提交前必须格式化

## 目录与命名
- 新增组件放在 src/components/
- 文件命名：kebab-case
- 导出规则：统一使用 named export

## 编码要求
- 不要引入新库，除非我明确同意
- 遇到不确定的业务规则，先问我，不要猜
- 改动尽量小：能局部修就别重构全家桶

## 提交输出格式
- 先给变更摘要（改了什么/为什么）
- 再给 diff 或具体文件修改
- 附上如何运行测试的命令

让它“每次开工先读规则”的提示词

开始前请先阅读并遵守项目根目录的 AGENT_RULES.md。
后续所有方案和代码都必须符合其中约束。
如果规则与我的新指令冲突，先指出冲突并让我确认取舍。

你会明显感觉：沟通成本下降，输出更一致，review 轻松很多。

一份“懒人工作流”给你直接抄

每次写功能都按这个节奏走：

Plan：出方案 → 你审 → 再开写
Test：先写测试 → 跑红
Code：最小实现 → 跑绿
Rules：全过程遵守项目规则文件

这套流程对专业开发者是基本功。

对非专业写代码的人更是救命绳：不容易写着写着把项目写炸，还能学到真正的工程习惯。🧯

避坑清单（真的很常见）

只让 agent 写代码，不让它交付“验证方式”（测试/运行命令）
Plan 没评审就开写，结果方向错了还越写越多
规则文件写成口号（“代码要优雅”这种没法执行）
一次性让它改太多文件，定位问题像在垃圾堆找钥匙

你可以立刻做的 3 个动作

给你正在做的项目加一个 AGENT_RULES.md
下一次需求先让 agent 出 Plan，你只做评审
有条件就上 TDD，至少把核心逻辑用测试钉住

你照着做一周，就能明显感觉到：vibe coding 不再靠运气，代码质量也不再靠祈祷。