Skill: cizixiu/pangu (version 1.0.2)

--- name: pangu description: | 盘古 · skill - 将知识库/文件夹/单文档蒸馏为专业可安装的Skill。 支持四种蒸馏模式：完整知识库、指定文件夹、单篇文档、任务工作流。 trigger: 蒸馏知识库,知识库转skill,把知识库变成skill,distill kb,kb to skill,知识库蒸馏,开天术,盘古 metadata: clawdbot: tags: [knowledge-distillation, skill-creation, ai-agent, productivity] --- # 盘古 · skill > 「知识库是图书馆，Skill 是专家」——把你的知识库从「被动查询」变成「主动能力」。 > 本 Skill 借鉴了 [女娲 · Skill](https://github.com/alchaincyf/nuwa-skill) 的成熟经验，采用多阶段流程 + 检查点设计 + 质量验证标准，非常感谢。 --- ## 💡 最佳使用场景：IMA Copilot 本技能在 **IMA Copilot** 中使用效果最佳。 **为什么？** IMA 本身就是知识库笔记软件——你在 IMA 中积累的笔记、文档、知识库，正是本技能蒸馏的原料。整个工作流无缝衔接： ``` IMA 知识库（原始积累） ↓ 盘古 蒸馏 可安装的 Skill（结构化能力） ↓ 安装到 IMA Copilot 触发关键词 → 自动执行完整工作流 ``` **在 IMA 中使用本技能的完整流程：** 1. 在 IMA Copilot 中对话，说「盘古」或「蒸馏知识库」 2. 按提示提供知识库名称和需求 3. 本技能自动读取 IMA 知识库内容并蒸馏 4. 生成可安装的 Skill 文件 5. 将 Skill 安装回 IMA，即可重复使用 > 💎 **精髓**：IMA 负责「积累知识」，盘古负责「提炼能力」，形成知识增强闭环。 --- ## 核心理念 | 维度 | 知识库 | Skill | |------|--------|-------| | 使用方式 | 搜索 → 读取 → 理解 | 触发关键词 → 自动执行 | | 知识形态 | 原始文档（散装） | 结构化流程 + 精炼规则 | | 门槛 | 需要知道搜什么、怎么问 | 说一句话就触发完整流程 | | 复用性 | 每次都要搜+读+理解 | 安装即用，开箱即得 | | 分发 | 加入知识库 → 问答 | 安装 Skill → 直接用 | **关键区分**：蒸馏的是**能做到什么**（流程/规则/框架），不是**知道什么**（信息/文档）。 --- ## 执行流程 ### Phase 0: 入口分流 收到用户输入后，先判断蒸馏模式： | 模式 | 触发特征 | 示例 | |------|---------|------| | **完整蒸馏** | 提到知识库名称，未指定范围 | 「把 @XX知识库 蒸馏成 Skill」 | | **文件夹蒸馏** | 指定了文件夹名称 | 「只蒸馏「XX文件夹」里的内容」 | | **单文档蒸馏** | 指定了具体文档 | 「把「XX文档」蒸馏成 Skill」 | | **任务蒸馏** | 提到「刚才的任务」「工作流」 | 「把我刚才做的调研报告流程变成 Skill」 | --- ### Phase1: 需求澄清 根据蒸馏模式，确认关键信息（参见 `references/distillation-best-practices.md` 中的完整模板）。 **检查知识库是否适合蒸馏**： | ✅ 适合蒸馏 | ❌ 不适合蒸馏 | |------------|-------------| | 有明确流程/步骤 | 纯数据型（价格表、产品目录） | | 有规则/规范检查 | 需要频繁更新的实时数据 | | 有分类决策场景 | 纯文献存档（无操作指导） | | 有方法论/框架 | 一次性查阅的参考资料 | | 有固定输出格式 | 需要专业资质的领域（医疗诊断等） | --- ### Phase 1.5: 创建 Skill 目录 **收到确认后立即执行**，在读取内容之前完成： ``` {skill-name}/ ├── SKILL.md # 核心技能文件 ├── references/ # 参考文档（从知识库提炼） │ ├── 01-core-knowledge.md │ ├── 02-checklist.md │ └── 03-cases.md ├── assets/ # 模板文件（从知识库提取） └── examples/ # 使用示例 ``` **关键规则**：所有参考文件必须存在 skill 目录内部，Skill 必须是自包含的。 --- ### Phase 2: 内容读取与分析 读取策略： - **完整蒸馏**：读取知识库所有文件和文件夹结构 - **文件夹蒸馏**：只读取指定文件夹内的文件 - **单文档蒸馏**：只读取指定的单篇文档 - **任务蒸馏**：分析对话历史，提取完整工作流 对读取的内容进行结构化分析（核心知识提炼、流程提取、案例提取、参考文档识别）。 --- ### Phase 2.5: 分析确认检查点 内容读取和分析完成后，暂停展示分析摘要给用户确认，再进入 Phase 3。 --- ### Phase 3: 框架提炼 #### 3.1 核心框架提取（3-7个） 1. **扫描**：列出所有候选知识 2. **筛选**：按重要性排序，取 top 3-7 个 3. **记录格式**：每个框架记录——名称、一句话描述、来源证据、应用方式、局限性 #### 3.2-3.5 提炼内容 - **流程步骤提炼**（如有）：完成某项任务的具体步骤 - **检查清单提炼**（如有）：需要逐项确认的内容 - **决策规则提炼**（如有）：做判断时的快速规则 - **模板提炼**（如有）：需要生成特定格式内容时的模板 #### 3.6 边界规则 必须明确写出的局限：这个 Skill 不能做什么、在什么情况下不适用、需要人工介入的场景。 --- ### Phase 3.5: 提炼确认检查点 Phase 3 提炼完成后，暂停展示提炼摘要给用户确认，再进入 Phase 4。 --- ### Phase 4: Skill 构建 将 Phase 3 提炼结果组装为可运行的 SKILL.md。 **内容映射规则**： | 知识库内容 | 映射为 Skill 中的 | |-----------|------------------| | 零散的规则/规范 | 规范型 Skill 的检查清单 | | 操作步骤文档 | 流程型 Skill 的 Step 步骤 | | 分类知识 | 任务型 Skill 的决策表 | | 长篇参考文档 | references/ 目录下的参考文件 | | 模板/范例 | assets/ 目录下的模板文件 | | 案例/常见问题 | examples/ 目录下的示例文件 | --- ### Phase 5: 质量验证 生成 Skill 后，执行以下质量验证： | 检查项 | 通过标准 | 不通过信号 | |--------|---------|-----------| | 核心框架数量 | 3-7 个，每个有来源证据 | <3 或 >10 | | 每个框架的局限性 | 明确写出失效条件 | 只写优点 | | 流程步骤清晰度 | 用户能按步骤执行 | 步骤模糊或缺失 | | 边界规则完整性 | 至少 2 条具体局限 | 只有「不能替代人工」 | | 示例充分性 | 至少 2 个具体示例 | 没有示例 | | 文档结构完整性 | 所有必要 section 都有 | 有 section 缺失 | **迭代上限**：Phase 3→5 最多循环 2 次。 --- ### Phase 6: 双Agent精炼（可选） Phase 5 验证通过后，可选启动双Agent精炼： - **Agent A（结构视角）**：评审结构清晰度和工作流 - **Agent B（用户视角）**：评审触发关键词和示例 --- ### Phase 7: 输出与注册 将生成的 Skill 文件输出，提供注册指引（IMA 中注册：打包zip → 上传 → 等待审核）。 --- ## 更新已有 Skill 当用户说「更新我的 XX Skill」时： 1. 读取现有的 SKILL.md，标注更新时间 2. 只读取变化的部分 3. 对比新内容与现有内容，增量更新 4. 不重写整个 Skill --- ## 品味守则（速查） | 原则 | 一句话 | |------|--------| | 流程 > 知识 | 能执行的流程比散装知识更有价值 | | 规则 > 案例 | 具体规则比一堆案例更容易泛化 | | 边界 > 能力 | 明确边界比夸大能力更诚实 | | 精炼 > 堆砌 | 3 个核心框架远好于 10 个浅薄原则 | ### 绝不做的事 - 把知识库文档原封不动地复制到 Skill 中 - 蒸馏不适合蒸馏的知识库类型 - 夸大 Skill 的能力 - 在信息不足时强行生成完整的 Skill --- ## 特殊场景 ### 场景1：知识库内容太多（>100 文件或 50000 字） 建议用户指定蒸馏范围，或分批次蒸馏。 ### 场景2：知识库不适合蒸馏 纯数据型、需要频繁更新的实时数据、纯文献存档、需要专业资质的领域 → 建议保留为知识库。 ### 场景3：跨文件夹引用 保留引用关系，使用相对路径引用 references/ 下的文件。 ### 场景4：蒸馏用户自己的知识库 需要用户明确授权和描述核心知识，注意「自我认知偏差」。 ### 场景5：冷门知识库（<10 篇文档） 框架数量减至 2-3 个，边界规则 section 加大篇幅。 --- ## 蒸馏示例 完整示例请参考： - [示例1：完整知识库蒸馏](./examples/example-complete-distillation.md) - [示例2：文件夹蒸馏](./examples/example-folder-distillation.md) - [示例3：单文档蒸馏](./examples/example-single-doc-distillation.md) --- ## 小贴士 | 问题 | 建议 | |------|------| | 不知道技能名称怎么起？ | 不填，让 AI 自动生成（英文 kebab-case 格式） | | 不知道触发关键词怎么写？ | 不填，AI 会根据知识库内容自动推断 | | 知识库内容太多？ | 在"重点提炼"中说明哪些必须包含 | | 只想蒸馏部分内容？ | 加一行「蒸馏范围：只提炼「XX」文件夹」 | | 想修改已蒸馏的 Skill？ | 说"更新我的 XX 技能" | | 想分享给别人？ | 告诉 AI "我需要下载 zip 包" | --- ## 注意事项 1. **知识库必须可访问** — 使用 `@知识库名称` 引用 2. **不是所有知识库都适合蒸馏** — 纯数据型知识库效果差 3. **蒸馏后知识库仍保留** — Skill 是知识库的精炼版 4. **需要审核** — 注册后需等平台审核通过才可使用 5. **新对话生效** — 审核通过后，在新的对话中才能触发 6. **内容版权** — 确保你有权蒸馏该知识库的内容 --- ## 最后 这个 Skill 的目标是：让你知识库中的知识，从「被动等待查询」变成「主动帮你工作」。 一个好的蒸馏 Skill，应该让用户在安装后，只需要说一句话，就能触发完整的工作流——就像有一个专家在旁边指导一样。 **蒸馏的是能做到什么（流程/规则/框架），不是知道什么（信息/文档）。** > 本 Skill 由 [盘古 · skill](https://github.com/cizixiu/pangu) 生成

