# Negative Feedback

> 用户观察到某个力量/趋势/行为过度亢盛需要引入制衡时; 当系统出现"越用力越糟糕"的过冲现象时; 当需要设计自我调节机制防止系统走向极端时; 当用户说"物极必反"或"用力过猛反而坏事"时。 不适用于: 需要持续单向推进不需要制衡的场景(如创业初期的全力冲刺); 问题本身就是力量不足而非亢盛的场景。

- Skill: `kangarooking/negative-feedback` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kangarooking/negative-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kangarooking/negative-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kangarooking (https://skillmd.com/u/kangarooking)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kangarooking/negative-feedback

---


# Negative Feedback — 亢害承制调控法

## R — 原文 (Reading)

> 相火之下，水气承之；水位之下，土气承之；土位之下，风气承之；
> 风位之下，金气承之；金位之下，火气承之；君火之下，阴精承之。
> 帝曰：何也？岐伯曰：亢则害，承乃制，制则生化，外列盛衰，害则败乱，生化大病。
>
> — 《黄帝内经·素问》，六微旨大论篇第六十八

---

## I — 方法论骨架 (Interpretation)

任何力量如果不受制约地持续亢盛，最终会伤害系统本身——这就是"亢则害"。
但自然界的健康系统中，每个亢盛的力量背后都跟着一个制约力量——这就是"承"。
"承乃制"——有了制约，系统才能保持动态平衡，维持正常的"生化"(运转发展)。
如果制约机制缺失，系统就会走向"败乱"。

这个框架揭示了一个反直觉的道理：制约不是发展的阻碍，而是发展的前提。
没有制约的亢盛不是"强大"，而是"正在走向崩溃的前兆"。

素问列举了六气之间的承制关系：火之下水承、水之下土承、土之下风承……
每一对都是"亢盛力量→制约力量"的结构。
这些承制关系是系统内置的负反馈环路——当A过度亢盛时，
B就被激活来制约A，使系统回归平衡。

迁移到现代场景：严格的KPI(亢)需要配合创新指标(承)来制约；
快速增长(亢)需要配合组织建设(承)来制约；
强势领导(亢)需要配合 dissent 机制(承)来制约。
关键是：承制机制要在亢盛之前就建好，而不是等亢盛出了问题再临时找。

---

## A1 — 书中的应用 (Past Application)

### 案例 1: 六气的承制关系
- **问题**: 为什么五运六气之中，每个主气之下都有一个"承"气？
- **方法论的使用**: 素问逐一列出六气的承制配对：相火之下水气承之(水制火)，水位之下土气承之(土制水)，土位之下风气承之(木制土)……这不是随意搭配，而是按照五行相克的逻辑——每个力量都由"克它"的力量来制约。
- **结论**: "亢则害承乃制制则生化"——有了承制，系统才能正常运转(生化)；失去承制，系统就会败乱。
- **结果**: 理解承制关系的医生能判断"这个亢盛是正常的(有承制)还是危险的(失去承制)"，从而决定是否需要干预。

### 案例 2: 胜复循环的自动调节
- **问题**: 当某个运气过度亢盛之后会发生什么？
- **方法论的使用**: 至真要大论指出"有胜则复，无胜则否"——有过度亢盛(胜)就必定有反弹回复(复)，这是系统的自动调节机制。比如某年火气太盛(胜火)，随后就会有一股寒凉之气来回复平衡(复)。
- **结论**: 胜复是自然的负反馈——过度的亢盛会自动唤起制约力量。但如果不等到自然回复就人为干预，或者更糟地继续推波助澜，就会破坏这个自动调节。
- **结果**: 懂得胜复规律的医生在亢盛初起时不急于强力干预，而是顺势引导回复；不懂的医生可能在亢盛期继续助阳，加剧过冲。

---

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?

1. **过冲现象**: 系统中某个力量已经明显过度——指标飙高、行为极端、趋势过热——用户发现"越用力越糟糕"，需要引入制衡来纠偏。
2. **设计自调节机制**: 用户在构建一个新系统/组织/流程，需要提前内置制约机制，防止某个环节的亢盛失控。
3. **单边推进后的反弹**: 持续朝一个方向用力之后出现了反弹(团队倦怠、市场反噬、系统崩溃)，用户需要理解"为什么会这样"并设计承制。

### 语言信号 (用户的话里出现这些就应激活)

- "越用力越糟糕"
- "物极必反"
- "用力过猛反而坏事"
- "需要引入制衡/制约"
- "这个趋势太猛了，会不会过热？"
- "单方面推太远了，需要拉回来"
- "系统缺乏自我调节机制"

### 与相邻 skill 的区分

- 与 `zheng-xie-assessment` 的区别: 亢害承制是发现"亢盛→引入制约"的调控动作，正邪虚实是判断"虚(不足)还是实(过盛)"的诊断动作。前者是"做了什么"，后者是"判断是什么"。两者经常串联使用：先用正邪虚实判断出"实(亢盛)"，再用亢害承制来"引入承制"。
- 与 `cascade-prediction` 的区别: 传变预测是"问题沿链条传播到下游"，亢害承制是"亢盛力量唤起制约力量"。前者是单向传播，后者是双向对抗。

---

## E — 可执行步骤 (Execution)

当 skill 被激活后, agent 应按以下步骤执行:

1. **识别哪个力量正在亢盛**
   - 观察系统中哪个指标、行为、趋势、力量正在持续走高、过度膨胀、失去节制。
   - 判断亢盛的程度：是"正常范围内的旺盛"还是"已经超出平衡的亢盛"？
   - 完成标准: 明确标注"亢盛力量是什么"以及"亢盛的具体表现"。

2. **找到或引入对应的制约力量(承)**
   - 按照"克它"的逻辑找到天然制约者：增长过快→质量/合规来承，强势领导→ dissent 机制来承，高产出→可持续发展来承。
   - 如果天然制约者已存在但力量不足，分析为什么不足以制衡(是被压制了还是太弱了)。
   - 如果不存在天然的制约力量，需要人为引入一个。
   - 完成标准: 明确标注"承制力量是什么"以及它应该如何制约亢盛力量。

3. **建立制衡机制使系统回归平衡**
   - 设计具体的承制机制：可能是制度(审批流程)、指标(对冲KPI)、文化(鼓励反对意见)、技术(熔断机制)等。
   - 确保承制力量不会矫枉过正——制衡的目标是"制则生化"(回归平衡)，不是"彻底压制"。
   - 完成标准: 产出制衡方案，包括：承制机制是什么、何时触发、何时退出、如何避免矫枉过正。

---

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill

- **需要持续单向推进的阶段**: 创业初期、攻坚阶段、危机应对——这些场景需要的是全力推进，过早引入制衡会束缚行动力。制衡是稳态管理的工具，不是冲锋阶段的工具。
- **问题本身就是力量不足**: 如果系统的问题是"太弱"而不是"太亢"，需要的是补强(参见 zheng-xie-assessment 的"虚则补")，而不是引入更多制约。

### 作者在书中警告的失败模式

- 不知承制而助亢——看到亢盛就以为是"强"而继续推波助澜，这是"亢则害"的直接原因。素问明确警告：亢盛而不制约，结局是"害则败乱，生化大病"。
- 承制过度——制约力量本身也可能亢盛，导致系统从"亢盛"跳到"压抑"，两个极端都不好。"制"的目标是"生化"而非"消灭"。

### 作者的盲点 / 时代局限

- 素问的承制关系是固定的(五行相克配对)，现实中的制约关系往往更复杂、更多对多。需要灵活寻找而非套用固定模式。
- 古代关注的是自然界的亢害承制(气候、运气)，现代场景中的"亢盛"可能更隐蔽(如隐性文化压力、算法的正反馈环路)，识别难度更高。

### 容易混淆的邻近方法论

- "负反馈"——这是亢害承制的现代科学表述，但素问版本更强调"为什么要承"（亢则害）和"承的目标"（制则生化），不仅描述机制还给出价值判断。
- "三权分立"——政治学中的权力制衡是亢害承制在制度设计上的体现，但素问的框架更通用，可用于任何系统(不仅是政治)。

---

## 相关 skills (阶段 3 填充)

- depends-on: yin-yang-balance — 亢害承制的"亢"本质上是阴阳某一方过盛(阳亢或阴亢),"承"是引入对立面来制约(阳亢则引入阴的力量来承制,阴亢则引入阳的力量来承制)。制衡的方向来自阴阳平衡的盛虚判断。
- contrasts-with: cascade-prediction — 传变预测关注"问题沿链条向下游传播"(线性传导),亢害承制关注"亢盛力量唤起制约力量"(双向对抗)。前者是预测传播路径,后者是引入制衡机制;一个是"问题会走到哪里",另一个是"如何在这里把它拉回来"。

---

## 审计信息

- **验证通过**: V1 ✓ / V2 ✓ / V3 ✓
- **测试通过率**: {{%}} (详见 test-prompts.json)
- **蒸馏时间**: 2026-04-18