动态管理方法大全：产品经理进度跟踪实操方法落地清单

去年秋天我接手一个跨 4 个团队、涉及 6 个系统的会员中台重构项目。第 3 周周报上写着"整体进度 78%，风险可控"，第 7 周突然爆出支付网关的联调依赖被上游拖了 19 天，整个上线时间被迫推迟一个月。复盘时我发现一个很讽刺的事实：我们每天都在跟踪进度，站会开得比谁都勤，看板卡片比谁都多，但我们从来没有真正"动态管理"过，我们只是在反复确认一个已经过期的计划。这件事之后我花了将近一年时间，在三个不同规模的项目里反复调整跟踪机制，踩过的坑比读过的书多。

这篇文章就是那一年里我认为真正管用的东西，不是方法名词的罗列，而是一份可以直接拿去跑的落地清单。

我会先给出一个可能让你不太舒服的结论，然后拆解为什么大多数产品经理的进度跟踪会失效，接着给出五个必须跟踪的对象、四个阶段的动作设计、六张可复制清单、工具选型的判断标准，以及不同团队规模下的取舍建议。全文约 6000 字，建议先收藏，再按第十节的 7 天计划在自己团队里试跑一遍。

一、核心结论：动态管理的本质是"有机制地变"，而不是"随时改"

先说结论。动态管理不是把计划改成随时可变的，而是把"变化"这件事本身装进一个有触发条件、有责任人、有升级路径、有记录的机制里。计划可以变，但变的过程必须可追溯、可解释、可复盘。没有机制的变化叫失控，有机制的变化才叫动态管理。

1. 一个反常识判断：跟踪失效通常不是因为跟踪不够频繁

很多人第一反应是"我们跟踪得不够勤"，于是把周会改成日会，把日会改成早晚各一次。我做过这个实验，结果是会议时间增加了 60%，但延期暴露的时间点几乎没有提前。原因很简单：高频同步只能加速信息流动，不能提高信息质量。如果每个人汇报的都是"我在做"，而不是"我卡在哪、需要谁、什么时候能好"，同步频率再高也只是把噪音播得更响。

真正的瓶颈在于三个地方：跟踪对象选错了、状态定义模糊了、异常没有升级路径。后面会逐一拆开讲。

2. 动态管理的四个必要构件

我把一个能跑起来的动态管理机制拆成四个构件，缺一个就会退化：

• 触发条件：什么情况下必须更新计划？比如"关键路径任务延期超过 2 个工作日"或"依赖方承诺时间变更"。
• 责任人：每一类变化由谁负责记录、谁负责决策、谁负责通知。
• 升级路径：问题在什么时限内没解决就往上走一层，走到谁为止。
• 记录载体：变化写到哪张表、哪个字段，下次复盘时能不能查到。

我见过太多团队只有第一个构件，大家都知道"延期了要处理"，但没人说清楚谁处理、什么时候升级、记在哪里。结果就是每次延期都靠临时开会救火，救完就忘，下一个项目再犯一遍。

3. 三分钟自检：你的团队是否真的在动态管理

问自己四个问题，如果超过两个答不上来，说明你现在的进度跟踪还停留在"静态日报"阶段：

1. 项目当前的关键路径是哪几条任务？最近一次更新是什么时候？
2. 上一个被升级的阻塞问题，从发现到升级用了多久？
3. 本月的范围变更记录在哪里？谁批准的？
4. 如果明天核心开发请假一周，你的计划会怎么调？依据是什么？

这四个问题分别对应关键路径可视化、升级时效、变更控制和资源弹性。能答上来的团队，通常延期暴露时间点能提前 1，2 周。

二、为什么进度跟踪总是失效：三个我踩过的坑

在讲方法之前，我想先把失败场景讲透，因为大部分方法教程的问题是它们只告诉你"应该怎么做"，不告诉你"为什么你现在做的没用"。

1. 站会开成了逐人汇报，信息密度接近零

典型的 15 分钟站会是这样：8 个人轮流说"昨天做了什么、今天做什么、没有阻塞"。听起来很标准，但实际结果是：前 5 个人的发言没有人真正在听，因为跟自己无关；后 3 个人因为时间压力草草带过；真正的问题，比如"我等的接口文档还没给我"，被淹没在流水账里。

