发布审批怎么做？PMO入门指南：发布管理从0到1

去年 11 月，我参与了一家 320 人规模 SaaS 公司的发布流程复盘。他们的发布审批走 OA，一张单子 7 个节点，平均流转 2.6 天。我们把过去 6 个月的 214 次发布和 37 起线上事故做了交叉比对，结果很难看：37 起事故对应的发布里，有 32 起的审批单是 7 票全过，没有任何一位审批人在意见栏里提出问题或附加条件。

这不是审批人失职，而是审批设计失效。当一张单子上的信息不足以支撑判断时，签字就只剩下一个功能，分摊责任。PMO 从 0 到 1 搭发布管理，最容易犯的错就是把"发布审批"理解成一张需要被点通过的流程单，而不是一套让风险在发布前被迫显形的机制。

这篇文章不复述发布流程有哪些环节，而是回答三个更实际的问题：发布审批到底应该审什么、审批节点该设几个、以及在没有足够人手的情况下，PMO 怎么用最小成本让这套机制真正拦住问题。文中数据来自我参与过的 6 个团队复盘样本，涉及 500 人以下研发组织的公开发布记录，其中部分为脱敏后的区间估算，我会标注清楚。

一、先给结论：发布审批不是"把关"，是"授权"

很多 PMO 新人拿到"做发布管理"这个任务，第一反应是设计一张尽可能全面的审批表，然后把能想到的角色都拉进审批链。方向从一开始就偏了。发布审批的本质是授权，不是把关。把关意味着审批人要对发布结果负责，授权意味着审批人只对"授权条件是否满足"负责。

1. 发布审批真正产出的三样东西

我在做流程诊断时，会先问一个很朴素的问题：这次审批结束后，组织多知道了什么？如果答案是"什么都没多知道，只是多了一个签名"，那这条审批链就是纯成本。

一条设计合理的发布审批，应该稳定产出三样东西：

• 变更事实的完整披露：这次发布改了什么、影响谁、影响多大、有没有不可逆动作。注意是"事实"不是"描述"，"优化查询性能"是描述，"新增联合索引 idx_order_created，涉及订单表 1.2 亿行，采用 online DDL，预计锁表风险中"才是事实。
• 失败路径的预先约定：回滚怎么做、多久能回滚完、什么指标触发回滚、谁有权按下回滚按钮。这一条是审批单里最容易被写废的部分。
• 责任边界的明确转移：发布前风险由研发和测试承担，发布窗口内由发布负责人承担，发布后观察期由运维和值班人承担。审批的价值是把这条边界说清楚，而不是把所有人绑在一起。

2. 审批不该审"能不能发"，该审"发砸了怎么办"

这是一个我认为最关键的认知转换。"能不能发"是个技术判断，审批人大概率不具备判断能力，也不该承担这个判断。而"发砸了怎么办"是个管理判断，恰恰是审批人最该确认的。

所以我在设计审批单时，会把"验证证据"和"回滚方案"放在最前面，把"功能说明"压缩到一行。审批人真正需要确认的是：证据够不够、兜底有没有、兜不住的时候谁拍板。至于功能本身好不好，那是需求评审和测试环节的事，不该在发布审批里重审一遍。

3. 一个可操作的判断标准：这条审批有没有改变过决策

判断一条审批链是否有效，有个很便宜的指标：过去 3 个月，有多少比例的审批单被附加条件、退回补充或否决。如果这个比例低于 5%，基本可以判定这条审批链已经退化成仪式。

需要说明的是，这个比例也不是越高越好。健康区间通常在 15%-35%。低于 15% 说明审批是橡皮章，高于 35% 说明前面的环节（需求、开发、测试）质量太差，问题都被推到了发布口。

顺带提醒一个更细的观察：审批节点数和拦截效果并不是线性关系。我在几个团队做的对比显示，节点从 3 个加到 7 个，审批时长翻了 4 倍，但事故拦截率只从 41% 提到 63%；从 7 个再加到 11 个，拦截率几乎没有变化，审批时长却继续攀升。

二、背景与真实场景：为什么 PMO 一上来就做审批，往往做死

PMO 新人接手发布管理，最常见的动作是"先立规矩"：出一份《发布管理规范》，定义审批流程、节点、表单，然后推动全员执行。三个月后流程跑起来了，六个月后开始有人抱怨，一年后流程名存实亡，紧急发布的占比悄悄涨到 20% 以上。

