目标进度管理方法大全：管理层项目目标风险控制落地清单

先给结论：管理层管目标进度，真正要抓的只有五件事

我带过项目，也做过 PMO 负责人，还在几家中大型企业里帮他们重建过目标与进度管理体系。这些年我见过太多这样的场景：周报上全是绿色，季度末却发现核心交付延了两个月；风险清单每个月都在更新，但真正爆掉的风险从来没在上面出现过；目标拆到了每个人头上，可到了执行层，两个部门对同一个目标的理解完全不一样。

管理层管目标进度，问题从来不是"方法不够多"，而是"抓的点不对"。 SMART、OKR、KPI、甘特图、关键路径、看板、燃尽图、风险矩阵、PDCA、RACI，这些方法讲的人太多了，但真正决定项目会不会失控的，往往只有五个东西：目标口径是否唯一、里程碑是否可验收、风险是否有触发条件、依赖是否有明确负责人、偏差是否进入了纠偏闭环。

我把这五个东西做成了一套可以直接照着走的清单结构：一目标、三线、五清单。一目标指的是业务结果本身；三线指的是进度线、风险线、责任线；五清单分别是目标对齐清单、里程碑进度清单、风险预警清单、依赖责任清单、复盘纠偏清单。后面每一节我都会把其中一张清单拆开讲清楚，包括检查问题、预警阈值、会议节奏、责任分工。

这篇文章不打算给你一份百科式的目标管理方法大全，那种内容你随手一搜就有几十篇。我要给的是管理层视角的落地动作：你作为负责人，每周该问什么、该看哪张表、该在什么阈值上做决策、该在什么情况下换资源或改目标。读完你至少能判断出，你现在的项目进度管理体系，是缺工具，还是缺机制。

一、为什么"看起来一切正常"的项目，最后会崩掉

1. 一个典型的失控现场

去年我以外部顾问的身份介入过一家做企业服务的公司，规模大概 300 人左右，同时在跑 8 个项目。他们的项目管理成熟度在同规模公司里算不错的：有专职 PMO，有统一的项目管理平台，周报按时交，风险登记册每月更新，管理层月度经营会也会过一遍项目。

但那一年的第四季度，三个重点项目同时延期，其中一个直接导致客户验收推迟到次年，回款跟着往后压了一个季度。事后复盘的时候，我们发现了一件很扎心的事：这些延期不是某一天突然发生的，而是从项目启动第二周就开始积累的。

项目启动会上，销售认为"完成"指的是功能上线，产品认为"完成"指的是需求全部交付，研发认为"完成"指的是代码提交并通过自测。三个口径没人当场对齐，因为大家都觉得"这还用说吗"。结果到了第八周，产品说"我们完成了 90%"，研发说"我们还有一半接口没联调"。同一个项目，两套进度语言。

2. 为什么会这样：进度信息的三种失真

我后来把这类问题总结成进度信息的三种失真，这三种失真几乎在所有中大型组织里都会出现，只是程度不同。

• 口径失真：同一目标、同一里程碑，在不同角色眼里的定义不同，"完成"变成了一个可以被主观解释的词。
• 汇报失真：执行层报进度时天然倾向于报好消息，完成率容易被"美化"，越接近截止日期，美化冲动越强。
• 暴露失真：风险越晚暴露，对汇报者的短期评价越有利，于是风险被"拖到不能再拖"才上报。

这三种失真叠加在一起，就出现了"周报全绿、项目崩盘"的经典场景。你作为管理层，看到的不是真实进度，而是被过滤过的进度。过滤不是因为有人在撒谎，而是因为机制鼓励了过滤。

3. 管理层最容易犯的一个错：把"看板"当成"管理"

很多管理层把管理动作简化成"每天打开看板看一眼"。看板能看到状态，但看不到三样东西：看到的进度是真是假、风险会不会升级、依赖卡在谁手上。看板是执行层的工具，不是管理层的决策界面。

管理层真正需要的界面是决策界面：哪些里程碑已经偏离、哪些风险已经越过阈值、哪些依赖需要我出面协调、哪些目标需要重新排优先级。这四件事，看板一个都答不了。

二、四个反复出现的误区，我几乎在每个项目里都见过

1. 误区一：用完成率代替进度

