状态怎么做？管理层风险控制：任务属性从0到1

我在一次季度经营复盘会上碰到过一个很难忘的场面：一个投入 60 多人、排期 9 个月的重点项目，在研发管理平台里连续 6 周显示为「进行中」的绿色状态，直到交付前 3 周才一夜之间变红。会后我把它的状态流转记录导出来逐条看，发现真正的卡点不是团队不努力，而是它所依赖的底层平台改造任务，在「待联调」这个状态里停了整整 21 天，这个状态既没有绑定责任人，也没有触发任何升级规则，更没有任何人知道它停了这么久。

管理层的仪表盘没有说谎，它只是用错误的粒度在看世界。

这件事让我彻底换了一个角度看「状态」这个字段。很多团队把状态当成一个界面细节、一个下拉框、一个可以随手加两个选项的东西；而我在做过几轮状态治理之后越来越确定：状态是管理层风险控制的最小可观测单元，它决定了管理层能在多早的时候发现偏离，以及发现偏离之后能不能立即采取动作。这篇文章讲的「任务属性从 0 到 1」，重点不在字段本身，而在于如何用一套可控的状态与属性体系，把风险从「事后救火」变成「提前暴露」。

一、核心结论：先把结论摆在桌面上

在进入具体做法之前，我想先把这几年的判断一次性讲清楚。它们不是教科书结论，而是我在多次状态重构中反复验证、也反复被现实打脸后沉淀下来的东西。

1. 状态不是进度显示，是管理动作的触发器

这是我最有把握的一条判断：任何一个状态，都必须对应一个明确的管理动作。如果一个状态不触发任何人的任何动作，它就不应该存在。「待评审」对应的动作是评审人要给出结论；「阻塞」对应的动作是项目经理要解阻并指定解阻时间；「待验收」对应的动作是业务方要在 SLA 内确认。如果一个状态既不需要谁催办，也不需要谁升级，也不需要谁决策，那它只是执行者给自己写的一行日记。

我见过最多的浪费，就是团队为了让执行者「感觉更精确」，加了一堆没有管理动作的状态。这些状态在管理层视图里完全不产生价值，却每天都在消耗所有人的填报时间。

2. 状态必须携带「承诺三要素」

状态本身只是一个词，词是没有约束力的。真正让状态产生管理价值的，是它背后绑定的三样东西：责任人、时间承诺、准出条件。三者缺一，状态就退化成装饰。

• 责任人：谁为「离开这个状态」负责，而不是谁在「待在这个状态」。
• 时间承诺：在这个状态里最多待多久，超过多久触发升级。
• 准出条件：满足什么客观条件才允许流转，避免「手一滑就完成了」。

尤其第三条，是我认为被低估最严重的一条。没有准出条件的「已完成」，是管理层最大的风险来源，因为它是全系统里唯一一个无法被复核的绿灯。

3. 从 0 到 1 应该分四个阶段走，而不是一步到位

很多团队一上来就想设计一套「完美工作流」，结果三个月后没人用。我的经验是分四步：先立骨架，再收噪声，再加约束，最后做自动化。每一步都有明确的进入条件和退出条件。

二、真实场景：状态是怎么从 8 个膨胀到 43 个的

结论说完，我要讲一个我亲手参与过的现场。这家公司大约 300 人，硬件加软件混合，两条产品线，研发、测试、供应链、交付四个职能交叉协作。我第一次进去的时候，研发管理平台里一共配置了 43 个任务状态。

1. 43 个状态是怎么长出来的

我把这 43 个状态按出现顺序排了一遍，发现问题不是某个人乱来，而是三条非常合理的路径叠加出来的。

第一条路径是职能自建。测试团队觉得「测试中」太粗，拆成了「用例编写中、用例评审中、环境准备中、测试执行中、缺陷回归中」。每一条拆得都对，但拆完之后没有任何一条绑定了管理动作或 SLA。

第二条路径是流程补丁。某次出事故后，为了强制卡一道评审，就加了一个「待安全评审」状态。等到评审批次改为季度批量之后，这个状态没人管了，但也没人删。

第三条路径是工具迁移。从旧系统搬迁时，为了「不丢数据」，做了一次一对一映射，旧系统的 19 个状态原样保留下来。这条路径贡献了最多的僵尸状态。