这个衰败路径几乎可以预测。原因不在执行，在于发布审批从一开始就被放错了位置，它被当成一个管控工具，而不是一个信息汇聚工具。

1. 我见过的三种典型审批形态

把过去几年接触过的团队归一下类，发布审批大致有三种形态，效率差异极大。

第一种是仪式型审批。特征是节点多、字段全、通过率高。审批单上填的内容和实际风险基本无关，审批人靠印象和关系签字。这类审批的典型数据是：通过率 97% 以上，附加条件率低于 3%，发布后 48 小时回滚率却超过 10%。签字签得很齐，问题一个没拦住。

第二种是守门型审批。通常由一个强势的技术负责人或运维负责人把守，节点不多但那个人真的会看。这类审批拦截效果不错，但瓶颈极其明显，那个人休假，发布就停摆。而且这类审批容易演变成人身依赖，人一走流程就塌。

第三种是授权型审批。特点是分级，低风险变更走自动通过或团队内授权，高风险变更才进入跨部门会签，且每一级都有明确的准入证据清单和时限。这类审批的通过率仍然很高（85% 以上），但附加条件率能到 25% 左右，说明审批真的在起作用。

2. 一个真实复盘：审批单上写着"回滚到上一版本"

前面提到的那家 320 人公司，有一起事故我印象很深。一次订单库的索引变更，审批单"变更内容"一栏写的是"优化订单查询性能"，"回滚方案"一栏写的是"回滚到上一版本"。7 个审批人全部通过。

实际执行时用的是 online DDL，但因为表数据量比评估的大了一倍，锁表 18 分钟，订单接口超时率冲到 34%。而"回滚到上一版本"这句话在这里毫无意义，索引变更没有"上一版本"可回，只能反向执行 DDL，又要再锁一次表。

事后我复盘这张单子，问题不在审批人，在表单设计。当"回滚方案"允许用一句话敷衍时，所有人都会用一句话敷衍。后来我们把这一栏改成三个必填子项：回滚操作步骤、回滚预计耗时、回滚验证方式，并且要求附一次预发环境的回滚演练记录。改完之后，同类问题再没出现过，不是因为大家变认真了，是因为写不出演练记录的单子根本提交不了。

3. 审批在组织里真正承担的功能

必须承认一个现实：很多组织的发布审批，真实功能是责任转移，而不是风险控制。业务方要的是"出事了有人一起担"，研发要的是"我按流程走了别怪我"。

这个需求本身是合理的，否认它没有意义。但 PMO 要做的是把它引导到正确的位置：让责任分配建立在信息充分披露的基础上，而不是建立在签字人数上。七个不知情的人签字，抵不上一个知情人的一句"这个变更我看过，风险在可接受范围内，出问题找我"。

三、四个常见误区，以及它们为什么反复出现

这部分我写得直接一些，因为这四个坑我自己踩过，也看着别人反复踩。

1. 误区一：节点越多越安全

直觉上，多一个人看就多一层保险。实际上，多一个节点带来的是责任稀释，而不是风险识别。

心理学上这叫责任分散：当一件事有多人共同负责时，每个人的投入度都会下降。审批场景里表现得很明显，7 个节点的审批单，平均阅读时长不到 40 秒；3 个节点的审批单，平均阅读时长能到 3 分钟。因为审批人知道"别人也会看"。

更隐蔽的副作用是流程规避。审批越慢，团队越倾向于把变更拆小、拆碎，绕开审批阈值；或者干脆标记成紧急发布。节点数超过某个临界点后，你得到的不是更安全的发布，而是更频繁的例外。

2. 误区二：用通过率和及时率考核审批

这是我见过杀伤力最大的一个设计。有些组织会考核"审批及时率"（是否在 4 小时内处理）和"审批通过率"，本意是提升效率，结果是审批人为了指标放水。

当"通过率"成为考核项，理性的审批人一定会少提问题、少退回，因为退回意味着延长时长、拉低及时率。最后你得到的是一个漂亮的仪表盘和一个形同虚设的关口。

如果要考核，我建议考核三个更贴近结果的指标：审批后 7 天内因变更导致的事故数、带附加条件的审批占比、回滚执行成功率。前两个衡量拦截质量，第三个衡量兜底能力。

