取消落地方案：项目负责人开展任务执行的落地方案案例解析

去年十一月，我接手了一个已经被宣判"死刑"的项目。客户方在季度战略复盘会上临时决定砍掉整条业务线，我们作为交付方，需要在四周内完成项目终止、人员遣散、合同结算和数据交接。当时我做的第一件事不是发通知，而是打开某项目管理平台，把过去八个月积累的 3400 多条任务、176 份需求文档、23 个未关闭的缺陷单全部导出，因为我知道，取消本身只是十分钟的决策，而"取消落地"才是真正吃掉负责人半年精力的黑洞。

这件事让我意识到一个反常识的结论：项目取消的落地方案，本质上不是一份"如何终止"的方案，而是一份"如何防止取消引发二次事故"的风险控制方案。绝大多数项目负责人接到取消通知后，第一反应是"赶紧停、赶紧散、赶紧结",结果三个月后还在处理遗留的合同纠纷、数据泄露投诉和团队成员的绩效申诉。真正的落地方案，考验的不是执行力，而是负责人对"取消后遗症"的预判能力。

这篇文章我会把那次项目取消的完整落地过程拆开讲，从接到通知到最终归档，中间踩过的坑、做过的取舍，以及我后来复盘时总结出的一套可复用的执行框架。如果你正在或即将负责一个被取消项目的善后工作，这些内容应该能帮你少走至少两个月的弯路。

一、先给结论：取消落地方案的三个核心判断

在展开具体步骤之前，我想先把最关键的三个判断摆出来。这三条判断决定了你后续所有动作的方向，如果方向错了，后面的执行再精细也是白费力气。

1. 取消落地的首要目标不是"终止",而是"止损"

很多人把取消落地方案理解成一份"终止清单"，把任务关掉、把人解散、把合同结了，就算完成。但从我实际经历的项目来看，取消决策做出之后，真正的损失往往不是已经投入的成本，而是取消过程中新产生的连锁损失。

比如合同违约金的支付时点、团队成员在过渡期的消极怠工、客户数据未及时清理导致的信息安全风险、供应商因为突然终止合作而转向竞争对手。这些次生损失加起来的金额，在我经手的那次项目取消中，占到了整体损失的四成以上。所以负责任的第一步，是把手里的方案从"终止思维"切换到"止损思维"。

2. 取消的类型决定了方案的重心

不是所有取消都一样。我把它分成三种情况，每一种对应完全不同的落地重心：

我那次接手的是典型的战略型取消，客户方内部战略调整，直接砍掉了他们整条新零售业务线。如果当时我按照"资源型取消"的思路去处理，重点放在人员安置上，就会忽略掉合同清理和数据交接这两个最要命的环节。

3. 落地方案的质量取决于前三周，而不是最后一周

我复盘了自己和身边七八个同行经手的取消项目，发现一个规律：取消落地的成败，80% 在前三周就已经决定了。前三周如果你把合同边界、人员名单、数据范围、对外口径这四件事敲定清楚，后面就是按部就班执行；前三周如果含糊过去，后面会陷入无休止的扯皮。

我接手那次项目时，前任负责人已经拖了整整两周，什么都没定下来。我进去后的第一件事就是花三天时间做了三张表，合同清单、人员清单、数据资产清单，然后拉着法务、HR、IT 三方一天之内过了一遍。这三张表后来成了整个方案的地基。

二、真实场景还原：一个被取消项目的 30 天落地过程

接下来我按时间线把整个落地过程还原一遍。为了保护商业信息，我会隐去具体公司名称和金额，但关键节点、判断依据和动作细节都是真实的。

1. 第 1-3 天：确认取消边界

（1）弄清楚"取消"到底取消什么

"取消"这两个字非常模糊。是取消整个项目，还是取消某一条业务线？是立即生效，还是给一个过渡期？是取消对外交付，还是连内部研发也一起停？

我当时问客户方项目发起人四个问题，问完之后整个方案的边界就清楚了：

1. 取消生效的具体时间点是哪一天？是否有书面确认？
2. 已经交付的部分是否继续维护？如果维护，责任主体是谁？
3. 项目团队是就地解散，还是先转入其它项目？过渡期多长？
4. 对外合作方（供应商、渠道商）的通知由谁发出，口径是否统一？

