企业官网建设流程全解析

1. 从“写代码”到“聊代码”：Vibe Coding 到底在聊什么

第一次听到“Vibe Coding”这个词，我脑子里蹦出来的画面是：一个人对着编辑器敲几句自然语言，代码就自己长出来了。后来真正把一套全栈项目从零到一用这种方式跑通，我才意识到，它根本不是“让 AI 帮我补全几行代码”这么简单，而是一整套以智能体为核心执行单元、以自然语言为调度接口、以工程化交付为最终目标的开发范式。

说得再直白一点：过去我们写代码，脑子里要先想清楚数据结构、接口边界、状态流转，再一行行敲出来；现在这套范式里，你更像一个“技术导演”，把需求、约束、验收标准讲清楚，剩下的拆解、编码、联调、自测、修 bug，交给一个或多个智能体去跑。你的核心工作从“实现”前移到了“定义问题”和“把控质量”。

这篇文章我想聊的，就是这套范式落到一个真实全栈项目上，到底该怎么组织、怎么拆活、怎么防止它跑偏。适合两类人看：一类是已经用过 AI 辅助编码、但总觉得“只能写写小函数”的开发者；另一类是想把智能体真正接进团队研发流程、而不是停留在演示 demo 的技术负责人。我会把选型逻辑、目录结构、智能体分工、提示词模板、验收清单、踩过的坑全部摊开讲，尽量让你看完能直接照着搭一套。

先给一个我自己的判断：Vibe Coding 的成败，八成不在模型强不强，而在你有没有把它当成一个“需要工程化管理的协作者”来对待。把它当许愿池，它给你一堆能跑但没法维护的代码；把它当团队成员，配上清晰的接口约定和验收标准，它才可能稳定产出。

2. 为什么是“智能体驱动”，而不是“AI 补全”

2.1 补全模式和智能体模式的本质差别

很多人对 AI 写代码的印象还停留在 IDE 里的灰色补全，或者选中一段代码让它改。这种模式我称之为“补全模式”，特点是：上下文由人喂、任务由人切、结果由人验。它确实能提效，但天花板很明显——你没法让它独立完成一个跨文件、跨层级的任务，因为它没有“自己去找上下文、自己决定下一步”的能力。

智能体模式不一样。它有几个关键特征：能自主规划步骤、能调用工具（读写文件、跑命令、查文档）、能根据执行结果调整下一步。放到全栈开发里，这意味着你可以说“帮我把用户登录这条链路从前端表单到后端接口到数据库迁移全部打通”，它会自己拆成若干子任务，逐个执行，遇到报错自己读日志、自己改。

我实测下来，补全模式大概能省 20% 到 30% 的敲键盘时间，而智能体模式在边界清晰的任务上，能省掉 60% 以上的重复劳动。注意这个前提——“边界清晰”，这是后面反复要强调的点。

2.2 全栈场景为什么特别适合智能体

全栈开发有个天然特点：层次分明、约定成熟。前端组件、API 路由、服务层、数据访问层、数据库 schema，每一层该放什么、该怎么命名，行业里早有共识。这种“有章可循”的结构，恰恰是智能体最擅长的——它能依据约定推断出该在哪个文件、用什么模式写代码。

反过来，如果是那种高度依赖业务隐性知识、架构天天变的项目，智能体就容易懵。所以我的经验是：越规范的项目，智能体越好用；越混乱的项目，越要先人工把规范立起来，再交给智能体。

2.3 一个容易被忽略的前提：可验证性

智能体能不能自主干活，核心看它能不能自己判断“干对了没有”。全栈项目里，这件事是可以做到的：接口有返回、页面能渲染、测试能跑、类型能检查。只要我把这些验证手段配好，智能体就能形成“写—跑—看结果—改”的闭环。

