状态怎么做？企业管理者实操方法：任务属性从0到1

我在过去几年里参与过三十多家企业的研发管理体系建设，被问到最多的问题不是"怎么排期"，而是"状态到底应该设几个"。一家年营收二十亿的装备制造企业，研发中心在系统里堆了 23 个任务状态，结果项目经理每周要花 4 个多小时手工修正状态字段；另一家 200 人的 SaaS 公司只用了 6 个状态，交付周期反而缩短了 18%。

状态这件事看起来是最不起眼的字段配置，实际上它是交付节拍、责任边界和度量口径的压缩包。你怎么设状态，团队就怎么理解"一件事做完了没有"。

这篇内容我按"从 0 到 1"的顺序拆开讲：先给核心结论，再还原真实场景，然后把最常见的五类误区摊开，接着给出我实际在用的四层推导法，最后用一家 400 人规模制造企业的落地案例说明具体怎么配、怎么迁移、怎么治理，并给出不同规模组织的行动建议和取舍清单。

一、核心结论：状态是责任契约的编码，不是进度条

先把结论摆在这里，后面所有内容都是为这几个判断做论证。如果你时间有限，只看这一节也能拿走 70% 的价值。

1. 状态的数量应该由交接点决定，而不是由部门数量决定

这是我看到的最普遍的认知错位。很多管理者下意识觉得"我们有几个部门，状态就该有几个阶段"，产品、设计、开发、测试、运维各一个状态，看起来井然有序。但真正需要被标记的，不是"某个部门在干活"，而是责任从一个人/角色转移到另一个人/角色的那一刻。

一个部门内部连续工作三天，中间不需要任何状态切换；而一个跨部门的接口交付，哪怕只花了半小时，也必须有一个状态来接住它。判断标准很简单：如果一件事卡在这里，谁会主动去看它？如果答案是"没人"，这个状态就不该存在。

2. 一个可落地的状态机必须同时锁死三件事

值、条件、责任人。缺任何一个，状态就会退化成标签。

• 状态值：有哪些状态，每个状态的语义边界是什么，什么情况算"进入"，什么情况算"离开"。
• 流转条件：从 A 到 B 需要满足什么客观条件，是"有人点了按钮"还是"测试用例通过率 100%"。
• 责任人：谁有权把任务从 A 推到 B，谁只能提意见不能改状态。

我见过太多团队只做了第一件事。结果就是状态值写得很漂亮，但每个人对"开发中"的理解都不一样，有人觉得写了第一行代码就算，有人觉得代码合并才算。没有流转条件的多状态，本质上等于没有状态。

3. 从 0 到 1 的最小可用状态集是 5 个，不是 15 个

我的经验值是：一个标准任务流的最小可用状态集是 5 个，待评估、已排期、进行中、待验收、已完成。这 5 个状态覆盖了"要不要做""什么时候做""正在做""做完了待确认""确认完毕"五个决策点，剩下的大量状态都是在这五个点之间做无意义的细分。

状态膨胀的代价不是线性的。下面这组数据来自我跟踪过的 4 个团队（同一家公司不同事业部，业务复杂度接近，差异主要在状态数量），统计口径是上线后连续 8 周的均值。

4. 状态越"方便改"，数据就越不可信

这句话反直觉，但我验证过很多次。当任何人、任何时刻都能随手拖动卡片改状态时，状态数据的信噪比会快速下降。因为它变成了一种"心情表达"，而不是"事实记录"。

我的做法是引入轻量门禁：关键状态（比如"已完成""待验收"）的流转必须附带一个客观输入，比如关联的测试记录、评审链接、或者至少一个必填的完成说明。不需要审批流，只需要让改动有一点点摩擦。这一点摩擦会过滤掉 80% 的随手改。

5. 度量指标决定状态设计，反过来不成立

这是四层推导法的核心逻辑，后面会展开。简单说：你应该先问"我要度量什么"，是周期时间、阻塞时长，还是交付吞吐？然后倒推需要哪些状态作为观测点。先设计状态再想指标，几乎必然要返工。

二、背景与真实场景：状态表是怎么一步步变成"废表"的

状态体系很少是被一次性设计坏的，绝大多数是"长坏"的。理解这个过程，比记住一套模板更重要。

1. 从 Excel 到项目管理平台的三次迁移

