任务属性分类教程：项目经理最佳实践，避坑指南

一个 800 人规模的研发组织，任务库里的标签数量是 1247 个，而季度复盘时真正能用来切数据的只有 9 个。这是我 2022 年参与一次研发管理平台迁移时，打开对方生产环境后拿到的第一个数字。真正让我头疼的不是标签多，而是当我想把「支付链路重构」这条业务线的任务捞出来时，发现同一个业务同时存在四种表示方式：有人打标签「支付重构」，有人打「支付-重构」，有人挂在模块「交易中心/支付」，还有人只在标题里写了「支付」。

这就是任务属性分类失序的典型后果，它不是整洁度问题，而是统计口径已经不可信。项目经理每周花几小时做的进度报表，本质是在一堆语义漂移的数据上做二次猜测。

这篇文章不讲「任务应该有哪些字段」这种谁都写得出来的清单。我要讲的是：任务属性到底应该按什么逻辑分类、每类属性的真实成本在哪里、哪些字段看着有用其实是在给未来的自己挖坑，以及当组织规模跨过 100 人、200 人、500 人这几道坎时，属性体系该怎么演化。文中的数据和案例来自我参与过的四次研发管理平台迁移与属性重构，样本是 3 家 200 到 1500 人规模的研发组织，涉及硬件研发、SaaS 产品和企业级软件交付三类业务形态。

一、先说核心结论：任务属性只有四类，但只有两类值得长期投入

我见过太多团队在讨论「任务模板该加什么字段」时，一上来就进入具体字段名的争论，讨论两小时，最后变成「先都加上，用不到再删」。这个结论通常是错的，因为属性的添加成本极低，删除成本极高，一旦有历史数据依赖，删除字段意味着报表断档和迁移风险。

所以正确的顺序不是先想字段，而是先给属性分类。我用的分类框架是四象限，判断依据是这个属性的「写入者」和「读取者」是不是同一批人。

1. 四类属性的定义与边界

第一类是结构性属性，包括任务类型、所属迭代、所属模块、父任务关系。这类属性定义的是任务在系统里的位置，它决定了任务的层级、归属和汇总路径。结构性属性的特点是必须唯一、必须有明确取值域，而且变更频率极低。

第二类是流程性属性，最核心的是状态和状态流转规则。它决定任务在哪个阶段、谁能推动它往下走、什么条件下可以关闭。流程性属性是唯一一类「必须由系统强制约束」的属性，靠人工自觉维护一定会崩。

第三类是度量性属性，包括故事点、原始预估工时、实际耗时、缺陷严重程度、优先级。这类属性存在的唯一目的是被聚合、被比较、被用来做预测。判断一个字段是不是度量性属性，看它能不能出现在趋势图里就够了。

第四类是上下文属性，也就是标签、备注类字段、关联链接、来源渠道。它们提供的是检索线索和补充说明，不需要参与聚合，也不应该参与聚合。

绝大多数团队的问题，是把第三类和第四类的边界搞混了。标签被用来做统计，优先级被用来做排期，备注里塞了本该结构化的信息。

2. 为什么度量性属性的杠杆最大

度量性属性少一个，损失的是「某一类决策无法做」。比如没有实际耗时的沉淀，你在做下一季度排期时就只能靠印象，很难发现某类任务的实际耗时是预估的 2.4 倍。

上下文属性多十个，损失的只是「检索时多一点噪音」。它不会让报表算错，只会让报表变慢。这就是两者成本结构的不对称：度量性属性的缺失是能力缺失，上下文属性的过剩是效率损耗。

我在一次重构里做过对比。重构前该团队有 47 个自定义字段，其中 31 个属于上下文类（各类标签、备注、补充说明），真正参与报表的只有 6 个。重构后自定义字段压到 19 个，报表口径数反而从 11 个增加到 18 个。原因很简单，腾出来的字段名额被用来补齐了度量维度。

3. 一个可以立刻用的判断法则

在决定要不要加一个属性之前，我会问三个问题，任何一个答不上来就不加：