path: examples/example-complete-distillation.md
content: # 示例：完整知识库蒸馏

## 用户输入

```
请把我的知识库蒸馏成一个可安装的 Skill。

【基本信息】
知识库：@合同审查知识库
这个知识库主要解决什么问题：帮助法务人员审查合同中的风险条款
希望别人安装这个 Skill 后能做什么：上传合同后自动审查风险并生成审查报告

【技能定制】
技能名称：contract-review
触发关键词：审合同、合同审查、合同风险、协议审查、检查合同
不适用场景：合同起草、合同翻译、法律咨询

【内容范围】
重点提炼：风险条款识别规则必须包含，法律条文原文可以精简
编程规范/易错点：有，合同审查的四层检查流程和风险等级标准
参考文档：需要保留，风险条款对照表和审查清单

【交付要求】
是否需要下载 zip 包：是
```

## 知识库内容（模拟）

合同审查知识库包含：
- 📁 审查流程（文件夹）
  - 审查准备工作.md
  - 四层检查法.md
  - 审查报告撰写指南.md
- 📁 风险条款库（文件夹）
  - 违约责任条款.md
  - 知识产权条款.md
  - 争议解决条款.md
  - 保密条款.md
- 📁 审查清单（文件夹）
  - 通用审查清单.md
  - 采购合同审查清单.md
  - 服务合同审查清单.md
- 📁 案例库（文件夹）
  - 案例1：某互联网公司保密协议纠纷.md
  - 案例2：某制造企业采购合同纠纷.md
- 📄 合同审查规范.pdf

## 蒸馏输出

### 目录结构

```
contract-review/
├── SKILL.md                ← 核心技能文件
├── references/
│   ├── risk-checklist.md   ← 详细风险检查清单（从知识库提炼）
│   ├── four-layer-method.md ← 四层检查法详细说明
│   └── case-studies.md    ← 典型案例分析（从知识库提炼）
├── assets/
│   └── review-report-template.md ← 审查报告模板
└── examples/
    └── example-review.md  ← 审查示例
```

### SKILL.md 内容