我观察到的典型路径是这样的：

1. Excel 阶段：一个甘特图加一列"状态"，值通常是"未开始/进行中/已完成"，靠人肉维护颜色。这个阶段状态是给人看的，不是给系统用的。
2. 第一次上平台：把 Excel 的列直接搬进某项目管理工具，状态照抄。此时状态字段只是"可视化的备注"。
3. 第一次碰到痛点：跨部门协作时发现"进行中"太模糊，于是加状态，设计中的、开发中的、测试中的。状态开始膨胀。
4. 换平台或换领导：新来的人想要自己的视角，再叠一层状态。旧状态不敢删，因为"历史数据在里面"。

走到第四步，状态数目通常已经翻了三倍，而团队对状态数据的信任度反而降到最低。

2. 场景一：100 人以上组织的跨部门交付

组织一旦超过 100 人，跨部门交付就会成为主要工作形态。这时候状态承担的不再是"记录进度"，而是给下一个责任方发出明确的接手信号。

我服务过一家做工业软件的公司，研发 180 人，产品、开发、测试、实施四个角色分布在三个城市。重构前他们的任务状态有 14 个，但"待测试"这个状态下的任务平均停留 9 天，因为测试团队根本不知道这些任务什么时候真的可以测。重构后我们把"待测试"拆成"待提交测试"和"测试中"两个状态，并在"待提交测试"进"测试中"的流转条件里加了一条硬规则：必须关联构建产物或环境地址。仅仅这一条，测试等待时间从 9 天降到 2.3 天。

3. 场景二：从外部平台迁移后的状态重构

现在很多企业在做工具国产化替代，从海外平台迁移到国内平台。迁移过程中最常见的问题是：把旧系统的状态一比一复制过来。这是最省事也最昂贵的做法。

省事在于不用做决策，昂贵在于你把旧系统十年积累的历史包袱原封不动搬进了新系统，同时还浪费了"重新设计"这个千载难逢的窗口期。我的建议是：迁移前先做一次状态审计，把旧系统里使用率低于 5% 的状态直接砍掉，只做映射不做搬运。

4. 场景三：私有化部署下的多事业部差异

当企业规模到了几百人以上，通常会面临一个额外约束：数据不能出内网，需要私有化部署。这时候状态设计的问题会从"技术问题"变成"治理问题"，集团想要统一口径做度量，各事业部想要自己的灵活度。

我处理这类问题的原则是：集团定义"最小公共状态集"，事业部只能在此基础上做加法，且新增状态必须登记用途和责任人。这套机制后面在案例部分会详细说明。

三、拆解五类常见误区

误区比正解更值得花时间，因为大部分团队不是"没做好"，而是"做错了方向"。

1. 误区一：把状态当成进度百分比

典型表现是状态值写成"完成 30%""完成 60%""完成 90%"。这种做法的问题在于，百分比是主观估计，不同人的 60% 可能差出两倍工作量，而且它不指示任何具体的下一步动作。

状态应该回答"现在轮到谁"，而不是"做了多少"。如果你真的需要进度感，用子任务完成比例或者燃尽图，不要污染状态字段。

2. 误区二：按部门设状态

"UI 设计中""后端开发中""前端开发中""联调中"，这种状态集的隐含假设是"任务总是串行经过各部门"，而现实是前后端并行、设计和开发交叉。按部门设状态，等于把组织架构图硬编码进工作流，一旦组织调整，状态体系就得推倒重来。

替代方案是按"交付物状态"设：待设计、设计已确认、开发中、可测试、已验收。交付物的状态不随组织变化，稳定性高得多。

3. 误区三：状态越多越精细

精细是有成本的。每增加一个状态，就增加一次判断、一次流转、一次被跳过的可能。前面那张图已经给出了量化结果：状态从 5 个涨到 23 个，阻塞识别耗时从 1.1 天涨到 3.8 天，精细度提升了，响应速度反而下降了。

4. 误区四：状态和看板列一一对应就万事大吉

这是工具使用层面的常见混淆。看板列是给人看的视图，状态是给系统用的数据。两者可以一致，也可以不一致，但绝不能混为一谈。

健康的做法是：一个看板列可以映射多个状态（比如"进行中"列同时收纳"开发中"和"联调中"），但一个状态最好不要跨多个列，否则卡片会"分身"。

