企业官网建设流程全解析

做了一阵子 AI 辅助编程项目后，我最大的感受是：如今写全栈项目的瓶颈早已不在“敲代码”这件事上，而在“怎么让一堆 AI 生成的代码真正落地成一个能上线、能迭代、能被人接手维护的系统”。

我现在的工作流基本稳定在 Vibe Coding 这条路上：以 Cursor 作为日常主编辑器，配合 Claude Code 处理需要长上下文和多轮推理的攻坚任务，把前端、后端、数据库、部署脚本一起交给模型去生成，自己专注在拆需求、画边界、审代码。这套打法的核心支撑，是工程SDD（System Design Driven）方法，以及多 Agent 协作的任务编排。最初接触这套组合时，我也以为只是多了几个写代码的AI帮手；等真实跑过从零到一的全栈项目后才意识到，关键不在工具多先进，而在于它强迫你把“系统怎么设计”这件事想清楚——AI 生成代码的前提，是你先把系统的完整结构喂到它的上下文里；而多 Agent 协作能不能稳住，也取决于你给每个角色分配的任务边界够不够清晰。

这篇文章不是工具功能介绍，也不是什么课程逐字稿。我想从项目落地的角度，把这条链路的真实用法拆开讲透：Vibe Coding 的正确打开方式是什么，工程SDD 文档到底该写哪些东西，Cursor 和 Claude Code 在实战里怎么分工配合，多 Agent 场景下为什么不会乱。全程会结合我实际跑过的全栈项目举例，过程、坑、复盘都会写出来。适合三类人看：已经用 AI 写过不少代码、但总在“生成-报错-修-再报错”循环里打转的人；想把 AI 编程纳入正规项目流程、甚至带团队用起来的开发负责人；还有想系统学习这条路线、又不想只停留在“会点按钮会聊聊天”层面的新手。

1. Vibe Coding 的工程化：关键在把“意图”变成“上下文”

1.1 先搞清楚 Vibe Coding 为什么容易翻车

Vibe Coding 这两年讨论度很高，字面意思是“靠氛围和感觉编程”，具体场景就是：在编辑器里打开 AI 对话栏，用大白话描述“我要做一个什么功能”，然后让模型直接把代码生成出来，自己只做验证和微调。

这个模式一旦用顺了，效率确实恐怖。我做过一个内部工具型系统，从初始化项目到核心页面能跑，只用了一个下午。但同样地，翻车也翻得很快：项目稍微大一点，功能模块一多，AI 就经常“失忆”——昨天刚定的接口，今天生成的新代码就完全不管了；同一个数据结构在不同文件里被生成了三种样子；改一个字段，牵连出来的报错遍地都是。根本原因其实不是工具笨，而是我们给模型的“输入”太单薄了，只有一句需求，没有系统设计。

换个角度想，你让一个水平不差的工程师写代码，至少要给他需求和设计文档；AI 模型也一样，它需要知道系统的边界、模块关系、数据流，否则只能在黑暗中瞎猜。Vibe 这个词容易给人误导，让人以为 AI 编程靠的就是感觉和灵感；实际跑下来，真正稳定高效的 Vibe Coding，一定是“先有设计、后有生成”的，只是这个设计过程也交给 AI 来做罢了。

1.2 工程SDD：把设计任务前置到“写代码之前”

工程SDD 这个词在不同语境下有不同解释，我在实践中采用的是它在 AI 编程社区里最常见的落法：System Design Driven，系统设计驱动。核心思想一句话：先让 AI 生成足够清晰的系统设计，再让它基于设计去产出代码，而不是让它一边设计一边写。

打个比方，传统厨房里你请了个手艺很好的大厨，你只跟他说“给我做一桌菜”，他大概率按自己的习惯自由发挥，出来的东西未必合你口味；如果你给他一份完整的菜单、食材清单、每道菜的做法约束，他做出来的菜才能稳定地接近你想要的结果。传统开发的痛点在于做设计很费人力；SDD 的讨巧之处在于，设计这一步也可以交给 AI——你用自然语言描述业务目标，让 AI 先产出系统边界、模块划分、接口清单、数据模型，你审核确认后再把它喂回去生成代码。

