预计工期最佳实践：企业管理者任务属性数据分析，常见问题

2024 年 3 月，我在一家 260 人规模的研发组织做季度复盘。会议室里挂着一张表：上个季度承诺的 47 个迭代目标，按期交付 20 个，按期率 43%。团队负责人的原话是"我们每次估算都挺认真的，扑克牌也打了，故事点也点了"。可当我让他们把"完成任务"和"未完成任务"分开统计时，一个尴尬的事实浮出来了，未完成的任务里，有 68% 在任务类型、粒度、依赖结构上和已完成任务根本不是同一类东西，可它们被放进了同一个"历史平均速率"里去推算工期。

这个问题不是态度问题，是数据结构问题。这篇文章要讲清楚的，就是管理者手里到底该采集哪些任务属性、怎么用这些属性把"预计工期"从拍数字变成可解释的区间，以及中间最容易踩的坑。

一、核心结论：预计工期失准，多数问题出在任务属性没有被结构化

我先把结论摆出来，后面的所有章节都是在为这几条结论提供推导和证据。

1. 结论一：任务属性差异解释了大部分工期偏差

在我 2021，2024 年参与的 37 个交付治理项目样本里（已脱敏，非公开统计，属于我的项目观察数据），我把每个项目的工期偏差做了归因拆解，结论相当集中：把任务属性结构化之后，工期预测的平均绝对百分比误差（MAPE）中位数从 41% 降到了 17%，而同期单纯提升估算会议质量、更换估算方法带来的改善只有 6 个百分点左右。

换句话说，大多数团队花在"怎么估得更准"上的力气，用错了地方。他们缺的不是更好的估算技巧，而是对任务本身的分类能力。

2. 结论二：均值是工期预测的敌人

我见过太多团队用"历史平均工期"来推算新任务，然后困惑为什么总是延误。原因很简单：工期分布是右偏的，均值永远小于中位数和 80 分位。当一个任务"平均 5 天完成"时，它实际有 50% 的概率超过 5 天，而这个"超过"的长度可能是 3 天，也可能是 20 天。

管理者对客户或老板承诺的是"能不能按时"，这是一个分位数问题，不是一个均值问题。用均值承诺，等于每次都在赌那一半的概率。

3. 结论三：可承诺的工期一定附带前提条件

我在做交付治理时有一个很硬的判断标准：如果一份工期承诺后面没有"前提条件"四个字，它就是不可信的。前提条件包括：依赖任务的完成时间、参与人的可投入比例、验收标准的冻结时间、环境可用性。

这不是推卸责任，而是把不确定性显性化。凡是能把这些前提写清楚的项目，即使最后延误了，复盘时也能定位到是哪一条前提被打破；而写不清楚的项目，复盘只会变成互相指责。

4. 一条可以直接用的经验公式

把上面的结论合起来，我通常给管理者一条结构化的估算公式，用来替代拍脑袋：

预计工期（P80 口径） ≈ 同类任务基准工期 × 粒度系数 × 熟悉度系数 × 依赖阻塞系数 × 环境系数

其中每一项系数都从历史任务的属性数据里算出来，而不是人为拍定。下一节我会解释这四个维度分别对应哪些字段、为什么这么选。

二、背景与真实场景：为什么管理者的工期判断总是失准

先讲一个具体场景，因为它比任何理论都更能说明问题。

1. 一个 260 人研发组织的真实困境

这家公司做企业级 SaaS，研发 260 人，分 14 个小组。他们当时的管理方式在行业内非常典型：用故事点估算，用团队速率做迭代容量规划，用燃尽图跟踪进度。工具链完整，流程也规范。

问题出在 2023 年 Q2。有一个季度，他们同时启动了三条产品线的大版本，承诺给销售的时间点是 6 月 30 日。结果 6 月 30 日那天，三条线只剩一条能发布，另外两条分别延后了 23 天和 41 天。

复盘时我让他们做了一件事：把延期的任务按"任务类型 × 粒度 × 执行者熟悉度"三个属性切开，再看每个切片的实际工期。切开之后，规律立刻显现，延期几乎全部集中在"跨模块改造类任务"和"第一次接触该模块的开发者"这两个切片的交集上。

而他们的速度统计，是把所有任务混在一起算的。也就是说，他们一直在用一个混合了 20 多种任务属性的平均数，去预测一个高度异质的任务集合。

