里程碑管理方法大全：项目负责人项目阶段落地方案落地清单

2023 年我接手复盘一个延期 47 天交付的项目，翻它的里程碑台账时发现一个荒诞的事实：12 个里程碑里有 11 个标注为“按期达成”，唯一的例外是最后那个“项目验收”。纸面上这个项目的里程碑管理几乎完美，但项目本身一塌糊涂。后来我一个个倒查才发现，其中 6 个里程碑是在原定日期当天被“重新定义”了达成标准，原本要求“接口联调通过”，改成了“接口联调启动”。这类操作在很多团队里天天发生，而且没人觉得自己在造假。

这篇文章我想把里程碑管理这件事从头讲透。不是给你一堆模板，而是讲清楚里程碑为什么总是失效、该怎么设、怎么审、怎么关，最后给你一份可以直接照着做的分阶段落地清单。文章里的数据来自我过去 9 年带过的 30 多个项目复盘，以及 2022，2024 年间对 60 余个研发团队的访谈样本，规模从 8 人小组到 400 人以上的研发中心都有。凡是模拟推演的数据我都会标出来，不伪装成统计结论。

一、先给结论：里程碑是决策关口，不是进度节点

我带过的项目里，里程碑管理真正失效的，几乎从来不是“记录不及时”，而是把里程碑当成了任务清单上一个加粗的条目。这是最根本的认知错位。任务管的是工作量消耗，里程碑管的是状态跃迁。任务可以 60% 完成、80% 完成、95% 完成，里程碑只有两个状态：达成，或者没达成。

一旦你把里程碑降格成“大一点的任务”，后面所有的失控都是顺理成章的：它可以被顺延、可以被部分完成、可以被“基本达成”，最后整个项目的进度体系就变成了一堆可以商量的数字。

1. 三条我反复验证过的核心判断

判断一：里程碑必须绑定一个可验证的交付物，而不是一个动作。“完成需求评审”是动作，“评审纪要签字归档且需求基线冻结”才是交付物。动作没有验收标准，交付物有。

判断二：里程碑的核心价值是提前暴露坏消息，不是汇报好消息。如果你的里程碑评审会开成了庆功会，那这套机制基本等于没有。真正有价值的里程碑评审，至少有三分之一的会议时间在讨论“下一步的风险敞口有多大”。

判断三：里程碑必须有明确的签字责任人，且这个责任人不能是执行者本人。自评自签的里程碑，和没有里程碑是一样的。签字的人要对“这个状态是否可以进入下一阶段”负责，而不是对“这件事情做完了没有”负责。

2. 里程碑管理的四级成熟度

我把见过团队的里程碑管理分成四级，你可以对照看看自己在哪一级。这个分级不是理论模型，是我按“失控后能否提前 2 周以上预警”这个硬标准倒推出来的。

注意最后两列的差异。L1 到 L4 的预警提前期差了 20 天以上，这是量级差异，不是效率优化。很多团队的痛苦在于，他们花了大量精力在“把 L2 做得更精致”，比如把红黄绿灯换成更漂亮的仪表盘，但预警能力一点没提升。

二、真实场景：里程碑为什么会系统性漂移

2024 年上半年，我给一家做工业软件的公司做交付复盘。他们一个合同额 680 万的项目，原计划 8 个月交付，实际用了 10 个月零 6 天。项目组一开始的结论是“客户需求变更太多”，但我把 14 个里程碑的偏差天数逐一归因之后，发现了完全不同的答案。

需求变更造成的净偏差只有 23 天，占比不到三分之一。真正的大头是两件事：一是 4 个里程碑撞在了同一个时间窗口里，团队拆分不出人手，被迫串行；二是 3 个里程碑的退出准则写得太模糊，返工和补做吃掉了 35 天。

1. 里程碑漂移的五个高发位置

我把这 30 多个项目的漂移归因做成了一张瀑布图，你可以看到每一天的偏差到底是从哪来的。这个分布在我后续的样本里重复出现，稳定性很高。

排第一的是里程碑扎堆。很多项目负责人画甘特图时习惯把里程碑均匀铺在时间轴上，看起来很美，但忽略了资源约束。四个里程碑同周到期，等于四个里程碑都做不完。

