预算分配最佳实践：项目经理预算管理流程优化，常见问题

项目预算超支，往往不是因为团队“花得太快”，而是因为预算在立项时被一次性切成几个大筐，之后没有人持续判断每笔支出是否仍对应当前优先级。我做预算复盘时，最常看到的反常识情况是：项目总额没有超，关键里程碑却缺钱；某些科目还剩不少，团队却不得不临时申请追加。预算管理的重点不是把钱分得更细，而是建立一套能随范围、风险和进度变化而调整的分配流程。

一、先讲核心结论：预算管理是持续决策，不是一次性切账

1. 预算要回答三个不同的问题

项目经理做预算时，通常把“总共能花多少钱”“钱要花在哪里”“什么时候可以花”放在同一张表里处理。结果是总额看起来完整，执行时却无法回答哪些支出已经承诺、哪些还只是估算、哪些可以暂停。

我建议把预算拆成三个判断层：总额控制回答项目最多能承受多少成本；分配结构回答资金对应哪些交付成果和成本驱动因素；释放节奏回答在什么条件满足后，团队可以动用下一阶段资金。三者缺一不可。

预算分配的核心不是把每一分钱提前锁死，而是把不可逆的承诺控制住，把可调整的资金留给仍有不确定性的部分。这也是为什么成熟的预算流程通常会同时设定基准预算、已承诺金额、已发生金额、预测完工成本和应急储备。

2. 一张预算表至少要有四种金额口径

在项目管理中，“预算剩余”很容易被误读。比如预算总额为 500 万元，账面已支付 180 万元，看起来还剩 320 万元；但如果已经签署合同、承诺付款 210 万元，真正可以重新分配的资金就远少于 320 万元。

例如，批准预算为 500 万元，已发生 180 万元，已承诺但尚未支付 210 万元，剩余工作预计还需 130 万元，那么完工预测是 520 万元，而不是“还剩 320 万元”。预算表若不区分这些口径，管理者看到的余额就会制造安全感。

3. 最值得管理的不是预算消耗率，而是预测偏差

预算消耗率只能说明钱花了多少，不能单独说明项目是否健康。一个项目消耗了 60% 的预算，若只完成 35% 的范围，风险可能已经很高；另一个项目消耗了 70%，但已完成 85% 的关键交付，反而可能在可控范围内。

我会把预算审查从“本月花了多少”转向“当前完工预测与批准基准差多少、差异由什么引起、是否需要改变决策”。这会把财务数字连接到项目执行，而不是让预算表成为月末归档文件。

二、背景和真实场景：为什么“预算还有余额”仍然可能缺钱

1. 预算失控常常始于立项时的口径不一致

我在复盘项目预算时，会先问一个看似基础的问题：这份预算覆盖到哪里？有的团队把供应商实施费算进项目成本，却把内部人员工时排除在外；有的团队把税费、差旅、培训和上线支持放在部门运营费用中；还有的团队只列采购金额，没有列续费和维护成本。

这些做法在各自的财务口径中未必错误，问题在于项目内部没有统一说明。团队以为总预算是完整的，财务则认为部分费用属于其他科目，到了采购或验收时才发现项目资金不足。

因此，立项预算至少应写清成本边界、统计周期、币种与税务口径、内部资源是否计价、一次性费用与持续性费用如何区分。若有多个部门共同承担成本，还要明确谁负责付款、谁拥有预算调整权。

2. 固定预算与不确定范围之间存在天然张力

软件建设、产品研发、组织变革和系统集成项目都可能在执行过程中发现新需求。问题不在于需求变化本身，而在于预算流程假设范围不会变化，却又没有为变化设计决策机制。

如果一开始把预算全部分配到具体任务，新增高价值需求只能靠追加资金；如果把大量金额都放在“预备费”里，业务负责人又会担心资金没有明确用途，审批时难以解释。更稳妥的方式是将预算分为确定性较高的基础交付、受条件约束的阶段资金和受治理规则控制的应急储备。

储备不是“没人负责的钱”，而是对应特定风险、触发条件和审批权限的资金。例如，数据迁移复杂度只有完成样本验证后才能确认，就可以把相关资金设为阶段性释放，而不是在立项时假装已经得到精确报价。

3. 中大型组织还要解决跨团队预算的可见性

