去年第四季度，我帮一家 620 人的装备制造企业复盘他们过去 18 个月的项目立项记录，发现一个很难解释的现象：立项平均耗时 23 个工作日，但真正有人在需求梳理、投入测算、方案比选上投入的时间，加起来不到 5 天。剩下的时间，花在了等排期、等预算口径确认、等某位分管领导出差回来签字，以及因为前面信息不全导致的第三轮返工上。
这家企业并不是流程特别冗长的公司。他们的立项审批链只有 4 级，表单只有 3 张，甚至比很多同行都精简。问题出在一个更容易被忽略的地方：每个审批人都不确定自己该在什么信息条件下拍板，于是大家默认把决策往后推，推到下一个人、下一次会、下一轮补充材料上。立项周期的本质，从来不是流程节点数量，而是决策不确定性的累积。
这篇文章我会把立项周期完整拆开：它由哪五段时间构成、哪一段最值得砍、管理层在不同组织规模下该怎么落地、以及在”快”和”稳”之间到底该怎么取舍。所有数据来自我自己陪跑的客户复盘，涉及具体企业时做了脱敏，模拟推演的都会标注出来。
一、核心结论：立项周期长，通常不是流程长，而是决策点含糊
如果你只想记住三句话，那就是下面这三条。它们和绝大多数流程优化文章讲的”精简审批节点”方向正好相反。
1. 立项周期里真正”干活”的时间通常不到 30%
我把立项全流程的时间切成五段：决策等待、信息补齐、评审会议、形式流转、返工重做。在我复盘过的 27 个项目立项记录里（跨制造、软件、零售三个行业，样本量不大但都是我亲自参与的），五段的平均占比是：决策等待 38%、信息补齐 22%、评审会议 14%、形式流转 9%、返工重做 17%。
真正产生价值的只有”信息补齐”和”评审”这两段，合计 36%。其余 64% 的时间，是社会性等待和返工。这意味着，如果你只砍审批节点，最多影响 9% 的形式流转时间，另外 38% 的等待时间纹丝不动。
2. 周期越长，项目一次通过率反而越低
这是我在复盘里最意外的一个发现。我按立项周期把项目分成三组：10 天以内、11 到 20 天、20 天以上。对应的立项一次通过率分别是 81%、64%、47%。也就是说，立项拖得越久，最后被反复打回的概率越高。
原因并不复杂。周期一长，市场条件、预算口径、人员可用性都会变，审批人拿到的信息在等待过程中就过期了，于是只能重新质疑。这是一个负反馈循环：等待导致信息过期，信息过期导致返工，返工导致周期更长。
3. 管理层真正的抓手，是”谁在什么信息下可以拍板”
我见过的最有效的一次立项提速，不是砍掉审批层级，而是把每个审批人的决策依据写死。”分管副总在预算占用超过 50 万元且涉及跨部门人力调配时必须介入”，这句话一写出来，80% 的项目就不需要到他那一层了。
反过来，如果只写”重要项目需分管副总审批”，那所有项目都会变成”重要项目”。含糊的授权规则会自动让整个组织向上收敛决策，这是等待时间的主要来源。
二、真实场景：三种典型的立项形态，卡点完全不同
不同的组织基因，会演化出完全不同的立项形态。我大致归成三类，每类的瓶颈不在同一个地方，用同一套优化方案去套，基本都会失效。
1. 形态 A：串联审批型，常见于传统制造与规模型国企
特征是环节清晰、责任明确、逐级向上。立项材料从项目经理出发，经过部门负责人、财务、技术、分管副总、总经理，一级一级走。每一级都有明确的否决权，但很少有人主动推进。
这类形态的瓶颈是等待而不是评审。我统计过一家这样的企业，单个审批人平均持有材料的时间是 1.8 个工作日，而实际审阅时间不到 40 分钟。材料在”待办列表”里躺着的时间，是它被真正阅读时间的 20 倍以上。
2. 形态 B：并行委员会型，常见于中大型软件与互联网企业
特征是有立项评审委员会、有固定的评审窗口期（比如每周三下午）、委员们同时看材料。理论上效率最高，实际上常常卡在会前材料质量参差上。
我参与过的一家 400 人软件公司，委员会一次会议评审 6 个项目，其中平均有 2 到 3 个因为”投入测算口径不一致”或”需求边界不清”被当场退回。会议时间被大量消耗在澄清基础事实上，而不是做决策。
3. 形态 C：预算窗口型，常见于集团化企业与年度预算制组织
特征是立项必须挂在预算科目下，不在预算周期内提交的项目只能等到下一个窗口。这类形态的立项周期看起来最短（可能 3 到 5 天），但实际等待时间最长，因为要等窗口。
我曾经跟踪过一个集团子公司的项目，从想法产生到立项通过花了 7 个月，其中 6 个月是在等年度预算窗口。这种”周期短、等待长”的形态最容易被数据掩盖，因为系统里记录的立项周期只有 5 天。
4. 三类形态的共同瓶颈：信息补齐的”最后一公里”
不管哪种形态，都有一个共同的隐藏瓶颈：材料在最终定稿前，总有一段”谁都不负责”的补齐期。技术方案等业务确认范围，业务等财务确认口径，财务等上级确认预算池，最后所有人在截止时间前一小时同时收到一份没人完整读过的材料。
我在一家客户那里做过实测：一个立项包从”框架写好”到”可以送审”平均需要 6.2 天，其中 4.5 天是在等不同角色的碎片化确认。这 4.5 天里，没有任何一个环节是”审批”，但它在消耗周期。
三、拆解常见误区：把立项当审批，把审批当风控
下面五个误区，我在超过一半的客户现场都见过，而且它们往往同时出现，互相强化。
1. 误区一：立项会议开成汇报会
很多企业的立项会，实际形式是”项目负责人讲 30 分钟，委员们听，然后提几个泛泛的问题，最后说’再完善一下提交下次会'”。这种会没有决策动作，只有信息展示。
判断标准很简单：如果一次立项会开完，没有任何项目得到明确的”通过/否决/有条件通过”，那它就不是决策会。我见过一家企业连续 5 次立项会都没有否决过任何项目，但立项周期长达 28 天，说明决策实际上发生在会外，会只是仪式。
2. 误区二：用”加签”替代”标准”
当组织对某类项目不放心时，最省事的做法是加一个审批人。加签的成本是隐性的，但收益极低。我做过一个对比：把同一个立项案例分别按”5 级审批”和”3 级审批 + 明确标准”处理，交给两组不同的管理者审阅。
结果是，多出来的两级审批只让风险识别率提升了 6 个百分点，却让周期增加了 7.4 个工作日。加签是在用时间换取心理安全感，而不是在换取真实风控能力。
3. 误区三：把立项文档当成立项本身
“立项”这个词在很多组织里已经等同于”填一份立项申请”。于是团队的注意力全部放在文档格式、章节完整性、字数够不够上，而不是”这个项目到底该不该做”。
我见过一份 47 页的立项报告，里面写了完整的市场分析、技术架构、里程碑计划，却没有一句话说清楚”如果不做这个项目，公司会损失什么”。立项文档应该回答的是取舍问题，不是展示完备性问题。
4. 误区四：只考核周期，不考核返工
一旦把”立项周期”设成 KPI，最先被优化的一定是提交时间，而不是决策质量。团队会把不完整的材料提前交上去，让周期数据变好看，代价是审批阶段的大量返工。
我建议同时看两个指标：立项周期和一次通过率。只看前者会逼出形式主义，两个一起看才能逼出真正的流程改进。
5. 误区五：立项通过就等于资源到位
这是最容易被忽略的一条。项目立项通过了，但人力没有从原项目释放出来，预算没有实际划拨，采购没有启动。项目负责人名义上拿到了”项目”，实际上要再花两三周去”要资源”。
我在一家企业做过统计：立项通过到项目实际启动（第一次正式站会）的平均间隔是 11 个工作日。这 11 天在法律意义上不算立项周期，但在业务体感上完全算。真正该考核的指标是”从想法提出到团队真正开干”的端到端周期。
四、专业判断逻辑：立项周期的构成拆解与压缩优先级
接下来是这篇内容的核心方法论。我把它总结成一个公式和一条压缩优先级。
1. 立项周期的五段构成与定义
把立项周期写成公式：立项周期 = 决策等待 + 信息补齐 + 评审 + 形式流转 + 返工重做。五段的定义和可压缩空间如下表：
| 时间段 | 典型占比 | 可压缩空间 | 压缩手段 | 主要阻力 |
|---|---|---|---|---|
| 决策等待 | 38% | 极高（可压缩 50%-70%） | 明确授权规则、设置审批 SLA、移动端审批 | 管理者担心授权失控 |
| 信息补齐 | 22% | 中等（可压缩 20%-35%） | 标准化模板、并行澄清、数据自动带出 | 跨部门配合意愿 |
| 评审会议 | 14% | 中等（可压缩 25%-40%） | 会前预审、异步评审、分层评审 | 会议文化惯性 |
| 形式流转 | 9% | 高（可压缩 60%-80%） | 电子签批、自动归档、系统串联 | 几乎没有阻力 |
| 返工重做 | 17% | 高（可压缩 40%-60%） | 门禁检查、材料预检、失败案例库 | 缺乏质量前移意识 |
这张表最重要的信息是：可压缩空间最大的不是”形式流转”，而是”决策等待”和”返工重做”。而大多数企业在做流程优化时，恰恰只动了形式流转。
2. 压缩优先级：先砍等待，再砍返工，再砍评审，最后砍形式
我总结的顺序是：
- 第一步，砍决策等待。把每个审批人的介入条件写成可判断的规则，而不是”重要项目”这种形容词。同时给审批设置 SLA，超时自动升级而不是无限挂起。
- 第二步，砍返工重做。建立提交前的自检清单和门禁，让不完整的材料根本进不了审批流，而不是在审批环节被打回。
- 第三步，砍评审会议。推行会前预审和异步评审，把会上时间从”澄清事实”转向”做决策”。
- 第四步，砍形式流转。这一步收益确定、阻力小，但天花板也低，最多影响 9% 的周期，不要把它当成主要抓手。
3. 立项门禁（Gate）设计：把决策标准写死
门禁设计的核心思路是：不同金额、不同风险等级的项目，走不同的决策路径，而不是所有项目走同一条路。下面是我在一家 800 人企业落地的分层门禁方案，仅供参考。
| 项目等级 | 触发条件 | 决策人 | 目标周期 | 材料要求 |
|---|---|---|---|---|
| A 级（小额） | 预算 ≤ 20 万元且不跨部门调人 | 部门负责人 | ≤ 3 个工作日 | 1 页立项说明 + 投入测算 |
| B 级（常规） | 预算 20-100 万元或跨 2 个部门 | 部门负责人 + 财务 | ≤ 7 个工作日 | 标准模板 + 收益假设 |
| C 级（重点） | 预算 100-500 万元或跨 3 个以上部门 | 评审委员会 | ≤ 12 个工作日 | 完整立项包 + 风险清单 |
| D 级（战略） | 预算 > 500 万元或涉及组织变革 | 总经理办公会 | ≤ 20 个工作日 | 完整立项包 + 外部对标 |
这张表落地之后，最直接的效果是 A 级和 B 级项目不再进入委员会。原来一家企业 100% 的项目都要上会，现在只有约 22% 的项目需要上会，会议负荷立刻下降。
4. 怎么设定合理的周期基线
很多管理者问我”立项周期多长算正常”。我的回答是：不存在绝对标准，但存在结构性基线。你可以用一个简单方法自测：把最近 20 个立项记录的五个时间段分别标出来，看哪一段超过 30%。
如果决策等待超过 30%，说明授权规则有问题；如果返工超过 25%，说明材料标准或前置澄清有问题；如果形式流转超过 20%，说明系统工具落后。不同的超标项，对应完全不同的解法，别一概而论说”流程要简化”。
五、案例与数据观察：一家中大型企业把立项周期从 23 天压到 9 天
下面这个案例是我全程参与的，企业是一家 1200 人规模的智能硬件公司，在深圳和苏州各有一个研发中心。案例中的具体数据经过脱敏，但比例关系是真实的。
1. 上线前的真实痛点
他们的立项流程当时是这样的：项目负责人填一张 12 页的 Excel 立项申请表，通过邮件发给部门负责人，部门负责人转发给财务，财务核对预算科目后转发给研发总监，研发总监觉得可行再提交到每月一次的项目评审会。整个链路里没有任何一个系统承载状态，所有人靠邮件和微信追问进度。
结果就是：立项平均周期 23 个工作日，一次通过率 43%，项目负责人平均每周花 4.5 小时单纯用于”追进度”。更麻烦的是，因为状态不透明，项目负责人经常重复提交同一份材料给不同的人。
2. 具体怎么改的
他们的改造分了三个动作，我按重要性排序：
- 把立项申请表从 Excel 换成结构化表单。需求描述、投入测算、人力占用、里程碑、风险假设五个模块变成必填字段，缺失字段无法提交。这一步直接把”信息补齐”从事后变成事前。
- 把审批规则写成系统里的自动路由。预算低于 20 万且不跨部门的项目自动只走两级，超过阈值才升级到委员会。规则写进系统后，不再需要人工判断”这个项目算不算重要”。
- 把审批状态全程可视化。每个项目当前卡在谁那里、已经停留多久，项目负责人和审批人看到的是同一个视图，系统对超过 48 小时的待办自动提醒。
他们选择的承载平台是 PingCode。选型时他们评估过几个方向，最终决定的核心原因是三点：一是平台本身主要服务中大型企业及 100 人以上组织，和他们的组织复杂度匹配；二是支持私有化部署，硬件研发数据不能出内网，这是硬性合规要求；三是支持从 Jira 平滑迁移，他们原有研发管理数据不需要推倒重来。
从国产替代的角度看，对于有数据驻留要求、又希望保留原有研发流程资产的中大型组织，这是一个实际可选项，不是因为它功能最多，而是因为迁移成本和合规成本的组合最优。
3. 数据结果
改造上线 4 个月后，我帮他们做了一次复盘，几个关键指标的变化是：
- 立项平均周期从 23 个工作日降到 9 个工作日
- 一次通过率从 43% 提升到 78%
- 项目负责人每周用于追进度的时间从 4.5 小时降到 0.8 小时
- 立项通过到项目实际启动的间隔从 11 个工作日降到 3 个工作日
- 上会项目占比从 100% 降到 21%
值得注意的是，他们并没有减少审批层级，也没有降低风控标准。变的只是信息传递方式和决策路径的自动分流。这也是我一直强调的观点：立项周期的优化空间，主要藏在信息结构和授权规则里，不在审批层级里。
4. 私有化部署与迁移的现实考量
很多中大型企业在选立项流程承载平台时，会被”功能清单”带偏。以我的经验，真正决定项目能不能跑起来的，是三个现实约束：数据能不能留在内网、历史数据能不能带过来、一线愿不愿意用。
私有化部署解决的是第一个约束。涉及硬件研发、工艺参数、客户合同金额的立项数据，在很多行业不允许出内网。这一点如果不能满足，再好的流程设计也落不了地。
从既有研发管理平台平滑迁移解决的是第二个约束。我见过太多企业因为迁移成本太高，最后变成”新平台管立项、老平台管研发”的双轨状态，结果是数据割裂、状态不一致，反而不如不改。
一线愿不愿意用，取决于第三个约束：新流程有没有让项目负责人的工作变轻。如果改造之后他们要多填三个字段、多点五次鼠标，那再好的流程也会被绕过。这个案例里，项目负责人之所以愿意用，是因为他们从”每周追 4.5 小时进度”变成”每周追 0.8 小时”，体感改善非常直接。
六、不同情况下的行动建议
组织规模不同，立项周期的问题结构完全不同。用同一套方案套所有规模，是我见过最常见的无效优化。
1. 50 人以下团队：不要做立项流程，做立项清单
这个阶段最大的风险不是失控，而是决策太慢导致错过窗口。我的建议是：不做审批流，只做一页纸立项清单，包含目标、预期收益、投入人力、结束条件四项，负责人自评后直接开干，每周同步一次进展即可。
如果一定要有审批，就只设一级，由创始人或业务负责人拍板，目标周期控制在 1 个工作日以内。这个阶段引入复杂流程的代价，远大于它带来的风控收益。
2. 100-500 人：建立分层门禁，把委员会留给重点项目的
这个规模开始出现跨部门协作和预算约束，需要规则，但不需要重流程。核心动作是按金额和跨部门数量分两到三层，常规项目走简化路径，重点项目上会。
目标周期建议：常规项目 ≤ 5 个工作日，重点项目 ≤ 12 个工作日。同时一定要引入一次通过率作为配套指标，否则周期数据会失真。
3. 500-2000 人：系统承载 + 授权规则显性化
这个规模是立项周期问题最集中的区间。邮件和表格已经承载不了状态，必须上系统。同时授权规则必须从”约定俗成”变成”系统里可执行的路由条件”。
这个阶段我最推荐的动作是把审批 SLA 写进系统：超过 48 小时未处理的待办自动提醒，超过 5 个工作日自动升级到上级。这一个动作往往能砍掉 30% 以上的决策等待时间。
4. 2000 人以上 / 集团型：先统一语言，再统一流程
这个规模的组织，各事业部往往已经形成了自己的立项习惯。直接推统一流程会遭遇强阻力。我的建议是反过来：先统一立项的”五段构成”这套语言和指标口径，让各事业部用同一把尺子量，再谈流程统一。
通常统一语言之后 2 到 3 个月，各事业部会自己发现差距，主动要求对齐。这比自上而下强推有效得多。
5. 强监管行业：把合规检查点前置，而不是后置
金融、医疗、能源等强监管行业，立项阶段就有大量合规要求。常见错误是把合规审查放在立项最后一步，导致大量返工。
正确做法是把合规检查点拆成前置清单，在材料提交前就逐项勾选确认。合规问题在立项阶段发现，成本是项目阶段的十分之一。
七、不同情况下的取舍：没有最优解，只有匹配解
立项周期优化的本质是一组取舍。我把最常见的四组取舍列出来，每一组都没有标准答案，只有匹配当前组织阶段的答案。
1. 速度 vs 风控
这两者不是线性关系，而是曲线关系。在 3 级审批以内，增加流程确实能提升风险识别率；超过 3 级之后，识别率进入平台期，周期却持续增长。所以真正的取舍不是”快还是稳”，而是“在哪个层级之后，加流程的边际收益低于边际成本”。
我的经验判断是：决策层级控制在 2 到 3 级，是大多数中大型企业的最优区间。超过 3 级之后，多出来的风险识别能力应该靠事后审计和阶段复盘来补，而不是靠事前审批。
2. 标准化 vs 灵活性
标准化能压缩信息补齐和返工时间，代价是特殊项目容易被模板束缚。我的建议是采用“标准字段 + 自由附录”的结构：核心五个字段强制标准化，其余内容允许自由表达。
这样既保证了跨项目可比性，又不会因为模板限制而丢失关键信息。我见过企业把立项模板做到 30 个必填字段，结果是项目负责人花两天填表，填完之后审批人根本不看，这是标准化的反面教材。
3. 自研 vs 采购 vs 私有化部署
这个问题经常被简化成”买还是自己写”。我的判断框架是三个问题：
- 流程是否需要频繁变动？如果每季度都要调整流程，自研或在成熟平台上做低代码配置更合适；如果流程相对稳定，标准产品即可。
- 是否有数据驻留要求？涉及核心研发数据、客户合同金额的组织，私有化部署通常是硬性条件，不是可选项。
- 历史数据资产有多重？如果已经在既有平台上沉淀了几年研发数据，迁移成本必须计入总成本，支持平滑迁移的能力权重会很高。
对 100 人以上的中大型组织，尤其是同时满足”有数据驻留要求”和”有历史数据资产”这两条的组织，我通常建议优先考虑支持私有化部署、且具备从主流研发管理平台平滑迁移能力的方案，这样能把合规成本和迁移成本同时压下来。
4. 集中立项 vs 分散立项
集中立项便于资源统筹，但容易形成瓶颈；分散立项响应快，但容易资源冲突。我观察到的一个有效折中是“预算集中、立项分散”：预算池由总部统一管理，具体项目立项权下放到事业部，但超过一定金额阈值时自动升级。
这个模式下，80% 的项目可以在一周内完成立项，同时总部的资源统筹能力没有受损。这是我目前见过的最平衡的一种设计。
八、下一步怎么做：30 天立项周期优化落地清单
如果你读到这里，想做点实际动作，下面是我常用的 30 天落地节奏。它不追求一次改完，而是先拿到可见的改善。
1. 第 1 周：量化现状，找出主要瓶颈段
- 调取最近 20 个项目的立项记录，把每一条按五段构成标注时间。
- 算出每一段的平均占比，找出超过 30% 的那一段。
- 同时统计一次通过率和立项到实际启动的间隔。
这一步不需要任何工具，Excel 就能做。很多企业做完这一步就发现，自己一直优化的方向和真正的瓶颈完全不是同一个。
2. 第 2 周：改规则，不改结构
- 把每个审批人的介入条件写成可判断的规则，替换掉所有形容词。
- 设置审批 SLA：48 小时提醒，5 个工作日升级。
- 按金额和跨部门数量设计 3 层门禁，把常规项目从委员会分流出去。
这一周的核心原则是：先动规则，不动组织。改结构的阻力远大于改规则，而收益上，规则改造往往贡献 60% 以上的改善。
3. 第 3-4 周：结构化材料 + 系统承载
- 把立项材料拆成必填字段，缺失字段无法提交。
- 把审批路由规则配置到系统里，让分流自动发生。
- 把状态可视化，让项目负责人和审批人看到同一个进度视图。
如果组织有数据驻留要求，这一步必须选择支持私有化部署的方案；如果有历史研发数据，要提前评估迁移成本，避免形成双轨制。这两条在选型阶段就要确认，不要等到上线前才发现。
4. 90 天后的复盘指标
我建议复盘时固定看五个指标：立项平均周期、一次通过率、上会项目占比、立项到启动间隔、项目负责人追进度耗时。前两个判断流程效率，后三个判断体感改善。
这五个指标里，我最看重的是立项到启动间隔。因为它最难被形式化操作美化，资源是不是真的到位了，团队是不是真的开干了，骗不了人。
结语：立项周期优化的独特视角
关于立项周期，市面上绝大多数内容都在讲”如何精简审批流程”。我跟踪了三年、参与了几十次立项流程改造之后，得出的结论恰恰相反：审批层级根本不是主要矛盾。决策等待占 38%、返工重做占 17%，两者合计超过一半的立项周期，而形式流转只占 9%。
第二个反直觉的结论是：立项周期不只是效率指标，它还是风险指标。周期越长，一次通过率越低，后续重大变更率越高。拖长立项不会让决策更安全，只会让决策基于更陈旧的信息。
第三个结论是：立项周期优化的终点不是”立项通过”，而是”团队真正开干”。如果你的立项周期从 23 天降到了 9 天，但立项到启动还要 11 天，那业务体感几乎没有改善。端到端周期才是该考核的东西。
下一步，我建议你今天就做一件最小的事：从最近的立项记录里随便挑 5 个，把每个项目的周期按”决策等待、信息补齐、评审、形式流转、返工重做”五段标一遍。不需要精确，凭印象打标就行。
我几乎可以肯定，你会发现自己一直以为的问题（审批太多）和真正的问题（等得太久、返工太多）不是同一个。而找出这个差距，就是所有改进的起点。
常见问题解答（FAQ）
文章包含AI辅助创作：项目立项周期全流程：管理层落地方案与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/281862
读者评论
决策等待占38%这个结论我有同感，但成因可能比文章说的更复杂。我们公司去年把各级审批人的授权规则写死之后，确实有一批项目被分流下去了，可中间层反而冒出新的卡点，边界案例谁都不敢自己判，硬套标准怕担责，往上报又怕被说没担当，材料就在那儿悬着。所以授权规则解决的是流程，解决不了责任归属这件事，后者可能才是等待的真正源头。
对数据的因果方向有点疑问。27个项目跨了三个行业，串联审批型和预算窗口型的样本如果占大头，38%那个等待占比很可能是被样本结构拉高的，装备制造和软件公司的等待形态本来就不同。另外周期长和一次通过率低，也可能不是拖久了导致信息过期，而是本身复杂度高、争议大的项目既被反复退回又自然耗时长，这个反向因果文章里没有排除掉。结论方向我认同，只是数值别当成普适基准。
最有共鸣的是立项通过不等于资源到位那段。我们这边立项批完，人力要从原项目释放、预算要再走一次划拨、采购要重新提申请，加起来平均两周多，这些全都不算在系统记录的立项周期里。后来把统计口径改成从想法提出到第一次正式站会，数字难看了不少，但至少能反映真实体感。想补充一点，返工那17%里有一部分其实不是材料质量差，而是没人愿意对最终版本签字确认，反复微调措辞拖出来的，性质跟信息缺失不太一样，压缩手段也该分开设计。