对象、任务与流程的衔接

状态：对象、任务、流程的组织方向，以及流程浏览与操作衔接方向已由用户确认。除这些已确认方向外，本页的结构、字段和验收细则均为建议，可调整；本页没有指定具体控件，也不声明已有实现，第 8 节验收场景均未执行。 所属章节：信息架构与工作空间

1. 区分对象、任务与流程

对象提供稳定的工作身份；任务表达当前目标；流程表达业务推进关系。三者可以关联，但不能相互替代。

一份合同可以同时关联资料补充与审核任务；一个任务也可能涉及多个对象，必须明确本次作用范围。没有流程配置的对象仍可被查询和编辑；没有正式任务记录的分析工作仍需要清楚的目标与上下文。

必须区分：

• 实际业务阶段：由产品业务状态与服务端确认结果决定，例如“审核中”。
• 正在查看的步骤：用户此刻打开的内容，例如查看“起草”或预览“签署说明”。
• 当前可执行任务：当前身份有权执行、且满足业务条件的工作，例如“补充审核意见”。

三者不一定相同。步骤被访问过不等于业务已完成；浏览未来步骤不代表已获得执行权限；选择了某一步也不代表该用户承担其责任。

2. 建议的上下文契约

设计稿和实现规格应明确以下信息。它们是语义契约，不是强制 API 字段或数据库结构：

版本、责任人和任务编号只在业务存在且用户有权看到时展示。不能为了满足通用模板而制造不存在的数据。

3. 三类入口如何到达同一事实

对象入口

从对象列表或搜索进入时，优先帮助用户理解对象当前状态与主要内容；有待办任务时可提供明确入口。一个对象存在多个任务时，不能未经说明直接把其中一个当成“当前任务”。应说明任务名称、状态及其适用身份。

任务入口

从待办或通知进入时，直接定位任务所需内容，同时展示关联对象与当前业务状态。任务已完成时进入结果或历史视图，并说明原任务已不可继续操作，不默认新建另一个任务。

流程入口

从流程概览进入时，展示实际阶段、活动分支与可访问的节点信息。允许查看历史或未来阶段与允许执行必须分开。若用户没有步骤内容访问权，应按安全策略提供有限状态说明或不显示入口，而非先展示内容再报错。

入口之间可以切换。切换改变查看方式，不改变授权、实际状态或任务责任。

4. 流程导航的表达

线性步骤适用于业务确实有主要先后关系的流程。存在分支、会签或往返时，应选择能表达实际关系的阶段列表、分组或关系视图，不能用单一进度百分比掩盖阻塞与并行。

每个可见节点按需要说明：阶段名称、真实状态、必要的进入或完成条件、当前责任、用户可执行的动作。未满足条件的未来节点与无权访问的节点是不同原因，不应统一写成“不可用”。不过，解释不得泄露用户无权知悉的节点内容或人员信息。

“当前业务阶段”和“正在查看”应使用不同的文字或可被辅助技术识别的状态，不能只用两种相近颜色。完成标记应来自业务确认，而不是页面访问记录。

流程有多个活动分支时，可显示“审核：2 个分支处理中”等真实摘要，并允许有权用户查看各分支。只有产品提供可靠计数和合并规则时才能如此展示。

5. 查看资料后怎样返回任务

5.1 离开正在操作的任务

用户可以在任务中查看对象详情、附件、相关记录或其他流程步骤。界面应清楚说明这是查看资料，并保留回到原任务的入口。

若输入能在当前会话安全保留，普通浏览切换不必一律弹出确认。若切换会丢失未保存输入，或切换安全域使其不能继续保留，应在发生前说明，并提供真实可用的保存、放弃或取消离开方式。自动保存不等于已经完成流程任务。

5.2 返回任务

返回时按以下顺序处理：

1. 确认当前身份仍有权访问对象、任务和输入涉及的字段。
2. 重新取得任务状态、数据基准与必要的业务条件。
3. 恢复当前允许保留的原始输入，包括未解析或待修正内容；查看位置和参照信息另按当前上下文有效性恢复。
4. 对已变化或失效部分说明原因，保留允许保留的工作，要求用户重新核查或解决冲突。
5. 在确认当前任务仍可操作、必要校验通过后，才允许新的提交。

