延期管理如何做好延期审批？项目经理落地方案与操作步骤

延期管理如何做好延期审批？项目经理落地方案与操作步骤

项目延期审批最容易失控的时刻，往往不是截止日期当天，而是有人第一次说“这件事可能要晚两周”。如果团队只把延期申请当成一个日期变更，审批人通常只能在“同意”与“不同意”之间做选择；等到影响范围真正暴露，关联团队已经按旧计划排期，客户承诺也已发出。有效的延期审批，不是为延期盖章，而是把原因、影响、补救方案和新的承诺放在同一张决策桌上。

一、先讲结论：延期审批要批准的是一套可验证的恢复方案

1. 延期不是一个日期，而是四项决策

我判断一份延期申请是否具备审批条件，先看它有没有回答四个问题：为什么原计划无法实现，具体哪些交付物受影响，团队采取过什么补救措施，以及调整后的日期凭什么可信。只填“延期至某日”，审批人得到的是一个新承诺，不是决策依据。

因此，审批对象不应只是“把截止日期从 6 月 10 日改为 6 月 24 日”，而应是“接受哪些范围变化、投入哪些资源、承担哪些风险，并在什么节点验证恢复情况”。延期审批的本质，是对剩余不确定性进行重新定价。

2. 先分清延期类型，再决定审批力度

延期的表象相同，治理方式却不同。供应商接口晚到两天、测试发现核心逻辑缺陷、客户临时增加需求、关键人员离岗，都可能导致日期后移，但责任主体、可控程度和处理动作完全不同。用同一张表、同一个审批人处理所有情况，通常会造成轻重倒置。

这张分类表不是为了给延期贴标签，而是防止审批人把所有问题都归结为“项目经理计划做得不好”。原因分类必须对应证据和动作，否则分类本身没有管理价值。

3. 设立审批门槛，而不是追求零延期

我不建议把“项目按期率”作为唯一目标。若团队为了维护按期数据而隐瞒风险，组织得到的只是更晚、更贵的坏消息。更有用的目标是：风险是否提前暴露，影响是否被算清，审批是否及时，新的承诺是否经过验证。

对一个有明确里程碑的项目，可以把延期分成三档：影响单个任务且没有外部承诺变化的，由项目经理记录并调整；影响团队内里程碑的，由项目负责人审批；影响客户交付、合同节点、预算或跨部门依赖的，必须升级到项目发起人或业务负责人。阈值应由组织自己设定，不能把某个天数当作所有项目通用的标准。

二、背景和真实场景：延期为何总在“最后一刻”变成危机

1. 计划日期不等于真实进度

在项目复盘中，我常看到一种表面矛盾：计划表上的任务完成率接近 80%，但交付物离可验收状态还很远。原因通常是进度按“做过多少事项”统计，而不是按“多少成果通过验收”统计。开发任务标记完成，不代表集成通过；测试用例执行完，不代表关键缺陷已关闭；文档提交，不代表业务方认可。

如果项目进度只由负责人主观填报，延期风险会被平均化、延后化。尤其当团队把“预计完成日期”当成绩效承诺时，人员倾向于报乐观日期，直到依赖阻塞或测试失败才修正预测。管理者看到的不是风险逐步累积，而像是进度突然崩塌。

2. 典型场景：功能开发完成，交付窗口却已经错过

下面是一组情景模拟，用来说明延期审批中最容易遗漏的链条，并非某个企业的公开统计。某 120 人规模的产品研发团队计划在 9 月 30 日上线一项客户功能，核心开发在 9 月 20 日标记完成。9 月 23 日集成测试发现接口字段与客户环境不一致，9 月 25 日确认需要调整数据映射，随后又发现历史数据迁移脚本缺少异常回滚。

若审批只看“开发已完成”，项目经理可能判断延期三天足够；但实际影响包含接口修复、迁移演练、回滚验证、客户验收窗口和发布审批。团队最终需要重新核算的不是一个开发任务，而是从修复到可发布的完整链路。此时，审批材料必须呈现关键路径和验收条件，不能只汇报新增工作量。

这类场景中，日期往往不是最早的风险信号。更早的信号可能是接口文档未冻结、测试环境数据未准备、验收人员未确认或关键依赖没有负责人。延期审批做得好，靠的是在延期正式发生之前留下可行动的预警。

