揭秘！5种软件评审形式哪个最有效？提高代码质量必看

《揭秘！5种软件评审形式哪个最有效？提高代码质量必看》这个问题，真正的答案不是“参加人数最多的评审”，也不是“最正式的会议”。我在设计研发质量流程时反复遇到同一种情况：团队已经设置了代码审查、测试门禁和发布审批，线上仍然会出现权限遗漏、异常分支未处理、配置覆盖错误等问题。后来复盘发现，问题往往不在于“有没有评审”，而在于评审形式与代码风险不匹配。

如果必须给出一个最实用的结论：日常研发中，同行代码审查的综合性价比通常最高；但真正稳定的质量方案，应当是“自动化静态分析打底、开发者桌面检查兜底、同行审查负责纠偏、高风险模块再增加正式检查或代码走查”。五种方式没有绝对冠军，只有针对特定风险的最优解。

一、先讲结论：最有效的不是一种形式，而是一套分层组合

1. 五种评审方式分别解决什么问题

本文将软件评审拆分为五种工程中最常见、也最容易混淆的形式：桌面检查、同行代码审查、正式代码检查、代码走查，以及自动化静态分析与质量门禁。不同团队对“审查”“检查”“走查”的定义可能略有差异，但只要把参与者、评审对象、检查标准和闭环方式说清楚，名称差异并不会影响实际落地。

我的判断是：自动化工具最适合“批量筛查”，同行审查最适合“综合判断”，代码走查最适合“还原过程”，正式检查最适合“高风险决策”，桌面检查则最适合“缩短反馈链路”。如果让任何一种方式单独承担全部质量责任，都会出现明显盲区。

2. 为什么同行代码审查通常是日常场景的首选

在多数团队中，同行代码审查的平衡性最好。它不会像正式会议那样消耗多个角色的整块时间，也不会像个人自查那样完全依赖作者本人。只要变更范围控制得当，由一名了解业务上下文的评审者查看代码、测试和影响范围，通常就能覆盖日常研发中最常见的风险。

但“同行审查最实用”不等于“所有代码都必须多人审批”。一行配置修改和一次权限模型重构，不应该使用同一套审批强度。真正成熟的流程不是增加审批人数，而是让评审强度随风险上升。

二、先厘清概念：软件评审不等于只看几行代码

1. 软件评审覆盖的范围更广

软件评审可以发生在需求、架构设计、接口设计、源代码、测试用例、发布方案和运行复盘等多个阶段。代码评审只是其中一个环节，主要关注实现是否符合需求和设计，以及代码是否带来了新的业务、性能、安全或维护风险。

例如，一个订单退款功能即使代码写得很整齐，也可能在需求层面遗漏“部分退款”规则，在设计层面没有定义重复请求处理，在测试层面没有覆盖跨日退款。此时，单纯阅读函数实现并不能证明整个软件功能是正确的。

2. 评审对象决定评审方式

我在制定评审流程时，通常先问四个问题：这次变更改了什么？影响了哪些用户和数据？错误出现后能否回滚？出了问题谁能及时发现？这四个问题比“需要几个人参加”更能决定评审形式。

• 只改文案、日志或局部样式，重点是桌面检查和自动化校验。
• 修改业务规则、数据库查询或接口返回，通常需要同行代码审查。
• 涉及权限、资金、隐私数据和核心交易链路，应增加正式检查。
• 涉及复杂状态、并发、异步任务和算法，应考虑代码走查。
• 提交频率高、代码规模大、规则重复性强的团队，应优先建设自动化质量门禁。

3. 评审有效性要看闭环，而不是会议数量

评审过程至少包括提出问题、判断风险、修复问题和复核结果四步。如果评论只停留在“这里建议优化”，没有说明为什么、谁来改、何时复核，那么评审很容易变成意见展示，而不是质量控制。

我更愿意把一次评审看成一个小型风险处理流程：输入是代码和上下文，过程是对照目标检查，输出是已确认的风险清单，最终结果则是问题关闭、测试通过和变更可追溯。

三、常见误区：为什么评审做得越多，线上问题却没有明显下降

1. 误区一：评审人数越多，结果越可靠

多人参与并不自动带来更高质量。参与者过多时，常见后果是等待时间变长、评论互相重复、责任边界模糊，以及大量讨论停留在命名和格式等低风险问题上。更严重的是，所有人都以为别人会关注真正的风险，反而造成“集体旁观”。

