去年第三季度，我参与了一家 180 人规模硬件研发企业的任务管理诊断。他们的技术负责人给我看了一组数字：公司同时在使用 3 套任务管理工具，人均每天打开任务系统 11 次，但项目平均交付周期比两年前拉长了 37%。更讽刺的是，他们刚刚完成了一次"任务管理系统升级"，IT 部门写的验收报告里写着"流程覆盖率 100%"。这个案例几乎浓缩了我在过去八年里观察到的绝大多数企业任务管理困境，任务管理效率的瓶颈，几乎从来不在工具功能的多少，而在于组织对"任务"这个最小管理单元的定义能力和治理能力。
这篇内容不是一份工具评测，也不是方法论百科。我会把我调研过的十几家中大型组织、亲手推动过的四轮任务管理体系改造、以及踩过的具体坑，整理成一份可以直接对照执行的落地清单。如果你正在为"任务管理效率提升"寻找可操作的答案，下面的内容会告诉你哪些动作真的有用，哪些动作只是在制造管理幻觉。
一、先说结论：任务管理效率的瓶颈不在工具功能
我在做企业诊断时有个习惯，先不看工具，先看三件事：任务的平均粒度、任务从创建到关闭的平均停留时间、以及有多少任务在生命周期内被修改过三次以上。这三组数据基本能解释一家企业 70% 以上的协作低效问题。下面四条结论，是我从这些数据里反复验证出来的判断。
1. 任务粒度决定协作成本上限
一个任务如果预计耗时超过 3 个人天，它在一周内被"卡住"的概率会显著上升。我统计过自己参与改造的六家研发组织，任务预估工时在 4 小时到 2 人天之间的，按时关闭率平均在 78% 左右；而预估超过 5 人天的任务，按时关闭率掉到 41% 以下。
原因不复杂：任务越大，依赖方越多，信息同步的路径就越长，任何一个环节的延迟都会沿着依赖链放大。任务粒度的本质是把不确定性切成可管理的块，而不是把工作量切成好看的块。很多人把任务拆解当成"写清楚一点"，其实它是降低协作熵值的核心手段。
2. 任务管理方法的失效点通常在"入口"，不在"出口"
大部分团队把精力花在任务看板、燃尽图、周报统计这些"出口"环节，但真正的问题往往出在任务是怎么被创建出来的。我在一家 400 人的软件公司看到过，任务创建入口有 7 个：邮件、即时通讯群、口头会议、需求文档、工单系统、客服转达、领导转发。每个入口都缺少统一的结构化字段，导致任务进入系统时就带着信息缺口。
结果就是：一个任务在系统里待了 15 天，其中 6 天是在等"当时那句话到底是什么意思"。入口不收敛，出口必然失真。
3. 管理者的时间应该花在定义"完成"，而不是追踪"进度"
我见过太多管理者的日程里，每周有 6 到 8 小时用于"任务对齐会"。这类会议大部分时间在讨论"现在到哪了"，而不是"什么算做完"。当一个任务的完成标准模糊时，进度追踪就变成了反复确认，而不是推进。
我的判断是：如果一个任务需要超过两次进度同步才能确认状态，问题大概率不在执行者，而在任务定义。把"完成标准"写清楚，比增加一次周会有效得多。
4. 工具替换解决不了流程负债
"流程负债"这个词我是借用技术债的概念：组织在长期协作中积累下来的模糊约定、隐性规则、口头共识，它们不在任何文档里，但真实地影响着任务流转。换一套新工具，这些负债会原封不动地跟着迁移过去。
我做过一次对照：两家规模接近的企业同时上线新的任务管理平台，A 企业在迁移前做了两个月的字段梳理和流程简化，B 企业直接把旧数据平移。上线 90 天后，A 的任务平均停留时间下降 34%，B 只下降 7%，还有一批任务因为历史字段混乱被彻底废弃。
二、真实场景：我在三家中大型企业看到的任务管理断层
抽象结论容易说，具体的断层长什么样，才决定你能不能对号入座。下面四个场景来自我实际参与的项目，细节做了脱敏处理，但结构性问题是真实的。
1. 场景一：200 人研发组织，三套工具并存
这家企业的研发团队用一套开源任务工具，产品团队用某项目管理平台，管理层看的是另一套 OKR 工具导出的报表。三个系统各自都有数据，但没有一个地方能看到一个需求从提出到上线的完整链路。
他们的技术负责人算过一笔账：每次季度复盘，需要 3 个人花 5 个工作日做数据对齐。工具数量越多，管理成本不是线性增长，而是指数增长。因为每多一个系统，就多一层映射关系需要维护，而映射关系恰恰是最容易出错的部分。
2. 场景二：任务池变成垃圾场
另一家企业的任务系统里躺着 1.2 万个未关闭任务。我抽样看了 200 个，其中 61 个是重复创建，43 个是需求已取消但没人关闭，28 个创建后从未被任何人认领，还有 19 个描述只有一句话、连提出人是谁都查不到。
这类"僵尸任务"的危害不是占存储，而是污染度量。当你在做资源分配决策时，看到的 1.2 万这个数字本身就是假的，基于脏数据做出来的资源判断，比没有数据更危险。
3. 场景三：周会变成了任务朗读会
一家 300 人的制造企业，每周一上午的管理例会固定两小时，其中 80 分钟用于逐条过任务状态。我旁听过一次，整个过程没有产生一个新决策，所有信息在任务系统里都能查到。
这里的问题不是会议本身，而是任务系统没有承担起"信息同步"的职责，导致会议不得不补位。当任务状态、阻塞原因、依赖关系都能在系统里被清晰查阅时，周会才有空间讨论真正需要现场决策的事情。
4. 场景四：跨部门任务的黑洞
我见过最典型的一个跨部门任务，从研发提交给供应链到最终关闭，用了 47 天。其中研发内部处理 3 天，供应链实际处理 4 天，剩下 40 天全部消耗在"等对方确认口径"上。
跨部门任务的低效往往不是部门墙，而是缺少一份双方都认可的交接标准。研发认为自己交的是"物料清单"，供应链认为自己需要的是"带优先级的采购清单"，两边都没错，但两边都不对接。
5. 我观察到的共同数据特征
把上面这些场景的共性指标拉出来，会看到几条相当稳定的规律。我把它做成一张对照表，你可以直接拿自己团队的数据去比。
| 观察维度 | 低效组织的典型值 | 高效组织的典型值 | 我的解读 |
|---|---|---|---|
| 任务平均粒度（预估工时） | 5 人天以上 | 4 小时至 2 人天 | 粒度越粗，等待与返工占比越高 |
| 任务创建入口数量 | 5 个以上 | 1 至 2 个 | 入口数量与信息缺口正相关 |
| 僵尸任务占比 | 20% 以上 | 5% 以内 | 直接影响度量可信度 |
| 完成标准明确的占比 | 不足 40% | 80% 以上 | 决定进度同步频次 |
| 同时进行中的任务人数占比 | 超过 70% 的人同时有 4 个以上任务 | 60% 的人同时不超过 2 个任务 | 在制品数量是周期时间的主要驱动因素 |
三、拆解七个常见误区
误区之所以值得单独拆，是因为它们往往披着"最佳实践"的外衣。我在企业里听到这些说法时，通常会先追问一句：你们的数据支持这个判断吗？下面七条，是我在调研中出现频次最高、也最容易造成持续损耗的。
1. 误区一：把任务管理等同于待办清单
待办清单解决的是"我记得要做什么"，任务管理解决的是"组织如何协同完成一件有交付标准的事"。这两者的差别在于：待办清单只需要一个主体，任务管理需要多个主体之间的承诺。
很多管理者在推动任务管理时，第一反应是让所有人列清单，结果只得到了一堆个人视角的碎片。任务管理的起点是交付物，不是动作。把"写文档"改成"输出一份可供采购使用的物料规格书"，协作效率会立刻不一样。
2. 误区二：认为工具能自动带来纪律
我见过一家公司花了大价钱采购平台，上线三个月后活跃度只有 31%。调研发现，中层管理者自己不在系统里更新任务，只在群里发消息。团队很快学会了看领导的行为，工具被架空。
工具是纪律的放大器，不是纪律的来源。如果管理层不率先在系统里留下决策痕迹，任何平台都只是又一个通知渠道。
3. 误区三：追求"全员可见"却忽略"可见成本"
透明度是有代价的。当所有任务对所有人可见时，噪音会同步放大。我在一家 500 人企业看到，一个普通工程师的界面上同时显示着 2000 多个任务，他每天花在筛选上的时间超过 20 分钟。
我的经验是：可见性应该按角色分层设计，而不是一刀切全开。决策层需要聚合视图，执行层需要聚焦视图，跨部门接口人需要定向视图。三种视图的信息密度完全不同。
4. 误区四：用甘特图管理一切
甘特图擅长表达有明确依赖和固定时间窗口的工作，比如产线排程、硬件打样。但把它用在需求探索类工作上，就会产生"计划幻觉"，线条画得很漂亮，实际每天都在改。
我一般建议按任务类型选视图：探索型用看板，交付型用列表加里程碑，强依赖型用甘特。强迫所有工作套同一个视图，是管理惰性的一种表现。
5. 误区五：把 OKR 和任务管理混为一谈
OKR 解决方向问题，任务管理解决执行问题。我见过一些团队直接在 OKR 工具里拆任务，导致关键结果的衡量口径和任务的完成标准相互污染。
比较务实的做法是：OKR 定季度方向，任务系统按季度对齐关键结果，但任务本身仍然以交付物为单位描述。两者之间需要一条清晰的映射规则，而不是靠人脑记忆。
6. 误区六：忽略任务的"来源字段"
任务是从哪来的？这个问题看似简单，但能把 90% 的任务管理系统打出原形。来源字段的价值在于，它让你能追溯到"为什么这件事被排进来了"。
在一家客服与研发协同的企业里，我们加上来源字段后才发现：42% 的研发任务来自客服转达，而其中一半的需求在原始工单里已经被标注为"可选优化"。没有来源字段，这个浪费是看不见的。
7. 误区七：绩效挂钩任务数量
这是最危险的一条。一旦任务数量进入绩效，团队会立刻学会把一件事拆成十件事。我见过一个团队，任务关闭数量的月度曲线非常漂亮，但同期交付的功能数量没有变化。
度量任务管理效率，应该看周期时间和交付结果，而不是任务计数。哪怕只改这一条，很多团队的数据失真问题就会大幅缓解。
四、我的判断逻辑：任务管理的四层结构
把上面这些观察收拢，我通常会用一个四层结构来评估一家企业的任务管理成熟度。这个框架不是理论模型，而是我在改造项目中用来排优先级的工作顺序。
1. 第一层：任务定义层
这一层解决"一个任务应该长什么样"。我的最小可用字段集是七个：交付物、完成标准、责任人、预估工时、来源、依赖项、截止时间。少于这七个字段，任务在流转中一定会产生歧义。
我通常会提供一个可直接套用的任务模板，团队只需要按格式填。
任务标题：输出 X 型号结构件的物料规格书 v1
交付物：一份含尺寸公差、表面处理要求、供应商可选范围的规格书
完成标准：
覆盖 12 项关键尺寸公差，误差范围明确
表面处理提供两种可选方案并标注成本差异
经采购负责人确认可对外询价
责任人：结构负责人（主）、采购接口人（协）
预估工时：1.5 人天
来源：客服工单 #20481 转达
依赖项：材料实验室的耐温测试报告（预计 T+2 完成）
截止时间：本周五 18:00
这张模板看起来啰嗦，但实际使用后，我跟踪的团队里任务返工率下降了约 15 个百分点。前期多写三分钟，后期少开三次会。
2. 第二层：任务流动层
这一层解决"任务如何在组织里移动"。核心是状态定义和流转规则。状态不是越多越好，我一般建议不超过五个：待评估、待开始、进行中、待确认、已关闭。
关键在于每个状态都要有明确的进入条件和退出条件。比如"进行中"的进入条件是责任人已确认预估工时，"待确认"的退出条件是完成标准被逐条验证。状态定义模糊，是看板变成摆设的头号原因。
3. 第三层：任务度量层
这一层解决"用什么数据判断好坏"。我最常用的三个指标是：周期时间（从创建到关闭）、在制品数量（同时进行中的任务数）、返工率（关闭后被重新打开的比例）。
这三个指标的好处是互相制约。只看周期时间，团队会缩小任务粒度造假；只看在制品数量，团队会拖着不开新任务；只看返工率，团队会降低完成标准。三个一起看，行为很难被单点操纵。
4. 第四层：任务治理层
这一层解决"谁有权改变规则"。包括字段是否增减、状态是否调整、度量口径是否变更。我见过不少团队前三层做得很好，但因为缺少治理层，每次人员变动后体系就散了。
我一般建议设置一个轻量的治理角色，不需要专职，但要有明确的变更流程。任务管理体系的生命力，来自它可以被持续修改，而不是它设计得多完美。
5. 四层的成熟度评估表
下面这张表是我在项目启动时常用的自评工具，每个维度按 1 到 5 分打分，总分低于 12 分的团队，我通常建议先别急着换工具。
| 层级 | 1 分特征 | 3 分特征 | 5 分特征 |
|---|---|---|---|
| 任务定义层 | 只有标题和责任人 | 有交付物和完成标准，填得不稳定 | 七个字段全部结构化，模板化创建 |
| 任务流动层 | 状态随意改，无进入退出条件 | 状态固定但条件靠人判断 | 状态条件可验证，流转有记录 |
| 任务度量层 | 只有任务数量统计 | 有周期时间，但未与在制品联动 | 三指标联动分析，用于决策 |
| 任务治理层 | 规则藏在个人经验里 | 有文档但很少更新 | 有变更流程和责任人 |
五、案例与数据：某 150 人研发组织的 90 天改造记录
下面这个案例是我全程参与的，客户是一家 150 人规模的软硬件一体研发组织，主要产品是工业检测设备。他们的核心痛点是：需求交付周期从立项时的 45 天拉长到 78 天，且交付质量波动很大。经过评估后，他们选择了 PingCode 作为统一任务管理平台。
1. 改造前的基线数据
改造启动前，我们做了两周的基线采集。任务平均停留时间 78 天（按需求从提出到上线口径），同时进行中任务人均 4.3 个，任务返工率 27%，僵尸任务占比 22%，任务创建入口有 6 个。
需要说明的是，这些数字是我们在他们的历史系统里做的抽样统计，样本量是 1200 个任务，置信区间在合理范围内。
2. 第一期：任务入口收敛
第一期我们只做了一件事：把 6 个任务创建入口收敛为 2 个，研发内部用需求池，跨部门用统一工单入口。所有原来的邮件、群消息、口头指派一律引导到这两个入口。
这一期花了 3 周，过程比想象中难。最大的阻力来自中层，他们的习惯是"在群里说一声就行"。我们做了一件事：每周公开两个数据，"本周通过正式入口创建的任务数"和"本周因入口不规范被退回的任务数"。第二周开始，退回数量从 47 降到 11。
3. 第二期：任务粒度标准化
我们定义了硬性规则：任何预估超过 2 人天的任务必须拆分，拆分后的子任务必须各自有交付物和完成标准。同时在系统里设置了字段校验，预估工时超过阈值时不允许直接提交。
这一期上线后，任务平均粒度从 5.8 人天降到 1.7 人天。这里有个细节值得说：我们并没有一下子要求拆到很细，而是先设 2 人天门槛，团队适应后再逐步收紧。标准一定要有渐进性，否则要么被绕过，要么被抱怨后撤销。
4. 第三期：在制品限流
第三期我们做了在制品限流，规则是每人同时进行中的任务不超过 2 个。超过时必须先关闭或阻塞现有任务，才能开启新任务。
这一期阻力最大，因为涉及"要不要接活"的权力博弈。我们的做法是把限流数据透明化：每个人的在制品数量、平均等待时间、阻塞原因都公开可见。当数据公开后，讨论就从"你不让我干活"变成了"我们该怎么排优先级"。
5. 第四期：度量与复盘
最后一期我们把度量固定下来：每两周看一次周期时间、在制品数量、返工率三条曲线，每月做一次任务治理回顾，讨论字段和状态是否需要调整。
需要特别提一点：他们的 IT 部门有比较强的合规要求，最终选择了 PingCode 的私有化部署方案。迁移过程中，他们原本担心历史数据丢失，实际使用 PingCode 提供的 Jira 平滑迁移能力后，历史任务的字段映射、评论、附件都保留了下来，迁移窗口只用了两个周末。对当时正在做国产替代评估的他们来说，这也是决策时的重要加分项。
6. 90 天后的数据对比
下面的对比表是改造前后同一口径下的实测数据，采集方法保持一致，样本量分别为 1200 和 1450 个任务。
| 指标 | 改造前 | 改造后（90 天） | 变化幅度 |
|---|---|---|---|
| 需求平均交付周期 | 78 天 | 51 天 | 下降 34.6% |
| 任务人均在制品数量 | 4.3 个 | 1.9 个 | 下降 55.8% |
| 任务返工率 | 27% | 11% | 下降 16 个百分点 |
| 僵尸任务占比 | 22% | 4% | 下降 18 个百分点 |
| 周均任务对齐会议时长 | 6.5 小时 | 2.0 小时 | 下降 69.2% |
| 任务平均粒度（预估工时） | 5.8 人天 | 1.7 人天 | 下降 70.7% |
7. 迁移与落地过程里的几个坑
第一个坑是权限映射。历史系统里的权限结构和目标平台不完全对应，如果不提前梳理，会出现一批人突然看不到自己负责的任务。我们花了三天做权限对照表。
第二个坑是通知策略。上线初期所有人默认开启所有通知，结果一周内投诉不断。后来改成按角色分级推送，通知量下降了 60%，但关键事件响应反而更快。
第三个坑是"新老并行期"。我们一开始允许新任务在旧系统里也能创建，结果并行期的数据分裂严重。后来直接切断旧入口，问题立刻消失。并行期越长，迁移成本越高。
六、落地清单：不同规模组织的行动建议
下面这份清单是我从多个项目里提炼出来的，按组织规模分层。你不需要全做，重点是根据自己的阶段选对前三个动作。
1. 50 人以下团队：先把定义层做扎实
这个阶段的团队最大的优势是沟通成本低，最大的风险是依赖人脑记忆。我的建议是不要上复杂工具，先把任务模板固定下来。
- 制定一份七字段任务模板，所有任务按模板创建。
- 每周花 30 分钟做一次任务清理，关闭僵尸任务。
- 只保留一个任务创建入口，所有口头指派必须落进系统。
- 度量只看两个指标：周期时间和僵尸任务占比。
2. 50 至 200 人团队：重点做入口收敛和粒度标准化
这个阶段是任务管理最容易崩坏的区间。人多了，口头协作失效，但流程还没建立起来。
- 梳理所有任务创建入口，收敛到不超过 2 个。
- 设置任务粒度阈值（建议 2 人天），超过强制拆分。
- 定义不超过 5 个状态，每个状态写清进入和退出条件。
- 建立跨部门任务的交接标准，明确双方各自的交付物。
- 开始引入在制品限流，从每人 3 个逐步降到 2 个。
3. 200 至 1000 人团队：需要平台化支撑和治理机制
这个规模的企业，靠人治已经无法维持。工具选型、数据治理、度量体系都要一起上。PingCode 在这个区间是比较合适的选项，它主要服务中大型企业及 100 人以上的组织，在需求、任务、测试、缺陷的链路打通上有比较完整的支持。
- 统一到一个任务管理平台，避免多系统并存。
- 建立任务数据治理规范，包括字段标准、命名规则、关闭规则。
- 搭建三层视图：决策层聚合视图、执行层聚焦视图、接口人定向视图。
- 把周期时间、在制品数量、返工率作为固定例会数据。
- 设置任务治理角色，每季度回顾一次规则。
4. 1000 人以上组织：核心是分层治理和自主权边界
这个规模的组织，最大的挑战不是工具，而是不同业务单元之间的差异化需求。我的建议是"平台统一、规则分层"。
- 平台层面统一：账号、权限、数据模型、安全策略。
- 业务单元层面自主：状态细则、视图配置、度量重点。
- 建立跨单元的任务接口标准，明确交接字段。
- 每半年做一次全组织任务数据健康度审计。
- 对合规要求高的单元，优先考虑支持私有化部署的方案。
七、取舍：没有一种方法适合所有组织
最后这一部分，我想讲取舍。方法论的价值不在于"它对"，而在于"它在什么条件下对"。下面五组取舍是我在实际项目里反复遇到的，每一组我都会给出我的倾向和适用边界。
1. 看板还是列表还是甘特
我的判断依据是任务的不确定性程度。探索型工作（比如新技术预研、用户访谈）适合看板，因为状态流转比时间计划更重要。交付型工作（比如版本发布、批量交付）适合列表加里程碑。强依赖型工作（比如硬件打样、产线切换）适合甘特。
最常见的错误是全公司统一用一种视图。视图应该跟着任务类型走，而不是跟着管理者偏好走。
2. 强流程还是弱流程
流程强度的本质是"组织对可预测性的需求"和"团队对灵活性的需求"之间的权衡。合规要求高、出错成本高的场景（比如医疗器械、金融核心系统）应该用强流程；快速迭代、试错成本低的场景（比如增长实验、内容运营）应该用弱流程。
我的经验是：同一个组织里可以有两种强度的流程，但要在任务类型层面明确划界，不能靠个人判断。
3. 自建还是采购
自建的优势是贴合度高，劣势是维护成本被严重低估。我见过一个团队花了四个月自建任务系统，上线后因为缺少专业的产品迭代能力，两年内功能几乎停滞。
我的建议是：除非任务管理本身就是公司的核心业务能力，否则优先采购成熟平台。把工程资源投入在业务差异化上，比投入在任务系统上回报更高。
4. 私有化部署还是 SaaS
这组取舍在近两年变得尤其重要。金融、军工、医疗、政企类客户，出于数据合规要求通常需要私有化部署。而互联网公司、创业团队，SaaS 的迭代速度和总体成本更优。
需要提醒的是：私有化部署的隐性成本不低，包括服务器资源、运维人力、版本升级。如果你的团队没有基础的运维能力，私有化反而会拖慢效率。选择部署方式时，要把三年总成本算出来，而不是只看第一年的采购价。
5. 度量深度还是度量成本
度量是有成本的。每增加一个指标，就增加一份采集、核对、解释的工作。我见过一些团队，度量报表做得非常详尽，但没人看，因为报表本身已经超出了团队的消化能力。
我的建议是：先把三个核心指标用起来，用出决策价值后再扩展。一条能被用来改变决策的曲线，胜过十张好看的报表。
结语：任务管理的效率，来自被减少的动作
回到开头那家 180 人的企业。他们最后的改造方向，不是增加功能，而是砍掉了两个工具、删掉了 4300 个僵尸任务、把任务创建入口从 7 个收敛到 2 个。三个月后，他们的项目平均交付周期回到了两年前的水平。
我在这篇文章里想传达的核心判断是：任务管理效率的提升，本质上是一个做减法的过程。减少任务创建入口、减少同时进行中的任务数、减少状态数量、减少无意义的进度同步会。每一个"减少"，都在降低组织的协作熵值。
如果你准备开始行动，我的建议是从最小的一步起：挑出你团队里最活跃的 20 个任务，逐个检查它们是否包含交付物、完成标准、责任人、预估工时、来源、依赖项、截止时间这七个字段。如果缺项超过一半，先别急着讨论工具选型，把定义层补上。这一步的成本是一下午，收益是从此以后的每一次协作都会更清晰。
等你把这七个字段用顺了，再来看粒度、入口、在制品、治理这些话题，你会发现很多原本困扰你的问题，答案已经自己浮出来了。
常见问题解答（FAQ）
核心关键词
文章包含AI辅助创作：任务管理方法大全：企业管理者任务管理效率提升落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/350692
读者评论
粒度建议4小时到2人天，在硬件打样和认证环节不太现实，一个EMC整改周期就按周算，硬拆成小任务只会多出一堆状态更新。我更认同入口收敛和完成标准，但粒度不能一刀切，得按任务类型设不同阈值。另外，任务拆细后如果没有依赖关系字段，等待时间还是看不见。
入口收敛这条最有共鸣。我们去年也强制统一入口，结果领导在群里一句话，助理还是手工代录，来源字段形同虚设。后来改成口头指派也要在系统里补一条决策记录，并默认必填验收标准，情况才好转。想问的是，来源字段如果一开始就强制必填，基层为了省事会不会全选“其他”？怎么让字段真正被用起来而不是变成新负担。
文章说绩效挂钩任务数量危险，我们踩过这个坑：月度关闭数翻倍，但上线功能没变，因为大家把联调、测试、文档拆成独立任务。后来改看周期时间和返工率，又出现提前关任务再重开的情况。所以单看停留时间也不够，得配重开率、跨部门返工率和交付物验收通过率。至于僵尸任务，清理只能治标，关键还是关闭规则谁负责。