如何利用大模型来生成一个完整的系统原型页面

weixin_44832514

503人浏览 · 2026-04-14 21:15:07

weixin_44832514 · 2026-04-14 21:15:07 发布

1. 核心架构与角色定义

本流程采用**“人类项目经理 + 三模型虚拟团队”**的协作模式。每个模型被赋予特定的人格（Persona）和职责，通过明确的输入输出协议进行协作。

2. 阶段一：深度业务逻辑构建与验证 (Deep Logic Engineering)

目标：在写第一行代码前，消除所有逻辑歧义，构建“无幻觉”的业务真理库。

Step 1: 宏观梳理与流程可视化

操作：将基础需求文档投喂给 Model A。
指令要点：
- “请先忽略技术实现，从业务宏观视角梳理系统核心价值。”
- “识别关键业务实体（Entity）和它们之间的关系。”
- “输出完整的业务流程泳道图（使用 Mermaid 语法），明确标注每个节点的输入、输出及异常分支。”
产出：01_宏观思路与泳道图.md

Step 2: 功能架构与菜单树规划

操作：基于泳道图，引导 Model A 进行功能拆解。
指令要点：
- “根据业务流程，推导系统必须具备的功能板块。请进行‘减法’（删除冗余）和‘加法’（补充遗漏，如审计日志、数据字典管理）。”
- “设计详细的系统菜单树（一级/二级/三级），并定义每个菜单项的核心功能范围（Scope）。”
产出：02_功能架构图与菜单树.md

Step 3: 状态机与权限矩阵设计 (核心难点)

操作：这是系统最复杂的部分，需多轮对话。
指令要点：
- 角色定义：列出所有系统角色（如：省分安全员、总部审核员、系统管理员）。
- 状态机：定义核心单据（如“事件报告”）的所有状态（草稿、已提交、复核中、驳回、已归档等），并绘制状态流转图。
- 矩阵构建：
  - 生成 角色 - 权限 - 状态对应矩阵（谁在什么状态下能做什么操作？）。
  - 生成 菜单 - 权限对应矩阵（谁能看到哪个菜单？）。
产出：03_状态机逻辑与权限矩阵.xlsx (或 Markdown 表格)

Step 4: 全链路逻辑“红队测试” (Red Teaming)

创新步骤：新建一个临时对话窗口（或利用 Model A 的自我反思能力）。
操作：将上述所有文档汇总，要求模型扮演“挑剔的审计员”。
指令模板：
“你是一名严苛的系统审计专家。请基于以下业务规则，对系统进行‘红队测试’：
1. 流程闭环性：是否存在死胡同状态？（如：一旦驳回无法重新提交）
2. 权限边界：是否存在越权操作的可能？（如：普通用户能直接归档）
3. 关键控制点：国家回执ID绑定、MD5校验、时间戳锁定等逻辑是否缺失？
4. 异常场景：网络中断、并发提交时的处理逻辑是否定义？
  输出要求：先概括整体理解，再逐条指出逻辑漏洞，最后给出修正建议。”
动作：根据测试结果，修正 01-03 文档，直到模型确认“逻辑无矛盾”。
最终产出：📜 系统业务逻辑白皮书 (Final_Version).md —— 这是后续开发的“宪法” 。

3. 阶段二：多模型环境初始化与知识注入 (Context Injection)

目标：建立三个独立窗口，确保上下文不丢失，风格不漂移。

Step 5: 建立协同工作区

打开三个独立的浏览器标签页/窗口，分别命名为 A-Architect, B-Developer, C-Designer。

Step 6: 知识注入 (Knowledge Seeding)

注入 B (开发者) ：
- 内容：发送 📜 系统业务逻辑白皮书。
- 指令：“请深入学习以上材料。你不需要现在写代码。你的任务是建立系统心智模型。请回复：‘我已理解系统全貌，包括 [列举3个关键流程]、[列举5个核心角色] 及 [状态机逻辑]。我将以此作为后续开发的唯一真理来源。’”
注入 C (设计师) ：
- 内容：上传一张你喜欢的竞品系统截图（或描述设计风格，如“Ant Design Pro 红色系变体”）。
- 指令：“请分析该图的视觉风格。输出一份详细的**《UI 设计规范》**，包含：
  - 色彩体系：主色、辅色、警告色、背景色（提供 Hex 码）。
  - 布局规范：栅格系统、间距规则（8px倍数）、T型/L型布局定义。
  - 组件样式：按钮、表单、表格、卡片的圆角、阴影、边框细节。
  - 字体排版：字号层级、行高、字重。”
