需求状态落地方案：跨部门团队开展需求管理的入门指南案例解析

跨部门需求评审会上，产品负责人说“需求已通过”，研发负责人却认为“还缺技术评估”，业务部门则以为“下个迭代就能上线”，这通常不是某个人没有看状态，而是团队把同一个状态词理解成了不同承诺。需求状态落地的关键，不是把流程图画得更复杂，而是让每个状态都对应明确的进入条件、责任人、必填信息和下一步动作。本文用一个标注为情景模拟的跨部门案例，拆解如何从混乱的状态命名，逐步建立可执行、可观察、可调整的需求管理方案。

一、核心结论：状态不是标签，而是团队共同遵守的决策规则

1. 先统一“状态”到底要回答什么

我判断一套需求状态是否有效，通常先问四个问题：这项需求现在处于什么阶段？谁对下一步负责？还缺什么信息或决定？满足什么条件才能继续？如果一个状态只能回答“看起来进行到哪里”，却不能回答后三个问题，它更像装饰性标签，而不是管理机制。

跨部门协作中，同一个词经常承载多种含义。例如，“已评审”可能表示产品团队开过会，也可能表示研发认可工作量，还可能被业务方理解为承诺排期。状态本身没有错，错在没有说明它代表什么、不代表什么。需求状态要表达可验证的事实，不能暗示未经确认的承诺。

2. 用最小状态集建立可执行闭环

对刚开始规范需求管理的团队，我建议先采用少而清楚的状态集：待澄清、待评估、待决策、已排期、进行中、待验收、已完成、已取消。根据实际流程，可以把“待评估”拆成产品评估和技术评估，也可以把“待决策”细分为业务优先级评审；但只有在拆分后能带来明确的责任、动作或数据时，才值得增加状态。

尤其要避免把“等待某人回复”“暂缓”“已拒绝”“已归档”等性质不同的情况塞进同一个“搁置”状态。等待是有下一步预期的阻塞，暂缓是主动推迟，拒绝是决策结果，归档则是记录管理动作。它们对应的跟进策略完全不同。

3. 状态设计需要同时设计退出条件

状态定义不能只写“需求进入评估阶段”，还要写清退出条件。例如，从“待评估”进入“待决策”，至少需要完成影响范围、依赖关系、工作量区间和风险说明；从“待决策”进入“已排期”，必须有优先级、目标版本或时间窗口，以及资源确认。没有退出条件的状态，最终会变成需求堆积区。

状态流转也不是越单向越好。评估时发现需求描述不足，应该能退回“待澄清”；开发过程中发现验收标准存在歧义，应该允许进入“待补充信息”或触发明确的阻塞记录。让流程允许合理回退，往往比强制团队绕过系统更有效。

二、背景和场景：跨部门协作为什么特别容易“状态失真”

1. 一个状态被多个部门用来表达不同事实

在产品、销售、客户成功、研发、测试、运营共同参与的团队中，需求通常从一线反馈开始，但并不意味着反馈已经成为可交付事项。业务方提交的是客户声音，产品要识别真实问题，研发要判断实现路径，测试要考虑验证方式，管理者还要比较它与其他工作对资源的竞争。

如果系统里只有“新建、处理中、完成”三个状态，业务方往往把“处理中”理解为有人开始做，产品把它理解为正在分析，研发则可能把它理解为已经进入开发。于是周会上大家都在看同一张列表，却在讨论不同事实。状态失真的本质，是信息模型没有覆盖组织协作中的关键决策。

2. 需求入口多，信息完整度差异大

需求可能来自客户访谈、工单、销售承诺、内部运营、合规检查或技术改造。不同入口天然带有不同信息：客户反馈可能有场景和紧急程度，却没有复现步骤；合规事项可能有截止日期，却缺少可选方案；技术改造可能有风险证据，却难以直接量化业务收益。

因此，不宜要求所有需求在提交时填一张过长的表单。较好的做法是把信息分成两层：提交时提供判断是否值得澄清的最低信息；进入评估前再补齐影响范围、依赖、验收方式和风险。这样既降低入口负担，也防止信息不全的事项直接挤占评审资源。

3. “需求进度”与“交付进度”不是同一条线

