企业官网建设流程全解析

今年圈子里最热的开发词，Vibe Coding 绝对算一个。起因是 Karpathy 在 2025 年初随口提了一句“程序员开始边哼调子边写代码”，这个说法就像病毒一样扩散开来——开发者不再逐行敲键盘，而是用自然语言描述需求，AI 直接把代码生成出来，人负责感受整体节奏，发现问题就丢一句反馈，AI 再迭代一版。听起来很玄，但背后其实是代码生成能力跨过了一个临界点：模型从“补全下一个 token”进化成了“理解意图并执行任务”。

我身边不少做全栈开发的朋友，现在已经开始把工作流切换成这种模式。前端页面、后端接口、数据库表结构、部署脚本，整条链路都能交给 AI 智能体去推进，人更像戴着工程帽的指挥官。这篇文章我想聊透的就是这件事：Vibe Coding 背后的智能体驱动机制到底是什么，它怎样把全栈开发的流程重新切片，哪些环节能放手、哪些环节必须把住方向盘，以及如何把它沉淀成一套能长期迭代的工程化开发范式。

不管你是被 Vibe Coding 点燃的独立开发者，还是想帮团队提效的 Tech Lead，下面这些内容应该都有参考价值。我会把原理、工具、流程和踩坑经验放在一起说，尽量做到看完就能在真实项目里试一把。

1. Vibe Coding 的“底层真相”：是什么让它变成新一代开发范式

1.1 从“补全”到“执行”：智能体才是真正的拐点

很多人把 Vibe Coding 理解成“让 AI 凭空生成代码”，这其实只看到了冰山一角。Vibe Coding 真正依赖的不是某个聊天窗口里的代码补全，而是能够自主行动的智能体。智能体的工作循环大致是：感知当前仓库状态，制定一个改动计划，生成补丁，执行测试或构建命令，观察结果，发现问题再回到计划继续修。它不是一个单向的输出机器，而是一个具备“感知—行动—反馈”闭环的执行单元。

这个区别很关键。传统 IDE 里的代码补全，本质是“猜你接下来要敲什么”，模型看到前面的字符，补出后面几十个字符就已经很了不起了。但 Vibe Coding 场景下，你给一句“把订单接口加上库存校验，不够就返回 400”，智能体需要自己找到订单服务、找到库存表、确认校验逻辑、写测试、跑一遍验证。这一整套动作里包含大量隐性决策：改哪个文件、用什么错误码、怎么处理事务回滚。换句话说，你从“写代码”变成了“提需求、验结果”。

我见过不少人第一次上手时会犯同一个错误：把 Vibe Coding 当成搜索引擎用。对着聊天窗口问“库存校验怎么写”，拿到一段代码粘贴进去就完事。这不是智能体驱动，这只是在用更昂贵的方式复制粘贴。真正的智能体驱动开发，是把自然语言当成一种可执行的“委托语言”，你委托给 AI 一个完整的小任务，它自主完成、自证结果，你只负责验收。

这里有个很贴切的类比：以前写代码像自己下厨，从洗菜切菜到调味装盘全程亲力亲为；传统 AI 辅助像是多了个帮你递调料瓶的帮厨；而智能体驱动则像你把一整道菜交给副厨去炒，你在旁边尝咸淡、看火候、决定要不要翻锅。Vibe Coding 这个“Vibe”说的正是尝咸淡那个动作——不是真的随心所欲，而是用直觉和品味去引导执行。

1.2 Vibe Coding 与传统 AI 辅助编程的边界

要理解 Vibe Coding 在整个开发方式光谱里的位置，我一般习惯把开发模式分成四档，对比看会非常清晰。

从这张表能看出来，Vibe Coding 和传统 AI 辅助之间不是简单的升级关系，而是“人机协作的位置”变了。传统 AI 辅助里，人是真正的驾驶员，AI 只是副驾驶；Vibe Coding 里，AI 变成了主驾驶，人坐到了导航和监考的位置。这个转变带来一个非常直接的好处：人的注意力不用消耗在语法、样板代码和琐碎的调试上，可以更集中在“这个功能到底应该怎么设计”。