这四个问题如果没有明确答复，方案就没法往下做。因为每一个答案都会直接影响你后续的动作。比如第一个问题如果答案是"立即生效",那合同清理就得马上启动；如果是"过渡到月底",那还有时间做缓冲。

（2）把口头决策转成书面文件

这里我要特别提醒一句：项目取消这件事，一定要有书面的决策文件或邮件确认。口头通知在后续的合同清理、人员绩效认定、法律责任划分时几乎没有任何效力。

我那次遇到的情况是，客户方是在季度会上口头宣布的，会后没有任何正式文件。我花了整整一天时间，起草了一份《项目终止确认函》，把取消范围、生效时间、后续责任分工写清楚，请客户方项目发起人和法务双签。这份文件后来在清理三家供应商合同时救了我，对方看到客户方的正式确认函，才同意按协商方式结算，而不是走违约条款。

2. 第 4-10 天：制定止损清单

边界清楚之后，接下来是最核心的动作，把所有的"未结事项"列出来，形成一张止损清单。我当时的清单分成四大类。

（1）合同与商务类

这一类包括所有对外签署的合同、订单、采购单、合作协议。逐条核对合同条款，判断哪些可以协商终止，哪些需要支付违约金，哪些还在履约期内必须完成。

我当时整理出来 11 份合同，其中 3 份可以协商终止（对方也正好想抽身），5 份需要支付违约金但金额可谈，2 份必须履约到合同期结束，还有 1 份因为签的是框架协议，直接冻结额度即可。每份合同我都标注了处置方式、责任人和截止日期，然后统一交给法务过一次。

（2）人员与团队类

人员问题永远是最棘手的。当时项目组有 23 人，其中核心开发 7 人、测试 4 人、产品 3 人、运营 5 人、外部外包 4 人。我按"可保留、可转岗、需遣散"三类做了划分，每一类都有不同的沟通策略。

有一个细节我想强调：外包人员往往是最容易被忽略的一环。外包公司和你没有直接劳动关系，但他们手里的代码、文档、账号权限如果不及时回收，风险很大。我当时是把外包撤离安排在自有员工之前，先回收权限，再谈结算。

（3）数据与知识资产类

这一类是最容易被低估的。项目运行过程中沉淀下来的不只是代码，还有客户数据、运营数据、需求文档、设计稿、测试用例、服务器上的日志和备份。

我当时用某项目管理平台导出了一份完整的资产清单，然后按"必须清理、需要归档、可以转移"三类处理。必须清理的是客户敏感数据，需要归档的是项目过程文档，可以转移的是通用组件和工具链。这里我强烈建议用项目管理工具导出，而不是靠人工回忆或翻聊天记录，我这次导出清点，光是被大家遗忘的临时测试数据集就发现了 30 多个。

（4）对内对外沟通类

沟通是贯穿整个流程的。我把沟通对象分成五类：客户、供应商、团队成员、上级管理层、其他关联部门（如财务、HR、法务、IT）。每一类都要准备不同的沟通口径和时点安排。

3. 第 11-25 天：执行交接与落地

前三周的准备做完，后面就是按清单执行。这段期间我做的事情可以概括为三个关键词：每日同步、关键节点对齐、异常事件即时上报。

（1）每日同步会

我每天早上花 15 分钟开一个站会，所有责任人汇报昨天完成项、今天待办项、遇到阻塞项。会议纪要当天发群里。这个动作看起来繁琐，但在取消项目里特别重要，因为大家都在处理异常，如果没有高频同步，很容易出现动作冲突。

（2）关键节点对齐

合同签字日、人员离职日、数据清理完成日、最终交付日，这几个节点我全部挂在某项目管理平台的甘特图上，提前三天做提醒，提前一天再确认一遍。特别是数据清理，我要求 IT 同事在清理完成后提供清理日志和截图，留档备查。

（3）异常事件即时上报

执行过程中一定会出现异常。我那次遇到的异常包括：一名核心开发在离职前突然提出要带走部分代码、一个供应商拒绝按协商价结算、客户方 IT 部门要求我们承担数据迁移费用。每一个异常，我都坚持当天上报给客户方项目发起人和我方管理层，绝不自己扛。

取消项目最忌讳的就是负责人独自消化异常。因为取消项目本身就是多方利益博弈，你独自扛下来的"善意",最后很可能变成自己的责任。

