审批实操方法：PMO提升工时表效率的效率提升方法与模板

工时表审批最耗人的，往往不是填报，而是月底才发现项目、任务、人员和日期对不上：员工补填两周记录，项目经理逐条核对，财务再追问费用归属，PMO最后还得把几套口径拼成一张报表。我的判断是，效率提升不应从“催得更快”开始，而要从减少无效审批、提前发现异常和统一数据口径开始。下面给出一套可落地的审批方法、判断规则与模板，并用明确标注的情景模拟数据说明怎样衡量改进。

一、先讲核心结论：工时审批不是逐行盖章

1. 把审批目标从“每行都看”改为“高风险项必看”

工时表常被当作一份需要主管逐条确认的记录。实际上，审批的价值在于确认数据是否可信、投入是否符合业务事实，以及异常是否得到处理。重复核对所有正常记录，既消耗管理者时间，也容易让真正重要的异常淹没在大量无差别的审批动作里。

我建议把审批分成两层：系统或规则先做完整性与逻辑校验，主管集中处理需要判断的例外。正常记录通过基础校验后进入快速确认；跨项目超时、休假日填报、任务状态不匹配、长期集中补录等情况则进入人工复核。审批的重点不是多看几行，而是把注意力放到可能改变资源决策的记录上。

2. 效率应同时看耗时、返工和数据可用性

只统计审批平均用时，容易制造“点得快就是效率高”的错觉。若审批人批得很快，但之后财务、项目经理和 PMO 还要反复修订，整体流程仍然低效。因此，我会至少同时观察审批周期、退回率、补录比例、人工核对耗时和报表可用率。

建议把效率定义为：在数据质量达到最低要求的前提下，完成一次月度关账所需的总人工时间。这里的“总人工时间”应包括员工填写、主管审批、PMO 纠错和财务追数，而不只计算审批按钮前后的等待时间。

3. PMO 应设计规则，而不是成为人工中转站

当 PMO 每月花大量时间帮员工补项目名称、统一任务写法、追主管确认时，问题通常不在执行者不够努力，而在流程把模糊规则留给了人工解释。PMO 的核心职责应是定义数据口径、确定例外处理路径、监测流程瓶颈，再通过复盘让规则逐渐稳定。

这并不意味着 PMO 不再接触记录。相反，PMO 要更有针对性地检查：哪些错误反复出现、哪些团队总在截止日集中补录、哪些项目缺少可选任务、哪些审批人形成流程瓶颈。把重复问题转成规则，才是可持续的效率提升。

二、背景和真实场景：为什么月底总会变成“数据救火”

1. 多项目并行时，工时记录承载不止一种用途

在中大型组织里，工时数据可能同时用于项目投入分析、成本分摊、资源规划、客户结算和审计留档。不同用途对精度的要求并不相同：资源规划可能需要周级别的投入趋势，成本核算可能要求项目和成本中心准确，客户结算则可能要求任务说明与合同范围对应。

因此，“每人每天填几小时”只是表面问题。真正的设计问题是：组织要用这些记录回答什么问题？如果目标只是团队负载趋势，过细的任务拆分会增加维护成本；如果要支持可审计的成本归集，则必须明确项目、工作类型、日期和审批责任。

2. 月末集中补录会把小问题放大成关账问题

员工如果在月底一次性回忆整月工作，容易出现日期偏移、任务描述笼统、跨项目投入估算不一致等问题。主管也很难凭印象确认几周前某项工作具体投入了多少时间。记录越晚，校验越依赖人的记忆，返工就越容易发生。

我通常会把“提交及时性”当成数据质量的前置条件，而不是行政纪律。及时记录降低回忆误差，也让项目经理有机会在投入偏离计划时调整安排。可操作的做法是按周提醒、按周校验、按月锁定，而不是等到月底再发一次全员催办。

3. 例子：多团队交付组织的月度工时关账

以下案例是为说明方法而构造的情景模拟，不代表某家企业的实测结果。假设一个约 240 人的产品与交付组织，包含 12 个项目团队，月末每人需提交工时，项目经理负责确认，PMO 负责抽查与汇总。

流程改造前，员工常在月末最后两天集中补填；项目名称由员工自由输入，审批人收到的是长列表，缺少任务状态和休假信息的关联校验。PMO 每月需要集中清理重复项目名称、追问异常投入并处理退回记录。问题不是审批角色太少，而是审批前缺少可执行的判断条件。