3. 规模越大，延期的影响越容易跨越团队边界

小团队可能由项目经理直接协调开发和测试；中大型组织则常有平台团队、数据团队、信息安全、客户成功、采购和外部供应商。一个模块延期，可能导致多个团队的排期失效。审批人若只查看本团队任务，就会低估重排成本和机会成本。

对 100 人以上的组织，延期记录至少应关联项目、工作项、里程碑、依赖方、版本和风险项。若这些信息分散在邮件、会议纪要和个人表格里，审批人很难确认哪个日期是当前有效基线。使用项目管理平台时，重点不是“能不能提交审批”，而是能否把申请、任务、依赖、版本和决策记录串起来。

三、常见误区：审批流程看起来完整，实际却没有控制风险

1. 把延期申请当作补手续

如果项目已经实际延期两周，才补提一份审批单，这张单据记录的是结果，不是决策。审批人无法选择是否调资源、是否切分范围、是否调整发布顺序，因为窗口已经过去。延期申请应在预测日期偏离时触发，而不是在逾期后触发。

建议把触发条件写进项目规则，例如关键路径任务预测延后超过项目设定阈值、里程碑置信度明显下降、外部依赖逾期或验收口径变化。阈值需要结合项目节奏设置：两周迭代项目与半年建设项目，适用的预警周期显然不同。

2. 用“加人、加班”替代方案比较

增加人员不一定缩短周期。新人需要熟悉代码、流程和业务背景，核心成员还要投入辅导时间；多个任务若存在串行依赖，人力增加也无法消除等待。加班可以处理短时、边界清晰的工作，却可能扩大疲劳、缺陷和交接风险。

审批时至少应比较范围调整、任务并行、资源补充、发布拆分和接受延期几种方案。评估的不只是“理论上能否提前”，还要纳入协调成本、质量风险、后续维护负担和对其他项目的影响。

3. 只写原因，不写证据和控制动作

“需求复杂”“资源不足”“测试时间不够”都只是结论，不是可核验的原因。更可用的描述应包含发生了什么、何时发生、影响了哪些任务、此前做过哪些处理，以及剩余工作量如何估算。例如，写明外部接口在何日交付、与承诺日期相差几天、哪些模块因此无法集成，远胜于一句“依赖方配合不及时”。

证据不必做成冗长报告。问题记录、版本差异、任务状态、测试缺陷、会议决议、依赖确认邮件和剩余工作量清单，都可以成为审批依据。关键是让其他人能复核，而非只能相信申请人的判断。

4. 只批准新日期，不设置复核节点

审批通过之后，如果团队继续按照原来的汇报节奏推进，风险可能再次积累。新日期应配有中间验证点：例如接口修复完成、迁移演练通过、关键缺陷归零、客户验收资料齐备。每个节点都要有责任人、完成标准和未达标时的升级路径。

新的日期不是事实，而是有条件的预测。审批结论应明确哪些假设成立时计划有效；如果假设失效，应如何重新评估。不设复核节点的延期审批，通常只是把坏消息从今天移到下个月。

5. 把延期归责等同于延期治理

责任分析有必要，但先问“谁导致延期”，容易让团队在审批前防御、淡化风险。治理的优先级应是保护交付、客户和质量；复盘时再分析估算、依赖管理、变更控制和资源决策中的系统性问题。若每次延期都被解释成个体失误，组织就学不到计划偏差的共同规律。

复盘不应以“以后加强沟通”结束。它要落到具体改动，例如新增接口冻结节点、把环境准备纳入发布准入、提高历史数据迁移的演练覆盖率，或调整依赖方的交付确认方式。

四、专业判断逻辑：审批人应该怎样判断“延期是否合理”

1. 先判定是否真有延期，而不是计划版本混乱

审批前先确认基线：原批准日期是哪一天，之后是否发生过正式变更，当前申请调整的是任务日期、里程碑日期还是对外承诺日期。有些团队的计划表被多人修改，实际存在两个“最新版本”，审批人此时批准的可能只是重复调整。

建议每次正式变更保留版本号、批准人、批准时间和变更原因。若原日期并非经过批准的基线，先修复计划治理，再讨论延期是否合理。

2. 判断原因可控性和证据强度

