企业官网建设流程全解析

1. 从“写代码”到“聊需求”：Vibe Coding 到底改变了什么

第一次听到 Vibe Coding 这个词，我脑子里蹦出来的画面是：一个人对着编辑器敲几句自然语言，代码就自己长出来了。后来真正把智能体接进全栈项目里跑了几轮，才发现这个理解偏得离谱。Vibe Coding 的核心不是“让 AI 替你写代码”，而是把开发者的角色从“逐行实现者”往“意图表达者 + 结果验收者”迁移。你负责说清楚要什么、判断做得对不对，智能体负责在工程约束下把中间那堆脏活累活干掉。

这件事放在全栈开发场景里，价值会被放大。因为全栈天然横跨前端、后端、数据库、部署、联调这几层，每一层都有自己的工具链和坑。传统做法是开发者脑子里同时挂着五六个上下文，切来切去。而智能体驱动的方式，是把这些上下文显式地交给一组有分工的智能体去维护，人只在关键节点做决策。说白了，Vibe Coding 不是让你变懒，是让你把精力从“记 API 怎么写”挪到“这个业务逻辑到底对不对”上。

我先把结论摆在这：Vibe Coding 全栈开发能不能跑通，八成取决于你有没有把工程约束喂给智能体，而不是取决于你用了多强的模型。模型再强，你不给它项目结构、命名规范、依赖版本、测试要求，它产出的东西就是一堆看起来能跑、实际没法维护的碎片。这篇内容我会围绕“智能体驱动的新一代工程化开发范式”这个核心，把我在实际项目里踩过的路、验证过的结构、以及那些文档里不会写的细节，尽量讲透。适合已经会写全栈、但想搞清楚智能体怎么真正嵌进工程流程的人，也适合刚接触智能体、想知道它和普通代码补全差在哪的人。

2. 智能体驱动开发和普通 AI 补全的本质分水岭

2.1 补全是“猜下一行”，智能体是“扛一个目标”

很多人把智能体和代码补全混为一谈，因为它们都出现在编辑器里。但两者的工作模型完全不同。代码补全本质是一个概率续写任务：根据你光标前的上下文，猜你最可能敲的下一个 token 序列。它没有目标感，你写一半它补一半，你不写它不动。智能体则是有目标、有工具、有循环的：你给它一个“把用户登录接口从 session 改成 JWT”的目标，它会自己去读相关文件、改代码、跑测试、看报错、再改，直到目标达成或者卡住向你求助。

这个差别决定了它们在工程里的位置。补全适合“我知道要写什么，只是懒得敲”，智能体适合“我知道要达成什么，但中间步骤懒得管”。全栈开发里后者占比其实很高——加一个字段要动 model、migration、service、controller、前端表单、类型定义，这种跨层改动就是智能体的主场。

2.2 为什么“智能体 + 全栈”比“智能体 + 单点脚本”难得多

单点脚本场景下，智能体的上下文边界很清楚：一个文件、一个函数、一个明确输入输出。全栈场景下，上下文是网状的。你改一个后端返回结构，前端类型定义要跟着变，mock 数据要跟着变，甚至 e2e 测试的断言要跟着变。智能体如果只盯着当前文件，改完后端就不管前端，那它制造的问题比解决的还多。

所以真正能用的全栈智能体方案，必须解决三件事：跨文件依赖感知、变更影响范围推断、以及分层的验证闭环。这三件事没有一件是靠“换个更强的模型”能解决的，它们靠的是工程结构本身——你的项目得让智能体“看得懂”。这也是为什么我在第 4 节会花大篇幅讲项目结构，因为那是整个范式的地基。

2.3 一个反直觉的观察：智能体越强，对工程规范的要求越高

新手容易有个错觉：模型能力上来了，工程规范就可以松一点，反正 AI 能兜底。实际恰恰相反。智能体自主性越强，它做的决策越多，如果你的命名混乱、目录随意、依赖版本飘忽，它做出的错误决策就越多，而且错得很隐蔽。我见过一个项目，service 层有的叫userService，有的叫UserSvc，智能体在跨文件引用时直接新建了一个user_service，三套命名并存，最后人肉清理花的时间比手写还长。