```markdown
---
name: contract-review
description: 合同审查专家 - 自动识别合同风险条款并生成审查报告。触发词：审合同、合同审查、合同风险、协议审查、检查合同
trigger: 审合同,合同审查,合同风险,协议审查,检查合同
---

# 合同审查专家

> 上传合同文档，自动识别风险条款，生成专业审查报告。

---

## 不适用场景

- ❌ 合同起草（本 Skill 只做审查，不做起草）
- ❌ 合同翻译（本 Skill 只做中文合同审查）
- ❌ 法律咨询（本 Skill 只做合同条款审查）

---

## 执行流程

### Step 1: 接收合同

用户上传合同文档（PDF/Word/图片）后：

1. 确认合同类型（采购/服务/保密/其他）
2. 确认审查重点（全套审查/重点审查）

**决策表**：

| 用户说 | 行动 |
|--------|------|
| 「帮我审这份合同」 | 全套四层审查 |
| 「重点看下违约责任」 | 重点审查 + 其他简要检查 |
| 「这是采购合同」 | 使用采购合同审查清单 |

### Step 2: 四层检查法

按照以下四层顺序审查：

#### 第一层：形式审查

检查合同条款是否完整：

- [ ] 合同主体信息完整
- [ ] 合同标的明确
- [ ] 履行期限清晰
- [ ] 签字盖章页完整

**输出**：形式审查结果（通过/不通过 + 具体缺失项）

#### 第二层：风险条款识别

对照风险条款库，识别高风险条款：

| 风险类型 | 检查要点 | 风险等级 |
|---------|---------|---------|
| 违约责任 | 责任是否对等 | 🔴 高 |
| 知识产权 | 归属是否明确 | 🟡 中 |
| 争议解决 | 管辖法院是否合理 | 🟡 中 |
| 保密义务 | 期限是否过长 | 🟢 低 |

**输出**：风险条款清单 + 风险等级

#### 第三层：利益平衡分析

检查合同是否利益失衡：

- 单方权利过大？
- 单方义务过重？
- 免责条款过于宽泛？

**输出**：利益平衡分析报告

#### 第四层：可执行性检查

检查合同条款是否可执行：

- 履行标准是否量化？
- 违约责任是否可操作？
- 争议解决成本是否过高？

**输出**：可执行性评估报告

### Step 3: 生成审查报告

使用 `assets/review-report-template.md` 模板生成报告。

报告包含：
1. 合同基本信息
2. 形式审查结果
3. 风险条款清单（按风险等级排序）
4. 修改建议（逐条对应）
5. 总体评估（通过/有条件通过/不通过）

---

## 风险等级标准

| 等级 | 标识 | 定义 | 处理方式 |
|------|------|------|---------|
| 高风险 | 🔴 | 可能导致重大损失或法律纠纷 | 必须修改 |
| 中风险 | 🟡 | 可能影响合同履行或产生争议 | 建议修改 |
| 低风险 | 🟢 | 对合同履行影响较小 | 可选修改 |

---

## 常见风险条款对照

> 完整对照表见 `references/risk-checklist.md`

| 条款类型 | 风险特征 | 修改建议 |
|---------|---------|---------|
| 违约责任 | "甲方有权随时终止，无需理由" | 增加"提前30天通知"和"正当理由"限制 |
| 知识产权 | "乙方在履行合同过程中创造的所有知识产权归甲方" | 限定为"与本合同标的直接相关的"知识产权 |

---

## 参考文档

- [风险检查清单](./references/risk-checklist.md) - 完整的风险条款检查清单
- [四层检查法详解](./references/four-layer-method.md) - 四层检查法的详细说明
- [典型案例分析](./references/case-studies.md) - 真实合同纠纷案例分析

---

## 审查示例

> 见 `examples/example-review.md`

---

## 注意事项

1. **本 Skill 只做审查，不做法律意见** - 审查结果仅供参考，不构成法律意见
2. **特殊行业合同需谨慎** - 金融、医疗等特殊行业合同建议由专业律师审查
3. **合同金额超过阈值需升级** - 合同金额 >100万 时，建议提示用户"建议由法务总监复核"
4. **保留修改记录** - 审查报告生成后，建议用户保留修改前后的合同版本对比
```

### references/risk-checklist.md（节选）

```markdown
# 合同风险条款检查清单

## 通用检查清单

### 合同主体
- [ ] 名称与公章一致
- [ ] 地址、联系人、联系方式完整
- [ ] 法定代表人或授权代表签字完整

### 合同标的
- [ ] 标的名称、规格、型号明确
- [ ] 数量、质量标准明确
- [ ] 交付/履行地点、时间明确

### 对价条款
- [ ] 金额/报酬明确
- [ ] 支付方式、时间明确
- [ ] 发票类型、税率明确

### 违约责任
- [ ] 违约情形定义清晰
- [ ] 违约责任对等（双方义务相当）
- [ ] 违约金计算方式明确、合理

### 争议解决
- [ ] 管辖法院/仲裁机构明确
- [ ] 管辖地对公司有利（如约定在公司所在地）

### 知识产权
- [ ] 知识产权归属明确
- [ ] 使用许可范围明确
- [ ] 侵权责任承担明确

### 保密义务
- [ ] 保密信息定义明确
- [ ] 保密期限合理（一般不超过合同结束后2年）
- [ ] 违约责任明确

## 高风险条款特征

| 条款 | 高风险特征 | 建议修改 |
|------|-----------|---------|
| 违约责任 | 单方违约责任过重 | 调整为双方对等 |
| 解除条款 | 单方有权随时解除 | 增加提前通知期限和正当理由要求 |
| 免责条款 | 免责范围过于宽泛 | 限定为"不可抗力"等法定免责情形 |
| 知识产权 | 乙方所有知识产权归甲方 | 限定为"与本合同标的直接相关的" |
| 保密义务 | 永久保密义务 | 调整为"合同结束后2年内" |
```

### assets/review-report-template.md

```markdown
# 合同审查报告

**审查日期**：{日期}
**审查人**：{审查人}
**合同名称**：{合同名称}
**合同类型**：{采购/服务/保密/其他}
**合同金额**：{金额}

---

## 一、形式审查结果

| 检查项 | 结果 |
|--------|------|
| 合同主体信息完整 | ✅/❌ |
| 合同标的明确 | ✅/❌ |
| 履行期限清晰 | ✅/❌ |
| 签字盖章页完整 | ✅/❌ |

**形式审查结论**：通过/不通过

---

## 二、风险条款清单

### 🔴 高风险条款

| 条款位置 | 风险描述 | 修改建议 |
|---------|---------|---------|
| 第X条 | ... | ... |

### 🟡 中风险条款

| 条款位置 | 风险描述 | 修改建议 |
|---------|---------|---------|
| 第X条 | ... | ... |

### 🟢 低风险条款

| 条款位置 | 风险描述 | 修改建议 |
|---------|---------|---------|
| 第X条 | ... | ... |

---

## 三、修改建议汇总

1. **必须修改**（🔴 高风险）
   - 修改第X条：...
   - 修改第Y条：...

2. **建议修改**（🟡 中风险）
   - 修改第X条：...
   - 修改第Y条：...

3. **可选修改**（🟢 低风险）
   - 修改第X条：...

---

## 四、总体评估

**结论**：✅ 通过 / ⚠️ 有条件通过 / ❌ 不通过

**说明**：
{总体评估说明}

---

## 五、附件

- 合同原文（标注版）
- 风险条款对照表
```

---

## 质量检查

### ✅ 完整性检查

- [x] SKILL.md 包含完整的 frontmatter
- [x] SKILL.md 包含适用场景说明
- [x] SKILL.md 包含执行流程（四层检查法）
- [x] 参考文档已放入 references/ 目录
- [x] 模板文件已放入 assets/ 目录
- [x] 示例已放入 examples/ 目录

### ✅ 可用性检查

- [x] 触发关键词能准确触发（审合同、合同审查等）
- [x] 执行流程清晰可执行（四层检查法，每层有输出）
- [x] 没有模糊或矛盾的表述
- [x] 包含了所有关键知识（风险条款识别、四层检查法、报告生成）

### ✅ 蒸馏质量检查

- [x] 没有过度蒸馏（保留了风险检查清单、四层检查法详解等重要参考）
- [x] 没有蒸馏不足（法律条文原文等已精简）
- [x] 结构清晰（用户能快速找到需要的信息）
- [x] 示例充分（有完整示例和风险提示）
 ```


path: examples/example-folder-distillation.md
content: # 示例：文件夹蒸馏

## 用户输入

```
请把我的知识库蒸馏成一个可安装的 Skill。

