谁参与一项医疗标注任务
医疗数据标注同时是一项专业工作和协作工作。
Axon 来自一个医疗数据标注平台的客户委托。平台需要围绕已有的标注工具，组织项目、数据、成员与作业规则。医生及标注人员处理具体数据，审核员复核结果，质检员按照项目要求检查质量；项目管理员则需要先把这套协作方式定义清楚。
一份数据由谁处理、是否需要多人分别标注、在哪个环节接受审核、按什么要求进入质检，都会影响整个项目的组织方式。即使都叫“医疗标注项目”，不同项目的目标、数据要求和参与方式也可能不同。软件要承接的，是这些专业规则之间的关系。
从项目开始，我就把通用性作为设计的出发点：平台需要容纳多种医疗标注任务，让项目团队能够在共同的产品结构中定义自己的作业方式。
项目属性与规则
统一配置方式，同时保留业务规则的差异。
如果把某个项目的步骤直接写成固定流程，其他项目一旦改变标注方式、参与人数或审核顺序，就需要重新调整软件逻辑。反过来，如果把所有要求都留在说明文档里，平台又很难表达实际的协作安排。
我的判断是，把项目属性、步骤规则和连接关系变成可配置的产品对象。项目定义回答“这是什么任务、需要什么信息”；节点定义回答“这一环节做什么、遵守什么规则”；工作流回答“这些环节怎样衔接”。这三个层次共同表达一个项目。
这里采用了类似 Schema 的配置思路：用结构化定义承载属性类型、可选值和条件关系，再由定义组织配置界面。业务差异可以落在项目和节点配置中，共同的产品界面仍然保持一致。通用性由此有了具体载体，而不只是“支持多种场景”的描述。
节点中的动作和协作安排
把专业规范放进每一个关键步骤。
“标注”这个名称无法独自说明任务应该怎样完成。一个标注节点还需要表达标注类型、处理方式、是否启用质量控制，以及是否需要多人参与。这些规则随节点一起保存，成为流程定义的一部分。
配置界面也需要服从业务关系。例如，只有开启多人标注，参与人数才成为需要配置的内容。将这种依赖放进属性定义，能让管理员在当前选择的上下文中配置相关规则，避免面对一张没有层次的长表单。
审核与质检的参与位置同样需要随项目安排。管理员可以围绕标注环节组织检查步骤，并配置检查范围、抽样比例与通过条件。这样的设计让“谁在什么环节检查什么”进入工作流结构，专业人员的判断仍然由专业人员承担。
画布与属性面板
整体作业路径与局部专业要求，需要两种不同的阅读尺度。
我采用可缩放、可平移的无限画布来组织工作流。管理员从节点库选择共同步骤，通过连接安排数据收集、标注、审核与质检等环节。画布让步骤顺序和交接关系可以被直接看到，也给更复杂的项目路径留出编排空间。
节点内部的规则则放在属性面板里。选中一个步骤，配置界面随之切换，管理员可以在同一项目上下文中设置标注类型、多人协作和分配策略。这样既保留全局路径，又能进入一个环节的细节，不需要在不同页面之间反复寻找对应关系。
画布承担“怎样组织作业”，属性面板承担“这一环节怎样工作”。两者围绕选中的节点保持对应，让业务人员可以逐步完成配置，也让团队有一份共同理解流程的表达。
流程的结构检查
能画出一条路径，还需要能检查它的连接关系。
配置自由度越高，平台越需要帮助管理员发现结构问题。孤立的节点、没有输出的步骤、无法从起点到达终点的路径，都可能让图形看起来完整，却没有形成连贯的作业定义。
我把开始节点、输入输出连接、可达性与循环等检查放进流程编辑与发布路径。问题反馈到相应节点，管理员可以回到画布补齐连接，而不必等到配置离开编辑环境后再定位。
这里有两个不同层次的检查：平台检查流程定义是否连贯，审核员与质检员按照业务规范检查标注结果。保留这种分工，才能让可配置流程与专业质量控制各自发挥作用。
修改规则与版本发布
编辑中的草稿与已发布版本，承担不同的职责。
医疗项目的要求可能调整，团队需要继续编辑流程；同时，一次发布又需要有清楚的版本身份。把两者混在一份持续变化的配置中，很难说明某个版本究竟采用了哪些步骤和规则。
因此，Axon 分开保存草稿与发布定义。草稿承接配置过程中的修改，发布则经过结构检查、编辑权限与参数检查，再创建新的流程定义。旧定义归档，新定义保留父版本关系，使调整前后的结构能够沿着版本关系理解。
我希望流程成为可以保存、讨论和继续调整的业务对象。版本管理承接的正是这件事：一次配置获得稳定身份，后续变化获得明确位置。
三个产品取舍
通用性需要落实到产品的具体边界。
首先，用共同节点建立一致的配置方式，再让项目通过属性与组合表达差异。平台保留可理解的基本构件，管理员围绕实际规范组织流程。
其次，将流程画布与属性面板分工。把所有规则都塞进画布会削弱全局阅读，把所有步骤都变成长表单又会隐藏交接关系。全局路径和局部规则分别表达，再通过节点选择连接起来。
最后，将配置检查、专业审核和版本发布分开。它们分别处理结构连贯性、标注质量和定义身份。每一种机制都有明确对象，平台才能在灵活配置的同时保持清楚的使用方式。
我负责的部分
独立承担平台设计与开发，连接业务抽象、交互结构与系统实现。
我从一开始就围绕不同医疗项目的共性与差异组织产品。核心问题是：怎样让医生及标注、审核、质检角色围绕同一份数据协作，又不把所有项目限制在同一套步骤里。这个判断决定了平台以项目定义和可配置工作流为核心。
在产品层，我划分项目属性、节点规则和流程关系，明确管理员需要配置什么、专业人员在何处参与。用 Schema 式的属性定义承载业务选项和条件关系，让项目差异落在可表达、可保存的结构中。
在交互层，我完成节点库、无限画布和属性面板的组织方式。画布展示协作路径，面板呈现当前环节的专业要求，配置依赖控制相关字段的出现；这些细节共同服务于管理员理解和定义流程。
在实现层，我完成平台前后端及流程层开发，将节点配置、连接关系、项目协作上下文、结构检查、草稿保存与版本发布串成完整的配置路径。既处理可见的编辑界面，也处理定义如何保存、如何发布以及怎样保留版本关系。
这个项目的思考始终围绕“把专业协作规则交给项目定义”。通用性落在可配置对象上，专业性留在各项目的规则与人员判断中，软件负责提供共同的组织方式。
交付范围
项目已完成客户交付。
Axon 把医疗标注中的项目属性、作业步骤与质量控制安排组织为同一套可配置结构。团队可以围绕项目定义讨论流程，管理员可以在共同的编辑环境中安排规则，流程调整也有对应的版本记录。
这个案例重点展示平台的流程定义层。它建立的产品模型是：不同项目共享一套平台能力，同时保留各自的标注规范与协作路径。
展示说明
本案例聚焦已交付平台中的流程定义层：节点规则配置、结构检查与版本发布。
视觉依据原始实现重建，使用代表性示例数据。
