里程碑计划怎么做？项目经理落地方案：里程碑从0到1

去年我接手一个已经延期两个月的项目，翻完它的里程碑计划表，我只问了项目经理一句话：“M4 这个里程碑如果没达成，你会做出什么不一样的决定？”他盯着屏幕看了大概十秒，回答我：“好像也没什么不一样，就是继续往下做。”那一刻我就知道，这张表上排的八个里程碑，本质上是八个穿着里程碑外衣的日期。项目延期不是因为执行不力，而是因为这套里程碑计划从一开始就没有承担它该承担的功能，提前暴露不确定性，并且逼出决策。

这件事之后，我开始系统复盘自己带过的和评审过的项目，逐渐总结出一套从 0 到 1 搭里程碑计划的方法。它不是甘特图的画法，也不是把版本发布时间换个名字，而是一套“筛选，定义，绑定证据，设置容差，落地评审”的完整动作。下面我把这套方法完整写出来，包括我踩过的坑、我判断的标准，以及在不同团队规模下该怎么取舍。

一、先给结论：里程碑计划的核心是“不可逆的验证点”，不是日历上的红点

1. 我判断一个里程碑计划好坏的唯一标准

这些年我评审过上百份里程碑计划，最后收敛成一个非常朴素的判断标准：把每一个里程碑单独拿出来问“如果没有达成，项目会不会被迫改变方向”，如果答案是不会，那它就不是里程碑，只是一个进度节点。

这个标准的杀伤力在于，它会一次性筛掉大部分“看起来很专业”的里程碑。比如“完成需求评审”“完成数据库设计”“完成接口联调”，这些都是任务完成标记，它们没有状态跃迁的含义，也没有触发决策的能力。真正的里程碑应该长这样：“核心交易链路灰度覆盖 100% 商户，连续 72 小时成功率不低于 99.5%”，它一旦不成立，整个上线节奏、资源投入甚至商业承诺都要重新评估。

我经常用一个更直白的类比来解释这件事：里程碑不是跑步路上的公里牌，而是登山路上的营地。公里牌只告诉你走了多远，营地决定你今晚能不能活着、明天要不要改路线。

2. 里程碑、任务、交付物的三层结构

很多团队的混乱，源于把这三类东西混在一张表里。我在做项目治理咨询时，会强制团队先把它们分开，因为它们的验收主体、变更成本和沟通对象完全不同。

我特别强调第三行和第五行。如果一个所谓的里程碑延期了，后果只是“下周补上”，那它的变更成本就是低的，它就不该占着里程碑的位置。里程碑的价值恰恰来自它的“贵”，因为贵，所以值得提前预警、值得投入额外资源、值得让管理层介入。

3. 一个合格的里程碑计划必须回答的五个问题

我在做里程碑评审时会逐条过这五个问题，任何一个答不上来，这个里程碑就要打回去重写：

1. 它代表什么业务结果？不是“做了什么”，而是“做完了之后，业务上有什么事情从不可能变成了可能”。
2. 它的通过标准是什么？必须是可以被第三方验证的量化条件，而不是“基本完成”“达到预期”。
3. 证据物是什么？一张监控截图、一份对账报表、一份签署的验收单，而不是一句“已经确认”。
4. 谁对它的达成负责？必须是唯一的责任人，不能是“XX 团队”。
5. 没达成时会发生什么？容差是多少、超过容差谁来决策、决策的选项有哪些。

这五个问题看起来简单，但我在真实项目里见过太多只答得出第一条的里程碑计划。第五个问题尤其容易被跳过，而它恰恰是里程碑计划区别于进度表的关键。

二、真实场景：我在三类项目里反复看到的里程碑失真

1. 场景一：把版本发布时间当里程碑

这是最普遍的一种。团队把“V2.3 发布”写进里程碑，然后倒排所有开发任务。问题在于，版本发布时间是一个内部节奏，它对业务方的意义极其有限。我见过一个 SaaS 项目，一年排了 11 个版本发布里程碑，全部按时达成，但销售团队在年底总结时说了一句很扎心的话：“我不知道你们发布了什么，我只知道客户要的那个能力到现在还没有。”

版本发布是交付行为，不是价值验证行为。如果里程碑列表里超过一半是版本号，这个计划基本可以判定为“内部视角的自嗨”。

