企业官网建设流程全解析

年初的时候，我做了一个至今想起来还是会咂摸一下的决定：用VibeCoding的方式，给公司搭一个业务配置平台。

起因很现实。我们业务线一多，各种营销活动参数、审批流规则、表单字段全写死在代码里，产品改一个小配置都得提工单、排期、等发版。有一次运营配置一个限时活动，价格系数填错了没被发现，线上跑了两小时，损失虽然不算大，但整个团队被折腾得够呛。当时我就在想，能不能搞一个平台，让业务同学自己配、自己审、自己上线？

按以前的做法，这种平台从需求评审到上线怎么也得三四周。但那个时候正好是VibeCoding这个概念火起来的时候，我也在AI编程工具上尝到了甜头，就决定换个路子：不用传统的那套需求文档+架构设计+分工开发的流程，而是全程用自然语言和AI结对编程，把这个配置平台从0到1干出来。这篇文章就是我完整的过程复盘，包括我是怎么用对话的方式让AI一步步生成代码、功能模块怎么拆、踩了哪些坑、最后效果怎么样。如果你也想尝试VibeCoding，或者正准备做类似的后台配置系统，这篇应该能帮你少走不少弯路。

1. 为什么我决定用VibeCoding来啃这个项目

1.1 业务配置平台到底在解决什么问题

我先说一下业务配置平台是干嘛的。你可以把它理解成一个"给业务用的遥控器"：页面展示、表单字段、活动规则、审批流、定时任务参数，这些原本需要开发改代码才能变的东西，全部抽成可视化配置项，业务同学在页面上自己改，保存后立即或定时生效。

我梳理了一下当时的需求，主要分三类：

• 参数配置：比如活动折扣、风控阈值、缓存开关、第三方接口地址。这类配置的特点是量小、改动频繁、影响面大。
• 表单配置：比如工单系统的字段增删、下拉选项的调整、字段是否必填。这类配置需要一定的动态渲染能力。
• 流程配置：比如审批链路、自动通知规则、指派策略。这类配置最复杂，涉及状态流转。

这三类配置有一个共同点：都是典型的CRUD加状态管理，没有复杂的算法，也没有特别极端的性能要求。这就决定了它是一个非常适合用AI辅助开发（VibeCoding）的项目。

1.2 传统开发方式为什么让我觉得忍不了

在配置平台之前，我们改一个业务参数要走这样的流程：运营提需求给产品，产品写PRD，研发评估排期，开发改代码，测试回归，最后找一个发版窗口上线。运气好的话，一个小参数改动从提出到生效也要一两天，运气不好撞上版本冻结，等一周很正常。

这中间最让人崩溃的不是开发本身，而是"链路损耗"。一个配置改动，本质上只是把一个数字从1改成2，但因为它长在代码里，就得走完整套变更流程。业务人员和研发都被这种低效消耗搞得很有怨气。

我当时算过一笔账：我们团队一个季度大概要处理超过60个配置相关的需求工单，平均每个从提报到上线要1.8天。如果有平台让业务自助操作，哪怕流程上保守一点、带审批，平均耗时也能压缩到小时级。这笔账一算，平台的ROI就非常清楚了。

1.3 VibeCoding这种开发模式为什么适合这个场景

先解释一下VibeCoding这个词。它是2025年初开始火起来的，大意是：你不再逐行敲代码，而是用自然语言把需求描述给AI编程工具，让它直接生成代码；遇到报错了，也不用自己去翻堆栈，直接把错误信息丢给AI让它修；你更多是提供一个"氛围"和方向，所以叫"跟着感觉编程"。

当然，我理解VibeCoding不是完全躺平。我自己在实践中给它加了一条修正：方向我管，细节AI管。尤其是配置平台这种项目，它有一个非常讨喜的特点——结构高度重复。配置列表、配置编辑、配置发布、操作日志，每一类配置都是差不多的页面和接口。这意味着AI一旦学会了第一套模式，后面就是纯复制粘贴式的高效输出。这正好是AI最擅长的事情。

所以我的判断是：用传统方式开发这个平台，投入大、周期长；用VibeCoding方式，风险和收益的平衡点非常理想。就算中间有些代码要返工，整体成本依然可控。事实证明这个判断是对的。

2. 项目从0到1：我和AI的结对编程工作流

2.1 开工前的技术选型，我用一次对话搞定