知识库：@wolai公式助手
蒸馏范围：只提炼「日期函数」和「逻辑函数」文件夹里的内容
这个知识库主要解决什么问题：帮助wolai用户编写日期和条件类公式
希望别人安装这个 Skill 后能做什么：快速查询和编写wolai日期公式与条件公式
```

## 知识库内容（模拟）

wolai公式助手知识库包含：
- 📁 基础函数（文件夹）- ❌ 不蒸馏
  - 数学函数.md
  - 文本函数.md
- 📁 日期函数（文件夹）- ✅ 蒸馏
  - now().md
  - today().md
  - date().md
  - datedif().md
- 📁 逻辑函数（文件夹）- ✅ 蒸馏
  - if().md
  - and().md
  - or().md
  - not().md
- 📁 查找函数（文件夹）- ❌ 不蒸馏
  - vlookup().md
  - index().md

## 蒸馏输出

### 目录结构

```
wolai-formula-helper/
├── SKILL.md                ← 核心技能文件
└── references/
    ├── date-functions.md   ← 日期函数详细说明
    └── logic-functions.md  ← 逻辑函数详细说明
```

### SKILL.md 内容

```markdown
---
name: wolai-formula-helper
description: wolai 日期与逻辑公式助手 - 帮助快速查询和编写日期函数、逻辑函数。触发词：wolai公式、日期公式、逻辑公式、if函数、datedif
trigger: wolai公式,日期公式,逻辑公式,if函数,datedif,日期函数,逻辑函数
---

# wolai 日期与逻辑公式助手

> 快速查询 wolai 数据表格中的日期函数和逻辑函数用法，附带示例和常见错误。

---

## 不适用场景

- ❌ 数学函数查询（请使用数学函数助手）
- ❌ 查找函数查询（请使用查找函数助手）
- ❌ 文本函数查询（请使用文本函数助手）

---

## 执行流程

### Step 1: 识别用户需求

| 用户说 | 行动 |
|--------|------|
| 「怎么计算两个日期之差」 | 查询 datedif() 函数 |
| 「如果...就...怎么写」 | 查询 if() 函数 |
| 「多个条件同时满足」 | 查询 and() 函数 |
| 「任意条件满足」 | 查询 or() 函数 |
| 「今天日期」 | 查询 today() 函数 |

### Step 2: 提供函数说明

提供以下内容：
1. 函数语法
2. 参数说明
3. 使用示例
4. 常见错误

### Step 3: 提供相关函数

如果是日期函数，提供相关日期函数；如果是逻辑函数，提供相关逻辑函数。

---

## 日期函数速查

> 完整说明见 `references/date-functions.md`

| 函数 | 说明 | 示例 |
|------|------|------|
| `now()` | 返回当前日期和时间 | `now()` → `2024-01-15 10:30:00` |
| `today()` | 返回当前日期 | `today()` → `2024-01-15` |
| `date(年,月,日)` | 构造日期 | `date(2024,1,15)` → `2024-01-15` |
| `datedif(开始,结束,单位)` | 计算日期差 | `datedif([开始日期],[结束日期],"D")` → `天数` |

---

## 逻辑函数速查

> 完整说明见 `references/logic-functions.md`

| 函数 | 说明 | 示例 |
|------|------|------|
| `if(条件,真值,假值)` | 条件判断 | `if([金额]>1000,"大额","小额")` |
| `and(条件1,条件2,...)` | 多条件同时满足 | `and([金额]>1000,[状态]="已审批")` |
| `or(条件1,条件2,...)` | 任意条件满足 | `or([状态]="紧急",[金额]>5000)` |
| `not(条件)` | 条件取反 | `not([状态]="已完成")` |

---

## 组合示例

### 示例1：计算合同剩余天数并标注状态

```
if(
  datedif(today(),[结束日期],"D")>30,
  "充足",
  if(
    datedif(today(),[结束日期],"D")>0,
    "紧张",
    "已过期"
  )
)
```

### 示例2：多条件审批判断

```
if(
  and([金额]<=1000,[类型]="日常"),
  "自动通过",
  if(
    and([金额]<=5000,[类型]="日常"),
    "部门审批",
    "高管审批"
  )
)
```

---

## 常见错误

### 错误1：datedif 单位写错

❌ 错误：`datedif([开始],[结束],"天")`
✅ 正确：`datedif([开始],[结束],"D")`

| 单位 | 正确写法 |
|------|---------|
| 天 | `"D"` |
| 月 | `"M"` |
| 年 | `"Y"` |

### 错误2：if 函数缺少参数

❌ 错误：`if([金额]>1000,"大额")` （缺少第三个参数）
✅ 正确：`if([金额]>1000,"大额","小额")`

### 错误3：文本比较忘记加引号

❌ 错误：`if([状态]=已完成,...)`
✅ 正确：`if([状态]="已完成",...)`

---

## 参考文档

- [日期函数详细说明](./references/date-functions.md) - 所有日期函数的完整说明
- [逻辑函数详细说明](./references/logic-functions.md) - 所有逻辑函数的完整说明

---

## 注意事项

1. **日期格式** - wolai 中的日期格式为 `YYYY-MM-DD`
2. **文本字段引用** - 引用文本字段用 `[字段名]`，文本常量用 `"文本"`
3. **空值处理** - 如果字段可能为空，用 `if([字段]="",...)` 先判断
```

### references/date-functions.md（节选）

```markdown
# 日期函数详细说明

## now()

返回当前日期和时间。

**语法**：`now()`

**返回值**：日期时间类型，格式 `YYYY-MM-DD HH:MM:SS`

**示例**：
- `now()` → `2024-01-15 10:30:00`
- `year(now())` → `2024`
- `month(now())` → `1`

**常见用途**：
- 记录创建时间：`if([创建时间]="",now(),[创建时间])`
- 计算年龄：`year(now())-year([出生日期])`

---

## today()

返回当前日期（不含时间）。

**语法**：`today()`

**返回值**：日期类型，格式 `YYYY-MM-DD`

**示例**：
- `today()` → `2024-01-15`
- `day(today())` → `15`

**常见用途**：
- 判断任务是否逾期：`if([截止日期]<today(),"逾期","正常")`

---

## date(年,月,日)

构造一个日期。

**语法**：`date(年,月,日)`

**参数**：
- 年：四位年份，如 `2024`
- 月：1-12
- 日：1-31（需符合该月实际天数）

**示例**：
- `date(2024,1,15)` → `2024-01-15`
- `date(year(today()),month(today()),1)` → 本月第一天

---

## datedif(开始日期,结束日期,单位)

计算两个日期之间的差值。

**语法**：`datedif(开始日期,结束日期,单位)`

**参数**：
- 开始日期：日期类型
- 结束日期：日期类型
- 单位：`"Y"`(年)、`"M"`(月)、`"D"`(天)

**示例**：
- `datedif([入职日期],today(),"Y")` → 工作年限
- `datedif([开始日期],[结束日期],"D")` → 项目天数

**注意事项**：
- 结束日期必须晚于开始日期，否则返回错误
- 单位必须用双引号包裹
```


path: examples/example-single-doc-distillation.md
content: # 示例：单文档蒸馏

## 用户输入

```
请把我的知识库蒸馏成一个可安装的 Skill。