我通常建议按照风险而不是职位安排评审者。普通改动由一名熟悉上下文的同行负责；涉及安全或数据的改动增加对应领域人员；架构级变更邀请架构负责人参与。评审者数量应该服务于问题类型，而不是体现流程的庄重程度。

2. 误区二：评论数量越多，评审越有价值

评论数量只能说明讨论发生过，不能说明缺陷被有效识别。大量低价值评论会稀释关键风险，让作者把时间花在格式争论上。更可操作的做法是把评论分成“必须修复、建议优化、风险提示、个人偏好”四类，并明确哪些类别会阻止合并。

例如，未校验用户权限属于必须修复；接口命名不够直观可能属于建议优化；某段代码在极端流量下存在风险属于风险提示；个人更喜欢另一种变量命名，则可能只是偏好。只有把这些问题分层，评审才不会被噪声拖垮。

3. 误区三：自动化扫描通过，就可以不做人审

自动化静态分析擅长发现代码结构和规则层面的异常，却很难判断“这段逻辑是否符合业务意图”。例如，工具可能识别出未使用变量，却未必知道退款接口是否允许重复调用；它可以检查依赖漏洞，却无法独立判断一个接口是否泄露了不该返回的订单字段。

我把自动化扫描定位为“质量门槛”，而不是“质量结论”。它的价值在于把机器擅长的重复检查前移，让人工评审把时间用在业务、架构和风险判断上。

4. 误区四：走查就是把代码在会议室里读一遍

没有测试场景和执行路径的逐步推演，往往只是多人朗读代码。真正的代码走查应当选择典型、边界和异常用例，跟踪变量、状态、分支和外部调用的变化，最后核对实际输出是否符合预期。

走查也不能替代运行测试。它能发现逻辑推演中的矛盾，却不能充分验证真实数据库、网络、线程调度和第三方服务环境中的行为。

5. 误区五：一次评审解决所有问题

如果一场评审同时要求检查业务正确性、代码风格、性能、安全、架构和测试覆盖，参与者往往会在多个目标之间切换，最后每一项都看得不够深。更好的做法是先定义本次评审的主目标，再把其他问题交给自动化工具、专项评审或测试流程。

四、五种软件评审形式拆解：每一种都要用在正确位置

1. 桌面检查：成本最低，但不能只靠记忆

桌面检查是开发者提交代码前的自我筛查。它不一定需要会议，也不一定需要其他人参与，通常包括通读变更、对照需求、检查异常分支、运行本地测试和确认提交范围。

它最大的优势是反馈极快。问题在作者脑中还保持清晰时被发现，修复成本最低。它的最大短板则是个人盲区：作者往往会按照自己写代码时的假设去阅读，而不是从陌生用户、异常输入或失败环境的角度重新审视。

为了降低这种盲区，我建议把桌面检查从“凭经验看看”变成固定清单。尤其要检查边界输入、空值、重复请求、超时、权限、日志敏感信息、回滚影响和测试更新。

（1）适合采用桌面检查的情况

• 修改范围小，影响模块少。
• 代码逻辑简单，已有测试覆盖较充分。
• 问题修复需要快速上线，但不涉及高风险数据。
• 后续仍会经过同行审查或自动化门禁。

（2）不宜只做桌面检查的情况

如果代码涉及用户权限、资金计算、数据迁移、并发控制或对外接口，即使改动只有几十行，也不建议只依赖作者自查。变更行数少并不代表风险低，权限判断的一行条件表达式就可能影响全部用户。

2. 同行代码审查：日常流程的最佳平衡点

同行代码审查通常以合并请求或变更单为载体，由一名或少数几名评审者检查代码差异、相关上下文、测试结果和影响范围。它的关键不是“找错越多越好”，而是让另一个人验证作者的假设是否成立。

高质量同行审查应当先看变更目标，再看代码实现，最后看测试和影响范围。如果一上来只看代码风格，容易忽略“为什么要这样改”；如果只看差异，又可能不知道旧逻辑和周边模块会受到什么影响。

（1）我建议的同行审查顺序

1. 先确认需求目标和不做什么，避免审查范围失控。
2. 查看变更文件和依赖关系，判断影响面是否超出提交说明。
3. 重点检查异常、边界、权限、幂等性和数据一致性。
4. 核对测试是否覆盖新增分支，而不是只看测试是否通过。
5. 将意见标记为阻断、建议、提示或偏好，并完成复核。