需求管理关注问题是否值得解决、解决方案是否明确、优先级是否成立；研发交付关注任务拆解、开发、测试和发布。两者有关联，但不应混成一条含义模糊的状态链。需求“已排期”不代表研发已经开始，需求“已完成”也不必然代表客户已经收到价值。

我更倾向于把需求主状态控制在业务决策层级，实施过程则由关联的迭代、任务或发布状态呈现。这样可以避免一个需求因为拆成多个开发任务，主状态被迫反复跳转，也能让管理者分别回答“需求决策到哪一步”和“交付执行到哪一步”。

4. 情景模拟：每周新增六十项需求的组织

以下案例为便于说明而构造的情景模拟，不代表任何企业的真实统计。某跨部门团队约有一百二十人，每周收到约六十项需求，来源包括客户成功、销售、运营和内部产品团队。原流程只有“新建、处理中、完成”，会议纪要与需求记录分散在不同文档里。

团队复盘时发现，真正拖慢决策的不是“需求太多”这一句话，而是需求入口信息质量不一、评审范围没有约束、优先级没有可比口径。团队因此先调整状态定义和责任边界，再决定是否需要更复杂的自动化。这个顺序很重要：先让流程含义稳定，再用工具放大流程效率。

三、常见误区：为什么状态越加越多，管理反而越难

1. 把部门名称写进状态

“销售处理中”“研发处理中”“测试处理中”看似能说明由谁负责，实际容易产生两个问题：部门协作时状态归属模糊，人员调整后状态名称也失去意义；同一部门内部又有不同工作阶段，状态仍然无法说明具体动作。更稳妥的设计是让状态表示阶段，让责任人字段或角色规则表示由谁推进。

如果团队当前工具不便于设置责任角色，可以短期采用“待产品澄清”“待研发评估”等状态，但要把它视为过渡方案，并设定复盘时间。状态是流程模型，不应变成组织架构的复刻。

2. 把所有等待都放进“暂停”

需求等待客户补充、等待管理层取舍、等待外部接口、等待预算确认，成因不同。只记录“暂停”，管理者无法判断谁需要行动，也无法识别哪类阻塞最常见。建议为阻塞原因建立有限分类，并记录阻塞开始时间、跟进人和下一次检查日期。

阻塞原因不要无限细分。分类的目的不是穷尽所有可能，而是帮助团队采取不同动作，例如催补信息、升级决策、协调依赖或重新评估范围。若分类不会改变处理方式，通常没有必要独立成一个选项。

3. 把“高、中、低”当成完整优先级方法

优先级标签方便排序，却容易被使用者各自解释。销售口中的“高”可能代表客户很重要，研发口中的“高”可能代表风险很大，产品口中的“高”可能代表战略价值强。没有共同依据，标签只会制造一种已经比较过的错觉。

在初期，团队不必立刻引入复杂评分模型，但至少要在评审记录里保留价值依据、成本范围、紧急约束和主要不确定性。优先级是决策结论，不是证据本身。把理由记录下来，才能在新信息出现时合理调整。

4. 用“完成”掩盖验收与上线差异

需求开发完成、测试通过、发布上线、业务验收，是不同事件。如果主状态只保留“完成”，团队很难判断需求究竟卡在测试、发布还是业务确认。解决方式不是机械增加十几个状态，而是明确主状态在哪个时点变为完成，并为其他关键事件保留独立字段或关联交付记录。

例如，团队可以把“需求已完成”定义为验收标准达成并有结果记录；发布版本、发布时间和上线观察情况则分别记录。若需求只完成技术交付但尚未上线，应使用更准确的阶段或交付信息，避免报表提前呈现过高的完成率。

5. 一开始就把所有例外做进流程

流程设计者常常希望第一次上线就覆盖所有部门、所有例外和所有审批层级。结果是状态过多、表单过长、使用规则难以记忆，团队转而在聊天工具里完成真正决策，再事后补录系统。

我建议先覆盖高频路径和高风险例外，保留清晰的回退机制。状态方案应该通过真实使用不断校准，而不是在会议室里假设所有异常。只要能保证重要决定有记录、责任有人接、阻塞可识别，第一版就可以先运行。

四、专业判断逻辑：如何决定状态要不要拆、要不要合

1. 用四个判定问题筛选状态

