任务评论
在 LadVen OS 中，评论是任务的工作历史。参与者在评论中澄清需求、提出问题、把结果交给检查、记录决定，并解释退回修改或关闭的原因。
请把评论用作绑定到任务的讨论日志，而不是普通聊天。几天后，或负责人更换后，通过评论应能理解做了什么决定、谁下一步行动、结果在哪里。
评论在任务执行中的作用
任务会经过几个管理阶段：提出、澄清、执行、检查、验收和结果复盘。评论把这些阶段连成一个清晰场景。
把评论当作工作标记：
- 问题说明执行人缺少哪些信息；
- 回答消除不确定性，让工作可以继续；
- 阻塞点解释任务为什么不推进，以及下一步依赖谁；
- 决定固定所选方案，避免团队反复争论；
- 发送检查说明结果在哪里以及如何接受；
- 退回修改解释具体哪些内容未被接受；
- 最终评论关闭管理上下文：做了什么、接受了什么、什么被单独移出。
这样负责人不需要在聊天中单独收集状态：任务中能看到工作停在哪里、谁应回答、什么已经接受。
什么时候写评论
如果消息关系到当前任务的执行、验收或历史，请在任务中写评论：
- 需要澄清需求、期限、文件、检查清单或完成标准；
- 参与者需要带任务上下文的问题；
- 出现中间结果或最终结果；
- 决定改变工作顺序、范围、负责人或期限；
- 任务被退回修改、发送检查、关闭、取消或推迟；
- 需要为提出人、执行人、观察者或未来检查保存解释。
没有绑定到结果的简短一般讨论更适合聊天。如果讨论后对任务做出了决定，请在任务中用单独评论固定结论，避免它丢在聊天里。
好评论应包含什么
好评论简短回答工作问题：发生了什么，需要谁行动，如何检查结果。
差评论：
请看一下。
更好：
@安娜，请检查附件中的最终表格：我添加了“付款日期”列，并按清单中的客户填写了行。如果都正确，可以关闭任务。
如果评论用于记录决定，请把它写成结论，而不是争论的延续：
记录决定：第一个版本保留手动文件检查，自动核对移到单独关联任务中。
如何记录问题
问题应帮助继续工作，而不是只说明“不清楚”。请写到收件人无需额外搜索上下文也能回答。
好的问题结构：
- 具体哪里不清楚。
- 为什么没有回答就无法继续，或会有错误风险。
- 执行人看到哪些选项。
- 问题给谁，什么时候需要回答。
示例：
@玛丽娜，请确认哪个客户列表算最终版：5 月 18 日的文件，还是今天从 CRM 导出的列表。没有这个确认，我可能按错误基数计算金额。如果 15:00 前没有回复，我会把 5 月 18 日的文件作为已确认版本。
如果问题改变工作范围，回答后请用单独评论固定结论，并更新描述或检查清单。
如何记录阻塞点
阻塞点不只是“在等”。它是任务无法进入下一步的工作原因。
阻塞点评论中请说明：
- 什么停止了工作；
- 影响哪个任务或检查清单项；
- 谁能解除阻塞；
- 等待之外已经做了什么；
- 什么时候回到检查。
示例：
检查清单第 3 项有阻塞：销售部门还没有最终价格表。草算已准备好，但不能固定最终金额。@奥列格，明天 12:00 前需要文件，否则任务关闭期限必须移动。
不要静默暂停任务。负责人应看到的不只是逾期，还要看到造成逾期的依赖。
Rich text 和结构
评论编辑器支持格式化文本。请为表达含义使用格式，而不是为了装饰：
- 列表用于多个问题、修改或检查步骤；
- 强调用于关键决定、日期、限制或风险；
- 链接用于文档、外部材料、CRM 实体或关联任务；
- 引用用于回答讨论中的具体片段；
- 换行让长评论可快速浏览。
不要把评论变成新的任务描述。如果评论改变完成标准，请更新描述或检查清单，并留下说明变更原因的评论。
评论可以很长，但不应难以处理。如果需要描述大量结果，请附加文档或文件，并在评论中给出简短摘要和检查路径。
提及
提及用于明确把注意力分配给具体人员。当需要参与者回答、检查、确认、附加文件、做决定或关闭问题时使用提及。
好方案：
- 提及人员。
- 写明具体动作。
- 如果重要，指出期限或条件。
- 附加链接、文件或引用，避免对方恢复上下文。
示例：
@伊戈尔，请在 16:00 前检查检查清单第 2.3 项。我已把错误截图附在评论中。
不要“以防万一”提及所有参与者。多余通知会降低对真正重要消息的注意力。如果某人只需要知道结论，请在决定接受后的总结评论中提及他。
文件和 inline images
评论可以附加文件和图片。当材料解释当前消息时，这很方便：错误截图、中间报告、已确认文档版本、结果图片或用于检查的文件。
如果文件只服务于正在讨论的问题，请附加到评论。任务通用材料最好保存在任务文件区，具体步骤的证明保存在检查清单项附件中。
Inline image 适合需要在评论上下文中直接查看的图片，例如错误截图、界面状态或检查结果。添加图片后，请确认可见区域正确，文件名也能与其他附件区分。
编辑已有评论时，附件不会添加或替换。如果需要发送新文件，请留下带文件的新评论，并在需要时引用原消息。
引用和回复
当你回答具体消息、检查清单项、文件或讨论片段时，请使用引用。这样参与者无需重读整条线程就能看到你回应的对象。
引用尤其适合：
- 任务中有很多评论；
- 同时讨论多个问题；
- 需要按具体项目退回任务修改；
- 参与者不是回复最后一条消息；
- 决定与单独文件或检查清单项有关。
带引用的好回复不仅包含同意或不同意，还包含下一步：
同意关于计算的意见。我会修正公式，并用单独评论附上新版本文件。
如果讨论变长，请用不带引用的单独评论固定结论，方便查找。
编辑
当需要修正错字、澄清表述或在发布后立即补充缺失细节时，可以编辑评论。编辑窗口有限：当前参考是发送后 30 分钟。
不要用编辑来悄悄改变已接受的决定或讨论历史。如果评论已经被阅读，或已经有人按它行动，最好留下新评论：
对上一条评论的澄清：只检查 A 列表中的客户，B 列表进入单独任务。
编辑时请检查保存后评论含义仍然清楚，不依赖隐藏上下文。如果保存失败，请刷新任务并确认参与者看到的是当前版本。
删除
删除评论是危险动作，因为它会移除任务工作历史的一部分。只有当评论误发、包含错误文件、重复消息或暴露不应在任务中出现的信息时，才删除评论。
如果评论包含决定、问题、退回原因或检查结果，不要删除。请留下带修正的新评论：
上一条决定已变化：客户确认第二个设计版本。后续按 v2 文件工作。
删除前请确认重要信息已转移到描述、检查清单、任务文件或新评论中。
反应
如果任务中有反应，请用它发送不需要新文本消息的短信号：已接受、看过、同意、需要注意。若需要动作、决定、原因或可检查结果，反应不能替代评论。
反应适合：
- 确认消息已读；
- 参与者无附加条件地同意提议；
- 不需要创建新的文本通知；
- 讨论中已经包含完整上下文。
不要只用一个反应关闭重要问题。如果后续工作依赖这个反应，最好写一句短评论：“已同意，采用方案 B”。
新评论和已读标记
新评论可能把任务标记为未读并进入通知。已读标记帮助参与者看到哪里出现了新消息，并回到上次查看的位置。
请在工作日开始、验收结果前和关闭任务前检查未读任务。如果任务显示未读，请先阅读新评论，再变更状态或接受结果。
如果消息对具体人员重要，不要只依赖整体未读指示器。请提及参与者，并写明预期动作。
与活动和通知的关系
评论和活动解决不同问题：
| 区域 | 显示什么 | 什么时候看 |
|---|---|---|
| 评论 | 讨论、问题、决定、文件、参与者回复。 | 需要理解工作含义、提问、接受或退回结果时。 |
| 活动 | 任务事件：状态、期限、参与者、字段、通知和其他系统动作变化。 | 需要恢复具体改了什么、什么时候改时。 |
| 通知 | 关于新评论、提及、变更和事件的参与者信号。 | 需要理解谁应该收到信息时。 |
如果状态变化没有清晰评论，活动只会显示变化事实，不会解释原因。重要变更请留下评论：为什么移动期限，为什么退回任务，为什么部分接受结果，或为什么取消工作。
记录决定
决定应容易找到。不要把它藏在长讨论中间，尤其是当它改变工作范围、完成标准、期限、参与者或验收方式时。
在以下情况下写总结评论：
- 讨论以选择某个方案结束；
- 提出人改变完成标准；
- 执行人提出限制并被接受；
- 部分工作被移入关联任务或子任务；
- 结果带保留条件被接受；
- 任务被取消、推迟或以未成功状态关闭。
好的总结评论：
记录结论：采用方案 B，因为它不需要修改模板。方案 C 不在本任务中做；已创建关联任务来评估自动化。
如果决定影响执行，不仅要写评论，还要更新任务本身：描述、检查清单、期限、参与者、关联任务或文件。
验收评论
验收应回答：是否可以按约定标准认为任务已完成。因此，评论对执行人和检查人都必要。
执行人提交结果时写：
- 具体什么已经准备好；
- 在哪里打开结果：文件、链接、附件、关联实体；
- 哪些检查清单项已关闭；
- 还剩哪些限制或假设；
- 需要谁参与检查。
示例：
@叶莲娜，提交检查。五月最终报告已准备好：文件“五月报告_v3”已附加到任务，检查清单 1-4 项已关闭。限制：客户“北方”的数据未包含，因为合同尚未签署；我已把它移入关联任务。
检查人验收时不应只写“接受”，而应写管理结论：
已接受并关闭。最终报告符合检查清单，v3 文件视为工作版本。客户“北方”的数据在关联任务中控制。
如果结果未被接受，评论必须包含具体修正和再次验收条件。
实用验收模板：
执行人：
准备好检查。结果：[做了什么]。在这里检查：[文件/链接/检查清单项]。最终版本：[文件名]。不属于本任务：[限制或新范围]。
负责人：
已接受。已检查 [标准/文件/检查清单]。最终版本为 [名称]。开放限制：[如有]。新范围已移入关联任务 [如有]。
退回：
已退回修改。需要修正 [具体区块]，检查 [在哪里看]，并带着 [预期结果] 再次提交验收。
这些评论帮助企业所有者和部门负责人理解任务为什么关闭、结果在哪里，以及新承诺是否没有藏在聊天里。
负责人如何通过评论控制
如果团队正确维护任务评论，负责人不必要求每位参与者单独发送状态。打开任务检查四件事即可：
- 是否有清晰的最后一步：现在谁在行动，要做什么；
- 是否有未回答的开放问题；
- 是否有带所有者和解除期限的阻塞点；
- 重要变更是否有评论：期限、状态、负责人、范围或验收。
如果任务逾期，但评论中有阻塞点、所有者和下一次检查时间，这是可管理情况。如果没有评论，负责人看到的不是流程，而只是沉默的逾期。
定期控制时，最好与团队约定：任何期限变化、退回修改、带保留验收以及对其他部门的依赖，都必须在任务本身有评论。
退回和关闭时的评论
退回工作时，从意义上说评论是必需的：执行人必须理解具体修正什么、如何再次通过检查。
差退回：
重做。
好退回：
已退回修改：最终文件中没有 B 组客户的计算。请添加清单中的行，重新计算总金额，然后再次发送检查。
关闭时评论不总是必需，但当任务对历史、报告、客户或上下文交接重要时很有用。写清接受了什么、最终版本在哪里、还剩哪些限制。
示例：
已接受并关闭。演示文稿最终版已附加到任务，评论中的修改已纳入。自动导出移入关联任务。
分步场景
向执行人提问
- 打开任务。
- 进入评论。
- 简短说明问题和上下文。
- 提及需要回答的执行人或其他参与者。
- 如果没有文件、链接或图片问题会不完整，请附加它们。
- 发送评论。
检查结果：评论出现在动态中，提及显示正确，附件可打开，任务按 LadVen OS 规则为相关参与者标记未读或进入通知。
把结果发送检查
- 确认结果符合描述和检查清单。
- 附加最终文件、链接、文档或截图。
- 写评论：什么准备好了，在哪里检查，是否有限制。
- 如果需要检查人行动，请提及他。
- 如果流程要求，把任务切换到检查状态。
检查结果：检查人能看到评论，最终材料可访问，任务状态符合流程，评论中没有无法检查路径的“完成了”。
回复具体意见
- 找到你要回复的评论或项目。
- 使用引用或回复。
- 写明你做了什么，或为什么建议另一个方案。
- 如果有新文件，用新评论发送。
- 如果意见已关闭，请明确记录。
检查结果：回复靠近上下文，参与者理解哪个意见已关闭，新文件版本通过名称或说明可区分。
把任务退回修改
- 检查结果、文件、检查清单和最新评论。
- 写出具体修改列表。
- 如果需要引起负责人注意，请提及他。
- 说明重复提交后如何检查修正。
- 把任务状态改为工作状态或其他合适的退回状态。
检查结果：退回原因在评论中可见，修正单独列出，任务状态看起来不是已关闭或已接受，负责人获得清晰下一步。
记录最终决定
- 等待讨论形成决定。
- 写单独总结评论。
- 指出选择的方案、拒绝的方案，以及重要原因。
- 如果决定影响工作，更新描述、检查清单、期限、参与者或关联。
- 如有必要，提及需要知道结果的参与者。
检查结果：不用阅读整段聊天也能找到决定，任务反映新状态，关联任务已创建或更新。
报告阻塞点
- 检查是否真的无法在没有外部动作的情况下继续。
- 写明什么停止了任务、哪个结果有风险。
- 指出阻塞点所有者：人员、部门、客户或关联任务。
- 写明已经做了什么，以及可以并行做什么。
- 指出下一次检查时间或解除阻塞条件。
检查结果：负责人看到停止原因，解除阻塞的负责人已被提及，任务不像被遗忘。
状态和限制
- 旧评论可能通过单独动作加载。加载后检查你回复的是当前消息。
- 发送评论或上传文件时，不要在保存指示器消失前关闭任务。
- 如果操作不可用，请检查任务权限和参与者角色。
- 如果 LadVen OS 提示操作不可用，请检查任务权限、参与者角色和工作状态。
- 如果数据被其他参与者修改，请刷新任务，并在再次操作前检查当前评论或任务状态。
- 当前编辑参考窗口为发送后 30 分钟。
- 单个评论文本块大小的当前参考为 4096 字符。大型材料请用文件和简短摘要。
- 编辑模式下不会添加附件。新文件请用新评论发送。
良好实践
- 在工作所在的位置写评论：任务里，而不是个人聊天。
- 只有需要某人行动或决定时才提及他。
- 用单独总结评论固定决定。
- 如果问题、阻塞点、决定和验收是不同管理事件，请分成不同评论。
- 每个开放问题都写收件人和预期答复期限。
- 阻塞点写依赖所有者和下一步，而不只是“在等”。
- 退回修改时列出具体修正。
- 发送检查时写清什么准备好了、在哪里检查。
- 验收时固定哪个文件或结果版本是最终版。
- 把文件附加到需要它的位置：评论、任务或检查清单项。
- 用引用做点对点回复，用总结评论记录决定。
- 如果别人已按消息行动，不要通过编辑改变历史。
- 关闭任务前阅读新评论并检查未读内容。
发送后检查什么
- 评论出现在动态中，且不依赖隐藏上下文也能读懂；
- 提及显示正确；
- 附件已上传、可打开，并有清晰名称；
- inline image 显示需要的区域；
- 引用或回复指向正确消息；
- 重要决定没有只停留在反应里；
- 任务状态与评论内容一致；
- 关闭或验收前已处理未读消息；
- 任务活动确认系统变更，评论解释原因；
- 刷新页面后，评论、文件和已读标记显示符合预期。
常见错误
写在个人聊天而不是任务中。 决定会丢失，新参与者看不到历史。
发送“完成了”但没有结果。 检查人必须理解什么准备好了以及在哪里打开。
没有修改列表就退回任务。 执行人不知道修正什么，任务会反复退回。
无理由提及所有参与者。 多余通知会降低对重要消息的注意力。
把决定藏在长聊天中。 结论应是单独评论，必要时也应反映在描述或检查清单中。
用反应代替确认。 反应帮助确认注意力，但不固定工作决定。
编辑旧消息而不是写新澄清。 对已经读过原文的人来说，历史会变得不清楚。
删除带决定的评论。 最好留下带修正的新评论，让历史保持可理解。
附加文件但不说明。 参与者应理解这是哪个版本、为什么需要、如何检查。
带未读评论关闭任务。 新消息中可能有问题、阻塞点、拒绝决定或新结果版本。
把沉默当同意。 如果决定影响期限、资金、客户或验收，就必须用评论确认。
写阻塞点但没有所有者。 “等数据”不能帮助管理任务。需要指出谁给数据，什么时候回到问题。
接受结果但没有版本。 一个月后会不清楚哪个文件、链接或文档是最终版。
需要的截图
公开评论文档需要的截图应展示的不只是界面，还要展示工作场景：
- 任务中评论的总体视图，包含多条消息、附件和提及；
- 讨论后记录决定的评论；
- 带负责人提及的阻塞点评论；
- 带文件或链接的结果发送检查；
- 带具体修正列表的退回修改；
- 对具体意见的引用或回复；
- 有新评论或未读评论的状态；
- 如果负责人经常用手机检查任务，补充移动端评论视图。
本地化基础截图在 screenshot-manifest.json 中以 tasks.view.comments-light-desktop 跟踪。准备好对应演示状态后，可以把额外截图作为单独场景加入。