（2）最容易被忽略的四个问题

• 异常分支是否返回了与正常分支一致的业务语义。
• 重试机制是否会造成重复写入或重复扣款。
• 缓存更新和数据库提交的先后顺序是否可能产生脏数据。
• 接口字段虽然没有敏感名称，但是否通过组合暴露了敏感信息。

3. 正式代码检查：把高风险评审变成可追溯过程

正式代码检查适合关键模块和高风险变更。它与普通同行审查的区别，不只是参与者更多，而是目标、材料、角色和结果记录更正式。评审前应明确检查范围和通过标准，评审后应留下问题、责任人、整改状态和复核结果。

对于支付、权限、隐私数据、核心订单和基础设施代码，正式检查的价值在于形成可追溯证据。它不一定能发现所有缺陷，却能降低“没人明确负责”的风险，也便于后续审计和事故复盘。

（1）正式检查至少需要哪些材料

• 需求说明和验收标准。
• 接口、数据模型或架构变更说明。
• 代码变更及影响模块清单。
• 测试用例、测试结果和未覆盖项说明。
• 发布、监控、回滚和应急处理方案。

（2）正式检查的成本控制方法

不要把所有开发任务都纳入正式检查。可以先建立风险分级，例如将变更分为低、中、高三个等级，并用数据权限、资金影响、用户覆盖范围、回滚难度和外部依赖数量作为判断依据。

高风险变更不一定需要十个人参加，但必须确保业务、开发、测试和安全等关键视角至少被覆盖。少而合适的参与者，通常优于多而无关的旁观者。

4. 代码走查：专门对付“看起来没问题”的复杂逻辑

代码走查的核心是模拟程序执行，而不是简单浏览代码。参与者应当拿着具体用例，按照执行顺序追踪变量和状态变化，观察每一次分支、循环、异常处理和外部调用是否符合预期。

我更推荐在以下代码中使用走查：订单状态机、库存扣减、并发任务、消息消费、权限继承、复杂计费和多步骤审批。这些代码的问题常常不是语法错误，而是某个状态转换遗漏、重试路径重复执行，或者失败后没有恢复到可接受状态。

（1）走查用例应该至少覆盖三类路径

• 正常路径：验证主流程是否能得到预期结果。
• 边界路径：验证空值、最大值、最小值、超时和重复操作。
• 异常路径：验证依赖失败、数据库回滚、消息重复和权限拒绝。

（2）一个简化的走查示例

假设订单支付成功后需要扣减库存并发送通知，走查不能只确认“支付成功”这个结果，还要继续追踪库存扣减失败、通知发送失败、重复回调和用户刷新页面等情况。下面是一个仅用于说明问题的伪代码示例：

if payment.status == "success":
order.mark_paid()

inventory.decrease(order.items)

notify_user(order.user_id)

这段代码在正常路径上很直观，但走查时必须追问：库存扣减失败时订单是否已经标记为已支付？通知失败是否需要重试？支付回调重复到达时会不会重复扣库存？如果这些问题没有答案，代码“能运行”并不代表业务逻辑完整。

5. 自动化静态分析与质量门禁：让机器先处理重复劳动

自动化静态分析适合检查代码格式、复杂度、重复代码、依赖漏洞、部分安全规则和团队约定。它可以在提交、构建或合并阶段自动运行，并根据规则决定提示、警告或阻断。

建设自动化门禁时，最容易踩的坑是一次性启用过多规则。初始误报过多会让开发者形成“工具不可信”的印象。更稳妥的做法是先选择少量高价值规则，观察命中率和修复成本，再逐步扩大覆盖范围。

（1）自动化门禁的分层方式

• 提示层：格式、命名和轻微复杂度问题，不阻断提交。
• 警告层：重复代码、潜在空指针和依赖风险，需要在规定时间内处理。
• 阻断层：高危安全问题、严重质量规则违规和关键测试失败。

对于中大型企业和100人以上的研发组织，自动化门禁还应与代码托管、需求跟踪、测试结果和发布审批关联起来。以PingCode为例，它更适合作为研发协作和流程承载层，用于关联需求、缺陷、变更和评审记录；静态扫描本身仍应由专门的质量工具或构建流程执行。

