01 / 从真实资源开始
原模板与适用场景
适合设计和开发团队讨论原型交付。原模板带有模型驱动开发的术语，包括SUI、MDWE和代码生成，属于一种示例表达。常规团队可根据真实工作简化，不能据此宣称良功绘图会把原型自动生成完整网站。
在这份模板里，你能找到
- 原型构建
- 原型文件
- 功能规格说明
- 演示沙箱环境
上述节点来自原模板。下面的改图步骤包含新增建议；预览图不会自动同步这些修改。
02 / 具体案例
用一个具体案例理解这张图
案例：团队制作预约服务网站原型。首页、服务列表和预约确认页已能点击跳转，但没有真实排期数据。交付图应把“演示跳转”和“需要开发的数据规则”分开，并在说明中列出待确认项，避免客户将演示误认为已上线功能。
本例用于说明改图思路，不是客户业绩或实测结果。
03 / 动手改图
按照这四步整理你的版本
先确认页面与任务范围
写出用户要完成的一个任务，以及必需的页面。原型结构应围绕任务展开，不按已有组件数量堆页面。
分开结构和设计规范
页面结构说明页面与入口，设计规范说明文字、颜色和组件使用方式。将两者分别交付，减少改版时只改视觉却忘记导航的情况。
检查交互与真实功能边界
把可演示的跳转、状态反馈与依赖后端的数据规则区分。表单提交、登录或支付等演示动作应注明是否真实实现，不以界面外观判断完成度。
形成反馈与版本回路
演示后记录问题并返回对应页面或说明文档。交付时标明当前版本、未完成项和需要开发确认的部分，再决定是否进入正式实现。
04 / 对照检查
节点与分支应该怎样表达
| 项目 | 表达方式 | 核对重点 |
|---|---|---|
| 页面结构 | 页面、入口与任务顺序 | 确认是否覆盖目标任务 |
| 设计规范 | 组件、文字与视觉规则 | 保持跨页面一致 |
| 原型文件 | 演示状态与交互 | 标明模拟和真实功能边界 |
| 交付说明 | 版本、反馈和待确认项 | 开发不应靠猜测补业务规则 |
05 / 让 AI 帮你起稿
可以直接复制的 AI 绘图提示词
先复制下方文字，再打开 AI 绘图入口粘贴；把角色、条件和节点替换为你的实际情况。这段示例不会自动导入模板。
画网站原型交付流程图，场景是预约服务网站。步骤：确认用户任务→梳理首页、服务列表、预约确认页→原型构建→补充功能规格与设计规范→组件和交互检查→演示→记录反馈→修改→交付版本。区分模拟跳转和真实数据能力，未实现功能标待开发。不要声称绘图工具能自动生成完整业务系统，原模板的模型驱动术语只在团队实际使用时保留。
生成后逐条核对文字、层级与连线；需要保留原模板版式时，可直接使用模板编辑入口。
06 / 交付前复核
这些问题容易被忽略
- 照搬原模板中的模型术语，却无法解释本团队实际交付物。
- 将演示中的跳转成功描述成线上业务已经跑通。
- 只有截图没有状态和异常说明，开发无法确定数据缺失时显示什么。
用一个正常案例和一个异常案例从起点走到终点，再保存你的版本。不要只检查配色和对齐。
07 / 常见问题
使用前还想确认
原型图需要画错误状态吗？
需要覆盖影响主要任务的状态，例如必填信息缺失或结果为空。无需一开始穷举所有细节，但不能只有成功路径。
原模板中的代码生成步骤能直接保留吗？
只有团队确实使用相应工具链时才保留。否则可改为开发交接或实现准备，避免制造不存在的自动化能力。
从这张模板开始，做成你的工作图
先确认节点，再调整分支，最后统一排版。
使用这个模板在线编辑 ↗