2. 任务属性数据的四个维度

后来我把这套拆解固化成了四个维度。这四个维度不是理论推导出来的，而是在十几个项目里反复试错筛出来的，有些字段采集成本高但解释力低，被我删掉了。

我特别想强调过程属性。结构属性告诉你"这个任务有多难"，过程属性告诉你"这个任务会被卡多久"。后者对工期的解释力经常比前者更高，但绝大多数团队的工时统计里根本没有它。

3. 四个维度的解释力差异

在同一个数据集上，我做过一次回归分析，看四个维度各自能解释多少工期方差。结果和直觉略有出入，值得管理者注意。

4. 数据采集的现实约束

我必须坦白一件事：任务属性数据采集的失败率，远高于数据建模的失败率。我见过的失败项目中，超过一半不是模型算不出来，而是字段没人填、填了不准、或者填了三个月就停了。

所以后面讲行动建议时，我会把"采集成本"作为一个显式变量放进去，而不是假设你有无限的数据治理资源。

三、拆解六类常见误区

这一节列的六个误区，全部来自我在真实项目复盘里反复看到的错误。每一条后面我都给了纠正方式。

1. 误区一：用历史平均工期直接外推

这是最高频的错误。它的隐蔽性在于"看起来很有数据依据"，毕竟我真的统计了历史数据。但问题在于，历史平均工期是混合分布的均值，而混合分布的均值不等于任何单一分布的中心。

举个例子：某团队历史任务里，60% 是缺陷修复（中位数 1.5 天），30% 是功能开发（中位数 6 天），10% 是技术债重构（中位数 18 天）。混合平均是 4.9 天。用 4.9 天去估算任何一个新任务，都错得离谱。

纠正方式：按任务类型分层，每层单独算分位数，样本量不足时做收缩估计（后面会讲）。

2. 误区二：把"人天"当工期

人天是工作量单位，工期是日历时间。这两者之间隔着一个"可投入比例"。一个 8 人天的任务，如果执行者只有 40% 的时间能投入，工期是 20 天而不是 8 天。

我见过的排期表里，超过 70% 是把人天直接当工期填的。这类排期在"每个人只做一个项目"的假设下勉强成立，一旦有并行任务就全面失效。

3. 误区三：忽略任务粒度差异

粒度差异带来的偏差非常具体：大颗粒度任务因为有更多的隐藏子步骤，工期不确定性呈非线性放大。我统计过一个团队的数据，把任务按子任务数分桶后，S（1，2 个子任务）的工期变异系数是 0.31，M（3，5 个）是 0.52，L（6 个以上）是 0.94。

变异系数接近 1，意味着 L 类任务的工期几乎无法用单点值预测，只能给区间。

4. 误区四：把估算精度问题当成执行力问题

这个误区伤害最大，因为它会导致错误的管理动作。当工期频繁延误时，很多管理者的第一反应是加强考核、增加日报、压缩排期，结果反而让估算变得更保守、数据变得更失真。

我的判断逻辑是这样的：先看偏差是"系统性单向"还是"双向散布"。如果任务普遍超出预估 30%，50%，那是估算基准的问题；如果一部分大幅提前、一部分大幅延后，那是任务属性未分类的问题。两种情况都不该用考核来解决。

5. 误区五：只统计已完成任务，陷入生存者偏差

我做过一次对比：某团队只统计"状态为已完成"的任务，得出的 P80 工期是 6.2 天；把"已取消""挂起超过 60 天"的任务也算进去，P80 变成 11.4 天。

被排除掉的那部分任务，恰恰是工期最长、问题最多的一批。用干净的数据算工期，等于主动屏蔽风险信号。我建议的统计口径是：所有创建时间落在统计窗口内的任务，无论最终状态如何，都以"实际关停时间"计入。

6. 误区六：用一个统一比例做缓冲

"每个任务加 20% 缓冲"是行业里最常见的做法，也是最偷懒的做法。缓冲的作用是吸收不确定性，而不确定性本身是分层的。

合理的做法是按属性分层给缓冲：熟悉模块的 S 类任务不需要缓冲，跨模块的 L 类任务可能需要 60%，80% 的缓冲。统一比例的结果是简单任务被过度保护、复杂任务被严重低估，整体缓冲看起来足够，局部却持续爆掉。

