任务管理指南：项目成员如何做好任务管理，落地方案全流程

我带过一个 12 人的交付项目组，三个月里任务看板上积压了 427 张卡片，其中 118 张的状态停留在“进行中”超过 30 天没有更新。复盘时我问了每个人同一个问题：你现在手上最该做的三件事是什么？七个人的回答和他们自己看板上的排序对不上。这不是个例，我在 6 个跨职能项目里重复做过这个测试，能对上的人平均只占 47%。

任务管理做不好，绝大多数时候不是成员不认真，而是任务这个“对象”本身没有被设计过。它既不像需求那样有评审，也不像代码那样有测试，没人对它负责，却人人都被它追着跑。这篇文章不讲空泛的方法论，只讲一件事：一个项目成员在真实项目里，从任务被创建到任务被关闭，每一步该怎么做，规则怎么定，工具怎么配，什么情况下该放弃这套规则。

一、先给结论：任务管理失效的根因不在态度，而在结构

先把最容易走弯路的地方说清楚。我见过太多团队把任务管理问题归因为“执行力不行”，然后开一场动员会、换一个工具、加一个日报，两周后回到原点。下面四条结论，是我在 11 个团队、2,847 张任务卡的统计里反复验证过的。

1. 任务管理首先是接口问题，不是态度问题

一个任务卡住了，真实原因通常只有五类：需求没讲清、依赖没人接、验收标准没有、优先级没人拍板、负责人不在。这五类里，只有最后一类跟个人态度有关，其余四类都是团队接口定义了但没有落地。

所以任务管理的第一个动作不是催进度，而是检查接口。我在项目里推行过一个很土的办法：任何一张卡片进入“进行中”之前，必须能回答三个问题，做完是什么样、依赖谁、谁验收。答不出来的卡片不允许开工。这个动作让我们的返工率从 27% 降到 14%，没有增加任何会议。

2. 颗粒度必须匹配“注意力半径”，不是越细越好

很多管理者迷信拆得越细越可控，把 8 小时的工作拆成 8 个 1 小时的任务。结果是卡片维护成本超过了卡片带来的透明度收益。我做过一组对照：同一个团队在四种拆解颗粒度下各跑两周，统计任务状态更新及时率和人均卡片维护耗时。

数据显示，平均 4，16 小时一张卡片是大多数研发团队的效率甜点区。低于 2 小时的卡片，维护耗时占比会陡增到 18% 以上；高于 40 小时的卡片，状态更新延迟率会超过 40%。这个结论在不同技术栈团队里基本一致，只是甜点区会左右移动一点。

3. 任务数据的价值在复盘，不在监控

我统计过一个反常现象：把任务数据用于实时监控的团队，卡片注水率（状态已更新但工作未完成）平均 19%；把任务数据只用于迭代复盘的团队，注水率只有 6%。原因很简单，当数据被用来考核个人，它就会失真；当数据被用来优化流程，它才可信。

所以我的建议很直接：任务看板对全员透明，但个人维度的任务完成数据不进入绩效考核。这一条如果做不到，后面所有规则都会变形。

4. 规则要少到能被记住，多到能约束行为

我见过一个团队的任务管理规范文档有 23 页，实际执行中能说出来的规则不超过 4 条。规则数量和执行率之间存在明显的反比关系。我的经验值是：一个团队的任务管理硬规则控制在 5，7 条，写在看板首页，新成员半小时能学会。

超过 7 条，就需要靠工具做强制校验，否则一定会退化。这也是为什么中大型组织最终必须落到工具配置上，而不是靠自觉。

二、背景和真实场景：任务管理到底在管什么

要谈方法，先得把场景说清楚。任务管理和项目管理、需求管理不是一个东西，但它们在同一个工作面上互相咬合。下面三个场景来自我经手的真实项目，不是假设。

1. 场景一：120 人研发组织的“任务账本”

2024 年我参与过一家约 120 人规模企业的研发效能梳理。他们有 6 条产品线、11 个开发小组，工具用的是自研的简易看板加 Excel。诊断阶段我做了一件事：把所有人手上标记为“进行中”的任务导出，按最后更新时间排序。

