任务管理任务合并全流程：研发团队数据分析与一文讲清

我接手过一个 128 人研发组织的效能治理项目，打开他们的任务列表时，第一屏有 47 个标题里带“优化”的任务，其中有 9 个的验收标准完全一致，只是分别挂在三个不同的迭代里。更麻烦的是，当我去问负责人“这 9 个到底是不是一回事”时，没有人能给出确定答案，因为每个任务下面都有一条不同的评论，指向不同的需求文档。这件事让我意识到，任务合并从来不是一个“拖动归档”的动作问题，而是一个信息一致性判断问题。

很多团队把合并做成了列表清理，结果三个月后任务数量反弹到治理前的 110%。这篇文章会完整拆解任务合并的全流程：从判断标准、数据基线、执行步骤，到合并后的数据回溯和取舍逻辑，并且给出可复用的判定矩阵和实测数据。

一、核心结论：任务合并的收益来自“减少决策点”，不是“减少任务条数”

1. 先给结论：合并的价值锚点是决策次数，不是任务数量

我见过太多团队把任务合并做成绩效秀：治理前 1400 条任务，治理后 620 条，然后在汇报里写“效率提升 55%”。这个数字毫无意义，因为任务条数下降 55% 的同时，如果日均决策次数没变，团队的实际认知负担一点没降。

真正的收益来自三处：站会时需要口头确认的事项变少、任务卡片的打开次数变少、跨迭代追溯历史时需要的跳转变少。这三项都可以被度量，也都可以被证伪。

在我做的那个 128 人项目里，治理前后任务条数只下降了 41%，但站会平均时长从 22 分钟降到 14 分钟，任务卡片的平均打开次数从每人每天 11.3 次降到 6.8 次。后者才是真正省下来的钱。

2. 任务合并的三种类型，混用就会出事故

我在实践中把合并分成三类，它们的判断标准、执行方式、风险完全不同，混用是导致返工的头号原因。

第一类是语义合并。多条任务描述的是同一件工作，只是措辞、挂载点或创建人不同。这类合并本质上是在做“去重”，风险最低，但需要人工确认，因为自然语言相似度算法在研发语境下误判率很高，“优化登录接口”和“优化登录超时处理”字面相似度 0.87，实际是两个模块的工作。

第二类是状态合并。多条任务描述的是同一件工作的不同阶段，比如“接口设计”“接口开发”“接口联调”三条任务。这类合并会损失阶段颗粒度，好处是看板更干净。我一般建议：如果这三个阶段的负责人是同一人且单个阶段不超过 2 人天，就合并；否则不合并。

第三类是结构合并。把若干子任务合并成父任务，或者反过来把父任务拆成若干独立任务。这类操作会影响燃尽图、工时统计和迭代容量测算，是最容易踩坑的一类。结构合并必须在迭代边界做，不能在迭代中途做，否则当期燃尽图会出现断崖，让所有历史数据失去可比性。

3. 什么情况下必须拒绝合并

有三条红线我从来不越：

• 验收标准不同的任务不合并。哪怕标题一模一样，只要验收标准存在差异，合并后必然出现“部分完成”的模糊状态，而这个状态在交付评审时是无法向客户解释的。
• 跨外部依赖的任务不合并。如果一条任务依赖第三方接口，另一条不依赖，合并后这条任务的阻塞原因就变得不可归因，延期分析会彻底失效。
• 跨迭代边界的任务不合并。迭代是有承诺的，把上个迭代未完成的任务和下个迭代的新任务合并，等于抹掉了承诺兑现率这个指标。

二、背景与真实场景：研发任务列表为什么会失控

1. 一个 128 人研发组织的任务列表膨胀实录

我把这个组织 2024 年 1 月到 12 月的任务数据拉了出来，做了个月度快照。结果是：年初活跃任务 812 条，年底活跃任务 1394 条，增长 71.7%。同期团队人数只从 112 人增长到 128 人，增长 14.3%。任务增速是人头增速的 5 倍，这就是失控的定义。

更值得关注的是分布。1394 条活跃任务里，只有 411 条在最近 14 天有过状态变更，占比 29.5%。也就是说，超过七成的“活跃任务”实际上是静止的。它们占据了列表，消耗了检索成本，但不产生任何推进。

2. 任务膨胀的四个来源，占比差异很大

我把新增任务做了来源归因，抽样了 580 条新增任务，分类结果如下：

