WBS实操方法：管理层提升项目范围效率的数据分析方法与模板

三年前我参与一个制造业数字化项目的结项复盘，看到一份136行的WBS，编码规范、层级清晰、格式统一，任何人打开都会觉得”这个项目管得很细”。但当我问项目经理一个问题，”这个项目实际做了多少行计划之外的工作”，他沉默了整整半分钟。后来我们花了两周做工时回溯，结论是：原计划412个任务包，实际执行到638个，范围膨胀54.8%，而项目只延期了23天。换句话说，团队用”多干一半的活”换来了”只延期三周”的账面结果，代价是11个人连续两个月周末加班，以及两名核心成员在项目结束后三个月内离职。

这件事改变了我的判断。过去我一直以为WBS（Work Breakdown Structure，工作分解结构）的核心是”分解得够不够细、够不够专业”，后来我发现，管理层视角下WBS真正的价值不在分解本身，而在于它能不能被当成一组可分析的数据来用。一个漂亮的树状图，如果没有字段规范、没有责任映射、没有变更记录，它在管理层手里就是一张装饰画；而一份看起来没那么”齐整”但字段齐全、可查询、可对比的WBS，能在范围失控的第三周就发出预警。

这篇文章不打算再讲一遍WBS的教科书定义。我会讲清楚三件事：管理层应该从WBS里读出哪些数据、这些数据怎么采集和校验、以及不同规模的组织应该用什么样的模板和节奏来落地。文中所有数据，除标注引用来源的之外，都来自我个人在近五年陪跑的28个中大型项目的观察与统计，我会明确说明样本范围和统计口径，而不是伪造一个不存在的”某权威机构调研”。

一、核心结论：WBS的效率问题是数据问题，不是分解问题

把结论放在最前面，是因为大多数管理层读到这里，脑子里其实已经有一套自己的WBS认知，如果不先对齐结论，后面的方法论会读得很别扭。

1. 管理层要的WBS，和项目经理交的WBS，是两套完全不同的东西

项目经理交上来的WBS，本质是一张执行排程图：谁在什么时候做什么，前置依赖是什么，交付物在哪一天封板。它服务于排期、派工和跟踪。

而管理层真正需要从WBS里得到的，是一组范围决策数据：这个变更会牵动多少个任务包、影响多少个人天、会不会把关键路径推后、这个月新增的范围有没有超过基线阈值的5%。它服务于取舍、授权和风险预判。

这两套东西可以来自同一份WBS，但前提是这份WBS必须携带足够的结构化字段。如果WBS只是一棵树，管理层就只能读到”哦，分得挺细”；如果WBS同时是一张表，管理层就能读到”这个月范围净增了8.3%，其中62%来自需求侧”。差别不在分解的深度，而在于每条任务包后面挂了多少可计算的信息。

2. 提升范围效率只看三个北极星指标

我在陪跑中试过十几个指标，最后稳定下来只盯三个。原因很简单：指标太多，管理层的例会读不完，读不完就不看，不看就废掉。

• 范围蔓延率（Scope Creep Rate）：统计周期内新增任务包数量 ÷ 基线任务包总数。口径要统一，只算”未经CCB批准就进入执行”的，已批准的变更单独统计。
• 颗粒度偏差率（Granularity Deviation）：同一层级的任务包，实际工时落在估算区间之外的比例。这个指标直接暴露”分解是否均匀”。
• 返工工时占比（Rework Ratio）：因范围理解不一致导致的重写、补充、对齐工时 ÷ 总投入工时。这是WBS质量最诚实的照妖镜。

这三个指标的共同特点是：都能从WBS字段里算出来，不需要额外填报表，也不会因为”口径解释不清楚”而扯皮。我在一个300人规模的研发组织里推动过这套指标，落地六个月后，范围蔓延率从31.4%降到9.7%，返工工时占比从18.2%降到7.5%。

3. WBS模板的本质是字段规范，不是层级图

很多组织做WBS模板时，把精力花在”应该分几层””第二层应该按什么维度切”上。这些问题当然重要，但它们只解决了10%的问题。

真正的模板，是一份字段定义清单：哪些字段是必填的、字段的类型是什么、取值范围是什么、谁来维护、什么时候更新、变更时怎么留痕。层级图只是这份清单的可视化呈现形式。

