项目目标如何做好成功标准？项目负责人风险控制与操作步骤

2023年夏天，我以外部顾问的身份列席了一个交付项目的验收会。会议室里坐了十一个人，业务方负责人说的第一句话是：“这不是我们当初要的东西。”技术负责人当场翻开需求文档，回了一句：“文档里写的就是这个，签字也签了。”接下来两个小时的争论，没有一句是在讨论技术，全都在争论“什么叫成功”，进度表上写着“按计划上线”，上线也确实按计划发生了，但没有人能说清这个项目到底算不算成功。

这个场景我后来又见过很多次，它几乎总是指向同一个根源：项目失败很少是因为风险没被识别，而是因为成功标准本身是空的，风险清单也就跟着变成了摆设。

一、核心结论：成功标准是风险控制的锚点，不是结项报告里的一句话

先把结论摆在最前面：如果只允许项目负责人做一件事来改善风险控制，我会建议他先停下来，把“成功标准”写成一张能被第三方独立验收的卡片，再去列风险。顺序反了，后面所有动作都会空转。

1. 风险控制的第一道工序不是列风险，而是定义“什么叫成功”

绝大多数项目风险管理的培训都从“风险识别”开始讲，但实际操作中，识别风险需要一把尺子。没有尺子，你只能识别出“可能会延期”“可能会超预算”这类谁都能说的废话。

尺子就是成功标准。它规定了什么状态叫达标、什么状态叫偏离、什么状态叫失败。有了这三个状态，风险才有“等级”可言；没有这三个状态，风险评估就只能靠直觉打分，而直觉打分在跨部门会议上几乎不具备约束力。

2. 可用的成功标准必须同时满足三个条件

我在项目复盘时用一个很简单的筛子，一条成功标准如果同时满足下面三条，才算合格：

• 可测量：存在客观数值或可判定的二值状态，而不是“明显提升”“基本满意”。
• 可验收：明确写出验收人、验收证据、验收时间点，三者缺一不可。
• 可归因：当指标没达标时，能追溯到具体的工作包、供应商或决策节点，而不是全项目一起背锅。

这三条里最容易被忽略的是第三条。很多项目的成功标准写得很漂亮，比如“用户满意度达到90分”，但满意度是个结果指标，出问题时你无法定位到底该改哪一段流程，风险应对就无从下手。

3. 风险控制不是四步法，而是一个四段闭环

“识别，评估，应对，监控”这个框架本身没错，但它描述的是动作序列，不是逻辑闭环。真正能跑起来的结构应该是：成功标准 → 失败场景 → 控制动作 → 验收证据，然后再由验收证据反向校正成功标准。

这个闭环的关键差异在于起点。传统四步法的起点是“可能存在什么问题”，新闭环的起点是“我们要达成什么，什么情况下算没达成”。前者发散，后者收敛。

二、背景和真实场景：为什么风险总在验收时集中爆发

要理解成功标准为什么重要，得先看清风险爆发的真实路径。我梳理过自己参与过的项目复盘记录，风险的爆发点高度集中，而且集中在一个让人意外的时间位置，不是项目前期，也不是中期，而是收尾和验收阶段。

1. 我见过的三类“目标模糊”项目

第一类是口号型目标。项目章程里写着“打造行业领先的XX平台”，这句话在启动会上很有感染力，但它无法回答任何一个具体的验收问题。这类项目的中期通常很顺利，因为没人能证明它偏离了目标；到了验收阶段，所有人同时发现自己对目标的理解不一样。

第二类是转移型目标。项目负责人意识到目标太虚，于是把它替换成了易于测量的过程指标，比如“完成12个迭代”“上线38个功能点”。这种做法的风险在于，过程指标达成不等于业务价值达成，项目会变成“完成度很高但没人用”的典型。

第三类是单维型目标。只抓进度，或者只抓成本。这是最危险的一类，因为它在项目期间几乎不会报警，只要甘特图是绿的，一切都显得正常，直到质量或合规问题在验收时一次性爆发。

2. 验收扯皮的三种典型剧本

剧本一：业务方说“这不是我要的”，技术方说“需求文档就是这么写的”。本质是成功标准只定义了功能范围，没有定义业务结果。

剧本二：业务方说“能用了，但性能不行”，技术方说“合同里没写性能指标”。本质是成功标准缺少非功能性条款的量化阈值。