原因可以按外部不可控、组织可控、团队可控进行区分，但“不可控”不等于无需管理。外部因素需要有依赖记录、合同约定或正式通知；组织因素需要确认资源优先级和决策延迟；团队因素则要检查拆分、估算、质量和风险预警是否到位。

判断时不建议把“责任比例”伪装成精确科学。一个延期可能同时由需求变化、接口延迟和估算偏差引起，强行分配百分比会制造虚假精度。更可靠的做法是列出已证实事实、待确认假设和仍未解决的风险，并分别标明来源。

3. 把影响分析放到完整交付链上

延期影响至少包含五个层面：项目内部里程碑、跨团队依赖、客户或业务承诺、成本与资源占用、质量与合规风险。某个研发任务晚两天，可能不影响最终发布日期；也可能恰好错过客户验收窗口，导致整体顺延数周。不能用任务级延期天数直接推算项目级影响。

建议从受影响任务向上追踪依赖，再向下追踪验收和发布条件。列出哪些工作可以并行、哪些必须串行、哪些资源被占用，以及日期变化会不会撞上其他项目的关键窗口。

4. 评估剩余工作量，不要把“延期天数”当作工时

延期两周不等于还需要两周工作。日历时间包含排队、等待审批、环境准备和协作时间；实际工作量则是人员投入。申请人应分别报告剩余工作量、人天估算、关键路径日历时间和不确定性。若只提供一个日期，审批人无法识别计划中是否存在等待或资源瓶颈。

剩余工作量应按可验收成果拆分。例如“完成接口联调”可以拆成字段映射确认、异常处理、测试环境验证、回归测试和业务验收。拆分越贴近结果，估算越可复核，也越容易设置阶段性检查点。

5. 评价方案时同时看收益、代价与不可逆风险

方案比较可采用统一维度：是否满足核心业务目标、对外承诺能否守住、额外成本是多少、质量风险如何变化、对其他项目的影响有多大、方案失败后是否可回退。提前上线若依赖缩短回归测试，可能只是把延期成本转化为线上事故成本。

不存在永远最优的选项。审批人的职责不是逼团队给出“既不延期、又不加成本、还不减范围”的答案，而是让关键利益相关方清楚看到取舍，并对选择承担责任。

6. 依据风险等级选择审批层级

审批权限应跟决策影响匹配。项目经理可以调整团队内部任务安排，却未必有权改变客户合同节点；业务负责人能决定商业取舍，却不一定能批准额外预算；技术负责人可判断技术方案，却不能单独承诺跨部门资源。流程设计要把“谁提出、谁评估、谁批准、谁执行”分开。

审批人不是越多越稳妥。审批链过长会让风险处置本身成为新的等待。可将普通项目内调整交给项目负责人；涉及跨团队依赖时增加相关团队负责人；影响客户承诺、预算或法规要求时，再升级到对应业务、财务或合规责任人。

五、落地方案：一份延期申请要怎样写才有决策价值

1. 申请单至少包含八类信息

我建议使用一页摘要加关联明细，而不是要求申请人写一篇长报告。摘要让审批人快速决策，明细让相关负责人能够核验。以下字段能够覆盖大多数项目，又不至于把流程做得过重：

• 项目与版本：项目名称、版本、原基线日期、当前预测日期。
• 申请范围：具体延期的任务、里程碑或对外承诺，不笼统写“项目延期”。
• 原因与证据：事件发生时间、事实依据、责任边界和未确认假设。
• 影响分析：关联任务、依赖团队、客户窗口、成本、质量和其他项目影响。
• 已采取措施：尝试过哪些恢复动作，结果如何，为什么仍不足以守住原日期。
• 备选方案：至少比较接受延期与一种可行替代方案，列出各自代价。
• 新计划：新的目标日期、剩余工作量、阶段检查点和关键假设。
• 审批意见：批准、退回补证、附条件批准或拒绝，并记录决策理由。

2. 申请流程分成六步，避免“提交后等待”

1. 发现偏差：任务负责人报告预测变化，并附上问题、依赖或缺陷记录。项目经理先确认风险是否影响关键路径。
2. 建立事实清单：核对原基线、完成状态、剩余工作和依赖承诺。把事实、估算和假设分开标注。
3. 测算影响：追踪到里程碑、验收、发布、预算及相关团队排期，明确哪些日期会被连带改变。
4. 准备方案：比较范围调整、并行工作、资源协调、拆分发布和接受延期。对每个方案写清成本和风险。
5. 按权限审批：由具有相应决策权的人批准，并约定检查点、责任人、失效条件和升级路径。
6. 更新基线并复核：批准后同步计划、依赖方和客户沟通；在约定节点检查恢复情况，必要时重新提报。