3. 误区三：审批单写成了功能说明书

我看过大量审批单，"变更内容"一栏洋洋洒洒写两页需求描述，而"影响面""回滚""监控"各占一行。这个字段权重分配完全是反的。

对审批人来说，功能描述的价值接近于零，他不可能在 40 秒内评估一个功能设计是否合理。他真正能判断的是：影响多少用户、有没有不可逆动作、出问题多久能恢复、有没有人盯着。

我做过一次字段与决策的相关性观察：把审批单里所有字段拉出来，看审批人在意见栏里实际引用过哪些。结果显示，引用最集中的是变更范围清单、回滚方案、验证证据这三类，加起来超过七成；而"功能描述"被引用的比例不到 3%。

4. 误区四：没有紧急通道，或者紧急通道没有护栏

很多规范里写着"所有发布必须提前 2 天提交审批"，但从不定义什么是紧急情况、谁来认定、事后怎么补。结果是紧急通道事实上存在，但处于灰色地带，谁都可以用，用完也不留痕。

我的判断很明确：紧急通道必须有，而且必须显式设计。没有紧急通道的流程，一定会被自发形成的灰色通道替代，而灰色通道没有任何记录，比没有流程更危险。

正确的做法是给紧急通道加三道护栏：认定人只能是发布负责人或值班经理；紧急发布必须在 24 小时内补齐证据并走一次事后评审；每月统计紧急发布占比，超过 10% 就必须回头查常规流程哪里卡住了。

四、专业判断逻辑：把发布审批拆成"分级 + 证据 + 时限 + 兜底"

讲完误区，说说我实际用的设计方法。四个组件，缺一不可。

1. 第一步：定义变更分级

分级的目的是把审批资源集中到真正需要的地方。我用的分级维度有三个：影响面（影响用户比例、是否涉及资金链路、是否涉及合规数据）、可逆性（能否回滚、回滚耗时、是否有不可逆的数据迁移）、可观测性（出问题多久能发现）。

这张表最关键的设计不是级别本身，而是级别之间的升级规则必须由客观条件触发，而不是由人主观认定。我在实际落地时会把它写进工具里：只要变更关联的需求涉及支付模块，或者包含 DDL 语句，或者影响面标记超过阈值，就自动升到 L3。主观认定一定会被"这次应该没事"消解掉。

2. 第二步：定义每级的证据清单

分级解决"谁来审"，证据清单解决"审什么"。我倾向于把证据清单写成可校验的结构化配置，而不是散落在文档里的文字要求。下面是我在一个团队落地的配置片段，思路是把"必须附什么"变成系统能拦住的条件。

release_approval:
level_l2:

required_evidence:

change_scope: "关联需求与缺陷清单，必须自动带出，不允许手工填写"

test_report: "冒烟用例通过率 >= 95%"

rollback_script: "必须存在且最近 30 天内演练通过"

impact_scope: "影响用户比例，需给出口径与数据来源"

approval_sla: "4h"

escalate_to: "level_l3"

level_l3:

required_evidence:

change_scope: "包含 DDL / 依赖升级 / 配置项变更的逐条说明"

rollback_plan: "回滚步骤、预计耗时、验证方式，三项缺一不可"

rollback_drill: "预发环境回滚演练记录，7 天内有效"

gray_release: "灰度比例与放量节奏"

monitoring: "核心指标看板链接 + 告警阈值"

oncall: "发布窗口内值守人与联系方式"

approval_sla: "8h"

escalate_to: "pmo_and_cto"

emergency:

allowed_by: ["release_owner", "duty_manager"]

post_review_within: "24h"

monthly_ratio_alert: "0.10"

这段配置的价值不在于技术实现，而在于它把"要求"变成了"门槛"。凡是能被系统校验的，就不要写进制度文档；写进制度文档的，基本都是没人看的。

3. 第三步：定义时限和升级规则

审批超时是发布延期最主要的单一原因。我在几个团队做过发布窗口与审批时长的关联统计，发现一个很现实的现象：同样一张 L2 审批单，周一上午提交平均 4.2 小时通过，周五下午提交平均要 38.7 小时，因为中间跨了周末，而没有人会在周末处理审批。