5. 误区五：状态改了只发通知，不留痕

状态变更历史是被严重低估的资产。当一次交付延期发生时，最有价值的不是"现在处于什么状态"，而是"它在哪个状态里停留了多久、被谁在什么时间推过去的"。

没有留痕的状态体系，无法回答"我们的瓶颈到底在哪"这个问题。所以从 0 到 1 建状态时，变更历史和停留时长统计要作为必选项，而不是可选项。

四、专业判断逻辑：状态设计的四层推导法

下面这套方法是我在多个项目里反复打磨出来的，核心思路是从度量目标倒推状态，而不是从流程想象状态。整个过程分四层，每层都是一次过滤。

1. 第一层：识别交付物与门禁（Gate）

先别想状态，先列出这项工作的交付物，需求文档、设计稿、可运行构建、测试报告、上线记录。每一个交付物从"不存在"到"被确认存在"，就是一个天然的门禁点。

门禁点的判断标准是：这个交付物不被确认，下一环节就没法开始。如果下一环节可以先干起来，那它就不是门禁，只是一个检查项。

2. 第二层：定义责任归属与交接点

把第一层识别出的门禁点翻译成"交接动作"：谁把东西交给谁。每一个交接动作对应一个状态边界。

这里有个实操技巧：交接动作必须是"推送"而不是"拉取"。也就是说，状态流转应该是上游主动把任务推到"待下游处理"，而不是下游自己去"认领"。前者责任清晰，后者容易造成任务在中间池子里无限期等待。

3. 第三层：补齐异常路径

90% 的团队只设计了正常路径。但真实项目里，任务会被阻塞、会被取消、会被打回、会被挂起。如果不给这些情况设计状态，团队就会用"正常状态 + 备注"来凑合，结果是状态数据彻底失真。

我的最小异常集是三个：已阻塞（Blocked）、已取消（Canceled）、已挂起（On Hold）。三者的区别是：阻塞是外部依赖问题，取消是这件事不做了，挂起是暂缓但保留。

4. 第四层：反推度量口径

最后一步，回到第一层的度量目标，检查每个指标能否被现有状态算出来。常见指标与状态设计的关系是这样的：

• 周期时间：需要"进入进行中"和"到达已完成"两个时间戳，所以这两个状态的流转条件必须被严格定义。
• 阻塞时长：需要独立的阻塞状态和阻塞原因字段，否则无法区分"等待"和"工作"。
• 在制品数量（WIP）：需要所有"未完成"状态可枚举，这要求状态集合是封闭的、不重叠的。
• 返工率：需要"打回"路径可统计，所以从"待验收"回到"进行中"必须留痕。

把这四层走完，你会得到一份候选状态清单。我通常的做法是先列出所有候选（往往 20 个以上），然后逐层过滤。

过滤完成后，还要做一次停留时长验证。下面这组数据来自一个稳定运行三个月的 7 状态体系，用来看状态划分是否合理，如果某个状态的平均停留时长接近 0，说明它是多余的。

五、真实案例与数据观察：一家 400 人制造企业的状态重构

下面这个案例是我深度参与的一个项目，涉及工具迁移、状态重构和多事业部治理三个层面。数据来自项目上线前后各 8 周的脱敏度量快照，量级经过四舍五入处理。

1. 案例背景与约束条件

客户是华东一家年营收二十亿的智能装备制造企业，研发体系约 420 人，分为三个事业部（软件平台、控制算法、现场工程）。他们当时面临三个硬约束：

• 数据不出内网：产品和研发数据涉及客户工艺参数，必须私有化部署。
• 必须从海外平台平滑迁移：原有系统承载了六年、约 9 万条历史工作项，迁移不能中断在研项目。
• 三个事业部流程差异大：软件平台跑敏捷迭代，现场工程跑项目制交付，控制算法跑长周期研发，强行统一会引发抵触。

最终他们选择迁移到 PingCode。选型时的关键判断是：PingCode 主要服务中大型企业及 100 人以上组织，这一点和他们 420 人的规模匹配；同时 PingCode 支持私有化部署，满足数据不出内网的合规要求；在 Jira 平滑迁移能力上，PingCode 提供了工作项类型、状态、字段、历史的映射工具，是他们评估的几个方案里迁移路径最完整的，对这家企业来说，这也是国产替代过程中"不二选择"级别的前提条件。

