计划基线最佳实践：产品经理项目规划最佳实践，常见问题

上周三晚上十点，我在一个 100 人规模的 B 端产品团队做季度复盘，会议室白板上还留着两小时前争吵的痕迹。研发负责人说"原计划 9 月 20 日就该封版"，业务方说"你们明明答应过要加对账模块"，项目负责人翻遍了三个群、两个文档库，最后只找到一句"这个先加上，后面再评估"。

没有人撒谎。所有人都记得自己说过什么，但没有人手里有一份"被确认过的原计划"。这就是我这些年见过最多的一类项目失控，不是做不出来，而是做到一半，团队对"当初说好的是什么"已经失去了共识。

这篇文章不讲"什么是计划基线"的教科书定义，那部分内容网上已经足够多。我要讲的是更实用、也更难的一件事：产品经理怎么让计划基线在真实团队里活下来、被使用、被信任，而不是建完之后躺在某个文件夹里发霉。下面所有内容来自我在多个团队做项目复盘和流程改造时的一手观察，包括我们踩过的坑、修过的流程，以及在不同规模团队里做取舍时的判断依据。

一、先给结论：基线要解决的不是"能不能改"，而是"改了还有没有人知道原计划是什么"

如果这篇文章你只读一段，我希望是这一段。

计划基线的本质，不是一份被冻结的计划，而是一份被正式确认、可被追溯、可作为偏差比较依据的计划版本。它存在的意义只有一个：让你在项目跑偏的时候，有一个确定的参照系去回答"我们偏了多少"。

这个定义听起来平淡，但它直接推翻了绝大多数团队的默认理解。很多人把基线当成"军令状"，认为一旦建立就不能动，动了就是失控。结果就是：没人敢建基线，因为建了就等于给自己上枷锁。

1. 我判断一条基线是否有效的三个标准

做了几年流程改造之后，我形成了三个非常朴素的判断标准，可以拿去直接检查任何一个团队。

• 可查询：团队任意一个成员，能否在 5 分钟内找到"当前生效的基线版本"以及"上一版基线是什么"。
• 可追溯：每一个偏离基线的动作，能否对应到一次明确的确认记录，而不是一句群聊里的"行吧"。
• 可度量：团队能否用基线回答"我们现在落后原计划多少"，而不是只能回答"感觉有点赶"。

三个标准里，任何一个不成立，这条基线在管理意义上就等于不存在。它可能是一份漂亮的甘特图，但那和基线没有关系。

2. 为什么这个判断对产品经理尤其重要

在很多团队里，产品经理是需求的源头，也是范围变动的签发人。范围一变，进度、成本、人手全跟着变。但产品经理通常不是排期的执行者，也不直接承担交付压力。

这种角色错位，是基线失效最常见的结构性原因。产品经理觉得"我只是加了个小需求"，研发负责人感受到的是"我的排期又崩了"，业务方看到的是"交付日期又推迟了"。三方都在同一个项目里，却参考着三份不同的"原计划"。

基线就是让这三方重新对齐到同一个坐标系上的工具。在权限和工具层面，基线要同时服务"批变更的人"和"干变更的人"。以 PingCode 这类面向中大型组织的项目管理平台为例，基线、版本、变更申请通常是放在同一套权限模型下的，做需求的人和做评审的人看到的是同一条数据和同一份留痕，这个设计本身就减少了"各说各话"的空间。这也是我为什么一直强调：基线的第一价值是共识，第二价值才是管控。

二、真实场景：我见过的三种"基线死法"

在讲怎么做之前，我想先讲怎么做会死。因为大多数团队不是没建过基线，而是建完之后又放弃了，放弃的理由往往惊人地相似。

1. 死法一：建完即封存，从此没人打开

我参与过一个团队的项目复盘，他们确实建立了基线，文档也在共享盘里，命名规范、版本号齐全。但当我问团队里 8 个人"当前生效的基线是哪个版本"，只有 2 个人答对，其中 1 个是写文档的项目经理。

这种情况下，基线成了一个仪式性的产物。它在上线启动会上被认真讨论过一次，然后就被后来的迭代节奏淹没了。问题的根源在于：基线没有被接入任何日常动作。没有人需要在周会上对照它，没有人需要在变更时引用它，它自然就死了。

2. 死法二：谁都有一版"原计划"