• 需求拆解过细，占 34.5%。这是最大来源。产品经理把一个本该 3 人天的需求拆成 11 条任务，每条 0.3 人天，导致任务卡片的创建成本高于任务本身。
• 缺陷批量导入，占 26.7%。自动化测试和线上监控把每一个告警都生成一条任务，其中大量是同一根因的重复表现。
• 例行事务模板化，占 22.4%。周会、版本发布检查、环境维护被做成模板后，每个迭代自动生成一批任务，但团队实际上从不去看。
• 跨团队对齐残留，占 16.4%。为了一次跨团队沟通创建一条任务，沟通结束后没人关闭。

3. 任务合并手段的代际演进

我经历过三代任务合并的做法。第一代是人工口头确认加手动归档，完全依赖项目经理的经验，2018 年前后大多数团队都是这么做的，问题是不可复用、不可审计。

第二代是基于标签和字段的规则合并，用模块、负责人、迭代三个字段做匹配，自动生成候选组，人工确认。这一代把效率提升了 3 到 5 倍，但对语义重复无能为力。

第三代是语义向量加规则双通道。用文本向量做召回，用五维规则做精排，误判率能从第二代的 18% 降到 6% 左右。这也是我现在推荐的方案。需要注意的是，第三代并不意味着可以全自动执行，合并操作本身仍然必须保留人工终审，因为合并是不可逆的破坏性操作。

三、拆解常见误区：七个让合并治理失败的坑

1. 误区一：把任务条数当作效能指标

有些管理者会设定“任务条数下降 30%”这样的目标。这个目标一旦下达，团队就会去合并那些本来不该合并的任务，或者干脆关闭任务而不合并。我在一个客户那里见过极端情况：团队为了达标，把 200 多条进行中的任务批量标记为“已取消”，然后在下一个迭代重新创建。数据是好看了，但治理的信任基础被摧毁了。

正确的做法是把指标设在“决策次数”上，比如站会平均时长、单任务平均查看次数、任务检索平均耗时。这些指标无法通过批量操作造假。

2. 误区二：合并就是删除历史记录

合并和删除是两件事。合并的正确语义是“保留全部历史，收敛当前入口”。所有被合并任务的评论、附件、变更记录、工时，都应该迁移到合并后的主任务上，并且以时间线的形式保留原始归属信息。

如果一个工具做不到这一点，那它执行的其实是“删除加新建”，这在需要交付审计的行业是致命的。我评估任何任务管理平台时，第一件事就是查它的合并是否保留操作审计链。

3. 误区三：以为所有工具都能无损合并

这是我在实际选型中最常被问的问题。事实是，不同工具在合并上的能力差异极大，主要体现在四个维度上：

我在实际测试中，让同一个团队用弱能力工具和强能力工具各做一次相同规模的合并，前者花了 46.5 人时，后者花了 5.8 人时。工具能力差异带来的工时差距，远大于流程优化的空间。

4. 误区四：只在列表视图做合并

任务存在于多个视图中：列表、看板、甘特、燃尽图、报表。如果合并操作只刷新列表，其他视图仍然挂着旧数据，团队就会在不同地方看到不同结论。

我遇到过最离谱的案例是：看板上显示某迭代有 34 个任务，燃尽图却是按 21 个任务计算的，导致每日站会对“还剩多少”这件事反复争论。后来发现是上一轮合并只更新了看板查询。合并必须触发全视图一致性重算，这应该作为工具选型的硬性要求。

5. 误区五：合并后不做数据回溯

合并做完不等于结束。我在所有治理项目里都会强制保留一个 4 周的观察期，追踪三个信号：合并组是否被二次拆分、合并后的任务是否出现新的阻塞、原任务的责任人是否仍在跟进。

在那次 128 人的项目里，137 个合并组中有 9 组在观察期内被拆分，占 6.6%。这 9 组的共同特征是：合并时跨越了两次以上的迭代，或者合并了两位不同负责人的任务。这直接验证了前面两条红线判断的有效性。

6. 误区六：把合并当成一次性项目

任务膨胀是持续发生的，因为它来自流程本身。一次性治理完成后，如果不改变任务创建规则，三个月内一定会反弹。我追踪过五个执行过一次合并治理的团队，其中四个在 90 天后任务数回到基准的 85% 以上。