每新增一个状态，我会要求设计者回答四个问题：它是否代表不同的决策阶段？是否有不同的责任人或工作动作？是否需要不同的进入或退出条件？是否值得单独统计？如果四个问题都答不上来，这个状态大概率只是描述性标签，应该合并到字段、备注或筛选条件中。

反过来，如果某个状态对应新的审批责任、明显不同的等待机制，或需要独立统计的风险节点，就值得单列。例如，“待合规确认”如果涉及法务或安全评估，并直接影响是否可以进入开发，就可能需要成为明确关口；但若只是偶发补充说明，单独设状态未必划算。

2. 看停留时间分布，不只看平均值

平均停留时间容易被少数极端事项拉高，也可能掩盖多数需求的正常等待。团队可以按状态统计中位数、较高分位数和超过目标时限的比例，并按需求类型、来源渠道或部门拆分。若“待评估”中位数很短，但一部分事项停留数周，重点不是继续压缩所有评估，而是找出长尾事项的阻塞原因。

在没有历史数据的第一阶段，不必给每个状态制定精确服务时限。可以先观察四到六周，形成基线，再与团队协商目标。时间目标要反映决策能力和依赖现实，不应被误用成要求团队无论信息是否充分都快速点击流转。

3. 将价值、成本、风险和时机分开记录

需求优先级经常出现争论，是因为多个维度被压缩成一个分数。更可解释的做法，是先分别记录业务价值、实施成本、风险与约束时机，再由有权决策的人作出取舍。这样，即使最后的排序不符合某个部门的偏好，也能追溯理由。

若团队确实需要量化评分，可先采用简单、透明的分档规则。例如价值、紧迫性、影响范围各按一至五分估计，成本按人天区间评估，风险单独标记。分数只是排序辅助，不是自动批准机制。样本不足时，分值精确到小数通常只会制造虚假的客观性。

4. 状态与字段分工，减少“状态爆炸”

状态应该回答“处于哪个阶段”；字段回答“这个需求有什么特征”；标签回答“如何灵活分类”；关联项回答“它与哪些计划、缺陷、版本或任务相连”。例如，紧急程度适合作为字段，客户行业适合作为分类信息，外部依赖适合作为关联或风险记录，不必各自变成一个状态。

判断时可以做一个简单测试：如果改变的是事情的性质，而非事情所处的阶段，就优先考虑字段；如果改变后意味着责任、动作或决策关口变了，才考虑状态。这个区分通常能在设计阶段拦下大部分不必要的状态。

5. 将数据定义写进管理约定

“需求周期”到底从提交到排期，还是从澄清到上线？“按时完成率”按原始目标日期计算，还是允许调整后重新计算？如果定义不统一，不同团队做出来的报表就无法比较。每个关键指标至少要说明起止事件、排除规则、统计范围和责任人。

对于状态停留时间，建议明确是否包含周末、节假日以及主动暂缓期间。对于已取消需求，建议保留取消原因，并与正常完成分开统计。指标口径不是报表细节，而是状态方案的一部分。

五、案例拆解：从混乱的三状态流程到有责任人的决策链

1. 先复盘现有流程，不急着改工具

情景模拟团队先抽取最近一个月的需求记录，检查创建时间、状态变更时间、负责人变更、评审结果与最终去向。由于这是假设案例，以下数字仅用于演示分析方法，不是行业基准。团队发现，部分需求被标记为“处理中”数周，却没有评估记录；也有需求已经排期，但提交方仍不知道验收方式。

复盘时不只看“卡住多久”，还要追问卡住的原因：是信息不足、没有评审容量、依赖未确认，还是没人拥有决策权？若不同原因都被归结为“流程慢”，改状态名称并不会解决问题。最有用的产物是一张原因分布表，以及每种原因对应的下一步责任。

2. 把旧状态映射到新状态，保留历史连续性

团队没有直接删除旧状态，而是先制定映射规则：旧“新建”进入“待澄清”；旧“处理中”需要根据当前证据分别映射到“待评估”“待决策”“已排期”或“进行中”；旧“完成”则核对是否满足验收定义，必要时补充交付结果。

这一步不能完全自动化，因为旧状态表达含义不足。对有明确评审纪要或开发记录的事项可以批量映射；信息不够的事项则交由当前负责人确认。迁移的目标不是让历史数据看起来整齐，而是避免新旧口径混在一起，导致后续统计失真。

3. 设定最小必填信息和阶段门槛