以前选型得开会、调研、写对比文档，这次我直接把自己的约束条件甩给了AI，让它在给定范围内做选型。

我当时是这么说的：

我要开发一个公司内部的业务配置平台，前端需要比较成熟的中后台组件库，后端要求开发效率高、和前端语言栈统一，数据库用MySQL，缓存用Redis。请给出具体技术栈选型建议，并说明理由。

AI给了一套方案：前端Vue3 + Element Plus + Pinia，后端NestJS + TypeORM，MySQL存配置定义和发布记录，Redis存生效中的配置快照。选型理由也说得挺清楚：Vue3加Element Plus是国内中后台开发的主流组合，轮子多，遇到问题好搜；NestJS是TypeScript全栈，和前端语言统一，能减少上下文切换；TypeORM配合MySQL见了太多项目在用，AI训练语料充足，生成的代码踩坑概率低。

我没有完全照单全收，自己做了一个调整：把TypeORM换成了Prisma。理由是我之前用过Prisma，觉得它的类型提示和迁移工具更顺手。这个事也体现了VibeCoding的一个原则——工具和架构的最终决定权还是在人手里。

2.2 让AI先跑通一个MVP，而不是一上来就求完整

我见过很多人用VibeCoding失败，最大的原因是一上来就提一个巨大的需求，AI生成几百个文件，结果哪哪都是问题，根本找不到头绪。我的做法相反，第一阶段目标非常小：先做一个"配置分组 + 配置项列表 + 新建配置"的闭环。

我用的提示词大概是这样的：

在项目的现有框架里，帮我实现一个配置管理模块。功能要求如下：

1. 配置分组表：字段包括id、名称、编码、排序、创建时间；
2. 配置项表：字段包括id、分组id、配置key、配置值、值类型、描述、状态、更新时间；
3. 提供配置项的分页查询接口、新增接口、修改接口；
4. 页面做一个左侧分组列表、右侧配置项表格，支持点击分组筛选，支持新增和编辑配置项的对话框表单；
5. 配置值类型支持字符串、数字、布尔、JSON四种，表单里要对应生成不同的输入控件。

这一步的产出速度是真的快，AI大概一两分钟就把表结构、接口和页面框架都搭出来了。虽然页面丑了点，也不够灵活，但"能跑、能连库、能增删改查"这个核心闭环是通的。

这里有一个很重要的经验：VibeCoding第一版的目的不是"好"，而是"通"。业务配置平台这种系统，只有链路通了，你才看得到数据是怎么流的，才知道AI哪些地方理解错了、哪些地方需要你介入。第一版越简单越好。

2.3 分层推进，别让AI跨层乱改

MVP通了之后，我没有继续在一个AI会话里无限加需求，而是把项目拆成三层，每一层单独推进：

• 模型层：配置版本、配置变更记录、灰度发布表、审批状态机相关表结构。
• 接口层：配置提交评审接口、发布接口、回滚接口、配置拉取接口。这里开始涉及权限校验、数据校验、缓存更新。
• 页面层：配置列表增加版本号和发布状态列，新增"提交审批"和"发布"操作按钮，新增审批中心页面。

为什么分层推进这么重要？因为AI的上下文窗口是有限的。在一个会话里聊太久、改太多轮之后，AI会开始"遗忘"前面的约定，甚至自己改自己已经定义好的接口签名。我大概测出一个临界点：单个会话处理超过3到4个功能模块的修改，出错的概率就会明显上升。

所以我的策略是：每个功能模块开一个独立的会话，会话开头先把项目结构和已有约定简洁地喂一遍，再提具体需求。有点像对付一个记性不太好但能力很强的临时工——每次开工前都要让他快速过一遍背景，但具体活能干得很漂亮。

3. 平台核心功能拆解：配置平台该有的东西

3.1 元数据驱动的表单配置

配置平台最核心的能力是"动态"。你不能每加一个配置项都让研发写一个表单，那又回到了老路。所以我把配置项的值定义设计成了JSON Schema，前端根据Schema动态渲染控件。

一个典型的配置项Schema长这样：

{ "type": "object", "properties": { "discountRate": { "type": "number", "minimum": 0, "maximum": 100, "default": 90, "title": "折扣率", "description": "百分比，90表示9折" }, "enableMemberPrice": { "type": "boolean", "default": false, "title": "是否启用会员价" }, "maxPerUser": { "type": "integer", "minimum": 1, "maximum": 999, "default": 5, "title": "单个用户限购数量" } }, "required": ["discountRate", "enableMemberPrice"] }