这也是为什么我在项目一开始就坚持三件事：类型检查必须过、单元测试必须能跑、本地服务必须能一键起。这三样不是给智能体看的，是给它“照镜子”用的。没有镜子，它只能瞎猜自己写得对不对。

3. 项目整体架构：把智能体当成一个团队来编排

3.1 分层思路：谁负责什么

我把整个开发流程拆成了四个角色，每个角色对应一个智能体配置（可以是同一个模型的不同提示词，也可以是不同模型）：

这套分工的好处是每个智能体的上下文都更聚焦。规划智能体不需要看具体实现细节，编码智能体不需要操心整体架构，验证智能体只关心“对不对”。上下文越干净，输出越稳定。

3.2 目录结构约定：给智能体一张地图

智能体最怕的是“不知道东西该放哪”。所以我在项目根目录放了一个AGENTS.md，把目录约定、命名规范、常用命令全部写清楚。大致长这样：

# 项目约定 ## 目录结构 - src/app/ 前端页面与路由 - src/components/ 可复用组件 - src/api/ 前端请求封装 - server/routes/ 后端路由 - server/services/ 业务逻辑 - server/db/ 数据库访问与迁移 - shared/types/ 前后端共享类型 ## 命名规范 - 组件用 PascalCase，文件同名 - 接口路径用 kebab-case - 数据库表用 snake_case ## 常用命令 - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 跑测试：pnpm test - 数据库迁移：pnpm db:migrate

这个文件看起来平平无奇，但它是我踩了无数坑之后总结出来的最高性价比投入。有了它，智能体写代码时基本不会把文件放错地方，命名也不会五花八门。

3.3 接口契约先行：让前后端智能体不打架

全栈开发最容易出问题的地方就是前后端接口对不上。我的做法是：在写任何实现代码之前，先让规划智能体产出一份接口契约，用 TypeScript 类型定义写死，放在shared/types/里。

// shared/types/auth.ts export interface LoginRequest { email: string; password: string; } export interface LoginResponse { token: string; user: { id: string; email: string; nickname: string; }; } export interface ApiError { code: string; message: string; }

这份契约一旦定下来，前端智能体和后端智能体就各自照着它写，谁也不用猜对方。实测下来，接口联调的时间能砍掉一大半。

4. 核心实操：一个登录功能是怎么被智能体跑通的

4.1 第一步：把需求讲成“可执行的话”

我最初犯的错是需求写得太笼统，比如“做个登录功能”。智能体会给你一个能跑但漏洞百出的版本——没有密码加密、没有错误处理、没有限流。后来我改成这样写：

实现邮箱密码登录。要求：

1. 前端表单校验邮箱格式和密码长度（至少 8 位）
2. 后端接口 POST /api/auth/login，接收 email 和 password
3. 密码用 bcrypt 加密存储，登录时比对
4. 登录成功返回 JWT，有效期 2 小时
5. 失败返回统一错误结构，不暴露“用户不存在”还是“密码错误”
6. 同一邮箱连续失败 5 次锁定 15 分钟
7. 写单元测试覆盖成功、密码错误、账号锁定三种情况

你看，每一条都是可验证的。智能体拿到这种需求，基本不会跑偏，因为它知道验收标准是什么。

4.2 第二步：让规划智能体产出任务清单

我把上面这段需求丢给规划智能体，它返回的任务清单大致是：

1. 在shared/types/auth.ts定义请求响应类型
2. 在server/db/schema.ts增加 users 表和 login_attempts 表
3. 写数据库迁移脚本
4. 在server/services/auth.ts实现登录逻辑
5. 在server/routes/auth.ts暴露接口
6. 在src/api/auth.ts封装前端请求
7. 在src/app/login/page.tsx实现登录页
8. 写测试文件server/services/auth.test.ts

这份清单我会人工过一遍，重点看顺序对不对、有没有漏。比如它一开始漏了“锁定逻辑需要记录失败次数”，我补上之后它才把 login_attempts 表加进去。

4.3 第三步：编码智能体逐项执行