排第二的是退出准则模糊。这个后面我会专门讲怎么写。简单说，凡是含有“基本完成”“初步具备”“达到预期效果”这类词的退出准则，返工率都会显著上升。

排第三的是依赖未识别。里程碑 A 依赖外部供应商交付，但这个依赖没有写进里程碑定义里，等到评审当天才发现东西没到，只能挂起。

排第四的是评审节点后置。评审会安排在里程碑到期当天开，发现问题时已经没有缓冲了。正确的做法是提前 30% 的周期开预评审。

排第五的才是需求变更。它在我的样本里只排第五，但几乎每次复盘都被列为第一原因。这就是归因偏差：变更最容易被看见，因为它有明确的书面记录；而扎堆和准则模糊是“设计缺陷”，团队自己不容易发现。

2. 偏差风险不是均匀分布的

另一个被普遍忽略的事实是：里程碑的偏差风险在不同项目阶段差异极大。我用 18 个项目的实际数据做了统计，发现风险曲线是明显的 U 型，两端高、中间低。

启动阶段的前两个里程碑，偏差率最高，因为需求边界不清、干系人没对齐；中段执行期的里程碑最稳；而临近交付的最后两个里程碑偏差率再次飙升，因为所有前期欠下的债都会在收尾时集中爆发。

这个规律的实际意义是：你不应该给所有里程碑同等的管控力度。把 70% 的评审精力投在两端的里程碑上，中间阶段用轻量巡检即可，管理成本能降下来一大截。

三、拆解五个最常见的里程碑误区

下面这五个误区，我在项目评审中几乎每次都至少能撞见两个。它们单独看都不致命，但组合起来会形成一套“看起来在管理、实际上在自欺”的体系。

1. 误区一：里程碑就是大一点的任务

这个误区最普遍。表现是里程碑有负责人、有开始时间、有截止时间、有完成百分比。一旦有了完成百分比，它就变成任务了。

里程碑不应该有开始时间和完成百分比。正确的字段是：目标日期、退出准则、证据清单、签字人、当前状态（未开始/进行中/已评审通过/已挂起）。“进行中”只表示它还没有被评审，不表示完成度 70%。

我见过最离谱的操作，是给里程碑填了 45% 完成度。这个数字既不能预测什么，也不能决策什么，纯粹是心理安慰。

2. 误区二：里程碑日期一旦确定就不能改

这是另一个极端。很多团队把里程碑日期当成军令状，改了就是承认失败，于是宁可让标准缩水也不改日期。结果就是我开头说的那个场景，11 个里程碑全部“按期达成”，项目延期 47 天。

我的判断是：日期可以改，但改日期必须走和改范围同等严肃的流程。需要说明原因、影响评估、并得到上一级签字。真正不能动的是退出准则，你可以推迟达成的时间，不能降低达成的标准。

这个原则的执行效果很直观：当团队发现“改日期比降标准容易”的时候，他们会选择改日期；当他们发现“改日期要走流程、降标准只要自己说一句”的时候，他们就会降标准。所以流程设计必须让降标准的成本更高。

3. 误区三：达成就是交付物做完了

交付物做完不等于里程碑达成。里程碑达成的完整定义应该是：交付物完成 + 质量门禁通过 + 下游可启动 + 证据已归档 + 责任人已签字。

这五个条件缺任何一个，里程碑都不算达成。尤其是“下游可启动”和“证据已归档”这两条，被忽略的比例最高。前者保证了里程碑的真正意义是“解锁下一阶段”，后者保证了半年后回过头还能说清楚当时到底交付了什么。

4. 误区四：里程碑越细越好

我做过一个统计：把同一批项目按里程碑密度分组，看它们的交付表现。这里的密度指“平均每个里程碑覆盖的人天工作量”。

结果很有意思。密度在 80，150 人天/里程碑区间的项目，交付准时率最高；密度低于 40 人天/里程碑的项目（也就是里程碑特别密集），准时率反而下降了 9 个百分点，而且项目负责人的管理时间成本上升了约 35%。

原因不难理解。里程碑过密，评审会变成流水席，评审质量断崖式下降，最后演变成“盖章会”。里程碑的数量应该由“状态跃迁的次数”决定，而不是由“时间均匀”决定。一个项目如果有 6 次真正的状态跃迁，就设 6 个里程碑，不要硬凑 12 个。

5. 误区五：用工具记录里程碑就等于在做里程碑管理

