Vibe Coding实战：智能体驱动全栈开发与工程化约束

1. 从“写代码”到“聊需求”：Vibe Coding 到底改变了什么

第一次听到 Vibe Coding 这个词，是从一个做独立开发的朋友嘴里蹦出来的。他说自己最近三个月没写过一行完整的业务代码，全靠“跟智能体聊天”把一套带支付、带后台、带数据看板的全栈应用给上线了。我当时的第一反应是：这不就是高级版的代码补全吗？后来跟着他完整跑了一遍流程，才发现自己理解得太浅了。

Vibe Coding 的核心，不是让 AI 帮你补全几行函数，而是把“开发”这件事的重心，从逐行敲代码转移到描述意图、约束边界、验收结果上。你更像是一个技术负责人，带着几个不知疲倦、知识面极广但偶尔会“想当然”的智能体，把脑子里那个模糊的产品想法，一步步逼成一个能跑起来的工程实体。它解决的核心问题是：从想法到可运行系统之间的“翻译损耗”和“重复劳动”。

这套范式特别适合三类人：一是有产品 sense 但工程经验不足的独立开发者，二是想快速验证 MVP 的小团队，三是需要频繁做技术预研、原型搭建的资深工程师。当然，如果你连基本的系统分层、接口设计、数据流向都说不清楚，那 Vibe Coding 只会让你更快地造出一堆无法维护的“意大利面条”。所以这篇文章，我想把“智能体驱动 + 全栈开发 + 工程化约束”这三件事揉在一起，讲讲我踩过的坑和总结出来的可复现路径。

2. 整体设计思路：为什么是“智能体驱动”而不是“AI 辅助”

2.1 传统 AI 辅助编码的天花板在哪里

过去两年，大家用 AI 写代码基本停留在“补全”和“问答”两个模式。补全模式的问题在于，它只看到当前文件、当前光标附近的上下文，对全局架构一无所知。你让它写一个用户登录接口，它能给你生成一个看起来没问题的函数，但这个函数用的 ORM 是 SQLAlchemy 还是 Prisma，返回结构是裸 dict 还是统一响应体，它根本不关心。结果就是，你补全了二十个文件，拼起来发现风格、依赖、错误处理全对不上。

问答模式稍微好一点，你可以把需求描述清楚，让它生成一整段代码。但问题依然存在：它不知道你项目里已经有哪些工具类、哪些中间件、数据库表结构长什么样。每次对话都是“失忆”的，你得反复把上下文喂给它。这种模式下，AI 是一个“知识渊博但记性极差的临时工”，你没法把一整个模块交给它。

2.2 智能体驱动带来的三个根本性变化

Vibe Coding 之所以能成立，是因为智能体（Agent）相比单纯的 LLM 调用，多了三个关键能力：工具调用、记忆管理、任务分解。

工具调用意味着智能体可以主动去读你的项目文件、查数据库 schema、运行测试命令、甚至调用浏览器去验证页面渲染。记忆管理让它能在多轮交互中记住“这个项目用的是 FastAPI + PostgreSQL + React”这样的全局约束。任务分解则是把“做一个用户系统”拆成“设计表结构 → 写迁移脚本 → 实现注册接口 → 实现登录接口 → 写前端表单 → 联调”，每一步都有明确的输入输出和验收标准。

我自己的体会是，智能体驱动的开发，本质上是把“编程”变成了“编排”。你不再关心 for 循环怎么写，而是关心任务之间的依赖关系、每个任务的验收条件、以及当某个任务失败时如何回滚或重试。这跟传统工程里的 CI/CD 流水线设计思路是一脉相承的，只不过现在流水线上的“工人”变成了智能体。

2.3 SDD：让智能体不跑偏的“合同”

热词里反复出现 SDD，我理解它在这里指的是Specification-Driven Development（规格驱动开发）。这个词在智能体开发语境下特别关键，因为智能体最大的风险就是“自由发挥”。你让它写一个“用户列表接口”，它可能给你返回一个包含密码哈希的完整用户对象，也可能给你分页参数写死成 10 条。