我统计过一次，一个 8 人团队、15 分钟站会，有效信息（即能触发后续动作的信息）大约只有 90 秒。站会的问题不在于形式，而在于它把"同步"和"解决问题"混在了一起。同步适合异步做，解决问题才需要面对面。

2. 看板三个月后变成僵尸板

几乎所有团队都建过看板，也几乎所有的看板都会在 2，3 个月后失效。失效的标志很一致：卡片停留在"进行中"超过两周没人动，但没人觉得有问题；"已完成"列的卡片数量远超实际交付量；没人再去看板上的泳道划分。

根本原因是看板缺少流转规则。什么叫"进行中"？是开始写代码，还是开始设计？一张卡片在"进行中"待多久算异常？没有人定义，看板就退化成一个共享的待办列表，而不是一个进度仪表盘。

3. 延期在验收前一周才暴露

这是最痛的一种。项目前几天一切正常，最后一周突然发现三个模块都没完成，原因是它们都依赖同一个上游接口，而上游接口一直"快好了"。这类问题的本质是依赖没有被当作一等公民来跟踪。任务有 owner、有截止日、有状态，但依赖往往只存在于口头承诺里，没有任何记录字段和检查点。

我后来的做法是：任何跨团队、跨系统、跨角色的依赖，都必须在依赖表里有一行记录，包含"依赖方、承诺时间、验证方式、复查日期"。这一条改动单独就让我们的延期暴露时间提前了将近两周。

三、拆解六个常见误区

接下来这六条，是我在复盘会上反复听到、也反复纠正过的错误认知。每一条我都标注了纠正方向。

1. 把"跟踪频率"当成"跟踪质量"

每日同步不等于每日有效跟踪。频率解决的是信息新鲜度，质量解决的是信息可用性。一个每天更新但只写"正常推进"的看板，价值低于一个每周更新但明确标注了阻塞和依赖的看板。

我的建议是：先花两周把字段和口径定清楚，再考虑提高频率。顺序反了，只会增加所有人的负担。

2. 用任务完成率代替里程碑健康度

"完成了 80% 的任务"是一个几乎没有任何决策价值的指标。因为剩下 20% 的任务可能是整个项目的关键路径，也可能全是收尾工作。更糟的是，任务计数的口径非常容易被操纵，把一个任务拆成三个，完成率立刻好看很多。

我后来基本不看任务完成率，只看两个东西：关键路径上的里程碑是否按计划达成，以及下一个里程碑的预测达成日期。这才是能拿去做决策的信息。

3. 依赖管理只存在于口头

这是我认为最容易被忽视、代价最大的一条。团队内部的依赖相对好办，因为大家坐在一个会议室里；跨团队的依赖才是重灾区。我在一个项目里统计过，导致延期的事件中，超过一半来自外部依赖。

纠正方法很简单但需要纪律性：任何依赖必须在提出当天进入依赖表，并且有明确的验证方式，比如"接口文档已提供且字段确认""联调环境可用且返回正确状态码"。没有验证方式的依赖，等于没有依赖。

4. 风险登记册变成了道歉清单

很多团队有风险表，但表里的风险从来不变，三个月前的风险和今天一模一样，状态栏永远写着"关注中"。这样的风险表已经不是管理工具，而是一份"我们知道有问题但没人处理"的道歉清单。

我的判断标准是：风险表里每一条风险，必须有 owner、必须有一个明确的复查日期、必须能回答"如果它发生了，我们损失的是一天还是一周"。超过复查日期没有任何更新的风险，要么关闭，要么升级。

5. 变更不记录，范围悄悄膨胀

范围膨胀很少以"我要加一个大功能"的形式出现，它几乎总是以"这个小调整顺手做一下吧"的形式出现。单个看起来都不大，累积起来能吃掉 20% 以上的排期。

我的做法是设一个很低的记录门槛：只要影响到本迭代承诺范围的改动，一律进变更表，哪怕只花半小时。记录的目的不是审批，而是让膨胀可见。多数时候，一旦可见，提出者自己就会重新评估优先级。

6. 指标口径各说各话

同一个项目，开发说完成了 70%，测试说只收到 40%，产品说需求还没冻结。这不是态度问题，是口径问题。"完成"到底指代码提交、自测通过、还是联调通过？不统一，每次进度会都会变成一场对定义的争论。