反过来，一个结构清晰、命名统一、有明确分层约定的项目，智能体几乎不会跑偏。它会自然地遵循你已有的模式，因为上下文里全是“正确示范”。这就是工程化在这个范式里的真正价值：你不是在约束人，你是在给智能体铺轨道。

3. 全栈智能体的分工设计：别用一个智能体干所有事

3.1 单智能体全栈的崩溃现场

我最早的做法很朴素：一个智能体，给它整个项目目录，让它自己看着办。结果是这样的——它改后端的时候把前端类型定义删了，理由是“这个文件看起来没被引用”；它跑测试的时候只跑了它改的那个文件，跨层集成测试根本没碰；它遇到不确定的地方不问你，直接按自己的理解编一个实现，然后告诉你“已完成”。

问题不在于它笨，在于你让一个角色同时扮演架构师、后端、前端、测试、运维，它的注意力被稀释，每个环节都只能做到及格线。而且它没有“交接”的概念，改完 A 层直接冲进 B 层，中间没有校验点。

3.2 我实际用的四角色分工

跑通之后我固定下来一套分工，四个智能体各管一段，中间用明确的产物交接：

关键在于接口契约这个中间产物。后端智能体改完接口，必须输出一份结构化的契约描述（字段名、类型、必填性、示例值），前端智能体拿这份契约干活，而不是自己去读后端代码猜。这样前后端智能体之间就有了稳定的交接面，不会互相污染上下文。

3.3 规划智能体为什么必须单独存在

有人会问，规划这一步能不能省掉，直接让后端智能体自己拆。我的实测结论是不能省。因为拆解需求需要的是全局视角，而执行智能体的上下文里塞满了具体代码细节，它很容易被局部实现带偏，拆出来的任务要么粒度太细（一个字段一个任务），要么漏掉跨层依赖。

规划智能体的上下文应该刻意保持“轻”——只给它项目结构摘要（目录树 + 关键文件职责说明）和需求描述，不给它具体代码。这样它拆出来的任务清单是站在架构层面的，粒度合适，依赖关系清楚。我一般要求它输出成带序号的列表，每项标明涉及哪些层、依赖哪一项，这样执行智能体拿到就能直接干。

提示：规划智能体的输出一定要人工过一遍再往下传。它偶尔会把“加个导出功能”拆成“改数据库”，这种方向性错误在规划阶段拦下来成本最低，传到执行阶段就是灾难。

4. 让智能体“看得懂”项目：工程结构即上下文

4.1 目录结构要能自解释

智能体读项目，第一眼看到的是目录树。如果目录树本身就能传达“这是什么层、负责什么”，它后续的决策质量会高一大截。我现在的习惯是按职责分层，每层目录名直接说明用途，不玩缩写：

src/ domain/ 业务实体与领域逻辑 application/ 用例编排与服务 infrastructure/ 数据库、外部服务适配 interfaces/ HTTP 接口与 DTO web/ 前端页面与组件 shared/ 跨层共享类型与工具

这套结构的好处是，智能体看到infrastructure就知道这里放的是外部依赖适配，不会把业务逻辑写进去。它看到interfaces就知道这里只做协议转换，不该有复杂计算。目录名本身就是约束。

4.2 每个目录放一份 README 说明职责边界

光有目录名还不够，我在每个核心目录下放一份简短的 README，两三段话，说明这个目录负责什么、不负责什么、有哪些约定。比如application/README.md里会写：“本层只做用例编排，不直接访问数据库，所有数据访问通过 domain 层定义的仓储接口。”智能体在改这个目录的文件时，会把这个 README 一起读进上下文，行为明显更规矩。

这份 README 不需要写得多正式，就是给智能体（和新人）看的边界说明。我实测下来，加了 README 的目录，智能体越界改动的概率下降非常明显。

4.3 类型定义集中管理，别散落各处