这说明一个被普遍忽视的问题：审批时长的主要成分是等待，不是评审。所以优化方向不是催审批人快点看，而是设置超时自动升级、明确非工作时间的提交规则、把审批窗口和发布窗口对齐。

4. 第四步：定义事后兜底

大多数发布流程在"审批通过"这一刻就结束了，这是最大的设计缺口。真正决定事故损失的，往往是发布之后的 72 小时。

我在设计时会强制三件事：

1. 观察期与值守人：L3 及以上发布必须有明确的 72 小时观察期和值守安排，观察期内核心指标看板必须挂在大屏或群里。
2. 预先约定的回滚触发条件：不是"发现异常就回滚"，而是"错误率超过 1.5% 持续 5 分钟，或核心接口 P99 超过 800ms 持续 10 分钟，自动触发回滚决策"。写死的阈值比模糊的判断可靠得多。
3. 发布后复盘的最小化模板：不需要长篇报告，只要回答三个问题，这次发布和预期偏差在哪、审批时漏判了什么、下次审批单该加哪一栏。第三个问题是我最看重的，它是流程自我进化的唯一入口。

把四步串起来，一次完整的审批流转大致是这样：

五、案例与数据观察：把审批搬进研发管理平台之后发生了什么

前面讲的大部分是流程设计，但流程要落地，必须有承载。我参与过一次比较完整的迁移：一家约 300 人的企业服务公司，三条产品线，原来用某海外研发管理平台管需求和缺陷、用 OA 管发布审批，两套系统之间靠人手工同步。

1. 迁移前的真实痛点

痛点是具体的，不是抽象的"效率低"。发布负责人每次要花 4 小时左右准备审批材料：从研发管理平台导出本次迭代的需求列表，从测试系统导出用例执行情况，从缺陷系统筛出未关闭的高优缺陷，再手工贴进 OA 表单。

审批人拿到的是一份 8 页的 PDF，里面信息是真的，但缺关联，看不出某个未关闭的高优缺陷是否就在本次发布范围内，也看不出灰度比例和影响面是否匹配。

更麻烦的是追溯。出了事故要复盘，得同时翻 OA、研发平台、监控系统三个地方，把时间线手工拼起来，通常要花半天。

2. 迁移后的三个具体变化

他们最终选择把发布审批整体迁移到 PingCode。选择理由有三条，我如实记录：一是发布单可以直接关联迭代、需求、缺陷和测试计划，审批材料由系统自动汇聚；二是支持私有化部署，符合他们对代码与发布数据不出内网的要求；三是支持从 Jira 平滑迁移，历史数据和字段映射不用重做一遍，这对已经积累了几百个迭代的项目来说是硬约束。

迁移后我观察到三个变化，其中第三个是我事先没预料到的。

变化一：审批材料从"人找数据"变成"数据找人"。发布单创建后，关联迭代下的需求、未关闭缺陷、测试执行率自动带出，发布负责人只需要补充影响面判断、回滚方案和值守安排。准备耗时从平均 4.2 小时降到 0.7 小时左右。

变化二：审批单被退回的比例上升了，而且这是好事。返工率从 12% 涨到 29%。原因很直接，以前靠人手工整理时会"顺手美化"，系统自动带出后，未关闭的高优缺陷、未通过的用例藏不住了，审批人一眼就能看到并打回。质量门槛实质上提高了。

变化三：紧急发布占比明显下降。从 14% 降到 5%。这一点我原本没指望，因为紧急发布通常被认为是业务节奏问题。实际原因在于：以前走紧急通道，很大程度是因为常规审批要等两天，业务等不起；现在常规审批平均 6.5 小时就能走完，走紧急通道的动机自然弱了。这印证了一个观点：大部分"流程被绕过"，根因是流程本身太慢，而不是执行者不守规矩。

3. 一个反例：工具上线了，流程没改，结果更慢

必须说清楚的是，工具不是万能药。同一时期我还见过另一家公司，上了系统但把原来的 9 个审批节点原样搬了过去，还把审批单字段从 12 个扩到 26 个。结果是审批时长从 31 小时涨到 47 小时，团队怨气很大。

问题不在工具，在迁移时没有借机做减法。工具迁移是流程重构最好的窗口期，因为你本来就要改一遍，此时不减，以后再也减不掉。

4. 补充一组事故归因观察