剧本三：所有人都认可结果，但没人愿意签字，因为“签字意味着承担责任”。本质是成功标准没有指定唯一的验收责任人。

这三种剧本我都在不同项目上遇到过，它们的共同点是：问题在项目开始的第一周就已经埋下了，只是在验收时才被看见。

3. 为什么“按时交付”是最危险的成功标准

进度是最容易测量、最容易汇报、也最容易掩盖问题的指标。当项目把“按时交付”当作唯一成功标准时，团队会自发地把质量、成本、收益压力全部后置，先上线，再说别的。

这种选择在短期内看起来是理性的：进度是硬约束，质量可以后续补。但补的成本通常是指数级的，而且补的过程本身会制造新的风险，比如技术债导致的稳定性问题、临时方案导致的合规缺口。

三、拆解常见误区：为什么大部分风险清单最后都躺在文件夹里

我在做项目健康度评估时，会把项目组的风险登记册调出来看。判断一份风险清单是否有效，不需要看内容质量，只看两个字段就够了：有没有责任人，有没有触发条件。这两条缺一条，这份清单基本不会被执行。

1. 把风险管理当成文档任务

很多项目在启动阶段产出一份风险登记册，然后它在整个项目周期里只被打开过两次：一次是写的时候，一次是结项归档的时候。这不是态度问题，而是设计问题，如果风险清单不与例会、不与阈值看板、不与变更流程挂钩，它就没有被使用的场景。

纠正动作很具体：把风险登记册的“状态”和“最近更新日期”作为周会必看项，超过两周未更新的高等级风险自动升级到项目负责人本人。

2. 只评估不监控

评估是静态的，监控是动态的。我见过很多项目做了详细的风险概率-影响矩阵，给每条风险打了分，然后就没有然后了。问题在于，概率和影响会随着项目推进而变化，一个中期被评估为“低概率”的风险，在关键路径上可能已经变成了高概率。

我的做法是给每条高等级风险挂一个“观察信号”，这个信号必须是可被自动或半自动采集的，比如环境可用率、缺陷回归率、供应商交付准时率。信号一变，等级就重算。

3. 风险没有责任人和触发条件

“责任人：项目组”等于没有责任人。“触发条件：进展不顺利”等于没有触发条件。这两个字段的写法直接决定了风险应对能否启动。

合格的责任人必须是单个自然人，且这个人有调动相应资源的权限。合格的触发条件必须包含指标名、阈值和持续时间三个要素，例如“联调环境可用率低于80%，且连续3个工作日”。

4. 成功标准没有验收证据

这是最隐蔽的一个误区。很多团队确实写了量化标准，比如“系统响应时间小于200毫秒”，但没有约定用什么方式测、在什么环境下测、测多少次取什么值。结果验收时双方各测一次，数据不一样，又回到扯皮状态。

成功标准如果没有绑定证据形式，它就只是一个意向，不是一个标准。

5. 变更后不更新成功标准与风险清单

变更控制流程通常管住了范围和工期，却漏掉了成功标准和风险清单的同步更新。结果是项目结束时，成功标准还是三个月前那一版，而实际交付内容已经变了三轮。

我在流程里加了一个强制动作：任何被批准的变更，必须同时提交“成功标准影响说明”和“风险清单更新记录”，否则变更单不予关闭。

6. 用KPI堆砌代替成功标准

还有一种反面案例：项目组一口气写了二十几条指标，看起来很严谨，但没人知道哪几条是必须守住的红线，哪几条是可以让步的。指标太多等于没有优先级，没有优先级就无法在资源冲突时做取舍。

我的建议是控制在六到八条，并且明确标注哪些是“一票否决项”。

四、专业判断逻辑与8步操作法

下面这套方法是我在多个交付项目上反复调整后的版本。它不依赖任何特定工具，用电子表格也能跑，但如果项目规模超过五十人或者涉及强合规要求，用文档和表格维护会很快到达上限。

1. 第一步：对齐项目目标与成功标准

动作：把项目章程里的目标句子拆成可判定的陈述，逐个问“这句话达成时，我们看到的现象是什么”。

输出物：一页纸的项目目标澄清记录，包含目标陈述、现象描述、判定人。

常见错误：把目标澄清会开成动员会，最后仍然只留下一句口号。