对于 100 人以上的组织，项目成本往往散落在多个团队：研发人员工时记录在资源计划中，采购费用记录在财务系统里，外部服务费用留在合同台账，项目经理手中的表格则只记录汇总金额。每份记录可能都正确，但如果无法按项目、工作包和时间范围关联，就很难形成可用的预测。

以 PingCode 这类主要服务中大型企业和 100 人以上组织的项目管理平台为例，讨论重点不应只是“能不能把预算数字录进去”，而应是项目、迭代、工作项、负责人和状态能否形成可追踪的执行链路。预算数据通常仍需与财务、采购或工时系统核对，项目管理平台可以帮助管理工作过程，但不能替代正式财务账簿。

选工具时，我会检查三个问题：预算相关的工作是否能关联到交付项；变更记录是否保留申请人、理由、影响和审批结果；团队是否能按角色查看适当的项目状态。若这些链路缺失，工具再多也只会增加重复录入。

4. 预算审查要看时间维度，而不只是项目总额

年度预算可能充足，但资金到账时间、合同付款节点和项目采购周期并不总是一致。项目在第一季度需要支付设备预付款，年度预算却要到第二季度才完成审批；或者人员费用按月发生，项目预算却在阶段验收后才释放。这些都属于现金流和授权节奏的问题，不一定是项目总额不足。

因此，预算计划应同时画出成本发生时间和批准资金可用时间。项目经理若只盯总额，可能无法及时发现资金到位节奏会拖慢采购、测试或上线。

三、常见误区：看似精细的预算，为什么反而更难管

1. 误区一：预算越细，控制就越强

把预算拆到每个任务、每周甚至每个人，表面上很精确，但项目范围尚未稳定时，这种精度通常是假精度。团队会不断修改小数，管理时间被消耗在维护表格上，真正影响成本的假设却没有被验证。

我判断预算颗粒度是否合适，会看它能否改变决策。如果拆分到某个细项后，负责人可以据此选择供应商、调整范围或安排资源，那么拆分有价值；如果拆分结果无法触发任何行动，只是为了让表格看起来精细，就应合并。

预算应采用分层颗粒度：在立项阶段按工作包、成本类别和阶段估算；在近期执行阶段细化到采购项、人员配置或具体任务；远期部分保留区间，等信息成熟后再滚动细化。

2. 误区二：只看实际支出，不看承诺和预测

采购合同签了但发票未到、顾问已开始工作但阶段款尚未支付、云服务按季度结算但资源已持续消耗，这些成本都可能暂时没有出现在“已支付”列里。若团队仅按现金支出管理，就容易把钱重复分配。

预算审查至少应区分已发生、已承诺和未承诺的预计成本。采购、合同、人力安排和财务实际数要按固定周期对账，避免项目经理、采购负责人和财务人员对“还剩多少钱”给出不同答案。

3. 误区三：把应急储备当成随时可用的机动资金

应急储备若没有触发条件，就会变成隐藏预算。团队在初期把不确定性放进储备，执行中又把普通需求变化当成紧急情况，最后储备被日常消耗，真正遇到风险时反而没有缓冲。

我通常把风险储备与管理储备分开讨论。前者对应已经识别、可以估算的风险，例如接口改造量可能超出预期；后者对应当前难以具体识别、但项目治理层认可需要承担的整体不确定性。具体名称和会计口径应服从组织政策，但用途、额度、批准人和释放规则必须清楚。

4. 误区四：把预算差异归咎于执行团队“不够节省”

如果预算超支来自需求增长、技术路线变更、供应商报价变化或初始估算漏项，只要求团队压成本并不能解决根因。过度压缩测试、培训和上线支持，可能把成本转移到返工、故障和后续维护中。

偏差分析应先判断差异属于价格、数量、范围、效率还是时间因素。比如单价上涨和采购数量增加需要不同处理；由于返工导致的人天增加，也不应被简单归类为“团队效率低”。

5. 误区五：项目总额不变就不需要预算变更

同一项目从测试费用转移到外部实施费用，虽然总额没变，但可能影响部门授权、合同审批和验收责任。不同成本类别的权限和风险并不相同，跨科目挪用可能造成财务合规问题。

我会把预算变更分成总额变化、成本类别重分配、时间周期调整和范围变更四类。总额没有变化，不代表管理影响为零；尤其是涉及采购合同、资本化判断或跨部门分摊时，应按组织制度审批。

