企业官网建设流程全解析

最近圈子里Vibe Coding这个词火得不像话，朋友圈随便一刷就是"我用AI两小时做了个工具""大模型写的代码比我手写还利索"。确实，AI编程将门槛拉到了历史最低点，喊一句"给我做个设备巡检系统"，桌面就能长出个网页来。但做了几个项目之后你会发现，热闹归热闹，AI写出来的代码一旦要改起来，那叫一个酸爽——上下文忘了、逻辑串了、改动波及一大片。我自己的两个小项目被"生成一时爽，重构火葬场"折磨了两次之后，被迫开始认真研究SDD（Spec-Driven Development，规范驱动开发）。这段时间整个工作流已经彻底重写，从环境搭建、全局MD文档设计，到需求拆解、AI生成、人工评审，走完了一整条AI原生时代的软件工程化路径，踩了不少坑，也沉淀了一些确实有用的方法论。今天这篇就完整分享出来，适合正在用AI写代码、但被代码质量反复折磨的朋友，也适合团队里想把AI生成纳入正规研发流程的管理者。

1. 先说Vibe Coding：为什么大家突然都在"用感觉写代码"

1.1 Vibe Coding的日常长什么样

Vibe Coding这个词，大体描述的是那种"凭感觉、靠氛围、用自然语言对话式"的写代码方式。操作起来的画面感非常强：打开Trae、Cursor或者GitHub Copilot，用大白话描述想要的功能，AI哗啦啦生成一坨代码，跑一下能用，哎，就完事了。遇到报错，把错误信息粘回去，或者直接说"帮我修一下"，AI再给你一版。这一来一回，确实有一种在和"会写代码的实习生"对话的爽感。

我最初就是这么干的。一个内部用的巡检数据录入页面，从零到能用的1.0版本，前后大概三个小时。当时是真兴奋，觉得多年的SQL和JavaScript都白学了，以后点点鼠标路子就能写系统。但爽完紧接着就是疼。三天后需求方打来电话说录入页要加两个字段，我带着AI在代码里定位了半小时，改了表单、改了接口、改了校验，跑起来又冒出来三个新错误——因为那个页面当时是分三批对话生成的，每一批的字段名和数据结构都有点小差异，牵一发动全身。

1.2 我踩过的那些"感觉"坑

第一坑：上下文失忆。Vibe Coding本质上吃的是对话窗口里的上下文。生成完1.0版本，窗口里的代码已经几千行了，等两周后再来改，AI根本不记得这个项目当初是怎么约定的。它只会基于你当前给的几句话重新猜，大概率猜出和原来不一致的方案。

第二坑：代码风格分裂。因为每次对话AI会重新发挥，一个项目里经常出现两三种风格的数据请求方式。有用fetch的、有用axios的、还有用XMLHttpRequest的，明明是一个前端项目，却活成了Web前端发展史的活化石。代码review的时候看着就头大，更别提维护。

第三坑：重构基本靠推倒重来。Vibe Coding生成的东西，结构之间的依赖关系往往比较随意，这就需要"牵一发动全身"的最小改动往往做不到。你想加一个字段，可能得从数据库表一路改到前端展示层，中间还要处理AI生成时埋下的隐性逻辑，比如它可能在某个不起眼的脚本里对字段做了二次处理。

第四坑：测试天然缺失。AI生成的代码大部分只保证了"主流程能跑通"，边界情况、异常输入、并发问题，它极少主动处理。我有个自动对账脚本，白天跑得好好的，月末有大额流水时直接崩了，查了半天是数字类型溢出。这种问题在纯Vibe Coding模式下几乎是无解的，因为你没有测试，也没法快速定位。

1.3 别急着否定：Vibe Coding的真正价值区间

把坑讲得这么细，但我不认为Vibe Coding是错的，恰恰相反，它是当前AI时代最自然的探索方式。它适合的场景也非常清晰：原型验证、一次性脚本、个人小工具、临时数据处理。如果你只是想把一个想法快速落地成能看的东西，Vibe Coding的效率无可匹敌。但一旦这个项目要交付给别人用、要长期维护、要多人协作，Vibe Coding那套"脑子里有个模糊感觉就开写"的方式就必须让位给更严格的工程化方法。