但危险也在这。坐副驾驶的人如果睡着了，车就可能冲下悬崖。Vibe Coding 的核心矛盾从来不是“AI 写的代码能不能用”，而是“AI 把代码写得越来越快，人的判断跟不跟得上”。这就解释了为什么现在大家开始强调“智能体驱动”而不是单纯“Vibe Coding”——前者是在 Vibe Coding 的生成能力之上，增加了一整套工程化约束。

1.3 为什么全栈开发领域最先被改写

同样是软件开发，全栈开发是受智能体冲击最明显的领域，这不是偶然。

全栈开发有一个先天特点：链路长、技术栈杂、重复度高。今天你可能在写 React 组件，下午就要调 Prisma 的数据库查询，晚上还得研究 Dockerfile 怎么优化。每一层都有大量“模式化”的工作：CRUD 接口、表单校验、列表页、详情页、部署配置。这些代码的特征是熟练工友好、复杂度高但创新度低，恰恰是语言模型最擅长生成的类型。

另一个更微妙的原因是上下文切换成本。传统全栈开发者最头痛的事情不是某个技术不会，而是频繁在前后端之间切换导致大脑缓存失效。你刚记住前端组件状态怎么流转，转头就要去理清数据库事务的隔离级别。智能体没有这个负担，它可以瞬间把思维从一个文件切到另一个文件，而且永远记得你几个会话之前改过什么。

我用一个例子来感受差异。以前做一个带用户认证、任务管理的小型全栈应用，我的典型时间分配是：数据库模型设计占 20%，后端接口和校验占 30%，前端界面和联调占 40%，剩下 10% 花在部署和环境配置上。在智能体驱动模式里，数据库模型、接口、前端骨架都可以交给 AI 在极短时间内生成，人真正要花时间的变成了“确认数据权限边界”“验证业务流程是否符合预期”“评审 AI 生成的校验逻辑是否严密”。这本质上是一次工程重心的迁移，从“写得出”迁移到“想得清楚、审得明白”。

2. 工程化范式转型：从“手写每一行”到“编排智能体”

2.1 传统开发流程与智能体驱动流程的差异

传统全栈开发的流程可以简化成一条直线：需求分析 → 架构设计 → 编码实现 → 测试验证 → 上线发布。这条线天然适合人脑工作，因为每个阶段都需要大量显式的思考决策，比如接口怎么定、表结构怎么分、权限模型怎么设计。但也正因为是直线，反馈循环特别长。你可能花了两天写接口，联调时才发现自己设计的请求参数在真实使用场景里根本不合理，只能推倒重来。

智能体驱动开发把这条直线打散成了无数个小循环。每个小循环都是：提出一个明确的小任务 → 智能体实现 → 跑测试或构建 → 人工评审 → 进入下一个小任务。表面上每一步的产出变小了，但整体节奏反而快了，因为错误的代价被大幅压缩。我第一次在真实项目里感受到这种差异时，主观体验是“过去是一周崩溃一次，现在是一小时崩溃一次，但每次都是小崩，五分钟就能修回来”。

这里要强调一点：不是所有环节都适合交给智能体。需求本身来自业务方，架构决策影响全局，这些是人的主场。智能体真正接管的是“实现层”——在边界和约束已经划清楚之后，把代码写出来、把细节补齐、把测试跑通。所以工程化范式的本质是重新划定人机边界：人负责“做什么、为什么、验收标准”，AI 负责“怎么实现、怎么补齐、怎么自测”。

2.2 把“Vibe”变成“可控”：工程化三板斧

Vibe Coding 最被人诟病的一点是“不可控”。但我在实践里的体会是，不可控的不是 AI，而是工程方法。如果把下面这三样东西做到位，Vibe Coding 完全可以被驯化成一条可控的流水线。

