原型设计规范是一组团队共同遵守的页面、组件、交互和版本约定，让不同成员画出的方案能被一致理解。规范不必一开始写成厚手册，先统一命名、画布口径、常用状态和交接方式，再随着项目补充。
可以在墨刀原型项目中建立一页“项目约定”，把下文表格改成团队版本，并链接到实际页面。本文用报销申请说明写法；移动平台的触控尺寸与视觉要求，另外参考移动端UI设计规范。
先约定这份原型要表达多深
原型可能用于讨论流程、展示交互或确认视觉细节，保真程度不同，交付要求也不同。报销需求尚在讨论时，先画申请、审批与结果，重点是费用明细和处理规则；进入UI阶段后，再统一字号、颜色与组件状态。不要把低保真稿误当成视觉定稿，也不要用高保真外观掩盖规则尚未确定。
在项目约定中写明目标读者、当前阶段、演示范围与未覆盖内容。例如“本版用于报销流程评审，金额使用模拟数据，不接财务系统；附件权限和实际支付另行设计”。这样业务方不会因为可以点击提交，就误认为报销已经能真实入账。
用一张表统一页面、组件和交互约定
规范应让成员能立即判断怎样画、怎样命名，而不是只有“保持一致、提升效率”这样的原则。下表是一份起步示例，团队可以按现有习惯调整；选择一种清楚且能持续维护的约定，比追求一套复杂缩写更重要。
| 项目 | 示例约定 | 如何使用 |
|---|---|---|
| 页面命名 | 业务模块-任务-状态 | 报销-申请-草稿；报销-申请-提交失败 |
| 页面分组 | 按用户任务组织，探索稿与评审稿分开 | 申请人流程、审批人流程、公共组件 |
| 画布与适配 | 注明目标平台和逻辑尺寸，单列窄屏规则 | 不要把设备物理分辨率当作统一设计尺寸 |
| 公共组件 | 同类按钮、输入框、弹窗优先复用 | 特殊样式说明使用范围，不随意影响全局 |
| 状态命名 | 草稿、待审批、已通过、已退回等含义固定 | “退回修改”与“终止拒绝”不混用 |
| 交互注释 | 说明触发条件、页面反应与结果 | 提交失败后保留表单，允许再次提交 |
| 版本与交接 | 记录需求版本、原型版本、负责人和未决项 | 评审结论关联到受影响页面 |
命名中的状态应服务阅读，不必把所有字段组合都拆成独立页面。一个弹窗只有按钮加载差异时，可以用组件状态表达；流程发生改变、需要单独评审时，再建立清楚的页面或演示分支。
画布、内容和视觉原则怎样写得具体
不规定一个适用于所有项目的分辨率
手机、桌面后台和大屏不应共享一个固定画布尺寸。先按目标设备与业务场景选逻辑画布，再说明容器宽度、换行和滚动方式。手机项目可进一步参考移动端原型设计规范；桌面报销列表变窄时，是横向滚动、隐藏次要列还是改成卡片，需要项目明确，不能交给开发自行猜测。
页面中放真实长度的示例内容：长费用名称、较大金额、多行说明、缺失附件。用占位词“标题”“内容”画得整齐，并不能说明布局适合真实报销单。
对比、一致、对齐和亲密性落到对象上
对比用于突出主要动作和重要信息，例如提交按钮比暂存更突出，但错误提示不能被压低；一致性让同一动作保持名称与行为；对齐帮助扫描费用、金额和日期；亲密性则通过合理间距，把同一条费用的字段组织在一起。
这些原则不是所有元素都必须长得一样。删除附件属于有风险的操作，不应仅为统一而使用与上传相同的图标和文案。Nielsen Norman Group的一致性与标准原则强调用户不应猜测不同表达是否指同一件事，团队规范可以借此检查自己的按钮和状态命名。
一条交互说明，要让研发知道失败后怎么办
只写“点击提交进入下一页”不够。报销申请可能缺附件、金额不正确或网络失败；审批人也可能在页面打开后失去处理权限。把条件写在相关对象旁边，比把所有异常塞进文档最后一页更容易被发现。
报销申请提交：申请人填写费用明细和本例要求的附件后可提交。缺少必填项时，在对应区域说明问题，不清空已填内容。提交中显示处理中并避免重复操作；成功后展示申请编号并进入进度页；失败后保留草稿，显示重试入口。是否允许无附件申请由企业规则另行确认。
这段说明包含正常和失败两条路径，也明确了未决规则。与之对应的原型应能展示草稿、处理中、失败和成功后的结果。服务端验证、真实编号和重复提交控制由工程实现；原型负责把期望行为讲明白。
还要说明返回关系：从进度页回到申请列表是否保留筛选条件，退回后编辑的是同一单据还是重新发起。涉及表单细节时，可继续参考表单原型设计；需要演示触发、反馈和跳转，可看交互原型设计方法。
工具帮助执行规范，但不能替团队决定规则
在墨刀中可以利用页面组织、组件与原型交互维护上述约定。先建立本项目常用的申请表单、状态标签和详情弹窗，再逐步复用到其他流程。团队已经使用其他工具时，也可以沿用同样的命名和交付方式，不必为了写规范立刻迁移全部资产。
使用墨刀AI生成初稿时，把已有命名、状态和组件要求一起提供，再检查结果有没有引入同义不同名的字段。例如“报销金额”“申请金额”“费用合计”如果指向同一值，应统一含义；如果不同，则在规则中说明计算关系。
评审后怎样维护，才不会变成过期手册
指定一位维护负责人，记录规范版本、修改原因和影响范围。增加“预付款抵扣”后，先明确金额关系，再同步表单、详情、审批页和状态说明；组件发生变化时，检查引用它的其他页面，而不是只更新当前演示稿。
交付前让没有参与绘制的人根据原型完成一次报销申请。看他能否理解字段、找到附件、在失败后继续，以及从列表查看结果。问题记录到具体页面，决定采用的改动再回写规范。规范的效果应体现在少一些猜测和口头补充，而不是文档页数越来越多。