比封存更隐蔽的一种情况是：团队每个人脑子里都有一版原计划，但版本互不相同。产品经理记得的是"6 月底出 MVP"，研发记得的是"6 月底出核心链路"，业务方记得的是"6 月底能用"。

这三个理解在大方向上一致，在细节上完全错位。等到 6 月底交付时，三方拿着各自的版本互相指责，而实际上谁也拿不出真正的依据。没有统一基线的时候，争吵的成本会以指数方式上升，因为每一次争论都要从"当初说的是什么"重新开始。

3. 死法三：变更是靠"当天谁在群里说话"决定的

这是最普遍的一种。需求变更没有固定入口，谁在群里喊得响、谁跟产品经理关系近、谁在周会上抢到发言机会，变更就更容易通过。

这种机制看起来灵活，实际成本极高。它把本该由流程承担的一致性判断，变成了由个人影响力决定的随机结果。长期下来，团队会形成一种隐性认知：走流程不如找对人。一旦这个认知形成，任何流程都会被绕过。

三、拆解误区：关于计划基线的六个高频错误认知

下面这六条，是我在沟通中听到频率最高的错误表述。每一条我都标注了为什么它是错的，以及正确的理解应该是什么。

1. 误区一：基线就是甘特图截图

甘特图是排期的一种可视化形式，基线是某个时间点上被确认的计划内容。一个是视图，一个是版本。

两者最大的差别在于可追溯性。截图无法承载"这一版和上一版差了什么"，也无法承载"谁在什么时候批准了这次调整"。而基线恰恰要靠这两个信息才能发挥作用。

2. 误区二：基线等于里程碑清单

里程碑是计划中的关键节点，通常是基线的一部分，但远不是全部。一个完整基线至少还要回答：范围边界在哪里、交付物是什么、关键依赖有哪些、验收标准是什么。

只把里程碑当作基线的团队，往往会出现"日期没变但内容变了"的情况。里程碑按时打勾，交付物却缩水了一半，这种偏差因为不在基线范围内，反而最难被发现。

3. 误区三：基线定了就不能改

这是我最想纠正的一条。基线的意义不是不许改，而是改了要留痕、要有人批、要有记录可查。

一个从来不变更的基线，只可能出现在两种情况下：要么项目极其简单，要么团队根本没有认真对待它。真实的项目一定会变，问题不在于变不变，而在于变动是否有秩序。

4. 误区四：用了工具就自动有基线了

工具能帮你存档、能帮你比对、能帮你留痕，但工具不会替你决定"哪些内容该进基线""谁来批准这次变更"。

我见过团队把所有需求都设成基线，结果基线每周变动几十次，等于没有基线；也见过团队把基线功能开在那里整整一年没用过一次。工具解决的是记录效率问题，流程和权责解决的是判断问题，两者不能互相替代。

5. 误区五：三基线必须齐全

范围基线、进度基线、成本基线这三类说法流传很广，但它们并不是所有团队都必须同时具备的。质量基线、资源基线是否纳入，更是取决于组织本身的成熟度和行业属性。

对一个 30 人的产品团队谈成本基线，往往意义不大，因为他们的人力和预算基本由上级统一调配，没有独立核算的必要。基线层级应该跟着管理需要走，而不是跟着术语表走。

6. 误区六：基线是项目经理的事，跟产品经理无关

这条误区背后是角色认知的偏差。项目经理负责基线的维护和追踪，但产品经理是范围的主要决定者，范围变了基线必然要跟着调整。

我认为更接近事实的表述是：产品经理守范围边界与优先级，项目负责人守流程和节奏，研发负责人守实现路径与依赖约束。三者缺一，基线都无法长期维持。

四、专业判断逻辑：什么该进基线，什么不该进

我在团队里被问得最多的一个问题是："这么多需求，难道都要进基线吗？"这个问题问得非常好，因为它触及了基线最容易被滥用的地方。

1. 三个判断维度

我通常用三个维度来快速判断一个条目是否值得进基线。

• 对外承诺性：这个条目是否已经对外承诺，或者会影响到对外承诺的兑现？
• 变更成本：一旦它发生变化，会不会引发连锁调整（返工、加人、延期）？
• 验证需求：是否需要一个明确的参照点来判断它有没有被达成？