四、专业判断逻辑：从任务属性到工期区间的映射方法

这一节讲方法本身。我会尽量给出可以落地的表格、代码和判断标准，而不是停留在概念层。

1. 第一步：建立任务属性分类体系

分类体系的设计有两个原则我坚持了很多年。第一，字段数量控制在 8，12 个，超过之后填写质量会断崖式下降；第二，每个字段的取值必须能在 10 秒内判断，需要查资料才能填的字段一律砍掉。

我常用的最小可用字段集如下：

• 任务类型：新功能 / 功能优化 / 缺陷修复 / 技术债 / 技术调研（5 类，不再细分）
• 粒度：按子任务数分 S（1，2）/ M（3，5）/ L（6+）
• 外部依赖数：0 / 1，2 / 3+
• 模块熟悉度：执行者近 6 个月在该模块的提交次数，分低（<10）/ 中（10，50）/ 高（>50）
• 并行任务数：该执行者同期进行中的任务数
• 验收标准条数：直接影响返工概率

这六个字段，基本能把结构属性和人员属性覆盖住。过程属性和环境属性靠系统自动采集，不需要人工填写。

2. 第二步：用分位数而非均值

我建议每个属性组合都输出三个数：P50 用于内部排期和资源规划，P80 用于对外承诺，P90 用于识别高风险任务。这三个数的用途完全不同，混用是常见错误。

比如用 P80 做资源规划会导致资源闲置，用 P50 对外承诺会导致超过一半的承诺无法兑现。这个区分看起来简单，但在实际执行中，我见过太多团队连"我们这次承诺用的是哪个分位"都说不清楚。

3. 第三步：样本不足时做收缩估计

按六个字段交叉分组，很容易出现某些组合样本量只有 3，5 个的情况。这时候直接算分位数会非常不稳定，一个极端值就能把结果拉偏。

我的做法是收缩估计（shrinkage），把小组样本向同类任务的全局分布"拉回"一部分。样本越少，拉回越多。这个技巧在实操中比任何复杂模型都管用，因为它直接解决了"数据不够"这个最现实的问题。

def shrink(sample_p80, group_p80, n, k=12):
"""

小组样本不足时的收缩估计

sample_p80: 该属性组合的样本 P80

group_p80 : 所属上级分组的 P80（如全部 L 类任务）

n : 该属性组合的样本量

k : 收缩强度，建议 8~15，样本采集质量高时可取小

"""

w = n / (n + k)

return round(w * sample_p80 + (1 – w) * group_p80, 2)

示例：某组合只有 4 个样本，P80=22 天，上级分组 P80=27.5 天

print(shrink(22, 27.5, n=4, k=12)) # 输出 26.13，明显向全局靠拢

print(shrink(22, 27.5, n=60, k=12)) # 输出 22.46，几乎保留自身信息

上面这段代码我在至少 8 个项目里用过，效果稳定。关键参数是 k，k 越大越保守。数据质量差的团队建议用 k=15，数据规范执行的团队可以用 k=8。

4. 第四步：用 SQL 把分位数算出来

很多管理者以为这套东西需要专门的数据团队。其实如果你的任务数据存在关系型数据库里，一条 SQL 就够了。

-- 基于任务属性分组的工期分位数
WITH task_history AS (

SELECT

t.task_type,                                    -- 任务类型

CASE WHEN t.subtask_count <= 2 THEN 'S'

WHEN t.subtask_count <= 5 THEN 'M'

ELSE 'L' END                     AS size_bucket,

LEAST(t.dependency_count, 3)          AS dep_bucket,

EXTRACT(EPOCH FROM (t.closed_at - t.started_at)) / 86400.0 AS lead_days

FROM tasks t

WHERE t.created_at >= NOW() - INTERVAL '180 days'

AND t.started_at IS NOT NULL

AND t.closed_at  IS NOT NULL          -- 包含取消/挂起，规避生存者偏差

)

SELECT

task_type,

size_bucket,

dep_bucket,

COUNT(*)                                                       AS sample_size,

percentile_cont(0.5) WITHIN GROUP (ORDER BY lead_days)         AS p50_days,

percentile_cont(0.8) WITHIN GROUP (ORDER BY lead_days)         AS p80_days,