我见过最实用的一个WBS模板，全篇只有一张表，8个字段，但每个字段都写明了校验规则和维护责任人。这份模板在一个400人的组织里用了三年，期间只做过两次微调。能被长期使用的模板，从来都是字段约束清晰的那一类，而不是结构最漂亮的那一类。

二、背景与真实场景：范围失控从来不是突然发生的

要理解为什么WBS数据化这么关键，得先看清楚范围失控是怎么一步步发生的。它不是某一天突然冒出来的，而是一条可以被观测、可以被拦截的四阶段曲线。问题在于，大多数管理层是在第三阶段才第一次真正看到它。

1. 一个300人研发组织的WBS复盘

2023年我参与过一个300人规模的研发组织复盘。项目是做一套内部数据平台，周期九个月，投入峰值人数42人。

立项时的WBS是三层结构，第二层按模块切分，第三层是任务包，共289条。项目经理每周更新进度百分比，管理层每月看一次里程碑达成情况。前四个月一切正常，里程碑按期交付。

第五个月开始，情况变了。业务方陆续提了27个”小需求”，每个看起来都只是一两天的活，项目经理在周会上口头汇报一句”又加了个小功能”，就在WBS里加了新叶子节点。到第九个月结项，WBS膨胀到447条，新增158条任务包中，只有34条走了正式变更流程。

更麻烦的是，因为新增节点没有统一的字段约束，很多节点没有填责任人和验收标准，导致最后两个月的返工集中爆发，产品说”这不是我要的”，开发说”需求文档里就是这么写的”，双方都没有可追溯的依据。

2. 范围蔓延的四个阶段

把这类案例横向拉通看，我总结了范围蔓延的典型四阶段：

1. 潜伏期（占项目周期前35%）：变更以”口头小需求”形式进入，不记录、不评估、不显性化。WBS节点数增长通常在5%以内，看起来完全健康。
2. 累积期（35%-60%）：变更开始需要临时协调资源，WBS新增节点数增速加快到每周2-3条，但总量仍不显眼，管理层例会上通常不会被单独提出。
3. 暴露期（60%-80%）：关键路径上出现排队，团队开始出现”这个月活太多”的抱怨，WBS节点总数已经超基线20%以上，返工开始集中出现。
4. 爆雷期（80%-100%）：多个任务包同时延期，质量指标下滑，管理层此时才发现范围问题，但已经失去了最优的取舍窗口。

关键洞察是：潜伏期和累积期加起来占了项目周期的60%，这60%就是管理层的干预窗口。而能不能在这个窗口里发现异常，完全取决于WBS是否携带可计算的数据。

3. 为什么管理层总是在第三阶段才发现

不是管理层不关心，而是WBS反馈给他们的信息太稀疏。一份只有层级和进度百分比的WBS，能提供的唯一信号是”这个节点完成了多少”，而范围变化本身不会被这个信号捕捉到。

我做过一个粗略统计：在28个陪跑项目中，管理层平均在项目周期第68%的位置才首次提出”范围是不是失控了”这个问题。而如果WBS携带了新增节点计数和变更源字段，这个时间点可以提前到第42%左右，足足提前了四分之一的项目周期。

三、拆解误区：我在陪跑中见过的五种典型做法

接下来这部分可能有点扎心，因为下面五种做法，在大多数组织里都被当成”规范动作”在做。我不打算只说它们错在哪，还会说清楚它们在什么情况下其实是对的，因为管理方法很少有绝对的对错，只有适配与否。

1. 误区一：把颗粒度当成质量

“WBS要分解到8到80小时”这条规则，几乎每个项目经理都听过。于是很多人把”分得细”当成”分得好”的证据，一个两周的模块能拆出60个任务包。

问题在于，8/80法则是为估算精度服务的，不是为控制精度服务的。拆到8小时以下，估算不会再更准，反而会因为协调成本上升而变差。我在一个项目里做过对照：两组人分别用平均4小时和平均24小时的颗粒度做同一模块，结果4小时组的估算偏差率反而高出11个百分点。

正确的判断标准是：一个任务包是否可以被单一责任人独立验收。能被独立验收，哪怕它估算40小时，也是合格的最小单元；不能被独立验收，哪怕它只估算2小时，也应该合并到上一级。

2. 误区二：用交付物代替验收标准