前端拿到这个Schema之后，用一个统一的渲染组件把表单生成出来。AI生成这段渲染逻辑的时候我盯着看了一会儿，因为动态表单最怕的就是类型处理不当。它会根据type字段映射到不同的控件：number对应数字输入框，boolean对应开关，string对应文本输入，object则递归渲染子表单。JSON类型的配置值做成一个带格式校验的代码编辑器，编辑的时候实时做JSON.parse校验，解析失败不允许提交。

这一块的收益是巨大的：平台上每接入一种新的配置场景，只是新增一份Schema，连前后端代码都不用动。这也是我从这个项目里尝到的最大甜头。

3.2 规则配置与动态下发机制

配置平台不能只做到"存起来"，还得让配置真正在业务系统里生效。我们的方案是：配置发布时，把一份编译好的配置快照写入Redis，业务服务启动时加载一次，之后通过监听Redis的Key变更事件来做热更新。

这里有一个关键点，配置下发和本地缓存的最终一致性。我们用的思路非常简单：业务方读取配置时，先读本地Cache，没命中再查Redis，并记录当前的配置版本号；配置平台发布新版本时，Redis里的配置内容更新，同时递增版本号并发布一个Pub/Sub消息，业务方收到消息后把本地Cache失效，下一次读取自然拉到新值。

核心伪代码大概是这样的：

// 配置拉取接口（业务侧） async function getConfig(version: number): Promise<ConfigSnapshot> { const redisKey = `live:config:${configKey}`; const localCache = cache.get(configKey); if (localCache && localCache.version === version) { return localCache.data; } const snapshot = await redis.get(redisKey); cache.set(configKey, snapshot); return snapshot; } // 发布接口（配置平台侧） async function publishConfig(configId: number, payload: ConfigSnapshot) { const newVersion = await incrementVersion(configId); await saveAuditLog(configId, 'publish', payload); const redisKey = `live:config:${configId}`; await redis.set(redisKey, JSON.stringify({ ...payload, version: newVersion })); await pubSub.publish(`config:change:${configId}`, { version: newVersion }); await updateConfigMeta(configId, { status: 'published', version: newVersion }); }

这套方案不复杂，但足够解决大多数场景。AI在实现的时候需要你很清楚地把"版本号比对"和"缓存失效"这两个点交代清楚，否则它很容易写出"每次请求都查Redis"这种实现——功能没问题，性能上就是灾难。

3.3 发布审批与灰度控制

配置平台的"发布"不能没有节制。业务配置往往影响线上行为，必须要有审批和回滚能力。我在需求里给AI明确了一个状态机：

草稿 → 已提交 → 审批通过 → 已发布 → 已回滚

每个状态对应不同的操作权限和界面按钮。比如草稿状态只能编辑和提交，审批通过后不能再改配置内容，只能选择发布或打回；已发布状态下允许一键回滚到上一个已发布版本。

灰度控制我们做得比较务实，没有上特别重的全链路灰度平台，而是做了两件事：

• 环境隔离：同一条配置在不同环境（开发、测试、生产）有独立的配置值和发布状态，不会出现测试改了一个值带到生产的情况。
• 按发布批次生效：生产环境的配置发布支持"先部分生效，再全量生效"，操作系统内先对白名单用户或内部员工生效，观察一段时间没有异常再全量发布。

审批这一块，我让AI基于状态机把权限判断写成了装饰器，比如@RequirePermission('config:publish')，保证即使页面有入口，后端接口也会二次校验。这是我反复跟AI强调不能含糊的地方——配置平台最容易出安全事故的环节就是越权发布。

4. 踩坑实录：VibeCoding不是万能药

4.1 AI会一本正经地编造不存在的API

这是我在项目里遇到的第一个大坑，而且出现得非常早。MVP阶段，AI生成的TypeORM查询代码里用了一个我印象中不存在的方法，我当时没仔细看就跑了，结果编译直接报错。我把报错丢给AI，它道歉，然后换了一个同样不存在的写法。连续三轮都在编造API，最终我翻了官方文档确认正确的用法，让它照着改。

这种"自信编造"在AI生成代码里太常见了，尤其是涉及第三方库的API时。Element Plus里有些组件的属性名，AI会记成一个很相近但确实不存在的名字；Prisma的查询参数少写一层嵌套也是家常便饭。