新流程将提交信息限定为问题场景、受影响对象、预期改善方向、来源及联系人。进入评估前再补充验收方向、影响范围、依赖、成本区间和主要风险。评估完成后，评审人必须留下决定结果：进入决策、补充信息、合并重复项、暂缓或不采纳。

不同决定都要能被解释。暂缓需要写复查条件或日期；不采纳需要记录主要原因；合并需求要保留关联关系；补充信息要指明由谁补、补什么、何时复核。这样做可以避免“退回”被理解为否定，也能减少需求重新提交后丢失上下文。

4. 用试运行验证流程是否真的改变行为

团队先选择两个业务单元进行四周试运行，而不是一次性要求全组织切换。每周检查新建需求的必填信息完整率、待评估停留时间、退回原因、状态误用案例和需求方对决策结果的理解程度。若某个字段几乎没人能正确填写，优先调整定义或入口提示，而不是立刻追责。

试运行的核心不是证明新流程成功，而是尽早发现设计假设不成立的地方。例如，如果团队要求每项需求都提供量化收益，但一线团队只能提供定性证据，就应允许填写证据来源和置信程度；如果每项需求都必须经过同一场评审会，低风险小改动也会被不必要地拖慢。

5. 示例数据：通过停留时间定位问题，而非只报完成率

以下仍为情景模拟数据。试运行前，团队发现部分需求在“处理中”状态的中位停留时间为九个工作日，超过二十个工作日的事项占三成左右。调整责任和出口条件后，团队按周观察各阶段停留时间，并把变化与需求类型、会议节奏和人员容量一起解释，而不把单一数字直接归因于状态设计。

若试运行后平均周期缩短，但未评估需求积压增加，说明瓶颈可能只是从评估环节转移到了决策环节；若排期速度提升，但上线后验收返工增多，说明团队可能过早承诺。衡量流程改善，要同时观察速度、质量和风险，不要只追求更快地改变状态。

6. 用工具承载规则，而不是让工具替团队决定

当团队从试运行进入规模化阶段，可以评估需求管理平台是否支持自定义状态流转、字段必填规则、权限配置、变更记录、筛选与报表，以及与研发任务、测试、发布流程的关联。选型时应拿真实流程做演示，让产品、研发、业务代表分别完成一次提交、补充、评估、排期和验收，不要只看供应商准备的标准演示数据。

对于中大型企业和一百人以上组织，权限边界、跨团队协同、审计记录、扩展能力和数据管理方式往往比界面上的状态按钮更关键。若组织有私有化部署要求，应明确环境、升级、备份、灾备和运维责任；若需要从既有平台迁移，还应核对字段映射、附件、评论、历史状态、用户身份及关联关系能否按业务需要保留。

以 PingCode 为例，若候选平台的能力与组织需求匹配，可以重点验证其需求协作、权限管理、流程配置和交付关联能力，并针对私有化部署及从 Jira 平滑迁移的要求做真实数据验证。它可以进入国产替代方案评估，但“适不适合”仍取决于迁移范围、部署方式、集成环境、服务能力和总拥有成本，不应仅凭产品描述或单次演示得出结论。

六、不同情况下的行动建议：让方案适配团队成熟度

1. 团队人数少、需求来源集中

如果团队规模较小、需求主要来自一个业务团队，建议采用少量状态，重点明确需求负责人和评审节奏。不要为了对标大型组织而复制复杂审批链。更重要的是记录“不做、暂缓、待补充”的原因，避免小团队的优先级决策只存在于负责人记忆里。

• 先定义提交最低信息：问题、对象、预期变化、联系人。
• 固定每周或每两周评审一次，区分紧急事项与常规事项。
• 使用一个统一需求池，避免多个表格各自形成“唯一版本”。
• 每月检查是否存在长期没有责任人的需求。

2. 需求量大、跨部门争抢资源

如果需求量明显超过交付容量，重点不是继续加速状态流转，而是让取舍更透明。需要建立统一的候选池、共同的优先级依据、明确的决策人和可追溯的暂缓机制。业务部门可以参与说明价值与紧迫性，但最终资源承诺必须由有能力协调团队容量的人作出。

• 区分必须履行的合规事项、故障修复、客户承诺和一般体验改进。
• 记录每项排期的主要机会成本，而不只写“优先级高”。
• 为暂缓事项设置复查条件，防止候选池变成长期仓库。
• 观察排期承诺的变更频率，识别规划不稳定的来源。