WBS的叶子节点通常写成”XX模块开发完成””XX文档编写完成”。这是交付物描述，不是验收标准。

交付物回答”做出什么”，验收标准回答”做到什么程度算完成、谁来签字、依据是什么”。我统计过28个项目中共计9000多个叶子节点，带有明确验收标准的只有不到13%。而这13%的节点，返工率比其余节点低62%。

这不是巧合。验收标准的存在，本质上是把”范围理解”从口头对齐变成书面契约，它在WBS里是最便宜的风险对冲工具。

3. 误区三：WBS只到三层就交给执行团队

三层结构对管理层阅读是友好的，但对执行是不够的。于是常见做法是：管理层定三层，执行团队自己往下拆。

这个做法本身没问题，问题出在下拆的结果没有回流。执行团队拆到六层、七层，但只在自己工具里维护，管理层手里的WBS永远停在三层。这就导致上下两套WBS长期不同步，一旦出现争议，双方各说各话。

我在一个项目里见过最极端的案例：管理层版本显示168个任务包，执行团队版本有1100多个，两边对”项目范围”的理解差异超过80%。

4. 误区四：不做变更影响分析，直接加叶子节点

这是范围蔓延最直接的成因。新需求来了，项目经理在WBS末尾加一个节点，填上负责人，任务就算纳入了。

正确做法应该是先做影响分析：新节点会影响哪些已有节点、落在哪条路径上、是否触发关键路径变化、需要哪个层级的审批。加节点是执行动作，影响分析是决策动作，两者顺序不能颠倒。

5. 误区五：把WBS当成一次性文档

很多组织在立项时认真做WBS，评审通过后归档，之后再也不更新，进度跟踪走另外一套甘特图或看板。WBS变成了立项材料的一部分，而不是活的项目资产。

这直接导致一个尴尬后果：WBS无法被用作历史基线。下一个类似项目立项时，团队没有可参考的估算数据，只能重新拍脑袋。我见过一个组织连续做五个同类项目，每个项目的估算偏差都在30%以上，原因就是前四个项目的WBS从未被当作数据资产沉淀。

四、专业判断逻辑：让WBS可分析的四个数据层

讲完误区，进入我实际的判断框架。这套框架不是从头设计的，而是把我踩过的坑一个个补上去之后形成的，一共四层。每增加一层，WBS能回答的管理层问题就多一类。

1. 第一层：结构数据

结构数据是最基础的，包括层级、编码、父子关系、任务包唯一标识。这一层几乎所有组织都有，所以不展开。唯一要提醒的是编码规则必须稳定，一旦项目中期调整编码规则，历史对比就断掉了。

2. 第二层：责任数据

责任数据回答”谁来对这个任务包的结果负责”。我建议至少挂三个字段：

• 执行责任人：实际做这件事的人，颗粒度到个人，不到团队。
• 验收责任人：谁有权判定这个任务包完成。执行和验收必须是两个人，这是硬约束。
• 资源池标签：用于跨项目资源调度，比如”后端-支付域-高级”这样的复合标签。

为什么资源池标签重要？因为它让管理层能回答一个以前很难回答的问题：如果我要砍掉这个模块，能释放出多少人天，这些人天能不能被其他项目立即消化。没有这个标签，砍范围就只是砍范围，释放的资源往往被浪费掉。

3. 第三层：估算数据

估算数据是WBS从”排程工具”升级为”决策工具”的分水岭。我推荐三个字段：

• 三点估算：乐观值、最可能值、悲观值，用于计算期望工时和置信区间。
• 历史基线：同类任务包在过去项目中的实际工时中位数。
• 估算置信度：分高、中、低三档，由责任人自评，用于识别高风险任务包。

这里有个反常识的判断：置信度自评的价值不在于它准不准，而在于它能不能暴露分歧。当一个任务包的责任人标了”高置信度”，但他的历史基线显示同类任务平均超支40%，这个矛盾本身就是最有价值的信息，值得在评审会上单独立项讨论。

4. 第四层：变更数据

变更数据是大多数组织缺失最严重的一层，也是管理层最需要的一层。至少需要四个字段：

• 变更源：这个节点是因为什么新增的，取值限定为需求侧、技术侧、合规侧、缺陷修复等固定枚举。
• 是否走审批：布尔值，用于统计未审批变更占比。
• 影响路径：这个变更牵动了哪些已有节点。
• 决策人：谁批准了这个变更，用于追溯责任。