第一样是契约。契约指的是数据模型、API 签名、组件 Props 这类跨模块的约定。智能体在同一段代码里改得再天马行空，也必须遵守已经定义好的接口形状。我在项目里一般会让智能体先定义 TypeScript 类型和 Zod Schema，之后再写实现。这样前后端都被同一个类型约束住，AI 很难在修改时“顺手”把一个字段名改飞。

第二样是检查点。检查点是“Definition of Done”，也就是每个任务结束之前必须完成的验证动作。比如“写完订单接口后必须运行一次测试和构建”“改完组件后必须跑一遍类型检查”。检查点的作用是把验收这件事从“人肉回忆”变成“命令强制”。智能体天然会顺着指令走，只要你把检查点写进系统约定，它每次都会执行，这就规避掉了“AI 改完代码直接说完成了、其实根本没跑”的尴尬。

第三样是上下文。上下文包括项目文档、架构说明、技术栈约定、常用命令、历史决策记录。很多 Vibe Coding 翻车，是因为智能体根本不了解项目背景就开始乱写。你给它一个干净的AGENTS.md或CLAUDE.md，它就像是拿到了项目说明书，生成质量会立刻上一个台阶。这三板斧合在一起，就把不可预测的“Vibe”变成了可以被流程夹住的生产力。

2.3 角色重新分配：开发者、架构师、审阅者

转向智能体驱动还有一个很实际的问题：团队里每个人的角色会微妙地变化。过去我们按技能分工：前端工程师、后端工程师、运维工程师。现在更合理的分工变成了：架构编排者、实现执行者、验收把关者。架构编排者决定哪些任务可以委托、以什么顺序委托；实现执行者就是智能体；验收把关者负责评审代码、验证行为是否符合预期。

这个转变对资深开发者和新人的影响完全不同。资深开发者的核心竞争力从“代码写得快”变成了“判断力强”——知道哪个地方容易出问题，知道什么时候应该让 AI 停下来，知道哪些重构值得做。新人的成长路径却变得非常有意思：过去写代码要大量输入才能形成手感，现在新人可以在一天内生成一个全栈应用，再通过评审 AI 代码来学习“什么是有问题的写法”。我甚至见过一些转行学习者，通过系统性地对比“AI 的答案”和“资深工程师的修正”，学得比之前看教程快得多。

当然，角色变化也意味着一种新的风险：团队里如果每个人都在问 AI、AI 生成、然后无人真正理解代码，那这个项目就变成了一个黑盒。所以无论角色怎么变，团队里至少要保证有一个人足够理解核心架构，能回答“为什么要这样做”的问题。工具可以交付代码，但工具不会为故障承担责任。

3. 完整实操：用智能体从零跑通一个全栈项目

3.1 开工之前：把仓库与上下文改造成“智能体友好”

任何一次 Vibe Coding 全栈项目，第一步都不是写业务代码，而是先给智能体做“入职培训”。一个陌生的智能体进入你的仓库，它默认只知道泛化的编程知识，不知道你的工程约束、命名习惯和测试方式。你要做的，是把这些信息固化在仓库里。

我的标准做法是这样的：初始化 Git 仓库后，立刻创建两个目录，docs/和scripts/，并在根目录放一个AGENTS.md文件。这个文件是智能体开始任何工作前都要先读取的“员工手册”。内容不需要很长，但必须覆盖四个关键信息：技术栈、常用命令、代码组织约定、禁止事项。

# 技术栈 - Next.js 14 App Router，TypeScript 严格模式 - Prisma + PostgreSQL，本地开发可用 SQLite - 样式 Tailwind CSS，组件目录使用 kebab-case - 测试使用 Vitest，端到端测试使用 Playwright # 常用命令 - 本地启动：pnpm dev - 数据库迁移：pnpm db:migrate - 类型检查：pnpm typecheck - 单元测试：pnpm test # 代码组织约定 - 所有 API 入参必须使用 zod schema 做校验 - 业务逻辑放在 server/ 目录，不要散落在页面组件里 - 数据库 schema 变更必须先提供 migration 计划，确认后再执行 # 禁止事项 - 不要手动修改 Prisma Client 生成的文件 - 不要在没有跑测试的情况下标记任务完成 - 不要引入 package.json 里不存在的依赖