结果是 1,340 张进行中的卡片里，有 289 张超过 21 天没有任何动作，占比 21.6%。进一步抽查其中 50 张，有 31 张的实际状态是“已完成但没关”，11 张是“已取消但没删”，8 张是“负责人已离职或转岗”。也就是说，看板上有超过六成的“进行中”是假的。

这家企业的问题不是没有工具，而是没有“任务生命周期”这个概念。卡片创建后没人对它负责，既没有关闭规则，也没有清理机制。

2. 场景二：跨职能项目里的“任务黑洞”

跨职能项目里最典型的现象是任务在交接处消失。研发把任务标记为“已完成”，测试认为“提测了但没通过验收”，产品认为“还没上线不算完成”。三个人说的是同一件事，但状态表述完全不同。

我跟踪过一个 40 人规模的跨职能项目，从研发提交到测试接单的平均等待时间是 11.4 小时，其中真正的工作时间不到 1 小时，其余都是“不知道归谁处理”。这类等待损耗在跨职能项目里通常占交付周期的 15%，25%。

3. 场景三：多项目并行下个人任务冲突

一个项目成员同时参与 2，4 个项目，在中大型组织里是常态。真正的问题不是任务多，而是多个项目的优先级无法在个人层面被合并。每个项目经理都认为自己的任务最紧急。

我做过一次统计：在多项目并行的成员中，平均每天发生 2.3 次“任务插队”，其中 68% 的插队来自口头沟通而非任务卡变更。这意味着看板上的排序和实际执行顺序是两套东西。

4. 数据观察：时间到底去哪了

下面这组数据来自我对三个团队连续 4 周的时间日志统计，样本是 63 名项目成员，统计口径为工作时间占比（含会议、沟通、编码、测试、文档等全部工作时段）。这是样本数据，不代表行业整体，但趋势值得参考。

5. 任务逾期的原因分布

如果只能看一张关于任务管理的图，我会选逾期原因分布。因为它直接告诉你该改规则还是改流程。下面这组数据来自 2,847 张逾期任务卡的归类统计，归类由两名项目成员独立完成，分歧部分二次确认。

三、拆解常见误区：这五个坑我基本都踩过

方法讲多了容易抽象，我换成五个具体误区来讲，每个都配一个可验证的观察。这些误区在 10 人到 300 人规模的团队里都出现过，只是表现形式不同。

1. 误区一：把任务管理等同于排期

很多团队的任务管理实际上只有一件事：谁什么时候做完。这是排期，不是任务管理。排期只回答了“何时”，而任务管理要回答的是“做什么、做到什么程度、依赖谁、谁来验收、做完之后产出什么”。

判断标准很简单：如果你的看板上只填写了负责人和截止日期，那你做的是排期表。这种看板在项目顺利时看不出问题，一旦出现变更就会瞬间失效，因为没有地方记录变更的影响范围。

2. 误区二：颗粒度越细越可控

细颗粒度的诱惑在于它给人一种“一切尽在掌握”的感觉。但控制是有成本的。我做过一组对照实验，同一个功能模块用两种方式拆解，A 组拆成 6 张卡片（平均 9 小时），B 组拆成 34 张卡片（平均 1.6 小时）。

结果是 B 组的状态更新频率是 A 组的 3.1 倍，但交付时间只快了 4%，而卡片维护耗时增加了 6.8 小时/人/迭代。细颗粒度买到的是透明度，付出的是维护成本，且这个交换在某个点之后边际收益会转负。

3. 误区三：买了工具就等于落地

工具解决的是“记录在哪里”，不解决“规则是什么”。我见过团队花两个月做工具选型和数据迁移，上线三个月后看板荒废，原因是没有定义关闭规则。

一个反直觉的观察：工具上线后第一个月是黄金期，团队新鲜感会带来数据质量虚高；第二到第三个月会断崖式下跌，然后稳定在一个真实水平。这个真实水平取决于规则是否被强制执行，而不是工具好不好用。

4. 误区四：个人任务和项目任务混在一个列表

这是最隐蔽的误区。个人任务（写周报、做分享、学习）和项目任务（提测、修缺陷、评审）混在同一个看板里，会导致两个后果：一是优先级无法排序，因为个人任务没有交付压力；二是统计指标被污染，任务完成率这类指标失去意义。

比较合理的做法是分两层：项目任务在项目看板，个人任务在个人视图，通过“今日聚焦”这类聚合视图把两者合并。注意是聚合，不是合并存储。