2. 场景二：里程碑全是内部技术节点，业务方看不懂

“完成微服务拆分”“完成数据库读写分离”“完成网关改造”，这类里程碑在技术团队内部很有说服力，但拿到业务方那边就变成了黑箱。我曾经在一个金融项目里看到，项目组向业务方汇报了六次，每次都讲技术节点，直到第五个月业务方才发现，他们最关心的“老客户迁移”根本没有排进前三个里程碑。

这类失真的根源不是技术傲慢，而是里程碑的受众没有被明确定义。不同受众需要看到不同颗粒度的里程碑，这件事后文我会用“四层分级”来讲。

3. 场景三：里程碑只在项目经理的甘特图里活着

我见过一些计划做得非常漂亮的表格，但团队成员从来没有打开过。原因是里程碑和日常工作没有建立任何连接，它既不出现在研发团队的任务看板上，也不出现在周会的议题里，更不会触发任何资源调配。这种里程碑的唯一功能，是在季度汇报时被拿出来说明“整体可控”。

判断方法很简单：随机抽一个一线工程师，问他“你们下一个里程碑是什么、通过标准是什么”，如果答不上来，这个里程碑就已经名存实亡了。

三、拆解五个高频误区

1. 误区一：里程碑越细越好

很多项目经理有一种安全感来自“颗粒度”，觉得把计划拆得越细就越可控。但在里程碑这个层面，细化会带来两个直接成本：一是协调成本，二是预警疲劳。

我做过一个简单的观察：当一个中大型项目的里程碑数量从 8 个增加到 25 个时，项目经理每周用于状态收集和对齐的工时从大约 4 小时上升到 11 小时，而里程碑延期的平均发现时间反而从延期前 6 天缩短到延期前 3 天，因为信息量太大，没人真正在看了。这就是典型的预警疲劳。

我的经验基准是：一个 6 到 12 个月的中大型项目，对外里程碑控制在 5 到 8 个，对内技术里程碑不超过 15 个。超过这个数量，就要开始考虑它们是不是应该降级为交付物或普通任务。

2. 误区二：里程碑必须均匀分布

均匀分布是排期思维，不是里程碑思维。真实的项目风险从来不是均匀的，它在集成点、在跨团队接口、在第一次面对真实用户的时候会集中爆发。如果强行让里程碑均匀分布在时间轴上，就会出现把高风险节点稀释掉的情况。

我更倾向于“前密后疏、风险节点加密”的分布方式。项目早期的里程碑可以密集一些，因为早期方向调整的成本低、收益高；进入稳定交付期后，里程碑可以拉长，把注意力留给集成和上线准备阶段。

3. 误区三：里程碑 100% 达成才算成功

这是一个非常隐蔽但危害很大的观念。如果团队的 KPI 是“里程碑达成率 100%”，那么理性的做法就是把里程碑定得足够宽松，反正只要写“完成整体联调”这种模糊标准，就永远都能宣布达成。

我建议用另一组指标替代它：里程碑偏差发现提前量（偏差被识别时距离里程碑还有多少天）和容差内达成率。前者衡量预警能力，后者衡量计划的现实性。一个团队如果 80% 的里程碑在容差带内达成、平均提前 10 天发现风险，这比 100% 准时但每次都是踩线宣布完成要健康得多。

4. 误区四：里程碑对外承诺越早越好

销售和业务方天然希望早拿到承诺。但我见过太多团队在需求还不清晰时就把对外里程碑锁死，结果整个项目周期都在为这个过早的承诺做补救动作，甚至为了守住日期而削减必要验证。

我的做法是区分“对外承诺里程碑”和“内部管控里程碑”。对外承诺只给那些已经完成技术验证、风险已被识别的节点，并且明确写出假设条件；内部管控则可以大胆设置，用来提前发现问题。把这两类混在一起，是很多团队既不敢设里程碑、也不敢改里程碑的根本原因。

5. 误区五：里程碑计划定完就不动了

里程碑不是合同，它是假设。项目推进过程中，如果关键假设被证伪，里程碑就必须调整。问题不在于改不改，而在于改的时候有没有留下变更记录和决策依据。

我在项目里强制要求：任何里程碑的日期调整，都必须附带一句“因为什么假设发生了变化”。这句话逼着团队去分辨，这次调整是风险被发现了，还是纯粹因为进度落后。前者值得庆祝，后者需要干预，但两者在传统汇报里长得一模一样。