这个流程顺下来，最直观的变化是：AI 生成的代码不再是“看起来能跑”的玩具，而是有边界、有结构、能维护的系统。我试过同一个项目分别用“直接聊需求”和“先走 SDD”两条路径生成，后者的代码返工率至少低一半，尤其在联调阶段，接口对不上的情况大幅减少。

1.3 多Agent不是噱头，是上下文管理的必然产物

很多人听到“多个 AI Agent”第一反应是玄乎，其实它解决的是一个非常实在的问题：上下文窗口有限。

一个 AI 对话参与维护的项目，上下文一大就会开始糊涂。比如在一个较大的全栈项目里持续跟模型对话，几轮之后它就会忘记最初约定好的项目结构，开始生成互相冲突的代码。与其在一个对话窗口里硬撑，不如像团队分工一样把任务拆给不同角色的智能体：一个负责需求梳理和系统设计，一个负责后端实现，一个负责前端实现，一个负责部署排障。每个 Agent 只维护自己那块上下文，通过共享的设计文档和接口契约来对齐信息，这就把“靠一个上下文硬扛整个项目”的问题，转化成了“多个独立上下文协作”的问题。

我实际用下来，单 Agent 的上下文上限大概只能支撑三五个功能模块顺畅协作；切到多 Agent 分工后，十几个模块的项目也能保证每个对话窗口的上下文清爽。这不是什么魔法，本质上就是上下文隔离带来的工程收益。

1.4 为什么是 Cursor 和 Claude Code 的组合

工具选型上，我这个阶段的判断是：日常开发主战场放 Cursor，攻坚与长推理场景留给 Claude Code。

Cursor 的优势在于它深度融入了传统 IDE 的工作流，有完整的代码库索引、可视化的 diff 审查、可以针对整个仓库提问，在“边写边改”的场景下体验很好；Claude Code 则更适合跑在终端里做自动化任务，CLI 模式可以挂进脚本流水线，适合做批量重构、大规模代码扫描、跨文件修改这一类活，同时在长上下文推理上的表现也更稳定。两者不是替代关系，而是互补关系：Cursor 管日常，Claude Code 管攻坚。

有人问能不能只用其中一个？可以，但全栈项目落地时，任务多样性会导致频繁切换，单一工具容易在某些环节成为瓶颈。我的经验是：需要频繁集成到 IDE 里的活儿交给 Cursor；需要综合理解全仓库逻辑、跨模块改动的活儿，我会把任务交给 Claude Code 跑脚本。实际配合下来，整个项目的推进节奏会顺很多。

2. 工程SDD 实操要点：设计文档要写什么、怎么写

2.1 三个必写的设计文档内容

工程SDD 要落地，第一个问题就是：设计文档到底写什么？我实践的结论是，三件事最关键：系统边界、模块划分、数据契约。

系统边界：这个系统对外提供哪些能力，输入输出是什么，不做什么。比如做一个博客平台，边界就是“用户可注册、发文、评论”，不考虑推荐算法、不做多语言；边界定得越清楚，AI 越不会在没被要求的地方自由发挥。

模块划分：按照功能域切分目录结构和职责。前端放什么、后端放什么、公共逻辑放哪里、数据库模型放哪里，全部用目录树的形式写清楚。对 AI 来说，目录树就是最好的模块契约，读一遍就知道代码应该落在哪。

数据契约：核心实体和它们之间的字段关系。比如用户、文章、评论三张表的字段定义、关联关系、状态枚举。这部分是 AI 生成代码时最容易出错的地方，详细的数据模型定义比十段自然语言描述都管用。

2.2 用业务规则补齐需求盲区

很多 AI 生成代码跑不通，不是代码问题，是模型对业务目标的理解偏了。所以设计阶段要多一步：用自然语言把业务规则穷举给模型，让它理解各种分支条件。

举个例子。“用户上传头像”这个需求看起来简单，但业务规则可以很复杂：文件只能是 jpg 或 png，大小不能超过 2MB，默认头像在未上传时展示，上传后自动裁剪为正方形。这些细节不在设计阶段说清楚，AI 生成的上传逻辑大概率只有“存文件+返回URL”两行代码，校验、裁剪、默认值全都会漏。

我的习惯是在设计文档里专门写一个“核心业务规则”小节，用 5-10 条精简的规则覆盖常见分支。这一步投入不大，但对 AI 后续产出的代码质量影响极大，也是工程SDD 里最容易被人忽略、但实战价值最高的一环。