SDD 的做法是，在让智能体动手之前，先跟它一起把“规格”定下来。这个规格不是那种几百页的 PRD，而是一份结构化的、机器可读的契约。比如用 OpenAPI 的 YAML 片段定义接口的路径、方法、请求体、响应体、错误码；用 JSON Schema 定义核心数据模型；用一段自然语言描述业务规则和边界条件。这份契约既是智能体的“施工图纸”，也是后续自动化验收的“测试用例来源”。

我试过两种方式：一种是让智能体自己根据需求生成规格，我来审核；另一种是我先写好规格，再让智能体照着实现。实测下来，对于业务逻辑复杂的模块，先写规格再实现，返工率能降低一半以上。因为智能体在“理解需求”这一步就很容易产生歧义，如果让它边理解边实现，错误会被放大到代码层面，排查起来非常痛苦。

3. 核心细节解析：全栈智能体开发的关键环节

3.1 智能体的“项目上下文”怎么喂

智能体再聪明，如果不知道项目现状，也只能瞎猜。所以第一步是给它建立一个可查询的项目上下文。我的做法是在项目根目录放一个.agent/文件夹，里面至少包含这几样东西：

• architecture.md：用文字描述系统分层、模块划分、技术栈选型。
• schema.sql或schema.prisma：数据库表结构的权威来源。
• api-contract.yaml：OpenAPI 格式的接口契约。
• conventions.md：代码风格、命名规范、错误处理约定。
• env.example：环境变量清单，标注哪些是敏感信息。

然后通过智能体框架的“文件读取工具”，让它能在需要时主动读取这些文件。注意，不要一次性把所有文件塞进 prompt，那样既浪费 token 又容易让智能体迷失重点。正确的做法是让智能体根据当前任务，自己决定去读哪个文件。比如它要写一个接口，就应该先去读api-contract.yaml和schema.sql。

提示：conventions.md这个文件看起来不起眼，但它是减少“风格漂移”的关键。我通常会在里面写清楚：所有接口返回统一用{ code, data, message }结构；数据库查询一律走 Repository 层；前端请求统一走request.ts封装。智能体每次生成代码前读一遍，能省掉大量后期重构。

3.2 任务分解的粒度控制

智能体驱动开发最容易翻车的地方，就是任务粒度没控制好。粒度太粗，比如“实现用户模块”，智能体会一次性生成十几个文件，你根本审不过来，而且一旦某个文件有问题，整个模块都得推倒重来。粒度太细，比如“写一个函数签名”，你又失去了智能体自动编排的优势，还不如自己写。

我的经验是，一个任务对应一个可独立验证的交付物。什么叫可独立验证？就是这个任务完成后，你能通过一条命令或一个操作，明确判断它是对是错。比如：

• “创建 users 表的迁移脚本” → 验证方式：运行迁移命令，检查表结构是否符合 schema。
• “实现 POST /api/users 接口” → 验证方式：用 curl 发请求，检查返回状态码和响应体。
• “实现前端注册表单” → 验证方式：启动前端，手动填表提交，检查网络请求和页面跳转。

这种粒度下，每个任务大概对应 1-3 个文件的改动，智能体能在一次对话中完成，你也能在几分钟内完成验收。如果某个任务连续两次验收失败，就说明规格没写清楚，需要回到 SDD 阶段重新对齐。

3.3 多智能体协同的两种模式

热词里提到了“多智能体协同”，我在全栈开发场景下主要用两种模式。

模式一：按角色分工。一个“架构智能体”负责读规格、拆任务、分配任务；一个“后端智能体”负责写接口和数据库操作；一个“前端智能体”负责写页面和状态管理；一个“测试智能体”负责写自动化测试和跑验收。它们之间通过一个共享的“任务看板”文件来同步状态。这种模式适合模块边界清晰的项目，缺点是通信开销大，需要设计好任务交接的格式。

