任务字段和工作上下文
LadVen OS 这套企业操作系统通过任务字段固定工作约定：需要什么结果、谁负责、什么时候完成、材料在哪里、如何检查。对员工来说，这是行动说明；对负责人来说，这是控制、报告和团队管理的基础。
填写完整的任务会减少聊天中的反复确认，帮助更快找到工作，显示责任并保存决定历史。只要某个字段影响执行、搜索、报告、客户或结果验收，就应有意识地填写。
截图展示了 LadVen OS 的卡片如何把描述、文件、期限、优先级、计划时间、检查、工作组、客户、参与者和标签收集到一个工作空间。用户在这里理解工作，负责人也可以不解读聊天记录就检查任务是否可控。
主要规则
任务必须回答四个问题：
- 应出现什么结果；
- 为什么需要这个结果，它属于哪个上下文；
- 谁负责执行和检查；
- 按哪些标志认为结果完成。
如果这些答案不能在标题、描述、参与者、期限、关联、文件或评论中找到，任务就是不完整的。不要把重要约定转移到私聊中：决定、来源和完成标准应留在任务内部。
工作上下文地图
任务字段像一张管理卡片。有些字段解释要做什么，有些字段把工作与客户、项目、文档和报告连接起来。如果全公司用一致方式填写，负责人看到的就不是零散指令，而是可读的控制系统。
| 字段 | 对员工有什么用 | 对负责人有什么用 |
|---|---|---|
| 标题 | 不打开完整历史也能理解结果。 | 快速阅读列表并看懂指令含义。 |
| 描述 | 不搜索旧消息也能开始工作。 | 检查任务提出质量和验收标准。 |
| 期限和优先级 | 理解执行顺序。 | 看到风险、过载和客户承诺。 |
| 计划和实际时间 | 评估工作量并记录投入。 | 比较计划与实际，管理成本和负载。 |
| 项目或工作组 | 找到共同流程的材料和参与者。 | 控制项目阶段和团队工作。 |
| 客户和客户项目 | 看到互动历史和客户期待。 | 管理承诺、服务质量和客户报告。 |
| CRM 实体 | 理解与线索、交易、账单或请求的关系。 | 不丢失销售或支持的下一步。 |
| 文档和文件 | 使用当前材料工作。 | 根据来源检查结果，而不是听转述。 |
| 关联任务 | 看到依赖和相邻指令。 | 控制工作链条、阻塞点和责任划分。 |
| 标签 | 快速找到同类任务。 | 按流程、主题和重复问题建立切片。 |
不是每个任务都要填写所有字段。必须填写的是缺少后会失去可管理性的字段：任务会找不到、无法检查、无法关联客户、无法评估时间或无法向参与者解释。
标题
标题出现在列表、通知、搜索、关联和报告中。即使不打开卡片，它也应快速说明期待的结果。
好的标题：
- 以动作或预期结果开头；
- 包含工作对象：文档、客户、项目、列表、会议、设置；
- 不依赖口头上下文；
- 能与相邻任务区分；
- 不变成长描述。
| 不好 | 好 |
|---|---|
客户 | 准备给客户的实施期限回复 |
文档 | 发送给客户前检查合同 |
紧急 | 确认试点启动日期 |
看一下 | 检查四月付款导出 |
清晰标题对负责人和执行人同样重要：它让列表更容易阅读，也能不用逐个解释就看出团队正在做什么。
描述
描述说明上下文、工作量和完成标准。它应足够完整，让执行人不用搜索旧消息就能开始。
上下文：
任务为什么出现，与哪个客户、项目、文档或决定有关。
需要做什么：
1. 具体动作。
2. 具体动作。
3. 最终交付什么。
完成标准：
- 应附加、更新或确认什么；
- 谁在哪里检查结果；
- 需要考虑哪些限制或例外。
描述不能替代文件、文档和客户或 CRM 关联。如果任务引用外部对象，请添加链接或关联，并说明在其中要查看什么。
文本格式
格式用于提高可读性：区分章节、列表、链接、引用、重要警告和数据片段。它应帮助理解任务，而不是装饰文本。
适合使用格式的地方：
- 长描述内部的小标题；
- 编号步骤；
- 完成标准列表；
- 带清晰名称的链接；
- 客户、合同或评论中的引用；
- 需要比较选项时的短表格。
如果描述变得过长，请拆分工作。重复步骤更适合放进检查清单，材料放进文件或文档，独立结果则放进关联任务。
完成标准
完成标准说明结果如何被检查。它们对文档、客户回复、审批、报告、设置和多步骤流程尤其重要。
好的标准可以被检查：
- 最终文件已附加到任务；
- 提出人和负责人都能打开链接；
- 文档已更新且没有草稿评论；
- 客户回复已确认并发送；
- 必要检查清单已关闭；
- 关闭前已检查计划和实际时间；
- 评论中记录了最终决定。
差的标准像感受：“正常做完”“弄明白”“尽量检查”。这种表述很难无争议地验收或退回修改。
状态
状态显示工作所处阶段。它不是形式，而是任务流管理工具：负责人能看到什么尚未开始、什么正在执行、什么等待检查、什么已验收、什么已停止。
| 状态 | 对工作的含义 |
|---|---|
| 新建 | 任务已提出，但工作尚未开始；上下文、负责人和预期结果应清楚。 |
| 进行中 | 负责人正在工作，澄清细节，更新检查清单、文件或评论。 |
| 检查中 | 执行人认为结果已准备好并提交检查；任务中应能看到在哪里检查。 |
| 受控中 | 需要负责人、客户或流程所有者单独控制。 |
| 已完成 | 结果已验收，完成标准满足，未关闭问题已处理。 |
| 已推迟 | 工作因明确原因推迟；写明在等什么以及何时返回。 |
| 已取消 | 结果不再需要；取消原因最好记录在评论中。 |
| 未完成 | 结果没有达成，需要与取消或延期区分。 |
不要只因为执行人写了“完成”就关闭任务。先检查结果、完成标准、文件、检查清单、评论，以及如有必要的时间记录。
优先级和期限
优先级帮助把任务与其他工作比较。期限说明什么时候需要结果。二者共同帮助计划负载、发现风险并保住重要承诺。
高优先级适用于必须早于普通队列处理的任务：阻塞客户、启动、付款、控制日期或其他团队。如果任务只是意义重要，请在描述中解释，并选择现实期限。
期限应是需要结果的日期，而不是提出人想起任务的日期。如果期限未知，请在描述中记录谁、何时确认。
保存前检查：
- 期限符合真实需要；
- 高优先级有上下文解释；
- 期限不与负责人负载冲突；
- 延期原因能在评论或历史中看到；
- 无期限任务不会因缺少约定而丢失。
计划时间
计划时间显示预期工作量。它帮助负责人评估负载、比较计划与实际、准备客户或内部报告，并发现超出原始约定的任务。
当任务影响团队负载、工作成本、客户报告或需要预评估时，请填写计划时间。不要把等待客户回复或日历暂停算入计划，除非这段时间实际在工作。
对企业所有者来说，计划时间在重复流程中特别重要：准备合同、处理请求、客户实施、支持、报告。如果相似任务经常比预期耗时更长，就应重新检查流程、模板、角色分配或服务成本。
计划时间不应变成形式。如果任务范围扩大，请记录原因并更新评估。否则报告会显示漂亮的计划，却无法解释团队为什么来不及，或客户工作为什么变得更贵。
更多关于计划时间、计时器、实际时间和计划/实际，请看 在任务中记录时间。
结果检查
当任务不能只凭“动作已做”就算完成时，需要结果检查。合同、商业提案、客户回复、文件、设置、报告，以及任何需要提出人验收最终结果的任务都属于这种情况。
任务中应清楚：
- 谁检查结果；
- 具体打开或查看什么；
- 哪些标准是必须的；
- 最终版本在哪里；
- 如果退回修改，应怎么做。
如果检查是必要的，执行人不应绕过验收直接关闭任务。如果不需要检查，也应从流程中看得出来：例如负责人完成动作并在评论中记录结果后关闭。
预评估
当执行前需要理解工作量、复杂度、风险或期限时，应使用预评估。它可以避免带着错误预期开始工作，也避免向客户或负责人承诺未评估的结果。
预评估适用于：
- 提出人不知道真实工作量；
- 任务可能对一个期限来说过大；
- 需要在解决方案之间选择；
- 客户或负责人需要确认工时；
- 流程要求启动前评估。
评估后，请在任务中固定结论：更新计划时间、期限、描述、检查清单或评论。不要只把评估结果留在执行人脑中或私信里。
好的预评估回答三个问题：工作需要多少时间、什么会扩大范围、启动前需要做出什么决定。如果评估后发现任务过大，请拆成阶段或关联任务，让控制不依赖一个过长的指令。
标签
标签帮助按流程、主题或工作类型快速查找和分组任务。标签应回答：“之后需要哪个切片？”
好的标签示例：合同、试点、审批、实施、客户请求、报告。
不要用标签重复状态、负责人、项目或客户。如果标签不能帮助筛选任务、准备报告或启动重复流程，就不要添加。
对公司来说，随机标签没有统一词典有用。请为重复流程约定一小组工作标签，不要把标签当评论使用。
如果以后会按标签查找任务、查看流程质量或准备管理报告，就值得添加标签。例如，客户请求 可以帮助看到有多少任务来自客户，审批 可以显示延误最常发生在哪里。
项目和工作组
项目把任务连接到可管理的工作流：启动、实施、开发、支持、活动准备或其他有共同结果的任务集合。
当任务属于稳定团队、方向或空间，参与者已有共同上下文和材料访问权限时，工作组很有用。
如果它能帮助以下事项，请选择项目或工作组：
- 在列表和报告中找到任务；
- 查看团队负载；
- 把任务连接到项目阶段；
- 给参与者提供所需上下文；
- 避免任务淹没在个人指令中。
不要把项目当作装饰文件夹。如果任务不属于项目工作，多余关联会污染报告，让负责人难以看到真实情况。
对负责人来说，任务中的项目回答的是：这项指令属于哪个业务结果。项目选择正确时，不只能看单个期限，还能看整个方向的准备度：哪些任务打开、哪里逾期、缺少哪些参与者、哪些阶段需要决定。
如果任务属于项目但没有选择项目，它会留在执行人的个人指令列表中。之后更难把它纳入项目全局、交接给新参与者，也更难在关闭阶段时检查。
客户和客户项目
客户关联说明任务影响客户历史：销售、实施、支持、合同、付款、会议或请求。有了它，经理和负责人看到的不只是一个指令，而是客户工作的一部分。
客户项目用于细化客户内部方向。当一个客户有多个并行流时需要它：实施、支持、集成、培训、法务审批。
保存前检查：
- 选择的是正确客户，而不是相似名称的公司；
- 客户项目对应当前工作流；
- 参与者能访问客户上下文；
- 任务结果需要回到客户历史或 CRM；
- 文件和评论没有给无权限参与者暴露多余数据。
如果任务属于客户但没有选择客户，之后在互动历史、客户报告和承诺控制中会更难找到。
客户关联对承诺尤其重要：准备商业提案、回复邮件、检查合同、开展培训、修复问题、确认付款。在这些任务中，客户不是为了“整齐”而填写，而是为了让任何负责人都能打开客户历史，看到承诺了什么、谁负责、工作到了哪一步。
如果客户项目选择错误，任务可能进入错误的工作流。例如，实施指令落到支持流中，法务审批落到销售流中。对员工来说这是不便；对负责人来说，这是客户报告和风险判断被扭曲。
CRM 和其他工作上下文
当任务继续线索、交易、公司、联系人、账单、请求或其他销售与支持对象的工作时，需要 CRM 关联。
如果任务符合以下情况，请添加 CRM 上下文：
- 来自电话、邮件、会议或交易；
- 影响销售的下一步；
- 与合同、账单、提案或实施有关；
- 应在客户历史中让经理看到；
- 完成后需要更新 CRM。
CRM 关联不应只是形式。请在描述中说明该对象与当前任务的关系：要做下一步销售动作、准备合同、回复客户、更新账单、处理请求或记录会议结果。仅有 CRM 链接不能替代描述，任务中仍然要写清对交易或客户具体做什么。
如果任务来自评论、文档、文件、另一项任务或外部请求，请把来源保存在描述、关联或评论中。一周之后，“按之前说的”已经不能帮助恢复上下文。
CRM 上下文只有在帮助完成下一步时才有价值。如果任务关联了交易，任务中就应清楚下一步：准备账单、更新联系人、确认条件、检查付款、安排会议或发送文件。只有 CRM 链接、没有工作指令，会迫使执行人重新梳理历史。
对负责人来说，CRM 关联说明运营工作没有脱离销售和支持。借助它可以检查下一步是否丢失、客户问题是否悬停，以及任务完成后客户历史是否更新。
文档、文件和来源
文档和文件回答两个问题：工作基于什么，以及在哪里检查结果。它们可以是合同、账单、商业提案、简报、表格、规章、设计稿、截图、报告、邮件，或外部工作文档链接。
如果文件或文档符合以下情况，请添加到任务：
- 执行人需要它完成任务；
- 它确认结果；
- 它包含客户的原始要求或决定；
- 需要负责人、法务、财务或其他部门检查；
- 之后恢复历史时会用到。
文件必须有清楚用途。不要在任务中留下没有说明的一组链接：参与者应理解哪个文档是来源，哪个是草稿，哪个是最终版本，哪个仅供参考。
良好做法：
- 在描述中简短说明关键文档要做什么；
- 在完成标准中指出最终文件或链接；
- 在评论中讨论中间版本；
- 不把过期或偶然附件与最终结果混在一起；
- 在提交执行或验收前检查参与者是否有文档访问权限。
如果文件包含敏感信息，请先确认参与者确实需要访问。不要把无关附件拖进任务中，这会增加搜索和验收成本。
对客户任务尤其重要的是，不要把工作材料从 LadVen OS 带到私聊中。当文档、评论和决定都在任务里，新参与者或负责人就能不靠额外转述恢复上下文。
更多关于附件的信息，请看 在任务中附加文件。
关联实体
关联实体显示任务从哪里出现、会影响哪里。它可以是另一项任务、评论、文档、CRM 实体、客户、项目、请求或外部工作对象。
如果没有关联会丢失任务原因或工作依赖，就应添加关联：
- 一项任务阻塞另一项任务；
- 指令来自客户请求；
- 结果用于交易、账单或合同；
- 文档需要审批；
- 任务继续项目阶段；
- 负责人需要看到工作链条，而不是单独指令。
关联不替代任务提出。即使任务绑定了交易、项目或文档，标题和描述中仍要清楚说明需要什么结果。否则关联会变成“自己去找”的链接，而不是工作上下文。
好的关联让负责人能看到工作链条：一项任务从哪里出现，依赖什么，结果会影响哪里，关闭时要检查什么。
更多关于依赖和关联任务的信息，请看 任务关联。
工作计划
工作计划用于记录还不是独立任务的最近步骤。它可以是简短的行动清单、下一次检查、继续工作的约定或即将到来的阶段。
工作计划适用于：
- 任务暂时推迟，但下一步清楚；
- 需要展示预评估之后会做什么；
- 结果依赖外部回复；
- 提出人希望不用阅读全部讨论就看到最近行动；
- 某部分工作还太早，不适合拆成子任务。
不要在工作计划中存放完整项目计划。如果某一步有单独负责人、期限或可检查结果，请创建关联任务或子任务。
创建和更新日期
创建和更新日期帮助理解任务的新旧程度和变更历史。创建日期说明任务何时进入工作流。更新日期提示最近一次重要信息、评论、文件、检查清单或状态是什么时候变化的。
可以把这些日期当作信号：
- 创建很久但没有更新的任务可能已被遗忘；
- 关闭前的新更新需要检查；
- 大幅延期或更换负责人应有说明；
- 带客户上下文的任务在报告前可能需要最新评论；
- 过期任务可能需要取消、延期或重新提出。
更新日期本身不能证明有进展。检查结果时仍要看描述、文件、检查清单、评论、状态和时间。
如何填写和修改字段
字段的含义在所有阶段都应保持一致：创建、查看、编辑和关闭任务时都一样。修改字段不是为了“整理”，而是为了让工作约定保持最新。
创建时
保存前先填写最低工作上下文：
- 用结果来写标题。
- 在描述中写清上下文、动作和完成标准。
- 指定提出人、负责人和必要参与者。
- 如果影响执行，填写期限、优先级和计划时间。
- 如果任务属于项目、工作组、客户、客户项目或 CRM，请选择对应关联。
- 如果标签用于搜索或流程，请添加标签。
- 如果没有文件、文档、检查清单或链接就无法开始或验收，请一并添加。
保存前检查模板、复制任务或来源带来的数据。旧参与者、期限、文件或客户关联可能属于另一种情况。
查看时
查看任务时，任务应帮助做出决定：开始工作、澄清上下文、检查结果、退回修改或关闭。
请检查：
- 状态是否符合真实情况；
- 是否有完整上下文可以执行；
- 期限、计划时间、客户或 CRM 关联是否过期；
- 文件、文档和完成标准是否可见；
- 最新变更是否已保存；
- 是否需要修正某个字段，让参与者按最新约定工作。
编辑时
编辑应修正问题来源，而不是掩盖问题。如果范围变化，请更新描述、检查清单、计划时间和期限。如果客户上下文变化，请检查 CRM、项目、参与者和文件访问权限。
编辑后检查：
- 字段新值在任务中可见；
- 列表、筛选器或关联对象显示最新数据；
- 参与者理解发生了什么变化；
- 重要变更已留下评论；
- 描述、文件或检查清单中没有保留过期约定。
访问和保存变更
有时字段不能修改，是因为用户角色、任务状态或流程设置。不要用“按另一个期限算”这类评论绕过限制。如果字段影响流程、报告或责任，就需要通过可用方式修改，或在管理员、流程所有者决定前向参与者解释限制。
如果修改了重要字段，请确认变更确实保存，并且参与者能理解。影响期限、客户、执行人、成本或验收的变更，最好留一条短评论：改了什么、为什么改。
如果保存失败，或刷新任务后仍看到旧值，不要按猜测继续工作。请确认最新值，必要时重新修改，并把约定固定在任务中。
负责人如何用字段控制
字段帮助负责人管理的不是单独指令，而是一套工作系统：
- 标题和描述显示任务提出质量；
- 负责人和参与者固定责任范围；
- 期限和优先级帮助发现风险和过载；
- 项目、客户和 CRM 把任务连接到业务上下文；
- 标签提供流程和工作类型的快速切片；
- 计划和实际时间帮助比较预期与真实投入；
- 状态和完成标准把“正在做”与“已完成并验收”区分开。
如果任务中经常没有描述、没有期限、没有选择客户，或完成标准含糊，这不只是格式问题。它说明任务提出流程没有给团队足够的可管理性。
实用的管理控制建立在几个固定切片上：
| 切片 | 看什么 | 能看到什么风险 |
|---|---|---|
| 高优先级逾期任务 | 期限、负责人、客户、延期原因。 | 团队无法按关键承诺完成。 |
| 客户工作中没有客户或 CRM 的任务 | 标题、描述、项目、评论。 | 客户历史不完整，承诺难以恢复。 |
| 没有描述或完成标准的任务 | 标题、评论、文件、检查清单。 | 执行人和检查人对结果理解不同。 |
| 计划/实际偏差大的任务 | 计划时间、实际时间、评论。 | 流程被低估、服务变贵或任务膨胀。 |
| 没有更新的任务 | 更新日期、状态、最后评论。 | 工作停止但状态没有体现。 |
| 高频标签或重复任务类型 | 标签、项目、客户、执行人。 | 存在可标准化或自动化的重复流程。 |
这种控制不要求阅读每一项任务。负责人先看切片，再打开有风险的任务：逾期、缺少上下文、缺少客户、没有结果或检查不清楚。
字段如何帮助搜索和报告
字段填写一致时，列表、筛选器和报告才可信。客户、项目、标签、负责人、期限和状态让团队能找到任务，也让负责人能回答管理问题：谁过载、哪里逾期、哪些客户承诺未关闭、哪个流程最常出现问题。
搜索在重要信息放在专门字段里时效果最好，而不是只藏在讨论中。标题帮助找到结果，客户帮助找到互动历史，项目帮助找到共同工作流，CRM 帮助找到交易或请求，标签帮助找到重复主题，文件和文档帮助找到来源或证明。
如果任务以后需要被查找，请提前想清楚会按什么特征找：
- 按客户：选择客户和客户项目；
- 按销售或支持：添加 CRM 实体；
- 按内部方向：选择项目或工作组；
- 按工作类型：添加约定标签；
- 按文档：附加文件或链接并说明用途；
- 按承诺期限：设置现实期限，并在变化时更新；
- 按成本或负载：填写计划和实际时间。
典型错误是把所有上下文写进描述，却不填写结构化字段。这样任务在已经找到时可以阅读，但在列表、报告和客户历史中很难找到。
如何检查结果
结果检查不是从状态开始，而是从任务字段中的约定开始。
工作顺序：
- 打开任务。
- 阅读标题、描述和完成标准。
- 检查状态、期限、优先级和计划时间。
- 如果验收需要，打开文件、文档、链接、CRM 和客户上下文。
- 查看检查清单、评论和最近更新。
- 如果任务参与时间核算，检查实际时间。
- 确认结果对检查人和必要参与者可访问。
- 如果结果符合标准，验收或关闭任务。
- 如果需要修改，用具体评论退回任务。
如果完成标准在过程中变化，请先在评论或描述中固定新约定，再按新约定验收结果。
良好实践
- 把标题写成结果，而不是主题。
- 在描述中分开上下文、动作和完成标准。
- 只为提高可读性使用文本格式。
- 当项目、客户、CRM、关联实体和标签能帮助查找、检查或报告任务时使用它们。
- 把关键文档关联到任务，并说明需要对它们做什么。
- 解释高优先级和期限变更。
- 如果范围变化，更新计划时间和预评估。
- 在评论中固定重要字段变更。
- 检查参与者对文件、文档、客户、CRM 和项目的访问权限。
- 关闭任务前确认重要变更已保存。
- 编辑后从执行人或检查人的角度重新看任务。
- 使用统一标签词典，避免搜索和报告拆成相似变体。
- 客户任务关闭前，确认结果已反映到需要的历史中：评论、文件、CRM 或客户上下文。
常见错误
- 标题描述的是主题，而不是结果。
- 描述只有一个链接，没有解释。
- 完成标准缺失，或写成“正常做完”。
- 高优先级被用来替代紧急原因说明。
- 期限没有真实原因就设为“今天”。
- 范围扩大后没有更新计划时间。
- 标签重复状态、项目或负责人。
- 客户、项目或 CRM 没有选择，尽管全部上下文都在那里。
- 文档附加后没有说明，参与者不知道它是来源还是最终版本。
- 添加了 CRM、项目或其他任务关联，但描述里没有具体指令。
- 相似标签不断增加，没有统一词典，破坏搜索。
- 客户项目选择错误，任务进入错误工作流。
- 任务在没有检查文件、评论和时间的情况下关闭。
- 用口头约定绕过访问限制。
- 重要字段变更没有向参与者解释。
好上下文中应能看到什么
查看任务时，负责人应能快速理解的不只是当前状态，还有指令的工作逻辑：
- 卡片中描述了什么结果；
- 哪些文件是当前材料；
- 哪个期限和优先级影响计划；
- 是否需要检查或预评估；
- 谁提出任务、谁负责、谁观察；
- 是否有客户、项目、CRM 或工作组；
- 哪些标签帮助找到相似任务并生成报告。
缺少一部分上下文并不总是错误。但如果没有这个字段就无法找到、检查任务或把它连接到客户承诺，就应在关闭任务前填写。