字段字典发布后各项目仍自行改字段，说明字典目前只停留在文档约定，平台侧还没有形成约束。要处理命名冲突和口径漂移，先别急着发通知重申规范，而应把平台实际字段配置与字典逐项比对，查清偏差分布，再用证据确认项目能绕开字典的原因，最后收敛字段变更入口、合并重复字段、下线废弃字段，并用同一份字典验证恢复效果。
要点总览（TL;DR）
- 字段字典发布后仍被绕过，先做偏差盘点：把平台实际字段配置、字典版本、各项目在用字段三方对齐，按命名冲突、口径漂移、废弃残留分类归档。
- 原因排查用假设与证据对照：字段创建记录验证是否允许自建，变更审批记录验证入口是否收敛，配置比对时间线验证字典与平台是否同步，找不到证据的假设保留待验证。
- 处置按先冻结、再评审、后合并与下线的顺序推进，合并和停用前确认引用方、备份配置、设定停止点。
- 恢复验证用同一份字典重新比对，命名冲突与废弃残留归零或受控，并抽查关键字段取值口径；按月或按季度核对、变更留痕、字典与平台版本对应防止复发。
先确认偏差范围:哪些字段真的偏离了字典
“各项目乱改字段”是一个笼统印象，直接据此整改容易误伤正常配置。第一步要把印象拆成可核对的偏差清单：同一业务含义在不同项目出现多个字段名，属于命名冲突；字段名相同但各项目取值定义、枚举范围不一致，属于口径漂移；字典中已标记废弃的字段仍在项目配置或报表中被引用，属于废弃残留。三类偏差的判定依据不同，后续处置动作也不同，盘点时就要分开归档。
盘点范围覆盖三个来源：平台侧导出的全部字段配置，包括字段名、类型、枚举值、所属项目与创建人；当前生效的字典版本及其历史版本；各项目实际在用的字段，可通过工作项配置、报表和接口调用记录交叉确认。只比对字典与平台配置，会漏掉项目私下新建但未上报的字段；只看项目使用情况，又无法判断哪些字段偏离了字典定义。三个来源对齐后，偏差才有完整视图。
盘点结果建议整理成一张偏差盘点表，每行对应一个字段在一个项目中的实际状态，便于后续逐项处置和复核。
| 字段名 | 所属项目 | 字典定义 | 实际配置 | 偏差类型 | 引用方 |
|---|---|---|---|---|---|
| 客户等级 | 项目A | 枚举：A/B/C | 枚举：高/中/低 | 口径漂移 | 报表、看板 |
| 客户级别 | 项目B | 字典字段为“客户等级” | 自建同义字段 | 命名冲突 | 工作项、自动化规则 |
| 旧合同编号 | 项目C | 已标记废弃 | 仍可编辑并出现在筛选项 | 废弃残留 | 历史工作项 |
这张表的完成标志是：每个偏差字段都能对应到具体项目、字典条目和引用位置，没有“大概”“可能”这类模糊记录。盘点阶段只做范围界定和分类，不急于下原因结论，也不开始改配置。
偏差为什么反复出现:原因假设与排除证据
字典发布后仍被绕过，常见原因有三类，但每一类都需要证据支撑，不能凭经验直接定性。把假设和证据分开记录，可以避免把管理缺位误判成工具问题，也能防止在工具上做了限制、实际流程仍然绕行。
假设一：平台未限制项目自建字段，字典只是文档约定。验证方式是查看字段创建记录：偏差字段由谁、在哪个项目、通过什么入口创建。如果大量字段由项目管理员在平台内直接新建，且创建时没有引用字典或触发任何校验，这条假设成立。如果字段创建集中在少数几次批量配置，则更可能是历史遗留而非持续绕过。
假设二：字段变更没有统一入口和审批，项目按需直接改。验证方式是调取变更审批记录，确认字段新增、改名、改枚举值是否经过评审。若平台内存在修改入口但无审批环节，或审批在平台外以聊天、邮件完成且未回写记录，说明变更入口没有真正收敛。这条假设与假设一相关但不同：前者问“能不能改”，后者问“改的时候有没有把关”。
假设三：字典与平台配置未同步，发布后无人核对。验证方式是比对字典版本与平台配置的时间线：字典更新后，平台配置是否在合理时间内跟进；平台出现新字段后，字典是否补充登记。若两边长期各走各的，偏差会随项目增多持续累积。
| 原因假设 | 验证证据 | 判定标准 | 状态 |
|---|---|---|---|
| 平台未限制项目自建字段 | 字段创建记录、创建入口 | 偏差字段多由项目侧直接新建且无校验 | 待验证 |
| 变更无统一入口和审批 | 变更审批记录、修改操作日志 | 字段修改无评审记录或评审未回写 | 待验证 |
| 字典与平台配置未同步 | 字典版本时间线、配置比对结果 | 字典更新后平台长期未跟进，或新字段未登记 | 待验证 |
排除方法是一条假设对应一类证据，逐条标注“已证实”“已排除”或“待验证”。找不到证据的假设保留待验证状态，不用推测补位。三类原因可能同时存在，处置时按影响面排序，优先处理能解释大部分偏差的那一条。
处置步骤:收敛变更入口并统一口径
处置顺序遵循先冻结、再评审、后合并与下线。先冻结可以止住新增偏差，为后续清理争取稳定环境；先合并再评审，则可能在口径未定的情况下反复改动，扩大影响面。
第一步，冻结字段新增权限，项目侧改为提交字段申请。在平台权限配置中收回项目管理员直接新建字段的权限，保留查看和使用权限。项目有字段需求时，通过统一表单提交申请，写明业务含义、使用场景、期望类型与枚举值、涉及项目。冻结范围要提前公告，给出申请通道和响应时限，避免项目因无法配置而阻塞业务。这一步的完成标志是：平台内不再出现未经申请的新字段。
第二步，建立字段评审，判断复用还是新增。评审由字典维护方牵头，业务方和平台管理员参与。评审先查字典中是否已有同义或近义字段，能复用则复用，并明确该项目如何使用；确需新增的，先确定命名规则和取值口径，再纳入字典，由平台统一配置。评审结论要回写到申请单，形成可追溯的记录。评审节奏可以按周固定，紧急需求走加急通道，但同样留记录。
第三步，合并重复字段并做数据映射。对命名冲突类偏差，确定保留字段和待合并字段，建立旧值到新值的映射关系，明确枚举值如何对应、空值如何处理。迁移前备份相关项目配置和历史数据，先在一个项目试迁移，核对工作项、报表、自动化规则中的引用是否正常，再分批推广。合并期间设置停止点：一旦发现映射遗漏或报表口径异常，暂停后续批次，回退到备份状态再排查。
第四步，废弃字段标记停用并设定下线时间。废弃残留字段先改为只读，保留一段过渡期供历史查询，同时通知引用方在期限内完成替换。过渡期结束后停用字段，并从筛选项、报表模板和接口文档中移除。停用前确认没有活跃的自动化规则或外部集成依赖该字段，涉及历史数据的字段先归档再停用。
- 风险检查点一：合并与停用前确认全部引用方，包括报表、看板、自动化规则、接口和外部系统。
- 风险检查点二：涉及历史数据的操作先备份配置和数据，记录备份时间与恢复方式。
- 风险检查点三：每批操作设定停止点，出现异常立即暂停并回退，不带着问题继续推进。
- 风险检查点四：冻结权限前先开通申请通道并公告，避免业务中断引发项目绕过流程。
在平台承载上，字段规则的落地需要配置能力与权限控制配合。ONES Project 支持自定义需求状态与多种属性，并具备产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把字段配置权限收归平台管理方、项目侧保留使用权限；其组件化设计支持按业务需求定义项目类型与相关组件，可作为字段规则按项目类型统一承载的基础。字段级的新增与修改权限、字段变更审批流、字段合并与下线机制是否能在平台内直接实现，官网资料未作说明，需要在实际配置中核验，必要时用申请表单加人工评审补足。
验证恢复与防止复发
处置完成后，用同一份字典重新比对平台字段配置，确认命名冲突数量、废弃残留数量归零或处于受控范围。受控是指剩余偏差已登记在案、有明确处置时间和责任人，而非放任不管。比对结果与处置前的盘点表对照，能直观看出收敛程度。
口径验证不能只看字段名，要抽查关键字段在各项目的取值定义是否一致。抽查对象优先选跨项目报表和经营分析中高频使用的字段，逐项核对枚举值、默认值和必填规则。发现不一致的，回到评审环节确认是字典需要更新，还是项目配置需要纠正。
| 核对项 | 核对方式 | 通过标准 | 责任人 |
|---|---|---|---|
| 命名冲突 | 平台字段导出与字典逐项比对 | 无未登记的同义字段 | 字典维护方 |
| 口径一致性 | 抽查关键字段的枚举与默认值 | 各项目取值定义与字典一致 | 业务方与平台管理员 |
| 废弃残留 | 检查筛选项、报表、接口引用 | 废弃字段已停用或无活跃引用 | 平台管理员 |
| 变更留痕 | 抽查申请单与评审记录 | 每次字段变更可追溯到申请与结论 | 评审牵头方 |
防止复发依靠三项机制。其一是定期核对：按月或按季度将平台字段配置与字典比对一次，新字段必须登记入字典，字典更新必须同步到平台，核对结果留档。其二是变更留痕：字段申请、评审结论、配置操作都保留记录，便于事后追溯谁在何时改了哪个字段。其三是版本对应：字典版本与平台配置版本建立对应关系，字典升版时明确平台侧的生效时间和影响项目。
责任分工要落到具体角色：字典维护方负责字典内容的准确与版本管理，评审牵头方负责变更申请的受理与结论，平台管理员负责配置执行与权限控制，业务方负责提出需求和确认口径。核对机制的执行人建议与配置执行人分开，形成相互校验。三项机制运行一段时间后，再用偏差盘点表复查一次，确认新增偏差持续处于低位，处置才算真正闭环。
常见问题
项目提出字段需求很急，冻结新增权限后怎么避免阻塞业务？
冻结权限前先开通申请通道并公告，明确申请表单、响应时限和加急路径。紧急需求走加急评审，评审结论同样回写申请单。冻结收回的是项目管理员直接新建字段的权限，查看和使用权限保留，项目日常操作不受影响。若申请通道尚未就绪就冻结，项目容易绕开流程私下配置，反而增加后续清理成本。
合并重复字段时，历史工作项里的旧值怎么处理？
先建立旧值到新值的映射关系，明确枚举值如何对应、空值如何处理，再备份相关项目配置和历史数据。迁移先在一个项目试点，核对工作项、报表、自动化规则中的引用是否正常，再分批推广。历史数据建议保留映射记录，便于追溯原值；每批操作设定停止点，发现映射遗漏或报表口径异常立即暂停并回退。
废弃字段停用后，外部系统或接口仍在调用怎么办？
停用前先梳理全部引用方，包括报表、看板、自动化规则、接口和外部系统，通知引用方在过渡期内完成替换。过渡期内字段改为只读，保留历史查询能力。对确有外部依赖的字段，先与对接方确认替换方案和切换时间，再执行停用；涉及历史数据的字段先归档再停用。
字典维护方和平台管理员由同一人担任可以吗？
可以，但核对机制的执行人建议与配置执行人分开，形成相互校验。字典维护方负责内容准确与版本管理，平台管理员负责配置执行与权限控制，评审牵头方负责变更受理与结论。角色合并时，至少把定期核对交给另一方执行，避免自己核对自己配置的情况。
ONES 能否在平台内直接实现字段变更审批和字段下线？
ONES Project 支持自定义需求状态与多种属性，具备产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，组件化设计支持按业务需求定义项目类型与相关组件，可作为字段配置权限收归平台管理方的基础。字段级的新增与修改权限、字段变更审批流、字段合并与下线机制是否能在平台内直接实现，官网资料未作说明，需要在实际配置中核验，必要时用申请表单加人工评审补足。