模式二：按阶段串行。同一个智能体，先做架构设计，再做后端实现，再做前端实现，最后做测试。每个阶段结束后，把产出物写入项目文件，下一个阶段开始时重新读取。这种模式实现简单，适合个人开发者，缺点是智能体容易“思维定势”，比如写后端时留下的某些假设，到前端阶段可能就不适用了。

我目前更倾向于混合模式：架构设计和任务拆解用一个智能体，具体实现用另一个智能体，测试验收再用第三个。这样既保证了架构的一致性，又避免了单个智能体上下文过长导致的“注意力涣散”。

3.4 流式接口与实时反馈的处理

全栈开发里绕不开的一个技术点是流式接口。智能体在生成代码时，如果涉及 SSE（Server-Sent Events）或 WebSocket，需要特别小心。因为流式接口的调试比普通 HTTP 接口麻烦得多，智能体很难通过简单的 curl 命令验证自己写的流式逻辑是否正确。

我的做法是，要求智能体在实现流式接口时，必须同时生成一个最小化的测试页面。这个页面用原生 JavaScript 的EventSource或WebSocket连接后端，把收到的每条消息打印到页面上。这样我打开浏览器就能直观看到流式数据是否正常推送、格式是否正确、断线重连是否生效。这个测试页面不需要多好看，但它是智能体自我验证的重要手段。

另外，流式接口的错误处理很容易被忽略。智能体生成的代码往往只处理“正常推送”的情况，对“客户端提前断开”“服务端异常中断”“消息格式错误”这些边界情况缺乏考虑。我会在规格里明确要求：流式接口必须包含心跳机制、错误事件类型、以及客户端重连策略。这些约束写进api-contract.yaml后，智能体实现时就会有所遵循。

4. 实操过程：从零搭建一个智能体驱动的全栈项目

4.1 环境准备与工具选型

先说明一点，下面提到的工具和框架都是我在实际项目中用过的，选型逻辑是“智能体框架要支持工具调用和记忆管理，全栈技术栈要足够主流以便智能体有足够的训练数据”。

智能体框架方面，我主要用两类：一类是平台化的智能体构建工具，适合快速搭建和可视化编排；另一类是代码优先的框架，适合深度定制和嵌入现有工程。平台化工具的好处是上手快，自带工具市场和调试面板；代码优先框架的好处是灵活，能跟你的 CI/CD 流程无缝集成。我通常会根据项目阶段来选：原型阶段用平台化工具快速验证，进入正式开发后切换到代码优先框架。

全栈技术栈方面，我固定用一套组合：后端 FastAPI（Python）或 NestJS（TypeScript），数据库 PostgreSQL，前端 React + Vite，状态管理用 Zustand 或 TanStack Query。这套组合的好处是：类型系统完善（Python 有 type hints，TypeScript 原生强类型），智能体生成的代码容易做静态检查；生态成熟，遇到问题容易找到参考；社区活跃，智能体的训练数据里这类代码占比高，生成质量相对稳定。

环境准备的具体步骤：

1. 初始化项目仓库，创建backend/、frontend/、.agent/三个目录。
2. 在.agent/下写好architecture.md、conventions.md、env.example。
3. 后端初始化：创建虚拟环境，安装 FastAPI、SQLAlchemy、Alembic、Pydantic，生成requirements.txt。
4. 前端初始化：用 Vite 创建 React + TypeScript 项目，安装 axios、react-router-dom、zustand。
5. 数据库初始化：本地用 Docker 跑一个 PostgreSQL 容器，记录连接串到.env。
6. 配置智能体框架：设置好文件读写工具、终端执行工具、以及项目根目录的工作区路径。