1. 这个属性的写入者是谁？是每个人都要填，还是只有特定角色填？
2. 这个属性的读取者是谁？是当周就要读，还是三个月后复盘才读？
3. 如果这个属性三个月后全部为空，谁会受影响？

第三个问题是过滤器。我统计过一次，候选属性里有大约四成在第三问上答不出具体的人，它们后来几乎都变成了空字段。空字段的危害不只是占位，它会让填报者产生「填不填都行」的心理预期，进而影响到必填字段的认真程度。

二、背景：属性分类失序通常是怎么一步步发生的

几乎没有团队是主动把属性体系搞乱的。它更像是一种缓慢的熵增，而且每个阶段都有它当时的合理性。我把它拆成三个阶段，你可以对照自己团队现在处在哪一段。

1. 阶段一：自由生长期（团队成形后的前 6 到 12 个月）

这个阶段的特征是「谁都可以建字段」。产品经理为了标记用户反馈来源加了「来源渠道」，测试负责人加了「发现阶段」，技术负责人加了「技术债类型」。每个字段在创建的那一刻都有明确用途。

问题在于没有人在建字段时问一句：这个字段和已有的字段有没有语义重叠？我见过最典型的例子是同一个团队同时存在「任务类型」「工作类别」「任务分类」三个字段，三者取值域高度重叠但又不完全一致。三个月后，没人说得清三者区别，于是填报者随机选一个。

2. 阶段二：约束收紧期（12 到 24 个月）

报表开始不可信，管理层开始质疑数据，于是团队引入约束：字段必须必填、取值必须从下拉选、禁止自由创建标签。这个方向是对的，但执行时常常用力过猛。

我见过一个团队把自定义字段全部改为必填，包括那些原本只有特定场景才用得上的字段。结果是任务创建时间从平均 40 秒涨到 3 分 20 秒，工程师开始批量创建「先建了再说」的空壳任务，反而制造了更多垃圾数据。

约束的核心不是「必填」，而是「必填的时机」。一个字段如果在一个任务的生命周期里天然属于某个阶段，就不应该出现在创建表单里，而应该出现在该阶段的状态流转校验中。

3. 阶段三：治理与迁移期（24 个月以后）

到这个阶段，团队通常面临一次平台更换或者一次组织级的流程改造，属性体系被推倒重来的机会窗口出现了。这也是唯一一次能低成本「清零历史包袱」的机会，因为迁移本身就是一次全量语义对齐。

但我在实践中看到的反直觉现象是：真正的清理动作往往发生在迁移后的第 3 到 6 个月，而不是迁移期间。迁移期间所有人都忙着保业务连续性，没人敢删字段；等系统稳定了，才有精力回头做减法。

4. 一个真实场景：标签从 40 个涨到 900 个用了多久

我记录过一个 300 人研发团队（含硬件、嵌入式软件、云端服务三条产品线）的标签增长曲线。第一年 40 个标签，主要靠约定俗成；第二年引入「每人可自由创建标签」后，一年内涨到 610 个；第三年上半年突破 900 个。

真正的崩溃点出现在一次高管会议上。管理层想看清楚「面向车厂的定制需求」消耗了多少研发资源，结果需要三个数据分析师花两天时间做人工归集，归集过程中发现的重复标签有 214 个，含义冲突的有 37 组。

后来他们的做法很务实：不是清理标签，而是新增一个结构性字段「业务线」，然后把标签降级为辅助检索。所有报表改走业务线字段，标签只用于个人搜索习惯。这个改动的成本大约是 12 人天，但把报表口径的稳定性从「不可用」提到了「可用」。

三、拆解常见误区：五个看起来合理、实际代价很高的做法

下面五个误区我都亲自踩过或者近距离观察过，代价可以量化。我按修复成本从低到高排列。

1. 误区一：把标签当分类字段用

标签的本质是多对多的开放集合，它天生不具备互斥性和完备性。用它做分类，等于用一个不设边界的容器去承载一个有明确边界的概念。