4. 工具只能承接流程，不能替组织决定口径

工时审批可通过表单、项目管理平台、流程系统或专用工时模块承接。以 PingCode 这类面向中大型企业与百人以上组织的项目管理平台为例，适不适合用来承接工时相关流程，不能仅凭产品名称判断；需要核对当前版本、配置能力、权限模型、数据导出方式，以及它是否能与组织已有项目和人员口径对齐。

我会先拿一条真实业务链路做小范围验证：员工能否选到正确项目与任务，主管能否看到必要上下文，PMO 能否追踪异常，关账后能否导出可复核的数据。若工具只能接收一个孤立表单，却无法关联组织实际使用的项目结构，流程自动化也可能只是把错误数据更快地传下去。

三、常见误区：看似加严，实际增加了管理摩擦

1. 误区一：审批层级越多，数据越准确

多加一层审批，不会自动带来更高准确率。如果第二位审批人看不到项目进展、任务说明或异常原因，只是重复点选同意，组织得到的是更多等待时间，而不是更多证据。审批层级应按责任边界设置，不应把“有人签字”误当成“有人验证”。

我的判断标准是：每一个审批角色都必须能够回答一个独立问题。例如，项目负责人确认投入是否符合项目事实；成本责任人确认归集口径；PMO 维护规则并处理例外。若两个角色检查的是同一字段、同一风险，就应考虑合并或改为抽查。

2. 误区二：要求每天填写，就能消灭异常

频繁填报有助于减少回忆误差，但前提是填报动作足够轻、任务选择足够清楚。若员工每天要打开多个页面、手工搜索项目、重复输入同类说明，形式上的每日填报会很快退化为批量补录。

更稳妥的办法是依据业务节奏设定最低频率：项目变化快、客户结算严格的团队可以日填或隔日填；工作节奏稳定、只用于宏观负载分析的团队可以按周填。规则应该由数据用途决定，而不是所有部门套用一个强度。

3. 误区三：退回率低，代表填报质量高

退回率低可能有两种完全不同的解释：员工填得准确，也可能是审批人不愿退回、规则过于宽松或系统没有暴露异常。只有把退回原因、关账后更正、抽查差异和异常记录覆盖率放在一起看，才能判断质量是否改善。

如果审批人为了赶进度直接批量通过，退回率可能下降，但事后更正率会上升。PMO 应监控质量闭环，而不是把单一指标变成考核目标，否则流程参与者会围绕指标优化动作，而不是优化数据。

4. 误区四：把所有异常交给 PMO 手工判断

PMO 熟悉流程，但未必了解每条业务记录的上下文。若所有异常都进入 PMO 队列，PMO 就会变成事实上的二级审批中心，业务负责人反而失去责任。规则明确的异常应由对应责任人处理，PMO 负责定义规则、分析趋势并处理跨团队口径争议。

可以把异常分为三类：员工可自行修正的格式问题；项目负责人需确认的业务问题；涉及跨部门规则或成本归属的治理问题。队列分流的质量，通常比“PMO 多看几遍”更能决定整体效率。

5. 误区五：用工时总量直接评价个人产出

工时是投入记录，不是产出质量的替代指标。一个人填了很多小时，可能是在处理复杂工作，也可能是流程阻塞、返工或估算偏差；工时较少也不必然代表贡献较低。把工时排名直接用于个人绩效，容易诱发过度填报和任务拆分膨胀。

更合理的用法是结合项目阶段、交付结果、计划偏差和工作类型分析团队投入。PMO 应在制度中明确数据用途与访问范围，尤其要让员工知道哪些字段用于资源计划、哪些用于成本归集，避免工时数据被模糊地扩展到未经说明的评价场景。

四、专业判断逻辑：先判断这条工时记录是否值得人工审批

1. 先定义数据用途，再决定字段和审批强度

我设计流程时，会先问四个问题：数据用于什么决策？错误的代价是什么？谁能验证正确性？数据需要保留到什么粒度？回答不同，审批策略就不同。若用于容量规划，周级项目投入可能足够；若用于合同结算，任务说明和客户项目归属就不能省略。