注意：.agent/目录建议加入.gitignore，因为里面的规格文件可能会频繁变动，而且可能包含一些内部约定，不适合提交到公开仓库。但api-contract.yaml和schema.sql这类权威文件应该放在项目正式目录下，.agent/里只放指向它们的引用或摘要。

4.2 第一个任务：让智能体生成数据库迁移脚本

这是整个流程的起点，也是最能体现 SDD 价值的环节。我不会直接跟智能体说“帮我建个用户表”，而是先把schema.sql写好：

CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), email VARCHAR(255) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL, nickname VARCHAR(50), status SMALLINT NOT NULL DEFAULT 1, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_users_email ON users(email); CREATE INDEX idx_users_status ON users(status);

然后给智能体的指令是：“读取.agent/schema.sql，使用 Alembic 生成对应的迁移脚本。迁移脚本需要包含 up 和 down 两个方向。注意gen_random_uuid()需要确保 PostgreSQL 的 pgcrypto 扩展已启用，如果未启用，在迁移脚本中先执行CREATE EXTENSION IF NOT EXISTS pgcrypto;。”

这个指令里包含了几个关键约束：读取权威 schema、使用指定工具、要求双向迁移、处理扩展依赖。智能体拿到指令后，会先读文件，然后生成类似这样的迁移脚本：

"""create users table Revision ID: a1b2c3d4e5f6 Revises: Create Date: 2026-01-15 10:30:00.000000 """ from alembic import op import sqlalchemy as sa from sqlalchemy.dialects import postgresql revision = 'a1b2c3d4e5f6' down_revision = None branch_labels = None depends_on = None def upgrade(): op.execute('CREATE EXTENSION IF NOT EXISTS pgcrypto;') op.create_table( 'users', sa.Column('id', postgresql.UUID(as_uuid=True), primary_key=True, server_default=sa.text('gen_random_uuid()')), sa.Column('email', sa.String(255), nullable=False, unique=True), sa.Column('password_hash', sa.String(255), nullable=False), sa.Column('nickname', sa.String(50), nullable=True), sa.Column('status', sa.SmallInteger(), nullable=False, server_default='1'), sa.Column('created_at', sa.TIMESTAMP(timezone=True), nullable=False, server_default=sa.text('now()')), sa.Column('updated_at', sa.TIMESTAMP(timezone=True), nullable=False, server_default=sa.text('now()')), ) op.create_index('idx_users_email', 'users', ['email']) op.create_index('idx_users_status', 'users', ['status']) def downgrade(): op.drop_index('idx_users_status', table_name='users') op.drop_index('idx_users_email', table_name='users') op.drop_table('users')

生成后，我会在终端里跑一遍alembic upgrade head，然后连数据库检查表结构。如果没问题，这个任务就算验收通过。如果有问题，比如索引名不对、字段类型不匹配，我会把错误信息贴回给智能体，让它修正。通常一到两轮就能搞定，比手写迁移脚本快得多，而且不容易漏掉索引和约束。

4.3 第二个任务：实现后端接口与业务逻辑

数据库就绪后，下一步是让智能体实现接口。这时候api-contract.yaml就派上用场了。我会先写好用户注册和登录的接口契约：

paths: /api/users/register: post: summary: 用户注册 requestBody: required: true content: application/json: schema: type: object required: [email, password] properties: email: type: string format: email password: type: string minLength: 8 nickname: type: string maxLength: 50 responses: '201': description: 注册成功 content: application/json: schema: $ref: '#/components/schemas/UserResponse' '409': description: 邮箱已存在 '422': description: 参数校验失败

然后给智能体的指令是：“读取.agent/api-contract.yaml和.agent/schema.sql，实现/api/users/register接口。要求：使用 FastAPI 的 APIRouter；密码使用 bcrypt 哈希；邮箱唯一性冲突返回 409；参数校验失败返回 422；响应体遵循conventions.md中的统一格式；数据库操作封装在 Repository 层。”

