研发平台字段配置要先把业务规则整理成字段清单，再在平台里创建字段、绑定到工作项类型和流程节点、按角色控制权限，最后用样例数据验证后放量。本文按“定规则—建字段—绑场景—控权限—验数据”五步展开，适合研发平台管理员和研发效能人员对照执行；字段的业务含义与取值范围由业务方确认，平台负责承载。
要点总览（TL;DR）
- 字段配置按“定规则—建字段—绑场景—控权限—验数据”五步推进，配置前先产出一份可评审的字段清单，明确字段名、编码、类型、取值范围、必填条件和适用工作项类型。
- 字段创建时先建枚举类字段、再建引用类字段、最后建关联字段；默认值只给有明确默认语义的字段，必填条件尽量限定到工作项类型或状态，避免全局必填。
- 字段要完成三层绑定：挂到对应工作项类型、放入表单分组并设置显示条件、在状态流转节点控制必填与只读，绑定关系逐条对应字段清单。
- 权限按角色配置而非按个人授权，先列角色再形成可见、可编辑、只读的权限矩阵，敏感字段单独控制访问范围。
- 上线前用样例数据验证创建、流转、查询、报表和权限五项，通过后再放量；上线后字段新增、修改、停用要有责任人和影响评估，枚举值变更优先停用旧值、新增新值。
先定规则：字段清单要写清哪些内容
字段配置的返工大多发生在配置阶段之前：同一个“严重程度”在缺陷和需求里含义不同，或者两个团队各建了一个“优先级”，导致报表口径对不上。配置前先产出一份可评审的字段清单，把业务规则固定下来，平台管理员再据此落地。
字段清单建议包含以下列，缺一列就可能在配置时临时拍板：
| 列名 | 填写要求 | 示例 |
|---|---|---|
| 字段名 | 面向使用者的显示名称，全平台统一叫法 | 缺陷严重程度 |
| 字段编码 | 系统内唯一标识，配置后尽量不改 | defect_severity |
| 业务含义 | 一句话说明该字段回答什么业务问题 | 判断缺陷对用户的影响范围 |
| 字段类型 | 文本、单选、多选、日期、数值、人员、关联 | 单选 |
| 取值范围 | 枚举值列表或数值区间、格式要求 | 致命、严重、一般、轻微 |
| 必填条件 | 在哪个工作项类型、哪个状态下必填 | 缺陷类型创建时必填 |
| 适用工作项类型 | 需求、任务、缺陷、工单等 | 缺陷 |
| 负责人 | 业务规则确认人与平台配置人 | 测试负责人确认，平台管理员配置 |
清单里要区分两类责任：业务含义、取值范围、必填条件由业务方确认并签字，平台管理员负责字段类型选择、编码规范和实际配置。评审时重点检查同义字段，例如“优先级”和“紧急度”如果业务上回答同一个问题，就合并为一个字段；确实要并存，就在业务含义列写清两者的判断差异。
命名与编码规范在清单阶段统一：显示名用业务语言，编码用小写英文加下划线，同一概念只保留一个字段。完成标志是清单通过业务方和管理员双方评审，后续配置不再新增未列入清单的字段。
在平台中建字段：类型、默认值与校验怎么设
进入平台字段管理后，按清单逐条创建字段。操作顺序建议先建枚举类字段，再建引用类字段，最后建关联字段，因为后建的字段可能依赖前面的选项或对象。
- 选择字段类型。文本用于描述性内容；单选用于互斥分级，如严重程度；多选用于可叠加的标签，如影响模块；日期用于计划与实际时间；数值用于工时、故事点；人员用于责任人、评审人；关联用于指向其他工作项或对象。
- 填写字段名与编码，编码按清单原样录入，避免配置时临时改名。
- 设置默认值。默认值只给有明确默认语义的字段，例如新建缺陷的严重程度默认“一般”；没有合理默认值的字段留空，避免默认值掩盖真实判断。
- 设置必填与校验。必填按清单中的条件设置，能限定到工作项类型或状态的就不要全局必填；数值字段设置合理区间，文本字段设置长度或格式要求，日期字段限制可选范围。
- 维护枚举值。选项顺序按业务严重程度排列，不要按录入先后排列；每个选项配一句说明，减少理解偏差。
枚举值后续变更要谨慎：新增选项通常安全，直接修改或删除旧选项会影响历史数据的可读性。建议停用旧选项、新增替代选项，并在字段说明里注明变更时间。字段创建完成后，用一条测试工作项确认类型、默认值和校验都按预期生效，再进入绑定环节。
绑定场景：工作项类型、表单布局与流转节点
字段建好只是存在于字段库中，要让它出现在具体业务场景里，需要完成三层绑定：工作项类型、表单布局、状态流转节点。
第一层是工作项类型。把字段挂到清单中列出的工作项类型上，例如“缺陷严重程度”只挂缺陷，不挂需求和任务。同一字段可以挂多个类型，但每个类型都要在清单中有对应记录，避免字段在无关类型上出现干扰填写。
第二层是表单布局。按填写习惯分组，例如把“严重程度、影响模块、复现概率”放在“缺陷评估”分组，把“责任人、计划修复日期”放在“处理安排”分组。顺序按填写先后排列，低频字段折叠或放到次要区域。需要按条件显示时，设置显示条件，例如选择“致命”后才显示“影响客户数”。
第三层是状态流转节点。在缺陷从“新建”流转到“处理中”时，把严重程度设为必填；在“已关闭”状态下设为只读，防止关闭后随意改动。流转节点的必填与可编辑控制要和清单中的必填条件逐条对应，形成一张绑定关系表：
| 字段 | 工作项类型 | 表单分组 | 状态节点控制 |
|---|---|---|---|
| 缺陷严重程度 | 缺陷 | 缺陷评估 | 新建时必填，关闭后只读 |
| 影响模块 | 缺陷 | 缺陷评估 | 处理中必填 |
| 计划修复日期 | 缺陷 | 处理安排 | 排期后必填 |
在ONES Project中，工作项支持自定义状态与多种属性，项目类型和相关组件也可按业务需求定义，字段绑定可以依托这套工作项与项目结构落地；工单场景同样支持自定义处理流程与字段配置。绑定完成后，分别用新建、流转、关闭三种操作检查字段的出现位置和必填提示。
权限与角色：谁可见、谁可改、谁审批
字段权限按角色配置，不按个人逐个授权，否则人员变动后维护成本会迅速上升。配置前先列出角色：提交人、处理人、测试负责人、项目管理员、只读干系人，再为每个角色标注字段的可见、可编辑、只读状态，形成权限矩阵。
| 字段 | 提交人 | 处理人 | 测试负责人 | 项目管理员 |
|---|---|---|---|---|
| 缺陷严重程度 | 可见可编辑 | 可见只读 | 可见可编辑 | 可见可编辑 |
| 影响客户数 | 不可见 | 可见可编辑 | 可见可编辑 | 可见可编辑 |
| 修复成本估算 | 不可见 | 可见可编辑 | 不可见 | 可见可编辑 |
敏感字段单独控制访问范围，例如涉及客户信息或成本数据的字段，只对特定角色开放可见权限。字段本身的变更也要有责任人：新增字段由业务方提出、平台管理员评估影响后配置；修改枚举值或必填条件由字段负责人审批，并通知受影响的团队。ONES Project提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把上述角色映射到平台已有的权限体系上；字段级权限的具体粒度以平台实际配置项为准，配置时逐项核对。
示例：一个缺陷严重程度字段的完整配置
以“缺陷严重程度”为例，走一遍从规则到上线的全过程。
规则阶段：测试负责人确认该字段回答“缺陷对用户的影响范围”，取值为致命、严重、一般、轻微四级，缺陷创建时必填，关闭后不允许修改，适用工作项类型为缺陷，字段编码定为defect_severity。
建字段阶段：在平台选择单选类型，录入四个选项并按影响程度排序，每个选项附一句判断说明；默认值设为“一般”；必填条件限定为缺陷类型创建时；不设置数值区间类校验。
绑定阶段：字段挂到缺陷类型，放入“缺陷评估”分组并排在影响模块之前；在“新建”到“处理中”的流转节点设为必填，在“已关闭”状态设为只读。
权限阶段：提交人可见可编辑，处理人可见只读，测试负责人可见可编辑，项目管理员可见可编辑，只读干系人可见只读。
验证阶段：新建一条测试缺陷，确认严重程度出现在评估分组且为必填；流转到处理中，确认必填校验生效；关闭后尝试修改，确认字段为只读；在筛选和报表中按严重程度分组，确认四个选项都能正确统计。全部通过后再对实际团队开放。
上线前校验与后续维护
配置完成不等于可以放量。上线前用样例数据走一遍完整链路，按清单逐项核对：
- 创建：字段出现在正确的工作项类型和表单分组，默认值符合预期，必填提示准确。
- 流转：各状态节点的必填与只读控制生效，条件显示字段按规则出现或隐藏。
- 查询：按字段筛选能返回正确结果，多条件组合筛选无异常。
- 报表：字段作为分组或统计维度时数据完整，枚举值没有遗漏或重复计数。
- 权限：用不同角色账号登录，确认可见、可编辑、只读与权限矩阵一致。
通过标准是上述五项全部符合清单和权限矩阵，且没有出现清单外的字段。发现问题回到对应环节修正，修正后重新走一遍受影响的检查项。
上线后建立维护规则：字段新增由业务方提出需求，平台管理员评估与现有字段是否重复、影响哪些工作项类型和报表；字段修改重点评估枚举值变更对历史数据的影响，优先采用停用旧值、新增新值的方式；字段停用前确认没有在用报表和自动化规则依赖它，停用后保留历史数据可读。每次变更记录变更人、时间、影响范围和验证结果，定期回看字段使用情况，清理长期无人填写的字段。ONES Automation支持自定义自动化规则并提供运行日志，字段变更若涉及自动化规则，可借助运行日志确认规则是否仍按预期执行。
常见问题
字段清单评审时，业务方和平台管理员各自要确认什么？
业务方确认字段的业务含义、取值范围和必填条件，也就是这个字段回答什么业务问题、有哪些可选值、在什么情况下必须填写；平台管理员确认字段类型是否合适、编码是否符合规范、是否与已有字段重复。评审时双方共同检查同义字段，业务上回答同一个问题的字段合并为一个，确实需要并存的在业务含义列写清判断差异。清单通过双方评审后再进入平台配置，后续不再新增清单外的字段。
枚举值需要调整时，直接改旧选项和停用旧选项有什么区别？
直接修改或删除旧选项会影响历史数据的可读性，已经使用旧选项的工作项在报表和详情里可能显示为空或含义错位。更稳妥的做法是停用旧选项、新增替代选项，并在字段说明里注明变更时间，这样历史数据仍能按原值读取，新数据使用新选项。如果确实要调整选项名称，先评估有多少在用报表和自动化规则引用了该选项，再决定变更方式。
字段在某个状态下设为只读后，发现填错了怎么处理？
只读控制针对的是常规编辑入口，填错后的修正应通过流程回退或专门的更正操作完成，而不是放开该状态的编辑权限。配置时可以把“关闭后只读”与“回退到处理中可编辑”配合使用：需要更正时先回退状态，修改后再重新流转。这样既保留了关闭状态的字段稳定性，也给更正留出通道。具体回退规则要和团队的状态流转设计一起确定。
多个团队对同一字段的取值范围有分歧，配置时怎么处理？
先判断分歧属于业务规则层面还是平台承载层面。取值范围本身由业务方确认，平台管理员不替业务方拍板；如果两个团队的判断标准确实不同，可以评估是否拆成两个字段并各自写明适用工作项类型，或者在选项说明里写清不同场景的判断口径。拆字段会增加报表维度，合并字段会牺牲部分区分度，取舍由业务方根据统计需求决定，平台侧负责按最终结论配置并保证编码唯一。
字段上线后长期没人填写，应该直接停用吗？
停用前先确认没有在用报表、筛选视图和自动化规则依赖该字段，停用后要保证历史数据仍可读。如果只是填写率低，可以先检查必填条件是否设置过宽、字段说明是否清楚、表单位置是否太靠后，调整后再观察一段时间。确认业务上不再需要该字段时，按维护流程停用并记录变更人、时间、影响范围和验证结果，定期回看字段使用情况，清理长期无人填写的字段。
