关于 thinking-systems
一种系统思维技能,用于梳理组件、流量、反馈回路与延迟之间的相互作用。帮助团队诊断跨组件的反复问题,并在检查副作用的同时排列干预措施。
主要功能
- 01界定系统边界
- 02梳理存量与流量
- 03识别反馈回路和延迟
- 04检查反复出现的系统模式
- 05按杠杆效应和风险排列干预
适用场景
- 01诊断涉及多个服务的症状
- 02调查局部修复后再次出现的问题
- 03在变更可能引发副作用时选择干预措施
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ tjboudreaux/ cc-thinking-skills --skill thinking-systems安装后在 Claude Code 中输入/thinking-systems确认已加载。
详细介绍
系统映射与杠杆点
将问题视为结构与交互,而非孤立的部分。绘制边界、存量/流量、回路/延迟和反复出现的模式;检查副作用后,在可行的最高杠杆点进行干预。
适用场景
- 症状跨越多个服务/组件;单一技术栈的修复失败或反复出现。
- 一处的改动会破坏另一处;行为是涌现的。
- 尽管做了局部修复,问题仍反复出现(问题在结构,而不仅是症状)。
- 参数/缓冲区调整无法奏效,需要为干预措施排序。
不适用场景
- 单个组件中的线性 Bug,且有明确的调用栈/差异——追踪并修复。
- 吞吐量受一个明显的阶段限制——使用约束理论。
- 决策是某项拟议行动所引发的一连串后果——使用二阶思维。
- 选择方法(规划还是探查、还是稳定)——先使用 Cynefin。
流程
- 界定系统边界。 说明目的、参与者、边界以及输入/输出流。排除决策时间范围之外的噪声;纳入任何可能导致该症状的路径。
- 绘制存量与流量。 列出不断累积的存量(队列深度、技术债、缓存大小、在制品),以及使其增加/减少的速率。注意即使流量骤变,哪些因素仍会缓慢变化。
- 找出反馈与延迟。 对每个候选回路:标明它是强化型(放大)还是平衡型(抑制);标注同向(+)或反向(-)链接;说明延迟(TTL、部署延迟、指标延迟、爬坡时间)。反向链接的数量为偶数 → 强化型;为奇数 → 平衡型。延迟长且纠正力度大 → 有超调风险。
- 问题复发时,匹配反复出现的结构。 仅在存在复发或政策阻力时检查;不要强行套用模式:
- 修复失效(Fixes That Fail)——快速修复引发延迟出现的更严重副作用
- 转移负担(Shifting the Burden)——变通方案挤占根本性修复的资源
- 成长上限(Limits to Growth)——增长遭遇平衡性约束
- 公地悲剧(Tragedy of the Commons)——局部最优耗尽共享存量
- 升级恶化(Escalation)——相互反应形成螺旋
- 富者愈富(Success to the Successful)——优势通过资源分配不断累积
- 成长与投资不足(Growth and Underinvestment)——产能滞后于需求,直至危机发生 若认真检查后仍无匹配模式,则保留从零开始绘制的系统图。
- 从症状追溯结构。 沿着流量与回路向上游追踪;区分直接症状与结构性驱动因素(交互、延迟、错误目标、信息缺失)。
- 先按杠杆点排序干预措施,再考虑副作用。 优先选择可行的较高层级:目标/范式 → 规则/信息 → 回路结构(增益、增加平衡机制、缩短延迟)→ 存量/流量拓扑 → 缓冲区/参数。对每个候选方案评估:可行性、影响范围、延迟反转风险。优先选择能削弱有害强化增益,或强化所需平衡回路,且不会引发新的公地悲剧/升级恶化的措施。
- 停止。 确定可行的最高杠杆点干预措施,并设置用于观察回路/延迟响应的信号。仅当结构发生变化或干预未通过观察验证时,才重新绘图。
满足以下条件时停止: 已说明边界、关键存量/流量、主导回路及延迟、可选的系统基模,以及经过副作用检查并已排序的干预措施;或者问题已归结为单一线性原因。
输出
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