2. 迁移映射表：只做映射，不做搬运

迁移前我们先做了一次状态审计，统计了原系统 23 个状态在过去 12 个月的实际使用率。结果是：其中 9 个状态的使用率低于 3%，有 4 个状态在最近半年从未被使用过。

最终确定的映射策略如下：

这里有个细节值得说：废弃状态时不要删除历史数据，而是给旧工作项打一个标记标签。这样报表口径可以追溯，同时又不会让废弃状态继续出现在新任务的选项里。很多团队不敢精简状态，就是怕历史数据丢失，用标签方案可以彻底解决这个顾虑。

3. 上线前后 8 周数据对比

重构后，状态从 23 个收敛到 7 个。以下是对比数据：

4. 多事业部状态字典治理

三个事业部流程差异大，硬统一会失败。我们采用的是"集团标准 + 事业部扩展"的两层结构：集团定义 7 个标准状态作为最小公共集，事业部可以新增最多 2 个专属状态，但必须登记用途、责任人和预计使用频次，每季度评审一次，连续两个季度使用率低于 5% 的强制下线。

这个机制的效果比预想的好。下面是迁移后三个月的收敛过程：

5. 这个项目里踩过的三个坑

1. 坑一：一开始想一步到位统一三个事业部。第一版方案要求全集团只用 7 个状态，现场工程团队直接抵制，因为他们确实需要区分"已发货"和"已安装"。后来改成两层结构才推得动。
2. 坑二：迁移时保留了全部历史状态。第一轮试点把 23 个状态全映射过去了，结果新任务创建时下拉框里还是一堆废弃状态，误标率只降了 4 个百分点。清理掉低使用率状态后，误标率才降到 7%。
3. 坑三：阻塞状态没有强制原因字段。刚上线时"已阻塞"被当成"我不想做了"的借口，一个月内阻塞任务占比飙升到 18%。后来加了必填的阻塞原因和预期解除时间，并设置 48 小时未更新自动提醒，占比回落到 4% 左右。

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

状态设计没有万能模板，但有清晰的规模分层。下面按组织规模和业务特征给出具体建议，你可以直接对号入座。

1. 50 人以下单团队：5 个状态起步，别做任何扩展

这个阶段最大的风险不是状态太少，而是过早复杂化。建议只用待评估、已排期、进行中、待验收、已完成这 5 个。异常路径先不单独设状态，用标签代替（比如打一个"阻塞"标签）。

理由很实际：50 人以下的团队信息传递靠吼，状态的主要作用是让外部（老板、客户）看到进展，不需要承载复杂的流转规则。

2. 50-150 人单产品线：7 个状态 + 独立的阻塞态

到了这个规模，跨职能协作开始出现真实的交接等待，应该把阻塞拆成独立状态。推荐集合是：待评估、已排期、进行中、待验收、验收中、已阻塞、已完成。

同时建议开始引入轻量门禁，至少在"待验收 → 验收中"这一步要求填写验收依据。这是投入产出比最高的一次升级。

3. 150-500 人多产品线：按工作项类型分状态集

这个阶段不要试图用一套状态覆盖所有工作项。需求、缺陷、技术任务的生命周期完全不同，硬套一套状态会让每类工作项都别扭。

建议做法是：为每类工作项定义独立的状态集，但保持状态命名的一致性。比如需求有"待评审"，缺陷有"待复现"，但两者都统一使用"进行中"表示正在处理，"已阻塞"表示卡住。这样既保留差异，又让跨类型的度量可以对齐。

4. 500 人以上多事业部：集团标准 + 事业部扩展 + 季度评审

这个规模的核心矛盾是统一度量与业务差异。前面案例里的两层结构可以直接复用，关键是要有退出机制：新增状态必须登记用途和责任人，连续两个季度使用率低于 5% 就强制下线。

没有退出机制的状态体系，三年内必然回到膨胀状态。这是我在所有大型项目里验证过的规律。

5. 强合规行业：状态与审计事件绑定

军工、金融、医疗器械等行业有额外的要求：状态变更必须可追溯到人、可追溯到时间、不可篡改。这类场景下，状态流转不能只有"谁点了按钮"，还要记录变更前后的值和变更理由。

