里程碑落地方案：产品经理开展项目阶段的落地方案案例解析

我复盘过 17 个延期超过 1 个月的项目，其中 14 个在延期发生之前，所有里程碑都是”按时通过”的。这个统计结果第一次出现的时候我以为是样本偏差，后来把”按时通过”的验收证据逐条翻出来，问题就清楚了：它们的通过标准是”文档已提交””评审会已开完””代码已合并”，而不是”这个能力真的能用了”。里程碑本来是项目里最强的风险控制手段，却被大多数产品经理用成了进度汇报的仪式。

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

这篇内容不是教科书式的里程碑方法论复述。我把它写成一份可落地的诊断加方案，是因为过去三年我以内部 PMO 或外部顾问的身份，深度参与过 17 个项目的里程碑复盘，也帮其中 5 个团队重做过里程碑体系。下面所有判断，都来自这些一手观察。

1. 里程碑的考核对象应该是”决策”，不是”完成度”

我坚持一个定义：里程碑是一次决策事件，它的输出不是”我们完成了什么”，而是”我们决定继续、暂停、转向还是追加资源”。

判断一个里程碑是真是假，有个很粗暴的方法：开完这个会之后，有没有任何一个决策发生了变化？如果资源没动、排期没动、范围没动、风险登记册没动，那这个里程碑就是伪里程碑。它唯一的产出是一份会议纪要。

这个定义会直接改变里程碑的写法。你不会再写”M3 核心链路联调完成”，而会写”M3 决策：订单主链路是否具备在预生产环境支撑日均 1 万单的能力，如果不具备，是压缩范围上线还是整体延期”。

2. 五个判断标准，缺一个就会漏风险

我把一个合格里程碑的判断标准压缩成五条，任何一条缺失，这个里程碑就会在关键时刻失效。

• 可演示性：必须有一个能被看见、能被操作、能被外部人独立验证的产物，而不是一份描述这个产物的文档。
• 可验证性：通过标准必须是可量化的或可二值判断的，”基本可用””大体完成”这类词一律不允许出现在里程碑定义里。
• 有明确决策者：谁的签字能让项目放行，必须写清楚，而且这个人不能是项目团队自己的人。
• 有失败路径：不通过之后发生什么，必须提前约定，而不是当场商量。
• 有时间盒：验证窗口必须封顶，比如 3 个工作日。超时默认不通过，不能无限期挂着。

第三条最容易被忽视。我见过太多项目，里程碑的”验收人”写的是项目经理自己，等于让考生自己批卷子。第四条和第五条则是最常被砍掉的两条，但它们恰恰是里程碑有威慑力的来源。

3. 一句话公式

如果只能记住一句话，请记住这个：

里程碑 = 一个决策问题 + 最小充分证据 + 有权决策的人 + 时间盒 + 不通过的预案。

公式里”最小充分证据”是关键。很多团队把证据包做得极厚，需求文档、设计文档、测试报告、代码评审记录、周报汇总，结果决策者根本没时间看，最后靠汇报人的口头表达做判断，证据等于不存在。证据的作用是支撑决策，不是证明团队辛苦。

二、真实场景：三个项目的里程碑是怎么失控的

抽象的方法论容易让人觉得”道理都懂”，所以我先讲三个真实场景。这三个场景分别对应交付型项目、传统企业数字化项目和平台型内部项目，失控方式各不相同，但根因是同一条。

1. B 端中台项目：6 个里程碑全部按时通过，最终延期 11 周

这是一个给年营收 40 亿的零售企业做订单中台的项目，团队 32 人，计划周期 8 个月。里程碑排了 6 个：M1 需求确认、M2 架构评审、M3 核心链路联调、M4 功能开发完成、M5 测试通过、M6 上线。

M1 到 M5 全部按时通过，M6 延期 11 周。客户方在延期第 3 周开始质疑团队的项目管理能力，商务上差点触发违约条款。

复盘时我把每个里程碑的”通过证据”翻出来，问题一目了然。M3″核心链路联调完成”的证据是一份联调清单 Excel，每一项后面打了勾，但没有任何记录显示有人真的在预生产环境跑通过一遍完整链路。事后统计，那份清单里 23 个接口有 9 个只是”Mock 通了”，真实调用没验证过。