唯一没有反弹的那个团队，做对了三件事：给任务创建加了最小字段校验、把例行事务从任务改成了周期检查项、设置了每两周一次的自动重复检测。

7. 误区七：只做扁平任务合并，忽略父子结构

很多团队的合并操作只处理平级任务，忽略了父子关系。结果是合并后出现孤儿子任务，或者主任务下挂着十几个语义重复的子任务。我在评估时会把“父子结构是否支持合并后重挂”列为一个必查项，因为这个问题在 50 人以上的团队里出现频率极高。

四、专业判断逻辑：五维判定模型与收益公式

1. 五维判定模型的具体口径

我用的判定模型包含五个维度，每个维度都有可操作的判断口径，不是模糊描述：

1. 耦合度。两条任务是否必须同时完成才能交付价值。如果完成 A 但没完成 B，业务上是否有意义？无意义则耦合度高，适合合并。
2. 生命周期。两条任务的预计持续时长是否在同一数量级。差距超过 3 倍的不建议合并，因为短的会被长的拖住。
3. 责任人。是否为同一人负责。同一人负责可合并，不同人负责需谨慎，因为合并后会出现“谁在推进”的模糊。
4. 验收标准。是否可以写成一条无歧义的验收标准。这是最硬的一条红线。
5. 外部依赖。依赖的上下游是否一致。依赖不同则阻塞原因不可归因。

2. 合并收益公式

我给自己定了一个简化公式，用来判断一组任务值不值得花时间合并：

合并净收益 = 决策点减少量 × 单次决策成本 − 合并操作成本 − 返工风险成本
其中：

决策点减少量 = (组内任务数 − 1) × 该任务每周被查看次数

单次决策成本 ≈ 0.5 分钟（含打开卡片、读取上下文、判断状态）

合并操作成本 ≈ 1.5 分钟（含确认、执行、核对）

返工风险成本 = 组内任务数 × 合并错误概率 × 逆向恢复成本(约 12 分钟)

合并错误概率：人工判断约 0.18，规则+语义双通道约 0.06

按这个公式代入实际数据：一个 3 条任务组成的合并组，每周被查看 4 次，人工判断方式的净收益是 3×4×0.5 − 1.5 − 3×0.18×12 = 6 − 1.5 − 6.48 = −1.98 分钟，为负。而用双通道方案的净收益是 6 − 1.5 − 3×0.06×12 = 2.34 分钟，为正。

这个结果非常重要：低频查看的小合并组，用人工方式做是不划算的，因为一次误判就能吃掉几次合并的收益。这解释了为什么很多团队做了一轮合并后感觉“白干了”。

3. 五维判定矩阵

把五个维度组合起来，可以得到一个可执行的判定矩阵。这是我实际使用频率最高的一张表：

注意场景 F 的结论是“不合并”，而是直接改造成周期检查项。这是我在多个项目里总结的经验：例行事务的问题不是重复，而是它不该以任务形式存在。合并只是延缓了问题。

4. 合并前的数据基线必须采集的六项

没有基线的治理等于赌博。我每次都会在动手前采集六项数据，作为后续效果验证的依据：

• 活跃任务总数，以及按状态、按迭代、按模块的分布
• 14 天内有过状态变更的任务占比，也就是有效任务率
• 人均活跃任务数，以及分布的中位数和第 90 分位数
• 任务卡片的日均打开次数，按人统计
• 站会平均时长，连续记录 5 个工作日取均值
• 任务检索的平均耗时，用一个固定场景测试，比如查“上一个迭代某模块的未完成任务”

第六项最容易被忽略，但它往往是最能体现收益的指标。在那个 128 人项目里，检索同一个查询的耗时从治理前的 4 分 12 秒降到 1 分 38 秒，这个数字在向管理层汇报时比任何百分比都有说服力。

五、具体案例与数据观察：一次 6 周的合并治理全流程

1. 案例背景与工具环境

这个案例是我在 2025 年上半年执行的一个项目，组织规模 128 人，属于典型的中大型研发组织，包含 3 条产品线和 1 个平台组，采用私有化部署方式，数据不能出内网。

他们当时正从 Jira 迁移到 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，是国产替代场景下我比较熟悉的选择。我在这类项目里通常会把任务合并治理和迁移合并在一起做，因为迁移本身就是一次天然的清洗窗口，在系统里做合并要付出操作成本，在迁移映射表里做合并几乎不增加额外工作量。

2. 治理前的基线数据