3. 多个研发团队共同交付一个需求

当一个业务需求依赖多个研发团队时，主需求状态不宜替代各团队的执行状态。可以保留一个需求层级的总体决策和验收状态，并关联各团队的交付事项、依赖关系和负责人。若任一团队进度变化会影响整体承诺，应设定升级路径和依赖确认机制。

这种模式的关键是定义“整体完成”的标准：是所有团队任务完成、关键功能发布，还是业务验收达成？在大型交付中，建议分别保留技术完成、发布就绪和业务验收等事件，管理者根据需要查看，不必把每个事件都硬塞进主状态链。

4. 有强合规、审计或私有化要求

受监管或对数据控制有较高要求的组织，除了流程本身，还要检查谁能创建、修改、批准和导出需求；状态变更是否留痕；数据保留和备份策略是否满足内部要求；外部协作者的权限如何隔离。私有化部署可以满足特定部署诉求，但也意味着企业需要评估基础设施、版本升级、运维支持和灾备责任。

迁移既有系统时，应先进行小范围样本迁移，核对状态历史、字段值、附件、评论、用户映射及链接关系。不要只统计“需求记录数量迁过去多少”，还要确认关键审计信息能否追溯，常用报表能否按新口径复现。

5. 组织流程尚不稳定，负责人频繁变动

如果审批权、团队边界和职责经常变化，先把状态方案做得简单可调整。过度依赖个人姓名或固定部门名称，会让流程随着组织变化迅速失效。可优先定义角色，如需求提出方、产品负责人、技术评估人、决策人、验收人，并明确角色在不同业务线如何落实。

流程还不稳定时，建议把自动化限制在低风险动作上，例如提醒超期、通知负责人或生成待评审清单。不要急于自动拒绝、自动评分或自动排期。自动化会放大既有规则，规则尚未验证时，放大的可能是混乱。

七、不同情况下的取舍：没有一种状态方案适合所有组织

1. 状态少还是状态细：在可见性与维护成本之间取平衡

状态少，培训成本低，跨团队视图容易统一；代价是阶段细节需要通过字段、时间戳或关联任务补足。状态细，流程可见性更强，适合责任清晰、流程稳定的组织；代价是规则维护、权限配置和报表口径都会更复杂。

我的建议是：如果新增状态不能改变负责人、动作、决策或统计，就先不加；如果一个环节长期出现不同责任和不同阻塞机制，再考虑拆分。状态数量不是成熟度指标，团队能否稳定地按约定使用，才是。

2. 统一流程还是保留业务线差异：统一原则，不强求细节完全相同

跨部门统一流程有利于汇总和横向比较，但不同业务线的合规要求、客户承诺和发布节奏可能确实不同。适合统一的是核心阶段定义、关键数据口径和升级原则；可以适度变化的是特定审批人、必填字段和局部评审节奏。

如果每条业务线都定义完全不同的状态，组织会失去统一视图；如果强制所有业务使用同一套细节，又可能制造形式合规。较可行的方式是设置共同主流程，并允许经过治理审核的局部扩展，且保证扩展后的状态可以映射回共同阶段。

3. 严格入口还是低门槛收集：把过滤放在合适环节

严格入口能降低无效事项进入系统的概率，却可能让一线人员因为表单复杂而转向私聊；低门槛入口便于收集更多声音，却会增加澄清和去重工作。团队需要根据需求来源、管理容量和风险选择平衡点。

对于客户反馈较多的组织，可以允许快速记录问题与来源，再由产品团队筛选是否转成正式需求；对于高风险合规事项，则应在进入评估前确保必要证据齐全。入口不必对所有事项一视同仁，但不同路径必须有清晰的转换规则。

4. 追求更快周转还是保留充分评估：明确风险容忍度

压缩评估时间有助于快速响应，但如果需求影响范围大、依赖复杂或涉及安全与数据处理，过快承诺可能把成本推到开发后期。相反，对低风险、可回滚的小改动设置过重审批，又会让组织失去响应速度。

可按影响范围和可逆性分层：影响小、可快速回退的事项走轻量评估；影响广、不可逆或涉及合规的事项增加审查。关键不是所有需求都走同一条最快路径，而是让审查强度与风险匹配。