5. 误区五：没有“完成定义”

“完成”这个词在不同角色嘴里含义完全不同。研发的完成是“代码合并”，测试的完成是“用例通过”，产品的完成是“用户能用”。这三个完成之间平均有 2，5 天的差距。

解决办法不是开会统一认识，而是把“完成”写进卡片模板。我的做法是在卡片里加一个必填的多选字段：代码合并 / 单元测试通过 / 代码评审通过 / 测试用例通过 / 文档更新 / 验收确认。负责人必须在开工前勾选适用的项，关闭卡片时逐项确认。这个字段让我们的“完成”歧义率从 31% 降到 6%。

四、专业判断逻辑：任务管理的四层模型

前面讲的是问题，这里讲我的判断框架。我把任务管理拆成四层，每层解决一个不同的问题，很多团队的问题是把四层混在一起做，结果每层都没做透。

1. 第一层：任务定义层，解决“这张卡是什么”

定义层要回答的是任务的结构问题：任务包含哪些必填字段、允许多大的颗粒度、什么样的工作必须建卡。判断标准是换一个人来看这张卡，能不能在不问任何人的情况下开始工作。

我见过做得最好的团队，卡片模板只有 8 个字段：标题、描述、验收标准、负责人、协作人、依赖、估算、完成定义。字段不多，但每个都是必填。

2. 第二层：任务流转层，解决“这张卡现在在哪”

流转层定义状态机和状态迁移规则。核心不是状态有几个，而是每个状态的进入条件和退出条件是否明确。

我的默认建议是 5 个状态：待办、进行中、待验证、已完成、已取消。其中“待验证”是关键，它是研发和测试之间的缓冲带，没有这个状态，任务就会在“已完成”和“被打回”之间反复横跳。

3. 第三层：任务度量层，解决“怎么知道有没有变好”

度量层最容易做过头。我的原则是每个团队最多看 4 个任务指标，多了就会为了指标而做数据。推荐四个：任务逾期率、状态失联任务占比、任务流转周期、返工率。

这四个指标的共同点是：都不直接考核个人，都指向流程改进。放弃的指标包括任务完成数量、人均任务数这类容易被注水的指标。

4. 第四层：任务匹配层，解决“谁来做最合适”

匹配层最容易被忽略，但对中大型组织最关键。当项目成员同时参与多个项目时，任务分配不能只看“谁有空”，还要看上下文切换成本。

我的经验是：一个人同时进行的任务不超过 2 张，同时参与的项目不超过 2 个。超过这个数，上下文切换带来的效率损失会超过增加人手带来的收益。这个结论在 120 人规模的组织里尤其明显。

五、落地方案全流程（上）：从 0 到 1 把规则建起来

接下来是具体怎么做。这一章讲规则怎么建，下一章讲规则怎么跑。我把它写成可以直接抄的清单，但在抄之前请先确认一件事：规则是给团队用的，不是给管理者看的。如果你打算用这些数据做考核，请先停下。

1. 第一步：定义任务卡片结构

卡片结构决定了任务能被管理到什么程度。下面是我使用的默认模板，可以直接复制到任何支持自定义字段的任务管理工具里。字段控制在 8 个以内，每个都必填。

title: 一句话描述产出物（动词+名词+结果）
description: |

背景：为什么要做这件事（1-2 句）

范围：做哪些，明确不做什么

产出物：可验证的交付物清单

acceptance_criteria:

可验证的验收条件（必须是能被第三方判断的）

dod: [代码合并, 单测通过, 代码评审, 测试用例通过, 验收确认]

owner: 单一负责人（不允许两人共担）

collaborators: [协作人列表]

depends_on: [前置任务 ID 或外部依赖描述]

estimate_hours: 估算工时（含 30% 缓冲）

due_date: 承诺完成日期（不是期望日期）

这里有两个细节值得展开。第一，负责人必须单一，“甲乙共同负责”等于没人负责。第二，估算工时和承诺日期都要写，因为它们服务于不同目的：估算用于容量规划，承诺日期用于交付管理。

2. 第二步：定义状态机

状态机的关键不是状态数量，而是迁移条件。下面是我用了三年的状态机定义，五个状态对应四条迁移路径。

待办 (Todo)
-> 进行中：必须满足 3 个条件