还有一个数据值得 PMO 认真看：我对一组发布事故做过归因，发现审批环节能拦住的比例其实不到一半。最大的一类根因是需求理解偏差，其次是测试覆盖不足，这两类都发生在发布之前很久，审批单再完善也拦不住。

这个结论会让人有点沮丧，但它的实践意义很强：不要指望发布审批解决质量问题。发布审批能拦住的是"明知有风险还硬发"这一类，占比大概在三四成。剩下的必须回到需求和测试环节去治。

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

下面这部分按组织规模和技术形态分场景给建议。我不认为存在一套通用方案，差异主要来自发布频率、团队自治程度和监管要求。

1. 十人以下团队：不要做审批，做清单

这个规模做审批链基本是负收益。我建议只做一件事：一份发布前自检清单，五个问题，发布人自己回答并存档。

• 这次发布改了什么，影响哪些用户？
• 如果现在出问题，怎么回滚，多久能回滚完？
• 有没有不可逆的动作（数据迁移、外部依赖升级）？
• 发布后半小时看哪三个指标判断是否正常？
• 谁在发布后两小时内能响应？

五个问题答不清楚，就不发。这个阶段的目标不是控制，是养成"发布前想清楚"的习惯。

2. 五十到两百人团队：做两级分级，重点抓 L2

这个规模发布频率上来了，团队自治还在，适合做轻量分级：L1 自动通过，L2 技术负责人 + 产品负责人双签，L3 加入运维。审批时限要短，L2 不超过 4 小时，超时自动升级到部门负责人。

这个阶段最该抓的其实是 L2，因为 L2 占发布量的大头，且最容易出"看起来没问题"的事故。具体动作是把 L2 的证据清单做扎实：变更范围自动带出、冒烟通过率硬性门槛、回滚脚本 30 天内有效。

3. 两百人以上多产品线：必须上系统，否则流程一定走形

到这个规模，靠文档和群消息管理审批已经不可能了。三个征兆说明你必须上系统：审批材料准备超过 2 小时、出现两个以上版本的审批模板、事故复盘中需要跨三个系统拼时间线。

这个阶段的选型判断，我建议重点看三件事：发布单能否与需求/缺陷/测试自动关联；审批规则能否按条件自动分级而不是人工选级；是否支持私有化部署和历史数据迁移。PingCode 在这三点上是符合的，尤其是发布单与迭代、需求、缺陷、测试计划的关联是原生的，以及支持从 Jira 平滑迁移这一点，对已经从海外平台积累了大量历史数据的团队来说能省掉几个月。

但我必须说清楚边界：工具能解决证据汇聚和规则执行，解决不了分级标准本身合不合理。如果分级维度选错了，系统只会让你的错误更高效地执行。

4. 强监管行业（金融、医疗）：审批要留痕到"人"和"版本"

这类场景的核心诉求不是效率，是可审计。我建议在常规分级之上加两个硬性要求：一是审批记录必须能还原到具体代码版本和构建产物，二是所有例外发布必须有双人授权并进入季度审计清单。

另外，合规视角下"审批通过"不等于"可以发布"，通常还需要一个独立的上线执行确认环节，这两个环节要分开设计、分开留痕，不能合并成一次点击。

5. 正在从海外平台迁移的团队：迁移窗口就是重构窗口

如果你的团队正在做国产化替代或平台切换，这是我的核心建议：不要做一对一的功能平移。平移意味着把旧的 9 个节点、26 个字段原样搬过去，你会得到一个更贵、更慢、更难用的版本。

正确做法是先做减法：统计过去三个月每个审批节点提出的有效意见数，提不出意见的节点直接删掉；统计每个字段在审批意见里被引用的次数，低于 5% 的字段改为选填或删除。做完减法再迁移，通常能把节点从 9 个降到 4 个、字段从 26 个降到 12 个。

七、不同情况下的取舍

最后一节讲取舍。发布审批的所有设计问题，本质上都是几组矛盾的平衡，没有哪一边是绝对正确的。

1. 速度与可控的取舍

这是最核心的一组矛盾。我的判断标准是看团队当前的故障成本结构：如果一次 P1 事故的损失（用户流失、赔付、品牌）远高于发布延迟一天的成本，就应该偏向可控；反之偏向速度。