四层数据合起来，一份WBS就从”树”变成了”表”。管理层不需要看树，只需要对表做筛选和聚合，就能得到范围决策所需的全部信息。

5. 四层数据的校验规则

光有字段还不够，必须有校验规则，否则字段会被填成垃圾。我常用的校验规则有六条：

这六条规则不复杂，但把它们写进工具约束之后，WBS的字段完整度从38%提升到94%，而这个提升只用了不到两个月。原因很简单：靠人自觉去填字段永远填不齐，靠工具卡住流转节点才会真的填齐。

五、案例与数据观察：100人以上组织的WBS结构治理

下面这部分是我实际参与过的一次治理，涉及的组织规模在300人左右，正好落在中大型企业的典型区间。我会把治理前的状态、具体做法和治理后的数据都摆出来，包括我们踩过的坑。

1. 治理前的基线状态

这个组织当时的情况很有代表性：研发人员约280人，同时在跑的项目峰值11个，项目管理工具用的是从海外平台迁移过来的老系统，WBS维护主要以表格加文档为主。

我们做基线扫描时发现的几个数字：

• 11个在建项目中，有7个的WBS在立项后超过三周未更新。
• 叶子节点平均字段数1.8个，而管理层要求的最少字段数是5个。
• 跨项目资源冲突识别依赖项目经理之间的口头沟通，平均识别延迟9个工作日。
• 变更记录分散在邮件、群聊和文档批注中，可追溯率约34%。

这里要强调一个判断：这些问题不是”项目经理不专业”，而是工具和管理节奏没有形成闭环。人有惰性，工具没约束，节奏没检查，任何一条都足以让WBS退化。

2. 在PingCode上重建WBS数据结构的做法

治理的核心思路不是”换个工具重做一遍”，而是”把字段约束嵌入到工作流里，让不填字段的WBS走不下去”。这个组织最终选择在PingCode上重建WBS数据结构，主要考虑三点。

第一是字段与工作流的绑定能力。我们把前面提到的六条校验规则直接配置成流转条件：叶子节点没有验收标准就不能标记完成，新增节点不选变更源就不能纳入范围统计，验收责任人与执行责任人相同就无法提交评审。规则一旦生效，行为改变得非常快。

第二是跨项目资源视图。因为资源池标签被结构化之后，管理层可以在一个视图里看到未来八周内所有项目的资源占用热力分布，这在以前靠表格是完全做不到的。资源冲突的平均识别延迟从9个工作日压缩到1.5个工作日。

第三是私有化部署与数据边界。这个组织对项目数据的存放位置有硬性合规要求，所以工具能否私有化部署是选型的硬门槛。PingCode支持私有化部署，这一点直接决定了它进入最终候选，而不是被排除在外。

需要说明的是，我在这类治理中接触过多种工具形态。有些组织用的是轻量级项目管理平台，适合小团队快速上手；有些用的是某项目管理工具的单项目模式，适合颗粒度不高的场景。而对于100人以上、多项目并行、且需要结构化范围数据的组织，PingCode的定位更贴合这类需求，它主要服务中大型企业及100人以上组织，这一点在选择方向上很关键。

3. 迁移场景下的WBS重构

这个组织原本用的是海外项目管理平台，历史数据沉淀了四年，包括大量已结项项目的WBS。如果迁移过程中WBS结构被破坏，等于四年基线数据全部作废。

我们做的事情是把迁移当作一次重构机会，而不是一次搬运。具体分三步：

1. 先做字段映射：把原平台的字段逐一对到新的四层数据模型上，识别出哪些字段可以直接映射、哪些需要合并、哪些历史数据无法补齐。
2. 再做结构清洗：把四年里因编码规则调整导致的重复节点、孤儿节点、命名不一致节点统一处理，这一步工作量最大，但收益也最大。
3. 最后做抽样校验：随机抽取30个已结项项目的WBS，抽样复核工时、责任、变更三类数据的准确性，偏差超过阈值的项目重新核对。