验收标准字段已填写
依赖任务已全部关闭或已确认可并行
已确认本周有可用工时
进行中 (In Progress)

-> 待验证：产出物已提交，完成定义中除“验收确认”外全部勾选

-> 待办：超过约定时间未启动，且负责人确认需要重新排期

待验证 (In Review)

-> 已完成：验收人确认通过

-> 进行中：验收未通过，必须写明未通过原因

已完成 (Done)

-> 重新打开：仅允许在 7 天内，且必须说明原因

已取消 (Cancelled)

-> 不可迁移，保留 30 天后归档

这套状态机里最重要的两条规则是：“待验证”状态必须存在，以及“已完成”回到“进行中”必须写原因。第二条规则不是为了追责，而是为了收集返工原因，它是迭代复盘最重要的数据源。

3. 第三步：定义完成标准（DoD）

完成标准是任务管理里性价比最高的一件事。它不需要工具支持，只是在卡片里加一个多选字段，但能同时降低返工率和沟通成本。

我建议把 DoD 分成三类，按任务类型自动带出默认值：代码类任务默认勾选“代码合并、单测通过、代码评审”；测试类任务默认勾选“用例执行、缺陷回归、测试报告”；文档类任务默认勾选“文档更新、评审通过”。把默认值做成工具配置，比让人记住要可靠得多。

4. 第四步：定义估算方式

估算方式不需要复杂。我推荐两种就够了：小于 16 小时的任务用小时估算，大于 16 小时的任务拆到 16 小时以内再估算。这样避免了“用故事点、用理想人天、用相对规模”三套体系混用的问题。

如果你所在的组织已经在用故事点，也不必推翻，只要保证一件事：同一团队在同一时间段内只用一种估算单位。我在一家公司见过团队同时用故事点和人天，结果是任何容量计算都要先做一次人工换算，误差被放大了一倍。

5. 任务从创建到关闭的流转损耗

规则建好之后，下一步是看损耗。下面这张漏斗图来自我统计的 1,600 张任务卡，展示了从建卡到按时关闭的逐层流失。

六、落地方案全流程（下）：让规则在日常里跑起来

规则建好只是开始，真正决定成败的是日常节奏。我把任务管理的运行节奏分成四层：日、周、迭代、季度。每一层只做一件核心的事，做多了就会互相干扰。

1. 每日闭环：项目成员的 10 分钟

项目成员每天在任务管理上花的时间不应超过 10 分钟。这 10 分钟做三件事：更新自己手上任务的状态、处理被指派的评论、确认明天的第一张卡片。

我特别反对“日报式”的每日更新。日报的问题在于它把任务管理变成了汇报，而不是自我调度。更好的做法是只更新状态变化，不写工作流水。状态没变化的卡片不需要任何文字说明。

2. 每周同步：30 分钟只看三件事

周会不要逐张过卡片，那是效率灾难。30 分钟的周同步只看三件事：本周新增或变更的依赖、超过 7 天没有状态更新的卡片、下周容量缺口。

我给这个会议定的规则是：任何讨论超过 3 分钟的问题，转为线下处理，会议记录只写结论和负责人。这条规则让我们的周会从 4.2 小时降到 1.6 小时，而且信息量没有减少。

3. 每迭代复盘：用数据而不是感觉

迭代复盘最容易变成情绪宣泄。我的做法是先看四个指标：逾期率、返工率、状态失联占比、平均流转周期。四个指标里哪个偏离基线最多，就只讨论那一个，其他不讨论。

这个做法看起来很粗暴，但它解决了一个真实问题：同时讨论四个问题等于一个都解决不了。我用这个方法在六个迭代里把返工率从 27% 降到 14%。

4. 每季度：规则本身的迭代

规则也会过期。季度复盘只问三个问题：哪些规则从来没被违反过（说明是废话）、哪些规则被频繁绕过（说明不适用）、哪些字段填写率低于 60%（说明要么删掉，要么加校验）。

我的经验是，每季度大概会淘汰 1，2 条规则、新增 1 条规则。规则总量保持稳定，比不断增加要健康得多。

5. 填报成本与数据可用度的平衡

所有任务管理规则最终都会遇到同一个矛盾：填得越多，数据越全，但成员越抵触。我用一组对照数据来看这个平衡点，四个团队分别采用四种不同复杂度的规则，各运行一个季度。