"这个项目完成 80% 了"，这句话几乎没有任何信息量。因为 80% 是按什么算的？按任务数、按工时、按需求条数，还是按负责人拍脑袋？不同算法差异巨大。

我曾经做过一次内部小实验：让 5 个项目经理用各自习惯的方式，对同一个项目估完成度。结果是 55%、70%、80%、85%、95%。差距 40 个百分点。完成率是一个描述性指标，不是决策性指标。真正可用于决策的是：关键路径上的下一个里程碑，还剩多少天，验收条件是否满足。

2. 误区二：风险清单写成"担忧清单"

翻一翻大多数项目的风险登记册，你会看到大量这样的描述："需求可能变更""人员可能不足""进度可能延期"。这些不是风险，是担忧。担忧无法管理，因为它没有概率、没有影响、没有触发条件、没有责任人、没有预案。

一条合格的风险记录，至少要能回答五个问题：发生概率大概多少、一旦发生影响哪个里程碑、什么信号出现代表风险正在变成问题、谁负责盯这个信号、预案是什么。答不上来这五个问题，这条记录就不该进登记册。

3. 误区三：跨部门依赖靠"催"

跨部门协作不畅，本质不是沟通问题，而是责任归属问题。一个依赖任务挂在"产品部"或"技术部"头上，等于没有责任人。出事的时候，两个部门都能说出合理理由。

我见过最有效的一个做法，是把每一个跨部门依赖都拆成三行：谁提供输入、谁在什么时间点提供、如果提供不了谁负责升级。这三行写清楚之后，跨部门扯皮率会明显下降。

4. 误区四：复盘只出结论不出口动作

复盘会开得热热闹闹，最后产出十几条"加强沟通""提高意识""优化流程"的结论。没有责任人、没有截止时间、没有验证方式。下一次项目，同样的问题照旧发生。复盘的价值不在于总结出了什么，而在于改变了什么。

三、我的判断框架：一目标、三线、五清单

1. 一目标：要业务结果，不要任务量

目标的描述必须指向业务结果，而不是任务量。"完成 12 个功能模块"是任务量，"客户侧 3 个核心业务流程跑通并完成验收"是业务结果。前者完成后项目可能依然失败，后者完成才代表目标达成。

我会要求每个目标都写清楚三件事：成功标准是什么、由谁验收、时间边界在哪里。没有验收人的目标，等于没有目标。

2. 三线：进度线、风险线、责任线

管理层看项目，其实只需要盯三条线。

• 进度线：只看里程碑和关键路径，不看任务完成率。里程碑必须带交付物、验收标准、验收人、目标日期。
• 风险线：看触发条件和升级状态。风险不是"有没有",而是"到没到阈值"。
• 责任线：看每个关键接口、每个风险、每个纠偏动作背后是不是挂着一个具体的人。

3. 五清单：把管理动作变成可检查的表格

五张清单分别对应上一条的三条线和目标本身，下面这张表是它们的总览。我在实际项目里会把它们放在同一个项目工作区里，而不是分散在五个不同的文档中，因为分散意味着没人会同时看全。

四、清单 1：目标对齐清单，方向锁不死，后面全是返工

1. 目标对齐要解决的四个问题

目标对齐不是开一次启动会喊口号，而是要把四件事写清楚并且签字确认：目标从哪里来、成功怎么验收、不做什么、谁有权拍板。这四件事任何一件含糊，后面都会以返工、扯皮、延期的形式还回来。

2. 一张可复制的目标对齐检查表

下面这张表是我实际在用的版本，左侧是检查项，中间是判断标准，右侧是我在评审时最常追问的问题。

3. 我踩过的一个坑：把"不做什么"留白

我第一次独立负责跨部门项目时，犯过一个很典型的错误：目标清单里只写了要做什么，没有写不做什么。结果是项目进行到中期，各方向里塞进来的需求越来越多，范围像气球一样膨胀。我们当时的团队规模没有变，时间没有变，但范围扩大了将近一倍。

后来我强制自己在每一个目标里加一栏"明确不做"，并且要求业务方在这个栏目上确认。效果立竿见影：需求讨论从"这个要不要做"变成了"这个是否在已确认范围外"，决策效率明显提升。"不做什么"不是消极，它是保护目标的手段。

五、清单 2：里程碑进度清单，让"完成"变成可验证的事实