最典型的表现是「同一维度多标签并存」：一个任务同时打了「P0」「紧急」「本期必做」三个标签，这三个表达的是同一件事。当你想统计「本期必做任务占比」时，你得先决定以哪个标签为准，而这个决定在不同人那里答案不同。

识别方法很简单：如果你发现某个维度需要用三个以上标签来交叉表达，它就该升级成结构性字段或枚举字段，而不是继续留在标签体系里。

2. 误区二：用优先级承载排期信息

「优先级」几乎是所有项目管理工具里被滥用最严重的字段。我统计过 6 个团队的优先级分布，其中 4 个团队的 P0 占比超过 35%。当三分之一的任务是最高优先级时，这个字段的排序能力已经归零。

问题的根源在于，团队实际上在用优先级表达两件不同的事：重要性（这件事不做会有多大影响）和紧迫性（这件事最晚什么时候要做）。这两件事混淆在一起，就会导致所有人都倾向于报高优先级，因为报低了可能被插队。

我的做法是把它们拆开：优先级只保留三档（高、中、低），另设一个「期望完成时间」字段承载紧迫性，并且期望完成时间由需求方填，优先级由排期会议定。写入者分离之后，两个字段的可信度都会上升。

3. 误区三：把状态机当成阶段划分

状态和阶段是两回事。状态是任务当前的精确位置（待评审、评审中、开发中、待测试），阶段是任务所处的粗粒度区间（需求期、研发期、验证期）。

很多团队的做法是直接建一个 15 个状态的状态机，然后希望用这 15 个状态反推出阶段，做统计时再加一层映射表。这个方案在状态少时能跑通，一旦状态超过 10 个，映射表本身就成了维护负担，而且不同人映射口径不一致。

我倾向于让状态机保持精简（6 到 9 个），把「阶段」做成一个由状态自动推导的只读属性。这样填报者只需维护一个字段，统计侧拿到的是稳定的粗粒度维度。

4. 误区四：用自定义字段承载组织架构

这是一个特别隐蔽的坑。团队会建一个「所属团队」字段来标记任务归属，看起来很合理。但组织架构是会变的，而任务上的字段值是快照。

我见过的情况是：某团队在 2021 年做了一次组织调整，两个部门合并，但历史任务上仍然保留着旧部门名。一年后做跨年对比报表时，同一个业务被拆成了两行数据，因为口径不同。

组织归属应该由「人员-组织」的映射关系动态推导，而不是固化在任务字段上。任务上只需要记负责人，归属通过负责人所属组织实时算出。这样组织调整时只需改一处映射，历史统计会自动重算。

5. 误区五：迁移时按字段名映射而不是按语义映射

这个误区只在平台迁移时出现，但代价极高，因为它会污染整个新平台的数据基线。

最常见的错误是「同名即同义」假设。实际上，一个叫「工时」的字段在旧系统里可能指的是预估工时、也可能指实际工时、还可能指需求评审时估的复杂度分。如果不做语义抽样核对就按名字搬过去，错误会被完整继承。

我在一次迁移中做过抽样核对：随机抽 200 条记录，逐条比对字段值与业务文档的一致性，发现「工时」字段的实际语义在不同团队之间有三种，占比分别是 58%、27%、15%。如果直接迁移，等于把三种语义混进同一个字段。

四、专业判断逻辑：属性分类的决策框架

前面讲的是「不该怎么做」，这一章讲「怎么判断」。我用的是一套三层决策框架，先过滤、再定契约、最后固化命名。

1. 三问过滤法：从候选属性到落库属性

我把每次属性评审收到的候选项，都走一遍同样的流程。一个候选属性要连续通过三道关卡才能落库，任何一道不过就打回。

1. 唯一性关卡：这个属性能不能从已有属性推导出来？能推导的一律不加，改成计算字段或视图列。
2. 唯一写入者关卡：这个属性是不是有且只有一个角色负责填？如果有多个角色都觉得自己该填，说明定义不清，先定义后加字段。
3. 消费场景关卡：这个属性有没有一个明确的、已经存在的消费场景（报表、自动化规则、门禁校验）？如果只是「以后可能有用」，不加。

