vibe coding不是找个顶尖的大模型，对着许愿。vibe coding是你自己先把工程架构搭明白，让它来补充细节。
ai大模型工作的原理是基于"概率"预测下个token，所以后面讨论的一切，核心都是提高"概率"。
"把需求说明白"远比想象的难。
猜猜软件开发最难推进、最耗时间的步骤是什么？写代码？测试？都不对——是搞明白需求。
让客户或者老板把需求说清楚太费劲了，所以才有了产品经理这个岗位。产品经理就是程序员和甲方的中间层——输入模糊甚至矛盾的原始想法，输出一份描述详尽的需求文档。产品经理这个岗位的存在本身，就在暗暗佐证一件事：大多数人真的很难把需求说明白。
也正因此，vibe coding的第一步是搞清楚定位，摆正位置。从今天起，我们开发者就不再是一线撸代码的人了。我是产品经理——我的工作不是写代码，而是尽可能详尽地描述自己的需求，让AI预估工程规模：大概有多少个功能点，需要搞多久。说清楚排期，再让它反过来问我几个问题，确保人说的和AI听的是一回事，没有理解偏差。
落实到实操上，就是善用plan模式——开始编码前先让AI列一个计划，并诱导它向你提问。
参加过一线开发的同学听到这应该明白了——这不就是角色互换吗？以前需求评审会上是产品经理逼着开发给排期、确认改动范围，现在轮到你逼问AI了。没错，现在开发者就是AI和最终产品之间的中间层，我们的定位是从此变成技术产品经理。
经验丰富的一线开发都知道，如果一个项目比较大，排期超过一个月，那预估的工时大概率都在扯淡。这就好比你让我估计从北京开车到保定要多久，我能说个八九不离十；你要问我从北京开车到圣地亚哥，那所有时间预估都是扯淡。
vibe coding也一样。让它实现一个功能点，它能搞个八九不离十。你张嘴就是"帮我实现个淘宝"，再顶尖的AI也白给。
所以需求规模大到一定程度时，一定要让AI规划分期。假如这活搁以前你自己干一个礼拜都干不出来，那就该让AI分期——一期、二期、三期——并输出一份分期的规划文档，也就是概要设计文档。
概要设计文档不仅要写清楚每期大概干什么，也要写清楚不要干什么。比如你想实现一个简单的登记表单，AI很可能顺手把登录功能也给你做了——因为它被训练时，绝大多数的表单用例都绑着登录逻辑。你一定要在概要设计里明确写上"本期不实现登录功能"，才能避免白花花的token流向奇怪的方向。
概要设计除了每期要实现的功能点，还要明确项目的技术栈：前端是Vue还是React，CSS是Tailwind还是原生，组件库用哪个，版本号锁定到哪一档，测试框架怎么做，部署流程怎么走——这些都要在这个环节考虑到并落实到文档里。必要时还要把组件库的文档地址直接插进概要设计。这么做的目的就像教小学生画直线——你得时不时拿把尺子在旁边比着，不然越画越偏只是时间问题。
拿到概要设计文档之后，再基于分期输出详细的详细设计文档。比如第一期的详细设计：有哪些功能点，每个功能点涉及哪些模块，每个模块有哪些接口定义。详细设计每一步都要求高度精确，目的是让每期的改动精准可控。具体来说，页面有哪些层级结构，每层有哪些组件，涉及哪些状态管理，后端API的接口设计文档——全都在这一步敲定。
别嫌麻烦，再牛的大模型也得在明确规范下才能发挥真正的作用。饭得一口口吃，代码得一点点设计。这就好比你跟姑娘处对象，不能看人一眼就把孩子在哪上幼儿园都想好了——你得先加微信，搞搞暧昧，拉拉小手，确立关系，然后再想结婚办席生孩子的事。一上来就聊幼儿园，大姑娘肯定懵。
为了把需求说清，流程图和软件架构图必不可少——毕竟一图胜千言。架构图和业务流程图不只是方便AI理解，也是方便你自己，因为很可能一个多月过去之后，很多实现细节你自己也记不清了。
老开发都知道，代码写得好不如PPT汇报得好，画好架构设计和各种流程图尤为重要。
vibe coding之前，应该先引入测试机制。
两张AI根据提示词生成的图片，提示词只做了细节部分的少量变更，画面整体却可能存在巨大差异。AI写代码也一样——需求反复变更时，AI可能会意外修改无关代码。
为了避免上一轮写好的代码被意外改坏，我们要对写好的部分编写测试用例。工具函数、接口、框架开发推荐采用测试驱动开发（TDD），多写单元测试。每轮对话结束时跑一遍测试用例，必须全部通过，代码才能被采纳。
在编写UI、前端交互逻辑时，单元测试可能就不太好用了，这时候推荐端到端测试——也叫E2E测试。框架推荐Playwright——让AI每次改完UI代码后生成一份E2E测试脚本，相当于请了个测试帮你把页面点点点的操作路径录制下来。以后每次提交代码前跑一遍，确保页面仍然可用。
Playwright还有一个轻量版本适合每轮对话结束时做快速验证，叫playwright-cli。基本原理是安装一份skill，教AI通过命令行操作来验证页面正确性。它和常用的browser-mcp不一样的地方在于：browser-mcp是基于页面截图来理解页面，而且MCP需要在上下文里注入更多信息；而playwright-cli是基于可访问树——那个本来设计给视障人士用的类DOM树——来理解页面，天然更简洁、更轻量。
如果你有过深入的vibe coding经验，你一定会觉得这是一件比打游戏还爽的事。往往在电脑前一坐就是一天。很多人直呼自从开始vibe coding，再也不钓鱼了，也不刷短视频了。因为vibe coding本质上是间歇性强化机制——对神经系统来说，它和打游戏、刷短视频、钓鱼是同一回事。短时间内看着屏幕输出一串串代码实现功能，跟坐在河岸边半小时突然一条大鱼上钩，给神经带来的刺激不分伯仲。
要想vibe得爽，就不要打破这种心流。如果你一边coding一边和同事联调或者切到其他项目，那很难进入这种状态。所以我在vibe coding的时候不会优先选择前后端分离的架构——因为我不想切换思维模型，我的AI也不想被动扩大上下文。
很多同学用全栈框架vibe coding时常遇到一个问题：我只想改服务端代码，但AI总惦记着改UI来满足需求。尽管我在提示词里反复说别动UI、别动UI，它就是不听。
我的解决方法是设hook。主流agent工具都支持hook机制——在AI对话过程中设定若干个事件节点，比如命令执行前、对话结束后，允许用户在这些节点调用自定义脚本。
我常用的全栈框架是Next.js，它可以通过合理的目录结构区分哪些代码是UI层、哪些是服务端层。如果今天的变更不涉及UI，我会通过hook限制改动范围：一旦检测到AI改动了UI相关的目录，事件hook就返回错误信息，让AI意识到自己走错了路。
聊到hook，其实agent工具里像这样不为人知但好用的功能还不少。比如subagent，vibe coding和“人力外包”的结合。今天就先聊到这，subagent和其他几个骚操作，下期展开说。