2. 第二步：将成功标准转为可验收指标

动作：为每条标准补齐六个字段，指标名、目标值、测量方式、测量环境、验收人、验收证据。这六个字段构成一张“成功标准卡”。

输出物：成功标准卡，建议控制在六到八条，标注一票否决项。

常见错误：只写目标值不写测量方式，导致验收时口径不一致。

3. 第三步：反向识别失败场景与风险源

动作：对每一条成功标准，强制提出三到五个“什么情况会让它失败”的问题。这一步的关键是从标准倒推风险，而不是从经验正向罗列风险。

输出物：失败场景清单，按成功标准分组，而不是按风险类别分组。

常见错误：直接套用通用风险清单模板，导致识别出的风险与项目实际目标无关。

4. 第四步：评估概率、影响与风险等级

动作：用统一的评分口径给概率和影响赋值，再合成等级。评分口径必须在项目启动时定好并公示，避免后期随意调整。

输出物：带等级的风险条目，红黄绿三色分层。

常见错误：概率和影响都由项目负责人一个人拍，导致评估结果失去干系人认同。

5. 第五步：设置阈值、触发器与预警线

动作：为每条红色和黄色风险定义触发信号，信号必须包含指标名、阈值、持续时间。同时定义绿色、黄色、红色三档状态的判定规则。

输出物：阈值定义表，与监控看板一一对应。

常见错误：阈值设置过松，风险永远不触发；或者过严，告警疲劳导致没人看。

6. 第六步：制定应对策略与备用方案

动作：每条高等级风险至少给出一个主方案和一个备用方案，并明确备用方案的启用条件。这里可以借用风险应对的四种基本策略：规避、降低、转移、接受。

输出物：风险应对计划，含主备方案、启用条件、所需资源。

常见错误：只写“加强监控”，这是状态描述，不是应对策略。

7. 第七步：明确责任人、资源与升级路径

动作：指定唯一责任人，明确其可调动的资源，并写明当应对失败时向谁升级、多长时间内必须升级。

输出物：责任矩阵与升级路径图。

常见错误：责任人只有义务没有权限，导致风险应对停留在口头。

8. 第八步：嵌入监控、变更与复盘闭环

动作：把阈值看板接入周例会，把变更流程与成功标准、风险清单强绑定，把每次复盘的结论回写到标准卡中。

输出物：周度风险看板、变更影响评估记录、复盘回写记录。

常见错误：复盘只总结“做得好与不好”，不产出对成功标准的具体修订。

下面是一份可以直接改成自己字段的风险登记条目模板，用 YAML 写是为了方便之后接自动化脚本或导入项目平台：

risk_id: R-014
title: 核心支付网关联调延期

linked_criteria: SC-02 支付成功率 >= 99.5%（上线首周）

category: 进度 / 技术

trigger_signal: 联调环境可用率 < 80%，连续 3 个工作日

probability: 0.4

impact: 0.8

risk_level: 红

owner: 后端负责人 / 指定唯一自然人

strategy: 降低

action_plan:

6月10日前完成沙箱环境双活

6月12日前完成备选通道压测

fallback_plan: 启用备选通道，首周灰度 10% 流量

escalation: 触发后 24 小时内升级至项目负责人

deadline: 2025-06-12

evidence: 压测报告 v1.2 / 灰度监控看板

status: 处理中

last_review: 2025-06-05

如果风险条目数量超过三十条，手工维护等级会很吃力。一个轻量的自动化方式是先用脚本算等级，再人工复核红色项：

def risk_level(probability, impact):
score = probability * impact

if score >= 0.45:

return "红"

if score >= 0.20:

return "黄"

return "绿"

阈值 0.45 和 0.20 不是标准答案，而是需要在项目第一次风险评审时由团队共同确认并写入项目规范的数字。关键是这两个数字一旦确定，就不能因为某条风险“看起来比较重要”而临时调整。

五、案例与数据观察：一个中大型研发交付项目的180天

这一节我讲一个真实的项目结构，涉及的具体数字做了脱敏和区间化处理，但过程和方法与实际情况一致。项目背景是一家制造企业的数字化交付项目，参与方包含企业IT、业务部门、外部实施方和一家硬件供应商，项目周期约180天。

1. 项目初始状态：目标清晰，标准模糊