知识库：@我的知识库
蒸馏范围：只提炼「项目启动检查清单」文档
这个文档主要解决什么问题：确保项目启动时所有必要步骤都已完成
希望别人安装这个 Skill 后能做什么：生成项目启动检查清单并逐项确认
```

## 知识库内容（模拟）

「项目启动检查清单」文档包含：

```
# 项目启动检查清单

## 一、项目立项确认

- [ ] 项目章程已审批
- [ ] 项目目标明确且文档化
- [ ] 项目范围已定义
- [ ] 里程碑计划已制定

## 二、团队组建

- [ ] 项目经理已指定
- [ ] 核心团队成员已确认
- [ ] 团队沟通机制已建立
- [ ] 团队成员角色职责已明确

## 三、资源准备

- [ ] 预算已审批
- [ ] 所需设备/工具已申请
- [ ] 办公空间/会议室已安排
- [ ] 外部供应商已确定（如有）

## 四、干系人管理

- [ ] 关键干系人已识别
- [ ] 干系人沟通计划已制定
- [ ] 干系人期望已管理

## 五、风险管理

- [ ] 初步风险识别已完成
- [ ] 高优先级风险已制定应对策略
- [ ] 风险登记册已创建

## 六、流程规范

- [ ] 项目管理流程已宣贯
- [ ] 质量标准已定义
- [ ] 变更管理流程已说明
```

## 蒸馏输出

### 目录结构

```
project-launch-checker/
├── SKILL.md                      ← 核心技能文件
├── assets/
│   └── checklist-template.md     ← 检查清单模板
└── examples/
    └── example-checklist.md     ← 使用示例
```

### SKILL.md 内容

```markdown
---
name: project-launch-checker
description: 项目启动检查专家 - 确保项目启动时所有必要步骤都已完成。触发词：项目启动、项目检查、启动检查、项目清单
trigger: 项目启动,项目检查,启动检查,项目清单
---

# 项目启动检查专家

> 确保项目启动时所有必要步骤都已完成，避免项目执行中的常见问题。

---

## 适用场景

- ✅ 新项目启动前的最终确认
- ✅ 项目交接时的完整性检查
- ✅ 项目启动会议前的准备检查
- ❌ 项目执行中的进度检查（请用「项目进度检查」）
- ❌ 项目收尾检查（请用「项目收尾检查」）

---

## 执行流程

### Step 1: 确认项目基本信息

在开始检查前，确认：

1. 项目类型（研发/市场/运营/其他）
2. 项目规模（小/中/大）
3. 关键里程碑日期

**决策规则**：

| 项目规模 | 需要的检查项数量 | 特别注意 |
|---------|----------------|---------|
| 小型项目 | 基础检查项 | 可适当简化 |
| 中型项目 | 全部基础 + 部分增强 | 风险管理必须完整 |
| 大型项目 | 全部检查项 | 干系人管理要详细 |

### Step 2: 生成检查清单

根据项目基本信息，生成对应的检查清单。

### Step 3: 逐项确认

引导用户逐项确认检查清单，每项给出：
- 检查结果（✅/❌/⚠️）
- 如果不通过，需要采取的行动

### Step 4: 生成启动报告

汇总检查结果，生成启动报告，包含：
- 检查摘要
- 通过项和未通过项
- 待跟进事项
- 建议的启动时间

---

## 核心框架

### 四步启动法

**一句话描述**：项目启动分为「立项确认→团队组建→资源准备→风险管理」四步。

**来源证据**：
- PMBOK 项目启动过程组
- 公司项目管理规范第 3.1 节

**应用方式**：按照四步顺序逐项检查，确保每步都有明确的产出物。

**局限性**：
- 不同行业的具体检查项可能有所不同
- 紧急项目可能需要简化流程

### 干系人优先矩阵

**一句话描述**：根据干系人的「权力」和「利益」两个维度，将干系人分为四类，分别采取不同策略。

**来源证据**：
- PMBOK 干系人管理

**应用方式**：
| 干系人类型 | 权力 | 利益 | 策略 |
|-----------|------|------|------|
| 重点管理 | 高 | 高 | 密切合作 |
| 令其满意 | 高 | 低 | 及时汇报 |
| 随时告知 | 低 | 高 | 及时通报 |
| 监督 | 低 | 低 | 保持关注 |

**局限性**：
- 权力和利益可能随项目进展变化
- 复杂干系人可能同时属于多个类型

---

## 检查清单模板

> 完整模板见 `assets/checklist-template.md`

### 基础检查项（所有项目必须）

| 类别 | 检查项 | 通过标准 |
|------|--------|---------|
| 立项确认 | 项目章程已审批 | 有签批记录 |
| 立项确认 | 项目目标明确 | 目标文档化且 SMART |
| 立项确认 | 项目范围已定义 | 范围说明书已创建 |
| 团队组建 | 项目经理已指定 | 有正式任命 |
| 团队组建 | 核心成员已确认 | 成员时间已锁定 |
| 资源准备 | 预算已审批 | 预算文档化 |
| 风险管理 | 初步风险识别 | 至少识别 5 个风险 |

### 增强检查项（中型及以上项目）

| 类别 | 检查项 | 通过标准 |
|------|--------|---------|
| 团队组建 | 沟通机制已建立 | 会议节奏已确定 |
| 团队组建 | 角色职责已明确 | RACI 矩阵已创建 |
| 干系人 | 干系人识别完整 | 权力/利益矩阵已绘制 |
| 干系人 | 沟通计划已制定 | 计划文档化 |
| 风险管理 | 高优先级风险有应对 | 应对策略已记录 |

### 完整检查项（大型项目）

在增强检查项基础上，增加：
- 供应商管理检查
- 合规性检查
- 质量标准检查
- 变更管理流程检查

---

## 决策规则

| 场景 | 规则 |
|------|------|
| 检查项不通过但项目必须启动 | 记录风险，获得项目发起人批准后可启动 |
| 关键检查项不通过 | 必须修复后才能启动 |
| 检查项通过但有改进空间 | 记录为「建议项」，可在项目执行中改进 |

---

## 示例

### 示例1：小型项目启动检查

**输入**：「检查一个新网站开发项目的启动准备」

**输出**：
```
┌─────────────────────────────────────────────────────┐
│ 项目启动检查报告                                      │
├─────────────────────────────────────────────────────┤
│ 项目名称：新网站开发                                  │
│ 项目类型：研发                                        │
│ 项目规模：小型                                        │
├─────────────────────────────────────────────────────┤
│ 检查结果：7/7 通过                                   │
├─────────────────────────────────────────────────────┤
│ ✅ 项目章程已审批                                    │
│ ✅ 项目目标明确：3个月内上线新网站                    │
│ ✅ 项目范围已定义：官网 + 博客                       │
│ ✅ 项目经理已指定：张三                              │
│ ✅ 核心成员已确认：设计1人 + 开发2人                │
│ ✅ 预算已审批：10万                                  │
│ ✅ 初步风险识别：技术风险、资源风险                   │
├─────────────────────────────────────────────────────┤
│ 建议：可按计划启动                                    │
│ 启动建议时间：明天上午                               │
└─────────────────────────────────────────────────────┘
```

### 示例2：发现问题时的处理