2. 管理层看到的「绿灯」到底是怎么产生的

复盘之后我发现，「绿色项目突然变红」这件事有三个具体的机械原因，而且每一个都不是靠换工具能解决的。

第一，状态是执行者自己维护的，而执行者天然倾向于选择「看起来没事」的状态。在 43 个状态里，「联调中」和「受阻」都被允许存在，而前者听起来体面得多。当没有人对状态选择的准确性负责时，人的选择会系统性地偏向乐观。

第二，没有停留时长阈值，所以「待了 21 天」和「待了 2 小时」在界面上长得一模一样。管理层看到的是一个静态标签，而不是一个已经超期的异常项。这是一个非常纯粹的展示层缺陷。

第三，状态与管理层的风险分类之间没有映射。管理层关心的是「这个季度能不能交付」，而平台展示的是 43 个执行细节。中间缺少一层聚合规则，管理层就只能靠项目经理口头转述，而口头转述天然会延迟。

三、七个常见误区：为什么大多数团队的状态设计是无效的

状态设计这件事，做错的方式比做对的方式多得多。我把见过的失败案例归纳成七条，前四条是认知层，后三条是机制层。

1. 用百分比代替状态

「这个任务 60% 完成」是研发管理里最没有信息量的一句话。60% 是怎么算出来的？是工作量还是时间？谁来验证？它既不指向责任，也不指向动作，更无法比对。

百分比最大的问题是不可比：A 团队的 60% 和 B 团队的 60% 完全是两回事，管理层拿它做任何横向判断都会出错。状态的本质是离散的、可定义的、可复核的；百分比本质是连续的、主观的、不可复核的。用后者替代前者，等于把风险控制建立在叙事上。

2. 认为状态越多越「精细」

状态数量和管理精度不是线性关系，而是一条先升后降的曲线。状态太少，无法区分问题类型；状态太多，填报者开始在相近状态之间随机选择，数据一致性反而崩塌。

我在一家 800 人的企业里做过一次抽查：让他们对同一批 30 个已经完成的任务重新标注状态，然后和原始记录比对。当状态集只有 8 个时，一致性是 86%；当状态集有 35 个时，一致性掉到了 54%。一致性掉到 60% 以下，任何基于状态的数据分析都是自欺欺人。

3. 让执行层自由自定义状态

「团队自治」在工程实践上通常是好事，但在状态这件事上是灾难。因为状态是跨团队协作的接口，接口一旦各自定义，就会立刻出现「你的阻塞不是我的阻塞」的问题。

我接受的做法是：主状态全局统一，子状态可以有限自治。主状态是管理层的语言，必须收口；子状态是执行层的语言，可以按团队习惯保留，但必须挂在明确的主状态之下，不能平行存在。

4. 只让状态回答「做完了没」

这是最容易被忽略的一条。如果一个状态集只覆盖「未开始、进行中、已完成」，那它只能回答进度问题，完全无法回答风险问题。而管理层真正需要回答的是：哪里可能延迟、延迟的原因是什么、需要谁介入。

所以状态集里必须显式地包含偏离信号类状态，比如「阻塞」「等待外部依赖」「返工」「待决策」。这些状态的存在本身就是一种预警机制。我甚至认为，一个状态集里如果没有至少两个偏离信号状态，它就不具备风险控制能力。

5. 状态变更没有权限约束、没有留痕

我见过太多「谁都能把任务拖到已完成」的配置。这种情况下状态数据是不可信的，因为它没有成本。有成本的数据才有价值：把任务推进到「已完成」需要满足准出条件，把任务标记为「阻塞」需要填写原因和解阻责任人，把任务从「已完成」拉回「开发中」需要记录返工原因。

这些约束听起来麻烦，但它们正是状态的防伪成本。没有防伪成本的数据，在管理决策中的权重应该被视为零。

6. 状态与工作流脱钩

状态应该是工作流的节点，而不是一个独立的下拉框。区别在于：在工作流里，状态之间只能按允许的路径流转，往前和往后都有代价；而一个自由下拉框里，任务可以从「待澄清」直接跳到「已完成」，中间没有任何记录。

当状态是自由下拉框时，你拿不到真正的流转时长和返工路径，也就失去了最有价值的两个数据维度。这是我判断一个团队的状态设计是否可用的分水岭。

7. 一开始就追求全局统一