打个比方，Vibe Coding就像是兴之所至做一顿家常菜，好不好吃全看手感，主厨一个人对着锅台自由发挥没问题。但饭店里要做标准化菜品，没有SOP，没有配方卡，后厨早就乱套了。AI原生时代的软件工程，需要的正是"SOP"。

2. SDD是什么，它解决了什么问题

2.1 SDD的核心逻辑：规格先行

SDD，全称Spec-Driven Development，规范驱动开发。它的核心思想一句话就能说清楚：动手编码之前，先把"这条代码要实现什么、输入是什么、输出是什么、边界条件有哪些、和周边模块怎么交互"这类信息用结构化的文档描述清楚，然后AI按着这份规范去生成代码，而不是靠猜。

和传统瀑布模型里的需求文档不同，SDD的规范不是写给客户看的，也不是写完就锁进抽屉里的。它是给AI看的"施工图"，同时也是给开发者看的"验工标准"。一份合格的SDD规范，至少要包含这样几个要素：

• 业务背景：这个功能解决什么问题，用户在什么场景下使用
• 功能拆解：把需求拆成若干个可独立验收的功能点
• 接口定义：明确的入参、出参、错误码、数据类型
• 边界条件：空值、超长输入、并发、幂等等情况怎么处理
• 验收标准：用什么用例、什么数据来验证代码是对的

有了这些前置约束，再让AI生成代码，生成的代码就不是"自由发挥"而是"照图施工"。质量和可预测性都会高很多。

2.2 为什么AI原生时代反而更需要规范

有人可能会问，以前写代码也没见搞这么多文档，怎么到了AI时代反而要回到文档驱动？这里有个特别容易被忽视的技术原因：大模型的上下文窗口是有限的。

传统开发模式下，信息是分散存储在代码库、数据库、接口文档里的。程序员问一个模块的答案，可以在整个代码库里翻找。但AI没有这个能力，或者说它的"寻找"能力受到上下文窗口的严格限制。如果你不主动告诉它项目的整体约定、模块的边界、接口的契约，它就只能基于你当前对话里给的那点信息，外加自己在海量公开代码里学到的"统计规律"来发挥。统计规律是什么样的？它会把代码写得看起来像那么回事，但不一定贴合你的实际需求。

规范文档在这里扮演的角色就是"上下文压缩"。一份设计良好的全局MD文档，可以把几个月的项目决策、几百个文件的架构约定、几十次踩坑总结，压缩成几千字的结构化文本。AI读这个，比让它翻遍整个代码仓库高效得多，产出也稳定得多。换句话说，在AI时代，规范不是官僚主义，而是把项目经验喂给AI的最优载体。

2.3 SDD与Vibe Coding：不是替代，是刹车

我的核心观点是：SDD不是要消灭Vibe Coding，而是给Vibe Coding装上刹车和方向盘。

最理想的工作状态其实是混合模式：用Vibe Coding来探索可行性、快速验证方案，用SDD来约束正式交付的代码质量。打个不太恰当的比方，Vibe Coding是油门，负责冲；SDD是刹车和方向盘，负责让你不冲出赛道。你可以在一个项目的原型阶段尽情Vibe，但一旦确认功能要做进正式系统，就必须先把规范立起来，再让AI按规范重写或收敛。

我目前的工作流是：接到需求先写规范，规范定了之后，让AI按规范生成代码；生成完代码，我用规范里的验收标准逐项测试；发现问题就把问题描述和现场信息回给AI，让它修。整个过程既能享受AI带来的效率红利，又不会把项目变成一团没法收拾的乱麻。

3. 全局MD文档：连接Vibe Coding与SDD的那根线

3.1 为什么一份md文件能当"项目大脑"

在Vibe Coding实践里，"全局md文档"是很多人的秘密武器。表面上看它就是一份Markdown格式的说明文档，但它的本质作用，是充当项目的"外置大脑"。