三个维度中有两个及以上答案是"是"，我倾向于把它放进基线；只有一个或零个，通常放在迭代计划里跟踪就够了。

2. 进基线的四条准入标准

把上面的判断具体化，我总结成四条可以直接对照的标准。

1. 该条目已被相关方正式确认，而非单方面拟定；
2. 该条目对应明确的交付物或验收口径；
3. 该条目的变化会影响到至少两个角色的工作安排；
4. 该条目需要一个版本化的记录点用于后续比对。

这四条同时满足，进基线；只满足前两条，放在里程碑里跟踪；都不满足，就是个待办事项。

3. 可裁剪的基线层级：标准版与轻量版

标准做法通常包括范围、进度、成本三类基线，质量和资源视组织而定。但对没有专职项目管理的团队来说，全套照搬的结果往往是什么都做一点、什么都做不到位。

我更推荐的是一种可裁剪的轻量方案：只对范围边界和关键里程碑设基线，进度明细只做滚动跟踪，不进基线。这样做的代价是失去了细粒度的偏差对比能力，收益是维护成本下降一个数量级。

需要说明的是，这是一种经验性取舍，不是行业标准。选哪种，取决于团队能不能承受维护成本，而不是取决于哪种听起来更专业。

4. 角色权责：谁批、谁看、谁改

基线失效的一个重要原因，是没人说得清自己在基线上的动作是什么。下面这张表是我在多个团队推行过的版本，可以直接参考。

五、五步建立一条能活下来的基线

下面流程的每一步，我都给出了"最小动作"和"常见做错的地方"两面。这是我反复调整后认为最能落地的版本，而不是理论上的标准流程。

1. 第一步：划定基线边界，明确"哪些进、哪些不进"

这一步最容易被跳过，但它决定了后面所有工作是否有意义。建议在规划会前就准备好两份清单：一份是纳入基线的内容，另一份是明确不纳入的内容。

最小动作：输出一页纸，左边写"本期承诺"，右边写"本期明确不做"，两边都要有具体条目。

常见做错的地方：只写"要做什么"，不写"不做什么"。后者其实是更重要的边界，因为它能在后续需求涌入时提供拒绝的依据。

2. 第二步：开一场真正的基线确认会

确认会不是宣讲会。宣讲是单向的，确认是双向的，两者的效果差别很大。确认会的目的不是让所有人知道你要做什么，而是让所有人对"做什么、做到什么程度、什么时候交"形成一致表述。

最小动作：让每个相关方在会后复述一遍自己理解的承诺内容，说不一致的地方当场澄清。

常见做错的地方：会议开到一半开始讨论实现细节，把确认会开成了技术评审会，结果时间用完了，基线反而没确认。

3. 第三步：版本化存档，让"原计划"随时可查

存档的关键不在存，而在可查。命名规范要能让任何人一眼看出这是第几版、什么时候生效、和上一版差在哪。

我用过的一套命名规则是这样的，团队反馈上手很快：

项目代号-基线类型-版本号-生效日期
示例：CRM-PLAN-BL-v2.1-20260915

配套原则：

1. 同一时间只能有一个"当前生效版本"
2. 历史版本只读，不允许直接编辑
3. 每次更新必须填写变更摘要，一句话说明改了什么

最小动作：在当前生效版本上打标记，历史版本设为只读。

常见做错的地方：把基线存在个人电脑或私人云盘里，团队其他人找不到入口。

4. 第四步：同步约束而非同步文档

把基线文档链接发到群里，效果几乎为零。真正有效的是同步"约束"，也就是告诉每个人，哪些事情因为这条基线变得不允许了。

比如："本期基线已确认不含 XX 功能，如果后续要加，需要走变更流程并可能影响 9 月 20 日的封版节点。"这句话比发一个文档链接有用得多，因为它直接指向了行为和后果。

最小动作：在同步消息里写清楚"本期不做什么"以及"要加的代价是什么"。

常见做错的地方：只同步结论不同步边界，导致团队以为"没提就是可以做"。

5. 第五步：设偏差观察点

基线建立后如果没有任何观察动作，它在两周内就会变成历史文件。观察点要回答三个问题：多久看一次、看什么、出现什么情况要触发动作。