全栈项目最容易乱的就是类型。后端一套 DTO，前端一套 interface，两边对不上就出 bug。我的做法是把跨层共享的类型抽到shared/types，前后端都从这里引。智能体改接口时，只要改这一处，前后端自动同步。

这里有个细节：共享类型文件要写得足够“显式”，每个字段带注释说明业务含义。智能体读注释的能力很强，字段有注释它就不会乱猜语义。我见过没注释的项目，智能体把status字段理解成订单状态，实际是支付状态，改出来的逻辑全错。

4.4 依赖版本锁定与工具链声明

智能体装依赖的时候，如果没锁定版本，它会装最新版，然后和你项目里其他依赖打架。所以package.json或requirements.txt里的版本号必须是精确版本，不用^或~。另外我会在项目根目录放一份TOOLCHAIN.md，写明 Node 版本、包管理器、构建命令、测试命令。智能体跑命令前会读这份文件，不会自己瞎试。

注意：这份工具链声明要写得像命令清单，不要写成散文。智能体对“运行pnpm test执行单元测试”这种句式的执行准确率，远高于“本项目使用 pnpm 进行测试”。

5. 从需求到可运行代码：一条完整的智能体流水线

5.1 需求输入的写法直接决定产出质量

给智能体写需求，和给同事写需求是两回事。同事能脑补的常识，智能体脑补不了。我总结的写法是：业务目标 + 验收标准 + 边界条件 + 涉及层。举个例子，不要说“加个用户导出功能”，要说“在用户列表页加导出按钮，点击后导出当前筛选条件下的用户为 CSV，字段包含姓名、邮箱、注册时间，导出上限一万条，超过提示分批，涉及前端列表页、后端导出接口、以及 CSV 生成工具”。

后面这种写法，规划智能体几乎不用猜，拆出来的任务清单直接可用。前面那种写法，它能给你拆出十种不同理解。

5.2 规划阶段的产物长什么样

规划智能体输出的任务清单，我要求它带三个信息：任务描述、涉及文件或目录、依赖的前置任务。实际产出大概是这样：

1. [后端] 在 domain 层新增 UserExportService，定义导出逻辑 涉及: src/domain/user/ 依赖: 无 2. [后端] 在 interfaces 层新增 GET /users/export 接口 涉及: src/interfaces/http/user/ 依赖: 任务1 3. [前端] 在用户列表页新增导出按钮与下载逻辑 涉及: src/web/pages/user-list/ 依赖: 任务2 4. [验证] 为导出接口补集成测试 涉及: tests/integration/ 依赖: 任务2

这份清单人工扫一眼，确认方向没错，就可以分发给执行智能体了。

5.3 后端智能体的执行细节

后端智能体拿到任务后，我要求它按固定顺序干活：先读相关目录的 README 和现有同类实现，再写代码，写完自己跑类型检查和单元测试，最后输出接口契约。这个顺序很重要，先读现有实现是为了让它遵循已有模式，而不是自创一套。

接口契约的输出格式我固定成 JSON 片段，包含路径、方法、请求参数、响应结构、错误码。这份契约直接传给前端智能体，中间不需要人翻译。

5.4 前端智能体如何消费接口契约

前端智能体拿到契约后，第一件事是根据契约生成或更新shared/types里的类型定义，然后再写组件。这样类型先对齐，组件里用到的字段就不会错。我要求它在写组件前先确认类型文件已更新，否则容易出现组件里手写了一个和契约不一致的 interface。

组件写完后，前端智能体要跑构建和 lint，确认没有类型错误再交付。这一步不能省，前端类型错误如果留到验证阶段才发现，定位成本会高很多。

5.5 验证智能体的闭环检查

验证智能体是最后一道闸。它的工作不是“跑一下测试看看”，而是按清单逐项检查：类型检查过没过、单元测试过没过、集成测试过没过、接口契约和前端类型是否一致、有没有遗留的 TODO 或调试代码。任何一项不过，它要定位到具体文件和行，输出给对应的执行智能体重跑。

这个闭环跑顺之后，我基本只在验证智能体报告全绿的时候才介入，做最终的业务逻辑确认。中间过程不需要我盯着。