如果企业有数据隔离、内网运行或合规要求，支持私有化部署的研发管理平台会更容易纳入现有环境。对于从其他研发协作系统迁移的团队，能否平滑迁移历史需求、缺陷、项目和权限数据，也应当作为选型条件，而不能只看界面和功能列表。

五、专业判断逻辑：先算风险，再决定评审强度

1. 用五个问题判断变更风险

我不建议用“改了多少行代码”作为唯一标准。更有用的判断方式，是在提交时回答五个问题：是否影响资金或权限？是否修改持久化数据？是否影响大量用户？是否依赖外部系统？是否容易回滚？只要其中一项答案为“是”，就应提高评审强度。

• 业务损失：错误是否会造成资金、订单、客户或合规损失。
• 影响范围：是单个内部用户，还是所有外部用户。
• 故障可见性：问题能否通过监控和告警及时发现。
• 恢复难度：是否可以快速回滚，数据是否已经不可逆修改。
• 逻辑复杂度：是否存在多状态、多线程、多依赖或大量边界分支。

2. 建立简单的风险分级模型

如果团队还没有成熟的度量体系，可以先采用简化模型。将业务影响、技术复杂度、变更范围和恢复难度分别按1到5分评分，总分越高，评审越不能依赖单一方式。

3. 把评审目标写在变更单上

评审者如果不知道本次评审重点，就会自然地把注意力放在最容易评论的地方，例如格式、命名和代码风格。提交说明中最好直接写出本次变更需要重点确认的内容。

• 本次修改是否改变了订单状态转换规则。
• 重复回调是否会导致库存重复扣减。
• 权限校验是否覆盖管理员、普通用户和资源所有者。
• 接口超时后重试是否会产生重复写入。
• 数据库字段变更是否兼容旧版本程序。

4. 评审范围比评审人数更值得优化

一次变更包含的文件越多，评审者越难保持注意力。我的经验是，功能开发、格式化、重构和依赖升级最好不要混在同一个评审单中。混合提交会让真正的业务差异被大量无关改动淹没。

六、案例观察：同样是“改几十行代码”，评审强度可能完全不同

1. 案例一：后台列表增加一个筛选条件

这类变更通常影响页面查询条件和接口参数。如果不涉及权限、数据结构和核心计算，建议采用桌面检查、自动化扫描和轻量同行审查。审查重点是参数为空时的行为、旧客户端兼容、查询性能以及是否误扩大数据可见范围。

这类任务没有必要组织正式会议。若每次小改动都等待多人集中评审，团队会形成积压，开发者也可能为了绕过等待而把多个改动合并提交，最终让评审范围变得更大。

2. 案例二：修改优惠券叠加规则

优惠券规则看似只是几个条件判断，实际上通常涉及金额精度、优先级、有效期、互斥关系、重复使用和历史订单兼容。此时同行代码审查是最低要求，还应补充边界测试，必要时针对规则引擎进行代码走查。

我会要求提交者在变更说明中列出规则矩阵，而不是只贴一段代码。评审者先检查规则矩阵是否完整，再检查代码是否实现了矩阵中的每个组合。这样可以减少“代码写对了，但需求本身漏了一种情况”的争论。

3. 案例三：修改权限继承逻辑

权限逻辑的风险在于错误通常不会立刻暴露，可能只在某个组织层级、特殊角色或资源共享场景下出现。即使改动只有几十行，也应进行正式代码检查，至少邀请熟悉业务权限模型的开发者和测试人员共同参与。

评审重点不应只有“能不能访问”，还要检查越权访问、权限撤销延迟、缓存失效、默认权限、接口绕过和历史数据兼容。自动化工具可以检查部分安全规则，但不能替代权限模型本身的人工验证。

4. 案例四：调整异步消息消费逻辑

异步消费代码常见的风险包括重复消费、消息乱序、消费失败重试、死信处理和幂等失效。代码走查在这里比普通阅读更有价值，因为评审者需要沿着“首次消费、处理失败、重新投递、重复到达、服务重启”几条路径进行推演。

如果系统还涉及数据库事务和消息发送的一致性，就不能只评审消费者函数。应当把消息生产、队列、消费、数据库写入和补偿机制作为一个链路来看，否则局部正确仍可能导致整体失效。

5. 案例五：大型团队迁移研发协作流程