6. 误区六：预算系统上线后，数据自然会变得准确

工具可以减少重复整理、提醒节点、连接工作项与责任人，却不能自动修正错误的预算定义。若项目编码不统一、合同台账无人维护、工时填报口径不一致，系统只会更快地汇总出一份看似完整但不可比较的数据。

开始自动化之前，应先明确哪些数据是源系统权威数据，哪些字段由项目经理维护，哪些变更需要审批。流程和口径稳定后再集成，通常比一开始就追求全量打通更可靠。

四、专业判断逻辑：把预算分配做成一条可回看的决策链

1. 先定义预算边界，再开始分配

预算估算的第一步不是填数字，而是写清项目范围和成本边界。至少要确认交付成果、排除项、成本周期、内部资源计价方式、税费口径、采购范围以及项目结束后的持续运营费用如何处理。

若项目预算覆盖建设阶段但不覆盖维护阶段，就应该在立项材料中明确标注，而不是等上线后才讨论维护资金。对于系统项目，许可证、云资源、实施、迁移、培训、运维和升级可能处于不同成本周期，合并成一个“软件费用”会遮住长期成本。

2. 从交付成果倒推成本，而不是从部门额度正向切分

比较可靠的做法是先列出项目交付成果和工作包，再判断每项成果需要哪些人员、采购和外部服务。预算因此能回答“这笔钱买到了什么”，也更容易在需求变化时判断资金应转向哪里。

如果组织给项目设定了固定额度，也应把额度作为约束条件，而不是直接按比例分给各部门。团队可以先估算达成目标所需成本，再识别预算缺口，并通过范围分层、阶段交付或方案替代来解决。

3. 用区间和假设表达不确定性

立项早期的信息通常不足以支撑单点精确估算。与其给出 237.6 万元并让小数制造确定感，不如说明基准情景、低位情景和高位情景，并写清差异由哪些变量造成，例如供应商报价、迁移数据质量、内部人员可用度或审批等待时间。

区间估算并非逃避责任。相反，它把不确定性摆到桌面上，便于决策者选择：是先花钱做验证、接受较高风险，还是缩小首期范围。随着报价、原型测试或试点结果出现，区间再逐步收敛。

4. 将预算与风险登记册连接

每项需要储备的风险资金，都应关联一个风险描述、发生概率或影响判断、触发信号、责任人和应对方案。风险资金不能只写“预留 10%”，而应说明这部分资金具体用来应对什么。

对于影响重大但无法可靠估价的风险，可以先安排验证性工作。例如先做接口样本测试，再决定是否启动完整迁移。小额验证可能减少后续大额误判，这属于预算优化，而不是额外浪费。

5. 分阶段释放资金，把可逆决策留到信息更充分时

可以把预算分成基础交付资金、阶段评审后释放资金和受控储备。基础部分用于启动项目所需的确定性工作；阶段资金在成果、质量或采购条件满足后释放；储备则由指定治理角色按规则批准。

分阶段释放不是把项目切成繁琐审批，而是让资金授权与不确定性匹配。若某个工作包的主要成本会在试点结果出来后才确定，就不必在试点前把全额不可撤销地承诺出去。

6. 用完工预测和偏差解释驱动纠偏

预算状态报告不能只给出红黄绿灯。每次预算评审应解释当前已发生、已承诺、剩余工作预计成本和最终完工预测，并说明预测变化的原因、影响范围和建议行动。

简单项目可以使用滚动预测：按月更新剩余工作成本和已承诺成本。复杂项目若具备可靠的范围完成度和成本数据，可采用挣值管理的相关指标辅助分析，但不能为了套公式而制造虚假的进度精度。

• 预算偏差：实际成本与批准基准之间的差异，适合定位已经发生的偏离。
• 完工估算：当前实际成本加上剩余工作预计成本，适合预判项目最终成本。
• 成本绩效：将挣值与实际成本结合，适用于范围和进度口径较稳定、数据质量足够的项目。
• 承诺余额：批准预算扣除已发生和已承诺金额，适合判断真正可重新安排的空间。

7. 预算变更要记录“为什么”，而不只是“改了多少”