我用这套流程处理过一批 34 个候选属性，最终落库 11 个，从已有属性推导出 9 个，因为定义不清打回 8 个，因为无消费场景否决 6 个。通过率大约三分之一，这个比例健康。如果通过率超过一半，通常说明评审太松。

2. 四种数据契约：属性落库时必须写明的东西

一个属性被批准之后，不能只写个名字就完事。我会要求同时写清四件事，我称之为属性的「数据契约」。

（1）取值契约

明确取值域是枚举、区间还是自由文本。枚举必须给出完整取值列表和每个值的判定标准，自由文本必须明确长度上限和是否参与检索。

（2）时序契约

明确这个属性在任务的哪个时点被写入，以及是否允许修改。不允许修改的属性（比如首次进入开发的时间）价值极高，因为它是稳定的；允许随意修改的属性在统计上基本不可用，因为你可以通过改它来改变报表结果。

（3）空值契约

明确不允许为空、允许为空但默认值是什么、以及为空时在统计中如何处理（排除、计入其他、还是按零处理）。空值处理规则不写明，是报表口径分歧的最大来源。

（4）变更契约

明确这个属性的取值发生变化时，是否需要保留变更历史。度量性属性几乎都需要保留历史，因为「什么时候变的」和「变成了什么」一样重要。

3. 命名与取值规范：让字段名自带语义

命名混乱是隐性的时间黑洞。我在一次跨团队调研里统计过，工程师平均每周花在「确认某个字段到底该填什么」上的时间是 22 分钟，一个 200 人团队一年累计约 1500 小时。

我用的命名规范只有三条，但执行后字段理解的歧义率明显下降：

• 字段名必须包含单位或口径，比如用「预估工时（人时）」而不是「工时」，用「实际耗时（人日）」而不是「耗时」。
• 禁止使用「其他」作为枚举值，改成「待归类」并配一个必填的补充说明字段，或者干脆扩展枚举。因为「其他」会吸收所有定义不清的情况，让字段失去分析价值。
• 布尔字段一律用肯定式命名，比如「是否包含外部依赖」而不是「是否无外部依赖」，避免双重否定带来的填报错误。

# 属性定义示例（可直接用于平台配置评审）
attribute: estimated_effort

label: 预估工时（人时）

type: number

range: [0.5, 400]

nullable: false

default: null

write_stage: 需求评审通过时

editable_after_write: true

history_tracked: true

consumers:

迭代容量规划报表

预估偏差趋势分析

null_handling: 排除出均值计算，计入覆盖率分母

把上面这段配置当成属性上线的最低要求来执行，能在源头消掉大部分口径争议。注意 null_handling 这一项，它看起来最不起眼，但我在至少三次报表争议里发现根因都出在这里，有人把空值当零算，有人把空值排除，同一份数据得出两个结论。

4. 状态机与属性的耦合检查

状态流转和属性之间有一种容易被忽视的耦合：某些属性只在特定状态下才有意义。比如「验收结论」只应该出现在待验收及之后的状态，「实际耗时」只应该在任务关闭后有值。

如果不管这一层，就会出现「任务还在开发中但已经填了验收结论」这种数据。我的做法是给每个属性标注一个「有效状态区间」，并在状态流转校验里检查：任务离开某个状态时，该状态区间内必须填写的属性是否完整。

这比在创建表单里堆必填字段有效得多。创建时填 15 个字段，工程师只会敷衍；在关闭任务时强制填 2 个字段，工程师会认真填，因为这时候信息最完整。

五、案例与数据观察：一次 800 人研发组织的属性重构

这一章讲一个完整案例。它涉及三家产品线、一次平台迁移和一次属性体系重构，是我参与过的最复杂的一次。我尽量给出可验证的细节和数字。

1. 重构前的基线

该组织 800 余人，研发人员约 520 人，同时运行三条产品线。重构前的关键数字是：自定义字段 68 个，其中空值率超过 50% 的有 29 个；标签总数 1247 个；状态机最多的一条流程有 17 个状态；月度统计报表需要 3 名数据分析师投入约 6 人天做人工归集。