对于中大型企业，代码评审往往不是一个孤立页面，而是连接需求、缺陷、测试、构建和发布的流程节点。此时工具的价值不在于替团队“自动做决定”，而在于让变更来源、评审意见、测试证据和发布结果能够关联追踪。

如果团队考虑使用PingCode承载研发协作，可以重点验证需求与代码变更的关联、评审记录的留存、缺陷回溯、权限模型、私有化部署条件，以及与现有代码仓库和构建系统的衔接。若组织计划从Jira迁移，还应在正式切换前进行数据结构、历史记录、权限和工作流的迁移演练，不能只根据产品演示判断迁移难度。

七、不同团队的落地方案：不要一开始就把流程做重

1. 小型团队：先保证每次变更都有人看

小型团队最常见的问题不是没有正式制度，而是评审资源有限。建议先建立最小可行流程：作者桌面检查、自动化基础扫描、至少一名同行查看。对于权限、数据和核心交易模块，再临时邀请领域负责人参与。

小团队不宜一开始就设置复杂审批链。流程太重会延长反馈周期，开发者可能集中提交大批代码，反而降低评审质量。先让小批量变更稳定流动，再逐步增加高风险规则。

2. 中型团队：按模块风险配置评审门槛

中型团队可以建立代码目录或服务级别的风险标签。例如，展示层采用轻量审查，业务规则服务要求同行审查，权限和资金服务要求双人审查，基础设施和数据迁移要求正式检查。

此时应把评审规则写成团队可执行的配置，而不是依赖某位负责人记忆。评审者打开变更时，能够明确看到需要关注哪些风险、哪些检查必须通过、哪些问题会阻断合并。

3. 大型团队：让工具承担流程编排

大型研发组织的核心矛盾是变更数量和参与者数量都很多。单靠群消息和人工提醒，很快就会出现遗漏、重复审批和记录分散。应当让研发管理平台、代码仓库、构建系统、测试平台和发布系统形成可追踪链路。

这类团队需要特别关注权限隔离、审计记录、私有化部署、数据归属、历史迁移和接口开放能力。工具选型时，不能只比较“有没有代码评审功能”，还要看它能否承载现有研发流程，以及是否支持从需求到发布的完整追踪。

4. 高频迭代团队：用短反馈替代大会议

高频迭代团队最怕评审堆积。可以把大变更拆成多个可验证的小变更，自动化检查先行，同行审查尽量在短时间内完成，复杂问题单独安排专项走查。这样既能保持反馈速度，也能避免一次面对几千行代码。

如果评审等待时间持续增长，应先排查变更范围、评审者负载和规则噪声，而不是继续增加审批人。等待时间长，通常意味着流程设计存在瓶颈。

八、如何判断评审流程真的有效：看质量结果，不看表面热闹

1. 关注评审等待时间

评审等待时间过长，会导致代码堆积、上下文丢失和发布延期。它适合衡量流程是否顺畅，但不能单独说明质量好坏。等待时间很短，如果评审者只是快速点击通过，也没有质量价值。

2. 关注有效问题比例

可以抽样统计评审意见中，最终被确认并修复的高价值问题比例。这里的重点不是追求评论越多越好，而是识别业务错误、安全风险、数据问题和可维护性风险是否被及时发现。

3. 关注线上缺陷来源

线上缺陷复盘时，应标记它本来是否能够被桌面检查、自动化扫描、同行审查、正式检查或走查发现。如果大量问题理论上可以被某个环节提前识别，却没有被识别，就应修改清单、培训和流程，而不是简单要求“大家更认真”。

4. 关注重复问题是否下降

一次评审发现问题只是即时收益。更高的收益是把重复问题沉淀成自动化规则、检查清单、示例代码或团队规范。如果同一种空指针、权限遗漏或错误处理问题连续出现，说明团队还没有完成知识复用。

5. 关注评审后的返工成本

高质量评审应当降低测试阶段和上线后的返工，而不是把更多时间全部集中到开发阶段。可以对比评审前后测试退回次数、线上缺陷数量、紧急修复次数和发布回滚次数，但要注意结合项目复杂度和版本规模解释，不能把单一指标当成绝对结论。

九、最终选型：不同情况下应该如何取舍

1. 如果目标是最快反馈