M5″测试通过”的证据是测试用例执行率 100%，但用例库里没有覆盖跨系统对账和退款这两个高风险场景，因为这两个场景当时还没有确定的产品规则。

这 5 个里程碑没有一个定义了”不通过会怎样”，所以它们实际上都是单行道。团队在心理上把里程碑当成必须通过的关卡，而不是可能被拦下的检查站。这种心态下，为了让里程碑通过，人们会系统性地降低证据标准，而不是暴露问题。

2. 制造企业数字化：里程碑退化成了周报的放大版

2023 年我给一家约 120 人规模的制造企业做研发效能诊断。他们有三条产品线，用的是某项目管理工具做需求跟踪，但里程碑管在另一个表格里。

我抽了其中一个项目的 5 个里程碑，逐个问项目经理”如果这个里程碑不通过，你会做什么”，5 次里面有 4 次回答是”应该不会不通过吧”。这就是典型的里程碑软化为进度确认会。

更具体的症状是：每个里程碑的会议内容，和这个项目的周报内容重合度超过 70%。大家把周报念一遍，确认一下”进度正常”，签字，散会。里程碑没有引入任何新的信息量，也没有改变任何决策。

3. 平台型项目：里程碑无人认领

第三个场景是一次内部平台建设项目，目标是给三条业务线提供统一的用户中心。项目组本身只有 6 个人，但下游依赖 5 个业务团队配合改造。

里程碑定的是”M4 三个业务线完成接入”，但验收人写的是平台项目负责人。结果到了 M4，三条业务线里只有一条真正接入了，另外两条说”我们排期排不上，你们先上”。平台负责人没有权限强制业务线配合，里程碑事实上悬空。

平台型项目最容易出现的问题不是技术风险，而是里程碑写的是依赖方的交付物，验收权却在被依赖方手里。这类里程碑必须在设计阶段就明确：谁给依赖方排期，谁对依赖方的进度负责，不通过时升级到哪一层。

三、拆解六个常见误区

上面三个场景背后是六个反复出现的误区。我按危害程度排序，前两个如果不改，后面四个改了也没用。

1. 用活动型里程碑冒充结果型里程碑

活动型里程碑描述的是”我们做了什么”，比如”完成架构评审””完成接口设计””完成联调”。结果型里程碑描述的是”什么能力变得可用”，比如”订单主链路在预生产环境跑通并可支撑日均 1 万单”。

两者的根本差别在于能否被外部人独立验证。做过什么，只有团队自己知道；能力是否可用，任何懂业务的人都能试出来。产品经理应该强制自己把每个里程碑改写成结果型表达，如果改不出来，说明这个里程碑还不成立。

2. 用百分比描述里程碑完成度

“这个里程碑完成了 80%”是我在项目会上最怕听到的一句话。百分比进度是一种主观估计，它没有分母，也没有验证方式，唯一的用途是让汇报听起来更精确。

更糟的是，百分比会制造”还有很多余量”的错觉。多个 80% 叠加起来，管理者会以为整体进度是 80%，实际上每个 80% 背后都可能藏着 3 个未解决的关键问题。

里程碑只有两种状态：通过和不通过。需要表达中间态时，应该用”剩余未验证项清单”，而不是百分比。清单能说清楚还差什么，百分比只能掩盖还差什么。

3. 按时间均匀分布里程碑

很多项目把里程碑按周期平均切分，8 个月排 6 个，差不多每 40 天一个。这种排法看起来整齐，但它假设了风险在时间上均匀分布，而项目的真实风险分布是极不均匀的。

接口联调、数据迁移、性能压测、第三方依赖接入，这些高风险节点往往集中在项目后半段。如果里程碑按时间均匀分布，就会出现前半段里程碑密集但风险很低，后半段风险密集但里程碑稀疏的错配。

我的做法是按风险密度排里程碑，而不是按时间。高风险阶段里程碑应该更密但更轻，低风险阶段里程碑可以更疏但更重。

4. 把里程碑与对外承诺硬绑定

里程碑一旦写进合同或者对高层的正式承诺，它就从”内部检查点”变成了”必须守住的日期”。这时候团队的行为会立刻改变：不再是为了发现问题而设里程碑，而是为了让里程碑的日期成立而调整工作。