这一步是耗时最长的，但也是最省心的。我一般会按任务清单逐条喂给编码智能体，而不是一次性把整个清单丢过去。原因很简单：一次性丢过去，它的上下文会被撑爆，写到后面就忘了前面的约定。

每条任务我会附上相关文件路径和接口契约，比如：

任务：在 server/services/auth.ts 实现登录逻辑。 参考类型：shared/types/auth.ts 中的 LoginRequest、LoginResponse。 依赖：users 表、login_attempts 表已存在。 要求：密码比对用 bcrypt.compare，失败时更新 login_attempts，成功时清空失败记录。

这种“任务 + 上下文 + 约束”的三段式提示，是我试过最稳的写法。

4.4 第四步：验证智能体兜底

代码写完不代表完事。我会让验证智能体做三件事：

• 跑pnpm typecheck，看类型有没有错
• 跑pnpm test，看测试过不过
• 用 curl 打一遍接口，看实际返回对不对

curl -X POST http://localhost:3000/api/auth/login \ -H "Content-Type: application/json" \ -d '{"email":"test@example.com","password":"wrongpass"}'

验证智能体会把失败信息整理成结构化的问题清单，比如“类型错误：LoginResponse 缺少 user 字段”“测试失败：锁定逻辑未生效”。这份清单再交给修复智能体，形成闭环。

4.5 一个完整的提示词模板

我把上面这套流程固化成了一个模板，你可以直接抄：

## 角色 你是一名资深全栈工程师，负责实现指定任务。 ## 上下文 - 项目约定见 AGENTS.md - 相关类型定义见 shared/types/auth.ts - 相关数据表见 server/db/schema.ts ## 任务 [具体任务描述] ## 约束 - 遵循项目目录结构和命名规范 - 不引入新的第三方依赖，除非明确说明 - 所有函数必须有类型标注 - 错误处理统一使用 ApiError 结构 ## 验收标准 - pnpm typecheck 通过 - pnpm test 通过 - [具体功能验收点]

这个模板我用了大半年，基本没怎么改过。核心就是把“我以为它知道”的东西全部写出来。

5. 踩过的坑：那些文档里不会写的教训

5.1 上下文不是越多越好

我一开始的想法是“把整个项目都塞给智能体，它肯定更懂”。结果恰恰相反——上下文太长，它反而抓不住重点，经常在无关文件里瞎改。后来我改成只给相关文件 + 明确的任务边界，输出质量立刻上了一个台阶。

我的经验值是：单个任务的上下文控制在 2000 到 4000 token 之间最舒服。超过这个量，就要考虑拆任务了。

5.2 智能体会“自作主张”加功能

这个坑我踩得最狠。有一次让它实现一个简单的列表接口，它顺手给我加了分页、排序、缓存、限流，代码量翻了三倍，还引入了两个我没要求的依赖。后来我在提示词里加了一条硬约束：“只实现明确要求的功能，不要添加任何未提及的特性。”这条一加，代码立刻清爽了。

5.3 测试是智能体的“安全带”

我强烈建议：每个核心模块都先让智能体写测试，再写实现。听起来反直觉，但效果很好。因为测试本身就是一份可执行的规格说明，智能体照着测试写实现，跑偏的概率大大降低。而且测试跑通的那一刻，你就知道它真的做对了。

5.4 数据库迁移要人工把关

智能体写业务逻辑很靠谱，但写数据库迁移脚本我会格外小心。因为它不知道生产环境的数据现状，容易写出破坏性的迁移。我的做法是：迁移脚本必须人工 review，尤其是涉及删列、改类型的操作。

5.5 常见问题速查表

6. 工程化落地：让这套范式能长期跑下去

6.1 把提示词当代码管理

我现在的做法是：所有提示词模板都放在仓库里，跟代码一起版本管理。目录大概是这样：

