Skip to content
cccskills
FreePublished on GitHub

prevention-strategy

用户想预防某个潜在风险或问题时; 当系统出现早期预警信号但尚未爆发时; 当已出现问题需要防止恶化和扩散时; 当需要建立长期防护机制时。不适用于: 紧急危机处理(系统正在崩溃, 需要急救而非预防); 纯历史回顾 (分析过去发生了什么但不涉及未来预防)。

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (2)

  • SKILL.md8.8 KB
  • test-prompts.json5.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

治未病预防策略

R — 原文 (Reading)

是故圣人不治已病, 治未病; 不治已乱, 治未乱, 此之谓也。夫病已成而后药之, 乱已成而后治之, 譬犹渴而穿井, 斗而铸锥, 不亦晚乎? 上工救其萌牙, 必先见三部九候之气, 尽调不败而救之, 故曰上工。下工救其已成, 救其已败。 正气存内, 邪不可干。

— 岐伯, 四气调神大论篇第二、八正神明论篇第二十六、刺法论篇第七十二


I — 方法论骨架 (Interpretation)

治未病预防策略是一套分阶段的系统化预防方法论, 包含三个层级:

  1. 未病先防(第一层): 在问题出现之前就建立防护机制。"正气存内, 邪不可干"——核心逻辑是增强系统自身的抵抗力, 而不是等外邪来了再对抗。这对应现代的"免疫力建设""冗余设计""安全边际"等概念。

  2. 欲病早治(第二层): 在问题刚露苗头时就介入。"上工救其萌芽"——高明者能在问题还很微小时就识别并处理, 而不是等到问题全面爆发。关键能力是识别"早期预警信号"——那些还没有造成实质损害但已经偏离正常的小变化。

  3. 既病防变(第三层): 问题已经发生, 重点转向防止恶化和扩散。不是被动治疗, 而是主动阻断问题向其他子系统传导的路径。

这套策略的独特之处在于它的分层递进: 不是笼统地说"预防很重要", 而是针对三个不同阶段提供了不同的策略和能力要求。"上工"之所以高于"下工", 不在于治疗能力更强, 而在于介入时机更早。


A1 — 书中的应用 (Past Application)

案例 1: 渴而穿井——预防时机的比喻

  • 问题: 为什么强调在疾病发生前就干预?
  • 方法论的使用: 用"渴而穿井, 斗而铸锥"(口渴了才挖井, 打仗了才铸造武器)来说明——等到问题爆发再处理, 为时已晚。这是对第一层(未病先防)的核心理念的生动阐释。
  • 结论: 干预时机决定效果上限。越早介入, 所需资源越少, 效果越好。
  • 结果: 这一比喻确立了"预防先于治疗"的基本原则, 成为贯穿素问全文的指导思想。

案例 2: 上工救其萌芽——早期识别的能力

  • 问题: 如何判断一个高手?
  • 方法论的使用: "上工救其萌芽, 必先见三部九候之气, 尽调不败而救之"——高手不是治病最厉害的人, 而是最早发现问题并处理的人。他们能从微小的信号变化(三部九候之气)中读出未来的风险。
  • 结论: 预防能力的核心不是"怎么做", 而是"什么时候做"和"从什么信号判断该做了"。
  • 结果: "上工"的标准被定义为: 能在问题还是萌芽状态时就识别并处理, 且处理时系统尚未败坏(尽调不败), 成功率最高。

A2 — 触发场景 (Future Trigger) ★

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

  1. 潜在风险预防: 用户知道某个风险可能发生(如项目可能延期、系统可能崩溃、健康可能出现问题), 想提前建立防护机制。
  2. 早期信号识别: 系统出现了一些微小的异常(间歇性变慢、偶尔的沟通不畅、轻微的不适), 尚未造成实质影响, 用户不确定是否需要现在就处理。
  3. 防止问题扩散: 问题已经发生, 用户不仅想解决当前问题, 还想防止它波及其他领域——"既病防变"。

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

  • "怎么预防/避免X的发生"
  • "现在有一点苗头, 但还不严重"
  • "如果等到X发生就晚了"
  • "怎么建立长期防护/防御机制"
  • "出了这个问题, 会不会影响到其他方面"

与相邻 skill 的区分

  • 与 biao-ben-priority 的区别: 标本缓急处理的是"已经存在的多个问题的优先级", 治未病处理的是"尚未发生或刚刚萌芽的问题的预防策略"。
  • 与 five-elements-network 的区别: 五行生克用于分析连锁传导的路径, 治未病用于决定在传导链上的干预时机(在传导发生之前就阻断)。

