企业官网建设流程全解析

1. Vibe Coding 的两面性：它解决了什么，又制造了什么

最近这半年，Vibe Coding 这个词几乎被说烂了。我自己的项目群里，隔三差五就有人甩出一句“我用 AI 两小时写了个工具站上线了”，配一堆略显兴奋的截图。这词儿其实没有特别严格的学术定义，但从实践角度说白了就是：你用自然语言描述需求，让 AI 一句句把代码吐出来，你负责“感受”这个 vibe（氛围/方向）对不对，剩下的交给模型。很多人把它翻译成“氛围编程”“感觉编程”，我觉得更贴切的叫法是“靠手感驱动开发”。

但你要是真的在自己项目里连续用了三四周 Vibe Coding，会发现一个扎心的事实：写的时候是真爽，改的时候是真想哭。

先说它解决了的真问题。过去写一个原型，从拉工程、配依赖、写接口定义再到调样式，怎么也得折腾一两天。现在只要你把需求讲清楚，AI IDE（我用的是 Cursor 和 Trae 这几个）能在十几分钟里把骨架搭出来，页面能跑、接口能通，效率确实提了一个量级。这一点我完全不否认，Vibe Coding 在创意探索、单页 Demo、一次性脚本、个人小工具这些场景里，几乎是降维打击。你不需要出门左转去查框架文档，你把想法“说”给机器，机器帮你翻译成代码，这种体验在五年前是做梦。

可问题也来得很快。凡是稍微“长大了”一点的工程，凡是需要长期维护、多人协作、稳定迭代的项目，Vibe Coding 模式会迅速撞上三堵墙。

第一堵墙是“代码垃圾债”。AI 不懂你的业务上下文，它只会沿着对话历史里的惯性往下“圆”。你今天让它“加个筛选”，它就把列表页的筛选逻辑塞进组件里；明天你说“复用一下筛选逻辑”，它又复制一份改了改。三五个功能迭代下来，组件里塞满了鬼函数、魔法数字、用不到的 import 和几十个 props。Code Review 时你根本不敢细看，因为一细看就非要重写不可。

第二堵墙是“没人敢重构”。代码是 AI 写的，但你得人肉兜底。问题在于，人类对自己没写过的代码天然缺乏掌控感。你不知道这段逻辑当时是照着哪个“假想需求”写的，不知道改了会不会引发雪崩。我有个朋友做独立开发，半年攒了 3 万行 AI 生成的代码，最后想加一个支付功能，花了两周都没搞清楚原来的订单状态机是怎么流转的，只能推翻重来。

第三堵墙是“联调永远对不上”。AI 写接口、写前端、写数据库模型，它总是默认一切都顺理成章。它不会主动看你的字段命名规范，不会遵守你的错误码约定，更不会去读公司那套内部基建的接入文档。于是前后端接口对不上、数据库迁移脚本顺序错了、鉴权逻辑漏了页面，这类事故在 Vibe Coding 项目里几乎是日常。你在 vibe 里有多爽，联调时就有多痛。

所以，行业里开始往“AI 原生时代的软件工程化”这个方向探索，是必然的。不是说 AI 写代码不行，而是我们对待 AI 写代码的“姿态”不行：我们太快把手从方向盘上挪开了。Vibe Coding 把“写代码”这件体力活儿交给了 AI，但把“想清楚需求”这件智力活儿也顺手扔给了 AI，这才是大问题。

于是有了我们今天的主角：SDD，Spec-Driven Development，规范驱动开发。

2. SDD 的核心设计思路：把“感觉”固化成交互契约

SDD 也不是什么新造的概念，在传统软件开发里，规格说明书、接口契约、TDD 里的测试先行，本质上都是“先立规矩再干活”。但到了 AI 时代，SDD 被赋予了新的含义和新的紧迫性：因为你现在面对的“执行者”不是一个会主动问需求的人，而是一个极度聪明但极度缺乏常识假设的模型。