1. 里程碑不是日期，是交付物加验收人

我见过大量项目计划，里程碑只写了一个日期，比如"6 月 30 日完成系统联调"。这种里程碑几乎无法管理。因为到了 6 月 30 日，你只能得到两句话："差不多了"或者"还差一点"。

合格的里程碑必须包含四个字段：交付物是什么、验收标准是什么、谁验收、目标日期是几号。缺任何一个字段，这个里程碑就不可验证。我在项目里通常用一个固定结构来登记，形式大概是这样：

milestone:
name: "联调环境全链路跑通"

deliverable: "3 条核心业务链路可端到端执行并产出日志"

acceptance_criteria: "测试用例通过率 >= 95%，遗留缺陷 P1 = 0"

accepter: "测试负责人 张某"

target_date: "2026-06-30"

status: "green | yellow | red"

deviation_days: 0

2. 关键路径和领先指标：提前两周发现偏差

里程碑是滞后指标，它告诉你已经发生的事。真正让管理层提前介入的，是领先指标。

举个具体的例子：一个交付型项目，里程碑是"完成客户验收"。这是滞后指标，等到发现它要延期，往往已经来不及。领先指标可以是：需求确认完成率、接口联调成功率、缺陷收敛速度、客户侧参与测试的人数。这四个指标里任何一个掉下来，都意味验收里程碑大概率要延。

我的经验是：给每个关键里程碑配 2 到 3 个领先指标，并给它们设阈值。 当领先指标触线时，管理层开始介入，而不是等到里程碑到期。

3. 红黄绿规则必须提前定义

很多团队的黄灯绿灯是凭感觉打的。项目负责人感觉还行就报绿，感觉不太妙就报黄。这种规则没有管理价值。

我会要求红灯、黄灯、绿灯都有明确的量化条件。比如：关键路径偏差在 3 个工作日以内为绿，3 到 7 个工作日为黄，超过 7 个工作日为红；或者：P1 缺陷数超过 5 个自动转黄。规则定下来之后，颜色就不再是主观判断，而是数据映射。

六、清单 3：风险预警清单，从"救火"变成"触发"

1. 风险分五类，登记册按类别建

我一般把项目风险分成五类：需求类、资源类、技术类、依赖类、外部类。分类的意义在于，不同类别的风险，责任人和应对手段完全不同。需求类风险要业务方介入，资源类风险要职能负责人介入，技术类风险要架构师介入，依赖类风险要跨部门协调，外部类风险往往需要管理层出面。

不分类型，风险登记册就会变成一锅粥，没人知道该找谁。

2. 每条风险必须有触发条件

这是我认为整个风险控制里最关键的一条。没有触发条件的风险，只能被动等待它爆发；有触发条件的风险，可以被主动监控。

举个例子，"核心开发人员可能离职"这条风险，触发条件可以是"关键模块单点依赖人数大于 2 且连续两周无人参与代码评审"。一旦触发条件成立，就自动升级到管理层，并启动知识交接预案。

3. 阈值、升级路径与预案要写在一起

下面这张表是风险清单里我最看重的部分，它把风险、触发条件、升级对象、预案放在同一行。这样做的目的是让风险处置不依赖某个人当天的判断力。

4. 风险数量不是越多越好

还有一个反常识的观察：风险登记册里的风险数量，和项目健康度没有正相关。我见过登记了 60 条风险、最后崩掉的项目，也见过只有 8 条风险、顺利交付的项目。

关键差别在于，有效的风险清单里，每条风险都有 owner 和预案；无效的清单里，风险只是被记录，没有被管理。我宁愿要 8 条被真正管理的风险，也不要 60 条被归档的担忧。

七、清单 4：依赖与责任清单，跨部门协作不靠催

1. 责任必须落到人，不能落到部门

跨部门项目最大的隐性成本是等待。等待往往不是因为对方不配合，而是因为这项依赖没有明确的接口人。任务挂在部门名下，部门负责人有一百个理由说"我这边也在等别人"。

我的做法是：每一个跨部门依赖都指定唯一接口人，并写清承诺日期。 接口人不是部门领导，而是实际干活的那个人，同时另指定一个升级对象，用于接口人无法按时交付时的升级路径。

2. RACI 的正确用法