我的排查思路是这样固化的：第一轮出错后，如果AI给的修复仍然编译不过，就不要再和它来回拉扯。直接自己查一下库的官方文档或者旧项目里已验证过的用法，把正确的API形态贴给它，让它对齐。简单说就是：AI不懂装懂的时候，你负责打破砂锅问到底。

4.2 架构碎片化，不同会话生成的代码风格各搞一套

项目中期，我开始明显感觉到一个不舒服：不同AI会话生成的代码，风格完全不是一个人写的。有的接口返回格式是{ code, data, message }，有的是{ success, data, error }；有的工具函数放在utils/，有的放在helpers/。虽然都能跑，但维护起来非常痛苦。

这个问题不能怪AI，根源在我——我没有在项目开始就给它建立统一的"代码宪法"。后来我在项目根目录加了一个CLAUDE.md文件（其他工具如Cursor也有类似机制），把全局约定写清楚：接口返回格式、目录结构、命名规范、状态码定义、数据库命名规则、禁止使用any、所有时间字段统一字符串格式。之后每个会话开始前，我都会让AI先读这个文件再干活。

这个改动立竿见影。之后生成的代码风格统一度大幅度提升，我review的时候不再为"这到底是不是我们项目的写法"反复纠结。

4.3 上下文窗口瓶颈，项目大了之后AI开始"拆东墙补西墙"

平台上线的功能越来越多之后，我遇到了VibeCoding最本质的瓶颈——AI记不住整个项目的全貌。最典型的一次是我让AI给配置列表加一个"批量导入"功能，它确实加了，但改动了配置项查询接口的返回值结构，导致依赖这个接口的其他页面全部异常。

这个问题的本质是：AI只看到了当前这个文件的上下文，不知道还有别的模块在消费同一个接口。它在一个"局部正确"的情况下做了"全局有害"的修改。

我的应对有三板斧：第一，坚持小步提交，每完成一个功能就立刻提交推远，方便随时回滚；第二，让AI修改公共接口时，必须先列出所有调用方并评估影响，这一步必须人工确认；第三，重大重构坚决不用AI做自动修改，宁可让它给我重构方案，我自己动手改。守住这几条之后，项目的稳定性提升了一个量级。

4.4 AI的"平庸实现"会在数据量上来后变成性能隐患

最后一个坑是隐性的。AI生成的代码非常"平均"，就是它总是选择看起来最常规的写法，不会主动考虑数据规模上来之后的性能问题。配置列表页早期只有几十条数据，AI写的查询直接全表查出所有配置，前端自己分页。用起来没什么感觉，问题是运行了两个月后配置量涨到了几千条，还关联了变更记录和审批记录，页面开始明显卡顿。

后来我把问题描述给AI，要求它"考虑大数据量场景"，它才给出正确的分页方案和索引建议。这段经历让我意识到一个道理：VibeCoding生成的东西是"合格"的，但不自动是"优秀"的。你在提需求的时候，需要主动把非功能需求带上——性能、安全、可维护性、边界情况，这些AI默认不会替你考虑周全。

5. 落地效果与关键指标

5.1 配置变更时效的对比

平台上线第一个月，我拉了数据做了一次对比：

这个差距不是某一个环节的优化，而是整个链路变短了。以前运营修改一个参数要走完"提需求-排期-开发-测试-发版"这条长链路，现在自己在平台上改完，提交审批，审批人手机点一下，配置就推送到线上。这里有一个细节我要强调——路径变短不等于没有管控，审批和审计我们反而做得比以前更严格了。

5.2 研发发版频率和事务性工作占比下降

配置上平台之前，我们几乎每周都至少发一次版，其中一大半只是为了改配置参数。平台上线之后，这类"配置性发版"彻底归零，发版频率降到每两周一次甚至一个月一次，而且每次发版都是真正的代码功能迭代，风险更集中，评审也更认真。

我自己的感受更直接：以前我每天要回一堆"这个改一下明天能上吗"的消息，现在这些消息消失了，因为发版不再卡在研发这里。我能把时间花在真正有价值的业务功能开发上，而不是反复当一个"改数字的人肉工具"。

5.3 业务同学的使用反馈和权限边界

