# Qi Regulation

> 用户需要解决某个系统的功能失调问题时; 当直接处理表面症状无效时; 当需要理解"调气"(恢复功能状态)与"治形"(处理表面表现)的区别时; 当想要从根本上恢复系统的正常运行状态时。 不适用于: 纯信息查询、没有系统失调的场景、只需要描述现象不需要解决的场景。

- Skill: `kangarooking/qi-regulation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kangarooking/qi-regulation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kangarooking/qi-regulation/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/qi-regulation

---


# 调气治本框架

## R — 原文 (Reading)

> 用针之类, 在于调气。气积于胃, 以通营卫, 各行其道。
> 凡用针者, 虚则实之, 满则泄之, 宛陈则除之, 邪胜则虚之。
> 气至而有效, 效之信, 若风之吹云, 明乎若见苍天。
>
> — 黄帝/岐伯, 九针十二原第一、刺节真邪第七十五

---

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

调气治本框架是一个从"处理表面症状"转向"恢复系统功能状态"的元方法论。

其核心操作分为四层:

1. **识形气**: 区分"形"(表面表现/结果)和"气"(功能状态/原因)。症状是形, 导致症状的功能失调是气。头痛是形, 气血不通是气; 团队效率低是形, 沟通通道阻塞是气。

2. **调气而非治形**: 干预的目标不是消除表面现象, 而是恢复系统的正常运行功能。"用针之类在于调气"——一切手段都服务于恢复功能状态这个根本目标。

3. **四个方向**: 虚则补(增益不足), 实则泻(祛除多余), 宛陈则除(疏通淤滞), 邪盛则祛(排除干扰)。先判断属于哪种情况, 再选方向。

4. **有效的验证标准**: "气至而有效"——系统产生积极反应是干预有效的标志。效果应该是可感知、可验证的, "若风之吹云"般清晰。

这个框架的威力在于: 将注意力从"问题表现"转移到"系统功能", 从"消灭症状"转移到"恢复秩序"。

---

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

### 案例 1: 久病不愈的根因
- **问题**: 久病是否不可治?
- **方法论的使用**: 岐伯用四个比喻回答——"刺虽久犹可拔也, 污虽久犹可雪也, 结虽久犹可解也, 闭虽久犹可决也"。关键不是病了多久, 而是方法对不对。"疾虽久犹可毕也, 言不可治者未得其术也。"
- **结论**: 问题拖得久不代表不能解决, 而是之前的干预一直在治形(处理表面), 没有调气(恢复功能)。
- **结果**: 找到正确的功能恢复路径, 久病也能治愈。

### 案例 2: 经脉不通的解结法
- **问题**: 一条经脉上实下虚, 气血不通, 如何处理?
- **方法论的使用**: "此必有横络盛加于大经, 令之不通"——先找到阻塞原因(横络压迫), 然后"视而泻之, 此所谓解结也"——在阻塞点精准疏通。
- **结论**: 不是整条经脉都有问题, 而是某个点阻塞导致全线不通。调气就是找到并疏通这个关键阻塞点。
- **结果**: 阻塞疏通后, 气血自然恢复流通, "营卫之行上下相贯如环之无端"。

---

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

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

1. **反复处理表面问题无效**: 用户一直在"灭火"但问题反复出现, 需要从"治形"转向"调气"。
2. **系统功能失调**: 某个系统(团队/身体/流程)的核心功能不正常, 直接干预无效, 需要恢复其运行状态。
3. **长期问题久拖不决**: 问题存在很长时间, 多种方法都试过但无效, 需要"治本"思维。

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

- "这个问题反复出现, 怎么也解决不了"
- "一直在救火, 从来没有从根本上解决"
- "各种方法都试过了还是不行"
- "感觉系统本身出了问题, 不只是某个环节"

### 与相邻 skill 的区分

- 与 `excess-deficiency-decision` 的区别: 调气治本是**元原则**(干预的目标是恢复功能), 虚实补泻是**操作方向**(具体该怎么补或泻)。先确定"要调气", 再用虚实补泻决定"怎么调"。
- 与 `bottleneck-unblock` 的区别: 调气治本是**思维方式**(关注功能而非形式), 解结通滞是**具体方法**(找阻塞点疏通)。调气是"为什么要这样做", 解结是"具体怎么做"。

---

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

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

1. **区分形与气: 识别表面现象与功能失调**
   - 列出当前所有的"形"(可观察到的异常表现/症状), 然后追问每个"形"背后的"气"(是什么功能失调导致了这个表现)。
   - 完成标准: 每个"形"都找到了对应的"气", 且"气"是功能性描述而非现象重复。

2. **判断属于四种情况中的哪一种**
   - 虚(功能不足→需要增益) / 实(功能亢盛→需要抑制) / 瘀(功能阻塞→需要疏通) / 邪(外部干扰→需要排除)。
   - 完成标准: 明确给出判断并说明依据。
   - 判停条件: 如果多种情况并存, 标记为"混合型", 分别处理。

3. **制定调气方案: 恢复系统功能**
   - 根据判断结果, 制定恢复功能状态的方案(补/泻/疏通/排除)。方案的目标是"系统恢复自主运行", 不是"持续依赖外部干预"。
   - 完成标准: 给出至少1个具体的功能恢复动作, 并说明恢复后系统应有的自主运行状态。

4. **验证有效性: "气至而有效"**
   - 设定干预后可观测的验证指标。效果应该是可感知、可验证的。
   - 完成标准: 明确列出"干预有效"的1-2个可观测标准。

---

## B — 边界 (Boundary) ★

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

- **纯信息查询**: 用户只是想了解某个现象是什么, 不涉及系统功能失调, 不需要调气。
- **没有系统失调**: 如果系统运行正常只是外观不理想, 这不是功能问题, 调气框架不适用。

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

- **治形不治气**: 只处理表面症状而不恢复功能, 等于扬汤止沸。"言不可治者未得其术也"——方法不对不是问题不能治。
- **方向错误**: 如果虚实判断错误(把虚当实去泻), 会加重功能失调。"虚而泻之则经脉空虚, 血气竭枯。"

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

- 灵枢将一切失调归结为"气"的功能性概念, 但现代系统问题可能有结构性原因(如组织架构、技术债务), 此时"调气"(恢复功能)需要配合"调形"(改变结构)。

---

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

- composes-with: excess-deficiency-decision — 调气治本确定"要做什么"(恢复功能), 虚实补泻确定"怎么做"(补还是泻)。
- composes-with: bottleneck-unblock — 调气治本是思维方式, 解结通滞是具体方法, 二者经常串联使用。

---

## 审计信息

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