这个指令里，“封装在 Repository 层”是一个重要的架构约束。如果没有这条，智能体很可能直接在路由函数里写 SQLAlchemy 查询，导致业务逻辑和数据库操作耦合在一起。加上这条约束后，它会生成类似这样的结构：

# repositories/user_repository.py class UserRepository: def __init__(self, db: Session): self.db = db def get_by_email(self, email: str) -> User | None: return self.db.query(User).filter(User.email == email).first() def create(self, email: str, password_hash: str, nickname: str | None) -> User: user = User(email=email, password_hash=password_hash, nickname=nickname) self.db.add(user) self.db.commit() self.db.refresh(user) return user # routers/user_router.py @router.post("/register", status_code=201) def register(payload: RegisterRequest, db: Session = Depends(get_db)): repo = UserRepository(db) if repo.get_by_email(payload.email): raise HTTPException(status_code=409, detail="邮箱已存在") password_hash = bcrypt.hashpw(payload.password.encode(), bcrypt.gensalt()).decode() user = repo.create(payload.email, password_hash, payload.nickname) return success_response(data=UserResponse.from_orm(user))

这种分层结构的好处是，后续如果要加“用户列表”“用户详情”等接口，智能体可以复用 Repository 层的方法，不会重复写查询逻辑。而且单元测试也更好写，Repository 层可以单独 mock。

4.4 第三个任务：前端页面与接口联调

后端接口跑通后，前端就相对简单了。我会给智能体这样的指令：“读取.agent/api-contract.yaml，在frontend/src/pages/Register.tsx中实现注册页面。要求：使用 React Hook Form 做表单管理；邮箱和密码字段做前端校验；提交时调用/api/users/register；成功跳转到/login；失败时在表单上方显示错误信息；样式使用 Tailwind CSS。”

这里的关键约束是“使用 React Hook Form”和“样式使用 Tailwind CSS”。如果不指定，智能体可能会用受控组件手写表单状态，或者用内联样式，导致代码风格跟项目其他页面不一致。指定了具体库之后，生成的代码就能直接融入现有项目。

联调阶段最容易出问题的是CORS 和请求路径。智能体生成的前端代码可能直接写fetch('/api/users/register')，但开发环境下前端跑在 5173 端口，后端跑在 8000 端口，需要配置代理或 CORS。我会在conventions.md里提前写好：“前端所有请求走request.ts封装，baseURL 从环境变量VITE_API_BASE_URL读取；开发环境在vite.config.ts中配置 proxy 到后端。”这样智能体生成代码时就会自动遵循，省去联调时的手动修改。

4.5 验收与回归：让智能体自己跑测试

每个任务完成后，我会让“测试智能体”做一轮验收。具体做法是：读取api-contract.yaml，为每个接口生成 pytest 测试用例，覆盖正常流程和主要错误分支。然后运行pytest，把失败的用例和错误信息反馈给“实现智能体”去修复。

这个闭环非常重要，因为智能体生成的代码，最大的问题不是“跑不起来”，而是“边界情况没处理”。比如注册接口，正常注册肯定没问题，但邮箱重复、密码太短、邮箱格式错误这些情况，智能体可能只处理了一部分。通过自动化测试把这些边界情况固化下来，就能逼着智能体把逻辑补全。

我通常会要求测试覆盖率达到 80% 以上，核心业务逻辑（注册、登录、支付）要求 100%。这个标准写进conventions.md，智能体在实现时就会更有意识地处理各种分支。

5. 常见问题与排查技巧实录

5.1 智能体“幻觉”出不存在的方法或库

这是最常见的问题。比如智能体生成了一段代码，调用了db.query(User).filter_by_email(email)，但 SQLAlchemy 的 Query 对象根本没有filter_by_email这个方法。或者它 import 了一个fastapi_jwt_auth库，但你的requirements.txt里根本没装。