• 多久看一次：双周迭代团队建议每次迭代回顾时看一次，月更团队建议每月至少一次。
• 看什么：范围偏离项数、关键里程碑实际进度与基线的差值、未走流程的变更数量。
• 触发动作：建议提前约定一个偏差阈值，超过阈值自动进入变更评估流程，而不是靠感觉判断。

六、核心难点：变更控制怎么做得既严格又不拖累团队

基线建立只是开始，真正的挑战全部发生在基线之后。我甚至认为，没有变更控制的基线，本质上只是归档文件。这一节是我认为全篇最重要的部分。

1. 先分级，再决定走不走流程

很多团队变更控制做不起来，原因不是不想做，而是所有变更都用同一套重量级流程，导致小事也要等三天，团队自然开始绕过它。

我推荐的解法是分级。判断维度我用四个：是否影响对外承诺日期、是否改变范围边界、是否影响人力或成本投入、是否影响外部依赖方。

分级之后一个反直觉的现象会出现：变更申请的总量会上升，但平均处理时长会明显下降。原因是以前大量变更根本没被记录，现在被记录进来了，看起来"变更变多了"，实际上大部分是 L1，当天就能关闭。

2. 变更申请的最小要素

流程能不能跑起来，很大程度取决于申请表单有多重。我见过的最失败的版本是 20 多个字段，结果没人愿意填。经过几轮精简，我目前认为这五个要素是必须保留的：

变更申请最小模板

改什么：一句话描述本次调整的内容
为什么：不做的后果是什么，做了能解决什么问题
影响谁：涉及哪些角色、哪些外部依赖方
代价是什么：工期、人力、成本的增量估算
替代方案：如果不做这个变更，有没有别的解法
填写原则：以上五项合计控制在 300 字以内

超过 300 字通常意味着变更本身需要重新拆分

这四个要素的排序本身就是判断依据。如果"为什么"这一栏写不出具体后果，说明这个变更大概率是可有可无的；如果"替代方案"栏是空的，说明提出者还没有认真想过影响范围。

3. 变更通过后的三件事

很多人以为变更批准就结束了，实际上批准只是开始。后续必须做完三件事，否则这次变更等于白走流程。

1. 更新基线版本：不是修改原文件，而是生成新版本并标记生效日期，历史版本只读保留。
2. 同步受影响方：范围包括直接执行者、下游依赖方、以及对外的接口人，缺一不可。
3. 回溯偏差记录：把这次变更导致的时间或范围偏差记录下来，作为后续估算准确性的输入。

第三件事最容易被忽略，但它的长期价值最高。连续记录半年之后，你会得到一份非常宝贵的资料：你们团队在估算上到底偏向乐观还是保守，偏差平均有多大。这个数据可以反过来显著改善后续规划的准确性。

4. 没有 CCB 怎么办：轻量替代方案

变更控制委员会（CCB）在成熟组织里是标准配置，但对大多数中小团队来说并不现实。我实践过的一套替代方案是这样的，供参考：

• L1 变更：产品负责人单人确认，在变更记录表中留一行记录即可。
• L2 变更：产品负责人与研发负责人双人确认，其中任何一人有疑问就升级。
• L3 及以上：在每周固定的例会上追认，由在场的相关方共同确认，不单独组织会议。

这套方案的核心是把审批嵌入已有的会议节奏，而不是额外创造新的会议。额外增加的会议会被优先砍掉，嵌入现有节奏的动作才可能长期存活。需要强调的是，这属于适配中小团队的经验做法，不是通用标准，组织规模不同做法差异很大。

5. 工具层怎么承接：以 PingCode 为例

流程设计完之后，一个绕不开的问题是：这些动作放在哪里执行。如果流程在文档里、执行在聊天工具里，中间必然出现断层。

在 100 人以上组织里，这个问题会更复杂。跨团队协作、多项目并行、权限分层、审计留痕这些需求，靠文档加表格很难兼顾。这也是为什么中大型组织通常需要专门的项目管理平台来承接基线管理。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在基线场景下有几个能力值得关注。

第一是需求与版本的关联。基线的本质是"某个时间点的范围与排期快照"，如果需求条目本身就在系统里，那基线就可以通过版本快照的方式生成，而不需要人工整理一份独立文档。人工整理的问题在于，一旦需求发生变动，文档和系统数据就会不一致，而团队通常不知道哪边是准的。