项目章程里写的成功标准是三条：按计划上线、覆盖三个核心业务场景、用户可正常使用。这三条在项目启动会上获得了全体通过，但我在第二周做访谈时发现，三个不同的干系人对“可正常使用”的理解完全不同。

IT负责人的理解是“功能可用、无阻断性缺陷”；业务负责人的理解是“一线员工愿意用、不用回到老系统”；实施方的理解是“通过验收测试用例”。这三种理解在项目中期不会产生冲突，但在验收时会全部爆发。

2. 第一步改造：用成功标准卡替换三条模糊标准

我们花了两次会议把三条标准拆成了七条卡片化标准。举其中两条：

SC-02：上线首周支付成功率不低于99.5%，数据来源为网关侧日志，验收人为IT运维负责人，验收证据为系统导出的成功率报表。

SC-05：上线后第30天，三个核心业务场景的一线员工自主使用率不低于80%，数据来源为账号登录行为统计，验收人为业务负责人，验收证据为月度使用报告。

关键变化不在于指标本身，而在于每条标准都绑定了验收人和证据形式。当业务负责人被明确写为SC-05的验收人时，他在中期的参与度发生了明显变化。

3. 第二步改造：反向识别失败场景，从44条收敛到11条

针对七条成功标准，团队第一轮识别出44个失败场景。第二轮做了合并和筛选，保留11条主风险、3条观察项。

筛选标准有三条：是否影响一票否决项、是否具备可采集的触发信号、是否有明确的应对责任人。三条都不满足的场景，直接归入观察清单，不进入正式登记册。

这个收敛过程很重要。很多项目的风险登记册写了四五十条，看起来非常完备，但真正被监控的可能不到五条。少而可执行，远胜多而无人看。

4. 第三步改造：阈值、红黄绿看板与升级路径

我们为11条主风险全部定义了触发信号。举一条典型：硬件供应商交付准时率低于95%，且距离计划到货日不足10个工作日，触发黄色预警；低于90%且不足5个工作日，触发红色升级。

红黄绿看板接入周例会，会议议程被压缩为三项：上周触发的信号、正在执行的应对动作、需要跨部门协调的资源。进度汇报被移到书面材料，会上不再逐条过任务。

这个调整带来的变化非常直接：会议时长从90分钟压缩到45分钟，而讨论质量问题的时间占比从不到10%上升到接近40%。

5. 第四步改造：用平台承载闭环

项目进行到第60天的时候，团队遇到一个现实问题：成功标准卡、风险登记册、变更单、验收证据分散在三个不同的工具里，跨工具的追踪全靠人工同步，光是每周更新一次风险状态就要花掉将近两天的人力。

我们评估了几个方向，最终选择了 PingCode 来承载这套闭环。选择理由有三点，都是从项目实际约束出发的。

第一，需求、缺陷、测试、迭代本来就在同一个平台里。成功标准卡可以直接挂到需求条目上，验收证据可以挂到测试报告上，不需要人工维护跨系统映射关系。我们之前用表格的办法，最大的成本就是这份映射表每两周就会失真一次。

第二，PingCode 支持私有化部署。这个项目涉及制造企业的生产数据，客户的信息安全要求明确不允许核心数据出内网。私有化部署这一点在选型阶段是硬门槛，不是加分项。

第三，支持从 Jira 平滑迁移。客户的IT团队此前一直用 Jira，历史项目数据、字段配置、工作流都有沉淀。迁移成本如果过高，方案再好也推不动。PingCode 在这方面的迁移路径相对成熟，我们也因此省掉了大量数据清洗工作。

需要说明的是，PingCode 主要服务中大型企业及100人以上组织。如果是一个十人以下的团队做短期项目，用表格加一次周会就足够了，上平台反而增加负担。这一点我在下面的取舍章节会展开。

6. 第四步改造后的数据变化

闭环运行到第120天时，我们做了一次中期对照。需要强调的是，这些数字是单个项目的观察结果，受团队成熟度、客户配合度等多重因素影响，不能直接外推到其他项目。

但有一个变化我认为是可复用的：风险从被发现到进入正式处理流程的平均时长，从原来的两周以上压缩到一周以内。这个指标比“风险数量”更能说明风险控制体系是否在真正运转。

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