2.1 SDD 到底是什么：一个关系型协作模式

我用最通俗的方式解释一下我的理解。

传统开发里，人跟人协作，靠的是语言、文档、默契和无数次会议。你给后端说“给我一个用户列表”，后端会追问“分页吗？含不含已删除？返回哪些字段？”——因为人脑会自动补全这些细节。但 AI 不会。你跟 AI 说“给我一个用户列表”，它只会基于概率生成一个“看起来最像”的实现。大概率是返回全部用户、没有分页、字段命名随机。

SDD 的做法，就是把“应该给后端提的需求”提前写好，写成一个机器可读、人可审、逻辑可校验的“规格文档”。我们把这种文档叫 Spec，它可以是一份 Markdown，也可以是一组结构化的 YAML/JSON。核心思路只有一个：人和 AI 不直接对话写代码，人和 AI 一起对着 Spec 对话。

这个流程跑起来之后，协作关系就发生了根本变化：

• 人的职责：拆解需求、明确边界、定义输入输出、定验收标准；
• AI 的职责：照着 Spec 做翻译官，把结构化规格翻译成高质量、可维护的代码；
• 人再次介入的时机：Code Review 和验证环节，而不是逐行盯着 AI 生成代码。

换句话说，人从“逐行监督流水线”的工人，变成了“设计图纸并验收成品”的工程师。这是整个工作流最核心的转变。

2.2 为什么 SDD 能解决 Vibe Coding 的痛：三个关键转变

我把 Vibe Coding 和 SDD 的差异总结成一张对比表，方便你直观感受：

第一，从“模型没有记忆”升级为“项目有了长期记忆”。Vibe Coding 的上下文窗口再大，也是对话级的；今天聊的内容三天后就忘了，三周后换个人来聊，AI 完全不认识这个项目。SDD 的 Spec 是持久化在仓库里的一份权威文档，它相当于给 AI 装了一个“超长记忆外挂”，无论什么时候、谁来做，打开仓库就能看到完整的逻辑约定。

第二，从“代码复审”前置为“规格复审”。以前 AI 生成完代码，你一行行查 bug——这一步实际上在检查的都是“模型理解对了吗”“边界处理了吗”。SDD 把这个环节大大提前：你重点检查 Spec 写得对不对，而不是对着代码去猜意图。Spec 对了，AI 生成的代码至少不会跑偏。这个转变在团队场景里价值极大，Review 的颗粒度从“逐行为”降到了“逐契约”，效率完全不是一个量级。

第三，从“开发占主导”回归到“需求占主导”。Vibe Coding 最大的隐患是，AI 的“温柔顺从”会放大需求的不确定性。你脑子里其实只有一个模糊的想法，但 AI 天生会给你补全得“看起来特别完整”，于是你被它牵着走，最后做出来一个根本不是自己最初想要的东西。SDD 强制你在写代码之前先“想清楚”，这种强制性本身就是一种质量保障。

2.3 一个容易误解的点：SDD 不等于写文档

我得特别澄清一下：SDD 不是让你回到写一堆没人看的 Word 的时代。很多同学一听“规范驱动”，第一反应是“又要写几十页设计文档了”，马上头大。

不是这样的。SDD 的“规范”是精简的、可执行的、面向机器和人都能理解的契约式文本。它不必面面俱到，只需要规定清楚这几个核心要素：

• 意图：这一段子系统到底要做什么、不做什么；
• 输入/输出：对外暴露的接口、数据结构、错误码；
• 约束：代码风格、目录结构、不允许引入什么；
• 验收标准：什么样的表现才算“完成”；
• 边界：哪些事不要做、哪些功能明确不属于本模块。

写这份文档的时间，跟你过去在群里反复解释需求、跟人扯皮联调的时间比起来，其实是省钱的。而且它一旦写好，可以在多个 AI 会话、多个开发人员之间反复复用，边际成本会越来越低。