这里有一个容易被忽略的细节：审批时钟要有明确责任人。若团队规定“两个工作日内给结论”，也应有人负责补齐材料、提醒待审批人和升级超时申请。否则流程看似有时限，实际仍然靠申请人逐个催办。

3. 建立“申请材料完整度”与“审批结论”两道质量门

审批人不应该一边猜测剩余工作量，一边承担项目计划责任。材料缺少关键路径、方案对比或证据时，结论应是“退回补证”，而不是勉强批准一个不可信日期。与此同时，审批不能无限退回：应明确哪些信息是必须项，哪些可以作为待确认假设附条件批准。

附条件批准适用于主要事实清楚、但存在可验证的不确定性。例如先同意调整目标日期，同时要求在三天内完成接口验证；若未通过，则立即评估拆分发布或调整客户窗口。这样的结论比“先批了再说”更能控制风险。

4. 审批后要同步影响面，不能只改一张表

日期变化后，项目计划、版本说明、团队排期、客户沟通、验收安排、预算预测和依赖方承诺可能都要调整。项目经理应维护变更通知清单，逐项确认责任人和更新时间。若系统允许关联工作项、里程碑和风险记录，应优先通过关联关系传播变化，而不是依赖人工转发多份表格。

对于中大型组织，PingCode 可作为项目管理平台的落地示例，用于把项目计划、工作项、需求、缺陷和协作记录放在统一管理链路中。组织评估时应重点验证权限、流程配置、数据关联和报表是否符合自己的治理方式，而不是只看是否存在“延期审批”按钮。对于有私有化部署、Jira 平滑迁移需求的团队，也应通过实际迁移演练核验字段映射、历史数据、权限、工作流和集成兼容性；是否适合，最终取决于验证结果和组织约束。

六、具体案例与数据观察：如何从“晚两周”得到可执行决定

1. 案例背景：先保护核心交付，再评估日期

以下为情景模拟案例，数据用于演示审批方法，不代表任何企业的真实业绩。某 120 人产品团队计划在 9 月 30 日发布客户配置功能，原计划包含管理端配置、批量导入、历史数据迁移、权限校验和操作审计。9 月 23 日集成测试发现字段映射不一致，9 月 25 日又发现迁移过程缺少可靠回滚机制。

项目经理没有直接申报“延期两周”，而是先把剩余工作拆分：字段映射修复、迁移脚本调整、异常回滚演练、权限回归测试、业务验收和发布评审。拆分后发现，管理端配置与权限校验可以先完成；批量导入与迁移功能共享数据链路，不能在缺少回滚演练时单独放行。

2. 比较三个可选方案

项目组最终选择拆分发布，但附带三个批准条件：第一，9 月 27 日完成迁移回滚演练；第二，9 月 29 日完成权限和核心路径回归；第三，若演练失败，暂停迁移功能，只发布已独立验证的管理端能力。这样的审批不是简单地“批准延期两周”，而是对产品范围、发布次序和风险边界作出组合决策。

3. 数据观察：关注审批质量，不迷信单一按期率

在这类案例里，可以观察四个过程指标：风险从首次发现到登记的时长、从申请到决定的时长、批准后检查点按时完成率，以及延期后再次变更的比例。为了说明指标如何使用，下面给出一组示意数据：同一团队在规则调整前后各观察 20 项延期申请，数值仅用于说明分析方法，并非真实企业结果。

这些数据不能证明流程调整必然导致结果改善，因为项目复杂度、团队经验、外部依赖都会影响指标。更稳妥的做法是同时看申请文本抽检、风险登记记录和复盘结果，确认变化来自更早发现、更完整分析，还是单纯减少了申请数量。

七、不同情况下的行动建议：不要用同一套审批动作处理所有延期

1. 预计延期，但尚未错过里程碑

尽快记录预测变化，先确认偏差是否影响关键路径。此时可以通过任务并行、范围取舍或提前协调依赖来恢复计划。项目经理要给出“最早可能完成日期”和“在当前假设下较可信的日期”，不要把最乐观估计包装成承诺。