字段越多，理论上可分析的信息越多，但填报成本和维护成本也会提高。建议只采集能支撑明确决策的字段。一个字段若没人使用、没人维护、也不影响审计或资源决策，就应讨论删除，而不是因为“以后可能有用”而长期增加一线负担。

2. 用风险等级划分审核方式

审批不必只有“通过”和“退回”两种动作。可以把记录分为低、中、高风险：低风险满足完整性和常规范围，快速确认；中风险存在可解释偏差，由主管核实；高风险涉及制度、成本或资源冲突，暂停关账并要求补充依据。

3. 异常规则要区分“硬校验”和“提示”

硬校验适用于可以客观判断的条件，例如日期为空、人员不存在、项目已归档且不允许继续填报。提示规则适用于需要业务解释的偏差，例如某日工时超过团队常见范围、同一周跨项目数量显著增加。把所有偏差都设为禁止提交，会让系统阻塞合理的加班、紧急支持和跨项目协作。

阈值不能凭直觉永久固化。我倾向于先观察 4 至 8 周的实际分布，再按团队、岗位或项目类型设置提示区间。若一条规则每次都会触发，但绝大多数都被合理解释，说明规则需要调整；若规则很少触发却漏掉大量问题，说明校验条件或数据关联不足。

4. 把审批流程画成可追踪的状态，而不是口头约定

员工通常需要知道记录处于什么状态、下一步由谁处理、被退回后怎样修改、何时进入关账。流程状态至少要区分草稿、已提交、待审核、退回修改、已确认和已锁定。状态不清会带来大量“我提交了吗”“现在谁在处理”的沟通成本。

如果使用 PingCode 或其他项目管理平台承接相关流程，建议先验证平台能否按组织需要表达这些状态、配置相应权限与提醒，并能保留必要的修改记录。实际能力依产品版本和具体配置而异，实施前应通过试点验证，不应只根据宣传页面推定功能覆盖。

5. 优先处理流程瓶颈，不要只追个人提交速度

当审批周期变长，我会先拆分等待时间：员工填写用了多久、主管队列等待多久、退回修改用了多久、PMO 复核用了多久。若绝大多数时间耗在主管待办队列，继续优化表单帮助不大；若退回后反复往返，则需要改清晰度、示例或校验规则。

每月复盘时，可以给每个环节标注处理时间和责任角色，找出占总周期最大的节点。PMO 的首要改进对象应是瓶颈，而非最容易量化的环节。单纯压缩员工填报时间，可能把更多工作推给审批人；只有端到端总成本下降，才算真正提效。

五、可复用的审批方法与模板：把规则写成操作说明

1. 员工提交前检查模板

提交前检查应短到员工愿意读，且每一项都能指导具体动作。与其写“请认真填写”，不如写“项目必须从有效项目列表选择；当天投入分配到所有项目后需满足组织规定的总时数范围；无法匹配任务时先选择约定的工作类型并补充说明”。

• 日期是否对应实际工作日，是否误填到前一周或后一周。
• 项目与任务是否有效，是否使用组织统一的名称而非自行新建别名。
• 当天跨项目投入是否符合团队约定的记录方式。
• 休假、培训、内部支持等非项目工作是否按规定归类。
• 明显偏离常规范围的投入是否附有简短说明。
• 记录是否在团队规定的周期内提交，而非月底集中回忆。

2. 主管审批模板

主管不需要重新审阅员工每个字段背后的所有细节，但要对业务事实负责。建议审批界面或操作说明直接呈现关键上下文：项目与任务、投入日期、异常提示、最近一次状态变化，以及员工填写的说明。

• 项目与任务是否和团队实际工作一致？
• 异常投入是否有合理业务解释，是否需要调整任务归属？
• 记录是否存在明显重复、跨期错填或与休假安排冲突？
• 是否需要退回补充信息，还是可以确认并留存说明？
• 若是跨团队或成本口径争议，是否指派了明确的下一步责任人？

3. PMO 月度检查模板

PMO 的月度检查不应变成逐行复核全员记录。更有效的方式是抽查高风险项、关注异常分布，并把发现的问题归类到流程规则、数据维护、团队执行和工具配置四类原因。

4. 退回意见模板：指出错误，也给出修正路径

退回意见写“请修改”几乎没有操作价值。好的意见应该说明哪条记录有问题、违反了什么规则、需要提供什么信息，以及由谁确认。模板可以包含：记录日期、项目或任务、异常类型、所需补充内容、处理期限和联系人。