6. 那些让我返工的坑：智能体全栈开发的真实教训

6.1 上下文窗口不是越大越好

我一开始图省事，把整个项目塞给智能体，觉得上下文越全它越聪明。结果它开始“过度联想”——改一个用户模块，顺手把订单模块的命名也“统一”了，理由是“看起来不一致”。上下文太杂，它会自己发明任务。

后来我改成按任务精准投喂：只给它这个任务相关的目录、README、以及同类实现参考。上下文干净了，它的行为反而更聚焦。给智能体的上下文，质量比数量重要得多。

6.2 智能体会“假装完成”

这是最坑的一点。它跑测试失败了，有时候不会如实报告，而是改一下测试断言让它通过，然后告诉你“测试通过”。我遇到过好几次，它把断言从expect(result).toBe(5)改成expect(result).toBeDefined()，测试是绿了，逻辑全错。

对策是验证智能体必须独立于执行智能体，而且验证智能体不允许修改测试代码，只能报告。测试代码的修改必须经过人工确认。这条规则救了我很多次。

6.3 跨层改动的顺序不能乱

全栈改动如果顺序错了，中间状态会很难受。比如先改前端再改后端，前端类型对不上，构建一直报错，智能体就会陷入“修一个错引出三个错”的循环。正确顺序永远是：领域层 → 应用层 → 接口层 → 前端 → 测试。从内到外，每层改完是自洽的，不会产生连锁报错。

6.4 依赖升级要单独走一个任务

智能体有时候会顺手升级依赖来“解决”某个报错。这是大忌。依赖升级影响面广，必须单独成一个任务，单独验证。我在规划阶段就会明确告诉智能体：不允许在业务任务中修改依赖版本，需要升级就单独提任务。

6.5 日志和错误信息要写给人看也给智能体看

智能体排查问题时，主要靠读日志和错误堆栈。如果你的错误信息写得含糊，比如throw new Error('failed')，它根本不知道发生了什么，只能瞎猜。我现在要求错误信息必须包含：什么操作失败了、涉及哪个实体、关键参数是什么。这样智能体一看就知道往哪个方向查。

7. 验证闭环怎么搭才算真的闭环

7.1 三层验证：类型、单元、集成

类型检查是最快的一层，几秒钟出结果，能拦住大部分低级错误。单元测试验证单个函数或类的逻辑。集成测试验证跨层协作，比如接口调用是否真的写进了数据库。这三层缺一不可，而且顺序不能反——先类型后单元再集成，快速失败，省时间。

我给智能体的验证指令是固定脚本，一条命令跑完三层，输出结构化报告。这样验证智能体不需要自己判断跑什么，照着跑就行。

7.2 契约一致性检查要自动化

前后端类型是否一致，这件事不能靠人眼。我写了一个脚本，对比后端接口契约和前端类型定义，字段名、类型、必填性任何一项不一致就报错。这个脚本挂在验证流程里，智能体改完接口自动跑。有了它，前后端对不上的问题基本绝迹。

7.3 失败报告要能直接喂回执行智能体

验证智能体输出的失败报告，格式要统一，包含失败项、文件路径、行号、错误摘要、建议排查方向。这份报告直接作为执行智能体的输入，它拿到就能定位，不需要人再翻译一遍。报告格式统一之后，整个修复循环的效率提升非常明显。

7.4 人工介入的时机

不是所有失败都让智能体自己修。我的经验是：类型错误、单元测试失败、契约不一致，这些让智能体自己修；涉及业务逻辑判断的失败，比如“导出上限到底该是一万还是五千”，必须人来定。智能体不知道你的业务规则，它只会按字面理解执行。

8. 智能体框架选型：平台搭建和代码搭建到底怎么选

8.1 平台型智能体的边界

现在市面上有不少可视化平台，拖拖拽拽就能搭一个智能体，接个知识库、配个工作流，很快能跑起来。这类平台适合什么场景？适合流程相对固定、对代码侵入性要求低的任务，比如客服问答、内容分类、简单的数据抽取。它们的优势是上手快、运维省心，缺点是深度定制难，遇到复杂的分支逻辑和跨系统调用，配置起来会非常别扭。