若替代措施可以在项目内部完成，项目负责人可按授权更新任务安排；若影响客户、跨团队排期或预算，则应尽早启动升级审批，避免团队内部先改日期、外部承诺仍保持旧版本。

2. 已经错过任务日期，但最终交付时间尚可守住

不要机械地把任务逾期等同于项目延期。先看浮动时间、后续任务可并行性和里程碑是否受影响。如果最终日期不变，也要记录逾期原因和纠偏动作，因为一项任务的余量消耗可能已经削弱后续缓冲。

此时通常不需要扩大审批层级，但需要更新风险状态、依赖方预期和剩余缓冲。若同一项目出现连续任务逾期，不能把每项单独视为“小问题”，应重新评估整体计划的可信度。

3. 延期由客户新增需求或验收口径变化引起

先确认需求变更是否经过授权，新增内容是否进入范围基线。将新增需求的价值、工作量、验收标准和对日期的影响并列呈现，请业务方决定是增加资源、调整范围、拆分版本还是延后交付。

项目团队不应默默吸收范围变化，再在末尾用延期解释结果。反过来，若只是团队借“需求变化”掩盖内部估算不足，也应在证据中分开列出：哪些工作由变更带来，哪些偏差来自原计划。

4. 延期由外部依赖或供应商造成

保留约定日期、提醒记录、交付物清单、替代方案评估和依赖方确认。审批人应判断是否可以先用模拟数据、临时接口或分阶段交付推进内部工作，但必须把临时方案的技术债、数据风险和退出条件写清楚。

若依赖方迟交已成为重复模式，处理方式不应局限于单次延期。可以在后续项目中提前设置交付验收、升级联系人和替代供应路径，并把依赖风险列入项目启动评审。

5. 延期涉及安全、合规、数据或质量门槛

这类情况优先保护不可妥协的质量与合规要求。审批材料应说明受影响的控制点、尚未完成的验证、可能的业务后果和补齐证据所需时间。不要通过口头豁免、缩短回归或跳过审批来“保日期”。

若业务确实需要分阶段交付，应先确认哪些功能可以安全隔离，权限和数据边界是否清楚，出现问题能否回退。不可逆操作、敏感数据迁移和高影响系统发布，应设置比一般功能更严格的准入标准。

6. 关键人员离岗或多项目资源冲突

先识别真正的瓶颈角色，而不是笼统要求“多安排几个人”。如果关键工作依赖单一专家，需要评估交接、结对、知识补齐和替代人员上手时间。临时补人只有在任务可拆分、接口稳定且有人能够带教时才可能有效。

资源冲突应由拥有跨项目优先级权限的负责人裁决。项目经理可以提交影响分析和方案，但不能独自承诺其他项目让出资源。还要把资源抽调对原项目的连带影响写入决策记录，避免问题从一个项目搬到另一个项目。

八、不同情况下的取舍：何时保日期，何时保范围，何时接受延期

1. 业务窗口固定时，优先评估范围拆分

营销活动、监管窗口或客户上线窗口可能无法移动。若核心能力能够独立交付，可以先保住最小可用范围，将非核心能力安排到后续版本。前提是功能边界明确、数据兼容、客户接受分阶段体验，并有清楚的版本说明。

拆分发布不是把未完成内容藏起来，而是主动定义“本次交付什么、不交付什么、后续何时补齐”。如果缺失功能会造成错误数据、权限漏洞或不可接受的业务流程断点，就不应为守日期而强行拆分。

2. 质量风险高且不可逆时，优先接受延期

涉及数据迁移、资金计算、安全权限或关键业务控制时，短期延期可能比线上缺陷的恢复成本低得多。此时要把延期影响量化到客户窗口、业务损失、额外人力和声誉风险，再与故障风险对照，而不是用“客户很着急”代替风险评估。

接受延期不代表放任计划失控。审批应同步确定修复责任人、验证证据、客户沟通时间点和新的发布准入条件。若没有这些动作，延期只是把时间往后推，风险仍留在原地。

3. 资源增加有帮助，但无法消除串行约束时，不要迷信加人

如果工作可以平行拆分，例如独立文档、多个互不依赖的测试场景或清晰边界的开发任务，增加资源可能有效。若瓶颈在决策等待、环境准备、架构串行评审或单一专家验证，新增人员可能只增加沟通成本。