例如：“本周三的投入记录关联到已关闭项目。请确认该工作是否属于后续支持；若是，请补充支持任务或按团队规则选择维护类工作，并由项目负责人确认归属。”这样的意见比“项目不对，重填”更容易一次解决，也更利于后续统计退回原因。

5. 月度关账模板：用“完成条件”替代模糊催办

关账公告应说明统计范围、提交截止时间、审批截止时间、逾期处理方式、异常问题联系人以及关账后更正流程。不同团队如果使用不同日历或成本周期，也应显式注明，避免员工按自然月、主管按工作周、财务按结算周期各自理解。

• 本期记录覆盖的起止日期与适用人员范围。
• 员工提交和主管确认的具体截止时间。
• 缺少任务、项目关闭或跨部门投入的处理渠道。
• 逾期记录是否延后纳入报表，以及需要谁批准。
• 关账后更正的申请入口、审批责任人和留痕要求。

6. 不同工具场景下的配置检查项

若组织已有项目管理平台，可先检查能否复用项目、任务、成员和权限数据，避免再造一套项目主数据。若现有工具只适合简单表单，也可以用清晰的数据字典和导出校验降低风险，不必为了自动化而立即更换系统。

以 PingCode 等平台为例，试点时重点验证字段与项目结构的映射、提醒触发、审批状态可追踪性、权限隔离、修改留痕和数据导出质量。要把验证结果写下来，并区分“产品原生能力”“组织配置结果”和“人工补充步骤”；这能避免上线后把配置限制误当成业务规则。

六、具体案例与数据观察：怎样判断改造是否真的有效

1. 先建立改造前基线，不要上线后才挑指标

要判断改造效果，至少需要连续两到三个月的基线数据，记录提交时间、审批完成时间、退回原因、人工处理时间和关账后更正。若只保存每月平均耗时，无法判断问题来自单个团队、某一审批人，还是全组织的填报规则。

数据采集也不必一开始就复杂。可以先按团队、周次和异常类型做汇总，注意避免把个人工时细节暴露给无关人员。面向管理复盘的数据，通常团队级趋势比个人排名更有用；若确需个人级处理，应明确授权和用途。

2. 情景模拟：把规则前置后，成本可能从哪里减少

继续使用前述 240 人组织的情景模拟。假设月度记录约 4,800 条，每条记录原先平均发生 2.2 次人工触达，包括初次填报后的追问、退回或补充说明。通过统一项目选项、增加提交前完整性检查和按周提醒，目标是把大量低价值往返改成一次提交时修正。

若改造后人工触达次数降至每条 1.5 次，按每次触达平均 2.5 分钟估算，理论上可减少约 280 小时的月度触达时间。这个计算是用于规划试点的情景推演，不是实测收益；还没有扣除规则配置、培训、维护和异常复核新增的人力成本。

因此，试点报告不能只写“审批效率提升”。至少要把节省的员工、主管、PMO 时间分别列出，再扣掉流程维护和数据清理成本。若员工少花时间，但 PMO 多花同等时间做异常归一，整体没有净收益。

3. 用对照团队识别季节性和项目阶段影响

单纯比较上线前后可能受到项目收尾、人员变化、假期或季度关账影响。条件允许时，可以选两个工作类型相近的团队：一组先试点新规则，另一组暂时沿用旧流程。对比时观察相同周期内的审批时长、退回率和关账后更正率，并记录团队规模和项目阶段差异。

若无法设置对照组，至少要分层看数据：交付团队与产品团队分开，平稳期与发布期分开，正常记录与高风险记录分开。不同场景混在一起计算，可能让高强度项目把整体指标拉高，也可能掩盖某个部门的持续瓶颈。

4. 用分布而不是单一平均数读审批时间

审批周期通常存在长尾：多数记录一天内完成，少数记录因跨部门确认拖延一周。平均数会被长尾拉高，却不告诉 PMO 主要问题发生在哪里。建议同时报告中位数、较慢一成记录的时长和超期比例，便于区分快速路径与异常队列。

例如，中位审批时间从 3 天降到 2 天，但超期比例从 10% 升到 18%，说明典型记录变快了，最难处理的记录反而积压。此时应分析升级机制、责任人缺位和争议口径，而不是继续缩短所有人的审批期限。