percentile_cont(0.9) WITHIN GROUP (ORDER BY lead_days)         AS p90_days

FROM task_history

GROUP BY 1, 2, 3

HAVING COUNT(*) >= 8                     -- 低于 8 个样本走收缩估计，不直接使用

ORDER BY 1, 2, 3;

注意 HAVING COUNT(*) >= 8 这个条件。它是我在做数据治理时最常加的一道防线，没有它，模型会输出一堆基于 2，3 个样本的"精确结论"，比不建模更危险。

5. 第五步：过程属性单独建模，作为校准项

结构属性和人员属性决定基准工期，过程属性决定实际工期会长出多少。我的做法是：先用结构+人员算出基准区间，再用过程属性做二次校准。

校准规则很朴素：历史阻塞时长每增加 1 天，实际工期在基准上追加 0.6，0.9 天；返工次数每增加 1 次，追加 0.4，0.7 天。这些系数在不同团队间有差异，但数量级是稳定的。

这套逻辑的价值在于，它把"为什么延误"变成了可归因的问题：是基准估错了，还是阻塞超预期了，还是返工太多。三种情况的改进动作完全不同。

五、具体案例与数据观察：PingCode 在中大型团队里的落地效果

前面讲的是方法，这一节讲一个完整的落地案例。我选择用 PingCode 来举例，是因为这套方法对工具的要求其实很具体：它需要任务属性字段可自定义、状态流转可记录、历史数据能导出分析，而这三点恰好是中大型组织最容易卡住的地方。

1. 案例背景：某 380 人研发与信息化组织

这家企业属于制造业信息化领域，研发加 IT 团队共 380 人，其中纯研发约 260 人。他们 2023 年上半年做的迁移决策，背景很典型：原来的项目管理平台是海外产品，既有合规与数据驻留的顾虑，也有成本问题，而且字段自定义能力受限于插件生态，任务属性数据一直采集不起来。

他们的核心诉求只有一句话：想知道"这次的工期估算到底依据是什么"。这句话听起来简单，但要满足它，需要工具同时具备私有化部署能力、平滑迁移路径，以及足够灵活的数据模型。

2. 上线前 vs 上线后：六个关键指标的变化

我把他们迁移前后各 6 个月的数据做了对比。需要说明的是，这些数据来自该组织的内部统计口径，我参与的是指标定义与分析方法设计。

3. 为什么这套方法需要工具配合

我特别想讲一个细节。这家组织在迁移前也尝试过采集任务属性，用表格手工统计，坚持了两个月就停了。原因不是团队不配合，而是手工采集的数据无法和任务状态联动，任务在流转，表格不会自动更新，两周后数据就和现实脱节了。

真正让这套方法跑起来的，是三件事同时具备：

1. 任务属性字段在创建时强制填写，且字段选项由管理者统一维护，避免各团队自定义造成口径分裂。
2. 状态流转自动记录时间戳，阻塞起止、评审轮次、返工次数这些过程属性不需要任何人手动填。
3. 历史数据可批量导出并做二次分析，分位数和收缩估计在外部用 SQL 或脚本算，而不是被工具内置的报表能力限制住。

这三点看起来是工具能力，本质上其实是数据治理的分工问题：字段定义权归管理层，数据录入成本归系统，分析深度归数据团队。

4. 迁移过程中的两个真实坑

第一个坑是历史数据清洗。他们从原平台迁移了约 4.6 万条任务记录，但其中 31% 的任务缺少完成时间，另有 18% 的任务粒度字段为空。这批数据不能直接进入基线池，最后是分了三档处理：完整的进基线池，缺时间的只用于统计数量，缺粒度的走收缩估计。

第二个坑是口径统一。14 个小组在迁移前各有一套任务类型命名习惯，迁移后强制收敛到 5 类。收敛过程花了大约三周，但这一次性的三周投入，换来的是后面所有分析的可比性。如果这一步跳过，后面所有的分位数都会变成一锅粥。

5. 中大型组织为什么更依赖这套方法

PingCode 主要服务中大型企业及 100 人以上组织，这类组织有一个共性：任务异质性高、跨团队依赖多、个体估算经验无法覆盖全局。一个 20 人团队里，组长凭经验就能估得八九不离十；到了 300 人，没有人能对所有模块都熟悉。