最能说明问题的是那 6 人天。它的构成是：口径对齐会议 2.5 人天、标签归集 2 人天、跨系统数据拼接 1.5 人天。其中口径对齐占了四成以上，说明最大的成本不是算不出来，而是大家对「算什么」没有共识。

2. 迁移映射表：按语义而不是按字段名对齐

这次重构和平台迁移是同时进行的，目标平台选了 PingCode。选它的直接原因有三个：一是支持私有化部署，该组织有数据不出内网的要求；二是对中大型企业场景的适配度较高，800 人规模多产品线并行是它的常规负载；三是能从 Jira 平滑迁移，他们的旧系统就是 Jira，历史数据有五六年的积累，迁移保真是硬约束。

这个组织的旧系统里，和「工作量」相关的字段有三个：Story Points、Original Estimate，以及一个自建的 customfield_10231。从名字上看，中间那个是预估工时，另外两个看名字看不出所以然。

我们没有直接做字段映射，而是先做了一次抽样语义核对。做法是从每个字段各抽 300 条不为空的记录，对照当时的迭代评审文档，判断这个值实际代表什么。结论是：Story Points 是复杂度分（斐波那契数列，取值 1 到 21），Original Estimate 是预估工时（单位小时），customfield_10231 是部分团队自创的「理想人日」。三者语义完全不同，如果按名字合并，会把复杂度分和工时混成一列。

最终的处理方式是把三者拆开：复杂度分保留为一个独立属性，预估工时统一换算成人时，那个自创的理想人日字段不迁移，改为在迁移说明中标记为废弃，只保留历史导出文件供追溯。这个决定在当时有争议，反对意见是「历史数据就断了」。但因为它的填报团队只占 15%，且和其他两个字段存在换算关系，保留它的成本高于收益。

3. 迁移中的三个具体动作

这次迁移里我认为最值得复用的三个动作，都是围绕属性语义对齐展开的。

第一个动作是建立双人复核的映射表。每个旧字段由一名业务方代表和一名平台配置人员共同确认目标字段和转换规则，双方签字后生效。这看起来很重，但把 68 个自定义字段逐一对齐后，返工率从上一轮迁移的约 18% 降到 3% 以下。

第二个动作是必填属性的状态化改造。把原来创建时必填的 23 个字段压缩到 6 个，其余 17 个改为在对应状态流转时校验。这一项直接让任务创建平均耗时从 3 分 20 秒降到 55 秒。

第三个动作是先跑两周并行。迁移完成后新旧系统并行运行两周，每天比对关键报表的数字。发现的差异分三类处理：字段语义差异、状态映射差异、时区与统计口径差异。并行期的两周额外投入约 8 人天，但避免了上线后一个季度的报表信任危机。

4. 重构后的三个变化

变化一是报表从「解释性工作」变成「消费性工作」。重构前，每次月度报表都要先花时间解释口径；重构后，报表直接进入讨论环节。这个变化的体感非常明显，分析师从「数据的辩护者」变回了「数据的分析者」。

变化二是出现了一批新的决策场景。因为预估工时和实际耗时的字段口径统一了，他们开始能按任务类型计算预估偏差率。第一轮统计的发现是：涉及第三方接口联调的任务，实际耗时平均是预估的 2.3 倍。这个发现直接推动了后来在排期时对这类任务单独设置缓冲系数。

变化三是有代价的。私有化部署下的字段调整需要走配置变更流程，不如 SaaS 环境下点几下那么随意。前期有人抱怨灵活性下降，但三个月后这种抱怨基本消失，因为大家意识到字段变更需要走流程，本身就是一种必要的摩擦力，它过滤掉了大量「顺手加一个」的冲动。

六、不同情况下的行动建议

属性体系没有通用最优解，只有和组织阶段匹配的解。我按团队规模分四档给出建议，你可以直接对照自己的情况。

1. 30 到 50 人团队：只做结构性属性，度量属性够用就行