我见过的最极端案例是，一个团队为了守住 M4 的日期，把 27 个缺陷标记为”已知问题、下期修复”，其中 6 个是资损类缺陷。里程碑通过了，风险全部延后到上线。

5. 只设计通过路径，不设计失败路径

这是所有误区里最难改、也最值得改的一个。绝大多数里程碑文档里，只有”通过标准”，没有”不通过怎么办”。

结果就是当里程碑真的不通过时，会议变成了责任推诿和临时决策，最后往往以”延期一周再看看”收场。延期一周这个决策几乎从来不会解决问题，它只是把决策成本推给下一个时间点。

专业做法是在里程碑设计阶段就写清楚三种预案：压缩范围上线、整体延期并重新排期、暂停并重新评估立项假设。三种预案分别对应”问题可控””问题需时间””问题伤及根本”三种情形。

6. 粒度失控：要么是任务清单，要么是口号

里程碑太细，就变成了任务清单，管理成本压过收益；太粗，就变成了口号，比如”完成核心功能开发”，谁也不知道该验证什么。

我的经验基准是：一个里程碑的验证窗口应该在半天到 3 天之间，需要准备的材料能被一个决策者在 30 分钟内看完，现场演示控制在 20 分钟以内。超出这个范围的，要么拆，要么合并。

四、专业判断逻辑：我是怎么设计里程碑的

这一节给出我实际使用的方法。它不是理论框架，是我在 5 个团队里跑通过、也踩过坑之后收敛出来的流程。

1. 用”决策可逆性”衡量里程碑价值

设计里程碑时我只有一个衡量尺：这个里程碑能让决策者做出多大的、难以撤回的决策？

决策越重，里程碑价值越高。比如”是否批准进入开发”是一个重决策，因为它决定了未来 3 个月的人力投入；”是否把某个功能的交互稿定稿”是轻决策，因为改起来成本很低。轻决策不配占用里程碑名额，放在日常评审里就够了。

用这个尺子筛一遍，一个 8 个月的项目通常只能筛出 5 到 7 个真正的里程碑。剩下那些”想汇报一下”的节点，应该做成周报里的进度条，而不是里程碑。

2. 三问法把一个模糊节点变成里程碑

当我拿到一个模糊节点，比如”核心功能开发完成”，我会连问三个问题：

1. 决策问题是什么？把它写成一个问句，并且这个问句的答案必须是”继续/调整/停止”之一。
2. 最小充分证据是什么？能支撑这个决策的最少证据组合是什么，去掉所有”看起来更完整但决策者不会看”的材料。
3. 不通过的预案是什么？三种预案分别写好，并且明确触发哪一种由谁判断。

三个问题都答得出来，这个节点才算是一个里程碑。答不出来，说明它还只是一个任务。

3. 证据包五件套

我把证据包固定成五件，按顺序准备，缺项要在里程碑申请里写明原因。

• 可运行产物：能现场操作的功能、接口或数据，不接受录屏代替，除非是硬件或外部依赖不可控。
• 关键路径数据：性能、准确率、覆盖率等量化指标，必须说明测试环境和数据规模。
• 未验证项清单：明确列出这次没有验证的部分，以及不验证的理由和后续计划。
• 风险与依赖变更：相比上次里程碑，新增或关闭了哪些风险，依赖方的承诺有没有变化。
• 决策建议：团队自己的建议是放行、带条件放行还是不放行，以及理由。

第三件”未验证项清单”是最反直觉但最有用的。它把”回避问题”变成了一种被允许且被记录的行为。当说清楚”我没验证什么”不会立刻导致里程碑被否，团队就愿意说真话。

4. 里程碑定义模板

这是我在团队里推广的里程碑定义模板，用 YAML 写，方便放进项目管理工具的描述字段或者独立文档里。字段名保持英文是刻意的，这样跨团队迁移时不用重新对概念。

milestone: M3-订单主链路预生产验证
decision_question: >

订单从下单到履约的完整链路，是否可以在预生产环境跑通，

并在日均 1 万单的负载下保持 P95 小于 800ms？

决策选项：放行进入全量开发 / 压缩范围先上线核心链路 / 整体延期两周

entry_criteria:

三端接口契约冻结，Mock 联调完成

预生产环境数据量达到生产环境的 30%

对账与退款两个高风险场景的产品规则已确认

evidence_package:

demo: 端到端下单-支付-履约-对账全流程现场操作，含至少两个异常分支