这是我早期犯过的错。我试图在两周内让四条产品线使用同一套状态集和同一套准出条件，结果是被拖进了三个月的争论。不同业务的真实流转差异是存在的，强行统一只会让人绕过系统。

后来我改成：先在一个 30-50 人的试点单元里跑通，用真实数据证明它比原来好，再横向推广。推广时的阻力下降了非常多，因为反对者要面对的是数据，而不是我的观点。

四、专业判断逻辑：任务属性从 0 到 1 的四层设计框架

讲完误区，我说说我现在实际使用的框架。它不是从工具文档里抄来的，而是在多次重构中被现实修剪过的版本。整个框架分四层，从下往上依次是语义层、承诺层、信号层、聚合层。

1. 第一层：状态语义层

语义层的任务只有一个：让任意两个角色对同一个状态的理解一致。我用的检验方法很土但很有效，让产品、开发、测试各写一句话描述「这个状态意味着什么，谁该动手」，然后对比三句话。如果三句话的主角不是同一个人，这个状态的语义就是失败的。

在这个基础上我做状态收敛，收敛的规则有三条：

1. 把只描述「某人正在做事」但不指向任何交接的状态合并，比如「编码中」和「自测中」通常可以合并为「开发中」。
2. 把只描述时间点而不描述责任的状态改造成事件，比如「已提测」可以变成一条记录而不是一个状态。
3. 把「待 X 评审」这类状态限定为必须有 SLA 的阻塞点，否则合并回上一状态并作为子字段标记。

按这三条规则，那家 300 人企业的 43 个状态收敛到了 11 个主状态加 9 个子状态。收敛之后，跨团队沟通里「他说他在等测试」这种模糊表述基本消失了。

2. 第二层：承诺层

承诺层是给每个主状态绑定责任人、时间承诺、准出条件。这是整个框架里工作量最大、也最容易被跳过的一层，但它恰恰是管理层风险控制真正落地的地方。

（1）责任人的定义方式

我不写具体人名，而是写角色 + 兜底角色。比如「待验收」的责任人是业务验收人，兜底角色是产品负责人。原因是组织会变，人名会变，但角色和兜底关系相对稳定。兜底角色的意义在于：当主责任人缺位时，系统知道该把升级通知发给谁。

（2）时间承诺的设定方式

时间承诺不建议一刀切，我通常按状态类型分三档：

• 执行类状态（开发中、测试执行中）：用工作量估算，不做硬性 SLA，但做异常检测，比同类任务中位数超出 1.5 倍时提醒。
• 等待类状态（待评审、待验收、等待外部依赖）：必须设硬性 SLA，因为这类状态的耗时几乎全部是排队，是可压缩的管理损耗。
• 异常类状态（阻塞、返工）：必须设极短 SLA，通常 1-2 个工作日，并直接升级到项目管理层。

（3）准出条件的设计方式

准出条件必须是机器可校验的客观事实，而不是「质量达标」这种描述。我的经验是，一条合格的准出条件要能被写成一句可判断真假的语句。比如「验收标准字段非空」「已关联至少一个业务目标或客户问题单」「关联的自动化测试用例通过率 100%」。做不到这一点的条件，就退化成一句备注。

3. 第三层：偏离信号层

这一层是我认为最体现「管理层视角」的地方。执行层需要的是状态流转，管理层需要的是偏离暴露。二者不是一回事，所以我在状态集里显式保留四个偏离信号维度：

请注意最后一行。「待决策」这类状态的价值极高，因为它把管理层的响应速度变成了可测量、可追责的东西。我在不止一家公司里发现，真正拖慢交付的不是研发效率，而是等管理层决策的平均 6.4 天。当这个数字被摆在台面上之后，变化发生得比任何流程改革都快。

4. 第四层：聚合与映射层

最后一层是解决「管理层不应该看 40 个状态」这个问题的。做法是建立两组映射规则。

第一组是执行状态到风险桶的映射。我会把全部主状态压缩成五个风险桶：顺利推进、排队等待、存在阻塞、质量返工、等待决策。管理层只看这五个桶的分布和变化趋势，而不是看具体状态。

第二组是承诺偏离度映射。每个任务计算一个「承诺偏离度」，等于实际停留时长除以承诺时长。偏离度小于 1 是正常，1 到 1.5 是关注，超过 1.5 是升级。这个指标最大的好处是可以跨团队横向比较，而且它不依赖任何主观判断。