第二是变更流程与权限模型的结合。我在前面提到，L1 到 L4 分级需要不同的审批路径。如果平台支持按变更等级配置不同的审批流，那分级制度就能落地；如果不支持，团队就只能退回到"所有人走同一条流程"，分级就形同虚设。

第三是私有化部署与数据自主。这一点对金融、制造、政企类客户尤其重要。基线数据包含产品规划、交付节奏、人力投入等敏感信息，很多组织在合规要求下不能放在公有云上。PingCode 支持私有化部署，这在这类场景里是硬性前提，而不是加分项。

第四是迁移成本。很多团队过去用的是 Jira，历史数据里有大量已建立的版本和基线信息。如果迁移过程中这些数据丢失或结构错乱，过去几年积累的偏差记录就断了。PingCode 支持 Jira 平滑迁移，对于考虑国产替代的团队来说，这能显著降低切换时的数据损失风险。

需要说清楚的是，工具解决的是记录和执行的效率问题。"哪些进基线""由谁批准"这类判断，工具永远不会替你做。先想清楚流程，再选工具，这个顺序反了，再好的工具也只会变成一个更昂贵的文件夹。

6. 偏差阈值怎么定：一个需要算账的取舍

变更触发阈值是很多团队纠结的点。定得太低，变更申请满天飞，管理成本高；定得太高，偏差累积到无法挽回才被发现。

我倾向于把它当成一道算账题：阈值放宽一档，能省下多少次变更处理，但同时会增加多少返工成本？

从这组模拟数据可以看出，总成本的最低点通常出现在中间位置。我的一般建议是：先设一个中间值跑三个月，用真实的返工数据去校准，而不是一开始就追求最优解。这个参数只有跑过才知道，纯靠讨论很难得出可靠结论。

七、八个常见问题快答

这一节对应大多数人在搜索时最想直接得到答案的问题，每题控制在短篇幅内，末尾给一句可以直接拿去用的结论。

1. 基线建立后，需求还能改吗？

能改，但必须留下记录并明确代价。改本身不可怕，可怕的是改了之后没人知道原计划变了、也没人知道代价是什么。真正需要禁止的不是变更，而是无记录的变更。

一句话结论：能改，但每次改动都要能回答"改了什么、为什么、代价是什么"。

2. 基线建完之后没人看怎么办？

没人看通常不是态度问题，而是动作问题。如果没有任何一个日常动作要求你打开基线，它就会被遗忘。解法是把它嵌进已有节奏，比如放进迭代回顾的第一个议题，或者在每次变更申请时强制引用基线版本号。

一句话结论：把基线接进一个已有的会议或流程，而不是指望大家主动去看。

3. 进度落后多少算需要触发变更？

不建议用统一百分比一刀切。更可靠的做法是看关键路径上的偏差：如果关键路径上的任务普遍延后，即使整体进度看起来只落后 5%，也应该触发评估；如果落后集中在非关键路径，落后 15% 也可能不影响交付。

一句话结论：看关键路径的偏差，不看整体百分比。

4. 基线要不要对业务方公开？

我认为要，但公开的内容要有选择。业务方需要知道的是范围边界和对外承诺节点，不需要知道每个任务的具体排期。全都公开会带来不必要的干预，全都不公开会让业务方失去预期管理的能力。

一句话结论：公开范围边界与关键节点，细节不必公开。

5. 多个项目并行时，基线怎么管？

关键在于区分项目级基线和资源级基线。项目级基线各自独立维护，但共享资源的投入比例需要单独设一条基线，否则会出现多个项目都按"全员投入"排期，实际根本不可能实现。

一句话结论：项目基线分开管，共享资源单独设一条基线。

6. 没有专职项目经理，谁来做？

通常是产品负责人或研发负责人兼任。重要的是明确责任，而不是纠结头衔。但我要提醒一点：兼任者不能同时拥有"发起变更"和"批准变更"两个权限，否则变更控制就失去意义。

一句话结论：可以兼任，但发起权和批准权必须分离。

7. 用了工具就自动有基线了吗？

没有。工具提供的是存档和比对能力，基线的内容范围、责任归属、变更规则仍然需要人来定义。我见过开了基线功能却从未使用过的团队，也见过把基线划得过细、每周变更几十次的团队，两者的问题都不在工具。

一句话结论：工具负责记录，流程负责判断，两者不能互相替代。