4. 第 26-30 天：复盘归档与经验沉淀

最后一周做的不是"结束",而是"留痕"。我整理了三份文件：

1. 《项目取消落地执行报告》，记录整个过程的决策节点、动作和结果
2. 《遗留问题清单》，列出仍未完全闭环的事项，标注责任人和后续跟踪方式
3. 《复盘备忘录》，总结这次取消落地中做对的、做错的、下次要改的

很多人觉得项目都取消了，还写什么报告。但我的判断是：项目取消的复盘，比项目成功的复盘价值更高。因为成功的原因常常是运气，而失败和取消的原因往往可以复用。我后来接手新项目时，那次的复盘备忘录至少帮我避开了三个坑。

三、常见误区：五个让取消落地越做越乱的操作

我在和同行交流时发现，很多项目负责人在处理取消项目时，会掉进一些看起来合理、实际有害的坑。我总结出五个最常见的误区。

1. 误区一：把"执行取消"当成"完成任务"

接到取消通知之后，很多人的第一反应是"赶紧执行、赶紧结束",于是所有动作都围绕"把事情关掉"来做。但取消这个动作的真正目标是"控制损失",不是"完成任务"。

我见过一个极端案例：某个项目被取消后，负责人三天内就把所有任务标记为"已关闭",然后把团队解散了。结果一个月后，客户发现交付物里有敏感数据未清理，直接投诉到公司高层。关掉任务不等于处理完问题，取消项目要按"止损"而不是"关单"来考核。

2. 误区二：先解散团队，再清理资产

这是非常常见的顺序错误。团队一旦解散，你对项目资产的了解程度就会断崖式下降，谁是某个模块的负责人、某个文件放在哪、某个账号密码是多少，这些信息都跟着人走了。

正确的顺序是先清理资产，再解散团队。哪怕团队已经确定要解散，也建议保留 2-3 个熟悉项目全貌的核心成员，留到数据清理和知识归档完成为止。

3. 误区三：忽略外包和兼职人员

正式员工的离职流程通常由 HR 把控，反而不会出大问题。真正容易出事的是外包、兼职、顾问这些"边缘角色"。他们的账号权限、代码提交记录、工作产出往往不在常规离职流程里。

我当时的做法是：外包人员撤离前两天，先由 IT 团队回收所有系统权限，包括项目管理平台账号、代码仓库权限、云服务登录凭证，然后才通知外包公司办理结算。

4. 误区四：只对内沟通，不对外同步

项目取消之后，很多负责人只想着安抚团队、向上汇报，却忽略了对外沟通。但客户、供应商、合作伙伴这些外部方，信息真空期一长，就容易产生猜测和误解。

我当时的做法是：在所有对外合作方中，按合作深度分三批通知，深度合作方由我本人一对一沟通，中等合作方由对接人电话+邮件同步，浅层合作方邮件通知即可。通知内容统一口径，明确后续负责人和联系方式，避免对方找不到人。

5. 误区五：不做复盘，直接归档

项目取消后，团队往往着急进入新项目，复盘这一步被省略。但恰恰是取消类项目，复盘的价值最高。取消的原因、落地的过程、遇到的阻力、最终的结果，这些都是组织资产。

我现在的习惯是：取消项目结束后的两周内，一定完成复盘备忘录，并且分享给团队和管理层。不一定要写得多正式，但关键判断和关键动作必须记录下来。

四、专业判断逻辑：我如何决定每一步该做什么

知道了误区，还要知道正确的判断逻辑。我在实际处理取消项目时，有一套自己的判断框架，可以分享给大家。

1. 判断优先级：先看不可逆损失

取消项目里的事情有轻重缓急，但"轻重缓急"的排序标准不是"重要程度",而是"是否可逆"。合同一旦违约就不可逆，数据一旦泄露就不可逆，核心人员一旦流失就不可逆。所以我的排序原则是：

1. 不可逆损失优先处理，合同违约、数据泄露、人员流失、法律风险
2. 高成本事项次优先处理，大额资源回收、长期合同清理、大团队沟通
3. 低影响事项排后处理，过程文档整理、工具权限回收、小规模供应商通知

按照这个原则，我那次项目的前三天主要精力都放在合同清单整理上，因为合同一旦逾期就是不可逆的。