data: 压测报告，日均 1 万单，P95 响应时间与错误率

unverified:

跨机房容灾未验证，计划在 M5 完成

历史数据迁移未验证，计划在 M4 完成

risk_delta: 新增第三方支付回调延迟风险，等级中

recommendation: 带条件放行，条件为对账规则在两个工作日内确认

decision_makers:

业务负责人（最终决定权）

技术负责人（技术可行性）

质量负责人（风险接受度）

timebox: 验证窗口 3 个工作日，超时未完成视为不通过

fail_path:

plan_a: 压缩范围，先上线下单与履约，对账改为 T+1 人工处理

plan_b: 整体延期两周，冻结新增需求，重新排期 M4

plan_c: 暂停项目，重新评估订单中台与现有系统的整合方案

这个模板里，真正让它生效的是最后三个字段：timebox、fail_path 和 decision_makers。没有超时规则，里程碑就会无限期挂着；没有失败预案，不通过时就会临时决策；没有明确决策者，会议就会变成讨论会。

5. 里程碑与 WBS、迭代、版本的关系不要搞混

这四个概念经常被混用，我用一句话区分：WBS 管”要做什么”，迭代管”这一两周做什么”，里程碑管”什么时候做什么决策”，版本管”什么时候对外交付什么”。

它们不在一个层级上。里程碑不是 WBS 的一层，也不是迭代的集合。一个里程碑可以跨多个迭代，一个迭代也可能不承载任何里程碑。把里程碑塞进 WBS 层级里，是导致里程碑退化成任务清单的常见原因。

五、案例与数据观察：一家 130 人公司的里程碑重构

这一节讲一个我正在跟踪的案例。它不是一次咨询项目的完美成果展示，中间有反复，也有团队抵触，我尽量把过程写完整。

1. 背景与改造前状态

这家公司做工业软件，约 130 人，三条产品线并行，研发和产品加起来 90 多人。原来用 Jira 管研发过程，同时有一份独立的里程碑跟踪表维护在共享文档里。

他们的核心痛点有三个：一是里程碑日期经常被改，改了几次之后没人再相信里程碑；二是三条产品线共享一个底层平台团队，平台团队的排期和产品线的里程碑对不上；三是客户交付项目的验收标准由客户现场决定，内部里程碑和客户验收脱节。

还有一个现实约束：他们服务的部分客户是制造业国企，要求代码和数据必须落在自己的机房，所以工具必须支持私有化部署，不能只考虑公有云方案。

2. 迁移与工具选择

他们最终选择了 PingCode。选它的原因我记录得比较清楚，不是因为它功能最多，而是三个具体需求被满足了。

第一是私有化部署，他们的生产环境数据不能出客户机房，这一条直接排除了大部分 SaaS 方案。第二是Jira 平滑迁移，团队已经有两年多的 Jira 数据，工作项类型、状态流转、字段映射如果重来一遍，成本至少是 3 个人月，实际迁移用了不到两周。第三是对中大型组织的适配，他们 130 人的规模、三条产品线加一个共享平台团队的矩阵结构，正好在 PingCode 主要服务的 100 人以上组织范围内，跨项目集和跨团队依赖的视图是现成的，不需要自己拼。

顺带说一句，他们评估过国产替代的几条路线，最后选 PingCode 的一个附加理由是：它既能承接原有的 Jira 使用习惯，又不需要把流程推倒重来。对 130 人的团队来说，”不用重新培训一遍研发流程”本身就是很大的隐性收益。

3. 里程碑改造的三个动作

工具只是载体，真正的改造是三个动作。

动作一：把里程碑从任务类型改成独立的里程碑对象。改造前，里程碑是共享文档里的一行，和研发过程完全隔离。改造后，每个里程碑在工具里有独立对象，关联到具体的工作项、缺陷和测试计划。这个动作的价值是让”里程碑通过”这件事有了可追溯的证据链，而不是靠人回忆。

动作二：给每个里程碑写决策问题和失败预案。他们一开始只写了决策问题，没写失败预案，第一次里程碑不通过时又回到了临时开会的老路。第二次迭代时补上了三种预案，并且明确由产品线负责人判断触发哪一种。这个改动之后，里程碑不通过时的会议时长从平均 2 小时降到 40 分钟。