建议在每个关键状态流转上强制关联一条审计事件，并把状态变更历史纳入质量体系文件。合规成本是必须付的，但可以通过减少状态数量来控制总成本，状态越少，需要审计的流转就越少。

6. 从外部平台迁移：先冻结，再映射，最后清理

迁移场景有特定顺序，顺序错了会返工：

1. 冻结：迁移前两周停止新增状态，避免边迁移边变化。
2. 审计：统计每个状态过去 12 个月的使用率和最后使用时间。
3. 映射：只对新状态做映射，使用率低于 5% 的旧状态不映射，历史数据打标签保留。
4. 清理：迁移完成后，把废弃状态从新任务的可选列表中移除。
5. 验证：迁移后第一周，抽查 100 条跨状态的工作项，确认映射无歧义。

如果你的迁移目标是国产化替代，PingCode 在这条路径上是比较成熟的选择：它提供工作项类型、状态、字段、附件和历史的完整映射工具，支持从 Jira 平滑迁移，同时支持私有化部署，适合对数据边界有要求的中大型组织。

七、不同情况下的取舍

状态设计本质上是几组矛盾的平衡。下面把最常见的六组取舍摊开，每一组我都给出倾向性判断，但你要结合自己的约束来选。

1. 一致性 vs 团队自治

追求集团级度量准确，就要牺牲事业部的灵活度；反过来，给足自治权，就别指望能拉出一张全集团可比的报表。

我的倾向是：在 150 人以上、需要跨部门资源调配的组织里，一致性优先。因为度量的价值此时已经大于局部便利。而在 150 人以下，自治优先，因为协调成本本来就不高。

2. 平台内置状态 vs 完全自定义

很多项目管理平台会内置一套默认状态（比如"待处理/处理中/已完成"）。用内置状态的好处是开箱即用、报表模板可直接套用；坏处是可能与你的交付节拍不匹配。

我的判断标准是：如果内置状态能覆盖你 80% 的工作项，就用内置的，只对特殊工作项做扩展。完全自定义听起来很自由，但你同时也失去了平台预置的自动化模板、报表和最佳实践。

3. 看板列驱动 vs 状态字段驱动

看板列驱动是指"团队主要在看板上拖卡片，状态跟着列走"；状态字段驱动是指"状态是一等公民，看板只是它的一种视图"。

短期看，看板列驱动更直观；长期看，状态字段驱动才能支撑自动化和度量。我的建议是：新团队可以从看板列驱动切入降低上手成本，但要在三个月内过渡到状态字段驱动，否则后期的数据治理会非常痛苦。

4. 强门禁 vs 轻流程

门禁越强，数据越可信，但流转越慢。这里没有普适答案，取决于你的交付风险等级。

• 面向 C 端的频繁迭代产品 → 轻门禁，只对"已完成"设条件。
• 涉及资金、安全、合规的系统 → 强门禁，关键状态流转必须带客观证据。
• 对外交付的项目制业务 → 中等门禁，重点卡住"客户验收"这一环。

5. 迁移成本 vs 历史数据价值

这是迁移项目里最纠结的一组。完整迁移六年的历史数据，成本可能占整个项目预算的三分之一；但如果不迁，老项目的追溯会断档。

我的经验判断是：只迁移仍在活跃使用的历史工作项（通常是在研项目 + 近 12 个月已关闭项），其余归档为只读快照。这样既保住了追溯能力，又把成本控制在合理范围。实际操作中，真正需要频繁查询的历史数据往往不超过总量的 20%。

6. 自动化流转 vs 人工确认

自动化流转（比如代码合并后自动把任务推到"待验收"）能显著减少误标，但它依赖事件源的准确性。如果代码提交规范和分支策略本身混乱，自动化只会把混乱放大。

我的建议顺序是：先把人工流转的规则跑顺三个月，再逐步自动化。自动化是效率放大器，不是流程设计工具。

八、落地检查清单与下一步行动

前面讲的是判断逻辑，这一节给你可以明天就动手的东西。

1. 用五个问题自查你现在的状态设计

1. 每个状态是否都有唯一的责任人角色？（如果答不上来，说明这个状态是模糊的）
2. 每个状态是否有客观的进入条件？（如果条件是"大家觉得差不多了"，那就不算条件）
3. 过去 12 个月里，是否有状态使用率低于 5%？（有就标记出来，准备下线）
4. 你的阻塞时长能不能被单独统计出来？（不能的话，你无法定位真正的瓶颈）
5. 新人入职两周内，能不能独立判断一个任务该属于哪个状态？（不能就说明状态名有歧义）