2.3 把工程规范写进规则文件

工程SDD 里的“工程”二字还体现在规范配置上。团队里有人类工程师时，规范靠制度约束；全部交给 AI 生成代码时，规范就得写进配置和规则文件，让模型每次生成都必须过一遍。

我在项目里常配三个层面的约束：代码风格约束，比如 ESLint、Prettier、语言规范；项目结构约束，比如目录约定、命名约定；提交规范约束，比如 Commit 规范和分支命名规则。这些配置都要在 AI 开始干活之前就放进仓库，并明确告诉模型这些配置是硬约束。

尤其值得强调的是“禁止事项”比“应该做什么”更有效。比如“禁止在后端代码里直接拼 SQL，必须走统一的 DAO 层”，“禁止在前端代码里硬编码任何 URL，统一走环境变量”。这些硬约束能避免模型按自己的惯性生成一堆后续很难维护的代码。我见过太多 AI 生成的项目，功能能跑，但写法跟团队规范完全不沾边，接手维护的人看着脑仁疼。

2.4 两个工具的分工细节与衔接点

把 Cursor 和 Claude Code 的具体分工再拆细一点，方便直接抄作业。

Cursor 这边，适合做：日常单模块开发，比如前端组件、后端接口的单点实现；快速原型验证，搭一个能跑的 Demo 看效果；代码解释和局部重构，让模型对着某段代码讲清楚逻辑；还有仓库级问答，查某个功能在项目里是怎么实现的。

Claude Code 这边，适合做：全仓库级改动，跨多个模块的大型重构；长链路任务执行，比如从读设计文档到生成完整后端模块；批量任务处理，比如扫描所有文件找出未捕获的异常；以及复杂问题的根因分析，把报错日志贴进上下文一步步定位。

两边的衔接点在于项目设计和规则目录的一致性，两边都要能读到同一份设计文档和规则文件。我的做法是：把设计文档和规则文件放在仓库根目录统一维护，并在系统提示里写清楚读取路径和优先级别。这样无论用哪个入口，模型看到的“系统全貌”始终是同一版，行为也就不会因为工具切换而漂移。

3. 实操过程：一个全栈项目从零到落地的完整走法

3.1 用一个模拟项目把整个流程串起来

理论讲了不少，用一个模拟项目把完整流程走一遍。假设我们要做一个内部使用的“会议纪要知识库”系统，需求几句话就能说清：上传会议录音或文字稿，自动生成摘要和待办事项，待办可分配负责人与截止时间，支持按项目、日期、人员检索历史纪要。

我选这个例子是因为它足够典型：有文件上传、有内容解析、有结构化数据建模、有检索功能，完全能真实反映一套全栈 AI 编程会遇到的各类问题。虽然是模拟项目，但过程中踩到的坑和真实工作没有区别，你也可以把它换成任何业务系统来推演。

3.2 第一步：让 Claude Code 生成工程SDD 文档

整个流程的第一步不是写代码，而是让 Claude Code 生成一份完整的设计文档。我实际用的提示词是这样的：

你是一名资深全栈架构师。请为以下系统输出一份完整的系统设计文档：会议纪要知识库系统。 功能需求包括：上传会议录音或文字稿，自动生成摘要与待办事项，待办可分配负责人和截止时间，支持按项目、日期、人员检索历史纪要。 技术栈约定：前端 React + Tailwind，后端 Node + Express，数据库 PostgreSQL，部署用 Docker Compose。 输出要求：包含系统边界、核心实体与字段定义、模块划分与目录结构、接口清单（方法+路径+入参出参）、核心业务规则清单。 不要实现代码，只做设计，并在文档末尾列出你识别出的设计风险点。

跑完一轮后，把文档里明显不符合预期的部分改掉。比如我预期的是“全公司可看、编辑仅限本人”，模型默认给成了所有人可编辑，这种偏差就需要人工校正。修改后让模型根据反馈再更新文档，来回一两轮，直到稳定为止。这一步是整个流程里最花时间但最值得的部分。

3.3 第二步：在 Cursor 里按设计稿搭建骨架

设计文档定稿后，打开 Cursor 新建一个会话，让它“基于仓库根目录下的设计文档搭建项目骨架”。