一条可用的变更记录至少应包含变更原因、相关工作包、成本差异、对范围与时间的影响、资金来源、风险变化、审批人和生效日期。这样到季度复盘时，团队才能判断偏差源于估算质量、需求治理还是供应商管理。

如果只保存修改后的数字，下一任项目经理看到的只是结果，看不到决策条件。预算管理的组织学习，主要就来自这些理由和后续结果之间的对照。

五、案例与数据观察：一个 500 万元项目怎样避免“余额幻觉”

1. 案例背景与说明口径

下面是一个情景模拟案例，用于演示预算判断方法，不代表某个企业的真实财务数据或行业平均值。项目总预算为 500 万元，周期 9 个月，目标是完成一套业务流程平台的首期上线，涉及内部研发、外部实施、数据迁移、测试和培训。

项目启动两个月后，账面实际支出为 145 万元，采购合同及人员安排形成 170 万元承诺，未承诺工作包预计还需 210 万元。按当前口径，完工预测为 525 万元，较批准基准高 25 万元。若只看已支付金额，会误以为预算还非常宽裕。

进一步拆解发现，偏差并不是单一原因：数据清理工作量高于估算、一个关键接口需要额外适配、部分需求从首期范围外移入。团队如果把 25 万元直接归咎于执行效率，就会错过更有效的处理方法。

2. 先把偏差拆成可行动的原因

我会将预测差异按原因分类，而不是只按部门分摊。案例中的成本偏差暂分为数据迁移 12 万元、接口适配 8 万元、需求范围增加 10 万元、计划节省 5 万元，净增 25 万元。这里的数值是模拟拆解，重点在于展示“毛增量”和“可抵减项”都应透明呈现。

接下来需要分别判断：数据迁移是因为样本验证不足，还是数据质量实际恶化；接口适配是否属于项目原始范围；新增需求是否具备首期必要性；计划节省是否已经验证，还是仅停留在乐观假设。

3. 先保护目标，再决定哪里缩减

这个案例中，团队没有简单按比例削减所有科目，而是把范围分为上线必需、可分阶段和可取消三档。上线必需项包括关键流程、权限控制、核心数据迁移和验收测试；可分阶段项包括低频报表与部分自动化；可取消项则是对首期业务价值有限的个性化界面调整。

经过评估，团队把新增需求中 6 万元移至后续阶段，数据迁移采用分批策略，暂时释放 7 万元资金；接口改造经过样本验证后确认仍需 8 万元。最终预测调整为 512 万元，仍高于原预算 12 万元，但风险和原因已经清楚，项目发起人可以决定追加资金、延后非关键范围，或接受一定的上线时间变化。

这比为了“压回 500 万元”而砍掉全部测试和培训更可取。总额是否超出目标是决策问题，不是遮盖质量风险的理由。项目经理应提供可比较的选项及其影响，让有授权的人作取舍。

4. 案例观察：预测更新比月底纠偏更有用

在情景推演中，项目若按月只看已支付成本，预算风险往往要到合同付款或验收节点才显现；按周维护重大采购承诺、按月更新完工预测，通常可以更早发现资金缺口。这里不把提前发现的具体天数当作普遍统计，因为合同周期、项目频率和审批机制差异很大。

更值得跟踪的是预测质量：每月记录当月完工预测、最终实际成本和差异原因，连续几个项目后就能看出组织是否总是低估数据迁移、外部集成或跨部门协调成本。这样的历史误差，比引用一个脱离企业情境的“标准预备金比例”更有决策价值。

5. 数据观察要回到组织自己的历史记录

如果要用数据改进下一次预算，我建议至少保留项目类型、批准预算、完工预测版本、实际成本、承诺成本、范围变更次数、主要风险和最终结果。不要只保存最终总额，否则无法解释估算误差从何而来。

当样本逐渐积累后，可以按相似项目类别比较估算偏差，而不是把小型流程优化、企业级系统建设和硬件采购混为一谈。样本量有限时，要明确说明这是内部观察，不要把少数项目得出的比例包装成行业基准。

六、不同情况下的行动建议：按项目成熟度选择管理强度

1. 小型、短周期、范围稳定的项目

这类项目不需要复杂的预算治理委员会。项目经理可以用一张轻量表追踪批准预算、实际成本、已承诺金额、剩余估算和变更记录，并在关键采购或范围变更时更新预测。