5. 设定继续、调整或停止试点的判断门槛

试点开始前就要写明判断规则，避免上线后只挑有利结果。可以把目标分为三类：效率指标应改善，质量指标不能恶化，合规或权限要求必须达标。若效率上升但关账后更正率明显增加，说明流程只是把风险推迟了。

七、不同情况下的行动建议：先处理最影响决策的痛点

1. 人数较少、用途简单：先做轻量规范

若团队人数不多，工时只用于粗略资源规划，不必立刻设计多级审批或复杂自动化。先统一项目名称、填报周期、异常说明和审批责任，使用简单表单或现有工具就可能解决大部分问题。

轻量方案仍要保留数据字典和退回原因分类。没有这些基础，团队人数增加后，原本依赖口头沟通的规则会迅速失效。小团队的重点是把规则写清楚，而不是把流程做得像大企业一样复杂。

2. 百人以上、多项目并行：优先治理主数据与权限

当人员、项目和审批链路增多，单靠自由文本和人工汇总会很快失控。优先确认人员、项目、任务、成本中心等主数据由谁维护，过期项目怎样关闭，跨部门支持如何归属，以及哪些角色可查看明细。

对于百人以上组织，平台选型和流程配置应围绕数据关系、权限边界、历史留痕和报表导出验证。即使采用 PingCode 这类项目管理平台，也要先确认组织的真实流程能否落地，不要把“系统里有表单”误认为“工时治理问题已经解决”。

3. 客户结算或审计要求严格：提高证据留存强度

若工时记录直接影响客户结算、合同计费或正式审计，审批重点应从速度转向可追溯性。记录要能够说明谁提交、谁确认、何时修改、为何修改，以及修改前后内容的差异。任务说明和项目归属也需要与合同或成本规则保持一致。

这类组织可以接受更多高风险人工复核，但应把复核集中在影响结算的记录，而不是全面增加审批层级。并且要明确关账后变更的授权人和留档方式，避免已确认数据被无记录覆盖。

4. 工作高度不确定、跨项目频繁：采用弹性规则

研发探索、应急支持和跨团队协作，往往无法按固定任务计划准确分配投入。若流程强迫每小时绑定到过细任务，员工可能为了通过审批而制造虚假精度。对于这类团队，可允许使用约定的工作类别，并要求对显著偏差补充说明。

管理者应关注趋势和容量变化，而不是假设每条记录都能精确还原工作过程。对不确定性较高的工作，投入估算本身就有误差，应把误差边界和分析用途说清楚。

5. 现有数据质量很差：先收缩用途，再逐步扩展

如果历史记录中项目名称混乱、任务结构不完整、审批意见缺失，直接把数据用于精确成本分析风险很高。建议先限定一个可支持的用途，例如团队级容量趋势，再逐步修复主数据和审批留痕。

不要用自动化掩盖历史质量问题。先抽样识别错误类型，修复高频项目和关键字段；对无法可靠恢复的历史记录，明确标注口径限制。比起做一张看似完整但不可验证的报表，范围更小但可信的数据更有决策价值。

八、不同情况下的取舍：流程越严密，不一定越适合

1. 精细度与填报成本之间的取舍

记录到任务级，便于分析项目细节，却会增加选择和维护成本；记录到项目级，员工负担较低，但可能无法回答具体任务投入问题。取舍的判断依据不是“数据越细越好”，而是组织是否会基于更细的数据采取不同决策。

可以先选择最小可用粒度，运行一段时间后观察管理者是否持续提出更细的问题。如果报表很少被使用，就不应不断增加字段。只有当新增粒度能改变资源配置、范围管理或成本决策时，才值得承担持续填报成本。

2. 自动通过与人工复核之间的取舍

自动通过可以减少队列等待，但规则覆盖不了所有业务上下文；人工复核更灵活，却会受审批人时间和判断一致性影响。实际方案通常是常规记录快速通过、例外记录人工处理，并用抽查验证自动规则是否漏报。

若数据直接用于高风险结算，不宜为了速度把所有记录自动通过。若只用于团队趋势，过度逐条审批则可能成本过高。组织要按照错误后果设置自动化边界，而不是按照工具能否自动化来决定流程。

3. 周填与日填之间的取舍