只有变化影响判断、输入有效性或操作后果时，才需要重新确认；不要求每次返回都弹窗，也不让用户重填仍有效且未变化的内容。

5.3 任务已经结束

如果其他人已完成、撤回或取消任务，应展示当前结果与允许访问的完成信息。未提交意见可在权限允许且存储政策支持时保留供参考，但不得挂在已结束任务上继续提交。若业务允许创建后续任务，必须作为有明确含义的新操作，而不是自动把旧提交改投到新任务。

6. 操作名称与业务结果

“下一步”容易混淆导航和执行。仅切换编辑分区时可使用“下一节”并解释保存状态；推进业务时应使用“提交审核”“退回补充”等结果导向名称。

提交前显示目标对象、相关版本或数据基准、作用范围以及重要后果。提交后只有收到可信的业务结果才能显示完成或新阶段。请求已发出但未获得结果时，显示“结果待确认”并进入状态核查，不回退成可再次提交的初始状态。

业务完成与页面离开也要分开：成功后可提供“查看结果”“返回待办”等动作，不因用户没关闭页面就继续显示待处理，也不因为关闭页面就认定成功。

7. 示例：审核中查看起草资料

以下是说明交互的虚构示例，不定义合同业务制度。

合同 C 处于审核阶段，用户正在填写意见，随后打开“起草资料”。流程区继续显示“业务阶段：审核中”，同时标明“正在查看：起草资料”。用户查看附件后返回：

• 合同与任务未变化：恢复审核意见及阅读位置，继续操作。
• 合同内容已更新：保留允许保留的意见，提示哪些判断依据变化，引导核查；不能把旧确认直接套在新内容上。
• 审核已被其他人完成：展示已完成状态与允许查看的结果，取消旧提交入口，不重复执行审核。
• 用户已失去访问权：停止展示受限内容，按权限政策处理本地草稿；不能以“保留上下文”为理由继续展示。

8. 验收场景

以下为待执行的验收场景，当前结果均为未执行：

1. 给定业务处于阶段 B，用户查看阶段 A 和 C；预期业务状态始终为 B，浏览不会触发业务写入。
2. 给定填写中的任务，查看资料后返回且数据未变；预期有效输入、任务身份和必要位置保留。
3. 给定用户离开后对象发生影响判断的变化；预期返回后说明变化并要求重新核查，旧提交不能直接通过。
4. 给定任务已由他人完成；预期展示当前结果，旧操作不能重复执行，未提交意见不会自动转移到另一任务。
5. 给定并行分支；预期每个分支状态、责任与合并条件清楚，不因其中一支完成就展示整个流程完成。
6. 给定用户只能查看部分步骤；预期导航、搜索和深链接都遵守相同权限，不泄露受限步骤内容。
7. 使用键盘和辅助技术切换步骤；预期能分别获知查看位置、实际业务阶段与可执行动作，焦点不因后台状态更新无故跳转。

9. TASK-01：独立任务边界的判定记录

主操作限制中的“任务上下文”按目标、作用对象与范围、一次操作后果、输入及结果的归属共同判断。设计评审需能写出下表，而不是先按卡片、分栏或窗口数量分配主按钮；按钮呈现以 操作组件：按钮与动作入口 为主档。下表是细化工作稿，不是新增任务 API。

反向检查

如果两个“主操作”会消费同一份未保存输入、改变同一处理集合、互斥地结束同一个任务，不能仅因布局分组就称它们独立。D04（代理依用户授权作出的初始设计决定，见 决策与讨论记录）已选择不启用批准与拒绝双状态主操作例外，采用 操作组件：按钮与动作入口 的单主操作路径；布局分组不增加配额。

相关：上下文与返回见 导航、深链接与上下文保留；流程协作见 流程推进与协作责任；结果核查见 异步执行、结果核查与恢复。