审查频率可以与项目节奏一致，例如每两周或每月一次。重点是保证数字口径一致，并对预算偏差设置明确的升级阈值。没有明显不确定性的项目，不必为了形式把每项资金都拆成储备、阶段资金和多个审批层级。

2. 范围持续探索的研发或产品项目

研发和探索型项目的难点是价值与范围会随验证结果变化。此时不宜把全部经费绑定到一份过度固定的任务清单，可以按阶段定义要验证的假设、预期成果和资金上限。

每个阶段结束时，根据用户反馈、技术验证和产品目标决定继续、调整或停止。若某项实验失败但快速排除了高风险路线，预算不一定白花；判断标准应是它是否降低了后续决策的不确定性，而不是是否直接产出最终功能。

3. 供应商或采购占比高的项目

采购占比高时，预算控制要前移到需求规格、报价比较、合同条款和付款里程碑。只在发票入账后核对支出，已经错过了调整合同范围和付款条件的最佳时机。

我会特别检查报价是否包含税费、接口、数据迁移、培训、上线支持、变更费率和续费条件。若招标方案存在不同技术路线，应分别估算初始采购成本和后续维护成本，避免只挑首年价格最低的方案。

4. 多团队共同承担成本的项目

跨部门项目应在预算启动时明确成本归属和分摊方式。若一部分人员工时由业务部门承担，另一部分采购费用由信息技术部门承担，项目经理需要一份统一的项目视图，同时尊重各部门正式账务口径。

预算评审前，可以由各成本责任人确认本期发生、承诺和预测金额，再由项目经理汇总差异。若某团队提供的是估算而非正式承诺，应在报告中标注数据状态，避免管理层把预测误认为已核实金额。

5. 预算已经明显超限的项目

如果完工预测持续高于批准预算，第一步不是立即冻结所有支出，而是判断项目是否仍值得继续。评估应包括已投入成本、剩余成本、预期收益、停止成本、替代方案和合同退出成本。

已花出去的钱本身不能成为继续投入的理由。反过来，项目也不能因为当前超支就机械停止；若剩余投入可完成关键业务目标，且停止会造成更大损失，继续可能仍是合理选择。关键是把未来成本和未来收益分开看，不让沉没成本主导判断。

6. 预算口径和数据来源不统一的组织

先不要急着建复杂仪表盘。第一阶段应统一项目编码、成本类别、数据责任人和更新时间，明确财务、采购、工时、项目管理数据各自的权威来源。

随后挑选少量项目试运行，把人工汇总流程做实，再决定哪些步骤适合自动化。若直接连接多个系统却没有统一口径，最终会得到多个版本的“项目余额”，增加争议而不是提高可见性。

七、不同情况下的取舍：预算准确性、速度和灵活性不能同时最大化

1. 估算精度与决策速度的取舍

等信息完全明确后再批准预算，估算通常更准确，但项目启动会延迟；在信息不足时先给出区间和阶段上限，可以更快启动验证，却要求组织接受预测会滚动变化。

我的判断是：若早期验证成本较低、失败代价可控，应尽快小额验证；若错误决策会带来大型合同、合规风险或不可逆迁移，就值得先投入更多分析和尽职调查。不要对所有项目使用同一种估算深度。

2. 储备比例与资金利用率的取舍

储备留得多，短期看似资金利用率较低；储备留得少，遇到可预见风险时又可能频繁追加。合适额度不应机械套用统一百分比，而要参考项目范围成熟度、历史预测偏差、合同可变更性和风险暴露程度。

若企业没有足够历史数据，可以先通过一批项目记录估算偏差和触发原因，再逐步形成内部建议区间。使用区间时应标明适用项目类型，不能把试点项目的经验直接推广到完全不同的项目。

3. 集中控制与团队自主的取舍

集中审批可以提高资金透明度，降低重复采购和越权支出风险，但审批过多会拖慢执行；完全下放可以提高响应速度，却可能造成资金使用口径不一致。

可以按金额、成本类别和可逆程度设计授权。低金额、已在批准范围内、容易撤销的支出，可给予项目团队较高自主权；大额合同、跨科目转移、范围扩张或长期续费，则应提高审批层级。

4. 单项目最优化与组合优先级的取舍

项目经理通常希望把自己的项目做完整，但企业资金有限时，真正的选择可能是项目之间如何排序。即使某个项目能在原预算内完成，也不代表它优先级高于其他更有价值的项目。