5. 五条可以立刻用起来的命名与配置准则

如果上面四层框架太长，我把它压缩成五条可以直接抄的准则：

1. 状态名必须包含角色动作，比如「待评审」比「评审」好，因为它隐含了等待的对象。
2. 每个状态都要能回答「下一步谁动手」，答不出来的状态直接删除。
3. 偏离信号状态不超过 4 个，多了会被稀释，失去信号意义。
4. 准出条件不超过 5 条，且至少 3 条可机器校验，否则维护成本会超过收益。
5. 新增状态必须走变更流程，包括提出理由、预估影响范围、指定退出条件。这一条看起来是行政手段，但它挡住了 80% 的状态膨胀。

五、落地案例与数据观察：一家 300 人企业用某项目管理平台重构状态

下面这个案例是我参与较深的一次，之所以选它，是因为它的数据前后可比，而且踩过的坑比较典型。为保护商业信息，企业名称、行业细节做了模糊处理。

1. 重构前的家底

这家企业约 310 人，研发 190 人，分两条产品线。他们原先使用的是一套海外研发管理工具，工作流高度可配置，几年下来累积了 43 个状态、7 套不同的工作流、大量无责任人状态。最要命的是，其中 12 个状态的名称带有明显的个人习惯痕迹，新人需要口口相传才能理解。

他们选择迁移到 PingCode。原因有三点：一是需要私有化部署，研发数据不能出内网；二是需要平滑迁移历史工单，不能接受「重新开始」；三是团队已经在用多个海外工具，希望尽快收敛到一处。迁移过程中，PingCode 的工作流配置、字段权限和状态流转规则这三块能力基本覆盖了我们方案里需要的所有约束。

2. 我们具体做了四件事

第一，状态收敛。把 43 个状态按照前面讲的三条规则压缩到 11 个主状态 + 9 个子状态。收敛的标准不是「看起来简洁」，而是「每个主状态至少有一条可校验的准出条件」。

第二，补齐准出条件。11 个主状态共定义了 41 条准出条件，其中 29 条是可机器校验的。校验不通过时，任务无法被拖到下一个状态。这一步刚上线时收到了不少抱怨，但两周后抱怨就消失了，因为团队发现它挡住了不少「假完成」。

第三，加入偏离信号。新增「阻塞」「等待外部依赖」「返工」「待决策」四个信号类状态，全部设 1-2 个工作日 SLA，并配置自动升级。这里有个细节很关键：这四类状态的变更必须填写必填字段，阻塞要选原因枚举并指定解阻责任人，返工要填写返工原因分类。字段一旦必填，数据的可用性会有质的变化。

第四，建立管理层映射。把 11 个主状态映射为 5 个风险桶，管理层周会只看风险桶分布、承诺偏离度 Top 20、以及超期未处理状态清单。看板从「全部任务列表」改成了「异常清单 + 趋势」。

3. 一组前后对比数据

下面这组数字是他们内部统计口径，取治理前 6 个月和治理后 6 个月对比。它属于单一组织样本，我把它放出来是为了说明变化的方向和量级，而不是当作普适基准。

我最看重的是第二行和第三行。风险识别提前期从 3.5 天提升到 14 天，意味着管理层从「还有三天交付，现在发现来不及」变成了「还有两周，现在发现可以调整资源」。这两种处境的管理难度完全不在一个量级。

4. 迁移过程中踩到的两个坑

（1）历史状态的一对一映射会污染新体系

我们第一版迁移方案是按旧状态一对一映射到新状态，结果发现旧系统的 12 个僵尸状态把新体系的一致性拉低了。后来改成按「最后流转时间 + 当前责任人 + 是否有未关闭的准出条件」三重规则做语义映射，把历史任务优先映射到语义最近的活跃状态，问题才解决。

这里我要强调一个判断：历史数据的完整性，价值低于新体系的一致性。为了让历史数据好看而牺牲新体系的口径统一，是一笔非常不划算的交易。

（2）自动化规则上线太早会产生告警疲劳

第三周我们上线了第一版自动升级规则，结果因为很多任务的准出条件字段还没填完，系统一天发出 200 多条升级通知。两天之后，所有人开始忽略通知，这比没有通知更危险。