8. 项目中途换负责人，基线怎么交接？

交接清单里必须包含三样东西：当前生效的基线版本、全部历史变更记录、以及所有未关闭的偏差项。只交接当前状态而不交接偏差历史，新负责人会重复踩一遍前人已经踩过的坑。

一句话结论：交接的不只是当前版本，更要交接偏差历史。

八、自检：你的基线是"活的"还是"死的"

下面这份清单可以直接拿去对照自己的项目。我建议每季度做一次，逐项打勾。

1. 团队任意成员能在 5 分钟内找到当前生效的基线版本；
2. 历史版本全部只读保留，且能看到每一版的变更摘要；
3. 存在明确的变更记录入口，且最近一个月有实际使用记录；
4. 团队能说出至少一个最近被拒绝的变更及其理由；
5. 最近一次迭代回顾中，讨论过实际进度与基线的偏差；
6. 基线责任人明确到具体的人，而不是"项目组"；
7. 对外承诺的关键节点在基线中有明确记录；
8. 有一份明确列出"本期不做"的清单。

八项里打勾少于四项，说明你的基线大概率已经处于"名存实亡"的状态；打勾五到六项，属于基本可用但仍有明显漏洞；七项以上，说明这条基线是活的，能真正承担偏差度量的作用。

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

没有一种基线做法适合所有团队。下面按三个常见维度给出我的建议，同时把取舍讲清楚。

1. 按团队规模分

50 人以下团队：建议只建范围基线加关键里程碑，不建成本基线。这个阶段的核心矛盾是快速验证方向，重流程会拖慢节奏。取舍是牺牲细粒度偏差度量，换来灵活性。

50 到 200 人团队：建议建范围基线和进度基线，成本基线视核算需要。这个阶段开始出现跨团队协作，基线的主要作用从"内部对齐"转向"跨团队共识"。

200 人以上团队：建议三类基线齐备，并视行业属性补充质量或资源基线。到这个规模，管理成本已经被规模摊薄，不建基线的代价反而更高。这也是 PingCode 这类面向中大型组织的平台价值最明显的区间，私有化部署能力、权限分层、跨项目视图，在小团队里是冗余，在这个规模是刚需。

2. 按项目类型分

To B 定制交付类项目：范围基线的优先级最高，因为验收标准直接决定回款。建议把验收口径写进基线，而不是只在合同里体现。

自研产品类项目：进度基线的弹性可以大一些，范围基线的约束要更紧。这类项目最大的风险不是延期，而是方向频繁调整导致资源分散。

内部系统类项目：可以只建范围基线和里程碑，不必追求完整的偏差度量。使用方就是内部同事，沟通成本远低于外部客户。

3. 按交付节奏分

双周迭代：基线建议按季度或大版本设置，不要按迭代设。每个迭代都设基线，维护成本会高到无法承受。

月度或季度交付：可以在每次交付前设一条基线，颗粒度适中，维护成本可控。

持续交付：建议采用"发布列车"模式，即在固定的发布节奏上设置基线，而不是按功能批次设置。

4. 取舍清单：什么必须坚持，什么可以放弃

资源有限的时候，你需要知道哪些可以砍。下面是我认为不能妥协和可以妥协的部分。

结尾：从下一次规划会开始

写到这里，我想把整篇文章浓缩成一个我认为最反直觉、也最重要的判断：计划基线的价值不在于它有多完整，而在于它有没有被持续使用。一条粗糙但每天被打开三次的基线，价值远高于一份精美但没人记得的火柴盒。

如果你认同这个判断，那么下一步不需要做什么大改革，只需要三件事：

1. 指定一个基线责任人。明确到具体的人，写进项目文档，不需要是专职岗位。
2. 建一个变更记录入口。哪怕是一张共享表格，只要所有人知道往哪里写，就已经解决了六成问题。
3. 约定一次偏差回顾节奏。放在已有的周会或迭代回顾里，不额外加会。

这三件事做完，你就已经有了一条"活着的"基线。剩下的颗粒度、审批层级、工具选型，都可以在跑起来之后根据真实数据逐步调整。

最后提醒一句：不要试图一步到位。我见过太多团队在第一周就设计出完美的基线流程，然后在第三周彻底放弃。能长期活下来的机制，几乎都是从一个最小动作开始的。