跨项目字段标准模板的核心是一张字段字典表：把字段标识、业务含义、数据类型、取值范围、必填与默认规则、统一口径、项目差异、责任人和变更记录放在同一套表头下，各项目按同一口径建字段。本文给出一份可直接复制填写的空白模板，逐列说明填写方法，区分必填与选填，并用一个完整示例演示落地过程，最后说明模板的调整与维护方式。字段标准需要在研发平台中承载时，可借助ONES的项目配置与文档版本管理能力保存和分发。
要点总览（TL;DR）
- 跨项目字段标准模板以字段字典主表为核心，配套取值与规则附表、变更记录附表，三张表通过“字段标识”关联。
- 主表应包含字段标识、业务名称、业务含义、数据类型、取值范围、必填与默认值、统一口径、项目级差异、适用项目范围、责任人、生效日期和状态。
- 字段标识、业务名称、业务含义、数据类型、必填、统一口径、责任人、状态为必填列；取值范围、默认值、项目级差异等按字段类型补充。
- 填写顺序为先登记统一口径，再补取值与枚举，然后登记项目差异，最后设定生效日期与状态并记录首次发布。
- 模板发布时同步确定维护机制：新增字段先查重、口径变更走评审与通知、废弃字段保留记录、按季度或月度评审使用情况。
可复制空白字段标准模板
模板由三张表组成：字段字典主表记录字段本身，取值与规则附表记录枚举值、校验和默认值，变更记录附表记录每次口径调整。三张表通过“字段标识”关联，复制到文档或表格工具后即可填写。
表一：字段字典主表
| 字段标识 | 业务名称 | 业务含义 | 数据类型 | 取值范围/单位/格式 | 必填 | 默认值 | 统一口径 | 项目级差异 | 适用项目范围 | 责任人 | 生效日期 | 状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
表二：字段取值与规则附表
| 字段标识 | 取值编码 | 取值名称 | 取值说明 | 是否允许新增 | 校验规则 | 关联字段 | 备注 |
|---|---|---|---|---|---|---|---|
表三：变更记录附表
| 变更编号 | 变更日期 | 字段标识 | 变更类型 | 变更前 | 变更后 | 影响项目 | 评审人 | 通知方式 | 生效日期 |
|---|---|---|---|---|---|---|---|---|---|
每个字段列的含义与填写口径
同一列在不同项目被理解成不同意思，是字段标准失效的常见原因。下表逐列说明填什么、怎么填，列名与上文空白模板保持一致。
| 列名 | 填写内容 | 填写口径 |
|---|---|---|
| 字段标识 | 系统内唯一的技术名称，如 req_priority |
使用英文小写加下划线，全平台唯一，创建后不随业务名称修改而变更 |
| 业务名称 | 界面上展示的中文名，如“需求优先级” | 面向业务人员，同一含义只保留一个名称，避免“优先级”“紧急程度”混用 |
| 业务含义 | 一句话说明该字段回答什么问题 | 写判断对象和用途，如“标识需求交付的紧急程度，用于排期排序”，不写实现方式 |
| 数据类型 | 文本、数值、日期、单选、多选、人员、布尔等 | 按平台实际支持的字段类型填写；类型决定后续校验方式，确定后变更成本较高 |
| 取值范围/单位/格式 | 枚举值清单、数值区间、日期格式 | 枚举值在附表展开；数值写明单位和精度，如“人天，保留一位小数”；日期统一为 YYYY-MM-DD |
| 必填 | 是/否 | 写“是”表示创建或流转到指定状态时必须填写，需与平台校验配置一致 |
| 默认值 | 未填写时系统带入的值 | 默认值必须落在取值范围内；无合理默认值时留空，不用“无”占位 |
| 统一口径 | 所有项目共同遵守的定义 | 写清判定标准和边界，如“P0 指影响线上主流程且无替代方案” |
| 项目级差异 | 某项目允许的偏离及原因 | 写“项目名＋差异内容＋原因”，如“项目A 增加‘合规评审’选项，因涉及外部审计” |
| 适用项目范围 | 全部项目或指定项目清单 | 默认“全部项目”；仅部分项目使用时列出项目名，避免范围含糊 |
| 责任人 | 对该字段口径负责的角色或人员 | 写岗位加姓名，如“研发效能负责人 张三”，便于口径争议时找到决策人 |
| 生效日期 | 该行规则开始执行的日期 | 与变更记录中的生效日期一致，历史数据按原口径保留 |
| 状态 | 草稿、生效、停用、废弃 | 只有“生效”状态的字段可用于新建项目；废弃字段保留记录供追溯 |
区分字段标识、业务名称和业务含义时，可以按“技术唯一、界面可读、语义可判”三层理解：标识供系统对接，名称供人识别，含义供判断口径。三者分开记录，后续改中文名不会影响接口和数据统计。
必填项、选填项与填写顺序
模板列多，但并非每列在首次登记时都要填满。建议把字段标识、业务名称、业务含义、数据类型、必填、统一口径、责任人、状态列为必填，其余按字段类型和项目情况补充。
| 类别 | 列名 | 缺失后果或适用情形 |
|---|---|---|
| 必填 | 字段标识、业务名称、业务含义、数据类型、必填、统一口径、责任人、状态 | 缺失会导致字段无法在平台创建、口径无法判断或无人对争议负责；缺统一口径时各项目会自行解释 |
| 选填 | 取值范围/单位/格式、默认值、项目级差异、适用项目范围、生效日期 | 枚举类字段必须补取值范围；有合理默认值时填写默认值；存在项目差异或分批上线时填写后三列 |
| 附表必填 | 字段标识、取值编码、取值名称 | 枚举字段缺取值编码会造成各项目自建选项、统计口径分裂 |
| 变更记录必填 | 变更编号、变更日期、字段标识、变更类型、评审人、生效日期 | 缺记录时无法追溯口径何时变化、由谁批准 |
填写顺序建议分四步：
- 先由字段责任人在主表登记统一口径，只填必填列，形成待评审清单。
- 评审通过后补充取值范围、默认值和附表枚举值，确保取值编码唯一。
- 再逐项目登记差异，差异必须写明原因和适用项目范围，不能只写“按项目习惯”。
- 最后统一填写生效日期和状态，并在变更记录中登记首次发布。
先定统一口径再登记差异，可以避免项目差异反过来稀释标准；如果先收集各项目现状再合并，容易把历史习惯固化成“标准”。
一份填好的跨项目字段示例
以下示例演示一个通用字段和一个存在项目差异的字段，表头与空白模板一致。
主表示例
| 字段标识 | 业务名称 | 业务含义 | 数据类型 | 取值范围/单位/格式 | 必填 | 默认值 | 统一口径 | 项目级差异 | 适用项目范围 | 责任人 | 生效日期 | 状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| req_priority | 需求优先级 | 标识需求交付的紧急程度，用于排期排序 | 单选 | P0/P1/P2/P3，见附表 | 是 | P2 | P0 指影响线上主流程且无替代方案；P1 指影响核心功能但有临时绕行方案；P2、P3 依次降低 | 无 | 全部项目 | 研发效能负责人 张三 | 2025-03-01 | 生效 |
| req_compliance_review | 合规评审结论 | 记录需求是否通过合规评审及结论 | 单选 | 通过/有条件通过/不通过 | 否 | 空 | 仅涉及外部数据或第三方合作的需求需要填写 | 项目A 设为必填，因涉及外部审计；其他项目选填 | 全部项目（项目A 必填） | 合规负责人 李四 | 2025-04-15 | 生效 |
取值与规则附表示例
| 字段标识 | 取值编码 | 取值名称 | 取值说明 | 是否允许新增 | 校验规则 | 关联字段 | 备注 |
|---|---|---|---|---|---|---|---|
| req_priority | P0 | 最高 | 影响线上主流程且无替代方案 | 否 | 选 P0 时须填写影响范围说明 | 影响范围 | 需当日响应 |
| req_priority | P1 | 高 | 影响核心功能但有临时绕行方案 | 否 | — | — | — |
| req_priority | P2 | 中 | 常规迭代需求 | 否 | — | — | 默认值 |
| req_priority | P3 | 低 | 可延后处理 | 否 | — | — | — |
| req_compliance_review | PASS | 通过 | 评审无遗留问题 | 否 | — | — | — |
| req_compliance_review | COND | 有条件通过 | 需完成整改项后放行 | 否 | 须填写整改项 | 整改项 | — |
| req_compliance_review | FAIL | 不通过 | 存在合规风险，不得上线 | 否 | — | — | — |
变更记录示例
| 变更编号 | 变更日期 | 字段标识 | 变更类型 | 变更前 | 变更后 | 影响项目 | 评审人 | 通知方式 | 生效日期 |
|---|---|---|---|---|---|---|---|---|---|
| CR-001 | 2025-03-01 | req_priority | 首次发布 | — | P0–P3 四级口径 | 全部项目 | 张三 | 平台公告＋项目群通知 | 2025-03-01 |
| CR-002 | 2025-04-10 | req_compliance_review | 新增字段 | — | 新增合规评审结论字段 | 全部项目，项目A 必填 | 李四 | 评审会＋文档更新 | 2025-04-15 |
示例中的字段标识、取值编码和变更编号在模板、说明和示例中保持一致，复制使用时替换为组织自己的命名即可。字段标准确定后，需要在研发平台中落地为工作项字段、选项集和必填校验；ONES 支持在项目配置中管理字段与自动化规则，ONES Wiki 的页面模板库可用于固化字段字典文档，版本记录便于追溯口径调整。
模板的调整与长期维护方法
字段标准会随业务变化调整，维护机制要在模板发布时一并确定，否则半年后容易出现同一字段多套口径。
新增字段与新增项目的接入
- 新增字段先查主表是否已有同义字段，能复用则复用，避免“优先级”和“紧急度”并存。
- 新字段按“标识—含义—类型—口径—责任人”顺序登记，评审通过后状态改为“生效”，再在平台中创建。
- 新增项目接入时，默认继承全部生效字段；确需差异的，在“项目级差异”列登记原因和范围，不另建一套字段表。
口径变更的评审与通知流程
- 提出变更：由字段责任人或项目负责人提交变更申请，写明变更前后内容和影响项目。
- 评审：涉及多项目共用的字段，由字段责任人组织相关项目负责人评审；只影响单项目的差异，可由该项目负责人确认后登记。
- 通知与生效：通过后在变更记录附表登记，通过平台公告和项目群通知，设定生效日期，历史数据按原口径保留。
版本管理与废弃字段处理
- 模板按版本号管理，如 V1.0、V1.1，每次发布保留完整快照，便于对照历史口径。
- 字段停用时状态改为“废弃”，保留标识和变更记录，不在平台中直接删除，避免历史报表断链。
- 建议每季度评审一次字段使用情况，清理长期无人填写或取值高度集中的字段；组织规模较大、项目类型差异明显时，可缩短为每月一次。
维护责任建议落到单一角色：字段字典由研发效能或平台治理负责人统一维护，各项目指定字段对接人。模板文档可放在 ONES Wiki 中，利用页面模板库保持格式统一，借助版本记录查看和回滚历史版本，并按角色配置读写权限，让字段责任人有编辑权、项目成员以查阅为主。
常见问题
字段标准模板里的“统一口径”和“项目级差异”应该写到什么颗粒度？
统一口径写到能直接判断的程度：说明判定对象、边界和例外，例如“P0 指影响线上主流程且无替代方案”，让不同项目的负责人在同一情形下得出相同结论。项目级差异写到“项目名＋差异内容＋原因”三要素，例如“项目A 将合规评审结论设为必填，因涉及外部审计”。差异只记录偏离统一口径的部分，与统一口径相同的项目不必逐条登记，避免附表膨胀成项目清单。
已有项目已经各自建了字段，模板上线后如何处理存量差异？
建议把存量差异当作“项目级差异”登记，而不是一次性强制对齐。先按统一口径梳理出共用字段，再逐项目比对现有字段，能映射到统一字段的做映射，确有业务原因的登记差异和原因，并设定收敛计划。历史数据按原口径保留，新数据按新口径录入。存量字段的搬迁与配置迁移属于平台迁移工作，需要单独安排，不宜混在字段标准模板的首次发布里。
字段标准模板需要和平台配置保持什么关系？
模板是口径来源，平台配置是执行手段，两者要保持一致：模板中标记为必填的字段，平台侧应有对应的必填校验；附表中的枚举值应与平台选项集一一对应；状态为“废弃”的字段不应再出现在新建项目的可选字段中。字段标准确定后，需要在研发平台中落地为工作项字段、选项集和校验规则。ONES 支持在项目配置中管理字段与自动化规则，ONES Wiki 的页面模板库可用于固化字段字典文档，版本记录便于追溯口径调整。
字段字典文档放在哪里，谁能改？
建议放在团队共用的知识库中，由字段责任人维护，项目成员以查阅为主。ONES Wiki 支持为多种角色配置不同的读写权限，页面模板库可保持字段字典格式统一，版本记录便于查看和回滚历史口径。文档位置确定后应在模板中写明链接，避免出现多个副本各自更新。
字段数量很多时，模板会不会变得难以维护？
字段多时按使用范围分层维护：全部项目共用的核心字段放主表重点维护，仅少数项目使用的字段可在主表登记后由对应项目自行跟进取值细节。每季度评审一次字段使用情况，清理长期无人填写或取值高度集中的字段；项目类型差异明显、字段变更频繁时，可缩短为每月评审。分层和评审节奏都要在模板发布时写清楚，避免字段只增不减。