解决办法是把状态定义写进模板，作为清单的一部分固化下来，见第六节。

四、专业判断逻辑：跟踪先看五个对象

这一节是全文的方法核心。我不建议按"方法名"来组织进度跟踪，而建议按"跟踪对象"来组织。方法会随工具和团队变化，但需要被跟踪的对象是稳定的。

1. 任务流：谁在做什么，卡在哪里

判断问题：当前有多少张卡片处于"进行中"状态超过 5 个工作日？如果超过团队人数的 30%，说明工作被过度并行化，实际产出反而会下降。

记录字段建议：任务 ID、负责人、状态、进入当前状态的时间、阻塞原因、下次检查点。注意"进入当前状态的时间"这个字段，它比"开始日期"有用得多，因为它是计算滞留时间的基础。

2. 里程碑：关键节点是否偏移

判断问题：下一个里程碑的预测达成日期是什么？和基线差几天？很多人只记录"里程碑是否完成"，那是事后信息，没有决策价值。真正有用的是预测达成日期，而且要每周更新。

记录字段建议：里程碑名称、基线日期、预测日期、偏差天数、依赖项、验收标准。偏差超过 3 个工作日的里程碑，必须在周会上单独讨论。

3. 依赖：跨团队、跨系统、跨角色的阻塞

判断问题：有多少个依赖已经超过承诺时间但没有交付？这个数字是外部风险的最直接指标。

记录字段建议：依赖描述、依赖方、我方接口人、承诺时间、验证方式、复查日期、当前状态、影响的里程碑。这里我最强调"验证方式"，因为它是把口头承诺变成可核查事实的唯一手段。

4. 风险与阻塞：是否升级，是否有 owner

判断问题：有多少问题在团队内部停留超过 3 个工作日没有决策？这些就是应该升级的对象。

记录字段建议：问题描述、影响范围、发现时间、owner、升级层级、升级时间、解决方案、关闭时间。注意把"阻塞"和"风险"分开：阻塞是已经发生的问题，风险是可能发生的问题，它们的处理节奏完全不同。

5. 范围与资源：需求是否膨胀，资源是否过载

判断问题：本迭代新增的需求占原始承诺的百分比是多少？关键角色的人均并行任务数是多少？前者超过 15% 就应该考虑裁剪，后者超过 2 就应该调整排期。

记录字段建议：变更描述、提出人、影响工时、是否影响里程碑、决策结果、决策人、决策日期；资源侧记录角色、当前任务数、占用率、冲突项。

五、按项目阶段落地：四个阶段的动作与退出条件

动态管理的动作不是一成不变的，它会随项目阶段变化。我给每个阶段定义了目标、核心动作、输出物和退出条件，这样团队知道什么时候该切换到下一套节奏。

1. 启动期：把不确定性显性化

目标是把"未知"尽可能变成"已知"或"已知的未知"。核心动作包括：明确目标与成功标准、划定范围边界、识别关键里程碑、画出初始依赖图、做一轮风险预判、定义角色职责。

输出物是四样东西：里程碑清单、依赖表初版、风险表初版、RACI 矩阵。退出条件是关键路径可识别、主要外部依赖都有对应接口人、风险表里每一条都有 owner。

我自己的经验是，启动期投入 2，3 天做这件事，能省下后面至少两周的救火时间。很多团队急着开工，结果是在执行期反复补这几张表。

2. 执行期：保持信息新鲜度

目标是让进度信息不超过 3 天的延迟。核心动作包括：建立异步日更（不是每日站会）、维护看板流转、每周更新里程碑预测日期、每周检查依赖表。

输出物是每周的进度快照和依赖状态清单。退出条件是出现第一个需要变更计划的事件，这通常意味着进入波动期。

这个阶段我强烈建议把"同步"和"决策"分开：日常同步走异步文档，每天早上花 5 分钟更新自己的卡片状态；需要决策的问题集中到每周一次的 45 分钟会议上。我试过这个模式，会议总时长减少约 40%，而问题解决速度反而更快。

3. 波动期：处理变化本身

波动期不是异常状态，而是项目的正常组成部分。目标是让每一次调整都有记录、有决策、有对里程碑的重新评估。

核心动作包括：所有范围变更进变更表、所有阻塞按升级路径处理、必要时重排资源、必要时裁剪范围。输出物是更新后的里程碑清单、变更记录、修订后的依赖表。