这一环节的关键在于：一定要让 Cursor 先读设计文档，而不是直接让它“帮我搭建一个会议纪要项目”。没有文档时，模型会按它自己脑补的结构来建目录、命名、划分模块，后续代码跟文档一定对不上；有文档时，模型会老老实实照着文档建目录、定义接口、写模型，两边才能始终保持一致。

我在提示词里还会加一个要求：“不要一次性把所有文件全生成出来，按模块顺序逐个生成，每个模块完成后等我确认再生成下一个。”这一步的作用是把大任务切成小步，减少模型上下文漂移和错误扩散。一键全出的方式看起来很爽，但出错之后排查成本的增加远远超过那点省下的时间。

3.4 第三步：多 Agent 并行开发

项目骨架稳定后进入多 Agent 并行开发阶段。我的典型编排方式是：

Claude Code 负责后端和数据库：基于设计文档生成建表脚本、Express 路由、DAO 层和数据校验逻辑，跑完一个模块就自动写一个冒烟测试，并在完成报告里说明它做了什么、改了什么、需要人工注意什么。

Cursor 负责前端：基于设计文档和后端接口清单生成 React 页面和组件，每个页面生成后先检查是否与接口契约一致，不一致的地方主动标记出来。

两者连通的关键是接口契约文档。前端 Agent 依赖它确定调用方式和数据格式，后端 Agent 依赖它确定实现目标和测试要求。我只要保证这份文档在两边共享且始终不漂移，多 Agent 就能在互不干扰的情况下协作完成同一套系统。这种模式跑顺之后，项目的推进速度基本是传统写法的两三倍。

3.5 第四步：联调验收，从“代码能跑”到“项目能落地”

AI 生成的代码在联调阶段频繁出现的一个现象是：单看每个模块都没问题，组合在一起就各种报错。原因通常集中在三处：字段名不一致，比如后端返回 user_id，前端用的 userId；状态码约定不一致，后端返回 200/500，前端默认检查 201；异常处理缺失，后端没有对空值做兜底，前端拿到数据直接崩了。

我的验收流程分三步：第一步让后端 Agent 自测所有接口，输出一份接口自测报告；第二步让前端 Agent 对照报告调整调用逻辑；第三步我人工过一遍核心链路——注册登录、上传解析、生成待办、检索展示——每一步出错就让对应 Agent 去修，并把修法更新回公共设计文档。

验收标准也用文档固化。最简单的四件事：核心链路无报错、无未处理异常、无硬编码配置、构建与测试指令全部通过。这四个标准足够筛掉 AI 代码里绝大多数“能用但脆”的问题。这一节说白了就是：AI 写代码可以快，但验收标准不能省，这是从“代码能跑”到“项目能落地”的分水岭。

4. 实战高频问题与排查技巧实录

把这条工作流里反复遇到的坑整理成一份速查表，每条都是真实项目中踩过至少一次的。

4.1 上下文失忆与返工死循环

最典型的问题是：对话到三四个小时后，模型开始“忘记”自己上午写的代码，产出自相矛盾的方案。比如让它加一个筛选功能，它可能把整个数据层接口重新发明了一遍，而不是去改原有函数。踩过几次坑后，我的对策很干脆：对话超过 50 轮或者任务跨天，直接开新会话，把设计文档和“已完成清单”重新作为上下文喂进去。新会话成本低，但上下文干净，产出质量反而比死拖在旧会话里高得多。

另一个高频死循环是：让模型修一个 bug，它修改 A 处后 B 处开始报错；修 B 后 C 又报错，最后项目满目疮痍。这种返工的源头是需求不细、验收标准不明确。我现在的提示词模板都会带上三样东西：现象描述、期望行为、验收标准。比如“登录接口在输入正确密码时返回 500，期望返回 200 并带上 token，修复后自行调用一次验证并说明改动点”。给模型一个明确出口，它就不会在闭环里打转。

4.2 多 Agent 协作时的文件冲突

多 Agent 并行开发最大的坑是文件冲突。两个 Agent 同时改了同一个文件，后者把前者调好的逻辑直接覆盖了。这个问题最有效的破解思路是继续把“边界”切细：尽量做到一个 Agent 只动自己的文件，跨文件改动必须通过公共层接口完成；如果团队模式支持分支隔离，还可以让不同 Agent 在不同分支开发，最后由人工合并。