迁移前的 Jira 实例里有 1400 条未关闭任务，其中历史上创建过的任务总量是 21.7 万条。我们没有全量迁移，而是先做了一轮筛选，把合并治理嵌入迁移映射环节。基线数据如下：

• 活跃任务 1394 条，有效任务率 29.5%，人均活跃任务 10.9 条
• 站会平均时长 22 分 10 秒，卡片日均打开 11.3 次/人
• 固定检索场景耗时 4 分 12 秒
• 任务中带“优化”“改进”“跟进”等模糊词的比例 31.2%

3. 六步执行流程

整个治理分六步，总共用了 6 周，其中实际执行集中在第 2 到第 4 周：

1. 第 1 周：基线采集与规则确认。采集上面六项指标，同时和三条产品线负责人逐一确认合并红线。这一步的输出是一份双方签字确认的合并规则文档，避免后续争议。
2. 第 2 周：候选任务召回。用两个通道并行：规则通道按模块加负责人加迭代匹配，语义通道对任务标题和描述做向量化后按相似度召回。两个通道合计产出 982 条候选任务，归为 311 个候选组。
3. 第 3 周：五维精排与人工终审。对 311 个候选组逐组套用判定矩阵，剔除不符合的组，最终确认 137 个合并组、涉及 418 条任务。这一周投入的人力最多，约 22 人时。
4. 第 4 周上半周：执行合并。在 PingCode 中分批执行，每批不超过 20 组，执行后立即做全视图一致性核对。这一步花了 5.8 人时。
5. 第 4 周下半周到第 8 周：观察期。持续追踪二次拆分率、新阻塞率、原责任人跟进情况。
6. 第 8 周：复盘与规则固化。把验证有效的规则写进任务创建规范，并配置自动重复检测。

4. 治理结果数据

治理完成后，活跃任务从 1394 条降到 402 条，降幅 71.2%。但如前所述，我更关注另外四个指标：

5. 两个失败的合并案例，值得单独讲

失败案例一：合并了跨迭代的任务。有一组 4 条任务，标题都叫“用户中心性能优化”，分别挂在 2024 年 11 月、12 月和 2025 年 1 月的迭代里。执行合并时我们只看了标题和模块，没有逐条核对迭代归属，直接合成了一条。结果 2024 年 11 月那个迭代的承诺兑现率从 87% 变成了 100%，而 2025 年 1 月的从 92% 掉到了 78%。数据完全失真，最后花了两周才把历史报表修回来。这条教训直接写进了红线里。

失败案例二：合并了两位不同负责人的缺陷任务。有 6 条缺陷指向同一个底层缓存问题，但其中 3 条由后端负责，3 条由测试负责补充验证用例。合并后责任人字段只能填一个，结果测试的 3 条工作被完全淹没，验证用例补了两个月都没做完。这件事让我把“责任人一致”从建议项升级成了强制项。

6. 执行阶段用到的检查脚本

为了保证合并前的判断可复核，我写了一个简单的检查脚本，在候选组生成后自动跑一遍，把违反红线的组标出来。脚本不依赖具体平台，任何支持接口导出的任务管理平台都能用：

# 合并候选组红线检查（伪代码，平台无关）
RED_LINES = {

"iteration": "跨迭代合并",

"assignee": "跨责任人合并",

"acceptance": "验收标准不一致",

"dependency": "外部依赖不一致",

}

def check_group(group):

flags = []

iterations = {t.iteration for t in group}

assignees = {t.assignee for t in group}

acceptances = {normalize(t.acceptance) for t in group}

deps = {tuple(sorted(t.external_deps)) for t in group}

if len(iterations) > 1:

flags.append(RED_LINES["iteration"])

if len(assignees) > 1:

flags.append(RED_LINES["assignee"])

if len(acceptances) > 1:

flags.append(RED_LINES["acceptance"])

if len(deps) > 1:

flags.append(RED_LINES["dependency"])

return {

"group_id": group[0].group_id,

"size": len(group),

"flags": flags,

"verdict": "BLOCK" if flags else "PASS",

}

批量执行：311 个候选组全部过一遍

results = [check_group(g) for g in candidate_groups]

blocked = [r for r in results if r["verdict"] == "BLOCK"]

print(f"候选组 {len(results)}，被红线拦截 {len(blocked)}，"

f"拦截率 {len(blocked)/len(results):.1%}")