平台上线之后并没有直接把权限完全放开。我的权限设计是分层的：运营可以提交配置修改，但只有配置管理员和研发负责人可以审批发布；涉及订单价格、优惠金额这类敏感配置，必须走双人复核；所有操作都有操作日志，谁在什么时间把什么值改成了什么值，查起来一清二楚。

业务同学的真实反馈也是很好的参考。运营团队最爱的是"所见即所得"——配置表单上直接写了字段说明和合理范围，就算不理解的技术概念，照着提示填也不会出错。最让我意外的是，使用频率最高的并不是我们最初设计的营销配置模块，而是审批流配置和通知规则配置，这些本来是配套功能，结果反倒成了高频使用对象，这是需求阶段完全没预判到的。

6. 如果你想复刻这个项目，我的几点建议

6.1 Prompt要分层，全局约定单独放

不要把"项目背景+代码规范+功能需求+报错修复"全部塞进一个Prompt里，AI很容易顾此失彼。我是这样分层的：

• 全局约定层：放在CLAUDE.md，每次会话开始先加载，包含技术栈、目录结构、代码风格、接口返回格式。
• 功能需求层：每个会话只提一个功能模块，描述清楚输入、处理逻辑、输出、边界条件。
• 修复指令层：单独处理报错和Bug，直接把错误信息、相关代码片段、期望行为喂给AI。

这三层互不干扰，AI的注意力不会被分散。

6.2 让AI先解释，再动手写码

这是我的一个私人心得。当你问AI"怎么实现配置灰度发布"的时候，不要让它直接写代码，而是先让它说清楚方案：用什么机制做到只对部分用户生效？版本号怎么管理？回滚时数据怎么处理？如果它的方案你听完觉得不对劲，就当场纠正，而不是等它写出一堆基于错误方案的代码再来改。

这个习惯能帮你省掉大量返工。很多情况下，AI的理解和你的本意有偏差，但它在"回答方案"的时候就有苗头了，一问就能暴露。

6.3 架构底线必须人守：数据库设计和领域边界别放手

我可以很明确地说：VibeCoding可以做代码实现，但数据库设计和领域边界这两个事情，你绝对不能全权交给AI。为什么？因为AI没有"业务共识"的概念，它不知道你们公司"订单流程"和"售后流程"的关系，不知道哪些字段被其他系统强依赖，不知道"用户ID"在你们体系里是数字还是字符串。这些业务知识藏在你的脑子里，不在AI的训练数据里。

我的做法是：表结构我自己画大概的字段和关系，让AI去写迁移文件；领域模块的边界我在需求里明确指定，哪些逻辑归配置平台、哪些归业务系统，不允许AI跨模块自由发挥。

6.4 建立AI时代的代码审查机制

VibeCoding不意味着放弃代码审查，反而审查更重要。因为你有相当一部分代码不是自己敲的，你并不天然理解每一行的意图。我的审查机制是这样的：每次AI生成的代码合并之前，我会先快速跑一遍关键流程，再找同事做一次交叉review。重点看安全边界（权限校验、输入校验）和异常处理（网络超时、事务回滚）。

这里有个技巧：让AI自己生成一份"本次改动说明"，列出改了哪些文件、每处改动的原因、潜在影响。审查的人不用一行行比对，直接看说明就能快速定位高风险区域。

6.5 想清楚哪些环节该vibe，哪些环节必须较真

最后我想给"VibeCoding"祛个魅。我整个项目最vibe的部分是页面开发、CRUD接口、表单校验这些模式化的工作，它们重复、琐碎、有套路，交给AI效率极高。但我坚决不vibe的地方也很明确：数据库迁移、权限控制、发布审批流、配置下发的一致性协议。这些地方出了问题不是改一行代码的事，而是会出事故甚至线上故障。

这也是为什么我标题里说的是"VibeCoding出一个配置平台"，而不是"让AI完全托管一个配置平台"。VibeCoding正确的打开方式是：把AI当成一个手速极快、但偶尔会口出狂言的资深实习生，你负责把关方向、边界和安全，它负责快速执行。这个分工一旦清楚，AI编程的效率优势才能真正发挥出来。

最后再分享一个我的个人体会。做完这个项目之后，我对配置平台的看法变了很多——它表面上是一个工具，本质上其实是"研发与业务之间的协作协议"。VibeCoding帮我把这个协议快速落了地，但真正的价值，还是那套"谁能改、谁能发、出了问题怎么办"的规则本身。工具会变，规则带来的信任感不会变。