我自己在实践里最大的体感是：有了 Spec 之后，AI 更像一个靠谱的同事，而不是一个“盲猜的翻译器”。你给它一份结构清晰的契约，它产出的代码质量稳定到让人吃惊——函数命名统一、错误处理完整、边界情况覆盖齐全，好像它早就知道该怎么做。

3. 落地实操：我从 Vibe Coding 平滑迁移到 SDD 的四步法

理论讲了半天，很多朋友会问：那我到底该怎么做？总不能明天一上线就让团队所有项目推倒重写吧？

当然不用。我的建议是：在现有项目里先选一个新的、边界清晰的小模块做试点，把 SDD 流程完整跑通，再逐步铺开。下面这套方法我在不同项目里试过，有坑有收获，今天把它整理成一份可以直接照着做的四步法。

3.1 第一步：先做“规范前置”，给 AI 立一份全局规矩文档

无论你用 Cursor 还是 Trae，第一步不是急着写功能，而是先建立项目的“宪法”。我在热词里看到大家提到的“vibe coding 全局 md 文档”，本质上就是这个东西——但很多人的写法太简单，只放了一句“你是资深前端工程师，请输出优雅的代码”，这远远不够。

我的全局规范文档一般放在仓库根目录，命名为AGENTS.md（Cursor、Trae、GitHub Copilot 等主流工具都认），里面固定包含以下几块内容：

# AGENTS.md - 项目级 AI 协作规范 ## 项目身份 - 项目名、定位、所属业务域 - 核心领域词汇表（防止 AI 把“用户ID”写成“userId”或者“uid”） ## 技术栈与目录约定 - 前端框架 / 后端框架 / 数据库 / 部署方式 - 目录结构：页面放哪、组件放哪、api 封装放哪、工具函数放哪 ## 编码规范 - 命名：文件 PascalCase、变量 camelCase、常量 UPPER_SNAKE - CSS 方案、状态管理方案、请求库封装约定 - 禁止：Class 组件、any 滥用、重复代码（要求抽取公共函数） ## 工作流约定 - 先读 AGENTS.md 再读对应模块的 SPEC.md 再开始写代码 - 所有新功能必须先在 docs/specs/ 下新增 Spec 文档 - 涉及接口调用时，先查 api 文档或原有请求封装

这份文档就是 AI 的“入职培训手册”。实测下来，有了它之后再生成的代码，风格统一度能提升一个档次，至少不会出现一个项目里五种文件命名风格的惨状。注意，这份文档一定要放在仓库根目录，且文件名固定，因为很多 AI 工具会默认读取它，而不是靠你每次对话时临时“喂”给它。

3.2 第二步：把需求拆解成结构化 Spec，做成可复用的“开发卡片”

这一步是整个流程的重头戏，也是“人该干的活儿”。拿到一个需求，先别急着跟 AI 说“帮我写个登录页”，而是先花十分钟，把需求拆成一个结构化的开发卡片。

我把 Spec 模板固定成了下面这个样子，每次直接用：

# SPEC-XXX：登录页与登录态持久化 ## 背景与目的 - 用户需要访问受保护的仪表盘页面 - 登录后需保持会话 7 天（记住我勾选时） ## 功能范围 ### 包含： - 邮箱+密码登录 - 第三方 GitHub OAuth 登录 - 错误提示（密码错误/账号不存在/网络异常） ### 不包含： - 注册流程（已有独立页面） - 找回密码（暂未排期） ## 接口约定 - POST /api/v1/auth/login - 请求参数：{ email, password, remember } - 响应参数：{ token, user: { id, name, avatar } } - 错误码：40101 = 密码错误 / 40102 = 账号不存在 / 50000 = 服务异常 ## 数据结构 - User: { id: string, name: string, avatar: string, email: string } - Token 存储：localStorage（remember=true 时）/ sessionStorage（默认） ## 页面与交互 - 页面路径：/login - 布局：居中卡片、背景图、logo - 提交后按钮 loading 1.5s 以上防重复提交 - 校验通过拉取 /api/v1/user/me 回填用户信息，跳转 /dashboard ## 验收标准 1. 正确账号密码可正常登录并跳转 2. 错误密码提示“密码错误”，不泄露账号是否存在的细节 3. 刷新页面后登录态不丢失（若勾选记住我） 4. 重复点击提交按钮不会产生并发请求

