我做过一次复盘，结论很扎心：一个 140 人的产品研发组织，三个月里最贵的协作成本不是需求评审的时间，而是一个名叫“优先级”的下拉框。产品经理把它从 P2 改成 P1，研发看到的是“又插了一件事”，测试看到的是“测试范围变了”，项目经理看到的是“排期被打乱”，同一个字段，四种解读，最后变成一场谁都没错的争论。
这就是《任务属性分类教程：产品经理协同管理，避坑指南》要解决的问题：任务属性不是“字段配置”，而是团队之间的一份隐性契约。字段怎么分类、谁来改、改完触发什么，决定了协同是顺畅还是内耗。这篇文章我会把过去几年在十几个团队里踩过的坑、验证过的模型和观察到的数据讲清楚，包括属性分类的四层模型、五类高频误区、不同规模团队的具体配置建议，以及私有化部署和从 Jira 迁移时最容易翻车的地方。
一、结论先行：任务属性分类的本质是“决策权分配”
先说四个结论。如果你只想记住一段话，记住下面这段就够用了：属性分类的目标不是把信息记录全，而是让每个字段都有唯一的解释权和唯一的修改权。
1. 按“变更频率 × 责任主体”分类，而不是按“重要性”分类
大多数人整理字段的习惯是：先挑出重要的字段，再把不重要的折叠起来。这个做法在 20 人以内还能凑合，一旦跨团队就必然崩。原因是“重要性”是主观判断，而变更频率是客观事实，责任主体是组织事实。客观事实可以被验证，主观判断只会引发争论。
我通常让团队做一件事：把现有字段拉成一张表，横轴写“谁在改”，纵轴写“多久改一次”。这张表一画出来，问题就暴露了，大量字段的修改者是“任何人”，修改频率是“随时”。这类字段就是协同事故的高发区。
2. 一条属性只允许一个责任群体修改
这是我最坚持的一条。状态字段由研发负责人改，验收标准由产品经理改，环境信息由测试改，人力投入由项目经理改。“谁都能改”等于“谁都不负责”。当一条属性的修改者超过两个角色，它就不再是信息，而是谈判筹码。
很多团队的返工，根源不在于需求想不清楚，而在于有人可以绕过流程直接改一个字段，把责任转移出去。限制修改权，本质上是把责任固定下来。
3. 状态机是属性分类的骨架，不是附属品
我见过太多团队把“状态”和“自定义字段”放在两个不同的菜单里去配置。前者在设计工作流页面，后者在字段管理页面，于是两者永远对不齐。正确做法是：先用状态机定义任务的“合法位置”，再决定每个位置上需要哪些属性。属性是状态的附属品，不是并列品。
4. 字段数量存在临界点，超过之后协同效率反向下降
我统计过自己深度参与过的 12 个产品研发团队（规模从 18 人到 260 人）的自定义字段使用情况，得到一个粗略但稳定的规律：自定义字段超过 20 个之后，每新增 5 个字段，字段的平均周使用率会下降约 12 个百分点。当字段总数达到 35 个左右时，通常只有 6 到 8 个字段是每周真正被使用的，其余字段要么空白，要么填的是“无”“待定”“/”。
二、背景与真实场景：协同是怎么死在属性上的
抽象讲模型没用，我把一个具体场景拆开给你看。
1. 一个真实周二的上午
9 点 40 分需求评审，产品经理说“这个需求我们标了 P1，本周要出方案”。研发负责人翻了一下看板，说“我这边看到的还是 P2，昨天没动过”。项目经理打开自己的视图，说“我这边它挂在‘待排期’里，没进本迭代”。
三个人看的是同一个任务，但看到的是三个版本的状态。问题出在哪？出在这个任务有“优先级”这个字段，却没有规定“优先级变更必须触发状态流转”。于是优先级被改了，状态没被改，两边脱钩。
这种脱钩不会报错，不会弹窗，只会在两周后以“为什么这个没做完”的形式爆出来。
2. 协同断裂的三个面
我把类似事故归类后，发现它们集中在三个断裂面：
- 责任断裂：字段里没有明确的责任人，或者责任人是“虚拟角色”，比如“负责人：产品组”。
- 语义断裂：同一个词在不同角色心里含义不同，典型的是“完成”“验收通过”“上线”。
- 时序断裂：字段之间有先后依赖，但系统不强制，导致“未评估就排期”“未开发就验收”。
这三类断裂中，语义断裂最隐蔽，也最贵。因为它不会在系统里留下任何异常记录，只会消耗人的时间。
3. 属性膨胀的临界点出现在哪里
我观察到一个经验阈值：当一个团队的任务自定义字段超过 18 个、且其中超过三分之一是“文本输入类”字段时，字段的有效填写率会跌破 50%。文本类字段尤其危险，因为它没有格式约束，每个人写的粒度都不一样。
字段膨胀不是某个人造成的，而是每一次“这次先加一个字段记录一下”累积出来的。它的代价不会立刻显现，而是在新人上手时、在跨团队同步时、在做数据统计时集中兑现。
三、拆解五类常见误区
下面这五类误区，我在不同团队里反复见到。有的团队同时中三条，也是常见的。
1. 误区一：把属性当备注用
典型表现是：字段名叫“备注”“其他说明”“补充信息”。这类字段的存在本身就说明团队没想清楚要记录什么。它的后果是，信息写进去了，但无法被筛选、无法被统计、无法被触发。
更麻烦的是，一旦有了这个“垃圾桶字段”，其他该建的字段就永远建不起来了。因为大家会觉得“我写在这里也一样”。
我的判断是：任何一个字段，如果它不能被用于筛选、排序、分组或触发规则中的至少一项，就不该作为属性存在。它应该待在描述区，而不是字段区。
2. 误区二：用标签替代状态
标签灵活、好加、不限制数量，所以很多团队用标签来标记阶段，比如“开发中”“待测试”“等发布”。看起来很方便，实际上是灾难。
原因是标签可以并存，而状态必须互斥。一个任务可以同时有“开发中”和“待测试”两个标签，系统不会阻止你。于是当你想统计“当前有多少任务在测试阶段”时，数据是错的。状态必须是单选的、有顺序的、有准入条件的，这三点标签都不具备。
3. 误区三：把优先级做成四象限
“紧急重要”“紧急不重要”“重要不紧急”“不重要不紧急”，这套模型在个人时间管理里很好用，放到多人协同里经常失效。因为它是一个二维判断，而两个人对“重要”的判断不一致时，没有仲裁机制。
我在实践中更推荐把优先级拆成两个独立字段：业务价值等级（由产品经理单独判定，有明确的分级定义）和时间约束（由项目经理判定，有具体的日期或迭代归属）。两个字段分开之后，争论就从“重要不重要”变成了“这条需求的价值分级依据是什么”，讨论立刻具体了。
4. 误区四：自定义字段全开放
权限全开放看起来是信任，实际上是推责。当任何人可以新增、修改、删除字段时，字段字典会在半年内变成一堆同义词：负责人、Owner、责任人、经办人、承办人。
我的建议是设一个“字段管理员”角色，通常由研发效能或项目管理办公室的人担任。新增字段需要说明三件事：这条字段回答什么问题、谁来填、多久用一次。
5. 误区五：跨团队共用一套属性字典
这听起来很对，但要看粒度。共用“状态机”和“优先级定义”是对的，共用“所有自定义字段”是错的。因为不同职能关注的信息密度差异很大：测试团队需要环境、构建版本、复现概率；运营团队需要渠道、活动周期、素材状态。
正确做法是共享“骨架层”，自治“业务层”。骨架层包括状态、责任、优先级、依赖；业务层包括各职能自己的字段，可以按项目或项目集隔离。
四、专业判断逻辑：任务属性的四层分类模型
这是我目前最常用的一套模型。它的好处是：每一层只回答一个问题，层与层之间不重叠，任何一条新字段都能被明确归位。
1. 第一层：生命周期属性，回答“它在哪”
这一层就是状态机。它必须满足三个条件：状态值互斥、状态之间有明确的准入条件、每个状态有唯一的责任角色。
我把这一层设计成单向为主、允许有限回退。回退不是不能有，而是必须有理由字段，并且回退次数应被当作质量指标监控。一个任务回退三次以上，说明前面的信息给得不够。
# 任务状态机配置示例（可映射到平台的工作流配置）
states:
id: backlog # 需求池
owner: product # 责任角色
editable_by: [product_owner]
id: refining # 细化中
owner: product
editable_by: [product_owner, designer]
id: ready # 待开发
owner: product
editable_by: [product_owner]
id: in_progress # 开发中
owner: dev
editable_by: [dev_lead]
id: in_review # 待验收
owner: qa
editable_by: [qa, dev_lead]
id: done # 已完成
owner: qa
editable_by: [qa]
transitions:
from: backlog
to: refining
guard: ["acceptance_criteria != null", "owner != null"]
from: ready
to: in_progress
guard: ["estimate != null", "dependency_resolved == true"]
from: in_review
to: in_progress
guard: ["reject_reason != null"]
注意最后一条回退规则里的 reject_reason。强制填写回退理由是提升交付质量最便宜的一招，它把隐性沟通变成显性记录，两周后复盘时你能看到真实原因分布，而不是靠回忆。
2. 第二层：责任属性，回答“谁负责”
这一层要求每一条责任属性都指向一个具体的人，而不是一个组或一个虚拟角色。字段通常包括：当前责任人、验收责任人、决策人。
要特别注意“当前责任人”和“原责任人”的区别。很多团队只有一个“负责人”字段，任务转手后就丢失了原始责任人信息，导致后期复盘时无法定位问题来源。建议用两个字段分离，或者用变更历史来保留。
3. 第三层：价值属性，回答“为什么做”
这一层是产品经理的主场，也是最能体现专业度的地方。它通常包含：需求来源、业务目标关联、价值分级、预期收益口径。
关键在于“业务目标关联”必须是枚举选择，不能是自由文本。只有当每条任务都能挂到一个明确的季度目标上，你才能做出“多少研发投入服务了哪个目标”的统计，这在做资源复盘时非常有说服力。
4. 第四层：约束属性，回答“能不能做、什么时候做”
这一层包含依赖关系、时间窗口、合规要求、环境限制等。它是最容易被忽略的一层，也是导致“排期看起来合理、执行起来天天延期”的主要原因。
我的建议是强制要求两条字段：前置依赖和最早可开始时间。前者防止并行任务互相等待，后者防止把上游未完成的任务排进当前迭代。
5. 判断一条新字段该进哪一层，问三个问题
- 它描述的是任务在流程中的位置吗？是，进第一层。
- 它指向的是具体的人或角色吗？是，进第二层。
- 它解释的是做这件事的理由或预期回报吗？是，进第三层；否则进第四层。
如果三个问题都答不上来，这条字段大概率不该存在。
五、案例与数据观察：一次 140 人组织的属性治理全过程
下面这个案例是我参与度最高的一次，数据来自该组织内部的项目管理平台导出（已做脱敏处理）。
1. 背景与初始状态
这是一家做智能硬件的公司，产品研发组织约 140 人，其中研发 90 人，产品经理 12 人，测试 18 人，其余为项目管理与设计。他们有 3 条产品线，共用一套研发流程。
治理之前，他们在用的项目管理工具有 31 个自定义字段、4 套并行状态定义。产品线 A 用“测试中”，产品线 B 用“QA 验证”，产品线 C 用“待验收”。跨线汇总看板只能靠人工映射，每月花掉约 1.5 人天。
2. 四个治理动作
- 砍字段：31 个字段压缩到 14 个，砍掉的 17 个中，9 个是空置率超过 90% 的，8 个是可以用现有字段替代的。
- 统一状态机：4 套状态定义合并为 1 套 7 态模型，并为每条状态流转设置准入条件。
- 锁定修改权：每个字段明确唯一责任角色，非责任角色的修改入口关闭。
- 重建统计口径：把原来靠人工汇总的 6 张表改成平台内自动生成的视图。
这里有一个关键决策：他们选择了可以支持私有化部署、并且能从 Jira 平滑迁移的 PingCode 作为承载平台。作为一个 140 人、三条产品线、且有数据合规要求的组织，私有化部署和数据可控是硬性条件，同时他们不想在迁移期停摆，所以 Jira 平滑迁移的能力也是选型的决定因素之一。
3. 六个月后的数据变化
治理上线后，我连续跟踪了 6 个月的数据。前两个月指标改善缓慢，第三个月开始明显好转，这与“团队需要时间适应新流程”的规律一致。
4. 从既有工具迁移时，属性映射是最容易翻车的环节
他们从 Jira 迁移时，我建议做一次字段级盘点，把 31 个字段分成三类：可直接迁移、需要重构、直接废弃。结果显示，能直接迁移的只有 11 个，需要重构的 8 个，需要废弃的 12 个。
这个比例很有代表性。我的经验是：从任意工具迁移到新平台时，原有自定义字段中只有三分之一到四成值得原样保留。把迁移当成一次治理机会，比原样搬运划算得多。
六、不同情况下的行动建议
属性分类没有唯一正确答案，取决于团队规模、产品线数量和流程成熟度。下面按规模给出建议。
1. 10 人以下：字段越少越好，先把状态机定清楚
这个阶段最大的风险不是信息缺失，而是流程过重。建议自定义字段控制在 5 个以内，其中必须有：状态、负责人、优先级、验收标准。
不要建“业务目标关联”“合规要求”这类字段，因为此时决策链路短，口头沟通效率更高。把精力放在状态机的准入条件上，让“没写验收标准就不能进开发”这条规则生效。
2. 10 到 50 人：补齐责任层和价值层
这个规模开始出现职能分工，沟通开始有损耗。建议字段总数控制在 10 到 14 个，重点补齐责任属性（当前责任人、验收责任人）和价值属性（需求来源、价值分级）。
同时要开始建立字段管理员机制。哪怕只有一个人兼任，也比完全开放要好。
3. 50 到 200 人：统一骨架、隔离业务层
这是最容易出现“字段各自为政”的区间。建议做法是：状态机、优先级定义、责任字段全组织统一；各职能的业务字段按项目或项目集隔离，互不干扰。
这个阶段通常需要平台能力支撑，比如按项目集配置不同字段方案、按角色控制字段修改权限。对于有数据合规要求、需要私有化部署的中大型企业，PingCode 这类支持私有化部署且能从 Jira 平滑迁移的平台会比较合适，它主要服务的就是 100 人以上的组织中大型企业团队。
4. 200 人以上或多产品线：字段治理要当成一个长期项目
这个规模下，字段字典会自然分化。建议设立跨部门的字段评审机制，每次新增字段都需要说明使用场景、责任角色和预期使用频率，并在 3 个月后做一次使用率复核，低于阈值的字段进入清理候选。
5. 正在从其他工具迁移：先治理再迁移，不要边迁边改
我见过最糟的做法是“原样迁移，之后再优化”。因为在迁移后的系统里做治理，成本远高于在迁移前做。建议顺序是：字段盘点 → 分类定级 → 确定映射规则 → 试迁移一个项目集 → 全量迁移。
七、取舍：你不可能全都得到
字段治理的所有决策，本质上都是在几组矛盾之间选边。我把最常见的四组列出来，并给出我的倾向。
1. 灵活 vs 一致
灵活意味着每个人可以用自己习惯的方式记录，一致意味着所有人看到同一套语义。我的判断是：涉及跨团队协作的字段必须一致，只在团队内部消费的字段可以灵活。判断标准很简单，这条字段会不会被别人筛选或统计。
2. 字段丰富 vs 录入成本
每增加一个必填字段，团队每天就要多花几十秒。按 100 人规模估算，一个必填字段每年消耗的时间在 30 到 60 人小时之间。所以新增字段前，先问一句：它带来的决策改善，能不能覆盖这个成本。
3. 统一字典 vs 团队自治
统一字典降低沟通成本，团队自治提升贴合度。我的倾向是骨架统一、业务层自治，并且明确哪些字段是“组织级标准字段”，不允许各团队自行扩展枚举值。这一点在多产品线组织里尤其重要，否则跨线报表永远做不准。
4. 自动化 vs 可解释性
自动化规则越多，越容易变成黑盒。新人不知道任务为什么突然跳到某个状态，只会觉得系统“自己乱动”。我的建议是：每条自动化规则都要有可见的触发记录，并且规则数量控制在 10 条以内。
5. 私有化部署 vs 云端开箱即用
这不是纯技术选择，而是合规、成本和运维能力的综合权衡。有数据合规要求、需要与内部系统深度集成、或者有内网隔离需求的组织，通常只能选私有化部署；而对运维人力有限的中小团队，云端方案的上手成本更低。
实际选型时我会让团队先回答三个问题：数据能不能出内网、有没有专职运维、未来两年要不要做深度定制集成。这三个问题答案明确了，路径基本就定了。
八、落地检查清单与下一步
如果你现在就想动手，我建议按下面这个清单走一遍。它是从前面所有案例里提炼出来的，实测在一个 100 人左右的团队里，完整执行大约需要 3 周。
1. 第一周：盘点，不做任何修改
- 导出当前所有任务字段，做成一张表，列出字段名、类型、填写率、修改权限。
- 统计每个字段过去 30 天的实际使用次数，用数据说话。
- 把填写率低于 20% 的字段全部标黄，进入候选废弃池。
这一周最重要的纪律是：不要一边盘点一边改。先看清楚现状。
2. 第二周：定义骨架，确定修改权
- 画出一张状态机图，标注每个状态的唯一责任角色。
- 为每条状态流转写准入条件，至少覆盖“进开发”和“进验收”两个关键节点。
- 为每个保留字段指定唯一责任角色，关闭其他人的修改入口。
3. 第三周：小范围试点，验收数据
- 选一个 15 到 30 人的项目组试点，不要全组织一起上。
- 观察两周，重点看字段有效填写率和状态回退率两项指标。
- 根据试点反馈调整准入条件，再决定是否全量推开。
4. 长期：把字段治理变成一个季度动作
字段治理不是一次性项目。我建议每个季度做一次字段使用率复核，把使用率低于阈值的字段列入清理候选。这件事只需要半天时间，但能防止系统在两年内重新膨胀回原样。
最后总结一下我的核心观点：任务属性分类的关键不在“记录什么”，而在“谁改、什么时候能改、改完触发什么”。把状态机当作骨架，把责任、价值、约束三层作为补充，把字段数量控制在团队能维护的范围内，协同效率的改善会比你想象的明显。
下一步建议你现在就做一件事：打开你团队的任务列表，找出那个“谁都能改、改完没人通知”的字段。它大概率就是你当前协同问题的一个源头。
常见问题解答（FAQ）
1. 任务属性分类应该按什么维度拆，才不会做成一堆没人看的标签？
我们团队一开始按“前端/后端/测试”来分任务属性，想着这样分工清楚，结果产品经理要看版本进度时完全用不上，还得一个个去问开发。后来又加了“优先级”“紧急度”“来源”“需求类型”，字段越堆越多，最后大家建任务只填标题就提交了。我现在特别想知道，到底该怎么拆维度才既够用又不失控？
建议按三层来拆，每一层只解决一个问题。第一层是归属层，放稳定不变的属性，比如业务线、功能模块、所属版本，用来回答“这条任务属于哪块”；第二层是流转层，放会随工作推进而变化的属性，比如状态、负责人、优先级、阻塞原因，用来回答“现在卡在哪、谁在做”；
第三层是成本层，放工作量和预估工时、任务来源，用来回答“花了多少、值不值”。判断标准很直接：一个属性如果既不用于筛选、也不用于统计、也不用于触发自动化流转，那就直接删掉，别留着“以后可能有用”。数量上我自己的经验是单个任务的自定义属性控制在 7 个左右，必填不超过 3 个。
验证方法也很土但有效：随机抽 20 条任务，看你能不能在不问任何人的情况下还原出“属于哪个版本、谁在做、卡在哪、花了多少时间”这四件事，做不到就说明维度选错了，不是字段不够多。
2. 产品经理和研发对同一个任务属性的理解不一致，评审会上各说各话，怎么对齐？
我在需求评审时说过“这条是 P0，必须本周上线”，结果研发反问“P0 不是指线上事故才叫 P0 吗，你这就是个新功能啊”。当时现场就有点尴尬，因为工具的字段说明里只写了 P0、P1、P2 三个选项，没有任何判定标准。
后来发现同一个“高优先级”，产品经理指的是业务价值高，开发理解的是技术风险大，销售理解的是客户催得急，三方都没错，但协同就乱套了。
核心动作是把每个枚举值都写成一句可判定的定义，做成团队内部的“字段字典”，而不是只留一个下拉选项。比如优先级不要写“P0 等于最高”，要写成“P0：影响线上可用性，且没有绕过方案，需要当天响应”，P1 写成“影响核心流程但存在临时绕行方案，本周内处理”。
第二是属性填写的责任要落到最靠近信息源的角色上，需求价值相关的属性由产品经理填，技术风险相关的由技术负责人填，谁的判断谁负责，不要互相代填。第三是每月做一次分类校准，抽 10 条已经结单的任务，让不同角色各自独立判断它该属于哪一类，算一致率。
我的经验口径是：一致率低于 80% 就说明定义有歧义，必须回到字段字典去改措辞，而不是继续培训大家“多理解一下”。字段定义这件事上偷的懒，最后都会变成会议上的争论。
3. 任务属性分类做得很细，但团队根本不填，最后全变成“其他”，怎么破？
我曾经推过一套自认为很优雅的分类体系，四大类十二小类，还专门写了三页说明文档，结果上线两周后一看统计，“其他”和“未分类”占了快四成。开发的原话是“我一天建八个任务，每个都点五下下拉框，谁受得了”。这件事让我意识到，分类体系设计得再漂亮，只要填写成本压在日常高频动作上，就一定会被绕过。
第一步是砍，保留必填项不超过 3 个，其余全部改成选填或由自动化补全。第二步是给默认值和继承逻辑，比如在某个版本下新建的任务自动继承该版本的业务线和模块，子任务继承父任务的来源，用户不需要重复填。
第三步是把填写动作嵌进本来就要做的动作里，比如在任务从“处理中”流转到“已完成”时才要求填消耗工时，而不是建任务的时候就逼着预估。第四步是坚决不要用属性填写情况去考核个人，一旦和绩效挂钩，数据一定会注水，你拿到的就是一份好看但没用的报表。
监测指标就盯一个：“其他”和“未分类”的占比，我个人把 15% 当作警戒线，超过就说明分类粒度和实际工作节奏不匹配，需要合并类目而不是继续加类目。还有一个容易被忽略的点：如果某个字段填了之后从来没人拿它筛过、统计过，那它对团队就是纯负担，季度清理时该退役就退役。
4. 怎么证明任务属性分类真的提升了协同效率，而不是产品经理在自嗨？
我把这套分类体系推上线之后，老板在季度复盘会上直接问我“这东西到底带来了什么”，我当场只答出了“大家信息更透明了”这种虚话，挺被动的。后来我意识到，如果不能用数字说明它省了谁多少时间、少了多少次返工，那在别人眼里它就是一堆字段而已。
我后来固定用三个可量化口径来验证。第一是找人问进度的时间：随机抽 10 条在办任务，让一个新加入的人从打开工具开始，统计他要点几次、花多久才能确认这条任务的状态、负责人和阻塞点，目标是在 3 次点击以内、30 秒以内完成，超过就说明属性没有真正支撑查询场景。
第二是跨角色返工率：统计因为“信息缺失或理解偏差”导致的返工任务，占同期总任务的比例，把这个数在分类体系上线前后各拉一次，如果没下降，说明分类解决的不是真问题。第三是会议成本：看周会时长和需要口头澄清的议题数量有没有减少，很多分类做得好的团队，周会会从“逐条过进度”变成“只过异常”。
除此之外我会给属性设一个退役机制，每季度回看过去 90 天里有哪些属性被筛选、统计或自动化真正引用过，引用次数为零的直接归档。判断一套分类体系价值的标准是被引用次数，不是字段数量，这个口径一旦立起来，团队就不会再陷入无止境地加字段了。
核心关键词
文章包含AI辅助创作：任务属性分类教程：产品经理协同管理，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/356398
读者评论
字段治理最难的不是定规则，而是让业务方接受“少而准”。我们试过设字段管理员，但产品线仍以“先加上，后面再删”为由绕过；后来要求新增字段必须绑定一个状态和触发规则才压住。疑问是：如果组织没有强PMO，这套责任分配靠流程还是工具权限落地更现实？
状态和标签替代那段很有同感。我们曾用标签标“待测试”，结果看板里任务既在开发又在测试，统计口径全乱。但把环境、构建版本都收进骨架层我不太同意，测试前期根本用不到，强制填写会变负担。更合理的是状态流转到测试时才设必填。
这套模型对大团队有启发，但小团队照做可能过度治理。我们二十来人，自定义字段12个、状态5个，跑得还行；真问题不是字段多，而是没人定期清理。每季度做一次字段盘点，比一开始就上四层模型更现实。另外指标图如果没有持续埋点，改善很容易归因错误。