产品交互说明是把页面上的操作、触发条件、系统响应与状态变化写清楚的文档。写的时候，应让每条规则对应到一个具体页面或控件，并说明用户下一步能做什么。只有“点击保存，成功提示”还不够：保存前校验什么、请求中能否重复点击、失败后是否保留输入、离开页面后结果如何处理，都可能改变研发实现与测试结论。
可以结合墨刀产品经理工作台把原型中的控件与文字说明对应起来。操作目标还不清楚时，先用用户故事明确用户要完成的任务，再写行为细节。下面沿用“提交个人资料”的例子，把说明写到能被研发和测试共同使用的程度。
什么是产品交互说明
产品交互说明通常描述用户操作路径、界面反馈、状态变化和跳转逻辑，可以写在PRD、原型批注或独立文档里。文件放在哪里不是关键，关键是团队能找到与当前原型版本一致的规则，不需要从多个聊天记录中猜出最终决定。
为什么需要产品交互说明
一个可点击的原型能够帮助团队体验路径，但不一定展示所有数据、权限、异常和中断状态。如果未演示的分支没有文字约定，研发与测试就可能按不同假设工作。交互说明把这些差异提前摊开，让“这里应该怎样”有可追溯的答案。
交互说明和PRD、原型图的区别
- PRD：说明业务目标、范围、规则以及为何要做，帮助团队理解需求。
- 原型：呈现界面结构与操作路径，也可以通过状态和交互演示行为。
- 交互说明：补齐触发条件、反馈、数据变化和未完整演示的分支，让实现与验收有共同依据。
三者可以互相引用，不必把同一段规则复制三遍。例如“哪些人有权修改联系电话”可引用PRD中的权限规则，原型显示入口与状态，交互说明再约定权限失效时如何反馈。业务规则改变时，同步相关表现，避免各处都维护一份略有不同的答案。
产品交互说明包含哪些内容
一份完整说明通常覆盖以下内容，但无需给每个没有交互的装饰元素写一页说明。优先描述会改变用户路径、数据或状态的部分。
- 页面功能：页面目的、访问条件和主要操作区。
- 元素行为：按钮、输入框、弹层、Tab等的点击、输入、切换、关闭规则。
- 状态表现：默认、聚焦、禁用、编辑中、加载中等状态及切换条件。
- 反馈机制：成功或失败信息出现在哪里、包含什么、之后能做什么。
- 操作流程：进入、完成、返回和继续操作的路径。
- 边界与异常：字段错误、权限不足、网络失败、空数据、中断或重复操作。
描述状态时，尽量包含“触发条件、界面变化、数据去向”。例如“保存失败，按钮恢复‘提交资料’，昵称与联系电话保留，用户可重新提交”，比“失败时提示错误”更明确。多个错误是否同时出现、关闭弹窗后焦点回到哪里、返回列表是否保留筛选，也应放到对应操作中。
“提交资料”按钮可以这样写
假设用户在个人资料页填写昵称与联系电话，再点击“提交资料”。页面使用PROFILE-01，按钮使用submit-profile作为稳定编号，并在原型对应位置标注。下面沿这条任务约定行为；项目中的实际字段规则需要单独提供，不能由示例代为决定。
初始与编辑：进入页面展示已保存资料；用户修改后保留当前输入。本例按钮始终可见，提交中之外可以点击。字段错误在提交时明确显示，不靠始终禁用按钮让用户猜原因。电话格式与是否必填，引用同一份字段规则。
字段校验失败：点击提交后发现必填项为空，在对应字段附近显示原因，并定位到首个错误；此时不发起保存请求，其他输入保留。不能只在页面顶部显示“填写有误”，却不指出需要修改的字段。
提交中：校验通过后发起一次请求，按钮显示“提交中…”并阻止连续点击产生新的请求。用户通过系统返回离开页面，不代表服务端请求已取消；再次进入时按已保存结果显示，避免把离页等同于保存失败。
服务失败：恢复可提交状态，保留输入，并提供可理解的失败说明与重试动作。请求超时不能直接认定服务端没有保存，需要与研发约定查询结果或防止重复处理的机制，再决定下一步操作。
成功：收到明确成功结果后显示“资料已保存”。本例停留在当前页，展示保存后的内容，用户自行离开。点击按钮后不能立即清空表单；也不能只因为加载动画结束，就把未确认的结果显示为保存成功。
研发可以据此判断何时发送请求、何时恢复按钮；测试可以安排空字段、连续点击、超时后重试和成功返回等用例。如果原型只演示成功路径，应在说明里保留其余分支，不能让演示范围代替产品规则。
再补上容易落在文档缝隙里的行为
| 情形 | 需要写明的约定 | 本例如何处理 |
|---|---|---|
| 编辑后点击返回 | 哪些内容算未保存，取消离开后保留什么 | 有改动时确认是否放弃；选择继续编辑则保留内容与当前位置 |
| 键盘提交与点击按钮 | 允许的快捷操作是否走同一规则 | 若支持键盘提交，与按钮共用校验及防重复逻辑 |
| 保存过程中继续编辑 | 请求使用哪个版本的字段，结果对应哪次输入 | 本例提交中暂时锁定可编辑字段；结束后恢复 |
| 权限在页面打开后失效 | 服务端拒绝后如何显示，输入是否保留 | 说明权限已变化，保留当前输入供用户查看；不显示保存成功 |
| 另一处修改了同一资料 | 是否检查版本冲突，发生时如何处理 | 列为需与研发确认的规则，不默认为最后一次提交覆盖 |
这张表不是要求每个资料页都采用相同策略，而是把同一条操作中容易互相矛盾的决定写出来。例如，若某份说明前文允许提交中继续输入，后文又用请求发出时的值覆盖页面，就需要明确新输入是否会丢失。评审应解决这些矛盾，而不只是确认按钮文字。
可复制的交互说明文档片段
文档可以使用下面的短格式，不需要把每个字段都扩成独立章节。一个页面有多条关键操作时，分别编号并复用共同的字段与权限规则。
页面与控件：PROFILE-01 / submit-profile
用户动作：点击“提交资料”。
前置条件：当前用户具有资料修改权限；页面已加载完成。
校验：按字段规则检查昵称、联系电话；错误定位到字段，其他输入保留。
请求中：按钮显示“提交中…”；阻止重复提交；本例暂时锁定可编辑字段。
成功：更新已保存数据，停留本页，显示“资料已保存”。
失败：保留输入、恢复编辑与提交，并按错误类型显示下一步。
离开与返回：编辑未保存时确认放弃；提交后离页不等于撤销请求，再次进入读取已保存结果。
未决事项：数据版本冲突与超时后结果查询方式；由产品、研发确认后补入本条规则。
关联：原型版本、字段规则、权限说明与对应测试用例。
工程实现细节和用户行为要分开。产品说明需要明确重复点击的可见结果，但不必未经讨论就指定数据库锁或某种接口算法。研发选择实现方式后，把会影响体验的等待、失败和恢复行为再同步回来。
产品交互说明的写法与规范
用词精准：使用“点击后跳转至订单详情”“校验失败后保留输入”等可观察描述，避免“适当提示”“智能处理”“类似某平台”。如果引用通用组件规则，给出组件名称或链接，而不是让读者凭印象猜。
图文对应：文字中的控件名称、原型中的标签和测试用例的对象保持一致。用页面编号区分同名按钮，在图上标记实际位置；不要让“保存”同时指暂存草稿和正式提交。
逻辑与视觉一起描述：说明何时出现反馈，也说明反馈在何处。字段错误放在字段旁、全局失败放在页面提示区，两者的发现与恢复方式不同。键盘操作与焦点回到哪里，也属于交互说明的一部分。
写清中断而不只写完成：取消、关闭、返回、超时和权限变化可能影响已输入数据与请求结果。把这些行为放在发生的位置，不要在文末用一句“异常情况统一处理”略过。
修改规则时，同步哪些地方
把文档版本、原型版本和确认日期放在同一处。若把“保存成功后返回上一页”改成“停留本页”，至少同步成功反馈、原型跳转、返回行为和测试预期。只改一段说明，会让演示与实现依据互相矛盾。
评审意见可以写成：“PROFILE-01成功后停留本页，显示保存结果；删除自动返回连线；更新成功用例的预期”。这比“调整一下成功状态”更容易追踪。尚未确定的规则记录问题与负责人，确定后再变成正式约定。
用AI整理交互说明初稿
墨刀AI可以根据需求整理页面、功能与交互文档，并继续编辑。最有用的输入不是“帮我写一份完整交互说明”，而是已经确认的页面、字段和规则；AI适合帮助展开条目、发现遗漏，把没有依据的内容标出来。
先整理页面组件与业务限制，再输入明确任务。界面中的方案撰写入口可用于文档任务；不要把选择某个模式当作规则已经完整的保证。
例如为本文资料页输入下面的要求，就能让初稿沿着既有规则展开：
请为PROFILE-01个人资料页整理交互说明。字段为昵称、联系电话；按钮为submit-profile。点击后先校验再保存；字段错误保留输入并定位到错误；提交中阻止重复点击，暂时锁定编辑；成功停留本页；服务失败保留输入并恢复操作。离页不代表撤销请求。请按触发条件、界面反馈、数据变化和下一步动作写出规则。未提供的长度限制、电话格式、超时阈值、权限细则和版本冲突策略单独列为问题，不要自行设定。最后指出规则之间是否矛盾。
获得文档后，先看AI是否擅自填入了“11位手机号”“3秒后返回”等项目未给出的规则，再对照每个状态。把错误或遗漏修正后，继续追问“用户在提交中关闭页面时会怎样”“服务端已保存但客户端超时时如何显示”，让初稿暴露需要讨论的分支，而不是越来越像一份已定稿的承诺。
生成结果可以在编辑工作区继续修改，用于团队评审。交付时把已确认规则、未决问题和对应原型放在一起，只有经过确认的部分才作为实现依据。
把交互文档落到具体组件时，可以继续核对文件上传的进度、失败重试和批量结果，以及日期时间选择器的范围、禁选与跨时区规则。这些状态应写进对应说明，再放入原型检查操作前后的变化。
可以进入墨刀整理资料页原型与交互说明，先完成一条提交链路。让研发能够判断请求与状态，让测试能够写出预期结果，比把每个控件都堆满形容词更有价值。