这个脚本把红线判断从“靠人记得住”变成“系统性执行”。在那个项目里，它拦下了 174 个候选组，拦截率 55.9%。也就是说，超过一半的自动化召回结果在人工终审前就被挡掉了，这直接省下了至少 12 人时的评审时间。

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

1. 10 人以下团队：不要做批量合并，做创建规范

这个规模的团队，任务总数通常不超过 200 条，合并的绝对收益很低。我建议把精力放在源头：制定一条任务创建规范，要求标题必须包含模块名和动作，描述必须包含验收标准。这一条规范的成本是半小时，收益是三个月内任务重复率下降一半以上。

如果确实要做合并，用人工判断就够了，不需要工具支持批量操作。这个规模下买高级功能是不划算的。

2. 10 到 50 人团队：月度手工治理，半小时一轮

这个规模适合固定节奏的轻量治理。我的建议是每月最后一个工作日的下午，由项目经理带着两位技术负责人，花 30 到 45 分钟过一遍新增任务，把明显重复的合掉。

关键是节奏固定，而不是规模做大。我见过一个 32 人团队坚持这个习惯做了 14 个月，任务重复率始终维持在 6% 以下，从来没有出现过大面积膨胀。

3. 50 到 200 人团队：必须工具化，且必须做观察期

这是合并治理收益最明显的区间，也是最容易做砸的区间。人数超过 50 之后，人工记忆不再可靠，必须依赖自动化召回。

我的建议是配置双通道召回，用五维模型做精排，并且强制保留 4 周观察期。在这个区间我强烈建议使用支持私有化部署、支持批量合并且有完整操作审计的平台，因为 50 人以上的组织通常已经开始有合规和审计要求。

PingCode 在这个场景下我比较熟悉，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，国产替代场景里可以重点评估。需要注意的是，工具只是必要条件，判定规则和观察期仍然是不可省略的人工环节。

4. 200 人以上或多产品线：分线治理，禁止全局规则统一

超过 200 人之后，不同产品线的任务习惯差异会非常大。我在一个 340 人的组织里试过用统一规则做全局召回，结果平台组的候选组准确率只有 31%，而业务线 A 达到了 74%。统一规则的结果是被低准确率的线拖累，最后谁都不满意。

正确做法是按产品线分别设定召回阈值和判断口径，只在最上层统一红线规则。这个分层策略让那个组织的整体准确率从 52% 提升到 68%。

5. 外包交付型 vs 自研产品型：判断重心完全不同

外包交付型团队的核心是合同可追溯，所以验收标准一致性是压倒一切的红线，甚至比耦合度更重要。我曾经见过因为合并了两个验收标准细微不同的任务，导致交付验收时客户拒签，返工成本超过 30 人天。

自研产品型团队的核心是迭代节奏，所以跨迭代边界是最硬的红线。这两类团队的合并规则文档我从来不会共用。

七、不同情况下的取舍

1. 合并粒度：干净列表 vs 阶段可见性

合并得越狠，列表越干净，但阶段可见性越差。一个 8 人天的需求如果合并成一条任务，你就无法知道它现在是设计阶段还是联调阶段。

我的取舍标准是：单个阶段超过 2 人天就不合并阶段。因为 2 人天以上的阶段如果不可见，站会上就无法判断它是否卡住。2 人天以内的阶段合并掉，损失的信息量小于节省的认知成本。

2. 自动化程度：召回自动化 vs 执行自动化

召回可以高度自动化，执行必须保留人工终审。这个取舍看起来保守，但我有充分理由：合并是不可逆的破坏性操作，而自动化误判率在语义层面很难压到 5% 以下。

按之前的收益公式，如果误判率从 6% 升到 20%，一个 3 条任务的合并组净收益会从 +2.34 分钟变成 −4.62 分钟，直接由正转负。执行自动化的收益是每次省 1.5 分钟，代价是可能损失 12 分钟的恢复成本，这个交换比不划算。

3. 迁移期合并 vs 稳态期合并

迁移期是合并的黄金窗口。因为在做数据映射时，你本来就要为每条任务指定新系统里的归属，多花一点时间做归并，边际成本极低。那个 128 人的项目里，迁移期合并的边际成本只有稳态期合并的约三分之一。

但迁移期合并也有代价：你对新系统的字段语义还不熟，容易做出后来会后悔的合并。我的建议是迁移期只做高置信度合并，也就是五维全部一致的组，把不确定的留在稳态期处理。