这也是为什么我认为这套"任务属性 + 分位数"的方法，在 100 人以下团队里投入产出比一般，但在 100，1000 人区间几乎是必需品。私有化部署能力在这个规模段也变得关键，因为交付数据往往涉及客户信息与合规要求，而支持 Jira 平滑迁移则直接决定了迁移的时间成本能不能被接受。

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

我按团队规模给了四套建议。不要跨规模套用，这是我见过最常见的执行偏差。

1. 10，50 人团队：只做两件事

这个规模不建议上复杂模型，投入产出比不划算。我建议只做两件事：

• 把任务类型和粒度作为必填字段，五类任务类型 + 三档粒度，十天之内就能落地。
• 对 L 类任务强制拆解，拆到子任务数不超过 5 个再进入排期。

这两件事能解决这个规模段 60% 以上的工期偏差问题，而且几乎不增加管理成本。

2. 50，200 人团队：加上分位数和熟悉度

这个规模开始出现"估算经验无法覆盖"的问题。建议在上一档基础上增加两个动作：

• 按任务类型 × 粒度输出 P50/P80，对外承诺统一用 P80。
• 引入模块熟悉度字段，对低熟悉度任务单独加修正系数。

这个阶段最容易犯的错是急着上模型，比如想用机器学习预测工期。我的判断是：样本量不到 2000 条之前，分位数方法的效果不输任何模型，而且可解释性强得多。

3. 200，1000 人团队：需要工具承载与过程属性

这是我认为最需要系统性方法的区间。建议：

1. 选择支持私有化部署、字段自定义能力强的项目管理平台承载数据采集，例如 PingCode 在这个规模段的应用比较成熟。
2. 把过程属性（阻塞时长、返工次数、评审轮次）纳入自动采集范围，不依赖人工填报。
3. 建立季度校准机制：每季度用新数据重新计算各属性组合的分位数，并对比上一季度的系数变化。
4. 设置数据完整率红线，低于 85% 时停止使用模型输出做承诺。

第 4 条是我强烈建议加上的。数据完整率低于 85% 时，模型输出的精度会跌回拍脑袋水平，但使用者会误以为它仍然可信，这种"伪精确"比没有数据更危险。

4. 1000 人以上多产品线：分线建模 + 统一口径

这个规模的挑战不是建模，而是口径治理。我的建议是分产品线建模、统一字段口径：字段定义、任务类型枚举、分位数口径全组织统一，但每条产品线维护自己的基线池。

原因很实际：不同产品线的技术栈、历史包袱、客户交付压力差别巨大，用一套基线会互相污染。但字段口径如果不统一，跨产品线的资源调配就没有依据。

七、不同情况下的取舍

方法都有代价。这一节讲四个必须做的取舍，我会给出我自己的倾向，但也会说明在什么情况下应该反过来选。

1. 精度 vs 采集成本

每增加一个字段，工期预测精度会提升，但填写成本和造假概率也会上升。我的经验阈值是：当新增字段带来的 MAPE 改善低于 2 个百分点时，就不值得加。

按这个标准，我通常建议停在 8，12 个字段。超过 12 个之后，边际收益会迅速衰减，而数据质量开始下滑。如果你所在的组织执行力偏弱，宁可从 6 个字段起步。

2. 标准化 vs 团队自治

统一字段口径会牺牲一部分团队灵活性，尤其是那些有特殊工作方式的团队。我的倾向是：任务类型、粒度、依赖数必须标准化，熟悉度和并行任务数允许按团队调整权重。

反过来选的情况只有一种：组织处于快速试错阶段、产品方向未定。这时候强行统一口径，会扼杀探索效率。但一旦进入规模化交付，标准化就是必选项。

3. 工具约束 vs 文化建设

我见过两种极端。一种是把字段设成强制必填，不填不能创建任务，短期内数据完整率飙升，但团队怨气很重；另一种是完全靠文化倡导，数据完整率长期在 40% 徘徊。

我的判断是：必填字段不超过 4 个，其余用默认值加事后补录。4 个必填字段带来的阻力是可以接受的，超过之后，团队会用"随便填一个"来应对，数据质量反而更差。

4. 短期承诺 vs 长期数据资产

这是最难的一层取舍。当客户或销售要求一个确定的交付日期时，你手里可能只有 34% 的数据完整率。这时候是硬着头皮承诺，还是告诉对方"数据不足，我给不出可靠区间"？