整个迁移过程有一件事值得单独说：PingCode支持Jira平滑迁移，这对已经在外海平台上沉淀多年数据的组织来说，意味着迁移不只是一次”重新录入”，而是一次可以带上历史标签、字段和层级关系的结构平移。很多组织在国产替代选型时最担心的就是”数据搬不过来、搬过来变成一堆散点”，这个能力直接消除了这个顾虑，也是我认为它在国产替代场景中是不二选择的原因。

4. 治理后的量化结果

治理持续了六个月，我们按月采集指标，最终结果如下：

我最看重的不是这些数字本身，而是它们背后的一个变化：管理层的例会从”听汇报”变成了”看数据”。以前例会上讨论范围问题，靠的是项目经理的主观描述；现在讨论范围问题，直接打开视图看新增节点的变更源分布，讨论的是”这个月需求侧变更占新增的71%，我们要不要冻结两周”。

六、行动建议：按组织规模分三种打法

这一节的方法论强度会比较高，因为不同规模的组织，WBS落地的约束条件差异极大。用一套方法打所有规模，结果一定是小团队嫌重、大组织嫌轻。

1. 50人以下团队：轻量优先，别上字段

50人以下的团队，我建议只保留结构数据和责任数据两层，不要急着上三点估算和变更字段。

原因是这个规模的组织沟通成本极低，很多范围对齐可以靠日常沟通完成，强行上结构化字段反而会拖慢节奏。你要做的是三件事：

• 确保每个叶子节点都有明确的责任人和验收人，且两者不同。
• 每周固定十分钟过一遍任务包清单，看看有没有计划外的节点冒出来。
• 项目结项时把WBS归档，作为下一次类似项目的参考。

这三件事的投入很低，但能防止最严重的问题，范围完全无人掌控。等团队规模跨过50人，再把估算和变更两层补上。

2. 100-500人组织：四层全上，靠工具卡约束

这个规模是WBS数据化收益最大的区间。因为人多、项目多、沟通链变长，口头对齐的覆盖率急剧下降，而结构化的收益却随着规模上升。

我建议这类组织把前面讲到的四层数据全部落地，并且通过工具的流转约束来保证字段被填满，而不是靠培训和管理要求。培训只解决”知不知道”，工具才解决”做不做”。

落地顺序建议这样安排：第一步上责任数据和验收标准，这是最快见效也最容易推的；第二步上变更数据，把变更源和影响路径变成新增节点的必填项；第三步再上估算数据，因为估算能力需要时间积累，急不来。

3. 500人以上组织或多项目并行：先统一数据字典，再谈工具

500人以上的组织，最大的问题不是工具，而是各业务线对同一个字段的理解不一致。比如”变更源”这个字段，A部门理解为”需求来源”，B部门理解为”提交人部门”，两边数据放在一起就没法分析。

所以这个规模的组织，第一步必须是统一数据字典：把每一个字段的定义、取值范围、维护责任人、更新时点写成一份明确的文档，并且由跨部门的PMO或项目管理办公室来维护。这份文档的优先级高于任何工具选型。

第二步才是工具落地。这时候要特别关注工具是否支持多项目视图、跨项目资源调度、以及数据权限的细粒度控制。中大型组织往往还有数据合规要求，所以私有化部署能力也是硬门槛。

七、取舍：WBS管理没有最优解，只有适配解

这一节我想讲清楚几组必须做的取舍。管理者最容易犯的错，是希望同时拿到所有好处，而现实里每一组取舍都有明确的代价，选之前必须知道代价是什么。

1. 分解深度 vs. 维护成本

分解越深，估算精度越高，但维护成本上升得比精度更快。我的经验值是：当任务包的平均维护成本（填写、更新、评审）超过它自身工时的8%时，再往下拆就不划算了。

换句话说，一个20小时的任务包，如果维护它要花1.6小时以上，就应该合并到上一级。这个8%的阈值不是行业标准，是我在多个项目里试出来的经验值，不同组织的协作密度不同，可以上下浮动，但方向是明确的。

2. 工具约束 vs. 表格自由

表格自由度高，可以随意调整、快速试错，但字段完整度永远上不去。工具约束能力强，字段能填齐，但灵活性会牺牲一部分，遇到特殊项目会觉得”被卡住”。

我的判断是：当你的组织规模超过100人、且同时在建项目超过5个时，工具约束的收益一定大于自由度的损失。低于这个规模，表格可能更划算。

3. 标准统一 vs. 项目差异