排查思路：先看报错信息，定位到具体文件和行号，然后把相关代码片段和报错一起贴回给智能体，让它修正。如果它连续两次修正都失败，说明它对这个库的 API 不熟悉，这时候我会手动查文档，把正确的用法告诉它，或者干脆自己改掉那一行。

预防措施：在conventions.md里列出项目使用的主要库和版本，并明确“不要引入新的第三方库，除非在规格中明确要求”。这样能大幅减少“幻觉库”的问题。

5.2 任务执行到一半“卡住”或“跑偏”

有时候智能体会在一个任务上反复尝试，每次生成的代码都略有不同，但始终通不过验收。这通常是因为规格本身有歧义，或者验收标准不明确。比如“实现一个好看的用户列表页面”，什么叫“好看”？智能体不知道，只能瞎猜。

解决办法：把任务拆得更细，把验收标准量化。比如改成“实现用户列表页面，要求：表格展示邮箱、昵称、状态、创建时间四列；状态用不同颜色的标签区分；支持按邮箱模糊搜索；分页每页 20 条；空状态显示‘暂无数据’。”这样智能体就有明确的目标，你验收时也有明确的检查项。

5.3 多智能体之间的“上下文冲突”

用多个智能体分工时，容易出现 A 智能体做的假设被 B 智能体推翻的情况。比如后端智能体把用户 ID 设计成自增整数，前端智能体却假设它是 UUID 字符串，联调时才发现对不上。

排查技巧：在任务交接时，强制要求输出一份“接口摘要”，包含字段名、类型、示例值。这份摘要写入.agent/handoff/目录，下一个智能体开始工作前必须先读这份摘要。这样即使两个智能体没有直接通信，也能通过文件系统对齐关键信息。

5.4 常见问题速查表

提示：这张表建议放在.agent/troubleshooting.md里，每次遇到新问题就追加一行。时间长了，它就成了你这个项目的“智能体开发避坑指南”，换新智能体或新成员时直接丢过去，能省很多解释成本。

5.5 几个我踩过的坑

坑一：让智能体一次性生成整个模块。早期我图省事，直接说“把用户模块做完”，结果它生成了二十多个文件，其中一半的文件名和路径都不符合项目规范，还有几个文件之间互相 import 导致循环依赖。后来改成按接口、按页面拆任务，每个任务只改 1-3 个文件，问题就少多了。

坑二：忽略环境变量和配置。智能体生成的代码经常硬编码数据库连接串、JWT 密钥、API 地址。这些硬编码在本地跑没问题，一上测试环境就炸。后来我在conventions.md里加了一条：“所有配置项必须从环境变量读取，禁止硬编码。环境变量清单见env.example。”并在验收时专门检查这一项。

坑三：不写 down 迁移。智能体生成 Alembic 迁移时，经常只写upgrade()不写downgrade()，或者downgrade()写得不对。这在需要回滚时非常致命。我的做法是在指令里明确要求“必须包含可执行的 downgrade 逻辑”，并在验收时实际跑一遍alembic downgrade -1再alembic upgrade head，确认能来回切换。

坑四：测试用例只覆盖 happy path。智能体写测试时，倾向于只测正常流程。比如注册接口，它只测“邮箱密码都正确”的情况，不测“邮箱重复”“密码太短”“邮箱格式错误”。我会在验收时手动检查测试用例，如果缺少边界情况，就要求它补上。这个习惯坚持下来后，线上 bug 率明显下降。

6. 工程化最佳实践：让 Vibe Coding 可持续

6.1 版本控制与智能体产出的管理

智能体生成的代码，必须像人类写的代码一样走版本控制。我的做法是：每个任务完成后，先人工 review 一遍 diff，确认没有明显问题后再 commit。commit message 里标注是哪个智能体、哪个任务生成的，方便后续追溯。

另外，.agent/目录下的规格文件也要纳入版本控制，但可以单独用一个分支或子目录管理。这样当规格变更时，能清楚地看到“规格变了 → 代码跟着变了”的对应关系。如果某次智能体生成的代码出了问题，可以回滚到上一个规格版本，重新生成。

