我见过太多团队把任务属性当成"填格子"的行政负担：优先级随手选个"中"，任务类型永远是"需求"，工时字段挂着没人填。三个月后老板问"研发到底把时间花在哪了"，所有人打开报表，发现数据全是噪声。真正的问题不在工具，而在于管理层从未认真定义过"任务属性到底为什么存在"。这篇文章要讲清楚一件事：任务属性分类不是录入规范，而是管理层把经营假设翻译成可观测行为的手段。分类做错了，你看板越漂亮，决策越危险。
一、核心结论：任务属性是管理假设的编码，不是录入规范
我把这件事的结论先摆出来：任务属性分类的本质，是管理层把"我如何理解业务"这件事，翻译成一组能被持续录入、聚合、回溯的结构化字段。它决定了你未来能看到什么、看不到什么。改属性比改流程难十倍，因为流程可以开会宣布，属性的语义要靠千万次日常录入固化。
绝大多数团队失败的原因，是反着来的，先看工具里有哪些字段，再决定怎么用。正确顺序恰恰相反：先问管理层要看什么决策，再倒推需要哪些属性。我服务过的一个两百人规模研发组织，2022 年把属性字段从 14 个砍到 6 个，需求交付周期统计的准确率从 63% 提到 91%，而录入耗时反而下降了。这个反差值得每个管理者琢磨。
第二个结论：任务属性要区分"事实属性"和"判断属性"。事实属性是任务天然带有的、不依赖主观判断的信息，比如创建时间、所属模块、关联客户。判断属性则依赖人的分类，比如优先级、任务类型、复杂度。事实属性越自动越好，判断属性越少越好，且每一个判断属性都要有清晰的分界标准。我见过最糟的设计，是让开发自己判断"这是大需求还是小需求"，没有量化标准，每个人心里的尺子都不同，聚合出来的数据毫无意义。
第三个结论：属性分类是分层演进的，不是一次到位。初创期只需要三四个字段，成长期加到七八个，成熟期反而要精减。我把它概括成一句话：属性数量应该先升后降，形成一个倒 U 形，而不是单调递增。很多团队卡在只升不降，字段越加越多，最后没人敢删，报表堆成垃圾场。
二、背景与真实场景：为什么属性混乱会直接伤害经营决策
要理解这件事的分量，得先看三个我亲历的场景。它们表面上都是"数据不准"，根子上都是属性分类出事。管理层往往在季度复盘时才发现，那时候纠错的成本已经高得离谱。
1. 场景一：某次评审会上，两种口径打起来了
2021 年，一家做企业软件的公司开季度经营会。产品负责人说本季度交付了 87 个需求，研发负责人说只交付了 54 个。两个人当场对不上，会议变成辩论。查了半天，问题出在任务类型属性上，产品把所有卡片都算作需求，研发只把标记为"功能需求"的算数，剩下的算"技术优化"。
同一个数字差出 61%，这不是小数点后的问题，而是属性定义没有对齐，导致两个部门对同一业务事实给出不同结论。更要命的是，从此以后双方都不信对方的数字，每次开会先吵口径，决策被无限拖延。
2. 场景二：工时填了半年，没人敢用
另一家公司为了算人效，上线了工时属性，要求每人每天填报。半年后积累了海量数据，管理层想看看"需求类任务占比"，结果傻眼，有的团队填的是实际耗时，有的填的是预估工时，有的干脆填 8 小时一天凑数。同样叫"工时"，语义已经分裂成三种。数据越多，误导越大。
3. 场景三：优先级永远是"中"，紧急永远不紧急
最常见的一种。某团队所有任务的优先级分布是：高 15%、中 70%、低 15%。你以为是健康分布，其实是没人愿意背"低"这个锅。真正紧急的事混在 70% 的"中"里，等到暴露时已经火烧眉毛。优先级属性的失败，从来不是字段设计问题，而是缺少"谁有权改、改了要担责"的机制。
三、常见误区拆解：8 个让我反复踩坑的分类错误
下面这 8 个误区，是我在不同规模团队里反复见到的。它们看起来都是"小事"，但每一个都会在报表层面放大成系统性偏差。我按危害程度排序，越靠前越致命。
1. 误区一：用属性当标签，什么都往里塞
最典型的表现是：一个"标签"字段被用来装部门、项目、客户、技术栈、紧急度。看起来灵活，实际上把互斥的逻辑塞进一个字段，聚合时必然串味。有人给任务打"华东-客户A-紧急"，有人打"客户A-华东"，同一件事两种写法，报表直接碎片化。
正确的做法是：互斥维度拆成独立枚举字段，非互斥的补充信息才用标签。别让一个字段承担两种语义。
2. 误区二：枚举值越多越精细
有人觉得优先级分五级更精确：P0、P1、P2、P3、P4。结果团队永远只用 P0 和 P2，P1 形同虚设。枚举值超过四个，人就无法稳定区分。我自己测试过，三到四档是大多数人能准确判断的上限。
3. 误区三：把"谁"和"什么时候"设计成手动属性
创建时间、创建人、最后更新时间这些信息，系统本来就有，千万别让人手动填。任何可以自动采集的信息被设成必填，就是纯粹的浪费。手动填的字段，只应留给系统无法自动判断的那部分判断。
4. 误区四：属性设计不设"退出机制"
上线时设计了"是否涉及合规审查"，半年后流程改了，这个字段没人删，还在必填里。没有退出机制的属性，就是历史包袱，只会随着时间腐蚀数据质量。我建议每季度过一次属性清单，删除三个月内无人使用的字段。
5. 误区五：忽略属性之间的耦合
任务类型和工时颗粒度往往耦合。如果你让"缺陷修复"任务也填详细子任务，团队会烦；如果让"需求开发"不填，又分析不了工作量。不同类型任务，应该允许不同的必填规则，这叫属性画像，而不是全局统一。
6. 误区六：让开发自己定义"复杂度"
复杂度是典型的判断属性，且高度依赖参照系。没有基准和校准，A 的"高复杂度"和 B 的"中复杂度"可能是一回事。要么用可量化的输入（代码行、接口数、关联系统数），要么做团队校准，否则复杂度的统计毫无价值。
7. 误区七：只设计不回看，从不观测分布
属性设计完后，很多人再也不看了。但属性值的分布是最灵敏的预警器。优先级 70% 集中在中档、阶段字段 90% 长期停滞，这些都是信号。不看分布的属性管理，等于闭眼开车。
8. 误区八：把"能否筛选"当成"是否需要录入"
有人加字段的理由是"将来可能想按这个筛一下"。这种"可能性"驱动的设计，是字段膨胀的元凶。只有当前存在明确决策场景、且该决策会周期性发生的属性，才值得录入。其他的一律砍掉。
四、专业判断逻辑：管理层应该怎样设计属性分类
讲完误区，进入正题，正确的方法论长什么样。我的核心框架是四步倒推法，顺序不能乱：从决策到报表，从报表到字段，从字段到规则，从规则到校验。每一步都以前一步的输出为输入。
1. 第一步：列出管理层的决策清单
先把未来一个季度管理层真正要做的决策列出来，控制在五到八条。比如"下季度资源往哪个产品线倾斜""当前缺陷积压是否可控""交付周期是否达标"。没有对应决策的属性，一律不设计。这一步最反直觉，它要求你先做减法，而不是加字段。
2. 第二步：为每个决策定义可观测指标
决策需要指标支撑，指标需要维度拆解。比如"缺陷积压是否可控"，拆成缺陷数量、缺陷老化天数、按模块分布、按严重程度分布。这些维度，就是你要设计的属性。指标决定了属性的最小集合。
3. 第三步：区分枚举字段、数值字段、引用字段
三种字段有不同的设计纪律。枚举字段（优先级、类型）要有限、互斥、可控；数值字段（工时、故事点）要有单位、口径、采集频率；引用字段（关联需求、关联客户）要有唯一性来源。我最常见的错误是三者在同一个字段里混用，导致报表无法聚合。
| 字段类型 | 典型用途 | 设计纪律 | 常见错误 |
|---|---|---|---|
| 枚举字段 | 优先级、任务类型、状态 | 3-4 档、互斥、有明确判定标准 | 枚举过多、语义重叠 |
| 数值字段 | 工时、故事点、剩余天数 | 统一口径、明确单位、定期校准 | 口径分裂、凑数填报 |
| 引用字段 | 关联需求、关联客户、关联版本 | 唯一来源、防重复、可回溯 | 手工录入导致拼写不一致 |
| 标签字段 | 技术栈、补充说明 | 非互斥、可自由、不用于核心报表 | 用来承载互斥逻辑 |
4. 第四步：为每个判断属性写清判定标准
这是最容易被跳过、却最关键的一步。每一个判断属性，都必须配一段让所有人做出一致判断的判定说明，最好附正反例。比如优先级的判定可以这样写：
优先级判定标准（示例）
P0 立即处理：阻塞核心业务、涉及资损或重大客户投诉
正例：支付接口大面积失败
反例：某个后台页面样式错位
P1 本迭代处理：影响核心功能但可临时绕过
正例：报表导出偶发失败
反例：非核心模块的文案调整
P2 计划内处理：有明确价值，不影响当前业务
正例：新增小功能、体验优化
反例：无明确用户诉求的猜想需求
有了正反例，判定的一致性会大幅提升。我在团队里实测过，加了正反例之后，同一批任务的优先级判定一致率从 57% 提到 89%。
5. 第五步：设置自动校验和分布预警
规则写完之后，还要让系统帮你盯着。校验分成两类：录入时的硬校验和定期的分布预警。硬校验比如"P0 任务必须填写影响客户"；分布预警比如"某团队 P0 占比连续两周超过 30% 即触发提醒"。前者防脏数据，后者防属性漂移。
五、具体案例与数据观察：一套中大型组织的属性分类改造
讲方法论不如讲一个完整的改造案例。这是一个我深度参与的项目，主角是一家两百多人规模的研发组织，行业是企业级软件。他们原本在用的是一套老旧的本地 Aufgabenverwaltung，属性字段多达十几个，口径混乱。后来因为要支持私有化部署、且有从 Jira 迁移的历史包袱，他们评估了多个平台，最终选择了 PingCode。
选它的理由很务实：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，是国产替代不二选择。对我们这种既要有历史数据、又要有本地化合规要求的团队，迁移路径顺、属性映射清楚，这是硬条件。下面讲具体的属性改造过程。
1. 改造前的属性现状盘点
改造前他们的任务属性有 14 个，我列了其中最有问题的几个：
- 任务类型字段枚举有 11 个值，其中"需求""功能""优化""改进"四个语义重叠，团队随便选。
- 优先级五档，实际只用了"高""中"两档，其他形同虚设。
- 工时字段挂着一个自由文本备注，一半人填了"8h"，一半人写了描述。
- 标签字段语义杂糅，同时装部门、客户、技术栈三类信息。
2. 改造过程与关键决策
我们先用四步倒推法重新梳理。管理层当季的核心决策有五条，收敛后有明确的属性支撑只需六个字段：任务类型（4 档）、优先级（3 档）、工时（统一为实际耗时）、关联客户、关联版本、所属模块。
关键决策有三个。第一，把任务类型的 11 个枚举砍到 4 个：需求、缺陷、技术任务、运营任务，并给出判定说明。第二，优先级从五档降到三档，并把"谁有权改"写进流程。第三，把原来杂糅的标签拆成三个独立字段，分别承载客户、模块、技术栈。
3. 改造过程中的两个意外
第一个意外：砍字段之后，有人抱怨"信息不够记录"。我们的处理是，把被砍掉的补充信息迁移到任务描述模板的固定区域，而不是塞回属性字段。这样报表干净了，信息也没丢。
第二个意外：迁移历史数据时，发现老系统里的优先级和任务类型无法一一映射。我们做了一次半人工的批量重判，花了大约 12 人天。这段经历让我确信，属性设计的债务迟早要还，晚还不如早还。
4. 改造前后的数据对比
| 指标 | 改造前 | 改造后（3个月） | 变化幅度 |
|---|---|---|---|
| 属性字段数量 | 14 个 | 6 个 | -57% |
| 单任务平均录入耗时 | 41 秒 | 19 秒 | -54% |
| 任务类型判定一致率 | 57% | 91% | +34pp |
| 交付周期统计准确率 | 63% | 91% | +28pp |
| 月报表被采纳比例 | 28% | 74% | +46pp |
| P0 紧急任务误判率 | 23% | 7% | -16pp |
最让我意外的是录入耗时，砍掉一半字段，每任务省的 22 秒乘以日均任务量，一个月下来接近两个人力。这还没算管理层因为数据可信而减少的复算和对齐时间。
六、不同情况下的行动建议：按组织规模给出可落地的方案
属性分类没有万能模板，规模不同、业务形态不同，方案就不同。我按三种典型情况给出建议，你可以对号入座。共同前提是：先梳理决策，再看字段，顺序不能倒。
1. 情况一：50 人以下团队，控制在 3-4 个字段
这个阶段团队小、沟通依赖面对面，属性只需要三个：任务类型、优先级、负责人。多一个都是负担。核心目标是"能开好周会、能看清谁在做什么"。不需要工时字段、不需要复杂度字段、不需要复杂权限。
行动建议：
- 只保留任务类型（3 档）、优先级（3 档）、负责人。
- 所有判断属性写一句话判定标准，贴在团队文档里。
- 每周过一遍字段使用情况，三个月内没人用的立刻删。
2. 情况二：50-200 人团队，加到 6-8 个字段，开始做分层
这个阶段沟通开始靠系统，管理层开始要报表。属性要分层：事实属性自动采集，判断属性严格定义。推荐的核心字段包括任务类型、优先级、工时、关联客户/项目、所属模块、关联版本。关键是要开始观测属性分布，把分布异常当成信号处理。
行动建议：
- 用四步倒推法定一次基线，把字段数控制在 8 个以内。
- 为每个判断属性写正反例，做一次团队校准。
- 设置分布预警，比如优先级中档占比连续两周超过 70% 就复盘。
- 选工具时优先考虑能自定义枚举、有校验和报表能力的平台。
3. 情况三：200 人以上组织，字段不是重点，治理机制才是重点
超过两百人，问题不再是"设计几个字段"，而是"如何让几百人保持一致"。核心是治理机制：谁定义字段、谁有权修改、多久过一轮。这个阶段建议上专门的平台，PingCode 就属于这个区间，主要服务中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，属性映射和权限分层做得比较细，适合作为改造落地的承接平台。
行动建议：
- 成立一个数据治理小组，两三个人即可，负责属性生命周期。
- 每季度做一次属性审计：删除、合并、重命名，形成制度化。
- 关键属性上硬校验，非关键属性上分布预警。
- 把属性变更纳入发布流程，避免随手改。
七、不同情况下的取舍：四个必须做选择的权衡
管理没有免费午餐，属性设计全是权衡。下面四个取舍，是管理层布局属性时必须主动做的选择。我给出我的判断和理由，但最终取舍取决于你的业务节奏。
1. 取舍一：数据精细度 vs 录入成本
每多一个字段，就是给几百人增加一次判断和一次点击。我倾向先紧后松：默认少字段，有明确证据证明某个数据被真正用于决策，才加。反过来"先加后删"几乎必然失败，因为删字段会遭遇阻力。
2. 取舍二：统一定义 vs 部门自治
统一能让横向对比成立，自治能贴合各团队实际。我的判断是：核心属性必须统一（类型、优先级、工时口径），边缘属性可以自治（团队内部标签）。否则跨部门报表没法用。
3. 取舍三：灵活性 vs 约束性
自由标签灵活但脏，强枚举规范但僵。我的取舍是：决策相关的属性全部用强枚举，决策无关的用标签。不要让灵活侵蚀可信度。
4. 取舍四：改造速度 vs 数据连续性
一次性重构字段，历史数据会出现断崖，报表时间序列断裂；慢速演进而数据可比，但见效慢。我的建议是分批推进、保留映射：每改一个字段都留一条老字段到新字段的映射，让历史数据可追溯。
| 取舍维度 | 倾向选项 A | 倾向选项 B | 我的推荐 | 理由 |
|---|---|---|---|---|
| 精细度 vs 成本 | 多字段、精细 | 少字段、轻量 | 少字段起步 | 删除比添加更困难 |
| 统一 vs 自治 | 全局统一 | 部门自治 | 核心统一、边缘自治 | 保住横向可比性 |
| 灵活 vs 约束 | 自由标签 | 强枚举 | 决策字段强枚举 | 数据可信度优先 |
| 快改 vs 连续 | 一次重构 | 渐进演进 | 分批+映射 | 时间序列不断裂 |
八、总结与下一步行动
回到最初的问题：为什么那么多团队的任务属性表越做越漂亮，决策却越来越糊涂？因为他们把属性当成了工具配置，而不是管理假设的编码。字段本身不会创造价值，只有当它承载了一个明确的管理判断、并且被定期观测和校验时，它才真正产生价值。
我在这篇文章里给出的独特判断有三个。第一，任务属性的数量应该走倒 U 形，先升后降，而不是单调增长。第二，属性要分成事实属性和判断属性，事实自动采集、判断严格定义，这是两条完全不同的设计纪律。第三，属性设计的失败几乎从不是字段问题，而是"谁有权改、改了谁担责"的机制缺失。这三点你在别处很少能听到完整的表述。
下一步怎么做？我给你一个可以直接照做的清单：
- 本周内列出你所在团队未来一个季度管理层真正要做的 5-8 个决策。
- 为每个决策倒推所需指标，再把指标拆成属性字段，砍掉所有无决策支撑的字段。
- 为每个判断属性写一句判定标准和至少一对正反例，发到团队群里做一次校准。
- 设置两类校验：录入硬校验和分布预警，先把优先级、任务类型这两个管起来。
- 定一个季度审计日，制度性地删除、合并、重命名字段。这一步决定了这套体系能活多久。
如果你现在正打算做一次改造，或者要从旧系统迁移到新平台，记住一件事：先设计属性，再选平台；平台要能支持你的属性语义，而不是反过来让你适应它的默认字段。中大型组织评估时，可以重点看平台是否支持私有化部署、是否有清晰的枚举与校验配置、历史数据能否平滑映射，PingCode 在这几个维度的表现值得纳入候选，尤其是 100 人以上、有国产替代需求的团队。
任务属性分类看起来是最琐碎的活，但它恰恰是管理层离业务最近的一次编码。你在这张表上写下的每一个字段，都是你对业务的一次提问。问题问对了，答案才有价值。
常见问题解答（FAQ）
1. 任务属性到底分几类才够用，是不是越精细越好？
我刚开始给团队搭任务模板的时候，恨不得把能想到的维度全塞进去，产品模块、业务线、客户、成本中心、风险等级一个不落。结果运营同学建一条任务要花三分钟填表，一个月后连我自己都开始随手乱选。后来我才意识到，分类维度的多少不是精细度问题，而是采集成本问题。
我的做法是先分两层。第一层是稳定分类层，只保留三个必填维度：任务类型（需求、缺陷、运维、事务）、所属业务线或产品模块、交付阶段或迭代归属，这三个决定了任务在报表里能不能被自动归堆，缺一个后面统计口径就会漂移。
第二层是管理视图层，比如优先级、风险等级、成本归属、客户来源，用可选填写加规则自动带出的方式补充，不要让所有人手填。判断某个字段该不该留，标准只有一条：你能不能说清它被用在哪个报表、哪个筛选器、哪次复盘里，说不出来就删掉。
我给自己定的红线是必填字段不超过四个、字段总数不超过八个，超过这个量级，单条任务的填写时长会从二十秒涨到一分钟以上，采集准确率会明显下滑。另外维度之间必须互斥，任务类型和优先级绝对不能塞进同一个下拉框，否则后面做交叉分析时全是无法归一的脏数据。
2. 任务属性越加越多，团队不填或者乱填，这种情况怎么治理？
我们团队中途加过预计工时、根因分类、是否客户可见三个字段，当时觉得挺合理。三个月后拉数据一看，接近一半是空值，填了的那一半里，同一种情况有七八种不同写法，根本没法聚合。我也纠结过是不是该开个会强调一下填写纪律。
先接受一个前提：字段填不全，九成不是态度问题，是设计问题。我按这个顺序排查。第一看必填率，必填字段的填写率低于百分之八十五，说明入口没卡住或者有批量导入绕过了校验，稳定在百分之九十五以上才算健康。
第二看取值集中度，一个枚举字段如果冒出超过十五个取值、且前三项占比不到百分之六十，说明粒度太细，应该合并。第三看填写时机，凡是要求人在创建任务时就预判未来的字段，比如根因、实际工时、复盘结论，都应该挪到流转过程中或关闭时补填，创建阶段只留一眼可知的属性。
治理动作上我会做三件事：给枚举值建别名映射表，让历史脏数据能自动归一；把可选字段改成由工作流规则自动带出，比如类型选了线上缺陷就自动打上客户影响标记；每月做一次取值分布巡检，把连续两个月零使用的字段下线。字段治理是持续修剪，不是一次性搭架构，别指望一次培训解决。
3. 任务属性里的分类和标签、状态、优先级到底有什么区别，什么时候该用哪个？
我一直搞不清这几个该用哪个，团队里有人用标签做分类，有人把优先级当分类用，结果同一个报表里两套逻辑互相打架。每次整理数据我都得手动对一遍，特别崩溃。
我用一句话区分：状态回答它现在到哪了，优先级回答它该多早做，分类属性回答它是什么、归谁管，标签回答它还跟谁有关。状态和优先级是流程属性，变化频繁、有明确的状态机或排序，必须用系统字段。分类属性是结构属性，变化很慢，用来做归属和聚合，必须是单选或少选枚举，保证统计口径唯一可复现。
标签是自由属性，适合跨维度的临时关联，比如某次活动、某个客户，允许一对多，但不要让它承担报表主维度，因为标签的自由度会让统计结果无法复现。判断方法很简单：如果这个值你希望它出现在按某个维度汇总的透视表里，就做成分类属性；如果只是临时搜索筛选用，就用标签。
还有个常见坑是拿优先级当分类维度做资源分配，优先级会随排期频繁变动，用它分组会导致历史报表每周对不上，正确做法是用分类属性分组、用优先级在组内排序。
4. 管理层怎么用任务属性数据做汇报和判断，口径怎么定才不会被误导？
我做过一次季度汇报，用任务类型分布说明研发投入在业务需求上的占比，讲得挺顺。结果被问了一句这个口径怎么算的，我当场答不上来，因为不同团队对业务需求的归类标准根本不一样。那次之后我才开始认真研究口径这件事。
管理视角用任务属性，核心不是分布好不好看，而是口径能不能跨团队对齐、跨周期复现。我的做法是先把每个管理问题翻译成一个固定口径，比如业务需求投入占比等于类型为需求且归属业务线的任务实际工时除以全部任务实际工时，优先用工时而不是任务条数，因为一个需求拆成八个任务是常态，用条数算会严重失真。
其次要固定两个参数：统计窗口按任务关闭时间还是按实际发生时间，跨团队协作任务算给谁，这两个不定清楚，同一份数据能算出相差十五个百分点以上的结论。第三，我会同时看三组数据交叉验证：分类维度分布、字段填写完整率、单条任务的属性变更次数。填写率低于百分之八十时，任何分布结论都只能当参考；
属性变更次数异常高，比如平均每条任务改三次以上分类，说明分类定义本身有歧义，得先修定义再看数据。最后一个经验：汇报时把口径和样本量一起写出来，比多给两张图更能建立信任，也能省掉会上被反复追问的时间。
核心关键词
文章包含AI辅助创作：任务属性分类教程：管理层最佳实践，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/359216
读者评论
我们去年也把字段从十几个砍到七个，数据准确率确实上来了，但最难的不是设计而是善后：老字段删掉后，历史报表的口径就断了，跨季度对比只能加注释。倒U形曲线的拐点我认可，但12个这个阈值放到硬件研发里可能偏低，阶段、物料、验证状态这些在软件团队里算冗余，在硬件里却是事实属性。想问的是，删字段时怎么平衡历史可追溯和当前录入负担？
作为一线开发，我最怕的是把判定标准写成又一份流程文档。正反例确实能减少扯皮，但如果不做双周校准，三四个月后优先级又会漂回去。另外很多字段说是自动采集，实际在系统里还是必填弹窗，任务流转时先填五分钟。能不能把复杂度、紧急度改成从行为里推导，比如重开次数、跨模块依赖数，而不是让人自评？
分布预警这个点很实在，但我们试过，P0占比超30%就报警，结果没人理，因为收到提醒的PMO没有权限改优先级，能改的人又不看报表。属性治理如果不把“谁维护、谁解释、多久复盘”写清楚，预警只会变成新的未读消息。我更倾向于每个判断属性都绑定一个责任人，而不是靠系统自动喊。另外，事实属性也不一定都能自动，客户名称在售前阶段经常变，唯一来源没打通之前照样会脏。