这个文件看起来不起眼，但它决定了智能体输出的“下限”。我在多个项目里测试过，有这份手册和没这份手册，AI 写出不符合规范的代码概率差出好几倍。尤其是“禁止事项”这一块儿，能挡掉很多 AI 的无意识行为，比如偷偷升级依赖、直接改自动生成文件。

3.2 从需求提示词到第一版骨架

完成仓库初始化之后，就要开始用提示词和智能体交互了。很多人在这一步会踩同一个坑：一次性给出一个巨大无比的需求。比如“帮我做一个完整的任务管理系统，要用户、项目、任务、评论、通知，页面也要好看”。这种提示词对于智能体来说已经超出单轮会话的合理处理范围，结果往往是一个看似热闹、实则漏洞百出的骨架。

我的经验是把需求拆成“轮次”，每一轮只让智能体完成一个可验证的交付物。第一轮通常是“理解与规划”，不直接动代码。举个例子，我会这样发指令：

任务：阅读仓库根目录的 AGENTS.md、package.json 和 README，用列表形式总结当前项目的技术栈和已有结构，并给出你认为的第一版全栈应用文件骨架。在我确认之前，不要创建任何文件。

这一步看起来保守，但特别有用。它强迫智能体先建立对项目的完整认知，也让我有机会纠偏：如果 AI 对技术栈理解错了，比如以为用的是 Express 而不是 Next.js，现在改还来得及。等它输出骨架并确认之后，再进入第二轮“创建目录与配置”。

任务：按我确认的骨架创建目录和配置文件。本轮只需要完成基础设施，不要写任何业务逻辑。完成以后运行 pnpm typecheck 并汇报结果。

这里的关键是“每轮只做一件事、每轮都有验证动作”。把任务粒度控制在一两个文件级别，智能体的成功率会非常高，同时你的人工评审压力也会小很多。全栈开发本身就复杂，好的工程化范式不是让 AI 一次性挑战所有复杂度，而是把复杂度拆成它可以一口吃下的小块。

3.3 后端、数据库与接口的实现细节

当骨架搭起来，项目正式进入业务实现阶段。这里我最想分享的心得是：数据库和接口这两层，必须让智能体先把设计拿出来，再写代码。

很多开发者习惯直接丢提示词“给我建一个用户表和订单表”。智能体确实能一秒生成 Schema，但设计质量完全看运气：外键缺失、索引没建、枚举类型定义不合理，这些都是常见毛病。所以我要求智能体先输出数据模型设计，等人工确认再落地。这既控制了质量，又让智能体自己保留了对模型的理解，后续生成接口时会和 Schema 高度一致。

一个典型的后端任务提示词大概长这样：

任务：为“任务管理系统”设计数据库模型。 上下文：用户可创建项目，项目下可以建立多个任务，任务有状态字段。 要求： 1. 先输出 Prisma Schema 草案，标出外键关系和索引； 2. 说明每个枚举值的使用场景； 3. 等我确认后再修改 schema.prisma 并生成 migration； 4. 不要现在实现接口。

这种提示词会把 AI 拉回“先想再做”的模式。Schema 确认之后，接口实现就可以放开让智能体做。这里可以再加一条纪律：要求它先基于 Schema 生成一组 zod Schema 作为 API 契约，再写对应的 service 函数。这样无论 AI 把代码写成什么样，至少入参出参的形状是被锁死的，前端后续对接时不会莫名其妙多出来一个篡改的字段。

到这一步，真正能体现智能体价值的是“写完就跑”的自觉。在规则文件里写清楚“完成后必须运行 pnpm test 和 pnpm build”，你会发现智能体经常真的发现自己的类型错误并当场修掉。这个自证环节，比它闷头输出十段代码更有价值。

3.4 前端联动与“缝合”技巧

全栈项目里前端是最容易“风格漂移”的部分。智能体生成的前端页面，经常出现这里一个按钮风格、那里一个弹窗风格，好像两个不同的人写的一样。这是因为前端组件库和设计系统的约束，不像后端类型检查那样硬性。