我们的处理方式是灰度上线：先只对「阻塞」「待决策」两类信号开启自动升级，且只发到项目经理层级；等合规率超过 70% 之后再扩展到全部状态和更高层级。这个顺序不能颠倒。

5. 配置示例

下面是他们实际使用的状态配置片段，脱敏后保留结构。可以看到每个状态都绑定了责任人、SLA 和准出条件，并把升级对象写进了配置里。

workflow: 需求交付主流程
version: 3

states:

id: triage

name: 待澄清

owner_role: 产品负责人

backup_role: 产品总监

sla_days: 3

exit_criteria:

验收标准字段非空

已关联业务目标或客户问题单

escalate_to: 产品总监

id: dev

name: 开发中

owner_role: 任务负责人

backup_role: 技术负责人

sla_days: null # 执行类状态不做硬性 SLA

abnormal_rule: 超过同类任务中位数 1.5 倍时提醒

exit_criteria:

关联代码合并请求已合并

自测用例执行完毕

id: blocked

name: 阻塞

owner_role: 任务负责人

backup_role: 项目经理

sla_days: 2

required_fields:

阻塞原因枚举

解阻责任人

预计解阻时间

escalate_to: 项目经理

id: pending_decision

name: 待决策

owner_role: 项目经理

backup_role: 研发负责人

sla_days: 1

required_fields:

待决策事项

决策所需信息

escalate_to: 研发负责人

auto_agenda: true # 自动进入下一次决策会议议程

六、不同规模与场景下的行动建议

状态设计没有通用最优解，规模、行业、交付节奏会显著改变答案。我按我实际遇到过的几类组织给出建议。

1. 50 人以下：先解决「有没有」，不要解决「精不精」

这个规模的核心矛盾是信息同步成本低，口头沟通效率其实很高。所以状态的作用是减少同步会议，而不是做风险管理。

我的建议是 5-6 个主状态起步：待办、进行中、待评审、阻塞、待验收、已完成。不要配 SLA，不要配自动升级，不要配复杂权限。把精力放在两件事上：一是让每个人每天都更新状态，二是每周用状态分布核对一次真实进度。

2. 50-200 人：开始补「承诺三要素」

这个规模开始出现跨团队协作，口头同步开始失效。建议把主状态控制在 8-10 个，并开始为等待类状态配 SLA。

这个阶段最关键的动作是把「等待类」状态从「进行中」里拆出来。因为在 100 人左右的团队里，我观察到等待时间通常已经占到交付周期的 25%-35%，但它全部被隐藏在「进行中」里，管理层完全看不见。

3. 200-1000 人：需要完整的四层框架

这个规模是我认为状态治理收益最大的区间。原因是：交付周期长、跨部门依赖多、管理层与执行层信息断层明显。建议完整实施语义层、承诺层、信号层、聚合层四层，并把偏离信号状态设为必填字段。

这个规模的组织通常已经需要私有化部署和更细的字段权限控制。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，对需要国产替代的团队来说是一个比较务实的选择。选型时我会重点验证三件事：状态流转规则是否支持准出条件校验、必填字段能否按状态配置、能否导出完整的流转历史用于分析。

4. 1000 人以上：必须做多工作流 + 统一聚合

这个规模强行统一一套工作流是不现实的。我的做法是多工作流并存，但统一聚合规则：允许不同产品线有自己的状态集，但每个状态必须映射到全局的五个风险桶，且所有工作流共享同一套偏离信号定义。

这个阶段最重要的治理手段不是设计，而是变更控制。状态和工作流的任何变更都要走审批，要有影响面评估。我在一家 2000 人的企业里见过，因为缺少变更控制，三年内工作流从 3 套变成 27 套。

5. 强监管与硬件制造场景：把准出条件当成合规证据

在这类场景下，状态不只是管理工具，还是审计证据。我的建议是把准出条件与合规检查项对齐，并保留完整的流转审计日志，包括谁在什么时候把任务从哪个状态推到哪个状态。

硬件场景还有一个特殊点：外部依赖状态要单独设 SLA 并绑定对外接口人。因为在硬件项目里，等待打样、等待供应商、等待认证的时间往往能占到总周期的三分之一以上，而这三类等待是最容易被忽略的管理损耗。

七、取舍：状态设计里没有免费的精度