当项目组合需要重新排序时，建议把预期收益、战略重要性、风险、剩余投入、可停止成本和资源依赖一起呈现。项目预算不应成为部门争取资源的孤立工具，而应能支持组合层面的资金调整。

八、项目经理可直接使用的预算管理流程与检查表

1. 立项阶段：把口径和假设写在数字前面

项目经理应组织业务负责人、财务、采购和交付团队共同确认范围及成本边界。预算材料中不仅要列金额，还要列估算来源、假设条件、排除项和不确定性。

• 写清交付成果、首期范围和明确排除项。
• 说明内部工时、税费、差旅、培训、运维和续费的计价口径。
• 区分一次性投入与项目结束后持续发生的费用。
• 列出主要成本驱动因素和估算依据，例如报价、历史项目或人员计划。
• 标记高不确定性工作，并说明需要什么验证才能收敛估算。

2. 计划阶段：将预算映射到成果、责任人和时间

预算分配应能追溯到工作包和成本责任人。项目经理不必在所有细节上追求同一颗粒度，但应确保大额、不可逆或高风险支出有明确负责人和决策依据。

• 把交付成果拆成可估算的工作包。
• 为每个工作包标出人力、采购、服务和其他成本类别。
• 按计划月份或阶段安排成本发生时间。
• 标记已批准、待报价、待验证和情景预测等数据状态。
• 定义阶段资金释放条件和预算变更审批权限。

3. 执行阶段：按周期更新四类金额

不必要求每个团队每天更新预算，但必须有固定的核对节奏。常见做法是每周关注重大合同和风险事件，每月对账实际、承诺和完工预测；周期应根据项目速度、采购周期和组织要求调整。

• 核对实际成本与财务记录，标注尚未入账的已发生事项。
• 同步合同、采购订单、已安排资源等承诺金额。
• 估算剩余工作成本，并更新完工预测。
• 解释偏差原因，而不是只更新最终数字。
• 对预测持续恶化或关键假设失效的情况及时升级。

4. 变更阶段：比较方案，不只申请追加金额

任何预算变更都应同时说明不变更的后果。项目发起人需要知道，追加资金可以买到什么，不追加会失去什么，缩减范围会影响哪些成果，延迟交付是否会产生额外成本。

对于跨科目调拨，应额外检查授权范围、合同约束、会计分类和部门分摊。即使总额不变，也要保留审批记录，确保后续审计和交接可追踪。

5. 关闭阶段：让预算差异变成下一次项目的输入

项目结束时，预算复盘不应只判断“有没有超”。还要比较初始估算、各阶段预测和最终实际，识别估算偏差、范围变化、采购差异和效率因素。

复盘结论要能落实为下一次的估算改进。例如发现迁移成本经常被低估，就建立数据质量检查的前置工作；发现采购审批常延迟，就把等待时间纳入计划；发现维护费用未纳入立项，就调整预算模板。

6. 一页预算审查表应包含的字段

九、总结：好的预算不是最精确的表，而是最早暴露错误的机制

1. 把预算管理从“记账”改成“决策”

预算分配最佳实践并不等于把每项成本拆到最细，也不等于把预备金压到最低。更重要的是让管理者持续看见资金对应的成果、风险和承诺，知道预测为什么变化，并能在不可逆成本发生前作出调整。

我认为项目经理最值得坚持的三个习惯是：同时追踪已发生与已承诺金额；用完工预测而非单纯消耗率判断风险；每次变更都写明原因和可选方案。这三件事比增加一张复杂表格更能改善预算质量。

2. 下一步从一个项目开始做小范围验证

如果现有预算流程已经难以判断真实余额，不必先启动大型系统改造。选一个正在执行的项目，统一批准预算、实际、承诺和完工预测四种口径，连续两到三个周期记录偏差原因，再检查哪些信息最常缺失。

随后再决定要补的是流程、责任、数据接口还是工具能力。对于使用项目管理平台的中大型组织，可以先验证工作项、变更、责任人和预算状态之间的关联是否有效，再逐步连接采购和财务数据；任何平台都不应替代清晰的预算政策。

预算真正的价值，不是证明团队花得少，而是帮助组织把资金投向仍然值得完成的成果，并尽早停止那些已经不值得继续投入的部分。