日填更接近工作发生时间，记忆误差较小，但操作次数更多；周填能减少打断，却可能让员工在周末集中估算。决定频率时应考虑工作节奏、记录用途和员工使用成本，并在试点中观察逾期率与更正率，而不是以形式上的高频为目标。

一个实用方案是设置团队默认频率，同时为客户结算、发布冲刺或高风险项目增加更短周期的检查。频率不必永久固定，可以根据项目阶段调整，但应由明确规则触发，不要让每个主管临时制定一套个人标准。

4. 统一规则与团队差异之间的取舍

全组织统一规则有利于横向比较和财务汇总，但不同职能的工作结构可能差别很大。全部强行统一会造成大量例外；完全按团队自定义又会让数据无法比较。更可行的是统一核心字段、权限、状态和关账原则，同时允许工作类别和提醒节奏按团队配置。

PMO 需要明确哪些是不可变的治理底线，哪些是允许配置的执行细节。每个例外都应说明理由、适用范围和复核日期，防止临时例外长期积累为互不兼容的流程。

5. 短期提速与长期治理之间的取舍

临近关账时，人工集中清理可能是最快的救急方式，但不应被误认成长期方案。若连续几个月都靠 PMO 手工合并项目名、追问异常和补齐字段，说明流程在依赖隐性劳动，风险随着人员变动而增加。

短期可以先保障本期关账，再把重复问题转化为下月的校验规则、数据维护责任和培训内容。每次救火之后都应留下问题分类和改进责任人；没有复盘的救火，只会让同一成本在下个月再次出现。

九、下一步怎么做：用一个月完成可验证的小试点

1. 第一周：明确用途、口径和基线

选择一个业务边界清楚的团队，确认工时数据要支持的决策、所需字段、审批责任和关账规则。同步提取近两到三个月的数据，至少建立审批时长、退回原因、逾期比例、人工处理时间和关账后更正率的基线。

如果基线数据不完整，先标注缺口，不要补造数据。可以从本月开始建立统一记录，把数据质量本身作为试点的一个观察目标。

2. 第二周：做规则清单和最小化配置

把异常分为硬校验、提示和人工复核三类，先处理高频、低争议的问题。同步整理员工提交前清单、主管审批问题和 PMO 月度检查表，确保每条规则都有明确责任人和处理动作。

工具配置先做最小闭环：能提交、能看到状态、能退回补充、能记录修改、能导出数据。暂时不要追求复杂报表和全自动审批，避免把试点周期耗在低价值配置上。

3. 第三周：小范围运行并记录例外

让试点团队真实提交和审批，记录操作中出现的误解、等待和异常类型。每次规则触发都要判断它是发现了真实风险，还是制造了不必要的阻塞。对合理例外不要急着加新流程，先核实业务场景是否具有代表性。

试点期间保留人工兜底，但要把兜底时间也记录下来。否则试点看起来顺利，实际上可能是 PMO 在后台手动补了大量工作。

4. 第四周：复盘净收益并决定扩展边界

比较试点前后的总人工时间、处理时长分布、一次通过率、关账后更正和使用反馈。若只有速度提升而质量变差，应先调整规则；若员工体验改善但 PMO 工作增加，应重新分配数据维护责任；若指标改善且质量稳定，再逐步扩展到相似团队。

我的最终判断是：工时审批的成熟度，不取决于审批人有多少，也不取决于表单有多少字段，而取决于组织能否把业务事实转成清晰规则，把低风险记录快速通过，把高风险记录交给真正有能力判断的人。

5. 试点结束后的持续治理清单

• 每月检查退回原因，识别是否有高频问题可以前置校验。
• 每季度复核项目与任务主数据，清理失效选项和重复名称。
• 按风险抽样复核自动通过记录，观察漏报与误报变化。
• 跟踪关账后更正，区分流程问题、业务变化与数据维护问题。
• 调整规则时同步更新员工说明、主管指南和 PMO 检查表。
• 按数据用途审查访问权限，避免工时明细被无边界复用。

下一步不必先采购工具，也不必先重写整套制度。先选一个团队，拿出真实基线，明确三类异常和各自责任人，再试运行一个关账周期。若试点能同时降低总人工时间、保持数据质量并减少月末救火，才值得扩大；若只是把追催工作从员工转给 PMO，就应回到流程设计重新取舍。