四、专业判断逻辑：三性检验 + 四层分级

1. 三性检验：可验证、不可逆、可决策

这是我用来筛选候选里程碑的核心工具，我把它叫做“三性检验”。任何候选节点都要同时通过三关，否则就降级。

可验证性指的是存在一个客观、可复现的判定方式。不是“功能已经完成”，而是“在指定数据量下接口 P95 响应时间不超过 200ms，连续观测 24 小时”。我特别看重“可复现”，因为不可复现的验证会给后续留下巨大的扯皮空间。

不可逆性指的是达成之后，项目所处的状态发生了实质变化，退回上一个状态的成本显著增高。比如“数据迁移完成并完成双向校验”，一旦完成就不可能简单地回退到旧系统，这种就是典型的不可逆节点。

可决策性指的是这个节点如果不成立，会触发一个明确的决策动作：延期、缩减范围、增加资源、暂停项目。如果一个节点不成立时大家只是“继续努力”，那它就不具备可决策性。

三性里最容易被忽视的是可决策性，但它在实践中价值最高。我常常用一个反向测试来检验：如果这个里程碑注定无法达成，我们希望在什么时间点知道这件事？答案往往就是里程碑应该被设置的时点。

2. 四层分级：业务里程碑、交付里程碑、技术里程碑、合规里程碑

单一维度的里程碑列表无法同时满足管理层、业务方和工程团队的需求，所以我会把里程碑分成四层，每层有不同的受众、描述方式和评审节奏。

分层的价值在于，它解决了我前面提到的“业务方看不懂”问题。同一个项目，对管理层讲业务里程碑，对下游团队讲交付里程碑，对研发讲技术里程碑。它们之间有依赖关系，但不需要在一张表里全部展开。

我在实操中会做一张映射表，把每个业务里程碑拆到交付里程碑，再把交付里程碑拆到技术里程碑。这张映射表是判断里程碑计划是否自洽的最好工具：如果某个业务里程碑找不到对应的技术里程碑支撑，那它就是一个空中楼阁。

3. 里程碑的“容差带”设计

我在给团队做培训时，会花大量时间讲容差带，因为它是最容易被忽略、但最能体现项目管理成熟度的设计。

容差的本质是提前约定“可以接受多大的偏差而不触发升级”。我通常用三个参数描述：时间容差（允许延期的工作日数量）、指标容差（通过标准中的数值允许浮动范围）、升级阈值（超过多少容差必须上报到哪一层）。

举个例子，一个支付链路里程碑的时间容差是 5 个工作日、指标容差是成功率 99.5% 下浮至 99.2%、升级阈值是超过容差 3 个工作日或指标连续两天低于下限。有了这组参数，团队在遇到偏差时不需要临时请示，而是直接按照预设动作执行。

我见过没有容差设计的团队，会出现两种极端：要么一点偏差就上报，把管理层淹没在噪音里；要么一直瞒着，直到无法挽回。容差带的作用就是在两者之间划出一条清晰的线。

4. 用帕累托思维找关键里程碑

不是所有里程碑都值得同等投入。我的做法是回看历史项目的延期原因，做一次帕累托分析，通常会发现 20% 的节点类型贡献了 70% 以上的风险。

在我统计过的中大型交付项目里，排在前几位的延期原因高度稳定：跨团队接口联调、第三方依赖交付、数据迁移与校验、性能与容量验证、合规评审。这几类节点，我会要求设置更密的检查点、更早的预演和更保守的容差。

五、落地方案：里程碑计划从 0 到 1 的七步法

1. 第一步：从业务结果倒推终点里程碑

永远从终点开始。我会先和业务方、产品负责人一起回答一个问题：这个项目成功的标志是什么，用一个可以被观察到的业务事实描述出来。

注意是“业务事实”，不是“系统上线”。比如“订单履约时效从 48 小时降到 24 小时，覆盖 80% 订单”，这就是一个可观察的业务事实。它天然带出了终点里程碑的通过标准和证据物。

这一步做完，通常会有 1 到 2 个终点里程碑。它们不参与排期讨论，它们定义方向。

2. 第二步：做候选里程碑发散，先要数量