统一标准的好处是数据可对比、可聚合、可沉淀基线；坏处是有些特殊项目会被标准”削足适履”。完全放开项目差异，则永远得不到跨项目的历史数据。

我建议采用“核心字段统一、扩展字段自由”的策略：责任、验收、变更源、估算这四个字段全组织统一，不允许各项目自行定义；其他字段允许项目根据自己的业务特征增加，但不纳入跨项目统计。

4. 冻结基线 vs. 拥抱变更

冻结基线能让范围控制有锚点，但会让组织变得僵化，错过合理的市场机会。完全拥抱变更则会导致范围无限膨胀。

我在实际操作中的做法是设置分级阈值：基线内5%以内的变更，项目经理可以自行批准；5%-15%的变更，需要走部门级评审；超过15%的变更，必须上升到管理层决策，并且要同步给出”砍掉什么”的等价方案。这套分级让大部分小变更不用上升到管理层，同时保证大变更一定会被看见。

八、可复用的WBS数据字典模板与下一步

最后给出可以直接拿去用的模板结构。我不建议你照搬字段名，更建议你看清楚每个字段解决什么问题，然后按自己组织的语言习惯重写一遍。

1. 模板结构

下面是一份最小可用的WBS数据字典定义，用配置文件的写法展示，你可以直接把它翻译成工具里的字段配置：

wbs_node:
第一层：结构数据

node_id:      { type: string, required: true, note: "项目内唯一，周期内不可变更" }

parent_id:    { type: string, required: true, note: "根节点为空" }

level:        { type: int,    required: true, range: [1, 8] }

第二层：责任数据

owner:        { type: user,   required: true, note: "执行责任人，到个人" }

acceptor:     { type: user,   required: true, rule: "acceptor != owner" }

resource_tag: { type: list,   required: true, note: "如：后端-支付域-高级" }

第三层：估算数据

estimate_o:   { type: hours,  required: true, note: "乐观值" }

estimate_m:   { type: hours,  required: true, note: "最可能值" }

estimate_p:   { type: hours,  required: true, note: "悲观值" }

baseline:     { type: hours,  required: false, note: "历史同类中位数" }

confidence:   { type: enum,   required: true, values: [high, mid, low] }

第四层：变更数据

change_source:{ type: enum,   required: true, values: [demand, tech, compliance, defect] }

approved:     { type: bool,   required: true }

impact_path:  { type: list,   required: true, note: "受影响的已有节点ID" }

approver:     { type: user,   required: true }

验收标准

acceptance:   { type: text,   required: true, rule: "必须包含可验证的完成条件" }

这份定义只有19个字段，但覆盖了四层数据的所有关键信息。它的价值不在于字段多，而在于每个字段都直接对应一个管理决策场景，资源标签对应资源调度，变更源对应范围归因，验收标准对应返工防控。

需要提醒一点：字段定义写完之后，一定要同步定义校验规则和触发条件，否则这份定义只是文档，不会变成行为。

2. 落地三步

如果你准备下周就开始动手，我建议按这三步走：

1. 先做一次现状扫描：统计当前所有在建项目的WBS字段完整度，分别按四层统计。这一步通常只需要半天，但会让你知道短板在哪一层。
2. 再选一个项目做试点：不要一次推所有项目，选一个周期在三到六个月、项目经理配合度高的项目，把四层字段和校验规则全部落地，跑满两个月。
3. 最后定标准推广：试点跑完拿到数据之后，用真实结果去说服其他项目经理，比用方法论说教有效得多。这时候再把字段定义和校验规则固化到工具配置里，全组织推广。

3. 下周可以做的第一件事

如果你只打算做一件事，我建议是这一件：把你当前在建项目里所有”没填验收标准”的叶子节点筛出来，然后逐个补上。

这件事不需要工具改造、不需要跨部门协调、不需要预算审批，只需要项目经理花几个小时。但从我的观察看，它能直接影响到返工工时占比这一项指标，而返工工时恰恰是范围失控最终体现在成本上的那一环。

返回开头那个案例，如果那份136行的WBS里，每个叶子节点都写清楚了”谁来验收、依据什么验收”，那么后来那54.8%的范围膨胀里，至少有一半的返工是可以避免的。WBS的效率提升从来不是靠一次大改造完成的，它靠的是把每一个看起来很小的字段，变成真正会被人使用的约束。