AI模型在生成代码时，gpt、claude、gemini这类模型本身没有记忆，所有历史信息必须塞进对话上下文。而对话窗口有上限，东西一多，模型就会"忘记"前面聊过什么。全局MD文档就是针对这个问题设计的。你不是把它作为一个参考文件丢在仓库里，而是每次对话一开始，就让AI读取这份文档，然后再开始干活。文档里写的项目结构、技术栈、编码规范、接口约定，就成了AI在本次对话中始终遵守的"宪法"。

我在实践中的体会是：一份好的全局MD，效果比你在对话里反复强调"你要遵守规范"强一百倍。因为对话里的提醒是短时记忆，说完可能几十轮之后就被冲淡了；但写在文档里的内容是持久记忆，AI每一轮生成代码时都会参考。

3.2 一份真正有用的全局MD怎么写

我见过很多人的全局MD文档写成了"项目介绍PPT"，全是高大上的功能和愿景描述，结果AI读了等于白读。真正有用的全局MD，应该是一份"给AI的入职培训手册"，它要回答的是以下几个问题：

• 这是什么项目，核心业务是什么
• 用到的技术栈和版本是什么
• 目录结构怎么组织的，新代码应该放在哪
• 代码风格和命名规范是什么
• 有哪些跨模块的约定
• 有哪些已经踩过的坑，禁止再犯

我自己的模板大概长这样：

# 项目全局规范 ## 项目定位 一句话描述项目要解决什么问题，目标用户是谁。 ## 技术栈 前端：React 18 + TypeScript + Vite 后端：Python FastAPI + PostgreSQL ORM：SQLAlchemy 2.0 脚本：Node.js 20 ## 目录结构 - src/frontend：前端页面 - src/backend：后端接口 - scripts：运维脚本 - docs：项目文档 新增页面放src/frontend/pages，新增接口放src/backend/routers ## 编码规范 - 接口返回格式统一为 { "code": 0, "data": ..., "message": "..." } - code为0表示成功，非0表示业务错误 - 数据库表名使用snake_case，字段名使用snake_case - 前端组件名使用PascalCase，文件名使用kebab-case ## 通用约定 - 所有时间字段统一用ISO 8601格式存储 - 金额用Decimal类型，禁止用float - 涉及用户相关操作必须记录操作日志 ## 已踩过的坑 1. 不要在业务代码里直接拼接SQL，必须走ORM 2. 修改数据库表结构时，必须同步更新对应的模型定义 3. 不要在前端直接存储敏感信息，统一走后端接口获取权限

这份文档不需要很长，但每一句话都要是"可执行的约束"。AI读完之后，生成代码时的行为会有肉眼可见的变化——接口格式不会偏离、命名不会跑偏、也不会在业务层搞小动作。这就是全局MD文档连接Vibe Coding和SDD的桥梁作用：它让自由散漫的Vibe Coding有了一个不依赖对话记忆的规范锚点。

3.3 如何让AI真的把MD当回事

光写了文档还不够，AI不是人，它不会主动去读仓库里的文档。你得在每次对话的开头明确要求它读取。我常用的开场白是：

"开始工作前，先阅读项目根目录下的GLOBAL.md，理解项目规范后再动手。如果规范里有不清楚的地方，先问我，不要自己推测。"

还有一个细节：全局MD文档本身也是要版本管理的。项目经历了几轮迭代之后，文档里的某些约定可能已经过时了，这时候如果不更新文档，AI就会照着错误约定生成新代码，制造新的不一致。我一般每完成一个里程碑就过一遍全局MD，删掉过时的内容，补充新踩坑的经验，始终保持文档和代码现状同步。

4. 实操：从零搭一套SDD最小闭环

4.1 环境与工具链准备

所有的理念最终要落到工具和流程上。我现在的开发环境是这样的，供大家参考：