我在推动状态治理时，最常被问到的问题是「能不能既要又要」。我的回答通常是不能。以下是四组真实存在、必须做选择的取舍。

1. 精度与填报成本

状态越细，数据越精确，但填报成本越高。这条曲线不是线性的：状态从 6 个加到 11 个，填报成本上升约 40%，但风险识别能力提升接近一倍；从 11 个加到 25 个，填报成本再上升约 90%，而风险识别能力几乎没有提升，甚至因为一致性下降而倒退。

我的取舍原则是：当新增状态的边际风险识别收益低于边际填报成本时，停止增加。实操中，这个点通常落在 8-12 个主状态区间。

2. 全局统一与团队自治

全局统一有利于横向对比和管理层视图，但会牺牲局部效率；团队自治有利于执行体验，但会破坏聚合能力。我的取舍是分层处理：主状态全局统一（11 个以内），子状态允许自治（每个主状态下不超过 3 个）。

这样一来，管理层永远只看主状态和风险桶，执行层可以在子状态里保留自己的习惯。代价是需要维护一层映射关系，以及定期检查子状态是否被滥用。

3. 自动流转与人工确认

自动流转能省人力，但会引入误判。比如「代码合并后自动流转到待测试」，看起来高效，但如果合并的是空提交或者临时提交，数据就被污染了。

我的判断是：凡是会改变风险结论的流转，必须人工确认；凡是不改变风险结论的流转，尽量自动。举例来说，「开发中」内部的子状态切换可以全自动，但进入「已完成」必须满足准出条件且由责任人确认。这条线要划死。

4. 历史数据保留与干净起步

迁移时几乎所有团队都想保留全部历史数据，但我更倾向于保留原始记录，不保留原始状态语义。也就是说，历史任务的流转日志完整保留（用于审计和复盘），但它们的当前状态按新体系重新映射，不做一对一忠实还原。

理由是：旧状态语义本身是混乱的，忠实还原等于把混乱复制到新体系。这也是我在那家 300 人企业里返工过一次的地方。

八、总结与下一步：30 天把状态从 0 做到 1

写到这里，我想把最核心的几个判断再收一下。状态设计的本质不是把工作过程记录得更细，而是把「什么时候该有人介入」这件事变成系统的默认行为。它是一场关于观测粒度的管理设计，而不是一次字段配置。

如果只能留下三句话，我会留下这三句。第一，一个状态必须对应一个管理动作，没有动作的状态一律删除。第二，状态必须携带责任人、时间承诺、准出条件，缺一样就会退化成装饰。第三，管理层看的不是状态列表，而是风险桶和承诺偏离度。这三句话决定了整套体系是否真正具备风险控制能力，而不是只具备记录能力。

最后给出一个可以立刻执行的 30 天行动清单，它是我在最近几次治理中反复使用的版本：

1. 第 1-3 天：盘点。导出全部现有状态，统计每个状态的任务数量、停留时长中位数、是否有责任人。凡是任务数为 0 或停留时长中位数为 0 的状态，直接标记为待删除。
2. 第 4-7 天：语义对齐。让产品、开发、测试三个角色分别用一句话描述每个保留状态的含义，主角不是同一个人的状态合并。
3. 第 8-12 天：收敛到 8-11 个主状态。同时为每个主状态定义责任角色、兜底角色和至少 2 条准出条件。
4. 第 13-16 天：加入四个偏离信号状态。阻塞、等待外部依赖、返工、待决策，全部配置必填字段和 1-2 个工作日 SLA。
5. 第 17-20 天：建立风险桶映射。把主状态压缩成五个风险桶，把管理层周会看板从任务列表改成异常清单加趋势图。
6. 第 21-25 天：灰度上线自动升级。先只对阻塞和待决策两类信号开启，且只升级到项目经理层级，避免告警疲劳。
7. 第 26-30 天：建立变更控制。新增或修改状态必须提交理由、影响范围、退出条件。这一步决定了三个月后体系还在不在。

如果你的组织正在做国产替代或者从海外工具迁移，选型时我会建议把「能不能配准出条件校验」「能不能按状态配必填字段」「能不能导出完整流转日志」这三件事列成硬性验收项，而不是等到上线之后才发现做不到。这三项决定的是你的状态体系最终能不能承担风险控制职责，而不是仅仅承担记录职责。