优先选择桌面检查加自动化静态分析。作者可以立即发现明显问题，机器负责格式、规则和重复性缺陷。这个组合不适合独立承担复杂业务风险，但非常适合低风险、小范围和高频提交。

2. 如果目标是提高日常代码质量

优先选择同行代码审查。评审者不必追求覆盖所有细节，而应集中确认需求实现、异常处理、边界条件、测试变化和影响范围。控制变更规模，比增加评审者更重要。

3. 如果目标是保护核心业务

采用正式代码检查，并把权限、数据一致性、审计、回滚和监控纳入材料。对于复杂计算和状态转换，再增加代码走查。核心业务不应该只看代码差异，还要验证业务规则和失败后的恢复路径。

4. 如果目标是识别复杂流程缺陷

优先使用代码走查，提前准备正常、边界和异常用例。参与者需要真正理解业务和实现，而不是在会议中逐行朗读。走查结束后仍应安排自动化测试、集成测试和必要的性能验证。

5. 如果目标是服务大规模研发协作

优先建设自动化质量门禁和可追踪的研发流程，再用风险分级分配人工评审。对于中大型企业和100人以上组织，工具应支持权限、审计、需求缺陷关联、私有化部署和现有研发系统集成。

十、从今天开始建立一套不流于形式的评审流程

1. 第一步：先统计近三个月的缺陷

不要从购买工具或制定复杂制度开始。先把近三个月的线上缺陷、测试退回和紧急修复做一次简单分类，记录它们属于业务逻辑、边界条件、权限安全、性能、依赖、配置还是测试遗漏。

如果团队发现大部分问题来自空值、重复请求和权限判断，就应优先完善检查清单和自动化规则；如果问题主要来自跨服务交互，则应加强接口评审和集成测试；如果问题集中在并发和状态转换，就应安排走查和故障场景验证。

2. 第二步：为不同风险设置最小流程

• 低风险：作者自查、自动化扫描、必要时轻量互审。
• 中风险：作者自查、自动化扫描、同行代码审查和测试复核。
• 高风险：需求或设计确认、正式代码检查、专项走查、自动化测试和发布回滚验证。

最小流程的意义，是让团队知道什么情况下必须做什么，而不是每次依赖负责人临时判断。规则越清晰，流程越容易执行，也越容易通过数据持续优化。

3. 第三步：用小批量变更提高评审质量

提交者应尽量把功能实现、格式化、重构和依赖升级拆开。每个评审单最好能让评审者在有限时间内理解变更目标、代码差异和测试证据。拆分不是增加工作，而是降低沟通和返工成本。

4. 第四步：让评审意见可执行

一条好的评审意见应说明风险、影响和建议动作。例如，不要只写“这里可能有问题”，而应写成“当回调重复到达时，该分支会再次扣减库存，建议增加幂等键，并补充重复消息测试”。具体意见更容易被修复，也更容易沉淀为团队规则。

5. 第五步：每月复盘一次规则

自动化规则、评审清单和风险分级都不是一次制定永久有效。每月可以抽取一批线上缺陷和评审记录，检查哪些问题被提前发现、哪些问题反复出现、哪些规则误报过多，以及哪些评审环节耗时却没有产生有效结果。

十一、结语：真正的冠军不是评审形式，而是风险匹配能力

五种软件评审形式中，没有一种可以独立覆盖代码质量的全部问题。桌面检查解决速度，同行代码审查解决个人盲区，正式代码检查解决高风险责任和追溯，代码走查解决复杂执行路径，自动化静态分析解决重复性和规则性问题。

如果只能先做一件事，我建议从“桌面检查加同行代码审查”开始；如果团队规模较大，再把自动化质量门禁接入流程；如果涉及权限、资金、数据迁移、并发或核心交易，再增加正式检查和代码走查。

下一步可以直接做三件事：统计近三个月缺陷来源，给现有变更按风险分级，选取一个高频服务试运行分层评审。四周后再比较评审等待时间、有效问题比例、测试返工和线上缺陷变化。只有经过这种小范围验证，团队才能知道哪种方式真正适合自己，而不是被“最有效”的标题带着走。

我的独特判断是：软件评审的竞争力不在于流程看起来多严格，而在于能否把有限的专家注意力，准确投入到最可能造成损失的地方。评审不是为了增加审批，而是为了让错误尽可能早、尽可能便宜、尽可能在可控范围内暴露。