6.2 持续集成中的智能体验收

我把智能体的验收流程接入了 CI。具体做法是：在 CI 配置里加一个 job，当代码 push 到特定分支时，自动运行智能体生成的测试用例，并检查代码风格（用 ruff 或 eslint）。如果测试不通过或风格检查失败，CI 会失败，阻止合并。

这个机制的好处是，智能体在本地“看起来没问题”的代码，到了 CI 环境可能会暴露环境依赖、路径问题、配置缺失等问题。让 CI 做最后一道防线，能有效防止“本地能跑，线上就炸”的情况。

6.3 智能体行为的审计与回溯

热词里提到了“智能体行为审计”，这在团队协作场景下很重要。我的做法是：每次智能体执行任务时，把完整的对话记录、工具调用记录、生成的文件 diff 都保存到.agent/logs/目录下。日志按日期和任务 ID 命名，方便检索。

这样做的好处是，当出现问题时，可以回溯到具体的对话轮次，看智能体是基于什么信息做出的决策。如果发现是规格文件有误，就修正规格；如果是智能体理解偏差，就调整指令措辞。长期积累下来，这些日志本身就是一份宝贵的“智能体调教手册”。

6.4 安全边界：智能体不能碰的东西

智能体再方便，有些东西也不能让它碰。我的红线是：生产环境配置、密钥管理、支付核心逻辑、用户隐私数据处理，这四类必须人工编写和审核，智能体只能生成测试代码或辅助代码。

另外，智能体执行的终端命令也要做限制。我会在智能体框架里配置一个命令白名单，只允许运行pytest、alembic、npm run build这类安全命令，禁止rm -rf、DROP TABLE、git push --force这类危险操作。这个限制在项目初期就要设好，不要等出了事故再补。

6.5 团队协作中的智能体使用规范

如果是团队使用，建议约定几条基本规则：第一，规格文件由架构师或技术负责人维护，智能体只能读不能写；第二，每个智能体任务必须有明确的负责人，负责验收和 commit；第三，智能体生成的代码在合并前必须经过至少一轮人工 review；第四，定期清理过期的对话日志和临时文件，避免仓库膨胀。

这些规则看起来繁琐，但实际执行下来，能避免很多“智能体生成了一堆代码，没人知道是谁让生成的、为什么这么写”的混乱局面。Vibe Coding 的核心是“人指挥智能体”，而不是“智能体替代人”，这个主次关系任何时候都不能颠倒。

7. 我个人的一些体会

用智能体驱动全栈开发这段时间，最大的感受是：写代码的时间确实少了，但想清楚“要写什么”的时间变多了。以前可以边写边想，现在必须在让智能体动手之前，把规格、约束、验收标准都想明白。这个转变一开始很不适应，但习惯之后发现，它逼着我把很多以前会忽略的细节提前考虑清楚，反而减少了后期的返工。

另一个体会是，智能体最擅长的不是“创造”，而是“执行”。你给它一个清晰的、有参考实现的、边界明确的任务，它能完成得又快又好。但你让它“设计一个高并发架构”或者“想一个创新的交互方式”，它给出的东西往往平庸且缺乏深度。所以 Vibe Coding 的定位应该是“高效执行器”，而不是“技术决策者”。架构选型、技术难点攻关、业务逻辑梳理，这些还是得人来主导。

最后分享一个小技巧：给智能体起名字。听起来有点幼稚，但实测有效。当你给不同的智能体起了名字（比如“后端老张”“前端小李”“测试小王”），你在写指令时会不自觉地更清晰、更有针对性，就像在跟一个具体的同事交代任务一样。而且当多个智能体协同工作时，你能更清楚地追踪“谁做了什么”“谁的问题导致失败”。这个心理暗示的小技巧，对提升协作效率意外地有帮助。