这是近几年随着研发管理工具普及后新出现的误区。团队把里程碑录进系统、设置好提醒、每天看板上一片绿色，就认为管理到位了。

工具能解决的是“可见性”，解决不了“判断力”。谁来判断这个里程碑该不该通过？谁来判断退出准则写得够不够硬？谁来判断这次挂起是真的阻塞还是团队不想干了？这些都得靠人。

工具的正确用法是承载流程和证据，而不是替代判断。我后面会讲一个具体的中大型组织案例，说明什么样的工具配置才真正对里程碑管理有增益。

四、专业判断逻辑：里程碑怎么设、怎么审、怎么关

这一节是全文最核心的部分。我把里程碑管理的完整判断逻辑拆成四步：设置、定义、评审、关闭。每一步我给出具体的判断标准和操作方法。

1. 设置判断：这个节点配不配当里程碑

我常用的筛选标准是三问法，只要有一问答不上来，这个节点就不该设为里程碑，降级成普通任务即可。

第一问：这个节点通过后，下一阶段的工作内容会不会发生本质变化？如果通过前后大家干的事差不多，那它只是进度条上的一格。

第二问：这个节点失败，项目是否需要重新决策？如果失败了只是加两天班补上，那它不是里程碑，是风险点。

第三问：这个节点是否跨越了组织边界？也就是需要另一个部门、另一个团队或者客户参与确认。跨边界的节点最容易扯皮，也最需要正式的里程碑机制。

三问全过，才设成里程碑。按我的经验，一个 8，12 个月的项目，真正能通过三问法的里程碑通常在 6，9 个之间。如果初拟出来 20 个，说明筛选做得不够。

2. 定义判断：退出准则怎么写才算硬

退出准则的质量直接决定了里程碑的可信度。我给你一个可直接套用的写法模板：“当且仅当 [具体交付物] 通过 [具体验证方式] 并达到 [可量化标准] ，且 [证据已归档到指定位置] ，本里程碑视为达成。”

举两个真实例子的对比，你一眼就能看出差别。

【反面写法】
里程碑：完成核心模块开发

退出准则：核心模块功能基本完成，可以进入联调阶段。

【正面写法】

里程碑：核心模块通过内部验收

退出准则：当且仅当以下五项全部满足时，本里程碑视为达成，

1. 核心模块 32 个功能点全部通过单元测试，行覆盖率 ≥ 75%；
2. 接口契约文档已更新至 v1.2 并归档至项目知识库；
3. 静态扫描严重级别问题为 0，高危级别问题 ≤ 3 且有明确修复计划；
4. 下游联调团队已完成接口对接自测，并出具可联调结论；
5. 上述四项由模块负责人与测试负责人双方签字确认。

区别在哪？反面写法里没有任何一个词是可验证的。“基本完成”是谁的判断？“可以进入联调”是谁说了算？一旦到了评审日，执行者说“基本完成了”，你很难反驳。

正面写法里每一项都是可以查证的事实，覆盖率有报告、文档有版本号、扫描有结果、结论有签字。退出准则的本质是把“扯皮”提前到写准则的时候解决掉。写准则那天吵清楚，比评审那天再吵要便宜十倍。

3. 评审判断：评审会该怎么开

我坚持一个做法：里程碑评审会必须和进度汇报会分开开。合在一起开，会议一定会被进度讨论占满，最后五分钟草草表决。

评审会的标准议程我一般这样安排，时长控制在 60 分钟以内。

1. 主持人宣读退出准则原文（2 分钟）。注意是宣读原文，不是复述大概意思。
2. 责任人逐条出示证据，每条证据对应准则的哪一项要明确说（15 分钟）。
3. 评审人质询，重点是“有没有未披露的假设”和“下游是否真的可以启动”（20 分钟）。
4. 风险敞口讨论：这个里程碑通过后，下一个里程碑的最大风险是什么（15 分钟）。
5. 表决并记录结论，明确签字（8 分钟）。

第三步和第四步是评审的价值所在。很多团队的评审会只做前三步，结果就是“里程碑通过了，但下个月照样炸”。

关于评审频次，我也做过对比。同样规模的项目，坚持每里程碑正式评审的组，相比只在关键节点评审的组，缺陷逃逸率（也就是流到验收阶段才被发现的缺陷占比）有明显差异。这个数据我在下面这张图里给出。

