事实求是很多人第一次接触vibe coding，最大的错觉就是——我终于能用大白话让AI写代码了。结果呢？你对AI说"帮我做个用户管理页面"，它给你吐出一大堆看起来特别像那么回事的代码，列表有了、按钮有了、弹窗也有了，但字段对不上业务、按钮点了没反应、布局一缩放就塌。问题出在哪？不在于AI写代码的能力，而在于你喂给AI的需求本身就是一坨模糊的"感觉"。
我做了十几年产品和研发，最近半年高强度用vibe coding方式做项目，最深的体会是：vibe coding的第一步根本不是写提示词，而是把需求结构化。而蓝湖这类设计协作平台，恰恰是需求结构化最现成的抓手。这篇文章就把我实际跑通的"蓝湖需求结构化提取方案"完整拆开讲，从设计稿到AI能直接执行的规格说明，每一步怎么操作、踩了什么坑、怎么绕过去，一次说清楚。
1. vibe coding的低效陷阱：模糊需求被大模型"翻译"成垃圾代码
1.1 为什么"写得像人话"的需求反而最难用
先说个反直觉的结论：你描述得越像日常对话，AI生成的代码越不可控。因为大模型本质是一个概率系统，它收到没有约束的输入时，唯一能做的就是沿着"最可能的路径"生成代码。什么是"最可能的路径"？就是GitHub上出现频率最高的写法。可你的业务偏偏不是那个"最常见的写法"。
举个例子。你给AI说"做一个订单列表，支持筛选"，它大概率会给你生成一个这样的东西：一张表格、几个筛选项、一个分页器。看起来没什么问题，但你仔细看会发现——订单状态筛选项是写死的三个值，没有考虑你们业务里还有"已退款""待补款"这种特殊状态；时间筛选用的是日期框，但产品要求的是快捷区间；表格里的金额没有格式化，连货币符号都没有。你让AI改，它改一步、崩两步，改了金额格式又把对齐搞乱了。
这不是AI蠢，而是你的需求里根本没有这些约束信息。AI在替你补齐所有你没说的东西，而它补的内容可能是基于另一个完全不同的业务场景。
我一直跟团队说一个类比：vibe coding的AI就像一个手艺很好、但完全不了解你生活习惯的装修师傅。你跟他说"装得高级一点"，他装出来的高级可能贴着KTV风格；你给他一张施工图，标清楚每个插座的位置、每面墙的颜色、每个柜子的尺寸，他做出来的东西才可能是你想要的。需求结构化就是那张施工图。
1.2 蓝湖这类设计协作平台在需求链路里的位置
那"施工图"从哪来？很多团队走的是传统流程——产品写PRD、设计师画图、开发照着实现。但现在做vibe coding，我们需要的是"A能直接读取的结构化需求"，这时候蓝湖的角色就变得非常关键。
蓝湖本质上是一个设计协作平台，但它沉淀的东西比"设计稿图片"多得多。一张设计稿在蓝湖里不只是图片，它包含了图层结构、组件属性、标注信息、文本内容、切图资源。这些信息本身就是高度结构化的数据。问题是怎么把它变成AI能理解的上下文？这就需要MCP。
这里顺便说一句，市面上还有MasterGo、即时设计、Figma这些同类平台，Figma也有官方的MCP适配。蓝湖的差异化在于它在国内团队的渗透率极高，而且它本身就和需求、开发、设计协作流程绑定得很深，"蓝湖+需求结构化+AI生成"是一条很顺的链路。你用什么平台不重要，关键是**把设计稿从"给人看的图"变成"给AI读的数据"**这个思路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 蓝湖MCP：让AI直接"读"设计稿的结构化上下文
2.1 MCP机制是怎么工作的
MCP全称是Model Context Protocol，模型上下文协议。你要是觉得这个名字太抽象，换个方式理解：它是给大模型装外接设备的接口标准。
电脑没有USB口，你就没法插键盘鼠标；大模型没有MCP接口，它就没法主动去读你蓝湖里的设计稿。以前我们怎么让AI"看"设计稿？截图丢给它，它靠视觉识别硬猜——颜色能猜个大概，但图层关系、组件状态、精确间距全是靠蒙的。有了MCP之后，AI可以直接调用蓝湖提供的工具方法，按项目名、按页面名、按组件ID把结构化的数据拉回来。它看到的不是一张像素图，而是一份JSON结构：这个按钮的宽高是120x40、圆角是8px、文本是"立即登录"、状态是disabled。
这一步的意义怎么强调都不过分。视觉识别是让AI"看到"画面，MCP是让AI"读到"数据。后者是精确的、可计算的、不会产生歧义的。
2.2 配置蓝湖MCP的关键步骤
具体怎么配置？我以Mac环境上配置通用MCP客户端为例，整体流程来一遍。
第一，先在蓝湖开放平台（如果你用的是私有化部署，一般也有对应的开放接口文档）创建一个应用，拿到访问凭证。这一步相当于给AI办一张"门禁卡"，让它有权限访问你指定的蓝湖项目。
第二，在你使用的AI编程工具里找到MCP配置入口。以Claude Desktop为例，配置文件是claude_desktop_config.json；Cursor的话在Settings里也能找到MCP配置。添加一个蓝湖服务的配置节点，把服务地址和凭证填进去。
json复制{
"mcpServers": {
"lanhu": {
"command": "npx",
"args": ["-y", "@lanhu/mcp-server"],
"env": {
"LANHU_API_TOKEN": "你的访问凭证"
}
}
}
}
第三，重启客户端，新建一个会话，让AI调用工具看看能不能连通。你可以直接问它："读取蓝湖项目'电商后台V2'的项目列表"，如果它返回了正常的页面清单，就说明链路通了。
这里有一个非常容易被忽略的细节——权限范围一定要收敛。不要给你的访问凭证开通全部项目的权限，只授权当前需要开发的那个项目就够了。原因很简单，MCP工具被AI调用时，AI会根据对话内容自主决定读哪个项目，一旦权限过大，它可能读错项目、读到你不想让它看到的内容，而且调试的时候你很难意识到它读错了源头。
2.3 备选平台与差异化选择
国内团队如果没用蓝湖，完全可以用类似思路。Figma官方提供Figma MCP，MasterGo也有对应的开放接口，即时设计同理。你的设计稿在哪个平台，就用哪个平台的MCP适配，结构化的本质是一样的。
但我要说一个选型上的建议：选择MCP能力还不是最关键的，关键是这个平台是否覆盖了"需求-设计-开发"的完整链路。蓝湖在这方面的优势是，它不只是设计稿托管，还有原型图、需求文档模块、交付协同能力。这意味着你从需求结构化的第一步到最后交付给AI的整个过程，可以在一个平台上闭环。Figma虽然设计能力强，但国内团队在"需求-开发"两端的体验还是不太一样。
3. 需求结构化提取：从设计稿到AI可执行规格
配置好MCP只是第一步，真正的核心工作是把蓝湖里的设计稿信息，转译成一份AI可以直接照做的结构化规格说明。这一步做得越细，AI写出来的代码越贴近预期。我把它拆成五层，每一层都是下一层的基础。
3.1 页面拓扑与区块划分
第一层叫"页面拓扑"。什么意思？就是一个项目里有哪几个页面、每个页面是干什么的、页面之间的层级关系是什么。这看起来简单，但很多人恰恰会在这个地方偷懒。
我给你看一个我实际用过的结构化模板开头：
markdown复制## 项目概览
- 项目名称：电商后台管理V2
- 技术栈：React + TypeScript + Ant Design 5
- 布局策略：左侧固定导航 + 右侧内容区自适应，最小宽度1280px
## 页面清单
1. 登录页（/login）
- 用途：管理员账号登录入口
- 包含区块：登录表单、系统公告、备案信息
2. 订单管理（/orders）
- 用途：查看和操作全部订单
- 包含区块：筛选区、数据表格、批量操作栏、分页器
3. 订单详情（/orders/[id]）
- 用途：查看单个订单的完整信息和流转记录
注意上面对布局策略的描写，一定要在技术栈那一行就写清楚。因为蓝湖设计稿是一个固定宽度的视觉稿，AI如果不被告知布局策略，它会默认把页面的像素宽度直接写成死值。你写清楚"最小宽度1280px、左侧导航固定、右侧自适应"，AI才有机会生成真正可用的网页。
页面清单列完之后，紧接着做区块划分。一个页面不要直接让AI开写，先按功能区切开。以订单管理页为例，我会切成：筛选区（订单号输入、状态选择、时间快捷区间、查询/重置按钮）、数据表格（订单号、用户、商品、金额、状态、创建时间、操作）、批量操作栏（批量发货、批量导出）、分页器。每个区块我都标一个优先级：P0表示这个区块是页面的核心，AI必须首先生成并保证功能完整；P1表示次要但必须有；P2表示有更好，没有也不影响主流程。
这个优先级的价值在于，vibe coding的上下文窗口是有限的，你一次塞太多东西进去，AI后面一定会"忘"。有了优先级，你可以引导AI先实现P0，通过验证后再补齐P1和P2，而不是让它胡子眉毛一把抓。
3.2 组件级描述：状态、行为、边界
第二层是组件级描述。这是整个结构化过程中最花时间、也最值钱的一步。
设计稿在蓝湖里其实已经标注了组件的样式信息：宽高、颜色、字号、圆角。但AI光拿到这些还不够，它需要知道你定义的"这个组件在什么情况下长什么样、点了会怎样"。
我在做组件描述时，强制要求每个组件都覆盖一个"三件套"：状态、触发行为、边界条件。举一个真实例子，订单状态标签这个组件：
markdown复制### 订单状态标签
- 所属页面：订单管理页、订单详情页
- 状态枚举：
- 待付款：灰色底(#F5F5F5)、灰色文字(#999999)、文案"待付款"
- 已付款：蓝色底(#E6F4FF)、蓝色文字(#1677FF)、文案"已付款"
- 已发货：橙色底(#FFF7E6)、橙色文字(#FA8C16)、文案"已发货"
- 已完成：绿色底(#F6FFED)、绿色文字(#52C41A)、文案"已完成"
- 已关闭：无底色、灰色描边、灰色文字、文案"已关闭"
- 触发行为：
- 在订单管理页点击"待付款"标签 → 跳转到订单详情页
- 在订单详情页点击标签本身 → 无交互
- 边界条件：
- 当订单同时满足"已付款"和"部分发货"时，显示"部分发货"而不是"已付款"
很多人会觉得，这不就是设计走查清单吗？对，本质上就是一回事。但区别在于，这个清单是给AI看的，所以它必须精确到"无底色、灰色描边"这种程度，而不是写"弱化样式"。AI对形容词的理解极不可靠，对名词和具体参数的理解才可靠。
组件级描述还有一个作用：它天然形成了AI生成时的"样式约束"。你在提示词里写"所有按钮统一使用主色#1677FF、最小触达尺寸44x44"，AI在生成任何模块时都会遵守这个规则，哪怕你后面给它喂的新页面里没有重复提到这个约束。
3.3 业务规则的补充与优先级定义
第三层是业务规则。这一层是蓝湖里的设计稿给不了的，因为设计稿只负责"长什么样"，不负责"怎么运作"。你需要从PRD、后端接口文档或者你自己脑子里把这些规则挖出来，落到对应的组件和页面上。
举一些我在实际项目中写过的规则描述：
markdown复制## 业务规则
1. 订单列表默认只展示最近30天的订单，超过30天需要手动修改时间范围
2. 订单金额 = 商品总额 - 满减优惠 - 优惠券金额 + 运费；满减和优惠券不能同时使用
3. 删除订单按钮仅对"已关闭"状态可见，且点击后需要二次确认弹窗
4. 批量导出的文件上限为1万条，超过时提示"请缩小导出范围"
5. 订单详情页的收货信息，在订单发货后不可编辑
这些规则必须写得很"死"，尽量不要留解释空间。AI不是一个会追问的工程师，你写"订单金额的计算方式比较复杂"，它就真的不知道怎么算；你写清楚公式"商品总额 - 满减优惠 - 优惠券金额 + 运费"，它才能照着实现——哪怕它不理解为什么这样算。
我在做这些规则时还有一个习惯：每条规则都标注它的影响范围。比如"删除订单按钮仅对已关闭状态可见"影响的是"订单管理页的操作列"和"订单详情页的操作区"两个位置。AI在读规则时就能确定，这个约束只作用于特定组件，而不是全局。这是一个避免AI"过度泛化"的关键技巧。
4. 把结构化需求喂给vibe coding的指令实战
结构化的需求文档做出来后，不能直接整篇复制给AI说"开始写吧"，那样它消化不了。要遵循一套喂食的节奏和格式。
4.1 单页面的结构化提示词模板
我自己用下来最稳定的提示词结构是五段式：角色定义、上下文引入、任务说明、硬性约束、验收条件。拿订单管理页来举例：
text复制你是资深前端工程师，使用React + TypeScript + Ant Design 5实现电商后台页面。
项目整体背景：这是一个电商后台管理系统，包含订单、商品、用户、营销等模块。
之前已经完成了登录页和订单详情页，订单详情页的组件风格可以作为参考。
现在需要实现"订单管理页"（/orders），页面结构如下：
[把前面整理的页面清单、区块划分、组件描述粘贴进来]
硬性约束：
1. 组件库使用Ant Design，不允许自行封装复杂组件
2. 订单金额按"分"存储，展示时必须格式化为"元"并保留两位小数
3. 所有按钮的最小点击区域为44x44像素
4. 删除操作必须使用Popconfirm二次确认
验收条件：
1. 页面在1280px宽度下不出现横向滚动条
2. 点击"待付款"标签能跳转到对应订单详情页
3. 筛选条件变化后，重新请求列表数据，并保持页码重置为1
4. 空数据时显示空状态插画，而不是空白表格
这套提示词的逻辑是：它把AI从"猜你需求"切换成了"照单执行"。角色定义约束了它的技术输出风格，上下文引入让它记住这是同一个项目里的页面，硬性约束把最容易出错的地方提前锁死，验收条件让它在生成完后自查。你会发现，AI生成的代码和设计稿的吻合度会高一个数量级。
4.2 渐进式铺开：先骨架后交互再数据
第二件重要的事情是——一次只喂一个页面，甚至一个页面也可以分三次喂。
我第一次用vibe coding做完整项目的时候，贪多，一次性把五个页面的结构化需求全扔给AI。结果到第二页的时候，AI明显开始混乱，第一页定好的色彩规范它忘了，按钮用了另一个圆角值，表格间距也对不上了。后来我改变策略，每个页面分三个阶段推进：
第一阶段只做静态骨架。让AI先按照设计稿把页面布局、区块、组件的位置和样式搭出来，不看交互、不发请求。这个阶段要验证的是"长得像不像"。
第二阶段引入交互。点击跳转、弹窗、表单校验、状态切换。这个阶段要验证的是"能不能动"。
第三阶段接入数据。把假数据换成真实的接口请求，处理loading、空态、错误态。这个阶段要验证的是"通不通"。
每个阶段结束，我会让AI自己对照验收条件检查一遍，然后我人工跑一遍，发现问题后把反馈以"修改意见"的形式追加到对话里，不让它推倒重来。这是一个非常关键的细节——在vibe coding里，反馈式修改比一次生成高效得多，因为AI会在上下文中积累你对项目的偏好，就像带一个新人，你反复纠正几次之后，他自然就懂你的套路了。
5. 实测中的翻车现场与应对策略
再好的方案，实操时都会遇到意外。我把自己在这套流程里踩过的几个比较典型的坑拿出来说，每一个都对应一个可行的应对策略。
5.1 像素级还原与响应式冲突
蓝湖设计稿的标注值是固定的像素，比如内容区宽度1200px、侧边栏宽度240px。AI拿到这些值后，很自然地就会写死布局宽度。结果我放到自己的笔记本上一看还行，放到公司外接显示器上一看，整个人傻掉了——页面内容挤在中间一小条，两侧全是空白，更小的屏幕上直接横向滚动。
后来我在布局策略里加了一句："设计稿的宽度标注仅供参考，所有区块使用flex布局，内容区最大宽度1280px，超出部分居中并自适应。"AI的输出立刻不一样了。
经验总结：蓝湖的标注是"设计意图"，不是"实现参数"。给AI的布局约束一定要写清楚哪些值是固定的、哪些是需要自适应的。如果设计稿本身没有明确说明响应式行为，那你必须在结构化需求里替它定义清楚。
5.2 MCP只拉到了默认态
蓝湖MCP能读到组件信息不假，但设计稿里的组件通常只画了默认状态。一个按钮的hover色、一个弹窗的遮罩、一个表格的loading骨架、一个搜索框在输入时的清除按钮，这些"看不见的状态"在蓝湖里往往是藏在组件库或交互面板里的，MCP拉取的时候不一定都抓得到。
这个问题的直接影响是：AI生成的页面只有静态效果，交互态几乎全靠猜，而且猜的质量不高。我的应对办法是在结构化需求里单独加一个"交互状态清单"，穷举所有组件需要覆盖的状态，把默认态、悬停态、禁用态、加载态、空态、错误态全部列出来。AI有了这个清单，就能主动生成对应的样式和逻辑，而不是等你一个个去提。
交互状态清单长这样：
markdown复制## 交互状态清单
- 按钮组件：default / hover / loading / disabled
- 搜索输入框：default / focus / hover / disabled / 输入后显示清除图标
- 表格：数据为空时显示空插画；加载时显示骨架屏；请求失败时显示重试按钮
- 分页器：当前页高亮；上一页/下一页在边界时禁用
- 弹窗：打开时显示遮罩，点击遮罩或右上角关闭按钮可关闭
有了这个清单，AI需要在每个组件的实现里主动考虑这些状态，输出质量会提升一截。
5.3 "看懂了设计稿但没看懂业务"
这个坑最隐蔽，也最难察觉。AI看了你的设计稿，把页面写出来了，但很多时候它只是把"视觉元素"翻译成了代码，根本没有把"业务语义"理解进去。
举个例子，我们做订单详情页时，设计稿上有一个"再次购买"按钮。AI生成的代码没有任何问题——按钮位置正确、样式正确、点击也能触发。但它没有发现，这个"再次购买"必须是登录状态下才能点击的按钮，而且它应该基于"当前登录用户"的支付方式生成一个新订单，而不是复制原订单的支付方式。代码是"对"的，业务是"错"的。
这正是我在第三章强调"业务规则必须显式写出来"的原因。AI无法从视觉稿中反推出业务逻辑，它只能执行你写出来的规则。所以我在结构化需求模板里专门留了一个"业务规则"区，每条规则都会配上影响组件和触发条件。你希望AI遵守什么，就一定要白纸黑字写下来，绝不能指望AI自己悟出来。
6. 结构化需求的长线价值：从单页到跨端复用的扩展
写到这里，你可能觉得这套流程最多就是解决"如何让AI更好地实现一个页面"的问题。但我在实际使用中的体会是，它带来的复利效应远不止于此。
6.1 建立可复用的需求资产库
当你的项目里有五六个页面的结构化需求文档后，你会发现它们之间有很多可复用的部分。比如所有后台页面的"全局导航""页面头部""批量操作栏"这些区块描述其实是通用的；"订单金额"的计算规则、"删除操作的二次确认"这些业务约束也可以在多个页面里复用。
我的做法是把这个目录直接放在项目仓库里，和代码一起管理：
text复制docs/
├── 00-global-rules.md # 全局布局、色彩、组件规范、通用业务规则
├── 01-login-page.md # 登录页结构化需求
├── 02-order-list.md # 订单管理页结构化需求
├── 03-order-detail.md # 订单详情页结构化需求
└── 04-product-list.md # 商品管理页结构化需求
每次新会话开始前，我会先让AI读00-global-rules.md，再让它读当前页面的结构化需求，然后再开始写代码。这个"先读规范再干活"的动作，极大减少了AI在不同页面间生成风格不一致的问题，也省去了反复粘贴大量上下文的麻烦。
6.2 与团队协作流程的衔接
结构化需求文档还有一个意外收获——它成了团队里轻量级的"需求说明书"。产品经理可以review业务规则是否准确，设计师可以review组件描述是否和设计规范一致，测试可以照着一个一个写用例。vibe coding不是把开发和需求流程干掉，而是把所有人都拉进一个更精确的协作语境里。
我还把这套结构化需求用于跨端复用的场景。之前为Web端写的订单管理页结构化需求，后来在做一个轻量级的App管理端时，我几乎原封不动复用了其中区块划分、组件状态、业务规则的描述，只是在技术栈和组件库上做了替换。AI基于同一份结构化需求，在不同技术栈下生成了风格统一、逻辑一致的两端实现，这个体验很直观地说明了结构化需求的通用价值——它不绑定某一种技术实现，它绑定的是"这件事到底是什么"。
最后再分享一个我个人的使用心得。vibe coding这个玩法，本质上没有改变"好代码需要好需求"这个底层规律，它只是大幅缩短了从需求到代码的路径。过去一个需求要经过PRD评审、UI设计、技术评审、开发实现好几道工序，现在压力全部集中在"你能不能把需求说清楚"这一个环节上。蓝湖MCP和结构化提取方案解决的就是这个环节。如果你能把这一步做扎实，vibe coding对你来说就不是一个玩票工具，而是一个真正能交付生产级代码的工作方式。