这个阶段最不该做的是引入复杂的自定义字段体系。人少的时候，口头同步的效率远高于填表。我的建议是只保留核心的五个属性：任务类型、负责人、所属迭代、状态、预估工作量。

度量性属性只留一个就够，我建议是预估工作量，单位统一。不要同时引入故事点和工时，小团队没有足够样本量做两者的相关性分析，同时存在只会造成填报困惑。

这个阶段真正要做的事是把命名规范定下来并写进团队文档。成本几乎为零，但等团队涨到 100 人时，这个规范能省掉一次完整的重构。

2. 50 到 200 人团队：开始治理标签，建立属性评审机制

这是属性体系最容易失控的区间。团队已经跨过口头同步的临界点，但还没建立起治理流程。我的建议是三件事同时做：

1. 把标签创建权限收归到每个团队的固定角色，禁止全员自由创建。
2. 建立属性评审机制，按前面讲的三问过滤法走流程，评审频率可以低频（每月一次），但必须有。
3. 开始收集预估偏差数据，这是度量性属性最基础的一步，也是后续所有容量规划的前提。

如果这个阶段正在考虑更换平台，我会建议优先考虑能从现有系统平滑迁移的方案，并且把「迁移时的字段语义核对」写进项目计划。这个阶段的团队通常没有专职的平台管理员，迁移一旦出问题，修复能力有限。

3. 200 到 1000 人团队：必须做属性分层和状态机收敛

这个规模的组织，属性体系必须分层：组织级属性（跨团队报表必需，由平台统一管理）、产品线级属性（本产品线特有，由产品线维护）、团队级属性（团队内部使用，不进入组织报表）。

分层的核心价值是隔离变更影响。团队级属性随便加，不影响组织报表；组织级属性变更需要走评审，因为它影响所有下游。

状态机在这个阶段必须收敛。我的经验是组织级统一状态机不超过 9 个状态，各团队如需更细粒度，用子状态或标签表达，不要动主状态机。因为状态机一旦分裂，跨团队的周期分析就无法进行。

这个规模的组织如果有数据不出内网的要求，私有化部署基本是必选项。同时因为历史数据量大，迁移的保真度比迁移速度重要得多，值得为语义核对多花两三周。

4. 1000 人以上或强合规场景：把属性当配置资产管理

到这个阶段，属性已经不只是填报字段，而是配置资产。需要做的事包括：属性变更走正式的变更管理流程、属性定义文档纳入版本控制、迁移映射表作为历史资产长期保存。

我还建议做一件事：定期做属性健康度审计。审计指标至少包括空值率、唯一值数量分布、变更频率、下游消费方数量。空值率超过 40% 且下游消费方为零的属性，进入废弃候选清单。

七、不同情况下的取舍

属性设计本质上是几组矛盾的平衡，没有两全方案。我把最常见的四组取舍摊开讲，方便你判断该往哪边偏。

1. 灵活性与可统计性

灵活性越高，可统计性越低，这是铁律。允许自由填写备注的团队，检索体验好但报表做不出来；严格枚举的团队，报表稳定但遇到边界情况无处安放。

我的取舍原则是：度量性属性偏可统计性，上下文属性偏灵活性。也就是说，工时、优先级这类要参与计算的字段，一律严格枚举；而备注、说明类字段可以自由填写，反正它们不参与聚合。

最忌讳的是「半结构化」，用文本字段承载本该枚举的信息。比如把优先级写成文本，就会出现「高」「高优先级」「紧急」三种写法，等于废掉这个字段。

2. 统一字段与团队自治

统一能换来跨团队对比能力，自治能换来团队适配度。200 人以下我建议偏统一，因为跨团队对比的价值在这个阶段还不高，而统一的执行成本低。200 人以上必须分层，否则要么统一得太粗导致团队无法表达真实业务，要么放任自治导致组织报表无法生成。

分层的关键是明确哪一层属性进入组织报表。我在实践中见过一种失败模式：分层做了，但团队级属性也被纳入了组织报表，导致组织报表里出现大量只有某个团队有值的字段，整体空值率飙升到 60% 以上。分层必须配套「报表隔离」才有意义。