退出条件是偏差被收敛到可接受范围，或者上线时间被正式重新确认。这里我要强调一句：重新确认上线时间不是失败，隐瞒偏差才是。我见过太多团队为了"不显得失败"而假装进度正常，最后付出的是数倍的返工代价。

4. 收尾期：验收、复盘与沉淀

目标是完成交付并把经验变成资产。核心动作包括：验收标准逐条核对、遗留问题登记、复盘会、模板更新。

输出物是验收报告、遗留清单、复盘记录、更新后的模板库。退出条件是至少有一条模板或规则因为本次复盘被修改。如果复盘后什么都没变，那这场复盘基本等于没开。

六、六张落地清单（可直接复制使用）

这一节是全文最"工具化"的部分。我给每张清单列出字段和填写规则，你可以在项目管理平台里建对应的表单，也可以先用表格跑起来。

1. 里程碑与依赖清单

这张表决定你能不能提前发现延期。字段如下：里程碑名称、基线日期、预测日期、偏差天数、关键路径标记、依赖项、验收标准、责任人、下次复查日期。

填写规则有三条：预测日期每周必须更新一次；偏差超过 3 天自动进入周会议题；关键路径标记全项目不超过 8 条，多了就失去意义。

2. 同步清单（异步日更模板）

我用一页模板替代了每日站会，字段只有四项：昨天推进了什么、今天计划推进什么、当前阻塞是什么、需要谁配合。最后一项是关键，没有它，同步文档就退化成日记。

【日更模板】
日期：

负责人：

昨日完成：（限2条，写结果不写过程）

今日计划：（限2条）

当前阻塞：（无则写"无"）

需要谁配合：（写具体人名 + 具体事项 + 期望时间）

下次检查点：（日期）

纪律要求：阻塞项如果不是"无"，必须在提出当天进入风险与阻塞升级表。这条规则是整套机制里最重要的一条。

3. 看板流转规则

看板失效的根源是没有规则。我建议至少定义五个列，并为每一列设置进入条件、退出条件和滞留预警时间。

滞留预警是这套规则的核心。超过预警时间的卡片会自动标红，负责人必须在 1 个工作日内给出说明：要么继续，要么阻塞，要么拆分。不允许"就这样放着"。

4. 风险与阻塞升级表

字段：编号、类型（风险/阻塞）、描述、影响范围、影响程度、发现日期、owner、升级层级、升级日期、处理进展、复查日期、关闭日期。

规则：team 内部停留超过 3 个工作日未决策的，自动升级一级；升级后 2 个工作日仍无结论的，再升一级。升级层级建议不超过三级，通常对应团队负责人、项目负责人、跨部门决策组。

5. 变更控制表

字段：变更描述、提出人、提出日期、影响工时、是否影响里程碑、影响哪个里程碑、优先级评估、决策结果、决策人、决策日期、进入哪个迭代。

规则只有一条但必须严格执行：任何影响本迭代承诺范围的变更，无论大小，必须进表。这张表的价值不在于审批，而在于让累积膨胀可见。我一般每两周统计一次变更影响工时总计，超过原始承诺 15% 就触发范围裁剪讨论。

6. 进度健康度仪表盘

我不用任务完成率做仪表盘，只用六个指标。它们要么直接对应风险，要么直接对应决策。

七、工具怎么选：轻量、中量、重量，以及适用边界

工具选型这件事，我见过最多的错误不是选错了，而是选重了。小团队上了重型平台，结果是流程走不下去、数据没人维护、三个月后彻底弃用。

1. 三档工具能力与适用场景

判断标准我给四条：团队规模、项目复杂度（依赖数量）、远程协作程度、流程成熟度。如果四个维度里有两个以上偏"高"，才值得上重量级方案。只要一个是"高"，中量级通常足够。

2. 什么时候该上重型的一体化平台

我经历过一次从轻量工具迁移到一体化平台的过程。当时团队规模从 30 人扩到 120 人，产品线从一个变成三条，跨团队依赖从每周两三个变成每天十几个。这时候表格已经跟不上了，不是因为功能不够，而是因为依赖关系和权限边界无法在表格里有效表达。

需要上一体化平台的三个典型信号：一是跨团队依赖数量持续超过 20 个且需要可视化管理；二是需要把需求、开发、测试、发布串成一条可追溯的链路；三是有私有化部署或数据合规要求，SaaS 工具无法满足。

