theory-of-constraints

约束理论

一份诊断操作手册，通过伊莱亚胡·高德拉特的约束理论（ToC）优化任何流程——CI/构建流水线、开发价值流、Agent Skill 或插件，或运行时代码路径。

让 ToC 强大的核心理念是：任何系统在同一时间都恰好只有一个制约约束，只有改善这一约束，全局吞吐量才会提升。在其他地方投入精力毫无效果——“在非瓶颈处节省一小时，只是海市蜃楼。”本操作手册通过测量找出约束，然后按照五大聚焦步骤予以缓解，同时避免引发新问题。

何时应用

当用户希望优化流程或工作流，且符合以下任一情况时，使用此技能：

• 他们想优化，却不知道从何处着手（“让这个更快”“为什么这么慢”“降低这部分的成本”）。
• 局部提速没有改变端到端结果（优化错了地方）。
• 工作、队列或 WIP 堆积在某个阶段，而其他阶段却闲置。
• 一切看起来都处于 100% 忙碌状态，但产出很少（利用率高，吞吐量低）。
• 他们增加了产能、并行度或资源，却没有效果。
• 解决一个瓶颈后，另一个瓶颈随即显现。
• 真正的限制是策略或规则，而不是资源（必须运行完整测试套件、评审必须串行、“阅读所有参考资料”的指令、所有发布都必须批量进行）。
• 他们困在阻碍显而易见解决方案的取舍中（“更快还是更安全”“更小的上下文还是更广的覆盖范围”）。

以下情况不要使用此技能：

• 已经定位到具体热点，且已知约束所在——直接修复即可（例如 O(n²) 循环 → complexity-optimizer）。
• 纯粹进行正确性/质量审查，没有提升吞吐量的目标——使用代码审查技能。
• 还没有证明某个阶段就是约束时，不要对它进行微优化。这是 ToC 最根本的错误；此技能正是为了避免这种情况。

持续改进流程（POOGI）

ToC 是一个循环，而不是一次性流程。务必按顺序执行——先挖掘而非提升资源，这正是 ToC 与“直接投入更多资源”的区别。

        ┌─────────────────────────────────────────────────┐
        │                                                   │
        ▼                                                   │
1. IDENTIFY the constraint  ── the one stage that gates global throughput
        │
        ▼
2. EXPLOIT it               ── get the most from it with NO new spend
        │                       (remove waste/idle on the constraint)
        ▼
3. SUBORDINATE everything   ── pace all non-constraints to the constraint;
   else to the constraint      let them idle rather than build WIP
        │
        ▼
4. ELEVATE the constraint   ── only now add capacity / invest / parallelize
        │
        ▼
5. REPEAT                   ── the constraint has moved; go to step 1.
        │                       Do NOT let inertia (old policies) be the
        └───────────────────────new constraint.

最常见的错误与跳过步骤直接相关：在第 2 步（挖掘）之前跳到第 4 步（提升资源），或始终没有执行第 1 步（优化最显眼的环节，而不是制约环节）。

常见症状

从这里开始。找到对应症状，打开其决策树，运行快速检查。

症状	常见约束	快速检查	决策树
“优化一下，但不知道从哪里入手”	未知——先测量	queries/measure-stage-times.sh	查找约束
局部提速，但整体没有收益	优化了非约束环节	queries/throughput-accounting.py	局部最优
某个阶段的队列/WIP 不断堆积	约束位于堆积处或紧接其下游	queries/measure-wip.sh	WIP 积累
到处都很忙，但交付很少	非约束环节过度激活	queries/utilization-vs-throughput.py	利用率陷阱
增加了产能，却没有改善	提升了错误的环节／跳过了充分利用	queries/measure-stage-times.sh	提升失效
修复一个瓶颈后，另一个又出现了	约束已转移（这是预期情况）	queries/measure-stage-times.sh	约束转移
某条规则／流程限制了进度	策略约束	queries/five-focusing-steps.sh	策略约束
陷入取舍困境	显现出的两难阻碍了修复	（推理——化解冲突云）	冲突解决

对于 Agent Skills／插件，约束最常见的是始终加载的上下文预算（臃肿的 SKILL.md），或薄弱的描述（技能从不触发，因此其吞吐量为零）。运行 queries/skill-context-cost.sh <skill-dir>。

使用方法

1. 在上表中找到症状，然后打开 references/ 中对应的决策树。
2. 先定义目标和吞吐量指标。 如果没有需要提升的全局指标，ToC 就毫无意义（例如每周合并的 PR 数、每秒请求数、每次 Agent 会话完成的任务数、构建墙钟时间）。这些决策树假定你已经有一个指标——通过 config.json 设置，或询问用户。
3. 运行决策树指定的快速检查查询。 查询位于 references/queries/；每个查询都在标题中说明参数及输出的解读方法。
4. 沿决策树推进，直到得到终端操作。每条路径最终都会导向一项具体的 ToC 举措（充分利用／从属／提升／改变策略／重复）。
5. 使用 assets/templates/report.md 记录发现。 在调查日志中追加一行记录，以便随着时间推移识别反复出现的约束。

如需查看包含入口点和严重程度的完整目录，请阅读 references/symptoms.md。

设置

此技能使用 config.json 确定被研究系统中的“吞吐量”含义，以及如何测量各个阶段。首次使用时，如果 goal_metric 或 value_stream_stages 为空，请通过 AskUserQuestion 询问用户：

• 目标指标（要最大化的全局吞吐量），以及
• 要优化的工作流的有序阶段。

然后将它们保存到 config.json。如果无法填写配置，技能仍可正常工作——改为在对话中询问用户，并手动测量各阶段。切勿因缺少配置而中断。

注意事项

经典的 ToC 陷阱（测量局部效率、先提升而非先充分利用、优化最显眼的阶段）记录在 gotchas.md 中。首次调查前请先阅读——避免这些错误正是 ToC 存在的意义。

相关技能

• complexity-optimizer — 如果 ToC 确定某个代码阶段是约束，请用它找出并修复该阶段中的算法热点。
• dx-harness — 如果约束是开发者体验方面的繁琐工作（启动缓慢、手动步骤），此工具会审查并修复相应的工具链。
• dev-skill:evolve — 如果约束本身是 Agent Skill（上下文臃肿、触发薄弱），此工具会对其进行改进。