我统计过自己深度参与的 37 个项目复盘记录，真正因为"活干不完"而延期的只有 9 个，剩下 28 个延期的根因都指向同一件事，父任务失真。任务清单里每个子任务都标着"进行中"，父任务进度条停在 60% 三周不动，等到交付前一天才发现，缺的那 40% 藏在某个没人认领、也没人敢关掉的子任务里。这不是执行态度问题，是父任务管理方法的结构性缺陷：大多数团队把父任务当成了文件夹，而不是验收单元。
这篇内容把父任务管理拆成可执行的清单，包含判定标准、配置方法、误区对照、不同规模组织的行动建议，以及什么时候你该干脆放弃父任务这一层。
一、先给结论：父任务管理本质上只解决三件事
如果只允许我从十几年的项目管理实践里留下三条关于父任务的判断，就是下面这三条。它们看起来朴素，但绝大多数任务树失控的组织，都是在这三条上翻了车。
1. 父任务不是文件夹，是验收单元
文件夹的职责是"装东西"，你往里塞多少子任务都行，塞满了也不代表工作完成。验收单元的职责是"证明完成"，它必须有一个能被第三方验证的完成定义。我见过太多团队把"产品迭代 v2.3"设成父任务，下面挂 47 个子任务，这个父任务在语义上毫无验收价值，因为没有人能回答"v2.3 到底什么算做完了"。
判断标准很简单：如果父任务下面所有子任务都关闭了，你能直接对外宣布"这件事完成了"，那它才是合格的父任务。如果还需要再开一次会讨论"算不算完"，说明它的完成定义没有前置写死，它只是个文件夹。
2. 父任务只认一个责任人，且这个人不是"所有人"
我在一个 200 人的研发组织里做过统计，父任务责任人为空或填成"项目组"的，平均关闭周期是责任人为单个人的 2.7 倍。原因不复杂：责任分散等于无人负责。当父任务的负责人是一个群体，任何一次状态更新都变成了"别人会去更新"的心理博弈。
正确的做法是：父任务责任人唯一，且职责不是"干所有的活"，而是"确保这件事被完成"。这个区别很重要，前者是执行者，后者是收口人。收口人可以是技术负责人、产品负责人、交付经理，但绝不能是"某某项目组"。
3. 层级深度超过三层，协同成本就开始吃掉管理收益
任务层级每增加一层，信息在上下层之间传递时就会多一次失真的机会。我在多个组织里做过对照观察，结果高度一致：三层以内（父任务，子任务，检查项）的任务树，父任务按时关闭率明显高于四层及以上。
四层以上通常意味着组织把"组织结构"直接映射成了"任务结构"，部门、小组、个人各占一层，看起来很整齐，实际上每个跨层变更都要走一遍传播链。
二、背景与真实场景：任务树是从哪一步开始失控的
父任务管理失控从来不是一次性事故，它是一个渐进的滑坡。我把这个过程拆成三个阶段，你大概能在自己组织里找到对应的位置。
1. 第一阶段：两层结构被当成"不够专业"
最早的团队通常只有两层：一件事，拆成几件小事。这个结构简单有效，但容易给人"管理粗放"的错觉。某次评审会上有人说"我们连模块都没分清楚"，于是引入模块层，变成三层。这本身没错，错的是引入模块层之后，没有人删掉原来那些语义重叠的父任务。
结果是同一个交付物在任务树里出现了两个入口：一个按模块划分，一个按迭代划分。基层成员不知道该更新哪个，于是两个都不更新。
2. 第二阶段：跨部门协同把父任务撕成两半
当任务跨越两个部门时，最常见的做法是各自建一个父任务。前端建"前端改造"，后端建"后端改造"，两边各自排期、各自关闭。问题出在交付验收那一刻：两边都显示 100%，但联调从来没做过。
父任务被按组织结构切分，而不是按交付物切分，是跨部门协同里最贵的错误。它的代价不会在项目中期显现，只会在最后一周集中爆发。
3. 第三阶段：一次真实的延期复盘
我参与复盘过一个为期 11 周的版本交付。任务树共 4 层，父任务 23 个，子任务 180 余个。延期 9 天，直接原因是 3 个接口联调未完成。
复盘时我们拉出了完整数据：这 3 个接口对应的子任务，在延期发生前的整整 14 天里，状态一直是"进行中"，而它们所属的父任务状态是"正常"。问题在于父任务状态是人工维护的，没有人会主动去改一个看起来"正常"的任务。直到最后一周，研发负责人逐个点开 180 个子任务时，才发现问题。
这次复盘之后我们做了两件事：父任务状态改为由子任务推导，同时把层级压到 3 层。下一个迭代，同类问题的平均发现时间从 8.4 天缩短到 1.6 天。
三、七个高频误区：每个我都踩过至少一次
下面这些误区按出现频率排序。我把它们的表现、真实后果和修正动作放在一张表里，你可以直接拿去对照自己的任务树。
1. 误区一：父任务进度 = 子任务进度的算术平均
这是最普遍也最危险的做法。假设一个父任务下有两个子任务，A 是"完成核心算法"（预计 20 人天），B 是"更新文档标题"（预计 0.2 人天）。B 完成了，A 没开始，算术平均进度是 50%，但真实进度接近 0%。
进度不是数量平均，而是权重平均，权重应该按工作量或关键路径贡献度来定。如果工具的进度只能按子任务数量算，那就干脆不要显示百分比，只显示"已完成 X / 共 Y"，把判断权交回给人。
2. 误区二：父任务必须由项目经理亲自持有
我早期也是这么干的，结果就是自己成了所有任务的瓶颈。后来我算了一笔账：当我持有 18 个父任务时，每周光状态确认就要花 6 小时以上，而且这 6 小时几乎不产生任何价值。
正确的分配是：父任务交给最接近交付结果的那个人。技术模块给技术负责人，客户交付给交付经理，合规事项给法务对接人。项目经理持有的应该是跨模块的里程碑级父任务，数量控制在 5 个以内。
3. 误区三：拆得越细越可控
拆细的收益在前期，成本在后期。我把一个 60 人天的工作拆成 40 个子任务之后，光是每周的状态同步就从 20 分钟涨到了 75 分钟，而且出现了大量"为了更新而更新"的噪音。
我的经验阈值是：单个子任务的预估工作量不低于 0.5 人天，不高于 10 人天。低于 0.5 人天的，合并成检查项；高于 10 人天的，说明还没拆到位。
4. 误区四：状态自动汇总之后就万事大吉
自动汇总能解决"信息不同步"，但解决不了"定义不一致"。我见过一个父任务下面，三个子任务的"完成"含义分别是"代码合并""自测通过""客户确认"，自动汇总显示 67% 完成，但这个数字对任何人都没有决策价值。
5. 误区五：所有子任务完成，父任务才算完成
这条在瀑布式交付里成立，在敏捷迭代里经常不成立。真实场景是：一个父任务下挂了 8 个子任务，其中 2 个在迭代中期被判定为"本期不做"，需要移出。如果系统强制要求全部关闭才能关闭父任务，团队就会选择伪造关闭或者干脆不关父任务。
正确的机制是：允许子任务被"移出"而不是"关闭"，父任务的完成判定只看当前有效子任务集合。这个区别决定了数据可信度。
6. 误区六：父任务描述留空，靠子任务猜意图
父任务描述为空的任务树，在交接时会变成灾难。接手人需要逐个点开子任务才能反推父任务意图，这个成本在人员流动频繁的团队里被严重低估。
7. 误区七：把里程碑和父任务混为一谈
里程碑是时间点，父任务是工作集合。把"9 月 30 日上线"设成一个父任务，下面挂一堆子任务，会让时间点和交付物纠缠在一起。一旦日期调整，整个任务树都要重排。
| 误区 | 典型表现 | 真实后果 | 修正动作 |
|---|---|---|---|
| 进度算术平均 | 小任务拉高整体进度 | 进度虚高 30% 以上 | 改权重平均或不显示百分比 |
| 项目经理全持有 | 18 个父任务压在一个人身上 | 周状态确认耗时 6 小时 | 父任务下沉到最近交付人 |
| 拆得过细 | 单任务 0.2 人天 | 同步耗时增长 2.75 倍 | 合并到 0.5-10 人天区间 |
| 只做自动汇总 | 完成定义不一致 | 进度数字无决策价值 | 先统一完成定义再汇总 |
| 强制全部关闭 | 伪造关闭或长期挂起 | 数据可信度崩塌 | 引入"移出"状态 |
| 描述留空 | 靠子任务反推意图 | 交接成本翻倍 | 父任务描述写完成定义 |
| 里程碑当父任务 | 日期变动全树重排 | 排期维护量激增 | 时间点与工作集合分离 |
四、专业判断逻辑：一个父任务值不值得存在
我不太相信"父任务应该怎么建"这种泛泛之谈，我更愿意用一组可打分的判定标准。下面这四个维度，是我在过去几年里反复修正后定下来的。
1. 维度一：可验收性
问自己一个问题：这个父任务完成后，需要一个什么样的人、看什么样的证据，才能确认它真的完成了？如果答案模糊，这个父任务就不该存在。
可验收性弱的父任务，会在项目末期变成扯皮的中心。因为"完成"是一个主观判断，而主观判断在跨部门场景下几乎必然产生分歧。
2. 维度二：单一责任人
责任人字段必须是单值。如果组织确实需要多个角色参与，那把角色放进子任务，不要放进父任务。多责任人字段在多任务平台里几乎都会演变成"谁都不看"。
3. 维度三：时间盒边界
父任务应该有明确的开始和结束边界，而且这个边界要能被子任务继承或约束。没有时间盒的父任务会变成"永远进行中"的僵尸任务，这也是任务列表里最容易被忽略的一类噪音。
4. 维度四：状态可推导性
父任务的状态不应该靠人猜。理想状态是它由子任务状态按明确规则推导出来，规则本身是可见的、可解释的。这样当有人质疑"为什么显示正常"时，你能立刻指出是哪几个子任务在支撑这个判断。
下面是我在配置任务模型时最常用的一段结构定义，可以直接映射到多数支持自定义字段和流程的平台：
{
"parent_task": {
"title": "支付网关灰度切换",
"owner": "single_user",
"acceptance_definition": "灰度流量 100% 且支付成功率 ≥ 99.9% 连续 72 小时",
"status_rule": "derived_from_children",
"derivation": {
"done": "all_children_done",
"blocked": "any_child_blocked",
"at_risk": "any_child_due_in_days "in_progress": "any_child_started"
},
"allowed_children_depth": 2,
"child_size_range": "0.5d – 10d"
}
}
5. 五个维度的健康度评分
把这四个维度加上"子任务粒度合规率"，可以组成一个简化的健康度评分。我一般要求团队每月抽检 20 个父任务，低于 3.5 分的进入下一轮重构。
五、案例与数据观察：300 人研发组织的父任务重构
下面这个案例来自 2024 年我参与的一次系统性改造，主体是一家 300 人左右的研发组织，涉及 4 条产品线、11 个交付小组。它不是实验室环境，过程中出现过明确的阻力和反复。
1. 改造前的基线数据
我们先做了一轮基线采样，覆盖连续 6 个迭代、共 214 个父任务。核心数字是：父任务平均层级 3.8 层，子任务平均数量 9.4 个，父任务按时关闭率 58%，平均关闭周期比计划长 4.2 天。
更值得关注的是子任务数量与父任务延期率之间的关系。当单个父任务下的子任务超过 12 个时，延期率出现明显跳升，从 31% 涨到 64%。这说明"一个父任务塞进太多子任务"本身就是风险信号。
2. 改造动作：四步走
我们没有一次性推翻原有结构，而是分四步推进，每步都有可观测的指标。
- 层级封顶：把任务树强制压到 3 层，第 4 层统一转成检查项（Checklist），不参与状态汇总。
- 完成定义前置：每个父任务必须有"验收标准"字段，字段为空的任务不允许进入迭代。
- 责任人单值化：把原先 47 个"多人负责"的父任务拆成单一责任人，剩余角色转到子任务层。
- 状态推导化：父任务状态由子任务按规则推导，取消人工修改父任务状态的权限。
这四步里，阻力最大的是第四步。有几位资深工程师认为"系统自动判断不了解业务的复杂性"。我们的处理办法是保留一个"人工干预"入口，但要求必须填写干预理由，且理由会在周会上被抽样阅读。三个月后，人工干预的使用率从每周 34 次降到 4 次，说明大部分"复杂性"其实是状态定义不清造成的假象。
3. 工具侧的配置要点
这次改造落地在一个支持深度自定义工作流的研发管理平台上。我们最终选择的是 PingCode，主要原因是它在任务层级、状态推导规则、私有化部署这几块的能力能直接满足前面的设计要求，不需要靠外部脚本硬凑。
具体来说，有三点是我们评估时最看重的。第一，任务层级可以显式限制，能从系统层面堵住"无限往下拆"的口子，这比靠规范文档约束有效得多。第二，父任务状态支持基于子任务的推导规则，配合验收标准字段的必填校验，前面讲的"完成定义前置"才能落成机制而不是口号。第三，对于这家组织的安全合规要求来说，私有化部署是硬性前提，数据不出内网这一点在选型阶段就是否决项。
迁移过程也比预期顺利。这家组织原本用的是海外某主流工具，属于典型的中大型团队场景。PingCode 提供的数据迁移能力支持这类平滑迁移，字段映射和状态流对照在两周内完成，历史 3 年的任务数据基本无损保留。对于 100 人以上、开始考虑国产替代的组织来说，迁移成本和迁移后的可用性，往往比功能清单本身更值得在选型阶段重点验证。
4. 改造后的结果
改造持续了 5 个月，覆盖 4 条产品线。核心指标变化如下：父任务按时关闭率从 58% 提升到 81%，平均关闭周期从超计划 4.2 天缩短到超计划 1.3 天，周均跨层同步耗时从 9.6 小时降到 3.4 小时。
还有一个未预期的收益：因为父任务有了明确的验收标准，需求评审的平均时长反而下降了。评审时争论的焦点从"这件事要不要做"变成了"验收标准写得对不对"，后者更容易收敛。
六、落地清单：不同规模组织的具体动作
同样一套原则，在 50 人团队和 800 人组织里的落地方式完全不同。下面按规模给出建议，你可以直接对照自己的情况取用。
1. 50 人以下：先别急着上父任务
这个规模下，任务数量通常不超过几百个，靠两层结构和口头同步就能覆盖。过早引入父任务，反而会增加维护负担。
如果确实需要，只做两件事：给跨职能的工作建一个父任务，并且责任人必须是单个自然人。其他一律保持扁平。
2. 50-150 人：三层结构 + 状态推导
这个区间是父任务真正开始产生价值的阶段。核心动作是：
- 把任务树稳定控制在 3 层，第 4 层转成检查项。
- 父任务必须填写验收标准，否则不允许进入迭代。
- 开启状态推导，取消人工修改父任务状态的权限。
- 每月抽检 20 个父任务做健康度评分。
3. 150-500 人：加一层治理，但不要加一层任务
这个规模的组织容易出现"部门墙"。正确的做法不是给任务树加层，而是在父任务上增加治理字段：跨部门依赖、风险等级、上级里程碑关联。
我通常建议这个区间的组织把父任务数量和迭代容量绑定。例如一个两周迭代内，单个小组的父任务不超过 6 个，超过就要评估是否拆分迭代。这条规则能有效抑制"什么都想做"的冲动。
4. 500 人以上：父任务要分域，不要全局统一
到这个规模，全局统一的任务树几乎必然失控。可行方案是按域切分：产品域、平台域、交付域各自维护父任务体系，只在里程碑层做对齐。
同时，这个阶段的组织通常有较强的私有化部署和合规要求，工具选型要把数据主权、权限粒度、审计日志作为一级指标，而不是先看功能清单。PingCode 在这类场景里主要服务的就是中大型企业和 100 人以上组织，私有化部署能力和对既有工具的平滑迁移支持，是它在这个区间最常被提到的两个理由。
七、取舍：什么时候你该放弃父任务这一层
不是所有场景都适合父任务。硬套一套结构，比不用结构更糟。下面这几种情况，我的建议是放弃或弱化父任务。
1. 探索型、强不确定性工作
当工作内容本身还在探索阶段，比如技术预研、新市场验证，你无法预先定义验收标准。这时候建立父任务只会产生大量需要反复修改的结构。
可行替代是用"主题标签 + 时间盒"代替父任务层级，只约束周期和产出形式，不约束分解结构。
2. 强运维、持续响应型工作
值班、工单、告警处理这类工作天然是流式的，没有明确终点。给它们建父任务，会导致大量"永远进行中"的僵尸节点。
这类工作的关键是响应时效和闭环率，应该用单独的看板和 SLA 指标管理，不要混进项目任务树。
3. 工具能力不足时的取舍
如果你的工具不支持状态推导、不支持层级限制、不支持验收标准必填校验，那么强行推行父任务规范，最终会退化成"文档规定一套，系统里做另一套"。
这种情况下有两个选择：一是先在两层结构下把基础数据做干净，等工具升级后再推进；二是直接换工具。我的经验是，如果组织规模已经超过 150 人，第一条路的成本往往更高，因为规范执行的摩擦成本会随时间持续累积。
4. 自建还是采购
我不建议中大型组织自建任务管理工具。自建的优势是贴合度高，但劣势是状态推导规则、权限体系、迁移工具这些部分都需要长期维护，而它们恰恰是最容易被低估的部分。
下面这张对照表，是我在做选型评估时最常用的框架。
| 取舍维度 | 倾向自建 | 倾向采购成熟平台 | 判断依据 |
|---|---|---|---|
| 任务结构复杂度 | 极高且频繁变化 | 标准三层结构能满足 | 复杂度是否稳定 |
| 合规与数据主权 | 无强制要求 | 要求私有化部署 | 是否支持内网部署 |
| 迁移成本 | 历史数据少 | 有 3 年以上历史数据 | 迁移工具成熟度 |
| 维护投入 | 有专职平台团队 | 无专职维护人力 | 年度维护人天 |
| 迭代速度要求 | 半年以上可接受 | 要求季度内见效 | 业务窗口期 |
八、总结：父任务管理的本质是降低判断成本
回到最开始那个数字：37 个项目里 28 个延期的根因是父任务失真。这个现象背后其实是一个更朴素的判断，父任务存在的唯一理由，是让别人不需要打开子任务就能做出决策。
如果你的父任务做不到这一点，它就只是任务列表里一行更好看的标题。做完这篇文章里的对照，你可以按下面的顺序推进：
- 今天：抽查 10 个父任务，检查验收标准字段是否为空、责任人是否为单值。
- 本周：统计每个父任务下的子任务数量，超过 12 个的列入拆分清单。
- 本月：确认工具的父任务状态是否可推导，如不可推导，评估配置或替换方案。
- 本季度：按组织规模对照第六节的清单，确定层级上限和父任务配额。
最后说一个我自己的取舍：我现在基本不再追求"任务树完整"。宁可让 10% 的父任务看起来不够整齐，也不愿意为了整齐增加一层结构。管理工具的收益来自减少判断，而不是增加结构。这条判断，比任何具体配置都更值得保留。
常见问题解答（FAQ）
1. 父任务到底应该拆到几层？拆多了和拆少了的边界在哪？
我们团队最开始图省事，把所有事都塞进一个大父任务底下，结果看板一打开全是子任务，父任务反而没人看，进度也没人维护。后来我换成拆到四五层，想着颗粒度够细总没错，但两个迭代下来发现下面两层基本是僵尸状态，没人更新。我现在就想搞清楚，到底拆到几层才是合理的？
实操上我建议以两层为主、三层封顶，不要拆到四层以上。一个可以直接用的判断规则是：父任务对应一个可交付成果，有明确的验收人和验收标准；子任务对应三天以内能完成的具体动作。按这个口径，一个父任务下的子任务数量控制在3到8个，超过8个说明你的拆分维度选错了，应该先按阶段或模块建一次中间层，再往下分；
少于2个就直接删掉父任务，不要为了有层级而建父任务。为什么是三层封顶？因为层级每加深一层，成员主动更新的概率就明显下降，第三层往往只有创建者在维护。你可以拿过去两周的数据验证：统计各层级子任务的状态更新次数，如果某一层的平均更新次数低于每周一次，这一层就是无效层级，应该合并掉。
2. 父任务的进度百分比怎么算才不骗人？
我被这个坑过两次。第一次是老板看到父任务显示100%就以为交付完了，结果验收时发现核心模块根本没动；第二次我改成按子任务数量平均算，10个子任务干完9个显示90%，但剩下那1个是风险最高的联调，实际进度可能连一半都不到。所以我一直想找一套不会被误读的进度口径。
不要用子任务数量做简单平均，那等于把高风险工作和改个文案当成同等权重。可行的做法有三种，按项目类型选：一是权重法，给每个子任务标注预估人天作为权重，父任务进度等于各子任务权重乘完成度再除以权重总和，适合工作量差异大的研发类项目；
二是里程碑法，父任务不显示百分比，只显示未开始、进行中、待验收、已完成四个状态，状态由子任务的最短木板决定，只要有一个子任务未完成，父任务就不能标完成，适合交付型项目；三是干脆不显示进度，只显示剩余子任务数和最近一次更新时间，反而最不容易被误读。
另外补一条硬规则：父任务标完成必须挂验收人和验收结论，以完成定义为准，不是以点击完成按钮为准。如果想保留百分比，建议同时展示完成口径说明，比如按人天权重计算，避免别人按数量理解。
3. 跨部门协同的时候父任务归谁负责？通知怎么设才不会被嫌吵？
我们有个父任务同时涉及产品、研发、测试三方，上线前一周才发现测试环节没人接，因为每个部门都以为别人在管。更麻烦的是通知，一开始开了实时提醒，两天之内所有人都把消息免打扰了，等真正卡住的时候反而没人看到。这个平衡点我一直没找准。
父任务必须只有一个责任人，这一条不要妥协，部门再多也只填一个人，其他部门作为协作方出现在子任务的执行人字段里。落地时可以用发起方负责人加交付方接口人的双角色设计，但工具里的负责人字段只能填一个，接口人写进描述或用自定义字段承载，避免出现两个负责人等于没有负责人。
通知策略上，父任务只订阅两类事件：状态变更和逾期提醒；子任务不推实时消息，改成每天固定时间一条汇总，比如早上九点半推送给相关人。判断依据很简单：当一个人一天收到超过十几条任务提醒时，他会直接关闭通知，之后的提醒成本远远大于收益。
另外给跨部门父任务设一个机制：超过约定时间无人认领的子任务，自动升级提醒到父任务责任人，而不是继续在群里喊。
4. 父任务管理怎么推行才不至于三个月后只剩项目经理自己在填？
工具上线第一周大家都很积极，第二周开始有人不更新状态，第三个月打开一看，基本只有项目经理一个人在各处补数据，其他人只在被问的时候才回一句。我不想再来一次这样的循环，所以想知道推行阶段真正该抓的是什么。
推行失败通常不是因为工具不好用，而是因为一开始规则定得太全。我的做法是先定最小可运行规则，只保留三条硬约束：父任务必须有负责人和截止日期，子任务工作量不超过三天，每周固定时间更新一次状态，其余字段、权限、报表全部放开，不强制。
推行顺序上，先在一个真实在跑的项目试点两到四周，把三条规则跑通，再往其他团队复制，不要一开始就全员上线。效果检查用三个指标：父任务逾期率、子任务平均存活时长、更新及时率，比如要求每周五18点前完成更新的比例不低于90%。这三个指标里如果更新及时率长期低于七成，说明规则太重了，应该减规则而不是加考核。
还有一点经验：把周会上的进度汇报直接换成看板上父任务的视图，让不更新的成本立刻显现，比发通知催更有效得多。对某个具体项目管理平台而言，选型时优先看它能不能支持父任务单一责任人、子任务权重字段和固定时间汇总通知这三件事，缺一件，落地时大概率要额外靠人工补。
核心关键词
文章包含AI辅助创作：父任务管理方法大全：企业管理者任务管理协同管理落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/350939
读者评论
图表结论说三层是天花板，但样本量42个项目，而且是推演数据。我做过一个硬件+软件+结构件的项目，四层几乎没法压，因为交付物本身就是分层的。关键可能不是层数，而是每层有没有独立验收定义。如果四层里每层都能独立验收，协同成本未必比三层高多少。所以这个拐点我觉得不能一刀切。
父任务唯一责任人这点很对，但现实中很多团队把父任务给技术负责人，结果他只盯自己模块，跨模块协调还是没人管。收口人只有责任没有权限，照样推不动。我们后来给收口人配了跨部门协调的虚线权限，父任务关闭率才改善。文章没提责任和权限要匹配，这点在实际落地时挺关键的。
关于子任务'移出'而不是'关闭'，我深有同感。但我们用的某项目管理平台只支持关闭和删除，没有移出状态。迭代中期调整范围时，不做的子任务要么挂着不动，要么直接删掉，删掉后历史记录就断了。后来只能自定义一个'本期移除'状态，但父任务完成判定还得手动改。希望工具能原生支持这个机制。