mcpField
T
thinking-systems

thinking-systems

github.com/tjboudreaux开发1.7k617 次安装12 周前更新
代码仓库

关于 thinking-systems

一种系统思维技能,用于梳理组件、流量、反馈回路与延迟之间的相互作用。帮助团队诊断跨组件的反复问题,并在检查副作用的同时排列干预措施。

主要功能

  1. 01界定系统边界
  2. 02梳理存量与流量
  3. 03识别反馈回路和延迟
  4. 04检查反复出现的系统模式
  5. 05按杠杆效应和风险排列干预

适用场景

  1. 01诊断涉及多个服务的症状
  2. 02调查局部修复后再次出现的问题
  3. 03在变更可能引发副作用时选择干预措施

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/tjboudreaux/cc-thinking-skills --skill thinking-systems

安装后在 Claude Code 中输入/thinking-systems确认已加载。

详细介绍

系统映射与杠杆点

将问题视为结构与交互,而非孤立的部分。绘制边界、存量/流量、回路/延迟和反复出现的模式;检查副作用后,在可行的最高杠杆点进行干预。

适用场景

  • 症状跨越多个服务/组件;单一技术栈的修复失败或反复出现。
  • 一处的改动会破坏另一处;行为是涌现的。
  • 尽管做了局部修复,问题仍反复出现(问题在结构,而不仅是症状)。
  • 参数/缓冲区调整无法奏效,需要为干预措施排序。

不适用场景

  • 单个组件中的线性 Bug,且有明确的调用栈/差异——追踪并修复。
  • 吞吐量受一个明显的阶段限制——使用约束理论。
  • 决策是某项拟议行动所引发的一连串后果——使用二阶思维。
  • 选择方法(规划还是探查、还是稳定)——先使用 Cynefin。

流程

  1. 界定系统边界。 说明目的、参与者、边界以及输入/输出流。排除决策时间范围之外的噪声;纳入任何可能导致该症状的路径。
  2. 绘制存量与流量。 列出不断累积的存量(队列深度、技术债、缓存大小、在制品),以及使其增加/减少的速率。注意即使流量骤变,哪些因素仍会缓慢变化。
  3. 找出反馈与延迟。 对每个候选回路:标明它是强化型(放大)还是平衡型(抑制);标注同向(+)或反向(-)链接;说明延迟(TTL、部署延迟、指标延迟、爬坡时间)。反向链接的数量为偶数 → 强化型;为奇数 → 平衡型。延迟长且纠正力度大 → 有超调风险。
  4. 问题复发时,匹配反复出现的结构。 仅在存在复发或政策阻力时检查;不要强行套用模式:
    • 修复失效(Fixes That Fail)——快速修复引发延迟出现的更严重副作用
    • 转移负担(Shifting the Burden)——变通方案挤占根本性修复的资源
    • 成长上限(Limits to Growth)——增长遭遇平衡性约束
    • 公地悲剧(Tragedy of the Commons)——局部最优耗尽共享存量
    • 升级恶化(Escalation)——相互反应形成螺旋
    • 富者愈富(Success to the Successful)——优势通过资源分配不断累积
    • 成长与投资不足(Growth and Underinvestment)——产能滞后于需求,直至危机发生 若认真检查后仍无匹配模式,则保留从零开始绘制的系统图。
  5. 从症状追溯结构。 沿着流量与回路向上游追踪;区分直接症状与结构性驱动因素(交互、延迟、错误目标、信息缺失)。
  6. 先按杠杆点排序干预措施,再考虑副作用。 优先选择可行的较高层级:目标/范式 → 规则/信息 → 回路结构(增益、增加平衡机制、缩短延迟)→ 存量/流量拓扑 → 缓冲区/参数。对每个候选方案评估:可行性、影响范围、延迟反转风险。优先选择能削弱有害强化增益,或强化所需平衡回路,且不会引发新的公地悲剧/升级恶化的措施。
  7. 停止。 确定可行的最高杠杆点干预措施,并设置用于观察回路/延迟响应的信号。仅当结构发生变化或干预未通过观察验证时,才重新绘图。

满足以下条件时停止: 已说明边界、关键存量/流量、主导回路及延迟、可选的系统基模,以及经过副作用检查并已排序的干预措施;或者问题已归结为单一线性原因。

输出

boundary: <system purpose and edges>
stocks_flows: <stock → inflow/outflow list>
loops:
  - name: <loop>
    type: reinforcing | balancing
    delay: <where cause lags effect>
    links: <brief +/->
archetype: <name or none>
structural_driver: <one sentence>
interventions_ranked:
  - level: <goals|rules|loops|structure|params>
    action: <what>
    side_effects: <feedback/elsewhere/delay risk>
chosen: <highest feasible>
watch: <signals that confirm or falsify>

验证

  • 证伪: 如果移除一个组件就能完全解释并解决问题,且没有跨组件影响,那么系统映射就是错误的——改用局部调试。如果利用率显示只有一个固定阶段构成瓶颈,则改用约束理论。
  • 停止: 选定干预措施并设定观察方案后,不要继续添加回路。
  • 避免过度应用: 没有复发证据时,不要套用系统基模。存在可行的更高层级方案时,不要将低杠杆参数调整列为首选。不要重新创建独立的系统基模/反馈/杠杆点流程——这些检查仅属于此映射流程。

评论

支持 Markdown