RACI 本身没有新意，但很多人用错了。常见的错误是把 RACI 用在整个项目上，结果做出一张巨大而没人看的表。我建议只对跨部门关键交付项使用 RACI，通常不超过 15 项。每项写清四个角色：谁执行、谁负责、谁被咨询、谁被告知。

这里有个容易忽略的点：R（执行）和 A（负责）最好不是同一个人。当执行和负责是同一个人时，这个任务在组织里就没有第二双眼睛，出问题的时候也缺少制衡。

3. 变更控制和决策纪要

依赖管理的另一半是变更控制。我见过太多项目，需求被口头改掉，工期没人调整，最后变成执行层自己扛。变更控制的动作很简单：任何影响范围、时间、资源的变更，必须记录影响并经过决策人确认。

决策纪要要写三件事：决定了什么、谁决定的、什么时候生效。没有这三件事，纪要就是会议记录，不是决策记录。

4. 会议只解决三类问题

项目周会最容易变成流水账汇报会。我的建议是，把周会限制在解决三类问题上：信息同步（只讲偏差，不讲流水）、风险决策（越过阈值的风险当场决策）、资源协调（需要管理层出面的依赖当场定人定时）。

流水账汇报会开两小时，决策会开二十分钟。差别不在会议时长，而在会议有没有预设的决策清单。

八、清单 5：复盘纠偏清单，让偏差变成组织能力

1. 偏差不只看时间，还要看范围和资源

大多数团队的偏差分析只看时间：延了几天。但时间偏差往往不是第一位的。我见过项目时间没延，但范围压缩了、质量下降了、团队透支了，这些隐性偏差在下一个项目里会连本带利还回来。

所以我在偏差分析里固定看四个维度：范围偏差（做了多少计划外的事）、进度偏差（关键路径延迟天数）、资源偏差（人力投入是否超过计划）、风险偏差（风险清单是否新增或升级）。四个维度一起看，才能看出项目真实健康度。

2. 纠偏动作必须有责任人和验证方式

纠偏动作的格式我要求统一为：做什么、谁负责、什么时候完成、怎么验证。少了最后一个"怎么验证"，纠偏动作很容易变成一句空话。

举个例子，"加强测试投入"不是纠偏动作，"在第 6 周前增加 2 名测试人员，使 P1 缺陷日均收敛数从 5 个提升到 9 个以上，由测试负责人每周五验证"才是纠偏动作。

3. 把有效做法沉淀成模板

复盘的最终产出应该是组织资产，而不是一份 PPT。我在团队里推动过一个做法：每次项目结束，必须至少往模板库里增加或修改一条内容，可以是检查项、阈值、预案，也可以是某个里程碑的验收标准写法。

两年下来，这个模板库变成了我们最值钱的东西。新人接手项目时，不需要从零开始想，而是站在前面几十个项目的经验上。组织能力的积累，本质上就是清晰化经验的积累。

4. 复盘要区分"人的问题"和"机制的问题"

这一点很重要但常被忽略。很多复盘会最后都归结到某个人的失误上，比如"某某沟通不到位"。但如果你往下追一层，往往会发现，是机制没有要求他把这件事说清楚。

我会在复盘里强制问一个问题：如果换一个同样能力的人来做这件事，他是不是大概率也会犯同样的错？ 如果答案是"会"，那这就是机制问题，要改流程；如果答案是"不会"，那才是个体问题，要谈改进。

九、工具箱：方法怎么组合，而不是堆名词

1. OKR 和 KPI 用在目标对齐，不用在进度跟踪

OKR 适合解决"目标有没有对齐、有没有挑战性"的问题，KPI 适合解决"关键结果有没有达标"的问题。但它们都不适合做进度跟踪。用 OKR 跟进度，会把目标管理变成任务管理；用 KPI 管过程，会诱导执行层做数字游戏。

我的建议是把 OKR 或 KPI 放在目标对齐清单里，作为目标来源和成功标准的依据，进度跟踪交给里程碑清单。

2. 甘特图、关键路径、看板、燃尽图各管一段

3. 按项目复杂度选组合，不要一刀切

我最反对的做法是让所有项目用同一套工具模板。一个 3 人两周的小项目用全套风险矩阵和 RACI，纯属负担；一个跨 5 个部门、周期 9 个月的项目只用看板，等于裸奔。