4. 关闭判断：例外情况怎么处理

现实项目中，里程碑很少能干干净净地通过。总会有“90% 满足”的情况。我的处理原则是：不允许部分达成，但允许有条件通过。

这两者的区别很关键。“部分达成”意味着这个里程碑可以带着未完成项进入下一阶段，未完成项从此消失在视野里。“有条件通过”意味着里程碑状态仍为“未达成”，但项目可以启动下一阶段的部分工作，条件是必须在指定日期前补齐缺口，且补齐后需要二次评审。

具体操作上，我会要求三条约束同时成立：

• 缺失项必须被登记为独立的高优先级任务，有负责人和截止日期，进入项目主看板而不是某个人的备忘录；
• 有条件通过必须在下次项目例会上作为固定议题复查，不能等到下个里程碑才想起来；
• 同一项目连续两次“有条件通过”，触发项目级风险升级，由项目负责人向管理层说明。

第三条是关键。人的行为会被制度的宽容度塑造。如果“有条件通过”没有次数限制，它就会变成常态。我见过一个项目，8 个里程碑里 6 个是有条件通过，最后补缺口的任务堆到收尾阶段才爆发，直接导致 40 天延期。

五、分阶段落地清单：从启动到收尾的完整动作

这一节我给出可以直接照做的清单。清单按项目阶段组织，每一项都写清楚动作、产出物和完成判断标准。你可以直接复制到自己的项目文档里。

1. 启动阶段清单（项目立项至需求基线冻结）

1. 识别状态跃迁点。用三问法从 WBS 里筛出候选里程碑，通常 8 个月的项目筛出 6，9 个。产出物：里程碑候选清单及筛选理由。
2. 给每个里程碑写退出准则。用“当且仅当…通过…达到…且证据归档…”模板。产出物：每个里程碑不少于 3 条、不多于 7 条的可验证准则。
3. 排布日期并做资源冲突检查。重点是检查有没有两个以上里程碑落在同一周。产出物：带资源约束校验的里程碑计划。
4. 明确每个里程碑的签字人。签字人必须是下游接收方或跨部门角色，不能是执行者。产出物：里程碑责任矩阵。
5. 定义证据归档位置。每个里程碑的交付物放哪里、用什么命名规则，一次定清楚。产出物：项目知识库目录结构。
6. 向干系人宣讲里程碑机制。特别是要讲清楚“日期可改、标准不可降”和“有条件通过最多两次”这两条规则。产出物：宣讲纪要及确认名单。

2. 执行阶段清单（每个里程碑周期内循环）

1. 提前 30% 周期开预评审。比如一个 20 天的里程碑周期，第 14 天就要开预评审，把问题在还有缓冲的时候暴露出来。
2. 预评审只做一件事：逐条对照退出准则，标出当前满足和未满足的项。不做进度汇报，不做鼓励动员。
3. 把未满足项转成带日期的任务。每项都要有负责人，进入主看板。
4. 正式评审会按标准议程走。宣读准则、出示证据、评审质询、风险讨论、表决签字五步不能省。
5. 评审结论当天录入系统。状态、证据链接、签字人、结论类型（通过/有条件通过/挂起）四项必须齐全。
6. 有条件通过的项目登记缺口并进入复查队列。下次例会必须复查，不能延期。

3. 收尾阶段清单（最后两个里程碑）

1. 盘点所有未关闭的缺口任务。把历次有条件通过积累的补做项全部拉出来，看总量是否可控。
2. 做一次全量里程碑台账复核。重点查有没有“状态为达成但证据缺失”的里程碑，这是历史雷区。
3. 对最后一个里程碑设置双重验证。验收类里程碑建议由质量角色和客户方分别确认，不能只由项目组自评。
4. 输出里程碑复盘报告。至少包含：原计划 vs 实际的偏差天数、偏差归因、有条件通过次数、缺口补齐率。

4. 一个中大型组织的工具落地案例

2023 年底，我参与了一家约 260 人研发组织的管理工具切换。他们的情况在中大型团队里很典型：三个产品线、六个交付团队、项目周期普遍在 6，12 个月，此前的项目管理依赖一套自建表格加邮件审批，里程碑数据分散在四个不同的地方。