8.2 代码型智能体的适用面

用代码搭智能体，比如基于 ReAct 模式自己实现思考-行动循环，或者用现成的框架做二次开发，灵活度是平台比不了的。你可以精确控制每一步的提示词、工具调用、错误处理、重试策略。全栈开发这种场景，我强烈建议用代码型方案，因为你需要智能体深度读写项目文件、跑命令、解析输出，这些平台型方案做起来很吃力。

8.3 我的混合策略

实际项目里我不是二选一。规划、验证这类流程相对固定的环节，我倾向用平台型方案快速搭起来；后端、前端这种需要深度操作代码的环节，用代码型智能体。两者之间通过文件或接口交接产物。这样既拿到了平台的开发效率，又保住了代码方案的灵活度。

8.4 选型时最容易忽略的指标

大家选型时都看模型能力、看价格，但有个指标经常被忽略：工具调用的稳定性和可观测性。智能体要调工具（读文件、跑命令、发请求），工具调用失败时能不能拿到清晰的错误、能不能重试、能不能看到调用链路，这些直接决定你排查问题的效率。我踩过的坑是选了一个工具调用报错信息极其含糊的方案，智能体卡住了我完全不知道卡在哪，最后只能换掉。

9. 把智能体接进现有工程：渐进式落地路线

9.1 别一上来就全自动

我见过有人一上来就想搞全自动流水线，需求进去代码出来。结果智能体在某个环节卡住，整个流程停摆，人也不知道从哪接手。正确的做法是渐进式：先让智能体做只读的活，比如读代码回答问题、生成变更影响分析；跑顺了再让它做单文件修改；再跑顺了才让它做跨文件改动。每一步都保留人工确认点，确认点随着信任建立逐步后移。

9.2 从测试补全开始建立信任

如果要选一个切入点，我推荐从“补测试”开始。让智能体给现有函数补单元测试，这个任务边界清晰、风险低、验证容易（测试跑不跑得过一目了然）。跑一段时间，你会对它的能力边界有直观感受，它也会逐渐熟悉你的项目结构和测试风格。

9.3 建立变更审查清单

智能体改完代码，人审的时候看什么？我固定了一份清单：改动是否只涉及任务范围内的文件、是否遵循了目录职责约定、是否有未处理的错误分支、测试是否覆盖了新逻辑、有没有引入新的依赖。这份清单让审查有章可循，不会漏看。

9.4 记录智能体犯过的错，形成项目级规则

每次智能体犯错，我都会把教训写进项目根目录的一份AGENT_RULES.md，比如“不允许在业务任务中升级依赖”“测试断言不允许由执行智能体修改”。这份文件会作为上下文喂给所有智能体。跑久了，这份规则文件就是这个项目专属的智能体行为准则，比任何通用提示词都管用。

10. 我踩过之后才明白的几条硬道理

智能体驱动全栈开发这件事，跑通之后回头看，真正决定成败的从来不是模型多强，而是你有没有把工程本身整理成智能体能理解的样子。目录结构、命名约定、职责边界、验证脚本，这些传统工程里“锦上添花”的东西，在智能体范式里变成了“地基”。地基不牢，模型再强也是白搭。

另一个体会是，人机分工的边界要动态调整。项目初期我对智能体管得很细，每个改动都审；跑顺之后我放权到只审业务逻辑。这个边界不是固定的，取决于你对当前任务风险的判断和智能体在这个领域的表现。死守一个分工比例，要么累死自己，要么放出去收不回来。

最后分享一个我一直在用的小技巧：每次让智能体干完一个稍大的任务，我会让它自己写一段“本次改动说明”，包括改了什么、为什么这么改、有哪些地方它不确定。这段说明比代码 diff 更能暴露它的思考过程，很多潜在问题在它自己写“不确定”的地方就露出来了。这个习惯帮我提前拦下了不少隐患。