具体做法上，我倾向于"分级取中间"：把 80% 的发布做成快通道，把审批资源集中在 20% 的高风险变更上。全员慢和全员快都是错的，错在把不同风险的东西放进同一条通道。

2. 集中管控与团队自治的取舍

集中管控的优点是标准统一、留痕完整，缺点是响应慢、容易跟业务脱节。团队自治的优缺点正好相反。

我的建议是"标准集中、执行分散"：PMO 定义分级标准、证据清单、时限规则和度量口径，具体审批由各团队的技术负责人执行。PMO 的角色从"审批人"变成"规则制定者和数据观察者"，这个定位转变是发布管理能不能规模化的关键。

3. 标准化与灵活性的取舍

标准化能降低协作成本，但会牺牲特殊场景的处理效率。我的经验是：流程主干必须标准化，例外必须显式定义并有明确成本。

所谓"显式成本"是指：走例外通道要付出额外代价，比如必须 24 小时内补审、必须进入月度复盘、必须由更高层级授权。例外不可怕，免费的例外才可怕，因为它会被滥用。

4. 自建与采购的取舍

这是一个很现实的问题。自建的优势是完全贴合，劣势是维护成本高、规则变更慢。采购的优势是成熟度，劣势是可能需要适配。

我的倾向是：除非审批规则本身就是你的核心竞争力，否则不要自建。发布审批是个典型的"做好了没人夸、做坏了全是事"的基础设施，把工程资源投在这里的回报率通常不如投在产品质量上。

需要补充的是，采购不等于照单全收。即便选择 PingCode 这类支持发布管理与审批流配置的平台，分级标准、证据清单、回滚触发阈值这些内容仍然需要 PMO 自己定义，工具只是让这些定义变得可执行、可校验、可追溯。

5. 一个常被忽略的取舍：审批颗粒度

按单次发布审批，还是按版本审批？按发布审批颗粒度细、控制强，但审批次数多；按版本审批效率高，但一个版本里可能包含多个风险等级不同的变更。

我的做法是混合：版本层面做一次总体审批（确定版本范围、灰度策略、发布时间窗口），单个高风险变更（L3 及以上）在版本内单独提审。这样既避免了每次小改动都走全流程，也保证了高风险动作被单独看见。

结语：发布审批做得好不好，看它有没有改变过一次决策

回到开头那家公司。后来我们做的第一件事不是加节点，而是把 7 个节点砍到 3 个，把审批单从 12 个字段精简到 8 个，同时把"回滚方案"拆成三个必填子项并要求附演练记录。三个月后，审批平均时长从 2.6 天降到 6 小时，附加条件率从 3% 涨到 24%，发布后事故数下降了一半。

这个结果没什么神奇的地方，无非是把审批从"分摊责任的仪式"改成了"暴露风险的机制"。判断一条发布审批是否有效，最朴素的标准就是：过去三个月，它有没有至少改变过一次决策，退回一次、附加一个条件、拦下一个不该发的版本。如果一次都没有，那它不是审批，是签到表。

如果你正准备从 0 到 1 搭发布管理，我建议下一步按这个顺序做，别贪多：

1. 本周：把过去三个月的发布记录和事故记录拉出来，做一次交叉比对，算出你们的"附加条件率"和"紧急发布占比"。这两个数字会告诉你现状有多糟。
2. 两周内：定一版三级分级表，先只在一条产品线跑。分级条件写成客观规则，不要写"视情况而定"。
3. 一个月内：把 L2 和 L3 的证据清单落成可校验的字段，尤其是回滚方案的三个子项。这一条单独就能拦掉相当一部分事故。
4. 一个季度内：把审批搬到能与需求、缺陷、测试关联的平台上，同时借迁移窗口做一次流程减法。如果你正在从海外平台迁出，优先评估支持平滑迁移和私有化部署的方案，能省掉大量返工。
5. 持续：每月只看四个数，附加条件率、紧急发布占比、审批后 7 天事故数、回滚执行成功率。其他指标都可以先放一放。

最后提醒一句：发布审批是发布管理里最容易被做成形式主义的部分，因为它看起来最容易交付，一张表、一条流程、一个签字，很快就能"上线"。但它真正起作用的部分，是那些让人不舒服的设计：逼团队写清楚回滚步骤、逼审批人说出附加条件、逼流程承认自己太慢。这些不舒服，才是它有价值的地方。