同一套方法在不同项目阶段的落地方式差别很大。下面按我实际遇到的几种典型情境分别说。

1. 项目刚启动的0到2周

这是成本最低、收益最高的窗口。建议把第一次成功标准澄清会安排在和启动会同一天或次日，参会人必须包含所有最终验收人。

会议输出不是会议纪要，而是一张成功标准卡草稿。草稿可以粗糙，但六个字段必须齐全，尤其是验收人与验收证据两栏必须填具体的人名和具体的文件形式，不能写“业务部门”“测试报告”这类泛指。

这个阶段最常见的阻力是“现在还不知道细节，先做起来再说”。我通常的回应是：先做起来可以，但请明确写下“不清楚的部分在第几周澄清”，把它变成一条带时间的风险，而不是一个默认的空白。

2. 项目中期发现成功标准不清

这种情况更常见，处理方式要克制。不要在项目中期重新定义整个成功标准，那会引发大规模变更和团队信心崩塌。

我的做法是只做“增量澄清”：把当前已经在推进的工作按现状写清楚，然后只对那些尚未启动或尚未定型的工作补上量化标准。已经完成的部分，用现状作为基准线，不再追溯。

同时启动反向识别，重点找那些“一旦不达标就无法补救”的项，比如合规审查、外部接口对接、硬件采购。这类风险越早暴露越有价值。

3. 项目末期或验收前的2到4周

这个阶段最忌讳的是重新讨论“什么叫成功”，那时候讨论已经无法改变交付物，只会推高冲突。正确的动作是转向证据准备。

把每条成功标准对应的验收证据逐条核对一遍：数据是否已经采集、采集口径是否和当初写的一致、验收人是否已经看过中期结果。如果发现某条标准缺少证据，立即启动补采，而不是等验收会上解释。

如果确实存在无法达成的标准，主动提出变更比被动接受否决要好。我的经验是，主动提出的变更在谈判中往往能换来部分认可，而验收会上被指出的问题基本只能全盘接受。

4. 多项目并行的PMO视角

PMO 最容易犯的错误是要求所有项目使用同一张风险登记册模板。模板可以统一，字段可以统一，但阈值不能统一，一个研发项目的进度偏差容忍度和一个工程项目的安全偏差容忍度完全不是一回事。

我的建议是PMO只统一三件事：风险条目的必填字段、红黄绿状态的判定规则、升级路径的时限要求。其余留给项目负责人自行决定。

另外，PMO 应该把“高等级风险的更新及时率”作为核心考核指标，而不是“风险数量”。前者反映体系是否运转，后者只反映团队会不会写文档。如果组织内项目数量多、并行度高，用平台做跨项目的风险视图会比用表格汇总现实得多，这也是中大型组织在项目组合管理上通常会走到系统化这一步的原因。

5. 强监管或工程类项目

这类项目的成功标准中，合规项通常需要前置为“一票否决项”，并且在项目早期就完成外部审查路径的确认。技术负责人在这一环节要格外注意：安全和质量类风险不能只用概率评估，因为一旦发生就是不可逆的。

我的做法是给这类风险单独设一栏“不可逆性”，只要标记为不可逆，无论概率多低，应对策略都必须是规避或转移，不能选择接受。

七、不同情况下的取舍

前面讲的是怎么做，这一节讲的是什么时候不这么做。项目负责人真正的专业能力，往往体现在知道哪一步可以省、哪一步绝对不能省。

1. 速度与完备性：什么时候可以减少文档

如果项目周期短于六周、参与人数少于八人、失败后果可逆，那么成功标准卡可以压缩到三条，风险登记册可以只保留红色条目，不需要完整的红黄绿体系。

但如果项目涉及资金支出、外部合同、生产环境数据或监管要求，即使周期短，成功标准卡也一条不能少。判断标准不是项目大小，而是失败的后果是否可逆。

2. 干系人签字确认与快速启动

要求全部干系人签字确认成功标准，在跨部门项目里往往需要一至两周。如果时间紧迫，可以采取“确认制”替代“签字制”：把成功标准卡发出去，明确说明“三个工作日内未提出异议即视为确认”。

这个做法在效率上有明显优势，但它有一个前提，必须留下可追溯的发送记录和回复记录。口头告知后直接开工，后面同样会扯皮。

3. 表格与平台：什么时候该上系统

