理论约束（Theory of Constraints）
吞吐量受限的系统只有一个约束瓶颈。只改进该约束；对非约束做局部优化会浪费精力，且常常增加在制品（WIP）。
何时使用
- 延迟或吞吐量目标中，某一阶段主导了时间或速率。
- 工作在某一阶段前堆积；下游空闲。
- 在别处增加容量或人力并不能提高端到端产出。
- 需要有序计划：先廉价地“利用”，再花钱“提升”。
何时不使用
- 负载分散；没有阶段占主导——应使用系统方法处理交互。
- 问题是正确性/故障，而非流速——应调试故障。
- 瓶颈因耦合/争用每次运行都跳变，没有稳定阶段——应做系统或并发设计，而非五步聚焦法。
- 约束已知且廉价修复已就绪——直接应用，无需仪式。
流程
- 定义流程与目标。命名工作单元（请求、作业、PR、记录）和关键指标（端到端速率或延迟）。
- 用证据识别约束。在利用率、队列/等待和吞吐量上比较各阶段。约束信号：接近 100% 使用、最长队列、最低阶段速率、工作在此堆积、更多输入不提高系统产出。优先使用实测速率而非意见。若两个候选并列，先选其改进能提高系统吞吐量的那个。
- 利用（无重大支出）。最大化约束产出：减少空闲、去掉约束上的非必要工作、减少返工/准备、保护其时间、在约束处改进质量以免产出被浪费。支出前先估算收益。
- 从属非约束。让上游按约束速率节拍；不要灌入 WIP。让其他阶段服务于约束（就绪、清晰、即时拉取）。拒绝在约束之前增加队列的局部利用率目标。
- 仅在仍不足时提升。利用已最大化后，投资提高约束容量（人员、工具、分片、并行路径）。选择最便宜的足够提升。
- 复查（防止惯性）。提升或大幅利用后，重新测量所有阶段——约束常会移动。返回第 2 步。不要继续优化旧约束。
当约束、证据、利用计划、从属规则和提升与否决策都明确时停止——或当没有单一阶段约束时停止（退出到系统方法）。
输出
system_goal: <吞吐量/延迟目标> flow: <阶段序列> constraint: <阶段或资源> evidence: <利用率 / 队列 / 速率事实> exploit: <行动、预期收益> subordinate:
- stage: <名称> change: <如何服务于约束> elevate: <无 | 选项 + 成本/收益> next_constraint_watch: <变更后重新测量什么>
验证
- 证伪：如果提高所命名阶段不能增加系统吞吐量（另一阶段已封顶），则识别错误。如果非约束优化改变了端到端速率，则重新识别。
- 停止：在利用耗尽前不要提升。不要“以防万一”优化多个阶段。
- 过度应用防护：一次一个约束。上游空闲容量不是要填满的问题。不要在没有约束阶段的纯多回路涌现中使用 TOC 语言。