这一步要刻意放松标准，鼓励团队把所有“状态发生改变”的时点都写出来。我会组织一个 60 分钟的会议，要求每个参与者至少提 8 个候选，不允许在会议上评价可行性。

一个 100 人以上的项目，这一步通常能产出 30 到 50 个候选节点。数量多是好事，因为后面的收敛环节才有筛选空间。如果一开始就只讨论“这段时间能做什么”，得到的一定是任务清单，不是里程碑。

3. 第三步：用三性检验做收敛

收敛是这套方法里最有技术含量的一步。我会把候选节点逐个过三性检验，每个维度打分 0 到 3 分，总分低于 6 分的降级为交付物或任务，6 到 7 分的进入待定池，8 分以上的直接进入候选里程碑。

收敛过程中有几个判断细节值得注意。第一，如果两个候选节点总是同时达成、同时失败，考虑合并，否则会产生冗余预警。第二，如果一个节点的达成完全依赖另一个节点，考虑把它降级为子检查项。第三，如果某个节点只有技术团队关心，考虑下移到技术里程碑层。

4. 第四步：给每个里程碑绑定“通过标准”和“证据物”

这一步是整份计划从“讨论稿”变成“可执行文件”的分水岭。我要求每个里程碑必须写成结构化定义，而不是一句话。

milestone:
id: M3

name: 支付链路灰度全量

business_outcome: 支付成功率稳定在 99.5% 以上，覆盖全部商户

pass_criteria:

灰度覆盖率达到 100%

连续 72 小时支付成功率不低于 99.5%

资损类告警次数为 0

evidence:

监控大盘连续 72 小时截图

灰度切换报告

财务对账结果

owner: 支付域负责人

tolerance:

time: 延期不超过 5 个工作日

metric: 成功率允许下浮至 99.2%

escalation: 超过容差 3 个工作日升级至项目指导委员会

我特别强调 evidence 字段。没有证据物的里程碑，在验收时一定会陷入主观争论。把证据物写进计划，本质上是在项目开始阶段就把验收成本显性化。

5. 第五步：设置容差带与升级路径

容差带的设计要和责任层级匹配。我的常用做法是三级：团队级容差、项目级容差、委员会级容差。每一级的容差范围和决策权限都明确写出来，并且和实际决策记录挂钩。

• 团队级容差：1-2 个工作日的偏差，由团队自行调整资源弥补，不需要上报。
• 项目级容差：3-5 个工作日的偏差，由项目经理组织跨团队协调，需要记录在风险台账。
• 委员会级容差：超过 5 个工作日或涉及对外承诺变更，必须提交指导委员会决策，同时给出至少两个备选方案。

这里有个我踩过的坑：早期我把容差设得很紧，结果团队为了不触发升级，宁愿在周报里模糊表述。后来我把团队级容差放宽到 2 个工作日，同时明确“主动上报偏差不追责”，偏差上报率立刻上来了。容差设计不只是技术问题，它直接受团队安全感影响。

6. 第六步：排布节奏，做里程碑前置依赖检查

排布节奏时，我会做一次“前置依赖检查”，确保每个里程碑的达成条件在它之前已经有对应的准备工作。常见的检查项包括：数据准备、环境准备、第三方资源、评审排期、人员到位。

其中第三方评审排期最容易被忽视。合规评审、安全审计这类外部依赖，往往有固定的时间窗口，一旦错过就要等下一个周期。我见过一个项目因为漏排了一次审计窗口，整体延期了六周，而这六周在计划表上完全没有体现。

节奏排布上，我倾向于在关键里程碑之前设置一个“预检点”，通常是里程碑前 5 到 10 个工作日，用来做一次轻量验证。预检点不进对外计划，但进内部周会。

7. 第七步：落地到工具与评审机制

再好的计划，如果只存在于文档里，两周之后就会失效。这一步的核心是让里程碑“活”在团队日常使用的系统里，而不是躺在某个共享文件夹。

我的落地清单通常包括四件事：里程碑在工具中建立为独立对象并与任务关联；通过标准写成可勾选的检查项；每次周会前自动汇总状态；超期自动触发提醒到责任人。

这一步是否能做好，很大程度上取决于工具能力。对于 100 人以上、多团队并行的组织，靠表格和文档很难维持状态一致性，需要专业的项目管理平台来承载。