我的做法是给前端任务一个专门的前置步骤：确认设计约束。如果项目里有现成的 UI 组件库，比如 shadcn/ui 或 Ant Design，我要求在规则文件里写明“组件样式统一使用 ui/ 目录里的基础组件，不自己写大量内联样式”。如果没有组件库，至少要指定颜色变量和间距变量的位置。

前端和后端缝合时，最常见的坑是类型对不上。智能体在后生成了接口，又在前面写了一个 fetch，但它可能凭感觉构造请求参数，跟后端 schema 不一致。我一般会让智能体先手动读一遍 API 契约文件，或者直接生成类型安全的客户端。以 Next.js 项目为例，如果用了 OpenAPI 定义了所有接口，可以让智能体在scripts/里加一个自动生成 API Client 的命令，前端只调用生成的 client，绝不手写请求 URL。这样就把“缝合”变成了一件机械工作，留给 AI 去完成。

如果前端是从别的工具生成的视觉稿，比如 v0 或 Figma 导出，记得要把这些代码当作“视觉参考”而不是“最终代码”。我会先把视觉稿里可复用的组件抽到项目的ui/目录，再让智能体把数据绑定到真实接口上，很多样式污染和组件滥用的问题会自然消失。

4. 工具选型：不同智能体怎么搭配更高效

4.1 三类智能体工具的分工逻辑

工具太多也会让人焦虑。其实主流智能体工具大致可以分成三类，每一类的分工逻辑是不同的。

第一类是 IDE 内嵌智能体，典型代表是 Cursor 这样的 AI 编辑器。它最大的优势是“人还坐在代码里”，你在编辑器里看到的文件和 AI 改的文件是同一个，评审 diff、局部回滚都非常顺手。这类工具适合日常开发，尤其适合需要高频迭代的时段。

第二类是命令行智能体，像 Claude Code、Gemini CLI 这类在终端里运行的工具。它们不用依赖某个编辑器，可以执行更复杂的多步骤任务，例如批量重构、自动修复测试失败、跨多个目录搜索。这类工具更像是“能接管终端的外包工程师”，但也更需要你用规则文件给它定边界。

第三类是一键生成型工具，比如 Bolt.new 这类浏览器里的全栈生成器。它们对冷启动极其友好，你描述一个想法，它直接给你生成可运行的前后端项目，甚至能直接预览。缺点是项目一旦复杂，控制权就迅速衰减。我把这类工具定位成“灵感孵化器”和“原型加速器”，不适合作为正式产品的唯一开发环境。

4.2 主流工具横向对比

我根据自己的使用经验，把这四类场景下的常见工具做了一个横向对比：

组合拳比单一工具更重要。就我自己而言，日常主力是 IDE 内 Agent，因为大部分工作流里我还是希望自己看得到代码；遇到“跑完测试再报错清单”这类需要多步操作的事，我会切到命令行 Agent，让它在终端里自动执行循环直到通过；偶尔想快速验证一个产品点子，才会用全栈生成器花半小时做个能点的 Demo。这套组合下来，既有速度又不失去掌控感。

4.3 上下文管理与规则文件工程化

工具选定了，接下来最值得花时间的工程化动作，是把上下文管理好。智能体的能力上限，很大程度上等于它看到的信息质量。你不可能每次都把整个代码库丢给模型，也不应该期待它跟你有相同的记忆。你需要做的是把项目知识外置到文件里，让智能体“知道该去哪里看”。

我的做法是在不同层级放不同的上下文文件。根目录的AGENTS.md放全局约定；后端目录放一份AGENTS.md，专门描述业务逻辑和数据库规范；前端目录放一份，描述 UI 组件库和视觉规范。这样当智能体处理某个子模块时，它能读到更精准的信息，而不是被根目录的泛泛说明误导。

另外，我强烈建议在docs/decisions/里记录关键架构决策。比如“为什么订单表使用软删除”“为什么缓存选 Redis 而不是 Memcached”。这些决策如果不记录下来，三个月后新加入的智能体可能会在重构时把它推翻。有了决策记录，你可以在每次任务开始时要求智能体先扫描决策目录，减少“重复发明轮子”或“推翻历史设计”的情况。