你别嫌这个模板长，写这份文档的时间最多 15 分钟，但它直接决定了 AI 后面两小时产出的代码值不值得留。有了这份 Spec，AI 不会再“自由发挥”去设计接口、选择存储方案、决定跳转逻辑——它只需要做一个听话的实现者。

有一个小细节值得单独说：Spec 里一定要写清楚“不包含什么”。这是我从踩坑里学来的。AI 特别擅长超卖——你说做个登录页，它顺手帮你把忘记密码、短信验证、防机器人验证码全加上了。表面上看起来“很贴心”，但每多一个功能，你就多一份需要维护的代码。把边界画清楚，是 SDD 的精髓之一。

3.3 第三步：用“模块化会话”来写代码，而不是一个会话聊到天荒地老

很多人的 Vibe Coding 习惯是：一个聊天窗口从早上聊到晚上，从“写登录页”聊到“改页脚颜色”。这种连续会话会让上下文越来越长，AI 越到后面越“糊涂”，而且前面的错误决策会不断影响后面的生成结果。

SDD 模式下，我建议把所有开发工作拆成“模块化会话”。具体操作是：

1. 每次会话只做一件事。如果做登录页，就只做登录页；做完验收完，归档，关掉会话窗口；
2. 每次会话的开始，把AGENTS.md和对应的SPEC-XXX.md先拖给 AI，告诉它“先读这两份文档，然后按照 Spec 实现”；
3. 等 AI 写出第一版，不要急着继续提需求，先自己人肉过一遍验收标准，把不符合的点一次性列给它改；
4. 改完后做一次小的 Code Review，确认没问题了，把这个会话归档，记录“SPEC-XXX 已实现”。

这个习惯的背后逻辑是：AI 的上下文窗口就像工作台，你在上面放越多的“历史杂物”，留给当前任务的“工作空间”就越少。每次会话清空重来，配合常驻的 Spec 文档，AI 反而每次都处于状态最佳的起点。

用 Trae 这类国内 AI IDE 做这套流程体验很好的一点是，它在比较新的版本里支持了项目级上下文自动召回（读全局文档再响应），这跟 SDD 的指导思想天然契合。我在实际使用 Trae 跑上面的流程时，发现只要第一步的 AGENTS.md 写得好，后面在代码区直接选中代码块问问题，它的回答精准度高很多。

3.4 第四步：把验收变成“客观标准”，让 AI 自己给自己打分

传统 Code Review 靠人肉，费时费力，而且在 AI 生成代码量大的时候根本看不过来。SDD 模式下，我们可以把验收标准变成 AI 可执行的自检清单，让 AI 在交付代码之前先自己过一遍。

这一步的操作细节是：在每份 Spec 的“验收标准”部分，不只写自然语言，还要加上可执行的检查命令或规则描述。比如：

• 运行npm run lint需 0 error；
• 运行npm run test需通过所有新增用例；
• 代码中不得出现any类型（TypeScript 项目）；
• 接口请求必须走统一封装的request方法，不得直接调用fetch；
• 关键函数必须有简单的注释说明意图。

然后在跟 AI 的会话结束时，我固定给它一句话：“在交付代码前，请对照 SPEC-XXX 的验收标准逐条自查，列出你完成了哪些、有哪些是故意没做的。”这一步看着简单，实测效果出奇地好。AI 自查后的问题往往比人肉 Review 发现得还多，因为它在生成代码时其实一直有“自我怀疑”，只是你没给它表达的机会。