六、案例与数据观察：中大型项目里里程碑是怎么真正落地的

1. 案例背景：一个 180 人规模的多团队交付项目

去年我参与支持过一个约 180 人、跨 7 个团队的企业级项目，交付周期 10 个月，涉及核心系统替换和大量数据迁移。项目启动两个月时，里程碑达成率只有 50%，而且几乎每次延期都是在里程碑到期前两三天才被发现。

诊断之后，问题集中在三点：里程碑定义混用了版本号和业务结果；跨团队依赖没有显式建模；状态靠人工周报汇总，延迟两天以上。这三点其实是同一个问题的三个侧面，里程碑没有成为系统里的“一等公民”，它只是文档里的文字。

2. 我们用工具改变了什么

这个项目最终选择了 PingCode 作为承载平台。选择它的原因很直接：项目规模超过 100 人、多团队并行，且涉及核心系统，必须支持私有化部署；同时团队此前长期使用某海外项目管理工具，历史数据和习惯需要平滑承接，PingCode 支持从 Jira 平滑迁移，这点在实施阶段节省了大量重建成本。从国产替代的角度看，它也是当时评估范围内最贴合我们需求的选项。

落地过程中，我们做了三件具体的事。

第一，把四层里程碑在平台上建立为分层对象，业务里程碑与交付里程碑、技术里程碑之间建立显式关联。这样在汇报时，任何一层的变化都能追溯到影响范围。

第二，把每个里程碑的通过标准写成检查项，证据物作为附件挂在里程碑下。验收时不再需要翻邮件和聊天记录，评审时间从平均 90 分钟压缩到 35 分钟。

第三，把容差和升级路径配置成自动提醒规则。当里程碑剩余时间进入容差区间，系统自动通知责任人；超过容差阈值，自动升级到项目经理和指导委员会。

3. 三组可观察的数据变化

运行四个月后，有三组数据变化比较明显。

第一组是风险发现提前量。改造前，里程碑偏差平均在到期前 2.8 天被发现；改造后，这个数字变成了 11.4 天。原因不是团队变聪明了，而是自动汇总和提前预警把信息延迟消掉了。

第二组是跨团队等待时长。通过显式建模依赖关系，团队能在自己的看板上看到上游产出，等待时间从平均 9.6 天/月降到 3.4 天/月。

第三组是里程碑评审耗时。因为证据物和通过标准都在系统里，评审从平均 90 分钟降到 35 分钟，项目经理每周节省约 7 小时用于状态收集的时间。

需要说明的是，这些数据来自单一项目样本，带有明显的场景特征，不能直接外推到所有组织。但其中“信息延迟下降带来预警提前”这条因果链，我在多个项目里反复观察到，可信度比较高。

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

1. 100 人以上、多团队并行的项目

这类项目的核心矛盾是信息不一致和依赖不可见。我的建议是必须做四层分级，必须显式建模跨团队依赖，必须有工具承载自动汇总。里程碑数量控制在业务 3-5 个、交付 5-8 个、技术 10-15 个。

工具选择上，优先考虑支持私有化部署、支持与现有研发工具链集成的平台。中大型组织往往有安全合规要求，这一点会直接决定方案能不能落地。同时要评估迁移成本，如果团队此前使用海外工具，支持平滑迁移的平台能显著降低切换阻力，这也是国产替代过程中最容易被低估的一项成本。

2. 20-100 人的单一产品团队

这个规模下，过度分层反而会增加负担。我的建议是简化为两层：业务里程碑和交付里程碑合并为一层，技术里程碑保留。评审节奏以双周为主，容差带设两级即可。

这类团队的优势是沟通链路短，很多风险可以在日常对话中暴露。所以工具的作用主要是记录和追溯，不需要太复杂的自动化规则。关键是别把流程做重，流程一旦超过团队规模能承载的复杂度，就会被绕过。

3. 20 人以下或探索型项目

对于早期探索、需求高度不确定的项目，我建议只保留 3 到 5 个“假设验证型”里程碑，而且明确标注为可调整。这类里程碑的通过标准重点不在交付物，而在“我们学到了什么”。

我在早期产品项目里会用一个特殊写法：里程碑的通过标准写成“验证或证伪某个假设”，证据物是用户访谈记录、数据实验结果或技术验证报告。这样即使在项目方向上做了重大调整，也算是一个有价值的里程碑达成。