• IDE：Trae，也可以用Cursor，二者都是面向AI编程深度优化的编辑器。Trae在国内网络环境下比较省心，Cursor对代码库的全局理解更强，选哪个看你自己的习惯。
• AI模型：Claude系列用于前端页面生成效果最好，GPT系列在逻辑推理类任务上更稳。国内的话，可以选择对应的国内模型服务。实际上模型不是最核心的，重要的是流程。
• 项目记忆：全局MD文档 + docs/specs目录，前者放项目级约定，后者放各个模块的功能规格。
• 版本管理：Git + GitFlow，AI生成的代码也走代码评审和分支管理，绝不能直接推到主干。
• 测试：Vitest（前端）+ Pytest（后端），每次AI改完代码，至少跑一遍相关测试。

这套环境不是一次配齐的，是踩了N次坑之后的沉淀。最初我直接在Trae里开了一个新项目就开始聊，后来发现项目稍微大一点，对话窗口就扛不住了。后来把全局MD做起来，又把每个模块的需求拆成独立spec，工作的节奏感一下就出来了。

4.2 一份可直接抄写的Spec模板

SDD的核心产物是spec文档。下面这个模板是我在项目里反复打磨后的版本，结构比较通用，适合中小型功能模块的开发，可以直接抄来用。

# 功能规格：[功能名称] ## 背景 （一两句话说明这个功能是为了解决什么问题） ## 功能拆解 - [ ] 功能点1：描述具体行为 - [ ] 功能点2：描述具体行为 ## 输入定义 | 字段 | 类型 | 必填 | 说明 | |-----|-----|-----|------| | name | string | 是 | 用户名称，长度限制50字 | | count | number | 否 | 数量，默认1，最大99 | ## 输出定义 | 字段 | 类型 | 说明 | |-----|-----|------| | code | number | 0成功，非0失败 | | data | object | 返回数据 | | message | string | 提示信息 | ## 边界条件 - 输入姓名为空时，返回错误码1001 - 数量超过99时，返回错误码1002 - 重复提交相同请求时，应实现幂等处理 ## 验收标准 1. 调用接口，传入合法参数，返回成功 2. 调用接口，传入空姓名，返回1001 3. 调用接口，传入数量100，返回1002 4. 连续提交5次相同请求，仅第一条生效 ## 涉及变更 - 新增接口：POST /api/xxx/yyy - 前端新增页面：src/frontend/pages/xxxx.vue - 数据库新增表：xxxx

写这个spec有个小技巧：验收标准一定要写清楚，因为验收标准就是你后面让AI改代码的"裁判文书"。AI生成的代码对不对，拿验收标准逐条跑就行，有bug就告诉它违反了几号验收项，它改起来针对性会强很多。

4.3 一个完整案例：从任务描述到代码落地

光讲模板太抽象了，拿一个实际的小项目走一遍全流程。上个月我们内部要做"设备巡检记录系统"，需求方的原始描述是："做一个网页，让工人可以填巡检记录，顺便能看到历史记录，最好能统计一下故障率。"

原始描述就是典型的Vibe思维——模糊、笼统、充满想象空间。如果直接把这句话甩给AI，做出来的东西大概率方向有偏差。所以第一步是把它变成结构化的规格。我花了一个小时与需求方沟通，搞清楚几个关键问题：巡检记录要填哪些字段？历史记录按什么维度过滤？统计报表是按天出还是按周出？工人需要登录吗，还是直接填？

最终整理出来的spec非常清晰：

• 巡检项目：设备编号、巡检人、巡检日期、运行状态（正常/异常）、备注、温度值（可选）
• 历史记录：按设备编号和日期范围筛选，列表倒序展示
• 统计报表：按周展示所有设备的异常率，用柱状图呈现
• 权限：不需要登录，但有管理员页面可以删除误填的记录

然后我把这份spec交给了AI，让它按spec生成前端页面和后端接口。因为spec已经把字段、类型、边界条件都写清楚了，AI生成的代码几乎没有出现结构性的偏差，第一版就有九成能跑。剩下的一成小问题，靠验收标准逐条纠错快速收敛。