关于验收，还有一个非常实用的做法：写完代码后，让 AI 自己补充测试用例。你把 Spec 里的边界条件、错误码、异常分支列给它，让它生成对应的单元测试。这些测试就是“配套的验收证据”，后续改代码时一跑，就知道有没有把原来的逻辑改坏掉。

4. SDD 的工具链与团队协作模式：全员同步，而不是各顾各的

聊完了单人实践，再说说团队场景。SDD 真正威力最大的地方，是它天然适配“多人协作 + AI 辅助”的现代开发结构。以前团队里的问题是“人跟人之间对齐困难”，现在多了一个“人跟 AI 之间对齐也困难”，SDD 刚好把这两个问题一起兜住了。

4.1 用 Git 管理 Spec：规范也要做版本控制、走评审

我强烈建议把 Spec 文档纳入 Git 仓库管理，和代码一起提交、一起 Review。这比“单独拉一个共享文档表格”要好用得多，理由有三：

第一，Spec 和代码天然有对应关系。你看一个 commit 时，能看到“这次怎么改的”以及背后的“为什么要这么改”，回溯历史轻松太多。第二，Spec 走 MR 评审，能让团队里每个人在动手写代码之前就“对齐认知”。评审通过后再进入开发，就不会出现“你理解的是一个登录页，我做出来的是一个账号中心”这种重大偏差。第三，Spec 是活的，它跟着版本走。你发布 v1.2 时用的 Spec 是什么样，代码就是照着那个版本生成的，后续排查问题也有据可查。

我自己现在的习惯是：先提一个 Spec 的 MR，等团队 Review 通过，再提代码的 MR。虽然步骤多了一步，但实际推进速度反而更快，因为代码 MR 的摩擦小了很多，Reviewer 几乎都是直接 Approve。

4.2 团队协作中的分工：产品定意图，技术定契约，AI 定实现

SDD 对团队的另一个正向影响，是它逼着大家把“职责”想清楚。我总结的分工是：

• 产品/业务方定义意图：这个功能解决什么问题，用户是谁，优先级如何；
• 技术负责人定义契约：接口是什么、数据结构是什么、边界在哪；
• AI 负责实现：按照契约翻译成高质量代码；
• 团队负责验收：逐条对照验收标准检查。

这个分工最大的好处是减少了“甩锅”和“拉扯”。以前业务方说“我要个按钮”，开发做出来，业务方说“我不是这个意思”——信息在对话里失真了。有了 Spec，业务方提前确认了功能范围，开发提前确认了接口和边界，AAI 再在其中扮演“翻译官”，整个链条的失真率被大幅压低。

不过这条实践对“文档基因薄”的团队有一定阻力。我的建议是从一个小需求开始试点，不要上来就全团队推广。找一个大家公认“沟通成本高、容易扯皮”的小模块，用 SDD 跑一个迭代，把结果和体感摆出来，比发十封制度邮件都管用。

4.3 哪些场景不适合 SDD，哪些场景千万别用

凡事都有适用边界。SDD 也不是万能的，我遇到这几类场景，就不太建议用：

• 纯探索期的创意脚本：你只是想在本地快速验证一个想法可不可行、数据有没有意思，这时候写 Spec 纯属浪费。先用 Vibe Coding 快速跑，跑通了再补 Spec；
• 一次性数据分析脚本：跑完就扔，也不会维护，没必要花时间写契约；
• 需求极度模糊且业务方自己也说不清时：这时候强行写 Spec，只会把错误的假设固化成文档，后面返工成本更高。不如先做一个粗糙原型，用原型倒逼业务方把需求想清楚。

我自己的判断标准是：“这个代码三个月后还会有人看吗？”答案是会，那就值得用 SDD 流程；答案是不会，那就怎么快怎么来。

Vibe Coding 和 SDD 不是二选一的对立关系，而是一条光谱上的两端。我的实践模式是：探索期用 Vibe Coding 快速试错，一旦方向确认，立刻转入 SDD 流程把它工程化。用了这个组合拳之后，我个人的产出质量和可维护性都有了明显改善。