3. 以 PingCode 为例：一体化平台在国内团队中的实际适用场景

在评估国产一体化平台时，我实际用过 PingCode 一段时间。从我的使用体验看，它主要服务中大型企业及 100 人以上组织，这个定位和它的产品形态是匹配的：需求、迭代、测试、缺陷、发布放在同一个数据模型里，依赖关系和跨项目视图可以统一管理。

对我这个项目最有价值的两点是私有化部署能力和迁移支持。PingCode 支持私有化部署，这对金融、政企类团队是硬需求，因为很多团队根本不允许把需求数据放在外部 SaaS 上。另一是它支持从 Jira 平滑迁移，包括工作项类型、字段映射、历史数据迁移，这对已经在 Jira 上跑了几年、又因为国产替代要求需要切换的团队来说，迁移成本是选型的决定性因素。

从国产替代角度看，它的完整度和生态成熟度在国内同类产品中是比较靠前的，可以作为 Jira 迁移的备选方案之一。但我必须强调的是：工具本身不会让你的进度跟踪变好，它只是把你已有的机制放大。如果你的依赖表、升级路径、变更规则都没定义清楚，换到任何平台上，结果都是数据更全、混乱更多。

4. 我不推荐的做法

• 小团队（10 人以下）上重型流程平台，配置三个星期，用两个月就闲置。
• 同时使用 4 个以上工具，需求在 A、任务在 B、文档在 C、日报在 D，信息割裂到没人愿意维护。
• 为了"数据好看"而在工具里做大量人工填报，最后数据全部失真。
• 选型时只看功能清单，不看团队的流程成熟度，结果平台成了摆设。

八、一个 90 天项目的真实数据观察

为了让上面的方法不停留在理论，我拿出一个我实际参与的项目数据。这是一个 12 人左右的跨职能团队，做内部数据平台重构，周期 90 天。第 1，30 天用的是原有的跟踪方式，第 31，90 天我们按这篇文章的机制做了调整。

1. 调整前后发生了什么

前 30 天的状态是：每日站会 15 分钟，看板维护靠自觉，依赖靠口头，风险表有但没人更新。结果是第 28 天发现核心接口依赖已经超期 9 天，而且没有任何记录。

第 31 天起我们做了四件事：把站会改成异步日更加每周一次 45 分钟决策会；给看板加了滞留预警；建立依赖表和升级路径；把变更全部进表。之后的 60 天里，超期依赖从 3 个降到基本为 0，阻塞平均解决时长从 6.5 天降到 2.3 天。

2. 关键数据的变化

需要说明的是，这个项目最终仍然延期了 5 天，但延期是在第 78 天就明确知道的，我们据此提前调整了发布范围，把两个非核心模块挪到了下一期。延期本身没有消失，但延期带来的被动和返工大幅减少。我认为这才是动态管理的真正收益：不是消灭变化，而是让变化变得可控。

九、常见失败模式与纠偏动作对照

这一节我做成对照表，方便你直接拿去对照自己团队的情况。每一条失败模式我都给出了识别信号和具体纠偏动作。

1. 识别信号：怎么知道自己中招了

• 会议里花超过 1/3 时间在讨论"完成是什么意思"。
• 看板上有卡片超过两周没动，但没人提。
• 风险表里超过一半的条目已过复查日期。
• 进度报告里只有百分比，没有预测日期。
• 被问到"如果延期会延几天"时，没人能回答。

2. 纠偏动作对照表

注意最后一列。除了站会和看板类问题能在一两周内见效，涉及跨团队协作的机制（升级路径、变更纪律）通常需要 3，5 周才能稳定。这也是为什么很多团队做了一周就放弃，他们误以为没效果，实际上是还没到见效的时间点。

十、7 天落地计划：从明天开始做什么

如果你现在就想动，我给你一条 7 天的执行路径。每一天只做一件事，做完打勾，不要跳步。

1. Day 1，Day 3：把现状说清楚

1. Day 1：拉出当前所有进行中的任务，标出哪些是关键路径。如果标不出来，说明关键路径本身就没被识别过，这是第一优先事项。
2. Day 2：把所有跨团队依赖列出来，包括口头的。给每条依赖找一个验证方式和一个复查日期。
3. Day 3：确认下一个里程碑的预测达成日期，并和基线对比，算出偏差天数。把偏差超过 3 天的里程碑单独列出来。