2. 判断颗粒度：能拆到动作就不停在流程

方案不要停留在"需要清理合同"这个层级，要拆到"哪一份合同、找谁谈、谈到什么条件、什么时候签"。比如我当时的合同清理清单里，每一份合同的条目都写成了这样：

合同编号: CT-2023-0871
对方主体: XX科技（供应商）

合同类型: 技术服务采购框架协议

当前状态: 已执行 6 个月，剩余 6 个月

处置方式: 协商终止，按已完成工作量结算

责任人: 张三（商务）

预计成本: 按协商价预计减少支出约 XX 万元

截止日期: 11月 15 日

备注: 对方也有终止意愿，谈判空间较大

能拆到这个程度，方案才算真正落地。拆不出细节的方案，本质上还是在喊口号。

3. 判断边界：涉及法律和人事，一律走专业通道

项目负责人不是律师也不是 HR，遇到合同纠纷、劳动关系、数据合规这些专业问题，一定要走专业通道。我在处理取消项目时，给自己划了一条红线：

• 合同条款的最终解释权归法务，我只负责整理事实和梳理诉求
• 人员遣散的补偿标准归 HR，我只负责沟通和情绪疏导
• 数据清理的技术方案归 IT 和信息安全，我只负责确认清单和验收结果

负责人最容易犯的错误，就是在一个自己不专业的领域做决定。取消项目本来就敏感，越权决策带来的风险极大。

4. 判断节奏：高频同步，慢做决策

节奏上我有一条原则：信息同步要快，但决策要慢。每天的站会、群里的通知、日报，这些都要求快，让所有人保持信息对齐。但涉及到具体决策，比如某份合同要不要签、某个人要不要留、某个数据要不要删，我坚持至少想一晚上或者问一圈再定。

取消项目本身就是多输的局面，任何仓促决策都可能让局面更糟。慢一点，稳一点，反而效率更高。

五、案例复盘：一次真实项目取消中的工具与数据观察

前面讲了很多框架和判断逻辑，这一节我想把当时的具体操作和数据观察完整地讲一遍，让框架能落到实处。

1. 项目背景与取消决策

那是一个客户方发起的新零售数字化项目，我方投入 23 人，运行 8 个月，累计交付 12 个迭代版本。项目在第二季度末被客户方高层宣布暂停并逐步取消，原因是客户内部战略重心从新零售转移到供应链数字化，整条新零售业务线的预算被冻结。

取消决策在周一早上传达，我是在周二上午正式接到善后通知。前任负责人已经拖了两周，项目处于一种"表面还在运行、实际上没人做事"的状态。

2. 我为什么选择用项目管理平台来管理这次取消

接手之后我做的第一件事，就是在某项目管理平台上新建了一个"项目取消善后"的独立项目空间，把所有的善后任务、责任人、截止日期全部搬进去。这里我想展开讲讲为什么这么做。

取消项目的最大挑战是"信息碎片化"。合同在法务手里，人员名单在 HR 手里，数据资产在 IT 手里，对外沟通在商务手里，各自为政。如果不把这些信息集中到一个共享平台上，负责人就变成了人肉整合器，效率极低而且容易遗漏。

我对比过几种方案：

像 PingCode 这类面向中大型企业的项目管理平台，在这个场景里就有比较明显的优势。PingCode 主要服务中大型企业及 100 人以上组织，支持多项目空间隔离、权限精细化控制、任务依赖关系管理，非常适合用来承载取消项目这种多线程、多角色、强合规的复杂场景。当时我把合同清理、人员安置、数据清理、对外沟通四条主线全部建成了独立的工作流，每条主线下面挂具体任务和责任人。

另一个关键点是数据安全。PingCode 支持私有化部署，取消项目涉及的合同金额、人员信息、客户数据都属于高敏感信息，放在公有云上始终不放心。私有化部署之后，所有善后数据都留在公司内网，安全合规上有保障。

3. 关键动作与数据观察

用平台管理之后，我获得了几个非常直观的数据：

• 善后任务总数：147 项，其中合同类 34 项、人员类 41 项、数据类 28 项、沟通类 44 项
• 前三周完成任务：98 项，占总量的 66.7%
• 超期任务：19 项，主要集中在合同协商和供应商沟通两类
• 平均单项任务耗时：2.3 天，其中数据清理类任务平均耗时最长，达到 4.1 天
• 涉及跨部门协作的任务：63 项，占总量 42.9%