**输入**：「检查一个新功能开发项目的启动准备，有两个成员还没确认」

**输出**：
```
┌─────────────────────────────────────────────────────┐
│ 项目启动检查报告                                      │
├─────────────────────────────────────────────────────┤
│ 检查结果：6/7 通过，1 项待确认                       │
├─────────────────────────────────────────────────────┤
│ ❌ 核心成员已确认（部分不通过）                      │
│    问题：后端开发李四时间冲突，可能延后到下月        │
│    建议：1) 协调李四时间 2) 寻找替代人选            │
│    影响：若2周内无法确认，项目里程碑需调整            │
├─────────────────────────────────────────────────────┤
│ 决策建议：                                          │
│ - 如果新功能必须在2周内上线 → 立即启动人员协调      │
│ - 如果可以延后 → 可先启动，其他准备工作继续         │
└─────────────────────────────────────────────────────┘
```

---

## 边界规则

### 这个 Skill 不能做什么

- ❌ 代替人工做决策（最终决策由项目经理/发起人做出）
- ❌ 预测项目能否成功（只检查启动准备，不预测结果）
- ❌ 替代正式的项目审批流程

### 何时需要人工介入

- ⚠️ 检查发现关键项不通过
- ⚠️ 团队成员冲突需要调解
- ⚠️ 预算超支需要发起人审批

---

## 注意事项

1. **这只是检查，不是审批** - 检查通过不代表项目可以启动，还需要正式审批
2. **规模不同要求不同** - 小项目可以简化，但关键检查项不能跳过
3. **记录很重要** - 即使是紧急项目，也要记录检查结果和风险
4. **持续更新** - 项目启动后，检查清单应根据实际情况调整

---

> 本 Skill 由 IMA 知识库蒸馏专家 生成
> 更新时间：{日期}
```

### assets/checklist-template.md

```markdown
# 项目启动检查清单

## 使用说明

本模板用于项目启动前的完整性检查。根据项目规模选择对应检查项。

---

## 基础检查项

### 1. 立项确认

- [ ] **项目章程已审批**
  - 通过标准：有签批记录
  - 所需文档：项目章程

- [ ] **项目目标明确且文档化**
  - 通过标准：目标符合 SMART 原则
  - 所需文档：项目目标说明书

- [ ] **项目范围已定义**
  - 通过标准：范围说明书已创建
  - 所需文档：项目范围说明书

- [ ] **里程碑计划已制定**
  - 通过标准：主要里程碑已确定
  - 所需文档：里程碑计划

### 2. 团队组建

- [ ] **项目经理已指定**
  - 通过标准：有正式任命
  - 所需文档：项目经理任命书

- [ ] **核心团队成员已确认**
  - 通过标准：成员时间已锁定
  - 所需文档：团队成员名单

### 3. 资源准备

- [ ] **预算已审批**
  - 通过标准：预算文档化并审批
  - 所需文档：项目预算

### 4. 风险管理

- [ ] **初步风险识别已完成**
  - 通过标准：至少识别 5 个风险
  - 所需文档：风险登记册（初稿）

---

## 增强检查项（中型及以上项目）

### 团队组建

- [ ] **团队沟通机制已建立**
  - 通过标准：会议节奏已确定（周会/日会等）
  - 所需文档：沟通管理计划

- [ ] **团队成员角色职责已明确**
  - 通过标准：RACI 矩阵已创建
  - 所需文档：RACI 矩阵

### 干系人管理

- [ ] **关键干系人已识别**
  - 通过标准：权力/利益矩阵已绘制
  - 所需文档：干系人登记册

- [ ] **干系人沟通计划已制定**
  - 通过标准：计划文档化
  - 所需文档：沟通管理计划

### 风险管理

- [ ] **高优先级风险已制定应对策略**
  - 通过标准：Top 5 风险有应对策略
  - 所需文档：风险登记册（含应对策略）

---

## 完整检查项（大型项目）

在增强检查项基础上，增加以下检查项：

### 团队组建
- [ ] 外包/供应商团队已确定
- [ ] 团队培训计划已制定

### 资源准备
- [ ] 所需设备/工具已申请
- [ ] 办公空间/会议室已安排
- [ ] 外部供应商已确定（如有）

### 干系人管理
- [ ] 干系人参与计划已制定
- [ ] 干系人期望已管理（已沟通）

### 风险管理
- [ ] 风险阈值已定义
- [ ] 风险监控机制已建立

### 流程规范
- [ ] 项目管理流程已宣贯
- [ ] 质量标准已定义
- [ ] 变更管理流程已说明
- [ ] 验收标准已明确

### 合规性
- [ ] 安全合规检查（如适用）
- [ ] 隐私合规检查（如适用）
- [ ] 行业特定合规检查（如适用）
```

---

## 质量检查

### ✅ 完整性检查

- [x] SKILL.md 包含完整的 frontmatter
- [x] SKILL.md 包含适用/不适用场景说明
- [x] SKILL.md 包含执行流程
- [x] 核心框架有来源证据和应用方式
- [x] 边界规则明确写出局限
- [x] 检查清单模板已放入 assets/ 目录

### ✅ 可用性检查

- [x] 触发关键词能准确触发
- [x] 执行流程清晰可执行
- [x] 没有模糊或矛盾的表述
- [x] 示例充分帮助理解

### ✅ 蒸馏质量检查

- [x] 没有过度蒸馏（保留了完整的检查清单模板）
- [x] 没有蒸馏不足（原始检查清单已结构化）
- [x] 结构清晰（按项目规模分层）
- [x] 示例充分（有正常通过和问题场景两个示例）
```


path: README.md
content: # 盘古 · skill

> 「知识库是图书馆，Skill 是专家」——把你的知识库从「被动查询」变成「主动能力」。