我们最终选择的是 PingCode。选它的原因有三点，这三点也正好对应中大型组织在里程碑管理上的真实痛点。

第一，它能承载“里程碑，迭代，需求，缺陷”的完整链路。这是关键。很多工具只能把里程碑做成一个独立的标签，那样里程碑和实际工作就是两张皮。PingCode 的里程碑可以关联到具体迭代和发布计划，评审时点一下就能看到关联的需求完成情况，证据链是通的。

第二，支持私有化部署。这家公司有数据合规要求，所有研发数据不能出内网。私有化部署对 100 人以上的组织来说往往不是加分项而是准入项。这一点在选型阶段直接筛掉了大部分候选。

第三，支持从 Jira 平滑迁移。他们之前用 Jira 用了五年，积累了大量的历史项目和字段配置。迁移时最怕的就是数据丢失和字段映射错乱，导致历史项目无法追溯。PingCode 提供了迁移工具和字段映射能力，实际迁移了约 140 个项目，历史里程碑数据基本完整保留。对国产替代场景来说，这是一个很实际的考虑点。

落地后三个月，他们做了一次内部对比。里程碑评审的按时召开率从 71% 提升到 94%，证据归档完整率从 43% 提升到 88%，有条件通过的缺口补齐率从 52% 提升到 79%。

但我要强调一点：这些提升里，工具本身的贡献大约只占三分之一，另外三分之二是流程重定义带来的。如果只是把原来的糊涂流程搬到新工具上，数据不会变好，只会让糊涂变得更可视化。

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

里程碑管理没有一套万能方案。同样是 8 个月的项目，10 人团队和 200 人组织的做法应该完全不同。下面按四种典型情况给出建议。

1. 10 人以下小团队

小团队最大的优势是沟通成本低，最大的风险是把优势当成不需要流程的理由。我的建议是：只设 3，4 个里程碑，但退出准则必须写。

具体做法：用一张在线表格维护里程碑，字段只需要五个，名称、日期、退出准则、签字人、证据链接。评审会不需要单独开，合并进每周例会，但要有明确的“通过/不通过”结论，不能只讨论不表态。

小团队最容易犯的错是跳过“写退出准则”这一步，理由是“大家心里都清楚”。事实是，项目进行到第四个月，没人记得当初心里清楚的是什么。

2. 50，100 人团队

这个规模是分水岭，靠吼已经管不住了。我的建议是：建立正式的里程碑评审机制，设 6，8 个里程碑，评审会独立于进度会。

这个规模需要开始考虑工具化。至少要有一个能统一存放里程碑状态和证据的地方，避免信息散落在多个文档里。同时要明确签字层级，涉及跨部门的里程碑由部门负责人签，项目内部的由项目负责人签。

一个具体的提醒：这个规模最容易出现“里程碑所有者缺失”。也就是里程碑挂在那里，但没人明确对它负责。设置责任矩阵是必须的，哪怕只是一张简单的表格。

3. 100 人以上中大型组织

中大型组织的核心问题不是管不住单个项目，而是多项目之间的里程碑互相冲突。我的建议是：建立组织级的里程碑标准，同时保留项目级的调整空间。

所谓组织级标准，是指统一的里程碑类型定义（比如需求基线、设计冻结、集成完成、验收交付这几类）、统一的退出准则模板、统一的证据归档规范。项目级调整空间是指具体的日期、评审频次、签字人可以按项目特点定。

工具层面，这个规模需要认真评估。核心考量三点：能不能承载里程碑与需求、缺陷、发布的完整关联链；支不支持私有化部署以符合数据合规；能不能平滑迁移已有的历史项目数据。前两点决定了工具能不能用，第三点决定了切换成本有多高。

顺带说一个观察：中大型组织最容易搞成“里程碑大跃进”，每个项目都设 15 个以上里程碑，然后大部分没人认真评。这种情况下，减少里程碑数量带来的收益通常比优化评审流程更大。

4. 强监管、交付型项目（乙方场景）

这类项目的里程碑管理和其他场景有本质区别：里程碑不是内部管理工具，而是合同的一部分。里程碑验收直接对应回款节点，因此容错率极低。

我的建议是：把每一个合同里程碑拆成“内部里程碑 + 对外里程碑”两层。内部里程碑提前 2，3 周，用于内部自查和整改；对外里程碑按合同日期执行，用于正式验收和回款。

