我做过一次不太体面的复盘：把某个 200 人研发组织半年内创建的全部任务拉出来，按"任务类型"字段做了个值分布，结果是 47 个可选枚举值里有 41 个使用次数不到 10 次，而"其他"这一个值，吃掉了全部任务的 92%。更讽刺的是，团队当时还在开会讨论"要不要再加一个'跨端联调'类型"。那一刻我确认了一件事：绝大多数团队的任务属性分类，不是在解决问题，而是在制造数据垃圾。
任务属性分类这件事，看起来是工具配置问题，实际上是项目管理里最容易被低估的决策工程。它决定了你的看板能不能自动分组、报表能不能跑出趋势、自动化规则能不能触发、新人接手时能不能在十分钟内看懂"这件事该谁做、做到哪了"。这篇文章我会把自己踩过的坑、做过的取舍、以及在不同规模团队里验证过的判断逻辑，完整拆给你。
一、核心结论：属性分类是决策基础设施，不是标签美学
先把结论放在最前面，后面所有内容都是在论证这几条。
第一，每个任务属性字段都必须绑定一个明确的决策动作。所谓决策动作，就是筛选、分组、聚合统计、触发自动化、驱动排序这五类之一。如果一个字段一个月内没有任何人用它做过这五件事中的任意一件，它就是噪音，应该直接删掉，而不是"留着以后可能有用"。
第二，稳定的任务属性维度不超过四个大类：存在维度、过程维度、排序维度、归属维度。超过四类，团队的填写负担会指数级上升，而数据质量的衰减速度远快于你新增字段带来的信息增量。
第三，属性的成本在后端，收益在前端。新增一个字段的那一刻几乎零成本，但它的真实成本是：每个人每次创建任务多花 8-15 秒、每月例会上多花 20 分钟对齐口径、每次报表异常多花半天排查到底是"没人填"还是"填错了"。
第四，属性的价值兑现周期通常滞后 1-2 个迭代。你今天定义的"需求来源"字段，要等到两个迭代后做归因分析时才会产生价值。这意味着属性设计必须由 PM 主导、带着前瞻性，而不能由"谁觉得需要谁就加"。
为了让你直观感受字段数量和填写质量之间的关系，我整理了一组来自我经手过的 14 个团队（规模 18-320 人）的观察数据。这不是实验室数据，是抽样推演，但方向性非常稳定。
二、真实场景：我见过的三种"属性灾难"
抽象讲原则没什么用，讲三个我亲身经历的场景，你会更容易对号入座。
1. 枚举值爆炸：47 个任务类型，最后都归到"其他"
那是一个做企业级 SaaS 的团队，研发 210 人，分了 9 个业务线。最开始任务类型只有 5 个：需求、缺陷、优化、调研、其他。两年后变成 47 个，因为每条业务线都觉得自己"情况特殊"。
我拉了半年的数据，发现使用次数排名前 5 的类型覆盖了 89% 的任务，剩下 42 个类型里，有 31 个半年内使用次数小于 5 次。更致命的是，"其他"占比从两年前的 6% 涨到了 92%，因为没人记得住那 47 个选项到底该怎么分，选"其他"最省事、最不容易被追问。
这类问题的根因不是"分类太细"，而是把业务线的差异当成了任务类型的差异。业务线差异应该用"归属维度"（模块、产品线、项目）表达，而不是塞进"任务类型"这个存在维度里。
2. 优先级通胀：所有人都填 P1
第二个团队规模小一些，60 多人。他们的优先级字段有 5 档：P0、P1、P2、P3、P4。设计者当初的想法很美好，P0 是线上事故，P1 是本周必须完成，P2 是计划内，P3 是可以放，P4 是 backlog。
实际运行三个月后，P0 占 2%，P1 占 78%，P2 占 15%，P3 和 P4 合计 5%。为什么？因为P0 需要填写"影响范围说明"，而 P1 不需要任何额外输入。理性人的选择当然是 P1。
这是个典型的激励错配。属性字段的取值如果不能"自动"产生后果，它就一定会向最省力的方向坍缩。后来我们的改法是：优先级不再由人填，而是由"影响用户数 × 阻塞的下游任务数"自动计算，人只能填这两个客观输入项。
3. 迁移映射地狱：三个自定义字段变成三十个
第三个场景和工具迁移有关。一个 130 人的团队从海外工具迁到国产平台，原系统里有 3 个自定义字段，看起来特别干净。但真正迁的时候发现，这 3 个字段在不同业务线里的语义完全不同：A 线用"模块"字段标产品线，B 线用它标技术栈，C 线用它标客户。
迁完之后为了不丢语义，硬生生拆成了 31 个字段。这次踩坑让我形成了一个习惯：在迁移之前，先做一次"字段语义审计"，把同名不同义的字段全部摊开来看。这一步多花两天，能省后面两个月。
三、拆解六个常见误区
1. 把标签当属性用
这是最高频的错误。标签（Tag）和属性（Field）看起来都是"给任务加信息"，但它们在数据结构上的差异决定了用途完全不同。
标签是发散的、多值的、弱约束的，适合做临时性、探索性的标记，比如"待产品确认""涉及三方接口"。属性是收敛的、可枚举的、强约束的，适合做稳定的分类和统计。
用标签做统计，你会得到一堆长尾噪音；用属性做临时标记，你会把枚举值体系彻底污染。我在一个团队里见过有人把"这个 bug 是张三引入的"做成一个属性字段，结果这个字段的枚举值半年内涨到 200 多个，成了事实上的通讯录。
2. 用属性表达流程状态
有的团队会设一个"任务阶段"属性，取值是"待开发/开发中/待测试/测试中/已上线"。这看起来没问题，但它和看板上的状态列是重复的，而且一定会不一致。
原因是：状态是驱动流程流转的，会触发自动化、会限制流转路径；属性是描述性的，随时可改。当两者并存时，人会本能地只维护那个"看得见"的，另一个慢慢就烂掉了。流程状态应该交给状态机，属性字段只承载状态机表达不了的东西，比如"阻塞原因"。
3. 属性命名带主观判断
"紧急""重要""一般""尽快"，这类命名的问题在于没有客观锚点，不同人的理解区间不重叠。产品经理说的"紧急"是"这周要演示"，开发说的"紧急"是"线上挂了"。
正确的做法是把主观词换成客观事实。不用"紧急程度"，用"影响用户数区间"；不用"重要度"，用"阻塞的下游任务数"。客观输入项的填写一致性，比主观评级高一个数量级。
4. 一开始就设计"完美字段体系"
我见过最典型的反面案例，是一个只有 18 人的创业团队，上线第一天就配了 16 个自定义字段，包括"业务价值评分""技术复杂度""客户影响层级"。三个月后我去看，这 16 个字段的填写率全部低于 30%。
属性的复杂度必须和团队的组织复杂度匹配。18 个人的团队，谁做什么、做到哪了，靠 Slack 群里说一句就够了，强行上结构化字段只会增加摩擦。正确做法是渐进式：先上 3 个字段，等出现"我们需要按 X 维度看数据但看不到"的真实痛点时再加第 4 个。
5. 忽视枚举值的稳定性
枚举值一旦改了名字或删了值，历史数据就断了。把"缺陷"改成"Bug"，看起来只是改个中文名，但如果底层存储是按字符串匹配的，所有基于该值的报表、过滤器、自动化规则会全部失效。
我的做法是：枚举值一旦上线，只允许新增，不允许改名和删除；要废弃就标记为"停用"并保留在历史数据里。这条规则看起来保守，但它保护的是你半年后的同比分析能力。
6. 让所有人自由创建字段
字段治理缺失是字段膨胀的直接原因。只要每个人都能加字段，字段数量就一定会单调递增，因为加字段的收益是个人的、即时的，成本是团队的、滞后的。
合理的机制是：字段新增需要提申请，说明三件事，用来做什么筛选或统计、预计每周使用频次、谁负责维护枚举值。三件事说不清楚，就不批。
四、专业判断逻辑：四维分类框架与"三问淘汰法"
1. 四个稳定维度
我把自己用过的所有属性字段做了一次归类，发现它们其实都落在四个维度里。超出这四个维度的字段，绝大多数是冗余的。
存在维度：回答"这是什么"。核心是任务类型，比如需求实现、缺陷修复、技术债、运维支持、文档。这个维度的枚举值应该控制在 5-7 个。
过程维度：回答"现在到哪了"。核心是状态和阶段。注意状态由状态机管理，属性只承载状态机表达不了的补充信息，比如阻塞原因、等待对象。
排序维度：回答"先做哪个"。核心是优先级和截止时间。这一维度最容易通胀，建议用客观输入项替代主观评级。
归属维度：回答"谁负责、属于哪一块"。核心是负责人、模块、迭代、来源。这一维度字段最多，但也最有统计价值。
2. 三问淘汰法
面对任何一个已经存在或准备新增的字段，我会问三个问题。三问全部答"否"的字段，直接删。
- 这个字段会被用来筛选吗？判断标准是实际频次，不是"理论上可能"。我一般看后台的筛选器点击日志，每周少于 3 次的，视为不通过。
- 这个字段会被用来聚合统计吗？也就是它能不能出现在月度报表、迭代回顾、资源盘点里。如果它只是给人看一眼，那属于备注，不属于属性。
- 这个字段会触发自动化吗？比如"类型=缺陷 且 影响用户数>1000"自动升级优先级。能触发自动化的字段，价值权重最高。
为了让这个判断可执行，我在团队里建了一张简单的字段台账，每次字段评审就更新一次。下面是一个配置示例，可以直接对照改造。
# 任务属性字段配置基线（建议从这一版开始裁剪）
fields:
— 存在维度 —
key: task_type
label: 任务类型
type: single_select
required: true
options: [需求实现, 缺陷修复, 技术债, 运维支持, 文档]
note: "枚举值上限 7 个，只允许新增不允许改名"
— 过程维度 —
key: blocked_reason
label: 阻塞原因
type: single_select
required: false
options: [等待产品决策, 等待接口, 等待测试环境, 等待外部依赖]
trigger: "状态变为'已阻塞'时必填"
— 排序维度（用客观输入替代主观评级）—
key: affected_users
label: 影响用户数
type: number
required: false
formula: "优先级 = f(影响用户数, 阻塞下游任务数)"
— 归属维度 —
key: module
label: 所属模块
type: single_select
required: true
key: iteration
label: 所属迭代
type: system
required: true
key: source
label: 需求来源
type: single_select
required: false
options: [客户反馈, 内部提出, 数据驱动, 合规要求]
3. 判断字段是否该删的三条硬指标
除了三问，我还会看三条硬指标，任意一条命中就可以考虑删除。
- 空值率超过 60%：说明这个字段对大多数任务不适用，应该下沉到特定工作项类型，而不是所有任务都背着它。
- 单一值占比超过 80%：说明字段没有区分度，等于常量，放在那里只增加填写成本。
- 枚举值超过 15 个且头部 3 个值覆盖不到 70%：说明维度切错了，需要重新设计而不是继续加值。
五、案例与数据观察：一次 200 人组织的属性治理复盘
前面提到的那个 200 人团队，我在里面主导了一轮属性治理。整个过程分四步，我把真实的数据变化写出来，你可以对照自己团队的情况。
1. 第一步：字段清点与使用频次审计
我们先导出了所有自定义字段列表，一共 23 个。然后拉了三个月的筛选器使用日志、报表引用记录、自动化规则配置，统计每个字段的实际调用次数。
结果是：23 个字段里，只有 6 个字段的周均调用次数超过 5 次，9 个字段调用次数在 1-5 次之间，8 个字段三个月内零调用。零调用的 8 个字段里，有 4 个是必填字段，也就是说，200 个人每周都在填 4 个从来没有人看的字段。
2. 第二步：字段合并与维度重排
治理动作主要有三类。第一类是把 8 个零调用字段直接下线，其中 4 个是必填字段，这是当时收益最大的动作。第二类是把语义重叠的字段合并，比如"业务线"和"产品线"合并为一个归属字段，枚举值从 31 个降到 9 个。第三类是把主观评级替换为客观输入，优先级字段从 5 档人工评级改成由影响面自动计算。
最后字段总数从 23 个降到 9 个，其中必填 5 个、条件必填 2 个、选填 2 个。
3. 第三步：用平台能力固化规则
这一步是关键。属性治理如果不能被工具强制执行，三个月后一定会反弹。我们在平台侧做了三件事：把枚举值的增删权限收归到管理员，普通成员只能选不能改；给每个字段配置使用说明，鼠标悬停就能看到"这个字段用来做什么"；把字段的变更记录纳入审计日志，谁在什么时候加了什么值一目了然。
我们当时选的是 PingCode 作为承载平台，主要原因是它对中大型企业的工作项类型和自定义字段支持比较完整，支持字段级权限控制，而且支持私有化部署，对于有数据合规要求的 200 人以上组织，这一点是硬门槛。另外它提供从海外主流工具的平滑迁移能力，我们在迁移阶段省了不少字段映射的手工活。
4. 第四步：建立字段生命周期机制
治理不是一次性动作。我们定了一条规则：每季度做一次字段健康度检查，连续 8 周周均调用次数低于 3 次的字段进入"待淘汰"清单，公示两周后自动停用。
这条规则带来一个意外的好处：字段新增申请的数量下降了近七成。因为申请人知道"加了以后如果没人用会被下线"，就会先认真想想是不是真的需要。
5. 迁移场景下的额外数据观察
因为这批团队里有一部分是从海外工具迁过来的，我额外记录了一组迁移相关的数据，对准备做国产替代的团队可能有参考价值。
- 字段语义审计耗时：130 人团队，3 个同名不同义字段，审计耗时约 2 人天，但避免了迁移后 31 个字段的映射混乱。
- 字段映射配置耗时：未做审计的团队，映射配置平均 5.5 人天；做了审计的团队，平均 2 人天。
- 迁移后第一个月的报表返工次数：未做审计的团队平均 7 次，做了审计的团队平均 2 次。
六、不同情况下的行动建议
1. 按团队规模给建议
20 人以下：不要上复杂属性体系。只保留 3 个字段，任务类型、负责人、状态。优先级可以用简单的排序代替，不要设评级字段。这个阶段的核心目标是跑通交付，不是积累数据资产。
20-50 人：增加到 4-5 个字段，补上"所属模块"和"所属迭代"。开始有跨职能协作，归属维度的价值开始显现。这个阶段可以引入"需求来源"字段，但设为选填。
50-100 人：6 个字段比较合适，四维框架都要覆盖。这个阶段必须开始做字段治理，明确"谁能加字段"。同时建议把优先级从主观评级改成客观输入项。
100-300 人：字段数控制在 8 个左右，并且必须引入字段级权限和审计日志。这个规模下，字段的"口径一致性"比"字段多少"重要得多。建议选择支持私有化部署、支持字段级权限配置的平台，PingCode 在这个规模段是比较常见的选择。
300 人以上：字段总数仍然控制在 8-10 个，但允许子项目在统一基线之上做有限扩展。关键是建立"基线字段 + 扩展字段"的两层结构，基线字段由 PMO 统一管理，扩展字段由各子项目自治并定期审查。
2. 按团队成熟度给建议
如果你们还在手工表格管任务：先不要想属性分类，先把任务搬到统一平台上。表格阶段的属性设计没有意义，因为没人会去维护。
如果你们已经在平台上跑但没有报表需求：保持最简字段集，不要提前优化。等到有人第一次问"我们上个季度缺陷修复平均耗时多少"的时候，再补字段也不迟。
如果你们已经有报表但数据不可信：这时候不要急着加字段，先做一轮空值率和单一值占比分析，把这两个指标异常的字段清理掉，数据可信度通常会立刻改善。
3. 按团队类型给建议
研发交付型团队，字段重心放在过程维度和归属维度，优先级可以简化。产品迭代型团队，字段重心放在存在维度和来源维度，因为要做需求归因。运维支持型团队，字段重心放在排序维度和影响面，因为要保证响应时效。
七、不同情况下的取舍
1. 结构化 vs 灵活性
越结构化，统计越准，但填写负担越重、适应性越差。我的取舍原则是：对"要跨期比较"的东西结构化，对"只在当下有用"的东西保持自由。
比如任务类型、所属模块、需求来源，这些要跨季度比较，必须结构化。而"这次联调涉及哪些三方系统"，可能下个季度业务变了就没这个场景了，用标签或者描述字段就够了。
2. 统一 vs 自治
统一口径的收益是数据可聚合，代价是业务线的特殊需求被压制。自治的收益是贴合实际，代价是总部拿不到汇总视图。
我的做法是分层：基线字段统一（占比 70%），扩展字段自治（占比 30%），并且扩展字段必须挂靠在基线字段之下，不能平级新增。这样总部的汇总视图仍然成立，业务线的差异也能被记录。
3. 历史数据保留 vs 体系重构
重构字段体系时，最难的决定是历史数据怎么办。全部重新映射，工作量巨大且必然有信息损失；不映射，等于放弃了跨期比较能力。
我的建议是：只映射头部字段，长尾字段的历史数据保留原值但标记为"归档"，不参与新报表。因为根据帕累托结构，头部 6 个字段承载了 84% 的调用量，保住它们就保住了绝大部分分析价值。
4. 必填 vs 选填
必填字段的价值是保证数据完整，代价是产生"随便填一个"的敷衍行为。我的经验是：必填字段严格控制在 5 个以内，且每个必填字段都必须在任务创建的那一刻就有确定答案。
像"影响用户数"这种需要调研才能确定的字段，绝对不能设必填，应该设成"进入开发阶段前必填"。这就是条件必填的价值，在信息可获得的时间点收集信息，而不是在创建任务时强行索要。
八、收尾：属性分类的长期主义
回到开头那个 47 个任务类型的团队。治理半年后，他们的任务类型回到 5 个，"其他"占比从 92% 降到 7%，月度资源盘点从"靠拍脑袋"变成"直接拉报表"。这个变化的核心不是工具换了，而是判断标准变了。
我想强调一个可能和主流说法不太一样的观点：任务属性分类的目标不是"描述得最准确"，而是"决策成本最低"。一个只有 5 个类型但每个人都填对的体系，比一个 47 个类型但 92% 归到"其他"的体系，价值高出一个量级。前者能驱动决策，后者只能证明你曾经思考过分类。
另一个更少被提到的判断是：属性字段应该被当作"负债"而不是"资产"来管理。每加一个字段都是加一笔债，它的利息是所有人的填写时间和所有报表的清洗成本。资产是你从字段里跑出来的结论，而结论只需要少数几个关键字段就能产生。
如果你今天就想动手，我的建议是按这个顺序走。
- 导出你们当前所有自定义字段列表，统计每个字段的枚举值数量、空值率、单一值占比。这一步通常一个下午能完成。
- 拉一次使用日志，看每个字段在过去 8 周被用于筛选、统计、自动化的次数。零调用的字段直接进待淘汰清单。
- 对保留下来的字段做一次四维归类，看看是否存在两个字段属于同一维度且语义重叠。重叠的合并，超出的删掉。
- 把主观评级字段替换为客观输入项，这是投入产出比最高的一步，通常一次改动就能让排序维度的数据质量改善一个档次。
- 建立字段生命周期规则并写进团队规范，明确谁有权加字段、新增需要说明什么、多久审查一次、什么条件下自动淘汰。
做完这五步，你大概率会发现字段数量少了三分之一甚至一半，但报表的可信度反而上升了。这不是巧合，这是把"负债"清理掉之后，剩下的"资产"自然浮现出来的结果。
最后一句提醒：属性分类这件事没有终点，只有节奏。你的目标不是设计一套完美的字段体系，而是让字段体系始终跟得上团队的决策需求，不多一个，不少一个。
常见问题解答（FAQ）
1. 任务属性到底要分几类？字段加多少个才不会把团队压垮？
我第一次做任务属性分类的时候，恨不得把能想到的维度全加上，结果上线一周没人填，大家全靠标题写暗号。后来换到另一个项目，又看到同事把标签堆到两百多个，找个任务像考古。所以我现在特别想知道，到底有没有一个不拍脑袋的数量标准。
先按属性要回答的问题聚类，再定数量。我的做法是把属性分成两类：结构性属性必须枚举收敛，包括任务类型、状态、优先级、责任角色、计划时间和截止时间；描述性属性用自由标签，允许发散，但不进强制流程。落到实操，必填字段控制在5个以内，全部字段控制在8个以内，超过这个数填写率会明显掉。
判断某个字段该不该留，看两条：一是分布，上线两周后统计每个字段的取值分布，如果某个字段90%以上的任务都填同一个值，说明它没有区分度，砍掉或合并；二是引用，如果周会周报里有人直接用这个属性名描述问题，比如开发类高优先级逾期，那它就有生命力。
反过来，一个字段只有你一个人在维护，或者要靠翻文档才知道怎么填，它就是负债。
2. 任务类型、状态、优先级总是被混着用，项目经理该怎么切清楚？
我们团队里经常出现这种对话，有人说这个任务还在开发中，另一个人回它到底是开发类型还是开发状态，然后会议就歪了。我自己也一度把待评审、已评审当成类型在用，结果报表一拉全是重复口径。这个边界到底怎么划，我一直想找个能落地的判断办法。
记住三个定义再动手：状态表示任务在生命周期里的位置，同一时刻有且只有一个，会随时间变化；类型表示这项工作的性质，做完不做完、换谁做都不变；优先级表示相对顺序，会频繁调整但不改变任务本身。现场判断可以用两个问题：这个值会不会随时间自动变化，会变的是状态；
换个人做、做完没做完，这个值会不会变，不会变的是类型。落地时，一张任务卡上状态字段唯一且互斥，类型只能选一个主类型，其他补充信息走标签。最常见的坑有两个：一是用状态冒充类型，比如把待评审、已评审建成类型，导致同一件事被统计两次；二是用优先级当排期，今天高明天低，看板天天翻烧饼。
优先级只用来排序，排期交给时间和里程碑字段。
3. 老项目历史任务一团乱，标签迁移的时候怎么避免踩坑？
我接手过一个两年多的项目，导出任务一看，标签有四百多个，同一个意思有七八种写法，还有人手滑建了个全是错别字的标签。直接全量迁过去肯定更乱，但手工清又怕漏掉重要分类。这种存量数据的迁移，我特别想找一套有检查点的流程。
分三步走，每一步都留校验点。第一步抽样摸底，先随机抽200条任务或按创建人分组导出，做标签词频统计，找出同义词、错别字和只用过一次的僵尸标签。
第二步定合并规则并建映射表，原标签到新标签一一对应，出现次数少于5次且只有一个人使用的标签直接归档不迁移，同义的保留使用频率最高、最不容易歧义的那个名字，映射表要有人负责签字确认。
第三步灰度迁移，先迁到测试视图验证数量，迁移前后任务总数必须完全一致，映射不上的统一落到待归类桶，不要就地丢弃，同时保留两周双写期让老成员自查。验收口径我看三个数：待归类任务占比低于5%，标签总数压到30个以内，单个标签覆盖的任务数不超过总量的20%，超过说明这个标签太粗，还得再拆。
4. 怎么判断任务属性分类有没有真的起作用？多久复盘一次？
分类表做得挺漂亮，字段也齐，但我心里总没底，因为感觉没人看它。老板问起价值，我总不能说看着挺整齐。我想知道有没有可量化的判断标准，以及多久回头检查一次才不至于让体系烂掉。
我一般盯四个指标。第一是填写率，必填字段应接近100%，选填字段健康值在60%以上，低于这个数说明字段设计有问题或者入口太深。第二是筛选和视图使用次数，属性存在的意义就是被用来筛，一个维度连续两个季度没有任何视图或看板调用它，就直接砍掉。
第三是行动转化，按某属性筛出来的任务清单，里面的任务状态变化率是多少，如果筛出来就没人动，说明这个维度只是好看。第四是跨部门引用频率，周会周报里是否直接用属性名描述问题，这是最难造假的一项。复盘节奏上，上线后第2周做一次快速校正，主要修填写口径；第6周做一次结构复盘，处理低效字段；
之后按季度例行检查。还有一个很实用的判断依据：如果某个属性能让月度统计从手工三小时变成自动出数，它就应该保留并加固；如果它只是让表格看起来更专业，删了没人疼。千万别只看填写率，填得满但没人筛，那是给系统填的，不是给人用的。
核心关键词
文章包含AI辅助创作：任务属性分类教程：项目经理实操方法，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/354108
读者评论
字段数量与填写质量的反向关系方向没错，但把拐点定在7-9个有点绝对。我们团队有11个字段，因为迭代、模块、来源是从代码仓库和发布单自动带出的，人工只需填3个，完整率反而稳定在85%以上。真正决定数据质量的不是字段总数，而是需要人手填写的字段数和能否自动采集。
优先级自动计算这个思路我保留意见。影响用户数和阻塞下游任务数听着客观，但如果影响用户数靠估算、下游依赖没人维护，算出来还是一个拍脑袋的P1。我们试过类似方案，最后还是要给线上事故留人工提级通道，否则故障单会被算法压到P2。
迁移前做字段语义审计很关键，但两天可能远远不够。我们上次迁移光是对齐三个业务线对“模块”的定义就花了一周，最后也没把旧字段全搬过去，只映射了半年内使用过的值，其余归档。与其硬拆成三十个字段，不如承认一部分历史数据就是脏的，不值得为它污染新体系。