这个例子想说明的是：SDD不是要把一个半小时能干完的活拉长到三天，相反，前期用一小时写清楚规格，后面AI写代码一次成型，省掉的是反复返工的几十个小时。站在项目全周期看，SDD是效率的最大化，而不是流程的累赘。

5. 迁移到SDD会遇到的坑与我的解法

5.1 渐进迁移，别搞一刀切

从纯Vibe Coding到SDD的迁移，最容易犯的错误是步子迈太大。一上来就规定每个功能、每块代码都必须有完整spec，团队或个人很快就扛不住，因为很多小改动根本不值得走完整的流程。

我的建议是分级：按照变更的大小来决定规范的严格程度。

• 小改动（改一个文案、调一个样式）：不需要spec，Vibe Coding直接改
• 中改动（新增一个接口、一个页面）：需要写精简版spec，只写输入、输出、验收标准
• 大改动（新增一个模块、重构核心逻辑）：需要完整spec，包含背景、拆解、边界、验收、变更清单

用这个分级策略，既不会让SDD变成沉重的负担，也能在关键节点把工程化的好处吃满。

5.2 AI不遵守规范的排查思路

即便写了规范和全局MD，AI在生成代码时仍然偶尔会"跑偏"。这种情况不用慌，按照下面的顺序排查，大概率能快速解决：

第一，检查是否在对话开头让AI读过规范。很多人写好了文档，但对话一开始就说"帮我写个函数"，AI根本不知道你有这个文档。需要在对话开头先执行"读文档"的动作。

第二，检查规范文档本身是否清晰。如果规范里有模糊表述，比如"统一的错误处理"，AI不知道该统一成什么样，就会自由发挥。解决办法是把规范写得更具体，比如直接写出"错误响应格式为code/data/message，message开头用大写字母"。

第三，把规范里的相关条目直接粘进对话。如果AI在生成某个具体功能时违反了规范，可以把规范原文贴出来，外加一句"请严格遵守上述规则，重新生成"。这比让AI自己去找规范再改有效得多。

5.3 文档会过期，规范要"活"起来

要说SDD最大的敌人，不是AI不够聪明，而是文档写了一堆但没人维护，最后变成一堆僵尸文档。我见过很多团队，规范攒了几十页，读起来全是"正确的废话"，根本没人看，AI自然也不会看。

解决这个问题就三个字：小步跑。规范别一次性写很多，而是跟着项目走。每次踩坑，顺手把教训写进全局MD；每次模块迭代，顺手更新对应的spec；每次用法有变化，马上改文档。让文档和代码保持同步，这比字斟句酌写一份完美文档重要得多。我自己有个小习惯，每次让AI改完代码，都会回头检查相关文档是否需要更新，如果有变动，顺手改掉，绝不留到"以后"。这个以后，通常就是不存在的。

6. 写在最后的几条心得

这套从Vibe Coding到SDD的工作流，我实际跑了两三个月，最大的感受是对"代码可控性"的信心回来了。AI编程最大的问题不是生成不了代码，而是生成的代码不可控。SDD解决的就是这个"不可控"问题：先定标准再执行，既保留了AI的效率，又守住了工程的质量底线。

最后分享三个小技巧：

第一，全局MD文档不要追求大而全，追求"约束可执行"。每一条都能对应到具体的代码行为，否则就是废话。

第二，spec的验收标准请一定用数据说话。说"要很快"不如说"100个并发请求，响应时间不超过200ms"；说"要处理异常"不如说"请求超时返回504，并且日志打印超时的URL"。

第三，AI原生开发真正值钱的不是写代码的手速，而是定义问题的能力。谁能把模糊的需求转成清晰的规格，谁就能让AI变成十倍产能的放大器。所以我建议你把写spec当成第一技能去练，这比追任何一个新模型都重要。

我个人估摸着，接下来一段时间，SDD会慢慢成为AI原生开发的主流姿势。因为大家很快会发现，AI生成代码的能力已经过剩，真正稀缺的是高质量的需求定义能力。早点把这套流程跑起来，等项目规模上来的时候，你就知道它有多香了。