编辑任务
LadVen OS 这套企业操作系统把任务保存为工作约定：需要什么结果、谁负责、到什么期限、用哪些材料检查。编辑任务不是为了改写历史，而是在工作已经进行时，准确更新这份约定。
编辑良好的任务能让所有参与者对新约定有同一理解。执行人看到当前结果和材料，负责人理解变更原因，企业所有者也能不翻聊天和会议记录就恢复决策过程。
在编辑模式中，只修改真正澄清工作约定的部分：结果描述、期限、计划时间、检查、文件、参与者和上下文。重要变更后，请留下说明原因的评论，让任务历史不仅显示“字段被改了”，也能解释管理决定。
主要规则
修改前先问：“这次修改后，团队仍在执行同一个任务，还是已经变成另一项工作？”
如果结果不变，请编辑当前任务。如果出现新结果、另一个所有者、单独期限或独立验收，请创建关联任务或子任务。这样责任不会被稀释，工作历史也保持可读。
好的编辑应：
- 澄清约定，而不是事后替换它；
- 保留一个清楚的最终负责人；
- 显示期限、范围、参与者或材料为什么变化；
- 帮助新参与者快速进入上下文；
- 给负责人留下透明的决策历史。
什么时候修改当前任务
当工作仍属于原来的结果范围时，编辑当前任务是正常做法：输入被澄清、出现了当前文件、期限变动、或新增了负责部分工作的人员。
适合编辑的情况：
- 澄清标题、描述、完成标准或预期结果格式；
- 添加当前文档、合同、简报、表格、客户或项目链接；
- 经确认后修改期限、优先级、计划时间或标签；
- 因明确原因把责任转交给另一名员工；
- 添加需要上下文的协作执行人或观察者；
- 附加新版文件或移除过期材料；
- 在同一项工作内部补充可检查的检查清单步骤；
- 将任务关联到其他任务、文档、项目或 CRM 实体。
编辑回答的是“现在如何完成原约定”。如果修改回答的是“我们新增了什么工作”，这就不再只是编辑。
什么时候需要新任务
当出现独立结果时，请创建新任务。这对管理很重要：单独工作应有自己的负责人、期限、讨论、材料、检查清单和验收。
需要新任务的情况：
- 原任务扩展成几项独立工作；
- 出现可以单独验收的结果；
- 需要另一个负责人或另一个期限；
- 需要其他部门、客户或负责人另行确认；
- 讨论进入独立上下文；
- 原任务已经可以关闭，新工作只是后续阶段；
- 变更太大，旧历史开始误导参与者。
如果新工作是总结果的一部分，适合创建子任务。如果工作与同一主题有关但流程独立，适合创建关联任务。
| 场景 | 正确动作 |
|---|---|
| 描述中忘记当前合同链接 | 编辑当前任务并添加链接或文件。 |
| 客户要求推迟确认期限 | 修改期限，并在评论中写明原因。 |
| 负责人休假并交接工作 | 更换负责人，固定状态交接和材料。 |
| 检查合同后还需要准备单独演示文稿 | 创建关联任务。 |
| 大任务拆成法务、技术和商务部分 | 创建子任务，并分别指定负责人。 |
| 已关闭任务产生下一阶段工作 | 不改写已关闭任务，而是创建后续任务。 |
如何打开编辑
- 打开任务卡片。
- 检查当前约定：结果、负责人、期限、材料、检查清单和最新评论。
- 如果有修改权限，进入编辑模式。
- 只修改与新约定有关的区块。
- 保存变更，并在普通查看模式中检查卡片。
- 如果变更重要，请写评论说明原因，并提及需要行动或确认的人。
如果无法编辑，不要无说明地创建重复任务来绕过流程。请让提出人、负责人或任务所有者修改，或协商创建关联任务。
修改时要固定什么
任何重要变更都应让没有参加通话、会议或私聊的人看得懂。对负责人尤其重要：任务中应显示不只是“改了什么”，还要显示为什么作出这个决定。
重要修改应记录：
- 改了什么；
- 为什么需要修改；
- 谁确认了修改；
- 对期限、范围、责任或验收有什么影响；
- 执行人下一步要做什么。
好评论示例：
期限移到 5 月 18 日，因为客户今天才发来新版合同。按新版文件检查第 3 和第 5 节。负责人仍是 Ivan，法务部门加入为协作执行人。
差评论示例：
更新了任务。
这样的评论不解释原因，不能保护约定，也不能帮助负责人理解计划为什么变化。
修改后的责任
编辑后，任务仍应保留一个主要结果负责人。协作执行人完成部分工作，观察者跟进上下文，提出人验收结果，但他们都不能替代最终所有者。
保存前检查：
- 现在谁负责最终结果；
- 谁验收或检查结果；
- 谁需要完成具体部分；
- 谁只需要了解进展；
- 新参与者是否能访问文件、文档、客户和项目；
- 原负责人是否交接了状态、风险和未完成动作。
如果责任转交给另一个人，不要只改字段中的姓名。请写评论：谁从何时起负责、已经完成什么、材料在哪里、还剩哪些风险。
修改描述和结果
当原始表述不准确、出现完成标准、结果格式变化或需要补充重要上下文时，应修改描述。
好的描述更新会：
- 让结果可检查；
- 补充缺失输入；
- 区分必交结果和参考信息；
- 不无说明删除重要历史；
- 不把新范围藏进旧任务。
如果描述变化来自口头约定，请写一条短评论。例如：“与客户讨论后，验收结果改为风险清单和第 2-4 节建议，而不是完整报告。”这样参与者知道这是协商后的变更，而不是偶然改文案。
如果新描述实际上把任务换成另一项工作，请停下来创建单独任务。把旧卡片中的结果重写会破坏控制：负责人看到一条历史，执行人做另一项工作，验收也会变得有争议。
修改期限和优先级
期限和优先级影响部门计划、负责人预期和客户承诺。不要静默修改，不要为了“好看”而改，也不要用改期限掩盖逾期。
延期时写明原因：
- 输入材料延迟；
- 客户或负责人改变优先级；
- 依赖另一项任务；
- 确认后范围扩大；
- 缺少访问、决定或确认；
- 病假、休假或责任交接。
如果期限经常移动，这不只是任务问题，也是流程信号。可能任务表述不清、范围过大、依赖没有单独管理、团队资源不足，或决定卡在负责人层级。
修改优先级时，请解释业务上下文发生了什么变化：客户期限、项目风险、阻塞其他部门、销售重要性或对负责人的承诺。没有原因的高优先级很快会失去管理信号作用。
修改参与者
只在角色清楚时添加参与者。多余观察者制造噪音，多余协作执行人会产生没有事实所有者的责任表象。
添加人员前回答：
- 他要做、检查或确认什么；
- 他是否需要材料访问权；
- 他是否应收到工作进展通知；
- 只在评论中提及是否足够；
- 谁向他说明当前状态。
移除参与者时，确认团队不会丢失上下文。如果人员已交接工作，请在评论中记录。如果参与者只为一次性问题加入，回答后可以从长期观察中移除。
修改文件和文档
任务文件用于执行、检查或恢复决策历史。请附加当前材料，并说明哪个文件是工作版本或最终版本。
替换文档时写明变化：
- “5 月 16 日新版合同，旧版不要使用”；
- “已添加用于检查的最终版设计稿”；
- “客户发来更新表格，以此作为数据来源”；
- “旧文件保留作历史，工作版本为
contract-v3”。
不要把任务变成主题资料仓库。如果文档很多且独立维护，更适合关联文件夹、项目、客户或文档。任务中保留当前工作和验收所需内容。
保存前检查访问权限。新负责人或协作执行人不仅要在任务中看到文件，也要有权打开源文档、表格、文件夹或关联实体。
修改检查清单
检查清单适合放同一任务内部的步骤。每个项目都应是可检查动作，而不是没有所有者的新任务。
好项目：
- 检查客户付款信息；
- 更新合同第 3 节；
- 附加最终文件；
- 获得提出人确认。
差项目：
- “弄清楚合同”；
- “把客户的事都做完”；
- 把“准备演示、确认预算、启动群发”写成一个项目；
- “交给市场部”，如果市场部会产生独立结果和期限。
如果项目需要单独负责人、期限、文件或讨论，请创建子任务或关联任务。检查清单显示一项约定内部的进度，但不能替代多项工作的管理。
修改关联和上下文
关联帮助理解工作来源和结果检查位置：项目、客户、CRM 实体、文档、父任务、关联任务。
修改关联后检查：
- 任务没有从原工作流中丢失；
- 新关联对参与者可见；
- 上下文没有泄露多余客户或项目数据；
- 描述或评论说明了为什么添加关联；
- 关联任务没有重复同一项工作。
如果任务属于客户、项目或文档，关联不只是为了方便。它帮助负责人之后恢复任务为什么出现、谁作决定、使用了哪些材料。
未保存变更或冲突
保存前确认任务没有被其他参与者修改。如果系统显示冲突或警告，不要自动把自己的改动覆盖到别人的改动上。
正确顺序：
- 查看其他参与者修改了什么。
- 与自己的修改对比。
- 只保存当前有效的合并约定。
- 如果变更影响期限、范围或责任，请写评论说明结果。
如果开始编辑后决定不改变约定，请取消修改。不要保存空变更或技术性改动：它们会污染历史，让负责人难以区分重要决定和偶然动作。
负责人如何控制变更
负责人需要看的不只是当前字段，还包括变更质量。任务可能看起来填得很完整，但管理上很弱：期限无原因移动、负责人无交接替换、新范围藏进检查清单。
查看已修改任务时检查：
- 是否仍只有一个结果所有者；
- 任务是否变成多项工作的集合；
- 延期是否解释清楚；
- 谁确认了范围变化是否明确；
- 新参与者是否理解自己的角色；
- 文件和链接是否当前；
- 完成标准是否对应新范围；
- 评论是否留下决策历史；
- 出现独立结果时是否创建了新关联任务。
如果变更影响客户、金额、项目期限或部门负载，请要求在评论中固定原因。这不是官僚流程，而是保护过程：一周后团队仍应理解为什么作出这个决定。
如何确认团队理解了变更
重要修改后，不要假设团队自动注意到了。尤其是期限、负责人、范围、完成标准或输入材料变化时。
可以这样检查理解：
- 写评论总结变更。
- 提及需要行动或确认的人。
- 请负责人确认新期限或新范围。
- 如果材料变化，指出当前文件或文档版本。
- 如果工作变大，拆分为单独任务。
- 确认后检查任务字段是否与评论中的约定一致。
对关键任务，可以直接写：“请确认新期限和范围已理解。”这能降低“卡片改了，但团队没有接收到”的风险。
评论示例
| 变更 | 评论示例 |
|---|---|
| 延期 | “期限移到 5 月 18 日：客户晚于约定时间发来原始数据。范围不变。” |
| 更换负责人 | “责任从今天起交给 Anna。Ivan 已交接当前状态和带修订的文件。” |
| 澄清范围 | “根据客户意见，增加合同第 5 节检查。其他章节仍按原完成标准。” |
| 添加协作执行人 | “法务部门加入检查表述。最终结果仍由提出人验收。” |
| 替换文件 | “已上传 5 月 16 日新版商业提案。旧版不要发给客户。” |
| 创建关联任务 | “演示文稿准备已拆到关联任务，避免扩大当前合同检查。” |
| 取消多余变更 | “决定不把额外检查纳入此任务。预算确认后另建任务。” |
常见错误
| 错误 | 风险 | 正确做法 |
|---|---|---|
| 通过描述替换结果 | 执行人和负责人开始按不同方式理解同一任务。 | 为新结果创建关联任务或子任务。 |
| 无原因修改期限 | 无法判断是延误、新决定还是掩盖逾期。 | 写明延期原因和谁确认了新日期。 |
| 稀释责任 | 多个参与者看似负责，但没人拥有最终结果。 | 保留一个负责人，其余按角色分配。 |
| “以防万一”添加观察者 | 通知失去价值，人们停止响应。 | 只添加需要跟进过程的人，其他人按需提及。 |
| 把独立工作藏进检查清单 | 新工作没有所有者、期限和单独验收。 | 创建子任务或关联任务。 |
| 替换文件不说明 | 参与者可能使用旧版本。 | 指明当前文件和变化内容。 |
| 编辑已关闭任务而不是创建后续 | 已验收结果的历史被破坏。 | 创建后续任务并关联到已关闭任务。 |
| 认为口头约定足够 | 几天后团队无法恢复决定原因。 | 在评论或描述中固定结果。 |
良好实践
- 先阅读当前卡片，再编辑，避免丢失已接受的约定。
- 只修改真正变化的内容。多余改动会让历史更难读。
- 重要修改后写原因评论，而不只是改字段。
- 保留一个结果和一个负责人。独立工作请创建单独任务。
- 不要在不了解历史价值的情况下删除旧材料。文件过期时请标明当前版本。
- 添加新参与者后立即检查访问权限。
- 对重要变更，请负责人或提出人在评论中确认。
- 保存后以查看模式打开卡片，确认它读起来是一份一致的约定。
编辑后的快速检查
认为修改完成前，请检查：
- 任务结果仍清楚；
- 期限、优先级和计划时间符合新范围；
- 负责人和参与者是有意识分配的；
- 重要原因写在评论中；
- 当前文件和链接对参与者可用；
- 检查清单没有包含独立任务；
- 出现单独结果时已创建关联任务；
- 团队确认了重要变更；
- 负责人能通过任务卡片恢复决策历史。
编辑后应能看到什么
保存后，任务应读起来像一份不矛盾的约定。请确认卡片显示：
- 当前结果描述；
- 如有变化，新的期限或计划时间；
- 一个清楚的负责人；
- 当前文件和链接；
- 角色明确的参与者；
- 对重要变更说明原因的评论；
- 如有新独立结果，对应的关联任务；
- 能让负责人恢复决策过程的历史。
如果编辑后仍需要口头解释新约定，说明卡片还没有更新完整。