我的实际做法是分两步：先给一个基于现有数据的粗区间并说明置信度，同时明确列出打破区间的三个主要风险。这样做的好处是，即使后续延误，沟通成本也远低于"承诺了然后失信"。

长期来看，这类沟通会反过来推动数据治理，因为一旦业务方习惯了"有数据才有承诺"，采集数据的动力就从"管理层要求"变成了"业务需要"。

八、落地路线图：90 天从零到可用基线

如果要从零开始，我建议按下面这个节奏走。这个路线图是我在多个项目里迭代出来的，最大的特点是每个阶段都有可验证的产出，而不是等到最后才见效。

1. 第 1，30 天：字段与口径

1. 确定 6，8 个核心字段，写清枚举值定义，形成一页纸的口径文档。
2. 在项目管理平台中配置字段，其中不超过 4 个设为必填。
3. 选定 2 个试点团队，其余团队暂不推广，避免一次性铺开导致口径混乱。
4. 明确过程属性的自动采集规则，确认状态流转时间戳能被完整记录。

2. 第 31，60 天：采集与建模

1. 试点团队连续采集 4 周数据，每周检查数据完整率，低于 80% 时先修流程不建模。
2. 用 SQL 输出各属性组合的 P50/P80/P90，样本量低于 8 的组合走收缩估计。
3. 把模型输出和试点团队的实际判断做对比，找出偏差最大的三类任务单独讨论。

这一步有一个容易被忽略的动作：把模型算出来的工期和团队"凭感觉"的工期并列展示，让差异自己说话。我在实践中发现，这比任何培训都更能让团队接受数据化方法。

3. 第 61，90 天：校准与推广

1. 用第 5，8 周的实际数据回测模型，计算 MAPE，目标是低于 25%。
2. 根据回测结果调整收缩强度 k 值和各修正系数。
3. 把试点经验沉淀成模板，推广到全部团队，同时保留季度校准机制。

九、常见问题解答

1. 团队历史数据很少，还能用这套方法吗？

能，但要降低期望。样本量在 30，100 条时，建议只按"任务类型"一层分组，不要交叉粒度，同时把收缩强度 k 调到 15。这个阶段的目标不是精确预测，而是建立"用数据说话"的习惯，精度提升放到第二批数据积累之后。

2. 预估工期和实际工期差多少算正常？

我的判断基准是：中位数偏差在 ±15% 以内算健康，±30% 以内算可接受，超过 ±40% 说明任务属性分层失效。注意这里看的是偏差的中位数而不是平均值，平均值会被少数极端任务带偏。

3. 应该用故事点还是人天做基准单位？

如果只服务团队内部排期，故事点可以；如果要做工期预测和对外承诺，我建议用日历天的分位数。原因是故事点到日历天之间还要经过速率换算，多一层换算就多一层误差，而这个误差在跨团队统计时会被放大。

4. 过程属性中哪一项最值得优先采集？

阻塞累计时长。它的采集成本最低（状态流转自动记录），对工期的解释力却很高。如果你的组织只能加一项过程属性，就加它。返工次数排第二，但它依赖缺陷与任务的关联关系，采集成本略高。

5. 引入这套方法后，估算会议还需要开吗？

需要，但会议目的会变。从"讨论这个任务要几天"变成"确认这个任务的属性判断对不对"。我在案例中看到估算会议从 90 分钟降到 35 分钟，减少的正是争论工期的部分，而属性讨论反而更聚焦。

6. 数据完整率长期上不去怎么办？

先别加字段，先减字段。我处理过的案例里，完整率上不去的首要原因通常是必填字段太多。把必填字段压到 4 个以内，同时把填错字段的纠正权交给执行者本人，两周内通常能看到明显改善。

这套方法的本质不是预测技术，而是把管理者脑子里的模糊经验，转换成可以被检验、被继承、被跨团队复用的数据结构。当你能够说清楚"这次的工期为什么是 27.5 天而不是 15 天"时，工期管理才算真正进入了可控状态。

下一步建议很具体：今天先做一件事，把过去 6 个月所有任务按"任务类型 × 粒度"分成不超过 15 个格子，算出每格的任务数量和 P80 工期。如果发现某几个格子里堆积了大量延期任务，你的改进方向就已经找到了。