研发平台的状态配置通常由四类对象组成：状态值定义工作项可以停留的具体阶段，状态分类把这些阶段归入待处理、进行中、已完成等语义分组，默认状态规定新建或流转时自动落入哪个状态值，状态属性描述单个状态值附带的约束与行为。本文按这四类对象逐一说明各自职责、相互关系，以及容易与工作流、看板列、权限混淆的地方。
要点总览（TL;DR）
- 研发平台状态配置由四类对象组成：状态值定义工作项可停留的具体阶段，状态分类把阶段归入待处理、进行中、已完成等语义分组，默认状态规定新建或流转时的落点，状态属性描述单个状态的约束与行为。
- 状态值管“有哪些阶段”，状态分类管“阶段属于哪一类”，两者是包含关系：一个分类下可以有多个状态值，分类不替代状态值，分类调整会牵动看板列与统计口径。
- 默认状态分两个环节：新建时自动落入的状态值，以及流转到某分类后落入的具体状态值；配置错误会出现新建即显示已完成、待处理队列为空等现象。
- 状态属性依附于状态值，常见项包括是否计入完成、是否允许编辑、是否必填字段、是否触发通知；它不替代状态分类的统计语义，也不替代工作流的流转规则。
- 状态配置与工作流、看板列、权限分属不同层：状态配置定义阶段与语义，工作流定义阶段之间怎么走，看板列属于展示层，权限控制谁能改状态。
研发平台状态配置到底包括哪些内容
状态配置回答的是“这个工作项在平台上可以处于哪些阶段、这些阶段分别代表什么、新建时落在哪里、每个阶段有什么限制”。围绕这四个问题，配置对象可以归为状态值、状态分类、默认状态、状态属性四类。它们共同构成平台承载业务规则的一层：业务规则本身由团队根据研发流程定义，平台负责把这些规则表达成可执行、可统计、可校验的配置。
四类对象的分工可以用一句话概括：状态值管“有哪些阶段”，状态分类管“阶段属于哪一类”，默认状态管“初始落在哪里”，状态属性管“这个阶段有什么约束”。理解这个分工，比记住配置界面上有多少个字段更重要，因为后续的看板展示、统计报表、流转校验都建立在这四类对象之上。
| 配置对象 | 回答的问题 | 主要被谁引用 | 典型内容 |
|---|---|---|---|
| 状态值 | 工作项可以停留在哪些具体阶段 | 工作项记录、流转规则、看板列 | 待处理、修复中、验证中、已关闭 |
| 状态分类 | 每个阶段在语义上属于哪一类 | 看板列分组、统计口径、流转条件 | 待处理、进行中、已完成 |
| 默认状态 | 新建或流转时自动落入哪个状态值 | 新建表单、流转动作 | 新建缺陷默认进入“待处理” |
| 状态属性 | 单个状态值附带哪些约束与行为 | 编辑校验、通知、完成度统计 | 是否计入完成、是否允许编辑、是否必填字段 |
需要说明的是，本文讨论的是平台如何承载状态规则，具体业务流程该设几个阶段、每个阶段叫什么名字，属于团队自身的业务定义，不在本文展开。
状态值与状态分类：阶段本身和阶段的语义分组
状态值是工作项可以停留的具体阶段，通常带有名称、排列顺序和所属分类。它是用户在日常操作中直接看到和选择的对象，例如“待处理”“修复中”“验证中”“已关闭”。状态值的数量由流程复杂度决定，粒度可以很细，也可以保持精简。
状态分类是语义分组，作用是把多个状态值归入统一的含义层级，常见分类包括待处理、进行中、已完成。分类本身不直接出现在工作项的状态选择里，而是被看板列、统计口径和流转条件引用。例如看板按分类分列时，“修复中”和“验证中”可以同属“进行中”一列；统计完成率时，只有归入“已完成”分类的状态值才计入。
两者的关系是包含关系：一个分类下可以有多个状态值，分类不替代状态值。团队可以为了管理精细度设置较多状态值，同时用少量分类保持统计口径稳定。反过来，如果只设分类而不设具体状态值，工作项就没有可停留的落点，配置无法运转。
状态值的改名或增删会影响历史数据与报表口径。删除一个状态值后，历史上处于该状态的工作项需要重新归属；改名虽然保留记录，但按旧名称筛选的报表和看板条件可能失效。分类调整的影响面更大，因为它牵动统计口径，调整前应确认哪些报表、看板列和流转条件引用了该分类。
默认状态：新建与流转时的落点规则
默认状态规定新建工作项时自动落入的状态值。用户打开新建表单，状态字段已经预填为某个值，这个值就来自默认状态配置。合理的默认值应当对应流程的真实起点，例如新建缺陷默认进入“待处理”，新建需求默认进入“待评审”。
常见做法有两种：按工作项类型分别设置默认落点，因为需求、缺陷、任务的起点往往不同；或者按状态分类设置默认落点，先确定新建项进入哪个分类，再在该分类下指定具体状态值。前者更精确，后者在状态值较多时更容易维护。
流转到某分类时的默认落点与新建默认状态是两个不同环节。前者发生在工作项已经存在、执行某个流转动作之后，例如“关闭”动作把工作项送入“已完成”分类，若该分类下有多个状态值，需要指定落入哪一个；后者只作用于新建瞬间。两者都叫“默认”，但触发时机和配置位置不同，排查问题时需要分开检查。
默认状态配置错误会带来容易识别的现象：新建工作项一创建就显示“已完成”，导致完成率虚高；新建项落在“进行中”，让待处理队列始终为空；不同工作项类型共用同一个默认值，使缺陷和需求的起点混在一起。出现这类现象时，优先检查默认状态与工作项类型的对应关系。
状态属性：单个状态值上的约束与行为
状态属性描述单个状态值的附加规则，回答“工作项处于这个状态时，平台应该做什么、禁止做什么”。常见属性项包括：是否计入完成、是否允许编辑、是否要求某些字段必填、是否触发通知或校验。属性依附于状态值，随状态值一起生效。
状态属性与状态分类的统计语义需要分开理解。分类决定“这个阶段算不算完成”，属性可以在此基础上补充“进入这个阶段时是否锁定编辑”“是否必须填写关闭原因”。属性不替代分类：即使某个状态值设置了“计入完成”的属性，统计口径仍应以分类归属为准，避免两套判断标准并存。
属性配置与流转规则、权限配置也有明确分工。流转规则规定阶段之间允许怎么走，属性规定停留在某阶段时的行为约束，权限规定谁能执行状态变更。三者可以配合，例如“已关闭”状态设置禁止编辑的属性，同时由权限控制只有特定角色能执行关闭动作，但任何一方都不能替代另一方。
不同平台对状态属性的支持范围存在差异，有的属性项丰富，有的只提供基础开关。具体平台提供哪些属性项，应以该平台的配置说明为准；本文列出的属性项属于通用类型，用于说明这一层配置的职责。
状态配置与工作流、看板列、权限的区别
状态配置与相邻概念容易混为一谈，区分它们有助于定位配置问题出在哪一层。状态配置定义阶段与语义，工作流定义阶段之间允许怎么走，看板列属于展示层，权限控制谁能改状态。
| 概念 | 负责什么 | 不负责什么 | 典型问题表现 |
|---|---|---|---|
| 状态配置 | 有哪些阶段、属于哪类、默认落在哪、有什么约束 | 阶段之间能否跳转 | 状态值缺失或分类归属错误 |
| 工作流 | 阶段之间的流转路径与触发条件 | 阶段本身的定义 | 想从“待处理”直接到“已关闭”却被拦截 |
| 看板列 | 按分类或状态值分组展示工作项 | 改变工作项的实际状态 | 拖动卡片后状态未变或列不对应 |
| 权限 | 谁能查看、编辑、变更状态 | 状态值是否存在 | 有权限的人看不到某个状态选项 |
看板列通常引用状态分类或状态值，属于展示层。列的分组方式变化不改变状态配置本身，但如果看板按分类分列，分类调整会直接改变列的构成。权限控制谁能改状态，与状态本身定义分开：权限不足表现为操作被拒绝，状态配置缺失表现为选项不存在，两者的排查方向不同。
旧状态配置的搬迁与迁移操作涉及数据映射和流程切换，属于迁移主题，本文不展开。
一个具体例子与常见误解
以缺陷工作项为例，可以把四类对象串起来看。状态值设为“待处理”“修复中”“验证中”“已关闭”“已拒绝”；状态分类把“待处理”归入待处理分类，“修复中”和“验证中”归入进行中分类，“已关闭”归入已完成分类，“已拒绝”可单独归入已关闭类或另设分类；默认状态设为新建缺陷自动落入“待处理”；状态属性方面，“已关闭”设置计入完成并禁止编辑，“已拒绝”要求填写拒绝原因，“验证中”触发通知给测试负责人。
在这个例子中，新建缺陷默认进入“待处理”，符合流程起点；“修复中”属于进行中分类，因此不会计入完成率；“已关闭”计入完成，同时锁定编辑，防止关闭后被随意改动。四类对象各司其职，任何一类配置缺失都会让流程出现断点。
常见误解有三类。第一类是把状态分类当成状态值，直接在新建表单里选择“进行中”，导致工作项没有具体落点，后续流转和统计都失去依据。第二类是把默认状态当成唯一入口，认为所有工作项只能从默认状态开始，忽略了流转规则允许的其他起点，配置排查时容易找错方向。第三类是用状态属性替代流转规则，例如希望通过“禁止编辑”属性阻止状态跳转，实际上属性约束的是编辑行为，阶段之间能否走由工作流决定。
把这四类对象的职责分清之后，状态配置的日常维护就有了检查顺序：先确认状态值与分类的对应关系，再检查默认落点是否符合流程起点，最后核对状态属性与流转规则、权限是否各就各位。在ONES这类研发管理平台中，工作项状态、状态分类与流转规则通常在同一套工作项配置体系内维护，团队可以按上述顺序梳理配置，让状态定义、统计口径和操作约束保持一致。
常见问题
状态值和状态分类可以只配一个吗？
两者承担不同职责，通常需要同时配置。状态值是工作项实际停留的落点，缺少状态值，新建和流转都没有可选项；状态分类是语义分组，缺少分类，看板列分组和完成率统计就失去统一口径。实践中可以精简状态值数量，但每个状态值仍应归入某个分类，否则统计时无法判断它属于待处理、进行中还是已完成。
新建工作项一创建就显示“已完成”，应该先查哪里？
优先检查默认状态与工作项类型的对应关系。常见原因是默认状态被设成了已完成分类下的某个状态值，或者不同工作项类型共用了同一个默认值。其次确认该工作项类型是否单独配置了默认落点。如果默认状态正确，再检查是否有自动化规则或流转动作在创建时自动推进了状态。
状态属性里设置了“计入完成”，还需要状态分类吗？
需要。状态分类是统计口径的统一依据，状态属性是单个状态值上的附加规则。如果只靠属性判断完成，不同状态值可能各自设置，容易出现两套标准并存；以分类归属为准，属性只补充编辑锁定、必填校验、通知等行为，统计口径更稳定。两者同时存在时，应明确以分类作为完成度判断的主口径。
想限制某个状态不能被随意修改，应该配状态属性还是权限？
两者解决不同问题。状态属性约束的是工作项处于该状态时的编辑行为，例如禁止编辑字段；权限约束的是谁能执行状态变更或编辑操作。如果目标是“关闭后内容不可改”，用状态属性更直接；如果目标是“只有测试负责人能关闭缺陷”，用权限控制。实际配置中两者可以配合，但排查问题时要分清是属性拦截还是权限拒绝。
调整状态分类会影响哪些已有配置？
分类被看板列、统计报表和流转条件引用，调整前应确认引用范围。常见影响包括：按分类分列的看板列构成变化、完成率等统计口径变化、以分类为条件的流转规则触发范围变化。状态值改名影响相对小，但按旧名称筛选的报表和看板条件可能失效；删除状态值则需要处理历史上处于该状态的工作项归属。