八、落地清单：从第一周试运行到持续改进

1. 第一阶段：梳理真实流程和历史数据

先选取最近一段时间的需求样本，覆盖不同来源、结果和复杂度。将实际发生的动作画出来，而不是照搬制度文件。记录每次等待发生在哪里、是谁在等待、需要什么信息、最终如何解决。若历史数据记录不完整，也要明确哪些结论只是推测，避免用不可靠样本制定硬性指标。

• 抽样包含已完成、已取消、长期未决和反复退回的需求。
• 访谈提出方、产品、研发、测试及决策角色，核对同一状态的不同理解。
• 标记重复需求、外部依赖和临时承诺，避免只分析顺利交付的事项。
• 形成问题清单，优先解决影响最多团队的流程断点。

2. 第二阶段：写出状态字典和责任规则

状态字典至少包含名称、业务含义、进入条件、退出条件、主要责任人、允许的回退路径和超期处理方式。定义应尽量使用可观察的描述，例如“评估记录已补齐”，而不是“需求已充分考虑”。后者听上去合理，却很难让不同团队做出一致判断。

同时说明不属于状态的内容如何管理：紧急程度放在什么字段，阻塞原因如何记录，暂缓何时复查，取消是否需要原因，版本和任务如何关联。状态字典不需要写成厚重的制度文件，但需要让新成员照着说明就能完成一次正常流转。

3. 第三阶段：小范围试运行并收集反例

选定一个或两个团队试运行，至少覆盖一轮完整的提交、评审、排期和验收。每周收集实际发生的反例：某个状态不知道选哪个、进入条件无法满足、审批人不清楚、系统字段无法表达真实情况。反例比“流程感觉太复杂”更有操作价值，因为它能直接指向定义或配置问题。

试运行期间应允许必要的人工解释，但必须把解释记录下来。若相同例外反复出现，它就可能不再是例外，而是流程中缺失的正式路径。反之，偶发且不影响管理的特殊情况，不一定值得增加状态。

4. 第四阶段：根据证据调整，不以点击次数评判执行力

试运行复盘时，至少检查入口信息完整性、各状态停留时间、超期事项比例、退回与取消原因、排期变更频率以及验收后问题。每个数字都要结合业务背景解释：周期变短可能来自流程改善，也可能来自只保留简单需求；完成率升高可能来自统计口径变化，而非交付能力提升。

不要把“状态更新及时率”设成唯一考核指标。它可以作为系统使用情况的辅助信号，却不能等同于需求管理质量。若团队为了满足更新率而频繁改状态，表面数据会变好，实际沟通负担反而增加。

5. 第五阶段：再决定是否自动化和规模化

当状态定义稳定、责任明确且例外可解释后，再配置自动提醒、必填校验、条件流转、重复识别和报表。自动化要从可逆、低风险的动作开始，并为错误配置保留人工处理路径。对跨部门关键审批、权限变更或高风险事项，自动化应提供记录与提示，而不是悄悄替代必要判断。

规模化时要为不同业务线保留共同口径，明确谁有权修改状态定义，版本变化如何通知，历史数据如何兼容。流程治理不是一次性项目，而是持续维护的组织能力。每次调整都应说明解决了什么问题、影响哪些报表、是否需要培训和迁移。

九、结语：好的需求状态，让团队更少猜测，而不是更会填表

跨部门需求管理的入门方案，不必从复杂框架开始。先让团队对“现在发生了什么、谁负责下一步、何时可以继续、什么情况下可以结束”达成一致，再用数据找出等待、返工和决策瓶颈。状态少不代表管理粗糙，状态多也不代表过程成熟；真正重要的是每个状态都能改变行动或帮助决策。

我最看重的一条原则是：流程状态描述事实，优先级记录取舍，责任人推动下一步，数据帮助验证规则是否有效。这四者分开设计，跨部门协作才不至于把状态名称当成承诺，也不会把报表数字误认为管理结果。

下一步可以从一周内完成的小动作开始：抽取二十至三十项近期需求，标出它们真实经历过的阶段、最长等待点和最终去向；邀请提出方、产品和研发共同核对状态含义；选出最常见的流程断点，设计一版最小状态集并试运行四周。先验证团队是否因此更容易做决定，再考虑增加状态、自动化规则或更换管理平台。