- 产出：🎨 UI 设计规范.md
同步规范至 B：
- 动作：将 🎨 UI 设计规范.md 发送给 Model A。
- A 的任务：将其转化为一段“风格约束提示词（Style Constraint Prompt）”。
- B 的执行：接收该提示词，并回复：“我已锁定 UI 规范，后续所有代码将严格遵循此风格，保持像素级一致。”

4. 阶段三：原型开发规划 (Strategic Planning)

目标：制定施工图纸，避免“边写边想”导致的代码混乱。

Step 7: 生成开发路线图

输入给 A：业务白皮书 + UI 规范 + 技术栈要求（原生 HTML/CSS/JS, FontAwesome, 无构建工具）。
A 的任务：生成一份**《分模块开发计划》**。
- 要求将系统拆分为 7-10 个原子模块（例如：1.全局骨架 -> 2.登录/鉴权 -> 3.列表页 -> 4.复杂表单 -> 5.详情只读页 -> 6.审批交互 -> 7.统计看板）。
- 定义每个模块的依赖关系（必须先做哪个，后做哪个）。
B 的执行：接收计划，仅确认并复述计划，严禁生成任何代码。
- 指令：“请确认你已理解开发计划。只需回复‘计划确认’并列出模块顺序，不要写代码。”
产出：📅 原型开发执行计划书.md

5. 阶段四：迭代式原型构建 (Iterative Coding Loop)

目标：通过“原子化修改”和“版本控制”，像搭积木一样构建系统，确保零回归错误。

Step 8: 全局框架搭建 (Base Version v1.0)

A 生成提示词：
- 详细描述 T 型布局、Header 高度、Sidebar 宽度、颜色变量定义。
- 关键点：要求生成一个“空壳”，包含导航菜单（静态）和面包屑占位符。
B 生成代码：输出 index_v1.0.html。
人工验收：
- 打开文件，检查布局、颜色、字体是否符合 UI 规范。
- 若不满意：告诉 A 哪里不对（如“侧边栏太宽”），让 A 修改提示词，B 重新生成 index_v1.0_fix.html。
- 若满意：锁定此文件为基线（Baseline） 。

Step 9: 模块化增量开发 (The Loop)

对计划中的每一个模块（假设现在是“事件列表页”），执行以下严格循环：

9.1 准备上下文

选取基线文件：找到上一个稳定版本（如 index_v1.0.html）。
明确需求：本次要实现“事件列表筛选”和“数据表格展示”。

9.2 A 生成精准提示词 (Prompt Engineering)

A 的指令结构：

# 任务目标
基于文件 [index_v1.0.html]，在主工作区实现“事件列表”模块。

# 业务逻辑约束
- 表格字段：事件ID、标题、当前状态、上报人、时间。
- 筛选条件：按状态、按时间范围。
- 交互：点击“详情”跳转（暂用 alert 模拟）。

# ⚠️ 绝对约束 (Critical Constraints - 最高优先级)
1. **禁止破坏**：严禁修改 Header、Sidebar 的任何 CSS 类名、颜色、布局结构。
2. **样式一致性**：新表格的边框、行高、字体必须完全复用原文件中定义的 CSS 变量。
3. **代码完整性**：输出必须是**完整的、可独立运行的 HTML 文件**，包含所有 CSS 和 JS。
4. **文件命名**：请将新文件命名为 `list_v1.0.html`。

# 输出要求
- 只修改 Main Workspace 区域的内容。
- 确保 JS 逻辑不影响原有的导航栏交互。

9.3 B 生成代码

输入：index_v1.0.html 的完整代码 + A 生成的提示词。
输出：list_v1.0.html。