这样设计的好处是，内部署的缓冲期能吸收掉大部分意外，避免对外里程碑出问题直接触发违约。代价是团队会长期处于“提前交付”的压力下，需要管理层在资源和排期上给出相应的支持。

七、不同情况下的取舍

里程碑管理本质上是一系列权衡。你想清楚每一次取舍的代价，才能做出适合自己的选择，而不是照搬别人家的做法。

1. 取舍一：控制精度 vs 管理成本

这是最根本的一组取舍。里程碑越多、退出准则越细、评审越频繁，控制精度越高，但管理成本也越高。

我在前面给过密度参考区间是 80，150 人天/里程碑。但这不是绝对标准。如果你的项目容错率极高，比如内部工具开发，拖一周没人受影响，那完全可以放宽到 200 人天以上，把管理成本压下来。

反过来，如果一次里程碑失败就意味着几十万的成本损失，那就该把密度提到 60 人天左右，多花的评审工时相比风险敞口是划算的。取舍的依据应该是“单个里程碑失败的最大损失”，而不是行业惯例。

2. 取舍二：日期刚性 vs 标准刚性

这两者你只能保一个。资源的现实约束决定了你不可能同时保证“绝对按期”和“绝对按标准”。

我的建议是优先保标准。理由是：日期延后是可见的、可沟通的、可管理的；标准降低是隐性的，代价会在后面几个阶段以返工的形式加倍偿还。前面那个 47 天延期的案例，根源就是团队选择了保日期、降标准。

但这不意味着日期可以随便推。正确的做法是给日期变更设置明确的门槛和审批链，让它变得“麻烦但可行”。麻烦到没人愿意轻易提，但又不会逼着人去做更糟糕的选择。

3. 取舍三：工具化 vs 轻量化

工具化的收益是可见性、可追溯性和自动统计；代价是实施成本、学习成本和灵活性损失。

我的经验判断是：团队规模在 50 人以下、项目并发数少于 5 个时，轻量化方案（表格 + 会议机制）通常够用，过早引入重型工具反而增加负担。当项目并发数超过 8 个，或者组织有明确的数据合规要求时，工具化的必要性就凸显出来了，尤其是私有化部署和跨项目数据汇总这两项能力，靠表格很难维护。

还要提醒一点：工具迁移是有隐性成本的。字段如何映射、历史数据怎么保留、团队习惯怎么改，这些在选型阶段很容易被低估。选择支持平滑迁移方案的工具，本质上是在降低这部分隐性成本。

4. 取舍四：全员评审 vs 关键人评审

全员评审的好处是信息透明、共识强；坏处是决策慢、容易变成表态会。关键人评审的好处是快、聚焦；坏处是容易形成小圈子判断，下游团队的顾虑传不上来。

我一般建议采用“小评审 + 大通报”的组合：评审决策由 3，5 个关键角色闭门完成，控制在 60 分钟内；评审结论和风险敞口向全体成员通报，保证信息对称。这样既保证了决策效率，也避免了信息垄断。

八、下一步你可以怎么做

如果你只能从这篇文章里拿走一件事，我希望是这个：回到你现在的项目，把每个里程碑的退出准则翻出来逐条读一遍，凡是含有“基本”“初步”“大致”“达到预期”这类词的，全部重写。这一步花不了两个小时，但它能帮你提前发现未来 80% 的扯皮。

接下来按顺序做三件事。

第一件，用三问法重新筛一遍你现有的里程碑清单，把不配当里程碑的降级成任务，把该有但没有的补上。这一步做完，里程碑数量通常会减少 30% 左右。

第二件，给每个里程碑补上签字人，且确认这个签字人不是执行者本人。如果找不到合适的签字人，说明这个里程碑的跨边界属性没想清楚。

第三件，把下一次里程碑评审会提前 30% 周期开成预评审，只做一件事，逐条对照退出准则，标出未满足项。你会立刻感受到正式评审和预评审的差别。

最后补充一个我自己的判断：里程碑管理的天花板不是流程有多复杂，而是项目负责人愿不愿意在评审会上说真话。流程再严密，如果所有人都默契地维护表面的绿色，体系就还是空的。这也是为什么我始终认为，里程碑管理的第一责任人不是项目经理，而是那个敢在评审会上说“这个不算通过”的人。