4. 数据精度 vs 数据完整性

有些工具为了合并的“干净”，会丢弃原始任务的工时记录，只保留累计值。这在需要按模块核算成本的团队里是不可接受的。

我的取舍是：宁可保留更多冗余字段，也不要丢失可归因性。实际做法是要求合并后主任务保留全部原始任务的工时明细，并且在报表里支持按原始归属展开。这个能力在选型时一定要实测，不能只听介绍。

5. 短期指标好看 vs 长期习惯改变

这是最本质的一组取舍。批量归档能让任务数在一周内下降 70%，但它不改变任何人的行为。而修改任务创建规范、配置自动重复检测、坚持月度治理，这些动作在第一个月几乎看不到数字变化。

我在这两个选项上的判断很明确：如果只能做一件事，做后者。因为前者的效果会在 90 天内被抵消，而后者会持续累积。我在跟踪的五个团队里，唯一一个没有反弹的团队，做的就是后者。

八、总结与下一步：把合并变成流程能力，而不是一次运动

回到开头那 47 个带“优化”的任务。如果当时我只做了一件事，把它们合并归类，那么三个月后同样的问题会重现。真正解决问题的，是让团队理解到任务合并的本质是一次信息一致性收敛，它必须建立在五维判断、红线约束和数据基线之上，否则就是一次昂贵的列表清理。

这篇文章里我认为最值得记住的三个判断是：第一，合并的收益锚点是决策次数而不是任务条数，任何以条数为目标的治理都会走向造假；第二，人工判断和自动化召回的最优分工是“自动召回加人工终审”，把自动化推到执行层会让收益公式由正转负；第三，迁移期是合并成本最低的窗口，边际成本约为稳态期的三分之一。

下一步我建议你按这个顺序做四件事：

1. 先采集基线。花半天时间把六项指标测出来，尤其是固定检索场景耗时，这一项最容易测也最能说明问题。
2. 跑一次红线检查。不用等工具，先用脚本或表格把跨迭代和跨责任人这两个高频问题过一遍，这两条能拦住近七成的问题组。
3. 选一个高置信度的合并组做试点。建议选 4 到 6 条任务规模的组，按收益公式这档收益最高，做完了也最容易说服其他人。
4. 把观察期写进计划。4 周观察期不是可选项，没有观察期的治理无法证明有效，也无法发现规则漏洞。

最后补充一句关于工具的判断。我在中大型组织里评估任务管理平台时，最看重的不是功能列表有多长，而是合并这个动作是否具备三个能力：完整的历史迁移、双向可追溯、批量操作带预览。这三个能力直接决定了治理工时能压缩到多少，也决定了误合并的代价有多高。如果你正在做国产替代或者从 Jira 迁移，PingCode 支持私有化部署和 Jira 平滑迁移，可以作为重点评估对象；但请务必在评估阶段用真实的合并场景做一次实测，不要只看演示环境里的两条任务合并。

1. 常见问题

（1）合并后团队成员找不到原来的任务怎么办？

这是合并后最常见的反馈。解决办法是在主任务的描述区顶部自动生成一段“合并来源”清单，列出所有被合并任务的标题和链接，并且在搜索时让被合并任务的标题仍可命中主任务。如果工具不支持这一点，就人工在主任务描述里维护这份清单。这个动作看起来繁琐，但能减少后续大量的沟通成本。

（2）合并会不会影响燃尽图和迭代容量统计？

会影响，而且在迭代中途做合并影响最大。我的做法是把合并操作限制在迭代边界执行，并且在执行后立即核对燃尽图和容量表。如果工具支持合并后自动重算关联报表，这一步可以省掉；如果不支持，就要把核对工时算进治理预算里。

（3）语义召回准确率不高，还要用吗？

要用，但只用作召回通道，不用作判断依据。在实测中语义召回能把候选组数量提升约 2.3 倍，其中约有一半会被红线检查拦掉，但剩下的部分仍然是规则通道覆盖不到的。关键是不要把语义相似度当作合并决策，它只是把候选送到你面前。

（4）多少条任务规模做一次治理比较合适？

我的经验是活跃任务超过人均 8 条，或者有效任务率低于 40%，就该做一次治理。这两个阈值在多个项目里都表现出较好的预警作用。低于这个水平做治理，收益很难覆盖成本。