prompts/ planning.md 规划智能体提示词 coding.md 编码智能体提示词 verification.md 验证智能体提示词 fix.md 修复智能体提示词

这样做的好处是：提示词改了有记录，团队里谁都能用同一套，新人上手直接看这几个文件就懂流程了。

6.2 建立“智能体友好”的代码规范

有些规范是给人看的，有些是给智能体看的。我总结了几条对智能体特别友好的规范：

• 文件职责单一：一个文件只做一件事，智能体更容易定位
• 导出显式：所有对外接口用export明确标出，别用隐式导出
• 注释写“为什么”：智能体看注释能理解设计意图，改代码时不容易破坏原意
• 避免魔法值：常量抽出来，智能体改的时候不会漏

6.3 人工 review 的边界在哪

我的原则是：智能体负责“实现”，人负责“决策”。具体来说，这几类事必须人工把关：

• 架构选型（用什么框架、怎么分层）
• 数据模型设计（表结构、索引）
• 安全相关（认证、授权、加密）
• 对外接口契约（一旦定了改动成本高）
• 数据库迁移脚本

而像 CRUD 实现、组件编写、测试用例、样式调整这些，基本可以放手让智能体跑。

6.4 团队协作中的注意事项

如果是一个团队用这套范式，有几件事要提前对齐：

• 统一提示词模板：不然每个人产出风格差异巨大
• 统一 AGENTS.md：这是智能体的“员工手册”，必须一致
• 统一验收标准：typecheck、test、lint 必须全过才算完成
• 定期回顾提示词：哪些提示词效果好、哪些老出问题，定期优化

我见过一个团队因为没统一模板，三个人用三种风格写代码，最后合并的时候冲突一大堆，反而比不用智能体还慢。

7. 这套范式适合谁，不适合谁

7.1 适合的场景

• 中后台系统：结构规范、CRUD 为主，智能体效率极高
• MVP 快速验证：需求明确、时间紧，智能体能快速出原型
• 重复性模块开发：比如一堆相似的列表页、表单页
• 测试用例编写：智能体写测试又快又全

7.2 不适合的场景

• 高度创新的算法研发：需要人的直觉和试错
• 架构频繁变动：智能体刚熟悉结构，结构又变了
• 强依赖业务隐性知识：智能体不知道的那些“潜规则”
• 安全敏感的核心模块：必须人工主导

7.3 一个务实的预期

我不想把话说得太满。这套范式不是“AI 取代程序员”，而是把程序员从重复劳动里解放出来，去做更有价值的决策工作。我实测下来，一个中等复杂度的全栈项目，用这套方式能省掉大概一半的编码时间，但前期在规范、提示词、验收标准上的投入，大概要占整个项目 20% 的精力。

这笔账划不划算，取决于你的项目规模和团队成熟度。项目越大、越规范，收益越明显；项目越小、越随意，可能还不如自己写快。

8. 我个人的几点体会

用这套范式做了几个项目之后，我最大的感受是：它逼着我把“想清楚”这件事做到位。以前写代码可以边写边想，现在不行——你没想清楚，智能体就给你一堆似是而非的东西，你还得花更多时间去改。

另一个体会是：规范的价值被放大了。以前规范是“最好有”，现在是“必须有”。因为智能体不会像人一样“凭经验猜”，它只会严格按你给的约定执行。约定不清，它就乱来。

最后分享一个小技巧：每次让智能体干活之前，先问它一句“你打算怎么做”。让它先输出计划，你确认没问题再让它动手。这一步能拦掉大部分跑偏的情况，成本极低，收益极高。我现在的习惯是，凡是超过三个文件改动的任务，都先让它出计划，我点头了再执行。

这套东西还在快速演进，我也不敢说自己摸到了天花板。但至少目前这套“契约先行 + 角色分工 + 验证闭环”的组合，是我试过最稳的。你要是也在折腾类似的东西，欢迎交流，踩过的坑越多，路才越好走。