我有一次临时让两个 Agent 同时处理前端两个页面，因为共享一个公共组件文件，结果互相覆盖了三轮才发现。后来我会先把共享文件的改动方案事先定死，再交给专人处理，这个坑才算治住。多 Agent 不是越多越好，边界切得清不清，直接决定并行开发的成败。

4.3 依赖与版本管理的隐性风险

还有一个容易被忽略的问题是版本管理。AI 生成代码特别爱自动拉取新版依赖，结果前两天还能构建的项目，第三天安装依赖之后直接编译失败。处理办法很朴素：用包锁文件固定所有依赖版本，锁文件纳入版本控制，任何升级都必须走显式审批流程，而不是让模型自由发挥。

同样的道理也适用于运行时环境。AI 生成的 Dockerfile 里如果出现不带版本号的镜像标签，我会一律改成固定版本。这类问题在传统开发里靠的是运维纪律，在 AI 编程时代，纪律得靠配置文件和检查脚本提前焊死，不然迟早要还。

4.4 AI 代码的人工评审要点

最后补一个建议：AI 生成的代码也要做评审，而且评审难度比人写的还高，因为你不知道它是从哪里学来的写法。我个人的习惯是：每完成一个模块，让模型先自述改动和风险；然后人工重点看三个位置——异常处理、安全边界、依赖引入，这三个位置是 AI 代码的重灾区。

安全边界尤其容易出问题，比如没有做输入校验、缺少外键约束、密钥直接写进代码里。这部分人工审查一刻都不能省。记住一个原则：AI 负责速度和广度的探索，人负责质量和安全的底线。

5. 落地的三个阶段与个人经验总结

5.1 从认知、流程到场景，分阶段渐进落地

想把这套玩法真正落地到自己的项目里，我的建议是分三个阶段走，切忌一上来就全面铺开。

第一个阶段先接受“代码可以被 AI 生成”这个事实，拿一个小项目试着完整跑一遍，亲自体验模型的上限和下限；第二个阶段引入工程SDD 文档和规则文件，观察模型产出的稳定性变化，这个阶段你开始能控制它；第三个阶段再引入多 Agent 协作，把项目拆成可并行的模块，形成一套稳定可复制的流水线。三个阶段对应三种能力：会用、能控、能编排。每一步踩稳了再往前走，比一次性铺开要可靠得多。

5.2 团队推广视角的几个建议

如果是团队想推广这套模式，阻力往往不在工具，而在习惯。反对声音里最大的一条是：“AI 生成的代码我看不懂，不敢让它动生产代码库。”我的回应是：不需要一下子全放权，可以先让 AI 从边缘场景做起，比如生成测试脚本、维护编译配置文件、产出文档，等到稳定运行一段时间后，再逐步扩展到核心业务。信任是建立在一次次小成功之上的，靠一次推倒重来的大动作很难服众。

在团队里还要解决一个认知问题：AI 编程不是要替代程序员，而是把程序员的职责重心从“写代码”推向“定义系统、审查质量、把控风险”。谁先适应这个转变，谁就能在这轮工具变革里拿到真正的效率红利。

5.3 最后分享一个零成本的小技巧

最后分享一个我自己用了很久、效果极好的小技巧：在仓库里维护一个 AI_LOG.md 文件，专门记录和 AI 协作过程中的关键决策——今天让模型改了哪个模块、为什么改、改了之后遇到什么问题。下一次开新会话时，把这份日志和历史设计文档一起喂给模型，它就能在某种程度上“继承记忆”，减少重复犯错的概率。

这个文件不是写给人类看的，而是写给后来接手的 AI 会话看的，每条只要几行字，但价值非常大。项目越复杂，这个文件越值钱。我目前手头维护的每个中大型项目都有这么一份日志，实测下来，新会话的“上手速度”比没有日志时快了不止一个台阶。

说到底，Vibe Coding 这几个字里的关键不是 Vibe，而是 Coding 背后的工程意识。工具会迭代，模型会升级，但“先设计、再生成、勤验收”这套底层的工程方法，会是接下来很长一段时间里真正拉开人与人效率差距的东西。希望这篇实战经验，能让你少走几步我走过的弯路。