最后一点是会话记录。智能体的工作记忆有限，跨会话之后它基本会忘记之前做了什么。我习惯了让智能体在完成每个阶段任务后，把当前状态和下一步计划写进docs/progress.md。这样做有两个好处：第一，下次会话你能快速告诉 AI “按 progress.md 继续”；第二，就算你换一个工具，新工具也能通过这个文件无缝接管。

5. 工程化治理：让 AI 生成代码能进主干

5.1 全程检查点：测试、构建、评审

把智能体生成的代码直接合并到主干，这几乎是一场灾难。生成速度越快，越需要工程化的闸门来控制质量。我在项目里会强制设置三层检查点，一层在本地，一层在远程，一层在人工。

本地检查点是智能体完成任务的必要条件。我要求的“完成”不是“代码写好”，而是“命令跑过”。在每个任务提示词的 Definition of Done 里，我会明确写：运行pnpm typecheck、pnpm test、pnpm build，并把输出贴回来。这能挡住一大半低级错误。

远程检查点指的是 CI。让每次合并请求自动跑 lint、测试和构建，智能体和团队成员都要被同样的规则约束。CI 的好处是它人类无法绕过，也不依赖人的心情。我见过太多时候，开发者嘴上说“我先跑一下测试”然后直接 push，CI 一跑，红了一大片。智能体也差不多，如果没有强制手段，很多 AI 生成任务会直接宣布完成。

人工评审是最后一个闸门。即使是智能体开发的范式，代码评审也不应该消失，只是评审的关注点变了。人不需要逐行看语法和命名，但要看三件事：第一，改动是否符合本来的业务需求；第二，是否覆盖了异常分支和安全边界；第三，是否引入了不必要的复杂度。我经常跟团队说，AI 赋予了代码生命，但人是它的监护人。

5.2 安全检查：依赖、密钥、敏感操作

智能体驱动的开发节奏快，安全问题反而更容易被放大。我最担心的不是 AI 的代码逻辑本身，而是它在“看不见的角落”里埋雷。

第一个雷是幻觉依赖。AI 经常引用一些包名，看起来合理，实际根本不存在。或者更阴险一点，它引用的包确实存在，但是一个多月前刚发布的、只有几十个下载量的可疑包。这已经超出了技术和工具的范围，变成一个供应链风险。我的对策是要求智能体在引入新依赖之前必须告知理由，并在我确认之后才能修改package.json。即使确认了，我也习惯使用npm audit或pnpm audit先看一遍风险报告。

第二个雷是密钥和敏感配置。AI 生成的代码里，偶尔会暴露.env内容，或者硬编码数据库连接字符串。规则文件里我会明确写：任何密钥变量只能在.env中引用，不得出现在提交代码里。如果发现智能体把 secrets 写进配置文件，我会立刻撤销那部分改动并要求它在安全策略里重新学习。

第三个雷是敏感操作。数据库迁移、删除表、重置数据、批量更新，这些操作在 AI 手里必须加上“先预览，后执行”的约束。在数据库相关的提示词里，我通常会写“生成 migration 文件即可，不要直接执行；只在得到人工确认后运行”。这条小小的限制，能避免很多“哦 no，我把生产环境的表删了”的惨案。

5.3 架构与文档沉淀：不让项目变成“一团乱”

Vibe Coding 模式下最常见的失败曲线，是项目前两周进展神速，第三周开始寸步难行，所有改动都很容易互相干扰。原因很简单：AI 生成代码的速度快，但持续演进的前提是架构清晰。如果每个智能体都在一个越来越大的代码堆上自由发挥，迟早会纠缠成一团乱麻。

避免这个问题的关键就是文档沉淀。要求智能体在完成每一个重要模块后，同步更新对应的docs/文档。比如数据库模型变了，就更新docs/data-model.md；新加了一个决策，就写一篇docs/decisions/xxx-ADT.md。这不是形式主义，而是为了让下一轮智能体有据可查。如果没有这些文档，智能体会在重复探索上浪费大量上下文窗口，甚至可能因为看不全架构，在局部优化时摧毁整体设计。