[![ClawbHub](https://img.shields.io/badge/ClawbHub-发布技能-blue?style=flat&logo=github)](https://clawhub.ai/publish-skill)
![Version](https://img.shields.io/badge/version-1.0.1-green)
![License](https://img.shields.io/badge/license-MIT-lightgrey)

---

## 📖 是什么

**盘古·skill**是一个 AI Agent Skill，能够将 IMA 知识库（或任何文档集合）蒸馏为专业、可安装的 Skill 文件。

| 对比维度 | 知识库 | 蒸馏后的 Skill |
|---------|--------|---------------|
| 使用方式 | 搜索 → 读取 → 理解 | 触发关键词 → 自动执行 |
| 知识形态 | 原始文档（散装） | 结构化流程 + 精炼规则 |
| 门槛 | 需要知道搜什么、怎么问 | 说一句话就触发完整流程 |
| 复用性 | 每次都要搜+读+理解 | 安装即用，开箱即得 |

---

## ✨ 功能特性

支持 **四种蒸馏模式**：

| 模式 | 说明 | 触发示例 |
|------|------|----------|
| 🗂️ 完整蒸馏 | 蒸馏整个知识库 | 「把 @XX知识库 蒸馏成 Skill」 |
| 📁 文件夹蒸馏 | 只蒸馏指定文件夹 | 「只蒸馏『XX文件夹』里的内容」 |
| 📄 单文档蒸馏 | 只蒸馏单篇文档 | 「把『XX文档』蒸馏成 Skill」 |
| 🔁 任务蒸馏 | 把工作流变成 Skill | 「把我刚才做的调研流程变成 Skill」 |

---

## 💡 最佳使用场景：IMA Copilot

本技能在 **IMA Copilot** 中使用效果最佳。

**为什么？** IMA 本身就是知识库笔记软件——你在 IMA 中积累的笔记、文档、知识库，正是本技能蒸馏的原料。整个工作流无缝衔接：

```
IMA 知识库（原始积累）
    ↓ 盘古·skill 蒸馏
可安装的 Skill（结构化能力）
    ↓ 安装到 IMA Copilot
触发关键词 → 自动执行完整工作流
```

**在 IMA 中使用本技能的完整流程：**
1. 在 IMA Copilot 中对话，说「盘古」或「蒸馏知识库」
2. 按提示提供知识库名称和需求
3. 本技能自动读取 IMA 知识库内容并蒸馏
4. 生成可安装的 Skill 文件
5. 将 Skill 安装回 IMA，即可重复使用

> 💎 **精髓**：IMA 负责「积累知识」，盘古负责「提炼能力」，形成知识增强闭环。

---

## 🚀 如何使用

### 安装到 IMA Copilot 、WorkBuddy、OpenClaw

1. 下载本 Skill 文件夹
2. 通过IMA Copilot的技能安装界面，WorkBuddy则放入 `~/.workbuddy/skills/` 目录
3. 重启会话，说「盘古」或「蒸馏知识库」即可触发

### 最快上手

```
请把我的知识库蒸馏成一个可安装的 Skill。

知识库：@合同审查知识库
这个知识库主要解决什么问题：帮助审查合同中的风险条款
希望别人安装这个 Skill 后能做什么：上传合同后自动审查风险并生成报告
```

---

## 📂 目录结构

```
pangu/
├── SKILL.md                          # 核心技能文件（必需）
├── references/                       # 参考文档（蒸馏最佳实践）
│   └── distillation-best-practices.md
├── examples/                         # 使用示例
│   ├── example-complete-distillation.md
│   ├── example-folder-distillation.md
│   └── example-single-doc-distillation.md
└── README.md                         # 本文件
```

---

## 🔄 蒸馏流程（7 Phase）

```
Phase 0: 入口分流        → 判断蒸馏模式
Phase 1: 需求澄清        → 确认基本信息和适用性
Phase 1.5: 创建目录      → 建立 Skill 目录结构
Phase 2: 内容读取与分析  → 读取知识库并结构化分析
Phase 2.5: 分析确认      → 检查点，用户确认分析结果
Phase 3: 框架提炼        → 提取核心框架/流程/规则
Phase 3.5: 提炼确认      → 检查点，用户确认提炼结果
Phase 4: Skill 构建       → 组装 SKILL.md
Phase 5: 质量验证        → 6项通过标准验证
Phase 6: 双Agent精炼     → 可选，结构+用户双视角评审
Phase 7: 输出与注册      → 输出文件，提供注册指引
```

---

## 💡 什么时候适合蒸馏？

### ✅ 适合蒸馏的知识库

- 有明确流程/步骤（如：审查流程、部署流程）
- 有规则/规范检查（如：代码规范、设计检查清单）
- 有分类决策场景（如：选型决策、风险评估）
- 有方法论/框架（如：思维框架、分析方法）
- 有固定输出格式（如：报告模板、文档格式）

### ❌ 不适合蒸馏的知识库

- 纯数据型（价格表、产品目录）→ 建议用知识库搜索
- 需要频繁更新的实时数据 → 建议用知识库+定期更新
- 纯文献存档（无操作指导）→ 建议保留为知识库
- 需要专业资质的领域 → 建议保留为参考，人工决策

---

## 📋 质量验证标准

生成的 Skill 必须通过以下 6 项检查：

| 检查项 | 通过标准 |
|--------|---------|
| 核心框架数量 | 3-7 个，每个有来源证据 |
| 每个框架的局限性 | 明确写出失效条件 |
| 流程步骤清晰度 | 用户能按步骤执行 |
| 边界规则完整性 | 至少 2 条具体局限 |
| 示例充分性 | 至少 2 个具体示例 |
| 文档结构完整性 | 所有必要 section 都有 |

---

## 🎯 设计理念

> **蒸馏的是「能做到什么」（流程/规则/框架），不是「知道什么」（信息/文档）。

- **流程 > 知识**：能执行的流程比散装知识更有价值
- **规则 > 案例**：具体规则比一堆案例更容易泛化
- **边界 > 能力**：明确边界比夸大能力更诚实
- **精炼 > 堆砌**：3 个核心框架远好于 10 个浅薄原则

---

## 🔗 相关项目

- [女娲·造人术 (nuwa-skill)](https://github.com/alchaincyf/nuwa-skill) — 蒸馏思维方式，造可对话的专家 Skill
- [OpenClaw](https://openclaw.ai) — AI Agent 平台
- [ClawbHub](https://clawhub.ai) — AI Agent 技能/插件社区

---

## 📜 更新日志

### v1.0.0 (2026-05-03)

- ✨ 初始版本，支持四种蒸馏模式
- ✨ 借鉴女娲 Skill 的成熟经验（多阶段流程 + 检查点设计 + 质量验证标准）
- ✨ 新增 Phase 5 质量验证（6项通过标准）
- ✨ 新增 Phase 6 双Agent精炼（可选）

---

## 📄 License

MIT License — 欢迎自由使用、修改和分享。

---

> 本 Skill 由 **盘古·skill** 生成，灵感来自「开天辟地」的神话——从混沌中开辟有序的世界。
> 就像把混沌的知识库，开辟成有序的 Skill。


path: references/distillation-best-practices.md
content: # 知识库蒸馏最佳实践

## 什么值得蒸馏？

### ✅ 适合蒸馏的知识库

| 特征 | 示例 | 蒸馏后的价值 |
|------|------|-------------|
| 有明确流程/步骤 | 合同审查流程、代码审查清单 | 用户说一句话就触发完整流程 |
| 有规则/规范检查 | API 规范、代码风格指南 | 自动检查并给出修改建议 |
| 有分类决策场景 | 不同客户类型的处理方案 | 根据用户输入自动路由到正确方案 |
| 有方法论/框架 | OKR 制定方法、用户访谈框架 | 引导用户按框架思考和执行 |
| 有固定输出格式 | 周报模板、需求文档模板 | 自动生成符合规范的文档 |

### ❌ 不适合蒸馏的知识库

| 特征 | 示例 | 建议方案 |
|------|------|---------|
| 纯数据型 | 价格表、产品目录、通讯录 | 保留为知识库，用搜索查询 |
| 需要频繁更新的实时数据 | 股价、天气、实时新闻 | 用 API 或实时数据源 |
| 纯文献存档 | 学术论文、法律条文原文 | 保留为知识库，用于查阅 |
| 一次性参考资料 | 某个具体项目的文档 | 保留为知识库，按需查询 |

---

## 蒸馏质量原则

### 1. 提炼，不要复制

❌ **错误做法**：把知识库的文档原封不动地复制到 Skill 中
✅ **正确做法**：提炼核心规则、流程、决策点

**示例**：

知识库原文（500字）：
> 合同审查需要注意很多方面。首先要看合同双方的基本信息是否完整，包括名称、地址、法定代表人等。然后要审查合同标的是否明确...

蒸馏后（50字）：
> **合同审查三步法**：①核对双方信息 → ②确认合同标的 → ③识别风险条款

### 2. 结构化，不要散装

❌ **错误做法**：把所有规则堆砌在一起
✅ **正确做法**：用表格、列表、流程图组织

**示例**：

散装（难用）：
> 如果合同金额大于10万需要法务总监审批，如果在国外需要合规审查，如果是采购合同需要采购部门确认...

结构化（好用）：
| 合同类型 | 金额阈值 | 审批人 |
|---------|---------|--------|
| 采购合同 | >10万 | 法务总监 |
| 任何合同 | 涉及国外 | 合规部门 |
| 任何合同 | 任何金额 | 采购部门（如适用）|

### 3. 场景化，不要抽象

❌ **错误做法**：写一堆抽象的原则
✅ **正确做法**：给出具体场景和示例

**示例**：

抽象（难理解）：
> 要注意合同条款的公平性，避免对客户产生不利影响的条款...

场景化（好理解）：
> ❌ **不公平条款示例**："甲方有权随时终止合同，无需说明理由"
> ✅ **修改后**："甲方终止合同需提前30天书面通知，并说明合理理由"

### 4. 保留边界，不要过度泛化

❌ **错误做法**：把特定场景的规则推广到所有场景
✅ **正确做法**：明确标注规则的适用边界

**示例**：

过度泛化（危险）：
> 所有合同都必须有违约金条款（❌ 实际上有些合同不需要）

保留边界（安全）：
> **需要违约金条款的合同**：服务合同、租赁合同、采购合同
> **可省略违约金条款的合同**：赠与合同、无偿保管合同

---

## 蒸馏步骤详解

### Step 1：浏览全貌（5分钟）

不要一上来就蒸馏，先花5分钟浏览知识库：

1. 看文件夹结构 → 理解知识组织方式
2. 看文档标题 → 识别核心主题
3. 看文档数量 → 判断是否需要指定蒸馏范围

**输出**：在心里形成一个知识地图

### Step 2：识别核心（10分钟）

问自己三个问题：

1. **用户用这个知识库最想解决什么问题？**（核心场景）
2. **解决这个问题最关键的知识是什么？**（核心内容）
3. **如果只能保留20%的内容，保留哪些？**（精炼核心）

**输出**：列出 3-5 个核心知识点

### Step 3：选择蒸馏类型（2分钟）

根据核心知识点的类型，选择 Skill 类型：

| 核心知识点类型 | Skill 类型 | 结构特点 |
|---------------|-----------|---------|
| 是一系列步骤 | 流程型 | Step 1 → Step 2 → Step 3 |
| 是一系列检查项 | 规范型 | 检查清单 + 通过标准 |
| 是不同场景的不同做法 | 任务型 | 决策表 + 场景路由 |
| 是一个思考框架 | 框架型 | 核心框架 + 应用指南 |

### Step 4：提炼和结构化（20-30分钟）

对每条核心知识，进行提炼：

1. **提取关键词**：这条知识的3-5个关键词是什么？
2. **简化为规则**：能否用一句话说完？
3. **示例化**：能否给出一个具体示例？
4. **边界化**：这条规则在什么情况下不适用？

**输出**：结构化的 Skill 内容

### Step 5：验证和优化（10分钟）

自己扮演用户，用这个 Skill：

1. 说一句触发语 → Skill 能正确触发吗？
2. 按 Skill 指引操作 → 能解决我的问题吗？
3. 遇到边界情况 → Skill 有应对吗？

**输出**：优化后的 Skill

---

## 常见蒸馏错误

### 错误1：试图蒸馏所有内容

**问题**：知识库有100篇文档，试图全部蒸馏到 Skill 中
**后果**：Skill 变得庞大而难用，失去了「精炼」的意义
**解决**：只蒸馏核心的 20% 内容，其余 80% 作为参考文档保留

### 错误2：蒸馏后无法触发

**问题**：Skill 的 trigger 设置得太窄，用户很难触发
**后果**：用户安装了 Skill 却用不起来
**解决**：设置 5-10 个常见的触发关键词，覆盖用户的自然表达

### 错误3：流程步骤不清晰

**问题**：Skill 中的流程步骤模糊，用户不知道下一步该做什么
**后果**：用户中途放弃使用
**解决**：每个步骤都给出「输入是什么」「输出是什么」「怎么做」

### 错误4：缺少示例

**问题**：Skill 只有规则，没有示例
**后果**：用户不理解如何应用规则
**解决**：每个重要规则都配一个具体示例（最好有正反对比）

### 错误5：没有边界说明

**问题**：Skill 没有说明「什么情况下不适用」
**后果**：用户在不适用的场景使用，得到错误结果
**解决**：在 SKILL.md 中明确写出「不适用场景」

---

## 质量自检清单

蒸馏完成后，用这个清单检查：

### 结构完整性

- [ ] SKILL.md 有 frontmatter（name, description, trigger）
- [ ] 有适用场景说明（✅ 和 ❌）
- [ ] 有清晰的执行流程
- [ ] 有注意事项/边界说明

### 内容质量

- [ ] 触发关键词是否覆盖用户的自然表达？
- [ ] 流程步骤是否清晰可执行？
- [ ] 是否有具体示例？
- [ ] 是否有边界说明？

### 蒸馏充分性

- [ ] 是否保留了核心知识（20%）？
- [ ] 是否去除了无关内容（80%）？
- [ ] 结构是否比原知识库更清晰？
- [ ] 用户能看懂并使用吗？

---

## 进阶技巧

### 技巧1：用决策表替代长篇说明

如果有「不同情况不同做法」的知识，用决策表：

**长篇说明（难用）**：
> 如果是新客户，需要... 如果是老客户，需要... 如果是一级客户，需要... 如果是二级客户...

**决策表（好用）**：
| 客户类型 | 所需材料 | 审批流程 |
|---------|---------|---------|
| 新客户 | A+B+C | 三级审批 |
| 老客户 | B+C | 二级审批 |
| 一级客户 | C | 一级审批 |

### 技巧2：用检查清单替代描述性文字

如果有「需要确保多项内容」的知识，用检查清单：

**描述性文字（难用）**：
> 在发布前，你需要确保测试都通过，文档都更新，代码都review...

**检查清单（好用）**：
Release 检查清单：
- [ ] 所有测试通过
- [ ] 文档已更新
- [ ] Code Review 已完成
- [ ] 发布通知已发送

### 技巧3：用模板替代格式说明

如果有「需要生成特定格式内容」的知识，提供模板：

**格式说明（难用）**：
> 周报需要包含本周工作、下周计划、风险点三个部分...

**模板（好用）**：
```markdown
# 周报 - {姓名} - {日期}

## 本周工作
- 

## 下周计划
- 

## 风险点
- 
```

---

## 总结

好的蒸馏 = **20% 的核心内容 + 清晰的结构 + 具体的示例 + 明确的边界**

记住：**Skill 是专家，不是图书馆**。用户想要的是「专家帮我做」，而不是「专家给我一堆书让我自己读」。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)