更新时间：2026年10月11日

协作评论要让人看清三个关系：这条问题针对什么内容，哪些回复属于同一次讨论，以及问题目前是否已经处理。主评论和回复应组织成线程，已解决内容保留查看与重新打开的入口；原文变化或对象删除时，要说明定位为什么失效，不能让评论悄悄落到错误位置。

以采购需求文档中的运费说明为例，可以用Pixso的UI设计协作能力绘制评论面板及各状态，和文档页面一起讨论。这里设计的是业务应用中的评论体验，而不是规定所有协作工具都采用同一套机制。

一条线程，围绕一个可以回答的问题

文档P-12写着“运费按整单填写”。评审者提出“多供应商运费如何处理？”，随后产品和业务人员在这条主评论下回复。这样的结构让读者知道回复在回应什么，不必从时间流中寻找被打断的前文。

主评论显示作者、时间、问题和定位对象；回复与主评论保持视觉归属，但不必无限缩进。回复某个人时可以在输入区显示回复对象，发送后也保留关系。若界面支持提及成员，需要说明通知谁；普通文字里出现一个名字，不能自动当成用户已经明确选择了该成员。

多条独立问题应拆成不同线程。例如“运费字段放在哪里”和“谁可以修改运费”可能由不同角色处理，合成一条长评论后标为已解决，容易掩盖其中尚未决定的事项。

定位的是内容对象，不是一枚永远正确的坐标

点击评论，应让读者找到对应段落、画面或记录，同时看见足够上下文。只跳到页面顶部，或把高亮隐藏在固定工具栏后面，都没有真正完成定位。高亮和线程之间的关系要可辨，不能只靠一根看不清的细线。

内容编辑后，原来的锚点可能不再可靠。移动段落、修改文本和删除对象是不同情况：系统如果能保持稳定对象关系，可以继续定位；不能确定时，应保留当时引用的片段，并提示当前版本中的位置需要重新确认。不要仅凭相同文字就自动绑定到另一处。

在Pixso画布中，把采购文档P-12及其右侧线程放在同一页面，再复制一份“原段落已删除”的状态。前一张能定位到运费说明，后一张保留引用片段和回复，并明确告诉读者当前版本已没有这段内容。

如果产品支持回看旧版本，可以提供通往相应版本的入口；如果没有，就保留能够支持理解的引用与时间，不画一个无法打开的“查看旧版”。评论的状态与文档版本也应分开：旧版本里的问题被解决，不意味着当前版本所有相关规则都已经确认。

本例的线程状态只有未解决和已解决。负责人确认“每个供应商单独填写运费，整单显示合计”后，在回复中留下结论，再标记已解决。默认列表可以收起已解决线程，但允许按状态找回，便于后来的人理解为何这样设计。

谁能解决、谁能重开、谁能删除，需要按协作关系制定。本例不让任何成员的删除操作自动带走其他人的全部回复。管理员能力如果更广，应有清楚的范围说明，而不是把所有动作都藏在同一个没有解释的垃圾桶图标里。

评论输入中常包含较长说明、链接或附件。发送时应让用户知道正在处理；失败后保留文字及能够保留的附件状态，允许重试或复制内容。不要关闭输入框，只留下一个短暂的“网络错误”。

用户切换到另一条线程时，未发送内容是跟随原线程保留、提示放弃，还是保存为草稿，需要保持一致。尤其在回复对象发生变化时，应让输入区重新显示当前对象，避免把对P-12的说明发到另一条问题下。

再次打开较长线程时，可以定位到未读回复，但仍应方便返回主问题。新回复到达时不要强制把正在阅读旧内容的人滚到最下方；提供“有新回复”的入口，让他自己决定何时过去。

桌面可以把评论放在文档侧边，窄屏则可能需要单独页面或面板。切换后仍应保留主问题、引用内容和回到原文的入口，不能只剩一个没有背景的回复框。关闭评论以后，也应返回此前阅读的位置。

在设计文件中分别检查未解决、有新回复、已解决、定位失效和发送失败状态，再用同一条运费问题串起来。若要进一步规定团队怎样写批注、何时关闭评审和怎样发布决议，可继续阅读异步设计评审的组织方法。界面提供清楚的讨论结构，团队方法再决定如何使用它。