
Four Seas Regulation
- 18 installs
- 29 repo stars
- Updated April 18, 2026
- kangarooking/huangdi-neijing-skill
Regulate major system hubs and distribution networks to maintain coherence across dispersed components.
About
Manages critical junctions and flows that keep distributed systems synchronized. Prevents collapse when peripheral parts diverge.
- Control hub points that synchronize system
- Regulate distribution flows for coherence
Four Seas Regulation by the numbers
- 18 all-time installs (skills.sh)
- +1 installs in the week ending Aug 2, 2026 (Skillselion tracking)
- Ranked #928 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/kangarooking/huangdi-neijing-skill --skill four-seas-regulationAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 18 |
|---|---|
| repo stars | ★ 29 |
| Last updated | April 18, 2026 |
| Repository | kangarooking/huangdi-neijing-skill ↗ |
What it does
Regulate major system hubs and distribution networks to maintain coherence across dispersed components.
Files
四海调节法: 核心枢纽管理
R — 原文 (Reading)
人有髓海, 有血海, 有气海, 有水谷之海, 凡此四者, 以应四海也。
气海有余则气满胸中悗息面赤, 气海不足则气少不足以言。
髓海有余则轻劲多力, 髓海不足则脑转耳鸣胫酸眩冒。
得顺者生, 得逆者败; 知调者利, 不知调者害。
审守其俞, 而调其虚实, 无犯其害。
>
— 黄帝/岐伯, 海论第三十三
---
I — 方法论骨架 (Interpretation)
四海调节法是一个通过管理系统的核心枢纽来调控整体的策略框架。
1. 识别核心枢纽: 复杂系统有若干"海"——资源汇聚和分配的核心节点。灵枢识别了四个: 水谷之海(供应链/消化吸收)、血海(资源池/血液)、气海(动力源/呼吸动力)、髓海(指挥中心/神经中枢)。
2. 每个海有输注点: 每个枢纽有入口(上输)和出口(下输), 管理就是"审守其输"——监控和管理这些进出口。
3. 有余不足各有征兆: 每个海的状态会通过特定信号表现出来: 气海有余=气满胸闷, 不足=气短; 髓海有余=轻劲多力, 不足=头晕耳鸣。通过监测信号来判断各海的状态。
4. 调其虚实不犯其害: 调节时不能伤害系统。方向正确则恢复("顺者得复"), 方向错误则败坏("逆者必败")。
---
A1 — 书中的应用 (Past Application)
案例 1: 髓海不足的诊断
- 问题: 一个人头晕耳鸣、腿酸无力、视力模糊、懈怠嗜睡, 是什么问题?
- 方法论的使用: 这些都是"髓海不足"的特征表现。髓海(脑)是全身的指挥中心, 髓海不足=指挥中心资源匮乏。
- 结论: 表面看起来是多个不相关的症状(头晕+耳鸣+腿酸+嗜睡), 实际上都指向同一个核心枢纽(髓海)的问题。
- 结果: 不需要逐个治疗每个症状, 只要调节髓海(通过其输注点), 所有症状都会改善。
案例 2: 气海的输注管理
- 问题: 如何管理气海(胸中宗气)?
- 方法论的使用: 气海的输注点: 上在柱骨之上下(颈部), 前在人迎(颈部动脉)。调节时通过这些输注点操作, "审守其俞而调其虚实"。
- 结论: 管理核心枢纽的关键是管理好它的输注点(进出口), 而不是直接操作枢纽本身。
- 结果: "无犯其害"——在输注点操作, 避免直接干预核心造成伤害。
---
A2 — 触发场景 (Future Trigger) ★
1. 多点异常同因: 系统多个地方同时出问题, 可能是某个核心枢纽失调。 2. 面面俱到失败: 试图管理所有细节但力不从心, 需要聚焦核心节点。 3. 资源分配失衡: 某些区域资源过剩某些不足, 需要从枢纽层面调控分配。
语言信号
- "到处都有问题, 顾不过来"
- "有没有一个核心问题导致所有这些"
- "怎么用有限精力管理这么多事情"
- "需要抓住关键点"
---
E — 可执行步骤 (Execution)
1. 识别系统的核心枢纽
- 列出系统中所有资源汇聚和分配的核心节点(供应链、资源池、动力源、指挥中心)。
- 完成标准: 识别出3-5个核心枢纽, 每个标注其功能和影响范围。
2. 监测各枢纽状态
- 每个枢纽有哪些"有余"和"不足"的信号? 当前的信号指向什么状态?
- 完成标准: 每个枢纽标注当前状态(有余/不足/正常)和判断依据。
3. 找到各枢纽的"输注点"
- 每个枢纽的关键进出口在哪里? 通过管理这些进出口来调节枢纽状态。
- 完成标准: 每个枢纽有至少1个可操作的输注点。
4. 调节虚实的优先级
- 哪个枢纽的问题最紧急? 先调哪个? "无犯其害"——确保调节不会造成新问题。
- 完成标准: 给出调节顺序和每步的预期效果。
---
B — 边界 (Boundary) ★
不要在以下情况使用
- 简单系统: 只有一个中心的简单系统不需要四海框架, 直接管理即可。
- 枢纽间无关联: 如果各枢纽完全独立, 框架简化为逐一管理。
失败模式
- 忽略非枢纽问题: 不是所有问题都来自核心枢纽, 有时确实需要处理末端问题。
- 过度集中: 过于关注枢纽而忽视边缘问题, 导致"灯下黑"。
---
审计信息
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 测试通过率: {{%}} (详见 test-prompts.json)
- 蒸馏时间: {{DATE}}
{
"skill": "four-seas-regulation",
"version": "0.1.0",
"test_cases": [
{
"id": "should-trigger-01",
"type": "should_trigger",
"prompt": "公司人很多但效率不高,感觉问题出在中间管理层太臃肿",
"expected_behavior": "调用 four-seas-regulation, 引导识别核心枢纽(管理层=气海), 判断其有余(臃肿)或不足(能力弱)",
"notes": "正面场景: 组织枢纽失调"
},
{
"id": "should-trigger-02",
"type": "should_trigger",
"prompt": "微服务架构中哪个服务是核心入口?它的状态会影响整个系统吗",
"expected_behavior": "调用 four-seas-regulation, 引导识别系统核心枢纽(API网关/注册中心), 判断其有余不足对全局的影响",
"notes": "正面场景: 系统核心枢纽识别"
},
{
"id": "should-trigger-03",
"type": "should_trigger",
"prompt": "供应链出了问题,想从关键节点入手优化,应该关注哪些环节",
"expected_behavior": "调用 four-seas-regulation, 引导找到供应链中的核心枢纽(仓储/物流/采购), 优先调节枢纽",
"notes": "正面场景: 多节点系统找核心"
},
{
"id": "should-not-trigger-01",
"type": "should_not_trigger",
"prompt": "帮我设计一个REST API",
"expected_behavior": "API设计, 不涉及枢纽管理",
"notes": "诱饵: 纯技术设计"
},
{
"id": "should-not-trigger-02",
"type": "should_not_trigger",
"prompt": "推荐几本管理学书籍",
"expected_behavior": "书籍推荐, 不涉及核心枢纽管理",
"notes": "诱饵: 非枢纽调控场景"
},
{
"id": "edge-01",
"type": "edge_case",
"prompt": "团队同时有技术leader和项目经理,两个都觉得自己是核心决策者",
"expected_behavior": "可触发, 涉及多枢纽冲突, 但也可能只是职责划分问题",
"notes": "边界: 多枢纽冲突vs简单职责问题"
}
]
}