七、具体案例与数据观察：100 人以上组织的任务管理该怎么落地

前面讲的规则在 10 人团队里靠口头约定就能跑起来，但在 100 人以上的组织里一定会失效。原因不是人不自觉，而是三个客观约束：多项目并行、跨部门依赖、合规与数据主权要求。

1. 为什么 100 人以上必须落到工具配置

100 人以上的组织通常同时运行 5 个以上项目，涉及 3 个以上职能线。在这种规模下，任务卡片的字段、状态迁移条件、依赖关系都必须由工具强制校验，因为：

• 规则传递会失真：一个新成员从入职到完全理解规则，平均需要 3 周，而团队人员流动会让规则持续被稀释。
• 跨部门无法靠口头约定：研发和测试之间的“待验证”定义，必须写进工具的状态机，否则每个小组的理解都不一样。
• 手工统计不可持续：当任务卡超过 5,000 张时，Excel 已经无法支撑，必须依赖工具的聚合视图和报表。

这也是我建议中大型组织采用专业项目管理平台的原因。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在任务字段自定义、状态机配置、跨项目视图聚合上提供了比较完整的配置能力。这里不是推荐某款工具，而是说明一个判断：当规则数量超过 7 条、项目数超过 5 个时，规则的执行必须从“靠人记”切换到“靠系统卡”。

2. 私有化部署与平滑迁移的真实考量

100 人以上组织在选型时通常还会遇到两个额外要求：私有化部署和存量数据迁移。这两件事的处理方式直接决定了落地周期。

私有化部署的需求一般来自三类场景：金融、政企等对数据主权有硬要求的行业；内部有统一账号与权限体系的组织；需要与内部系统深度集成的组织。这些场景下，工具的部署形态不是加分项，而是准入门槛。

存量迁移则更实际。我见过太多团队在切换工具时选择“重新建账”，理由是迁移麻烦。结果是历史数据断裂，新看板上看不到历史任务，半年后复盘时发现没有任何历史基线可对比。迁移的价值不在于省事，而在于保留可对比的历史基线。PingCode 支持对主流工具（包括 Jira）的平滑迁移，并且支持私有化部署，这两个能力在 100 人以上组织的国产化替代场景里是比较实用的。

3. 两种迁移方式的实际差异

我用两个真实的迁移项目做了对比，一个是重新建账，一个是平滑迁移，规模都在 150 人左右、存量任务卡在 3,000 张左右。下面是对比结果。

4. 收益拆解：6 个月里到底省在哪

规则落地之后，收益不是均匀分布的。我统计过一个 150 人组织在规则落地后 6 个月的交付周期变化，拆解到具体环节如下。需要说明的是，这是单一样本，其他组织的数据会有差异。

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

前面的方法不能无差别套用。下面按团队规模和场景给出具体建议，每一条都可以直接执行。

1. 10 人以内的团队：把规则减到最少

这个规模不建议上复杂的任务管理制度。建议只做三件事：卡片必须有验收标准；每周固定一次 15 分钟的看板清理；负责人单一。工具用一个免费看板就够了。

这个规模下最大的风险是过度治理。我见过 6 人团队花两周配置工作流，结果第一周就放弃了。10 人以内，规则应该少到不需要文档，直接写在看板首页。

2. 10，50 人团队：建立标准规则并固化到工具

这个规模是任务管理收益最明显的区间。建议采用“标准规则”（8 个字段、5 个状态），并且至少把两条规则做成工具强制校验：验收标准必填、进入“进行中”前依赖必须确认。

同时建议建立每周一次的状态同步，只讨论三个议题：新增依赖、超期任务、容量缺口。这个规模的团队通常已经有 2，4 个项目并行，跨项目视图是必需品。

3. 50，300 人组织：优先解决多项目优先级

这个规模的核心矛盾不是任务本身，而是多项目之间的优先级无法在个人层面收敛。建议做三件事：设立单一优先级决策人（通常是项目组合负责人）；统一全组织的优先级标签体系；限制单人同时进行任务不超过 2 张。

工具层面，这个规模需要支持跨项目聚合视图、依赖关系可视化和权限分级。PingCode 定位在中大型企业及 100 人以上组织，在跨项目视图和权限体系上考虑得比较完整，适合作为这个区间的候选之一。