5. 常见问题与排查技巧实录：从“踩坑”里总结的避坑经验

最后这部分，我把过去踩过的坑、群里朋友问得最多的问题，统一整理成一份速查清单。这些问题你不遇到很幸运，遇到了可以直接拿来排查。

5.1 AI 不遵守 Spec 怎么办：换一种“喂”法，而不是一味地骂

我用 AI 写代码一年多的经验是：模型不是不遵守 Spec，而是它没意识到“这份文档优先级最高”。很多时候你把一份很长的 Spec 丢给它，它读到最后，前面写的啥已经“记不清了”，于是开始自由发挥。

我的解决办法：

1. 把 Spec 精简到一屏能看完的体量。我见过不少团队友写的 Spec 长达 3000 行，这本身就是问题。Spec 不是详细设计文档，它只写“契约”，不写“过程”。如果某个模块确实复杂，就拆成多个小 Spec；
2. 在每次请求前明确提示优先级。在对话里加一句固定前缀：“请严格遵循 AGENTS.md 和 SPEC-20240601.md 中的约定，这是优先级最高要求。如果存在矛盾，以 Spec 为准。”这句话虽然有点“咒语感”，但实测有效；
3. 让 AI 先复述再动手。在实现前先让它用三句话概括“你打算怎么做”，你确认它真的读懂 Spec 了，再让它写代码。这一步像极了给实习生安排任务后让他复述一遍，能省掉后面 80% 的返工。

5.2 Spec 和代码不同步了怎么办：把“同步”做成每次开发的固定动作

SDD 最常见的腐化现象就是：Spec 写于某年某月，后来代码改了三轮，Spec 已经变成了“一张废纸”。这几乎无法避免，但可以靠流程控制住。

我规定自己两条规则：

• 需求变更时，先改 Spec，再改代码。哪怕是只改一个字段名，也要同步更新 Spec，不要让 Spec 滞后于代码。因为 AI 读取优先序是 Spec -> 代码上下文，Spec 一旦滞后，AI 生成的新代码大概率会拿旧契约做事；
• 每次 MR 里必须包含 Spec 的 diff。如果这个 MR 动了业务逻辑但 Spec 没有变化，说明你漏更新了；如果 MR 里只剩 Spec 改动而代码没改，说明你在“为了改文档而改文档”，需要停下来想想。

这两条规则守住了，Spec 和代码能长期维持在“互相印证”的健康状态。

5.3 团队里有人不配合写 Spec 怎么办：从“要求”变成“收益”

这个问题挺现实的。有人觉得 Spec 是“没用的文书工作”，觉得与其花 15 分钟写文档，不如直接让 AI 干完。我的经验是：别急着说服所有人，先让写 Spec 的人尝到甜头。

具体做法是，在团队例会里做一次“前后对比”：同一个需求，A 同事用 Vibe Coding 做了一版，B 同事先用 Spec 再做一版。让大家对比两版代码在 Code Review 里找 bug 的耗时、重构时的心理压力、以及后续迭代的速度。用数据说话，比用道理说话管用。

其实很多抵触情绪源于“不知道怎么写、怕写错、觉得浪费时间”。我就拿自己团队的套路手把手带了一次：把第 3 步那个 Spec 模板直接甩给他们，让他们照着填空。把“写 Spec”的门槛降到“像填报销单一样简单”，接受度一下子就上来了。

根据我个人的体会，从 Vibe Coding 到 SDD，本质上不是工具的变化，而是“心态和习惯”的一次升级。它要求我们重新承认一件事：AI 再强，它也只是执行者；需求的定义权、契约的制定权、质量的验收权，这些工程师的核心价值，永远要攥在自己手里。把这个观念转过来，你调教出来的 AI 会越来越精准，你手里的项目也会越跑越稳。