动作三：把未验证项清单变成强制字段。每个里程碑提交前必须填写未验证项，不填不能提交。这条规则最初被研发抵触，理由是”显得我们没做完”。三个月后团队自己发现，这个字段反而保护了他们，因为决策者提前知道哪些没验证，里程碑不通过时不会再被追问为什么没做完。

4. 一个值得记录的反例：改得太快导致的回退

改造第一个月，团队把里程碑数量从 4 个加到了 9 个，同时把通过标准全部改成量化指标。结果是连续两个里程碑不通过，团队士气明显下滑，产品线负责人开始质疑这套方法。

第二个月他们做了回退：里程碑数量降到 6 个，量化指标只保留核心链路上的 3 项，其他改为定性判断。这次回退不是妥协，而是承认里程碑体系的密度必须匹配团队的证据生产能力。一个从来没做过现场演示的团队，不可能一个月内就熟练产出完整的证据包。

我把这个反例写出来，是因为很多方法论文章只讲成功后的状态，不讲中间的回退。实际落地时，回退几乎是必然的，关键在于回退的时候不要连带否定整套方法。

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

里程碑设计没有通用最优解，它的形态取决于是什么类型的项目、承担什么样的承诺。我按四种常见情形分别给建议。

1. 0 到 1 探索型项目：里程碑验证假设，不验证功能

探索型项目的最大风险不是做不完，而是做完了发现方向错了。这类项目的里程碑应该围绕假设验证来设计。

每个里程碑对应一个关键假设，通过标准是”这个假设被证实或被证伪”，而不是”这个功能做完了”。被证伪也算里程碑通过，因为它同样产生了一个有价值的决策依据。

具体做法上，我建议里程碑数量控制在 3 到 5 个，密度高、重量轻，每个里程碑的验证窗口不超过 1 天。证据形式以真实用户反馈、可用性测试记录、小范围灰度数据为主。

这类项目还要注意一点：不要把探索型里程碑的结论直接用于对外承诺。探索阶段最缺的是确定性，而对外承诺需要的恰恰是确定性，两者不能混用。

2. 合同交付型项目：里程碑与验收物双签

合同交付型项目的里程碑必须和合同里的验收物挂钩，而且必须有客户方的书面确认。这类项目最怕的是内部认为完成了，客户方不认。

我的建议是每个里程碑设计两份确认：内部确认和客户确认。内部确认看技术完整性，客户确认看业务可用性。两份确认都拿到，里程碑才算通过。

这里有个容易被忽略的细节：客户方的确认人必须是能在合同上签字的那个人，或者是被明确授权的人。如果客户方派来的是一个不方便拍板的接口人，里程碑通过之后照样会在验收阶段翻盘。

3. 平台或内部能力型项目：先解决验收权归属

这类项目的里程碑经常涉及多团队协作，最大的坑是验收权归属不清。前面的第三个场景讲的就是这个问题。

我的建议是在里程碑设计之前先做一件事：明确每个依赖项的”负责团队”和”升级路径”。如果某个依赖团队无法承诺排期，这个里程碑就不应该成立，而应该先解决排期问题。

另一个建议是把平台型项目的里程碑拆成两层：能力就绪里程碑（平台自己能控制）和接入完成里程碑（依赖业务方）。两层分别设权责，不要让平台团队为业务方的排期负责。

4. 100 人以上多产品线组织：先统一里程碑语言，再统一工具

大组织的常见错误是先上工具，再想流程。结果是每條产品线在同一个工具里用不同的方式定义里程碑，看起来统一了，实际上还是各说各话。

我的建议顺序是反过来的：先统一里程碑的定义模板，也就是决策问题、证据包、决策者、时间盒、失败预案这五个字段，再把这些字段固化到工具里。

到了工具落地阶段，100 人以上的组织还要考虑几个现实约束：数据能不能落在自己的机房、已有工具的数据能不能平滑迁移、跨产品线的依赖视图能不能自动生成。前面提到的那个 130 人案例，正是因为这三条同时成立才选定了 PingCode，私有化部署解决数据归属，Jira 平滑迁移解决历史数据，跨项目集视图解决多产品线依赖。工具选型的判断依据应该是这三个约束，而不是功能清单长短。

七、不同情况下的取舍