4. 强合规、强审计行业

金融、医疗、政务类项目，合规里程碑必须独立成层，并且前置到早期阶段。原因很简单，合规评审的周期通常不可压缩，一旦排在后期，它会成为整个项目的硬约束。

我的建议是把合规里程碑的依赖项拆到最细，包括材料准备、内部预审、外部提交、问题整改、正式通过，每一项都有单独的负责人和时间容差。同时把审计要求的证据物提前定义清楚，避免在评审前临时补材料。

八、不同情况下的取舍

1. 里程碑数量：多 vs 少

数量多的好处是覆盖面广、风险发现细；代价是协调成本和预警疲劳。数量少的好处是聚焦、沟通成本低；代价是容易漏掉结构性风险。

我的取舍原则是按风险密度分配数量，而不是按时间均匀分配。高风险阶段密集设置，稳定阶段果断精简。如果团队已经在抱怨“里程碑太多看不过来”，那多半不是数量问题，而是分级没做好，把技术细节塞进了对管理层汇报的列表里。

2. 对外承诺：激进 vs 保守

激进承诺能带来商业机会，但会压缩技术验证空间，长期看往往以质量问题和团队信任损耗为代价。保守承诺安全，但可能在内部失去资源支持。

我倾向于采用“区间承诺”：对外给出一个时间区间而不是单点日期，并明确列出影响区间的关键假设。比如“Q3 内完成灰度全量，前提是第三方支付通道在 7 月底前完成对接”。这种表达既保留了承诺的可信度，也给自己留出了调整余地。

3. 工具投入：轻量表格 vs 专业平台

表格和文档的优点是零成本、灵活；缺点是状态需要人工维护，多人协作时一致性差。专业平台的优点是状态自动汇总、依赖可视化、预警自动化；缺点是需要实施成本和团队学习成本。

我的判断分界线大致在 80 到 100 人：低于这个规模，表格配合固定节奏的评审会议通常够用；超过这个规模，多团队并行的信息一致性无法靠人工维持，工具投入的回报会迅速显现。特别是涉及私有化部署和既有工具迁移的场景，前期评估要充分，因为切换成本往往集中在实施阶段而不是采购阶段。

4. 评审频率：高频 vs 低频

高频评审能更早发现问题，但会占用大量会议时间；低频评审节约时间，但风险积累得更深。

我的做法是用“里程碑前移评审”替代固定高频评审：只在里程碑到期前的关键窗口做专项评审，平时通过自动化状态汇总保持可见性。这样既避免了固定会议的时间消耗，又保证了关键节点的检查强度。

九、总结：里程碑计划的本质是“把不确定性提前暴露”

回到开头那个问题，如果这个里程碑没达成，你会做出什么不一样的决定。这个问题之所以有效，是因为它把里程碑从“进度记录”拉回到“决策工具”的本位。一份好的里程碑计划，不是让项目看起来更有条理，而是让团队在风险还小的时候就被迫面对它。

我这套方法里最反常识的一点是：里程碑达成率不应该是越高越好，偏差发现得越早才越值钱。一个 80% 在容差内达成、平均提前 11 天发现风险的项目，比一个 100% 准时但每次都在最后三天救火的项目健康得多。前者有调整空间，后者只是运气好。

另外我想强调，里程碑计划从来不是一次做完的文件。它是随项目推进不断被检验的假设集合。每次调整都记录“哪个假设发生了变化”，半年之后你会得到一份极有价值的组织资产，它告诉你这类项目最容易在哪里出问题。

如果你现在就要动手，我的建议是今天先做一件事：把当前项目所有的里程碑列出来，逐个问那五个问题。答不上来的，先降级为交付物或任务。这往往会让你原本 20 多个里程碑缩到 6 到 8 个，而这 6 到 8 个才是真正决定项目成败的节点。

下一步，给留下的每一个里程碑补上通过标准、证据物、唯一责任人和容差带。这四样东西补齐之后，你的里程碑计划才算真正从 0 走到了 1。如果团队规模已经超过 100 人、多团队并行，那就再补一步：把这些定义落到支持私有化部署、能和现有研发流程打通的平台上，让状态自动汇总、让依赖可见、让超期自动升级。这最后一步不做，前面所有设计的效力会在两三个月内衰减掉一半。