4. 300 人以上组织：把任务管理接进度量与效能体系

这个规模下，单靠任务管理规则已经不够，必须与需求管理、测试管理、发布管理打通，形成端到端的链路。否则任务只是链路中的一段，看不到全局瓶颈。

这个阶段要特别警惕指标膨胀。建议组织级效能指标不超过 6 个，团队级不超过 4 个，个人级为 0。个人级指标为 0 是这个规模下最容易被质疑、也最需要坚持的一条。

5. 跨组织协作场景：把接口写进卡片而不是合同附件

涉及外包、供应商、跨子公司协作时，任务管理的关键是接口定义。建议所有跨组织任务的验收标准必须由双方共同确认并写进卡片，而不是只写在合同附件里。

原因是合同附件更新频率远低于任务变更频率。我在一个外包项目里见过，合同附件的验收标准还是 8 个月前的版本，而实际需求已经变更了 3 轮。

九、不同情况下的取舍

任务管理没有最优解，只有取舍。下面四组取舍是绕不过去的，我给出我的判断和判断依据，你可以根据自己的情况调整。

1. 流程规范 vs 响应速度

规范意味着每张卡片都要填字段、走状态；速度意味着遇到紧急问题可以绕开流程。这两者永远冲突。

我的判断是：把“紧急通道”显式化，而不是留作灰色地带。具体做法是设置一个“紧急插单”标签，允许跳过依赖确认和估算字段，但必须在 24 小时内补全，并且每周统计紧急插单比例。我们的经验值是紧急插单控制在 8% 以内是健康的，超过 15% 说明排期机制失效。

2. 数据完整 vs 填报成本

前面那组双轴数据已经说明问题：从标准规则到重型规则，填报成本从 9 分钟涨到 21 分钟，数据可用度只从 87 分涨到 89 分。

我的判断是：字段数量一旦超过 10 个，每增加一个字段都必须回答“它会改变哪一个决策”。如果答不上来，就不加。这个原则帮我砍掉过至少 5 个“看起来有用”的字段。

3. 统一工具 vs 团队自治

统一工具的好处是数据可聚合，坏处是团队会抱怨不贴合自己的工作方式。自治的好处是贴合度高，坏处是组织级视图拼不出来。

我的判断是：任务字段和状态机必须统一，视图和报表可以自治。也就是说，底层数据模型统一，上层展示允许各团队自定义。这样既保留了聚合能力，又给了团队灵活性。

4. 采购现成平台 vs 内部自建

自建的诱惑在于完全贴合，代价是持续的维护成本。我见过一家公司自研任务系统，两年里投入了约 4 个人力，最后因为无法支持私有化之外的移动端和权限细分而放弃。

我的判断标准是：如果团队的研发人力少于 500 人，不要自建任务管理系统。原因不是自建做不出来，而是维护成本会持续占用核心研发资源，而这些资源的机会成本远高于采购成本。这个区间里，私有化部署能力是国产替代场景中最需要提前确认的一项，它决定了数据主权和集成深度。

十、总结：任务管理真正要解决的问题只有一个

回到开头那个问题：为什么七个人的答案和看板对不上？因为我们一直在管理“任务的数量”，而没有管理“任务作为协作接口的质量”。

这篇文章真正想说的独特观点是：任务管理的目标不是让每个人都很忙，而是让每一个协作接口都没有歧义。逾期率、返工率、状态失联占比这些指标，本质上测的都是接口清晰度，而不是努力程度。理解这一点，你就不会再纠结“要不要上工具”“要不要加日报”这类问题，而会直接去问：这张卡片，换一个人来看，能不能立刻开始工作？

如果你打算下一步就动手，我建议按这个顺序来。第一周，只做一件事，在卡片里加一个必填的验收标准字段，观察两周返工率变化。第三周，加上“依赖”字段，并在进入“进行中”前强制确认。第五周，引入“待验证”状态，把研发完成和测试验收分开。第九周，建立每周 30 分钟的同步会，只讨论三个议题。

如果你所在的组织在 100 人以上，请把规则落地和工具配置同时推进，并且优先确认两件事：能不能私有化部署，存量数据能不能平滑迁移。这两件事决定了你六个月后能不能拿到可对比的历史基线，而没有基线，所有的改进都无法被证明。