这几个月，我又找回了写代码的乐趣。
不是那种传统意义上的——一行行敲代码，拼各种脆弱的库，熬在样板代码里。而是，我开始“vibe coding”了。
Vibe coding 是一种全新的开发方式，你可以让最新的AI模型帮你搞定大部分工作。你只需要写好Prompt，规划好方案，剩下的交给AI。就像你在摩擦神灯，对着精灵说出你的愿望。
不过，和神灯精灵一样，如果你不说清楚，很容易得到你不想要的结果。
最大的变化？写代码不再是高成本的事了。
以前做一个功能要好几周。现在有了AI，资深工程师一小时就能搞定。做一个完整的SaaS应用？也许只要10天。我亲自试过。
这不仅仅是效率提升，更像是开了外挂。但要用好它，还是得有点经验。
Vibe Coding，不只是新手的玩具
Vibe coding 其实有点被黑了，一方面是推特上的“线程男孩”太会炒作，另一方面是以前AI写的代码确实不咋地。
但三个月前，Claude Sonnet 4 和 Gemini 2.5 Pro一出，彻底不一样了。这些模型真的很强。如果你以前用AI写代码觉得不行，现在可以再试试。
其实Vibe coding最适合有经验的工程师。如果你知道自己准备开发什么，熟悉各种框架和库，有自己的开发习惯，Vibe coding会让你效率大增。
Vibe Coding需要什么
1. 好的脚手架
先用像 ai‑monorepo‑scaffold 这样的monorepo脚手架。它自带迁移、路由、Zod schema、React Hook Form等。AI需要丰富的例子来学习。
AI有例子时表现最好。所以脚手架和规范很重要，能让AI写出更靠谱的代码。
2. 明确的规则
用 Cursor 的 .cursor/rules 规范项目。例如，我常用的规则有：
开发流程
- 写代码前，先列出详细的计划，审查后再问用户能不能执行。
- 执行后，跑一遍：
pnpm typecheck和pnpm lint。 - 跑测试：
pnpm test --filter @app/<web/api/db>。 - 千万别启动开发服务器或curl本地接口。
这些规则保证了规划、类型安全、代码规范和测试覆盖——让AI像个靠谱的初级工程师。
你可以看看我脚手架里的其他规则，涵盖数据库模型、迁移、env用法、React规范、shadcn组件、tRPC用法、Typescript规范等。我建议也写上项目介绍和各目录说明。
有时候AI会反复犯错，这其实是个好机会。Cursor有个功能，可以根据对话自动生成新规则，和现有.cursor规则一起用。
时间久了，你会有一套自己的规则，可以在不同项目间复用。
3. 完善的上下文
AI记性不好。它需要你给足上下文，自己不会自动找。
尤其是TypeScript类型，AI经常直接用any。
虽然以后可能会改善，但现在你得手动管理上下文。我的建议：
把所有相关文件都打开，包括
.d.ts类型文件（用cmd+click导入）。然后在Cursor里点Add All Open Files to Context。
这也是我现在推荐用monorepo的原因。以前我不喜欢，但现在技术进步了，所有代码都能被AI访问、随便改，也不会有lint或构建问题，真的很方便。
别省上下文。如果不确定，就多加点。虽然会贵点，但你的时间最值钱。
4. 智能编辑器
用 Cursor，它有快速lint、自动类型检查、规则集成和向量代码搜索。我不建议用远程agent，因为AI一旦跑偏，你得能随时暂停、重定向、重新提示。
我更喜欢Cursor而不是像Claude Code那样的命令行工具，因为它能随时加上下文，还有快速linter，AI能马上发现问题。命令行工具一般只在最后才做类型检查，不如边做边查。说到这，顺便提一句：
小步快跑，及时验证。
和写好代码一样，要有很快的迭代和验证循环。写一点，lint一下，测一下，再继续。AI默认不会这样。模型就像过于热情的初级工程师。你得管住它们，让它们慢点，把大项目拆成小块慢慢来。
5. 只用最强模型
用最好的：Claude Opus 4、Sonnet 4、Gemini 2.5 Pro 或 o3‑pro。一定要用“思考”模式。别为了省钱牺牲质量——你的时间最值钱。
6. 语音提示
我经常用 SuperWhisper 语音输入Prompt。虽然说得乱七八糟，但AI能听懂。语音比打字自然，还能说得更详细，我发现这样AI表现更好。AI很强，但还不会读心。
怎么写好Prompt
Prompt很关键。好Prompt能让AI变成靠谱的初级工程师，坏Prompt会让它乱来。如果你要vibe code，得学会怎么和AI说话。
我的经验：
1. 先让AI出方案
别直接让它“加登录功能”。要说：
“写代码前，先列个用Clerk、tRPC和Postgres DB实现邮箱/密码登录的详细方案。包括所有路由、mutation和数据库schema的更新。” 你同意后，AI才能写代码。
2. 说清楚你要什么
告诉AI你具体想要什么：
错误示例：
“给app加个toast”
正确示例：
“在
@layout.tsx里加一个shadcn的Toaster组件
3. 多给例子和上下文
例子很有用。AI看到一个Zod schema，就会照着写。如果你加了.cursor/rules，要提醒AI。
例子：
“按照
schemas/user.ts里的createUserInputZod schema格式来。”
4. 多加限制条件
别以为AI知道你的要求。要说：
- “别新建库”
- “别用
any，要用显式类型或Zod推断” - “测试别连真数据库——用mock”
5. 控制好范围
LLM很容易跑偏。你得管住它。
别说：
“给app加Stripe付费”
要说：
“加一个POST
/api/billing/checkout端点，为当前用户创建Stripe Checkout会话（见@user.tsx）。用stripe-node。”
6. 不确定时多说点
其实，Prompt越长越好。如果卡住了，就像和新手聊一样说出来：
“我想做这个。我有个React表单，想提交到tRPC端点，但要先用Zod校验。我们用React Hook Form和shadcn组件。”
哪怕说得乱，AI也能理解。
AI不擅长的事
自动找上下文
AI不会自动找需要的上下文。你得手动打开文件加到Cursor里。不然就会出错或者写出不合规范的代码。
TypeScript类型
AI写TypeScript类型很差，经常直接用as any。我觉得这其实是工具和上下文问题。Cursor没把npm模块的类型暴露给AI，所以我得手动加进去。
自动规划
AI默认直接写代码，不会先和你确认方案。我总是让它先出方案，因为先规划效果更好。
品味和架构
AI没有设计模式、模块化和项目风格的概念。这就需要你来定架构、定规范。
最后总结
- 脚手架和类型安全的上下文要建好
- 用
.cursor/rules规范项目 - 把所有相关文件（包括类型）都加到Cursor上下文
- 用顶级模型的规划模式（o3‑pro、Claude Opus 4等）
- 每次执行后都要lint、typecheck和测试