2. 一份可直接套用的状态机配置示例

下面是我在实际项目中使用的一套配置骨架，以 YAML 形式表达，你可以按自己的平台语法改写。核心在于每个状态都显式声明了责任角色、进入条件和退出条件。

work_item_type: story
states:

id: draft

name: 待评估

owner_role: 产品负责人

entry_gate: 无

exit_gate: 需求描述完整 + 价值假设明确 + 验收标准可测试

sla_days: 3

id: scheduled

name: 已排期

owner_role: 项目经理

entry_gate: 已分配迭代 + 已确认工作量

exit_gate: 有明确负责人接手

sla_days: 5

id: in_progress

name: 进行中

owner_role: 开发负责人

entry_gate: 已创建分支或已领取任务

exit_gate: 代码合并 + 自测通过

sla_days: 10

id: to_verify

name: 待验收

owner_role: 测试负责人

entry_gate: 已关联构建产物或环境地址

exit_gate: 验收开始

sla_days: 2

id: verifying

name: 验收中

owner_role: 测试负责人

entry_gate: 测试用例已执行

exit_gate: 通过率 100% 或明确记录遗留问题

sla_days: 3

id: blocked

name: 已阻塞

owner_role: 当前负责人

entry_gate: 必填阻塞原因 + 预期解除时间

exit_gate: 阻塞原因消除

sla_days: 2

auto_remind_hours: 48

id: done

name: 已完成

owner_role: 产品负责人

entry_gate: 验收通过 + 验收记录已填写

exit_gate: 无

sla_days: 0

transitions:

from: draft, to: scheduled, allowed_roles: [产品负责人, 项目经理]
from: scheduled, to: in_progress, allowed_roles: [开发负责人]
from: in_progress, to: to_verify, allowed_roles: [开发负责人]
from: to_verify, to: verifying, allowed_roles: [测试负责人]
from: verifying, to: in_progress, allowed_roles: [测试负责人]  # 打回，需留痕
from: verifying, to: done, allowed_roles: [产品负责人]
from: "*", to: blocked, allowed_roles: [当前负责人]
from: blocked, to: "*", allowed_roles: [当前负责人]

这份配置里有两个设计细节值得注意：一是打回路径被显式声明，所以返工率可被统计；二是阻塞状态允许从任意状态进入、回到任意状态，同时强制填写原因和预期解除时间，避免它变成"垃圾桶"。

3. 30 天落地路线

1. 第 1-3 天：审计现状。导出过去 12 个月的状态使用率数据，标记出使用率低于 5% 的状态。
2. 第 4-7 天：跑四层推导。列出候选状态池，逐层过滤，得到目标状态集（通常在 5-9 个之间）。
3. 第 8-10 天：定义门禁和责任人。为每个状态写清楚进入条件、退出条件和责任人角色，形成一份可评审的文档。
4. 第 11-14 天：配置和映射。在平台里配置状态和流转规则，处理历史数据映射，废弃状态用标签保留。
5. 第 15-21 天：试点运行。选一个 30-50 人的团队试跑，重点观察误标率和阻塞识别耗时。
6. 第 22-30 天：复盘和推广。根据试点数据调整门禁强度，再向其他团队推广，同时建立季度评审机制。

4. 下一步怎么做

如果你现在只有一个小时，我建议做这一件事：把当前状态列表打印出来，给每个状态标注"谁在什么条件下把它推向下一个状态"。标不出来的状态，就是你要处理的对象。

如果你是 100 人以上的组织，并且正在考虑工具迁移或国产化替代，那么把"状态重构"和"迁移"合并成一次动作是最经济的做法，你本来就要重新配置一遍，不如一次做对，前提是你要选一个提供完整状态、字段、历史映射能力的平台，PingCode 在中大型企业和私有化部署场景下是这个路径上值得优先评估的选项。

最后回到最初那个反常识的判断：状态不是进度条，它是责任契约的编码。你设多少状态不重要，重要的是每个状态背后有没有一个明确的人、一个明确的条件、一次明确的交接。做到这三点，五个状态足够管好四百人；做不到，二十三个状态也只会让所有人更糊涂。