另一个习惯是“定期复盘重构”。智能体也好，人也罢，连续输出之后都会积累技术债。我每个迭代周期会让智能体做一个只读审计任务，内容大概是：找出重复代码、圈复杂度最高的模块、被过度耦合的地方，以及建议的重构顺序，但明确要求“不要执行任何重构”。拿到这份审计报告，我再决定哪些重构有切实收益、哪些应该暂缓。有了这个机制，项目既保住了 AI 带来的速度，又不会让技术债滚成雪球。

6. 真实翻车现场与排查日志

6.1 高频事故复盘

Vibe Coding 最大的谎言是“AI 几乎不会错”。真实的现场是：AI 会以各种意想不到的方式翻车，但翻车的模式高度相似。把这些事故复盘下来，会比自己多踩几遍坑划算得多。

第一个高频事故是“幻觉依赖”。有一次我让智能体给图片生成加一个裁剪功能，它在代码里引入了crop-img-helper这个包，我当时没细看直接跑安装，结果 npm 报错说包不存在。这就是典型幻觉。从那以后，我用一条硬性规则锁死了这个问题：新依赖先pnpm view <package> version再过审，算是把这条防线焊死了。

第二个高频事故是“AI 的乐观主义”。智能体实现完一个功能后，默认输出是“已完成”，可它根本没有跑过测试，或者测试根本没有覆盖关键逻辑。更隐蔽的情况是它写了测试，但断言写得稀烂，比如断言response.status是 200，却不检查业务字段是否正确。现在我收到“完成”消息的默认反应不是信任，而是看它贴出来的命令输出和 diff。

第三个高频事故是“跨文件串改”。AI 写一个接口时，顺手把另一个服务里一个看起来名字很像的字段改了，结果牵连出好几个文件编译失败。智能体又会在错误追踪里陷入局部修复，改一个报错又冒出一个新报错，循环好几轮。对付这个问题的办法有两个：一是任务拆分尽量小，二是遇到连环报错时立刻打断它，说“先不要继续修改，分析一下这个错误的源头，列出所有相关文件，等你给我方案再动”。

6.2 常见问题速查表

实践里的问题其实高度集中，我把它们整理成一个速查表，方便你在现场直接对照排查。

这个表格里的每一项，我都亲自经历过至少一遍。最大的感悟是：八成故障其实不是 AI 能力不足，而是我们没有提前给它划定边界，没有在流程里设置检查点。

6.3 我自己的长期经验与心态调整

走到最后，想聊点更真实的东西。Vibe Coding 这个热词正在快速褪去新鲜感，但它留下的开发范式会沉淀下来。我自己的心态也从“哇，AI 什么都能写”变成了“我要怎么设计一个 AI 摔不坏的轨道”。

我现在已经不太区分 Vibe Coding 和普通开发了。日常工作中，AI 就是一个随时待命的智能体，我需要它的时候就给它一个清晰的小任务，它完成我就验，不好我就打回去。真正让项目走远的，不是某个工具多惊艳，而是项目有没有可被理解的架构、有没有能自动验证的测试、有没有持续更新的文档。这些工程化底座，AI 是替代不了人去建立的。

当然，我也承认 Vibe Coding 改变了我写代码的方式。现在更愿意把精力花在“定义”上——定义数据模型、定义接口契约、定义验收标准，剩下的大量实现工作交给智能体。它像一个反应极快但需要你的品味来指导的执行者，你把方向盘握得越稳，它跑得就越让人放心。

如果你正准备把团队或自己的开发流切换到这个模式，我只有一条最朴素的建议：不要急着让 AI 生成得更多，先把如何验收 AI 的产出想清楚。真做到这一步，你会在项目里感受到一种很独特的松弛感——所有环节都在飞快运转，但你心里清楚，每一处关键的转折点，都是由人完成的判断。