9.4 版本存档与验收

强制规则：
- 绝不覆盖：永远保存为新文件（v1.0, v1.1, v2.0）。
- 独立运行：每个生成的文件都应该是自包含的（Self-contained），方便单独测试。
人工验收：
- 打开 list_v1.0.html。
- 检查：列表功能是否正常？原来的导航栏坏了吗？ （这是最容易出的问题）。
- 如果导航栏坏了 -> 判定失败 -> 反馈给 A：“导航栏样式丢失，请在提示词中加强‘禁止修改 Sidebar’的约束”，重新生成。

Step 10: 复杂交互与状态联动

当涉及到“点击提交 -> 状态变更 -> 按钮变灰”等复杂 JS 逻辑时：
- 策略：让 A 先生成一段伪代码逻辑供你确认。
- 指令：“请先不要写代码，用文字描述你将如何用 Vanilla JS 实现‘提交后按钮禁用且显示 Loading 状态’的逻辑。”
- 确认逻辑无误后，再让 A 生成正式提示词给 B 编码。
文件管理：如果页面逻辑过于复杂，建议按功能拆分文件（如 form_create.html, form_edit.html），通过超链接串联，降低单个文件的复杂度。

6. 关键成功要素与避坑指南 (Best Practices)

✅ 核心原则

单一事实来源 (Single Source of Truth) ：系统业务逻辑白皮书 是最高准则。如果 B 生成的代码逻辑与白皮书冲突，以白皮书为准，立即纠正。
原子化迭代 (Atomic Iteration) ：每次只做一个小功能（如“加一个按钮”、“改一个表格列”）。步子迈大了，模型容易顾此失彼。
防御性提示词 (Defensive Prompting) ：在每次提示词中，必须显式包含“⚠️ 绝对约束”章节，明确列出禁止修改的区域。
版本快照 (Version Snapshotting) ：把每次生成的 HTML 文件当作 Git 的一个 Commit。文件名格式：模块名_功能描述_v版本号.html（例：report_form_initial_v1.2.html）。

❌ 常见陷阱与对策

陷阱现象	原因分析	解决方案
导航栏突然变了	模型在重写 CSS 时覆盖了全局样式。	在提示词中强制要求：“使用`<style>`标签内的局部类名，严禁修改`body`,`.header`,`.sidebar`等全局选择器。”
逻辑前后矛盾	模型忘记了之前的状态机定义。	每次对话都附带`系统业务逻辑白皮书`的相关片段，或让 B 在生成代码前先复述一遍当前状态逻辑。
代码截断	文件太长，模型输出不完整。	要求模型：“如果代码过长，请分段输出，并告诉我‘待续’，我会让你继续。”或者拆分文件。
样式污染	新组件的样式影响了旧组件。	强制使用 BEM 命名规范或独特的类名前缀（如`.report-form-btn`而不是`.btn`）。

7. 附录：提示词模板库 (Prompt Library)

模板 A：架构师生成提示词 (给 Model A)

你是一名资深提示词工程师。请根据以下信息，为前端开发模型 (Model B) 编写一段精准的指令：
- **当前基线文件**：[文件名]
- **新增功能**：[功能描述]
- **业务规则**：[相关规则片段]
- **UI 规范**：[相关规范片段]

**特别要求**：
1. 指令必须包含“⚠️ 绝对约束”部分，明确列出禁止修改的区域。
2. 指令必须要求输出完整的、可运行的 HTML 文件。
3. 指令必须指定新的文件名。

模板 B：开发者执行指令 (由 A 生成，发给 Model B)

# 任务：实现 [功能名称]
# 基线代码：见上文粘贴的代码块

## 业务逻辑
[详细逻辑描述]

## ⚠️ 绝对约束 (最高优先级)
1. **严禁修改**：[列出具体禁止修改的类名或区域，如 .sidebar, .header]。
2. **像素级一致**：新组件的样式必须与现有设计系统完全匹配。
3. **完整性**：输出必须是完整的 HTML 文件，不要省略任何部分。

## 输出
请直接输出代码，文件名为：[新文件名]