E — 可执行步骤 (Execution)

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

  1. 识别当前阶段: 未病/欲病/已病

    • 评估系统当前状态: (1)未病——一切正常, 但存在潜在风险因素; (2)欲病——出现早期预警信号, 但尚未造成实质损害; (3)已病——问题已经发生并造成影响。判断依据是: 是否有可观测的异常信号? 异常是否已造成功能性损害?
    • 完成标准: 明确给出当前阶段判定(未病/欲病/已病), 并列出判定依据(有哪些信号或证据)。
  2. 选择对应策略: 预防/早治/防变

    • 根据阶段选择策略: (1)未病→"正气存内, 邪不可干"——增强系统自身抵抗力, 消除风险因素; (2)欲病→"上工救其萌芽"——立即处理早期信号, 阻止其发展为正式问题; (3)已病→"既病防变"——在治疗当前问题的同时, 识别并加固可能被波及的其他子系统。
    • 完成标准: 给出与阶段匹配的策略名称和核心行动方向。
    • 判停条件: 若判定为"已病"且情况紧急(系统正在快速恶化), 应先切换到 biao-ben-priority 框架处理紧急问题, 稳住后再回到防变策略。
  3. 执行预防方案: 具体行动 + 监控指标

    • 将策略转化为具体行动: 列出2-3个可立即执行的动作。同时建立监控指标——用来持续跟踪系统状态, 确保(1)未病的保持未病, (2)欲病的信号在消退, (3)已病的没有扩散到新区域。
    • 完成标准: 给出行动清单(每项有明确的执行者/时间/验收标准)和至少1个监控指标(用于判断策略是否有效)。

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

  • 紧急危机处理: 当系统正在崩溃(服务器宕机、大出血、团队集体离职), 没有"预防"的空间, 必须先做紧急处置。治未病是在有喘息空间时的策略。
  • 纯历史回顾: 如果用户只是想分析过去发生了什么(复盘), 而不涉及"未来如何预防", 这不是治未病的场景。

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

  • 渴而穿井: 等到问题全面爆发再处理, 就像口渴了才挖井——虽然也能挖出水, 但代价远大于提前准备。这个失败模式的核心是"时机延误"。
  • 下工救其已成: 低水平的人只会处理已经明显的问题, 错过了萌芽阶段的最佳干预窗口。这不是能力问题, 而是"信号识别能力"的不足——看不到微小的早期征兆。

作者的盲点 / 时代局限

  • 素问的预防策略以个人健康为默认场景, "正气""邪气"等概念需要转化到具体领域。在企业管理、工程项目等领域, "正气"可以理解为"组织韧性""系统鲁棒性", "邪气"可以理解为"外部风险""内部隐患"。
  • 素问强调预防, 但没有讨论预防的成本。现实中, 过度预防(为每个可能的风险都建立防护)会消耗过多资源。需要结合标本缓急框架来确定预防的优先级和投入程度。

容易混淆的邻近方法论

  • 风险管理(Risk Management): 商业上的风险管理侧重于风险识别、评估、缓解, 但没有治未病的"三层递进"结构(未病先防/欲病早治/既病防变)。
  • PDCA循环: 持续改进框架, 但侧重"做事-检查-改进"的循环, 不强调"介入时机"的分层策略。

相关 skills (阶段 3 填充)

  • depends-on: observation-inference — 治未病的核心能力之一是"上工救其萌芽"——识别早期预警信号,这依赖于以外测内推理的多信号交叉验证能力。看不到微弱信号就无法做到早期干预。
  • composes-with: cascade-prediction — 治未病的"既病防变"层级需要预判问题会沿什么路径扩散到其他子系统,传变预测提供"沿相克链画传播路径"的方法。两者组合实现"识别风险→预判扩散路径→提前布防"的完整预防链。

审计信息

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

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

用户面对多个需要同时处理的问题, 不确定优先级时; 当表面症状和根本原因交织 在一起, 不确定该先解决哪个时; 当问题有"先发的"和"后发的"之分时。 不适用于: 只有一个明确问题的场景; 问题之间没有因果关联的独立问题集合; 紧急危机处理(需要先稳住再分析)。

The English summary is being prepared. Showing the original description.

kangarooking/huangdi-neijing-skill42Updated Apr 18, 2026

用户需要理解心理状态与生理/系统状态之间的因果联系时; 当情绪问题导致身体/工作表现下降时; 当需要管理情志以保护系统功能时。 不适用于: 纯技术问题没有心理因素的场景、纯心理咨询场景。

The English summary is being prepared. Showing the original description.

kangarooking/huangdi-neijing-skill42Updated Apr 18, 2026

用户面对系统阻塞/瓶颈问题, 需要找到阻塞点并疏通时; 当系统"上实下虚" 或"上虚下实"等方向性阻塞时; 当直接在问题点干预无效, 需要另辟蹊径时。 不适用于: 没有阻塞的问题、可以简单修复的场景、纯资源不足(非阻塞型)的场景。

The English summary is being prepared. Showing the original description.

kangarooking/huangdi-neijing-skill42Updated Apr 18, 2026

用户需要预测某个局部问题会如何扩散到其他部分时;当系统中一个环节出了问题需要评估连锁影响时; 当需要提前在传变路径上设防时;当用户说"这个问题会不会引发其他问题"或"如果不处理会怎样"时。 不适用于: 孤立问题不会产生连锁反应的场景;各环节完全独立的松耦合系统。

The English summary is being prepared. Showing the original description.

kangarooking/huangdi-neijing-skill42Updated Apr 18, 2026

用户需要说服不配合的人接受建议时; 当面对"骄恣从欲"的强势对象时; 当需要将复杂建议转化为对方愿意接受的方案时; 当需要在"尊重对方意愿"和"坚持正确方向"之间找平衡时。 不适用于: 纯信息传递不需要说服的场景、对方已完全配合的场景。

The English summary is being prepared. Showing the original description.

kangarooking/huangdi-neijing-skill42Updated Apr 18, 2026

用户需要在新的环境/市场/文化中部署已有方案时;当同一个问题在不同地区/场景下表现不同时; 当需要将通用方案本地化时;当用户说"为什么在这里不管用"或"换个地方方案就失效了"时。 不适用于: 环境因素不重要、问题与场景无关的纯技术/逻辑场景。

The English summary is being prepared. Showing the original description.

kangarooking/huangdi-neijing-skill42Updated Apr 18, 2026

See all skills by kangarooking

Report a problem with this skill