我会这样分：单部门、周期 1 个月以内的项目，用目标对齐清单加里程碑清单就够；跨部门、周期 3 到 6 个月的项目，五张清单全用；周期超过 6 个月或涉及外部验收的项目，在五张清单基础上再加季度目标重估和阶段门评审。

十、一个真实案例：300 人企业如何用 90 天把项目延期率降下来

1. 背景与初始状态

前面提到的那家 300 人规模的企业服务公司，在我介入时有一个可量化的问题：过去 12 个月交付的 14 个项目中，有 9 个延期超过 2 周，延期率约 64%。他们的项目经理平均每人同时负责 2.4 个项目，跨部门依赖占比很高。

他们原本已经在用一个项目管理平台，看板、任务、工时都有记录。但问题在于，平台记录的是任务层信息，管理层需要的目标层和风险层信息，散落在各个 Excel 里。

2. 我们做了什么

第一步是统一口径。我们把所有在建项目的里程碑重新登记了一遍，强制补齐交付物、验收标准、验收人三个字段。这一轮做完，有 6 个项目的里程碑定义被推翻重写。

第二步是建立风险触发机制。我们要求每个项目把风险登记册从"担忧清单"改成"触发清单"，每条风险必须有触发条件和升级对象。这项工作让风险条数平均减少了 40%，但被真正管理的风险比例大幅提升。

第三步是把五张清单放进统一的工作区。考虑到他们是中大型组织、且对数据主权有要求，最终选择了 PingCode 作为承载平台。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，对当时正打算替换原有工具链的他们来说，是比较匹配的选择。 迁移过程大概用了三周，主要是历史项目的字段映射和权限重建。

第四步是固定会议节奏。周会只讲偏差、风险和依赖，不谈流水账；月度经营会过一遍五张清单的红黄绿状态和纠偏动作完成率。

3. 90 天后的变化

三个月后，我们做了一次对比统计。需要说明的是，这是单一企业的内部观察样本，规模有限，不能当作行业结论，但趋势足够明显。

这里面我最看重的不是延期率下降，而是最后一项：纠偏动作按期完成率。它从 34% 提升到 72%，意味着偏差不再只是被记录，而是真的被处理了。这才是一个组织从"能看见问题"走到"能解决问题"的分界线。

4. 这个案例里最容易被忽略的一点

工具替换本身并不是这个案例成功的原因。同样的清单、同样的机制，如果他们继续用原来的平台，效果大概率也能出来。工具的作用是降低执行成本，让机制能持续运转，而不是替代机制本身。

我见过不少公司花大力气换了平台，结果半年后一切照旧。原因很简单：他们换的是工具，没有换清单和会议节奏。工具是载体，机制才是引擎。

十一、90 天落地路线：从一张表到一套机制

1. 第 1 到 30 天：统一口径和模板

这一个月的核心任务不是提升指标，而是把基础口径统一。具体动作包括：把所有在建项目的目标登记进目标对齐清单，补齐成功标准和验收人；把里程碑重构一遍，强制带交付物和验收标准；建立统一的风险登记册模板和依赖责任表。

这个阶段最容易出现的阻力是"太麻烦"。我的应对方式是不追求一次性做到完美，先把最关键的 2 到 3 个项目做完，用结果说服其他团队。

2. 第 31 到 60 天：跑预警和会议机制

第二个月开始跑真实节奏。重点是三件事：定义红黄绿规则并开始按规则打状态；给每条风险设触发条件；把周会改成偏差、风险、依赖三议题结构。

这个阶段要特别留意一个陷阱：规则定了但不执行。我见过团队定了红灯规则，结果真到红灯时又找理由报黄。一旦出现这种情况，整套机制的信用就崩了。管理层要做的，是在第一次出现红灯时按规则处理，而不是放水。

3. 第 61 到 90 天：固化复盘和考核

第三个月把复盘机制建起来。每个里程碑完成后做一次小复盘，项目结束做一次完整复盘，纠偏动作进入跟踪列表。同时把风险控制成效纳入项目经理的评价维度，比如纠偏动作按期完成率、风险预案覆盖率。

这里我要提醒一点：考核指标不要设成"零风险"或"零延期"，否则会导致风险被隐藏。更合理的指标是"风险暴露及时性"和"纠偏动作完成率"，鼓励早暴露、早处理。

十二、不同情况下的行动建议