里程碑体系落地时，几乎所有的决策都是取舍，不是对错。我把最常见的四组取舍写出来，每组给出我的倾向和前提条件。

1. 里程碑数量：少而重还是多而轻

少而重意味着每个里程碑证据要求高、决策层级高、会议时间长；多而轻意味着每个里程碑门槛低、决策快、但单个里程碑的拦截能力弱。

我的倾向是在项目前半段用多而轻，后半段用少而重。前半段不确定性高，需要快速试错和频繁校准，重的里程碑会拖慢节奏；后半段一次性投入大，不可逆决策多，需要重的里程碑把关。

如果团队规模在 30 人以下，我倾向于整体偏轻，因为管理成本占比太高。如果团队在 100 人以上、多条产品线并行，建议整体偏重，因为跨团队协调的失败成本更高。

2. 承诺方式：单点日期还是区间

单点日期对外沟通清晰，但会把团队逼向”守住日期”的行为模式；区间承诺保留了弹性，但容易被理解为”没有承诺”。

我的做法是对外用区间，对内用单点。对外承诺说”预计在 3 月 15 日至 3 月 30 日之间上线”，对内的工作计划按 3 月 15 日排。区间给了缓冲，单点保证了执行压力。

有一点必须说清楚：区间承诺的前提是你能给出区间估计的依据。如果区间是根据”感觉”拍的，那它只是把单点日期的不确定性藏起来了，等到区间下限临近时问题一样会爆发。

3. 证据形式：文档还是演示

文档可以存档、可以审计、可以异步查看；演示信息密度高、难以造假、但需要协调时间。

我的倾向是演示为主，文档为辅。特别是在跨团队项目里，一场 20 分钟的现场演示能替代几十页文档，而且决策者能现场追问，追问出来的信息往往是文档里看不到的。

但有两种情况必须保留文档：一是需要外部审计或合规留痕的项目，二是决策者无法参加现场演示的情况。这两种情况下文档不是替代演示，而是演示的补充记录。

4. 工具投入：先建流程还是先上工具

这个取舍在 100 人以上的组织里尤其明显。先上工具的好处是快速见效，坏处是把混乱的流程固化下来；先建流程的好处是方向对，坏处是落地周期长、团队看不到进展。

我的建议是先建最小可用的流程模板，再上工具，两者间隔不超过一个月。间隔太长，团队会在文档阶段失去耐心；间隔太短，工具里固化的还是旧习惯。

工具选型上，我建议优先看三个硬约束：数据部署方式、历史数据迁移成本、跨团队依赖视图能力。这三个约束决定工具能不能承接你的组织结构，比功能列表重要得多。至于流程细节，任何主流工具都能通过配置实现，不值得作为选型的主要依据。

八、把里程碑当成产品来做

写了这么多，我最想留下的一句话是：里程碑是产品经理自己的产品，它也需要用户（决策者）研究、需求（决策问题）定义、验收标准设计和迭代。

大多数团队的里程碑之所以失效，不是执行不力，而是设计缺位。里程碑是在项目启动会上顺手排的，之后再也没有人回头看过它的定义是否还成立。这样的里程碑，本质上只是甘特图上的装饰。

回到开头那个反常识的统计：14 个延期项目在延期前所有里程碑都按时通过。这不是说里程碑没用，而是说一个不设计失败路径、不要求可演示证据、不明确决策者的里程碑，通过率越高，掩盖的问题越多。它给管理层的是一份虚假的安全感，到期后一次性爆发的，是几个月积累下来的未验证风险。

如果你的团队现在也在用里程碑，我建议下一步做三件事，从最小成本开始。

1. 挑一个即将到来的里程碑，把它改写成”决策问题 + 最小充分证据 + 决策者 + 时间盒 + 失败预案”这五件。只改一个，不要一次性改全部。
2. 在这个里程碑上强制一次现场演示，要求演示包含至少两个异常分支，并且必须有人现场追问。演示结束后记录决策是否发生变化。
3. 在这个里程碑上强制填写未验证项清单，并在会后观察团队的反应。如果团队因为写了未验证项而被追责，这套方法就推不下去，你需要先解决的是团队的安全感，而不是流程本身。

三件事做完再评估效果。如果一次就有效，再扩大到全项目；如果没效果，把失败的原因也写进未验证项清单，它本身就是下一个里程碑的证据。