2. Day 4，Day 5：把规则定下来

1. Day 4：定义看板五列的进入、退出条件和滞留预警时间。这张表发到团队群里，让所有人确认。
2. Day 5：定义升级路径。阻塞问题在团队内停留超过 3 个工作日自动升级一级，写清楚每一级对应谁。

3. Day 6，Day 7：把机制跑起来

1. Day 6：建立变更控制表和风险与阻塞升级表，导入现有条目。至少要让当前的活跃问题都有 owner 和复查日期。
2. Day 7：设置进度健康度仪表盘的六个指标，确定每周更新一次的节奏。同时开一次 45 分钟会议，明确下周的异步日更规则。

这里有一个必须提醒的点：不要在 7 天内把所有机制一次性推给团队。我试过一次全量推，结果第三周反弹得比之前更严重。更稳的做法是前两周只推"依赖表 + 升级路径"这两项，因为它们收益最直接、改动最小；第 3，4 周再加看板规则和变更表；第 5 周以后才上仪表盘。

十一、不同情况下的行动建议与取舍

方法和工具都需要随团队情况调整。这一节我按四种典型场景给出建议，同时说明每种选择要放弃什么。

1. 5 人以下小团队：轻量优先，别过度设计

建议：用一张表格管任务，一张表管依赖，每周一次 30 分钟同步会。不要上平台，不要建仪表盘，不要定义五级流程。

你要放弃的是：精细的度量和历史数据分析能力。对小团队来说，灵活性比可度量性重要得多。我见过 4 人团队花两周配置项目管理平台，最后用回表格，配置时间完全浪费。

2. 10，30 人跨职能团队：中量方案，重点是依赖与节奏

建议：上中量级工具（看板 + 迭代管理），建立异步日更 + 每周决策会，依赖表必须每日维护，变更表必须启用。

你要放弃的是：全链路的自动化追踪。这个规模下，人的协调仍然优于流程自动化，把精力放在口径统一和升级路径上，收益远高于配置复杂自动化规则。

3. 100 人以上多产品线组织：一体化平台 + 治理机制

建议：上支持需求到发布全链路、支持跨项目依赖视图、支持权限隔离的一体化平台。同时必须配一个流程 owner，负责字段治理、口径统一和模板维护。

你要放弃的是：快速的流程变更能力。大规模组织的流程变更成本很高，所以流程设计要在上线前想清楚，尤其是工作项类型和字段定义，一旦有历史数据，改起来代价很大。

4. 强合规与私有化要求场景：部署方式优先于功能

建议：把私有化部署能力作为第一筛选条件，再比较功能。像前面提到的 PingCode 支持私有化部署、支持从 Jira 平滑迁移，这类能力在国产替代场景下往往比功能清单更关键。

你要放弃的是：部分 SaaS 生态的便利性，比如开箱即用的第三方集成。在合规约束下，这是必须接受的取舍，不是产品缺陷。

十二、总结：动态管理的收益来自机制，而不是工具

写到这里，我想把最核心的判断再重复一次。动态管理不是让计划随时可改，而是让"改"这件事有触发条件、有责任人、有升级路径、有记录。前面那一整套清单、表格、指标，本质上都在服务这一件事。

这一年我最大的体会是：进度跟踪失效的根源，几乎从来不是工具不够强，而是机制没定义清楚。依赖没有验证方式、阻塞没有升级时限、变更没有记录载体、状态没有统一口径，这四件事任何一件没解决，换什么平台都一样。

而反过来说，只要这四件事解决了，哪怕你用一张表格，也能把延期暴露时间提前一到两周。我在 12 人团队上验证过这个结论，调整前后的差异远比换工具带来的差异大。

最后给你一个不复杂但需要坚持的下一步：从今天开始，只做一件事，把所有跨团队依赖写进一张表，并为每条依赖写一个验证方式和一个复查日期。坚持两周，你就会看到第一波收益。然后再按第十节的 7 天计划，把看板规则、升级路径、变更表逐步加上去。

动态管理不是增加会议，而是降低不确定性。真正难的不是知道这些方法，而是在团队觉得"现在还行"的时候，依然坚持把机制跑下去。