1. 如果你在创业公司，团队 30 人以内

不要上五张清单。你只需要两张：目标对齐清单和里程碑清单。风险控制可以用周会上的十分钟口头确认代替，但必须记录触发条件。这个阶段的重点是速度，不是流程完备度。流程过重，会拖慢你们唯一的优势。

2. 如果你在 100 到 500 人的公司，正在跨部门推项目

五张清单都需要，而且依赖责任清单的权重最高。这个规模的组织，最大的效率损耗来自跨部门等待。我建议把跨部门依赖单独拉出来做一张看板，按超期天数排序，每周只看超期超过 3 天的项。

3. 如果你在 500 人以上组织，做项目群管理

你需要的不是单项目清单，而是项目群层面的统一口径和风险聚合视图。这个阶段的核心问题是：单个项目都绿，但整体资源超载。你需要增加一个跨项目的资源负载视图，识别哪些关键角色被多个项目同时占用。

中大型组织在选择承载平台时，通常会更关注数据主权、权限体系和历史数据迁移成本。像 PingCode 这类支持私有化部署、支持从 Jira 平滑迁移的平台，就是在这个场景下被较多考虑的选项之一。

4. 如果你已经在用某项目管理工具，但感觉没什么效果

先别急着换工具。拿你现在的项目，检查三件事：里程碑有没有验收标准、风险有没有触发条件、依赖有没有具体接口人。如果这三件事都是否，那问题不在工具。把清单补上之后再看效果，你可能会发现工具其实够用。

十三、不同情况下的取舍

1. 速度与可控性的取舍

管理机制一定会增加前期成本。目标对齐会多开两次会，里程碑重构会多花几天，风险清单会让人多写几段文字。这些成本是真实存在的。

我的判断标准是：如果项目延期一次的损失超过机制建设成本，就值得建；如果项目本身就是探索性质、失败成本可控，那就轻装上阵。 不是所有项目都值得全套机制，关键看延期和失败的代价。

2. 透明度与心理安全的取舍

你希望风险早暴露，就必须容忍"早期红灯多"。一个刚上线触发机制的团队，红灯数量一定会先上升，因为原来被隐藏的风险被暴露出来了。如果管理层在这个阶段批评红灯太多，机制立刻失效。

所以我的建议是：在机制上线的前两个月，明确告诉大家红灯增加是预期现象，考核的是响应速度，不是红灯数量。

3. 标准化与灵活性的取舍

统一模板能降低沟通成本，但也可能不适配所有项目类型。我的做法是保留核心字段统一，比如里程碑必须有交付物、验收人、日期，但允许不同项目类型在辅助字段上有差异。研发项目和交付项目、市场项目和基建项目，本来就不该用同一套细化模板。

4. 工具投入与机制投入的取舍

如果预算有限，优先投入机制建设，工具可以后置。机制是免费的，但它要求管理层真正花时间。工具是付费的，但它替代不了管理层的判断。我见过太多公司反过来做：舍得买工具，不舍得开会。

十四、管理层今天就能做的五个动作

如果你现在手上正好有项目在跑，不需要等 90 天路线开始，今天就可以做五件事。

1. 挑一个最关键的里程碑，把验收标准写清楚。 要求包含交付物、验收标准、验收人、目标日期四个字段，缺一不可。
2. 建一张风险登记册，先只写三条最重要的风险。 每条必须有触发条件和升级对象，写不出来的风险就删掉。
3. 给每条风险指定一个 owner。 不是部门，是具体的人，并告诉他触发条件是什么。
4. 定一个预警阈值。 比如关键路径偏差超过 5 个工作日自动升级到管理层，不需要等周会。
5. 开一次只解决决策的会。 议程只有三项：需要我决策的风险、需要我协调的依赖、需要我重新排序的资源。会议记录只写决定了什么。

这五个动作加起来大概需要半天时间，但它会把你的项目从"靠人盯"变成"靠机制跑"。我自己的经验是，管理层的价值不在于盯得更紧，而在于把判断力用在真正需要判断的地方，其他部分交给清单、阈值和节奏。

目标进度管理方法大全这个说法很吸引人，但真正好用的方法从来不是最多的那一套，而是能被你的组织持续执行下去的那一套。先选五张清单里最缺的那一张补上，比一次性铺开五张更有效。