ARTICLE · 1223614
为什么 AI 做前端页面,越做越乱?附完整工作流提示词
现在用 GPT、Claude、Codex 做前端，写出一个页面已经不难。
真正难的是项目越做越大之后，AI 容易出现：改一个地方顺手改三个、不同页面风格逐渐跑偏、参考图被当成功能需求，最后甚至说不清哪个版本才是最终版本。
问题很多时候不是 AI 不会写，而是没有明确的施工规则。
所以，我把整个过程整理成一套简单的方法：
先确认 → 定规则 → 做母版 → 控制修改 → 小批量传播 → 验收。
◇ ◆ ◇
01
PART
一、先把“做什么”说清楚
很多人一开始就把参考图丢给 AI：“按照这个样式，帮我做一个页面。”
但这里最容易出现一个问题：
参考图是视觉参考，不是业务需求。
它可以参考页面风格、信息密度、卡片、按钮、图标和留白，但不能直接决定：
页面有什么功能 谁可以使用 用户能做什么 有哪些业务状态 哪些功能需要权限
所以第一步不是写页面，而是先整理业务页面清单。
把页面、角色、功能、权限、状态、导航和主要操作先确定下来。
不确定的地方就标记为待确认，不要让 AI 自己补。
记住一句话：
“
业务决定做什么，参考图决定长什么样。
◇ ◆ ◇
02
PART
二、不要一上来做完整个项目
如果一个项目有几十个页面，直接让 AI 全部按照参考图开发，结果往往是：
每个页面都做了一遍“重新设计”。
最后按钮、字体、卡片、间距甚至顶部区域都会慢慢出现差异。
更稳妥的方法是：
“
先做少量代表页面。
比如选择一个数据总览页、一个列表页、一个详情页、一个表单页。
先把整体视觉方向确定下来，负责人确认后，再继续往后做。
这样可以避免错误的视觉规则一次性传播到整个项目。
◇ ◆ ◇
03
PART
三、把“好看”变成统一规则
确定了视觉方向，还不能只告诉 AI：“后面都按照这个风格。”
因为图片只能告诉它最终长什么样，却不能完整说明背后的规则。
所以要把确认后的视觉进一步整理成统一规则，包括：
信息层级 页面布局 颜色 字体 图标 按钮 公共组件
这样做的目的只有一个：
“
让不同页面使用同一套规则，而不是每个页面自己发挥。
以后需要调整时，也只需要修改对应的规则，而不是几十个页面分别修改。
◇ ◆ ◇
04
PART
四、先做“页面母版”，再批量施工
这是整个方法里最关键的一步。
例如项目里有很多列表页面，不要让 AI 每次重新设计。
先做好一个：
“
列表母版
然后：
“
商品列表 = 列表母版 + 商品业务
订单列表 = 列表母版 + 订单业务
用户列表 = 列表母版 + 用户业务
同样可以建立数据总览、详情、表单、审批、管理等不同类型的页面母版。
结构统一，业务内容不同。
如果确实存在业务结构差异，再单独建立对应变体，而不是每个页面重新设计一套。
◇ ◆ ◇
05
PART
五、每次修改，都要告诉 AI“能改什么”
AI 开发最容易出现的问题就是：
“
“我明明只让它改按钮，为什么连字体、图标和布局也一起改了？”
因为你只告诉了它：“改按钮”
却没有告诉它：
其他地方不能动。
所以每次施工都应该明确：
允许修改什么。
禁止修改什么。
例如这一次只调整按钮，那么字体、图标、页面布局、卡片、业务逻辑和权限都应该明确列入禁止修改范围。
这样 AI 才能真正做到：
“
只改这一项，不顺手优化其他地方。
◇ ◆ ◇
06
PART
六、一次任务，原则上只改一个视觉系统
在这个基础上，再增加一个简单原则：
“
一次施工，原则上只修改一个视觉系统。
比如本轮只改按钮，就不要同时修改字体、图标、颜色和页面间距。
这样出了问题以后，更容易知道到底是哪一次修改造成的。
如果确实需要同时调整多个系统，就先说明原因、影响范围和最小修改范围，再继续施工。
◇ ◆ ◇
07
PART
七、可点击，不代表都是按钮
还有一个很容易被忽略的问题：
可点击，不等于按钮。
页面里可能同时存在按钮、文字链接、列表操作、关闭图标、错误重试区域、导航和输入框。
它们虽然都可以点击，但交互语义完全不同。
例如“加载失败，点击重试”，可能是整个区域都可以点击。
如果为了统一样式，强行把它改成一个小按钮，就可能改变原来的点击范围和交互方式。
所以在统一按钮之前，要先判断：
“
它到底是不是标准按钮。
否则最后可能出现：
视觉统一了，交互却被破坏。
◇ ◆ ◇
08
PART
八、不要让 AI 一次修改全部页面
当规则和页面母版确定后，也不要马上让 AI 把所有页面全部改掉。
更合理的方式是：
先代表页 → 再小批量 → 最后扩大范围。
先选择不同业务模块、不同数据量、不同状态的页面进行验证。
如果发现问题，优先修改源规则或母版，再继续传播。
而不是每个页面单独打补丁。
这样才能真正做到：
“
一套规则，多处复用。
◇ ◆ ◇
09
PART
九、AI 说“完成”，不等于真的完成
最后一步是验收。
不能只看一张“正常页面”的截图。
至少要检查四件事：
① 不同尺寸
检查有没有：
横向溢出 文本截断 卡片挤压 图文碰撞 顶部遮挡 安全区域问题
② 不同状态
根据项目实际情况检查：
默认 加载 空状态 错误 禁用 长文本 大数据量 无数据 权限受限
如果项目还有审批、借出、归还、失败、重试等特殊状态，也要一起验证。
③ 技术验证
确认代码、运行、构建、组件、交互以及统一规则是否正常。
④ 真人确认
最后由负责人实际查看当前版本，确认视觉效果是否真正符合要求。
所以：
“
技术验证通过，不等于负责人视觉验收通过。
只有两者都完成，才算真正完成。
◇ ◆ ◇
10
PART
十、把整个流程压缩成 6 步
如果不想记住这么多内容，其实可以把整个方法记成：
① 先确认做什么
业务决定功能，参考图只决定视觉。
② 再确定长什么样
先做少量代表页面，不要一开始批量设计。
③ 把视觉变成规则
建立统一的信息层级、页面布局、颜色、图标、按钮和组件规则。
④ 先做页面母版
同类页面按照母版传播，而不是每页重新设计。
⑤ 明确施工边界
每次告诉 AI：什么能改，什么不能改。一次任务原则上只修改一个视觉系统。
⑥ 最后再验收
小批量传播 → 多尺寸 → 全状态 → 技术验证 → 真人视觉确认。
最终形成：
“
视觉不漂移 + 工程不漂移。
◇ ◆ ◇
11
PART
接下来，直接把这套方法变成可以执行的提示词
下面这 6 组提示词，可以按照项目实际阶段逐步交给 AI。
“
不要一次把 6 组提示词全部发给 AI。按照项目当前阶段逐步执行。
AI 如果发现前置条件不满足，应先停止当前步骤并说明原因，不要自行补条件。
◇ ◆ ◇
12
PART
提示词 1｜先梳理业务，不要急着写页面
text
你现在负责协助我进行一个前端项目的业务与工程梳理。
本阶段只做分析，不写代码，不设计页面，不根据参考图自行增加功能。
请先整理项目的前端页面结构。
每个页面至少输出：
1. 页面名称
2. 页面类型
3. 使用角色
4. 页面主要目的
5. 必须展示的信息
6. 主要操作
7. 次要操作
8. 权限要求
9. 业务状态
10. 页面之间的导航关系
11. 搜索、筛选、分页、提交、重试等交互状态
页面类型可以根据实际项目归类，例如：
Dashboard、List、Detail、Form、Approval、Management 等。
同时检查：
- 页面入口
- 返回关系
- 详情跳转
- 弹窗或面板
- Loading
- Empty
- Error
- Disabled
- 权限受限状态
如果需求中存在没有确定的功能、字段、操作或业务规则，请明确标记为“待确认”。
禁止：
- 根据参考图自行增加业务功能
- 根据常见后台系统经验补充需求
- 自行修改业务流程
- 自行确定我没有确认的权限规则
- 直接进入代码施工
核心原则：
业务真源决定页面功能、信息、动作、权限和状态。
参考图即使包含搜索框、Tab、卡片、按钮或其他控件，也只能作为后续视觉参考，不能直接视为业务需求。
完成后先输出：
① 页面清单
② 页面类型
③ 待确认项
④ 当前无法确定的内容
等待我确认后再进入下一阶段。
◇ ◆ ◇
13
PART
提示词 2｜先确定视觉方向，不要一次做完整项目
text
现在进入前端视觉方向确认阶段。
本阶段的目标不是一次完成全部页面，而是根据已经确认的业务页面结构，选择少量代表页面建立视觉方向。
请先确定：
1. 项目的整体视觉气质
2. 信息密度
3. 页面留白
4. Header 表现
5. 卡片组织方式
6. 页面区域层级
7. 字体层级
8. 图标风格
9. 按钮突出程度
10. 主次操作关系
11. 目标平台下的视觉约束
参考图片只用于提取视觉特征。
必须区分：
【采用的视觉特征】
【不采用的视觉特征】
【仍需确认的视觉特征】
不要根据参考图增加业务功能。
不要因为参考图存在某个功能入口，就默认我的项目也需要这个功能。
请选择少量具有代表性的真实业务页面进行视觉方案设计。
优先覆盖不同页面类型，例如：
- Dashboard
- List
- Detail
- Form
- Approval
- Management
不要求全部类型都建立，只选择项目实际需要的类型。
设计方案必须使用真实业务结构，而不是虚构内容。
完成后输出：
1. 视觉方向
2. 代表页面
3. 设计依据
4. 待确认项
5. 尚未冻结的内容
在我确认整体视觉方向之前，不要批量设计全部页面，也不要批量修改工程代码。
◇ ◆ ◇
14
PART
提示词 3｜把确认后的视觉变成统一规则
text
现在进入 Design Foundation 建立阶段。
请根据已经确认的视觉方向和代表页面，把视觉设计转换成可以长期执行的统一规则。
本阶段重点建立：
1. Information Hierarchy
2. Typography
3. Layout
4. Color
5. Icon
6. Button
7. Component
8. Asset 使用规则
请优先建立语义规则，而不是让每个页面自己决定具体数值。
需要明确：
【Information Hierarchy】
- 页面核心信息
- 区域标题
- 业务正文
- 辅助信息
- 弱提示
【Typography】
- 字体层级
- 字号
- 字重
- 行高
- 文字颜色角色
- 使用场景
【Layout】
- 页面左右间距
- Header 与内容距离
- Section 间距
- Card 间距
- Card 内部 Padding
- Row 间距
- 图标与文字间距
- Safe Area
- 小屏处理方式
【Color】
- Primary
- Danger
- Success
- Warning
- Neutral
- Background
- Surface
- Border
- Text Primary
- Text Secondary
- Text Disabled
【Icon】
- 图标来源
- 业务语义
- 图标尺寸层级
- 未知业务分类的回退规则
【Button】
- Primary / Danger / Neutral
- Small / Medium / Large
- Default / Pressed / Loading / Disabled
- Height
- Radius
- Padding
- Width Model
- Icon 槽位
【Component】
根据实际项目建立需要的公共组件和业务组件。
注意：
1. 相同语义必须尽量消费相同规则。
2. 页面不能自行建立第二套视觉规则。
3. 不要因为某个页面需要特殊布局，就直接修改全局规则。
4. 如果发现需要新增语义，请先说明原因和影响。
5. 不要为了视觉统一改变已经确认的业务行为、权限或交互。
6. 所有正式规则必须有明确的正式入口。
7. 示例数值不能自动变成正式规则。
完成后输出：
① Foundation 规则
② Token / Registry / Component 等正式入口
③ 页面消费方式
④ 待确认规则
⑤ 可能受到影响的页面或组件
未经确认，不要自行扩大规则范围。
◇ ◆ ◇
15
PART
提示词 4｜先建立页面母版，再复制到同类页面
text
现在进入 Page Master 建立阶段。
不要直接批量修改所有页面。
请根据已经确认的视觉规则，选择真实代表页面建立可运行的页面母版。
根据项目实际情况建立需要的母版，例如：
- Dashboard Master
- List Master
- Detail Master
- Form Master
- Approval Master
- Management Master
每个母版需要明确：
1. Header
2. 页面区域组织
3. 信息层级
4. 卡片结构
5. 页面间距
6. 字体
7. 图标
8. 按钮
9. 操作区
10. Loading
11. Empty
12. Error
13. Disabled
14. 小尺寸布局
母版必须基于真实业务页面实现。
请严格区分：
【固定结构】
例如：
Header、区域组织、卡片语言、间距、字体、图标、按钮、操作区。
【允许替换】
例如：
业务字段、数据、权限、业务状态。
不要因为不同页面的数据不同，就重新设计页面结构。
如果同类型页面存在明显结构差异：
1. 先判断是否属于业务真实差异。
2. 如果确实需要差异，提出 Variant。
3. 不要每个页面重新设计一套。
母版完成后先进行技术、多尺寸和状态验证。
只有验证通过并获得负责人视觉确认后，才能作为正式 Page Master 使用。
未经确认，不得批量传播。
◇ ◆ ◇
16
PART
提示词 5｜明确本次允许改什么，禁止改什么
text
现在进入正式施工阶段。
本轮施工必须严格执行 ALLOWED / FORBIDDEN。
【TASK】
本轮任务：
[填写本次具体任务]
【TASK_SYSTEM】
[例如：Button / Icon / Typography / Layout / Color / Component]
【ALLOWED】
本轮允许修改：
[填写允许修改的具体内容]
【FORBIDDEN】
本轮禁止修改：
[填写禁止修改的具体内容]
除上述 ALLOWED 范围外，不得主动扩大施工范围。
特别禁止：
1. 顺手修改其他视觉系统
2. 顺手重构代码
3. 顺手升级依赖
4. 顺手修改目录结构
5. 修改业务逻辑
6. 修改权限
7. 修改接口
8. 修改数据结构
9. 修改未授权组件
10. 修改已经冻结的设计规则
例如本轮如果是 Button：
ALLOWED：
- 高度
- 圆角
- Padding
- 边框
- 背景
- 已批准的按钮状态视觉
FORBIDDEN：
- 字体
- Icon Size
- 页面布局
- 卡片
- 页面间距
- 业务逻辑
- 权限
- 接口
- 数据结构
- 将 SPECIAL CONTROL 改造成 STANDARD BUTTON
如果发现任务必须修改其他系统才能完成：
立即停止该部分施工。
先输出：
1. 为什么必须修改其他系统
2. 需要修改什么
3. 会影响哪些消费者
4. 最小修改范围
5. 验证方案
等待授权后再继续。
本轮施工原则：
一次任务原则上只修改一个视觉系统。
不要用“更美观”“更现代”“顺便统一”等理由扩大施工范围。
◇ ◆ ◇
17
PART
提示词 6｜施工完成后，不要只说“完成”，必须验收
text
现在进入本轮施工验收阶段。
不要只回复“已完成”或“全部正常”。
请根据本轮实际修改范围进行受控验证，并返回可定位的证据。
至少检查：
【一、视觉一致性】
检查：
- Typography
- Layout
- Color
- Icon
- Button
- Component
- 页面结构
确认是否符合正式规则。
【二、多尺寸】
至少验证：
- 一个正常尺寸
- 一个较小尺寸
根据目标平台补充必要尺寸。
检查：
- 横向溢出
- 文本截断
- 图文碰撞
- 卡片挤压
- Header
- Bottom Navigation
- Safe Area
- 弹窗
- 表单
- 悬浮层
- 滚动区域
不能只通过缩放一张截图判断多尺寸通过。
【三、状态】
根据项目实际业务验证适用状态：
- Default
- Loading
- Empty
- Error
- Disabled
- Long Text
- Large Data
- No Data
- Permission Restricted
如果存在业务特殊状态，也必须验证。
不适用状态标记 N/A，并说明原因。
【四、交互】
核实：
- 点击事件
- 显示条件
- Disabled 条件
- Loading 条件
- 点击热区
- 事件传播
- 重试
- 重复提交
- 权限限制
不要只检查视觉截图。
【五、施工范围】
重点检查本轮是否发生越界修改。
对照：
ALLOWED
vs
实际修改
FORBIDDEN
vs
实际变化
如果发现：
- 字体被修改
- 图标被修改
- 页面布局被修改
- 卡片被修改
- 业务逻辑被修改
- 权限被修改
- 未授权组件被修改
必须明确报告。
不能因为最终页面看起来更漂亮，就忽略越界修改。
【六、工程验证】
检查：
- 项目能否正常运行
- 构建是否正常
- 资源是否正常
- 正式 Token 是否正确消费
- Registry 是否正确消费
- Component 是否正确使用
- 是否产生并行视觉体系
最后输出：
1. 本轮修改范围
2. 实际修改文件
3. 实际修改系统
4. 验证页面
5. 验证尺寸
6. 验证状态
7. 技术检查结果
8. 越界检查结果
9. 新增问题
10. 未验证项目
11. 当前版本
12. 当前状态
不要把：
“代码完成”
直接写成：
“技术验证通过”。
也不要把：
“技术验证通过”
直接写成：
“负责人视觉验收通过”。
两种状态必须分别记录。
◇ ◆ ◇
18
PART
最后：让 AI “施工”，而不是“自由发挥”
AI 越来越会写代码，但一个长期项目真正需要的，并不是让它每次都重新设计。
而是让它知道：
做什么、怎么做、哪些能改、哪些不能改，以及什么时候算完成。
这套方法本质上就是把 AI 从：
“自由发挥的开发者”
变成：
“按照规则施工的开发助手”。
如果你也经常遇到 AI 开发项目越改越乱的问题，上面这 6 组提示词可以直接拿去使用。
不用一次全部发送，按照项目实际阶段逐步执行即可。
关注我或者私信我，获得更多AI实用干货~