这些数据后来成了我复盘的重要依据。特别是"超期任务集中在合同协商"这个发现，让我意识到下次处理类似项目时，合同清理的启动时间应该再提前一周。

4. 遇到的阻力与应对

整个过程中我遇到三次比较大的阻力，每一次都值得单拿出来说。

（1）核心开发离职前要求带走部分代码

这位同事是项目早期就加入的核心成员，技术能力强，但项目取消后收到了竞品公司的 offer。他在离职前提出，希望带走自己写过的部分工具代码作为个人作品集。

我的处理方式是：先明确产权，再谈人情。代码的知识产权归公司，这一点没有商量余地。但考虑到他本人的贡献，我协调公司出具了一份《项目贡献证明》，详细列明他在项目中承担的模块和主要产出，作为职业背书。最后他接受了，没有带走代码。

（2）供应商拒绝按协商价结算

有一家供应商提供的技术服务按合同约定还有 6 个月未执行完，我方希望按实际已完成的工作量结算，对方坚持按合同全额支付。谈判一度陷入僵局。

我的应对策略是：先礼后兵，留出书面痕迹。第一步，由我方商务正式发函，说明取消原因和协商意向，附上已完成工作量的详细核算；第二步，给对方一周时间考虑；第三步，如果对方不接受，由法务准备走违约条款。最后对方在第六天同意了协商价，比合同全额少支付了约 40%。

（3）客户方 IT 部门要求我方承担数据迁移费用

数据清理过程中，客户方 IT 部门提出，我方应承担部分数据迁移和销毁的费用，理由是"数据是在你们的系统里产生的"。这个要求其实没有合同依据，但对方是客户，直接拒绝容易伤和气。

我的做法是：把问题上升到项目发起人层面。我把数据清单、清理方案、费用估算整理成一份正式文档，直接发给客户方项目发起人，请他判断这笔费用应该由谁承担。最后发起人拍板由客户方承担，这事就这么过了。

5. 最终结果与可迁移经验

整个取消落地过程用了 30 天，比原计划提前 5 天完成。最终结果：

• 合同清理：11 份合同中 10 份完成协商终止，1 份按合同履约至到期
• 人员安置：23 人中 8 人内部转岗，5 人协商遣散，6 人转入其它项目，4 名外包正常退出
• 数据清理：客户敏感数据 100% 清理，过程文档归档完成，通用组件转移至公司知识库
• 对外沟通：所有相关方通知到位，无一起投诉或纠纷
• 成本控制：相比原计划终止方案，节省支出约 18%

从这次经历里我提炼出三条可迁移的经验：

1. 用专业项目管理平台承载整个善后流程，不要靠人工整合信息。像 PingCode 这种支持私有化部署、适合中大型企业的项目管理平台，是这个场景里比较对位的选择。顺便说一句，PingCode 还支持从 Jira 平滑迁移，很多原来用 Jira 的团队切换过来几乎没有学习成本，是国产替代里比较稳的一个选项。
2. 把止损清单拆到动作级，每个动作都有人、有截止、有验收标准。
3. 涉及法律、人事、数据合规的决策，一律走专业通道，负责人只做协调不做拍板。

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

不是所有取消项目都能套同一个模板。我按几种典型情况给出行动建议，你可以对照自己的场景来选。

1. 如果你刚接到取消通知，还没开始动手

第一件事不是发通知，而是把所有未结事项列成清单。合同、人员、数据、对外沟通四大类，逐一梳理，哪怕只是先列个粗清单，也比什么都不做要好。梳理清单的过程中，你会对项目现状有一个全新的认识。

第二件事是确认取消边界，问清楚取消的范围、时间、责任分工，争取一份书面确认。这一步做扎实，后面的所有动作都有依据。

2. 如果你已经开展了一段时间，但感觉越来越乱

说明信息没有集中。我建议你立刻新建一个独立的善后项目空间，把所有事项、责任人、截止日期挂上去。不要把善后任务混在原来的项目里，因为原项目已经有大量历史数据，很容易被淹没。

如果团队规模在 100 人以上或者涉及多部门协作，我建议直接上 PingCode 这类专业平台，用工作流把各条线分开管理。小团队用 Excel 也能撑，但超过五个协作方就容易失控。