这是我被问得最多的问题。我的判断依据是三条：风险条目是否超过30条、是否涉及跨部门多人协同、是否有审计或追溯要求。三条中满足两条，表格就会开始成为瓶颈。

具体的瓶颈表现很典型：风险状态更新滞后、跨工具映射失真、验收证据找不到对应版本。当团队每周花在“对齐信息”上的时间超过四小时，上平台的投入就开始划算了。

选平台时我会重点看三件事：能不能把成功标准、需求、测试、证据放在同一个数据模型里；能不能私有化部署；历史数据迁移成本有多高。第三点往往被低估，但它是决定方案能否真正落地的关键，很多选型失败不是因为新系统不好用，而是因为老数据搬不过去，团队不得不同时维护两套系统。这也是我在中大型项目里会优先考虑支持平滑迁移方案的原因。

4. 严格变更控制与敏捷响应

变更控制严格到什么程度，取决于成功标准的稳定性要求。如果成功标准里包含合同金额、交付日期、合规条款，那么变更必须走完整评估；如果成功标准主要是业务结果类指标，变更的空间可以大一些。

我通常会在项目规范里明确写一条：影响一票否决项的变更，必须经项目负责人和验收人双签；不影响一票否决项的变更，可授权到工作包负责人。这样既保证了红线，又避免了所有变更都堵在一个节点。

5. 私有化部署与SaaS的取舍

私有化部署的优势是数据可控、可对接内网系统、满足合规要求，代价是运维成本和升级节奏。SaaS 的优势是开箱即用、迭代快，代价是数据边界和定制能力。

我的经验判断是：只要项目涉及生产数据、个人敏感信息或客户明确要求数据不出内网，就不要在私有化上纠结成本，这是必选项而不是可选项。反过来，如果只是内部协作工具且数据敏感度低，SaaS 的启动成本优势会非常明显。

需要提醒的是，私有化部署的隐性成本通常出现在升级和安全补丁环节，评估时应把未来两到三年的运维投入一并算进去，而不是只看初次部署费用。

八、项目负责人的判断清单

写到这里，我把整套方法压成五个问题。这五个问题是我在做项目健康度评估时实际使用的，任何一个答不上来，项目就存在结构性的风险控制缺口。

• 成功标准清楚吗？能不能在没有额外解释的情况下，由第三方独立判断是否达成？
• 失败场景列了吗？每条成功标准下面，是否都有对应的失败场景，而不是一份通用风险清单？
• 阈值设了吗？每个高等级风险是否有可采集的触发信号，包含指标名、阈值和持续时间？
• 责任人有吗？每条风险是否落到单个自然人，且这个人有调动资源的权限？
• 证据留了吗？每条成功标准是否绑定了具体的验收证据形式，且证据在过程中被持续采集？

最后还有一个我认为更重要、但很少被写进方法论的问题：当成功标准需要被修改时，改动的流程是什么？项目做到一半，成功标准一定会遇到需要调整的时刻。如果修改过程没有明确规则，那么前面所有的工作都会在一次随意的妥协中失效。

结尾：把目标翻译成可验收、可预警、可行动的标准

回到开头那个验收会。那位业务方负责人和技术负责人其实都没有错，他们只是拿着两套不同的成功标准在对话，而这两套标准从来没有被写成同一份文件。

我的核心观点是：项目负责人的风险控制能力，不体现在能列出多少条风险，而体现在能否把项目目标翻译成可验收、可预警、可行动的标准。成功标准定义方向，失败场景定义边界，控制动作定义响应，验收证据定义终点。这四件事连起来，风险才真正被管住。

如果你现在手上就有项目在跑，我建议下一步从这三件事开始：

1. 找出当前项目的成功标准原文，逐条检查是否具备目标值、测量方式、验收人、验收证据。缺少任意一项的，标记出来。
2. 挑其中最重要的一条，做一次反向识别，写出五个可能让它失败的具体场景，并为每个场景写一个可采集的触发信号。
3. 把这份内容带到下一次周会上，用二十分钟确认阈值和责任人，然后把它挂进例会议程，而不是存进文档库。

做完这三步，你就会发现风险管理的重心从“整理清单”变成了“盯住信号”。而当你连续几周都能在风险爆发前看到信号变化时，成功标准就从一份项目文档，变成了项目真正在用的控制面板。