原型标注要写清“什么情况下发生什么行为”，而不是只把尺寸和颜色抄一遍。一个能交给研发的标注，至少说明触发条件、页面状态、可操作范围、数据规则和验收结果。下面用“退款申请”页面示例，把业务行为说明和视觉标注分开，让产品、设计、研发对同一个原型做判断。
可以在墨刀原型画布上把说明放到对应页面和交互附近，并给页面与说明编号；研发就能把规则、页面与问题记录对应起来。
先定义标注对象和阅读顺序
以退款申请为例，页面包含订单信息、退款原因、金额、凭证上传和提交按钮。产品需要说明规则，设计需要说明呈现与交互，研发需要知道接口时机和结果处理。把标注分成“页面行为”和“视觉规格”两层：前者回答状态如何变化，后者回答尺寸、间距、字号和资源如何实现。两层写在同一页面的对应编号旁，避免只给一方信息。
| 标注字段 | 退款申请示例 | 研发验收问题 |
|---|---|---|
| 触发 | 选择部分商品并点击提交 | 没有选商品是否禁止提交 |
| 状态 | 草稿、提交中、审核中、已退款、失败 | 刷新后状态是否仍能判断 |
| 数据 | 退款金额不超过可退金额 | 金额精度、单位和错误提示是否一致 |
| 权限 | 本例约定已完成且满足售后条件可申请，已退金额不可重复申请 | 前端隐藏是否仍需服务端校验 |
| 结果 | 成功显示申请编号，失败保留已填内容 | 重试是否造成重复申请 |
用可点击路径承接业务行为
在墨刀原型中建立退款详情、选择商品、填写原因、提交中、审核中和结果页六个状态。每个按钮旁写触发条件和结果，不把“点击后跳转”当作完整说明。例如“提交”需要分成字段校验通过→进入提交中→返回成功或失败；提交失败时保留原因和凭证，允许用户重试。
一张标注表就能覆盖主要状态
| 页面/编号 | 触发条件 | 显示与操作 | 验收结果 |
|---|---|---|---|
| R02 选择商品 | 进入退款申请 | 只展示可退商品，选择后更新金额 | 金额与选中商品相符 |
| R03 填写原因 | 至少选择一件商品 | 原因必填，凭证可选 | 缺少原因时定位到字段 |
| R04 提交中 | 校验通过后提交 | 按钮锁定，显示处理中 | 连续点击不产生两次申请 |
| R05 失败 | 网络或服务异常 | 保留内容，显示重试和退出 | 重试前不丢失已填数据 |
| R06 成功 | 服务返回申请编号 | 显示编号、进度入口和返回订单 | 用户能找到后续查询位置 |
视觉规格只写对实现有影响的内容
尺寸、间距、颜色和字号应绑定组件或状态，而不是在每个页面重复一遍。例如在本项目约定“主按钮高度 44px、禁用态有明确表现、金额按币种规则处理”比“按钮要美观、文字清晰”更可执行。长原因、错误文案和多语言文本要用最长样例检查换行；移动端要标注安全区域和键盘出现时的滚动行为。
业务标注和切图交付不是一回事
业务标注决定用户动作和系统状态，切图交付决定资源文件如何命名、导出和验收。两者都可以挂在同一个原型节点，但不要用一套“宽高颜色”说明代替权限、校验和失败路径。研发接手前，产品应确认规则，设计确认视觉状态，研发确认接口和异常是否可实现。
标注完成的判断
从任意一个高风险节点出发，研发应能回答：什么条件进入、页面显示什么、用户还能做什么、结果如何返回、重复操作会怎样。若只能看懂成功路径，说明标注还缺状态。交付时把原型链接、标注表、资源清单和待确认问题放在同一版本，评审后再锁定变更范围。
一条标注如何写到研发能执行
推荐用“当……时，若……则……”描述动态行为。例如：当用户选择已完成订单中的商品时，若可退金额大于0，则更新退款金额并允许提交；若金额为0，则保留选择但禁用提交并说明原因。这比“金额联动”“按钮置灰”更能让研发、测试和产品对边界达成一致。每条标注同时给出页面编号和示例数据，减少仅凭截图猜测。
交付前的三方走查顺序
- 产品先从规则走查：权限、金额、状态和重复提交是否闭合。
- 设计再从呈现走查：默认、聚焦、错误、加载、成功和窄屏状态是否有对应表现。
- 研发最后从实现走查：接口触发点、幂等处理、错误码、回退和埋点是否有落点。
如果三方在同一节点提出不同意见，先在标注中记录待决策项，再锁定版本；不要直接改图后让其他人从头猜一遍。研发确认“可实现”不等于产品确认“规则正确”，两者都需要留下结论。
提交前可复制以下检查句：能否从任一状态找到进入条件？失败后保留了什么？刷新或重复点击会发生什么？没有权限时页面和接口分别如何处理？四个问题有一项答不上来，就把该节点标为待确认。
标注变更时怎样避免研发用错版本
每条规则使用稳定编号，例如 RFD-03 只表示退款金额校验。业务改动时保留编号，记录旧规则、新规则、影响状态和确认人；仅改间距就不重新描述整条退款流程。页面上的评论解决后，把确认结果写回规则表，不让关键决定只留在聊天记录里。
交付时给出版本名、评审日期和待确认项。研发在开发中发现规则冲突，应回到同一编号讨论；产品确认业务规则、设计更新原型、研发补实现约束之后再关闭。这样的版本管理比把文件反复命名为“最终版”更可追踪。
可以先在墨刀原型画布中摆出退款申请、提交中和失败三个状态，在旁边写上同一套页面编号与规则说明；邀请研发按一次失败重试走查，优先补齐他无法从页面判断的条件。