3. 迁移保真与重构清零

这是最纠结的一组。全量保留历史属性意味着继承历史包袱；全部清零点重建意味着历史数据失去可比性。

我用的判断标准是这个字段的语义在抽样核对中是否稳定。如果 300 条抽样的语义一致率超过 90%，就保留并迁移；如果在 70% 到 90% 之间，保留但标注语义说明；如果低于 70%，不迁移，只保留导出文件。

这个标准的好处是它是可执行的，不需要争论「要不要保留历史」。我在那个 800 人案例里就用了这个标准，68 个字段里有 9 个因为语义一致率低于 70% 被废弃，没有引起实质性的业务影响。

4. 私有化部署下的灵活性与治理强度

私有化部署对属性治理的影响是双面的。一方面，字段调整需要走配置变更流程，响应不如 SaaS 灵活；另一方面，这种摩擦力恰恰抑制了随意加字段的冲动。

我的建议是不要试图消除这种摩擦力，而是把摩擦力用在正确的地方。做法是区分两类变更：低风险变更（新增枚举值、修改显示名、调整排序）走快速通道，一到两天内完成；高风险变更（新增字段、修改字段类型、废弃字段）走正式评审。分类之后，日常的小调整不会积压，重要变更依然有把关。

另外要提醒一点，私有化部署下做属性重构，必须提前确认清历史数据的处理方式。存量数据的批量回填、变更历史的保留策略、版本升级时的属性兼容性，这三件事在私有化环境下需要提前规划，不能像 SaaS 那样依赖供应商自动处理。

八、一张可直接复用的属性清单

最后给一份我实际在用的清单模板。它不是「必须有的字段列表」，而是「每个字段上线前必须回答的问题」。你可以把它当作属性评审的检查表。

这张表里我最想强调的一行是「迁移时语义核对抽样量」。流程性属性之所以要求全量核对，是因为状态映射错一条，就会导致一条任务的周期统计永远错误；而状态值本身数量有限，全量核对的成本是可接受的。

上下文属性那一列我写的是「不迁移」，这不是偷懒。语义不稳定的上下文属性迁移过去之后，只会增加新系统的噪音，而且它们的检索价值通常有时效性，三年前的标签对今天的检索帮助很小。

1. 复盘：我踩过的两个最大的坑

第一个坑是过早追求完备。我曾在一次新平台上线时设计了 40 多个属性，覆盖了能想到的所有场景。结果是上线三个月后，有 21 个属性的空值率超过 60%，团队对填报整体产生了抵触情绪。后来的教训是：属性应该随着决策需求长出来，而不是提前铺好。

第二个坑是把治理当成一次性项目。我在另一家公司做过一次很彻底的属性精简，从 60 多个字段砍到 20 个，效果很好。但因为没有建立定期审计机制，18 个月后又涨回到 50 多个。属性体系的熵增是持续发生的，治理必须是常规动作而不是专项战役。

2. 下一步怎么做

如果你读完想做点什么，我建议按这个顺序，从成本最低的开始：

1. 导出你当前平台的所有自定义字段和标签，按前面四类归类，算一下每一类的空值率。
2. 把空值率超过 50% 且没有明确报表消费方的字段列出来，形成废弃候选清单。
3. 挑一个度量性属性（建议从预估工作量开始），把它的取值契约、空值处理规则、变更历史策略补齐，然后跑一个月看数据质量。
4. 在下一个季度评审时，把三问过滤法正式引入属性评审流程。

四步做完大概需要三到五周，投入不大，但你会得到一份自己团队的属性基线。有了这份基线，后面无论是要做平台迁移、还是要向管理层解释报表口径，你都有据可依。

最后说一句我的核心判断：任务属性分类的目标从来不是把任务描述清楚，而是让不同的人对同一批任务得出同一个结论。前者是文档工作，后者才是管理基础设施。搞清楚这个区别，后面所有的取舍都会变得容易一些。