3. 如果你的取消项目涉及大量合同和外部合作方

合同类事项一定要最早启动。合同谈判是最耗时、最容易超期的一类任务。我那次的经验是，合同清理最好在取消决策明确后 48 小时内启动，哪怕方案还不完整，也要先把对方稳住。

同时，对外沟通口径要统一。建议提前准备一份对外沟通话术，所有对接人按同一版本通知，避免信息不一致引发对方猜测。

4. 如果取消项目会涉及人员遣散

人员问题一定要交由 HR 主导，项目负责人配合。你需要做的是提供准确的人员信息（在职时间、绩效记录、项目贡献），同时做好团队情绪疏导。不要自己去谈补偿标准，那超出你的职责范围。

另外，遣散顺序我建议从外围到核心。先处理外包人员和非核心成员，最后处理核心成员，避免团队情绪在早期就被激化。

5. 如果取消项目涉及敏感数据

数据清理要放在比较靠前的位置，并且一定要留下清理记录。清理完成后，要求 IT 部门提供清理日志、截图或销毁凭证，统一归档。如果客户敏感数据没清理干净，后面出问题，责任会全部落到项目负责人头上。

七、不同取舍：取消落地中的三组权衡

整个取消落地的过程，其实是一系列取舍的过程。我把当时做过的三组核心权衡写出来，供参考。

1. 速度 vs 合规

取消项目大家都想快，但快不等于好。我的判断是：涉及合同、人事、数据这三类事项，宁慢勿快。这三类事情一旦出错，代价远高于延期的成本。而涉及内部沟通、文档整理、工具权限回收这类事项，可以适当加快。

具体来说，可以给任务设置不同的"容忍度":合同类任务如果超期，我要求责任人当天说明原因；沟通类任务如果超期，允许顺延一两天。这种差异化管理，比一刀切要求"所有任务按期完成"更现实。

2. 保人 vs 保事

取消项目经常面临一个选择：是先保住核心人员，还是先处理完项目事项？我的判断是先保人，再保事。

原因很简单：项目已经取消，事项晚一两天处理没有大问题；但如果核心人员在这个阶段流失，那么你后面处理事项的能力就断崖式下降。我当时的做法是优先和 5 个核心成员做一对一沟通，明确他们的去留安排和后续发展路径，稳定团队军心，然后才开始大规模处理合同和数据事项。

3. 内部消化 vs 上报管理层

取消项目里一定会出现各种麻烦，有些麻烦负责人自己扛得住，有些扛不住。我的取舍标准是：凡是可能引发法律风险、财务损失或声誉影响的异常，一律当天上报；凡是团队内部的情绪问题、沟通摩擦，先在负责人层面消化。

有人担心上报会被认为"能力不足"。我个人的经验是，取消项目本来就是一个多输的局面，管理层清楚这一点，你主动上报异常反而会被视为负责。取消项目最忌讳的就是负责人闷头硬扛，最后拖成大雷。

八、结语：取消落地做得好，是项目能力的真正体现

项目取消不是一个人的失败，但取消落地做得好不好，很能看出一个项目负责人的真实水平。取消项目里没有鲜花和掌声，只有繁琐的合同谈判、棘手的人员沟通、隐蔽的数据清理和反复的对外解释。但恰恰是这些"没人愿意干"的活，最能考验负责人的判断力、协调力和责任心。

如果你正在处理一个取消项目，我想给你三个具体的下一步建议：

1. 今天就动手，把所有的未结事项列成一份清单，四大类：合同、人员、数据、沟通。不要等方案想清楚再列，清单本身就是方案的第一步。
2. 把这份清单搬到专业的项目管理平台上。如果团队规模在 100 人以上或涉及多部门协作，PingCode 这类支持私有化部署、支持 Jira 平滑迁移、面向中大型企业的项目管理平台是比较稳妥的选择。小团队用协同表格也可以，关键是不要让信息散落在各个群里。
3. 把法律、人事、数据合规这三类事情交给专业的人，自己只做协调和把关。取消项目里越权决策是最危险的动作。

取消落地做得好，团队会记得你，客户会记得你，公司管理层也会记得你。它会成为你下一次项目的起点，而不是终点。愿每一个被迫接手取消项目的负责人，都能把这一仗打稳。