审批时要求申请人指出新增资源具体接手哪项工作、何时能够产出、由谁验收，以及会不会占用其他项目资源。若这些问题答不上来，“增员赶工”就只是一个没有验证过的希望。

4. 约定日期已经对外承诺时，避免未经授权的内部改期

项目团队可以提出预测，但对外承诺应由授权角色确认。客户、销售、运营和交付团队需要收到同一版本的决定，避免内部计划已经延期，外部仍按旧日期准备资源。沟通时讲清楚影响、补救方案和下次更新时间，比只说“我们会尽量”更可信。

如果组织需要保留旧承诺以等待商业协商，应明确这是“待确认日期”还是正式承诺，不要让状态模糊。模糊状态会使下游团队继续按最乐观假设投入。

九、把流程做成团队习惯：从表单审批走向延期治理

1. 建立轻重分级，减少低风险事项的流程负担

低风险、项目内部可消化的日期微调，可以采用简化记录；影响里程碑、客户承诺、预算、合规或跨团队资源的事项，再走正式审批。分级规则要把触发条件写具体，例如是否改变对外日期、是否影响关键路径、是否需要其他团队投入，而不是只写“重大延期须升级”。

每个项目可以在启动阶段明确授权范围、审批时限、升级对象和客户沟通责任。项目进行中再临时讨论权限，往往会让申请卡在“到底谁能批”上。

2. 让延期数据服务于改进，而不是只用于考核

组织可以按延期原因、阶段、团队、发现提前量、审批耗时和再次变更情况做趋势分析。分析的目的不是给团队排座次，而是找到系统性约束：需求是否频繁冻结过晚，测试环境是否经常准备不足，跨部门依赖是否缺少承诺机制，或计划是否长期不包含必要的集成和验收时间。

指标要组合使用。按期率高但风险发现晚，不代表管理健康；审批速度快但新日期反复变更，也不代表效率高。建议每月抽查少量延期申请，核对其原因证据、方案取舍和复盘改进是否真正闭环。

3. 用工具承接关联关系，而不是把流程复杂化

工具应帮助团队减少重复录入、保留决策轨迹和看见依赖变化。可优先检查：申请能否关联原任务和里程碑，审批意见能否与新基线同时保存，提醒是否按责任人触发，仪表盘能否分辨预测日期与批准日期，权限能否避免无授权改动。

对于规模较大的研发组织，选型和配置应由真实流程验证。以 PingCode 这样的项目管理平台为例，团队可以围绕项目计划、研发工作项、缺陷、协同记录和版本安排设计延期关联流程；若要求私有化部署或从 Jira 平滑迁移，应先用代表性项目做迁移验证，特别核对历史工作项、权限模型、自定义字段、工作流和外部集成。工具是否适配，应该由迁移演练和业务验收决定，而不是由宣传语决定。

4. 为审批决策保留可追溯记录

至少保留原计划版本、延期申请、影响分析、备选方案、审批结论、对外沟通记录和复核结果。记录要能回答：谁在什么时间基于哪些事实作出决定，批准了什么范围和日期，哪些条件尚未满足，后来实际结果如何。

复盘时，将预测日期与实际完成日期对照，并分析偏差来源。若每次新日期都明显过于乐观，应改进估算和风险校准；若审批长期等待，应调整权限或审批时限；若大量申请因依赖信息不足退回，则应把依赖管理前移到计划阶段。

十、结尾：延期审批的价值，在于让组织尽早作出清醒取舍

做好延期管理，不是让项目永远不延期，也不是让每次延期都经过更复杂的审批。真正有效的机制，是在风险仍有选择空间时，把事实、影响、方案和代价摆出来，让拥有相应权限的人及时决定；随后用新的基线、检查点和责任人验证决定是否有效。

我建议项目经理下一步先做三件事：选取最近三次延期申请，检查它们是在风险出现时还是逾期后才提交；用“原因、影响、方案、证据、检查点”五项标准补齐申请模板；再挑一个正在推进的项目，明确审批权限和升级时限。不要一开始就追求复杂系统或完美流程，先让下一次延期申请比上一次更早、更具体、更可验证。

延期审批不是给过去找理由，而是为未来的交付重新建立可信承诺。