\r \r

Skill Refactor — 技能改造方法\r

\r

核心理念\r

\r 技能存在的根本问题：不是"这个技能能不能优化"，而是"这个技能需不需要存在"。\r \r 传统思维是"技能存在→优化技能"，但更根本的问题是：这个技能是否本就不该存在？如果技能覆盖的领域是人的局限产物（历史遗留、重复功能、过时需求），那么消除技能比重构技能更彻底。\r \r 改造八步法：\r

• 第一步：边界识别——识别技能覆盖的领域边界\r
• 第二步：存在理由分析——追问技能存在的根本原因\r
• 第三步：消除可行性评估——评估技能是否可以完全消除\r
• 第四步：独立存在必要性判断——判断技能是否值得独立存在\r
• 第五步：拆解——识别技能的每个组成部分\r
• 第六步：消除——去掉不必要的组成部分\r
• 第七步：重整——基于需求重编技能内容\r
• 第八步：改造输出——给出明确的消除/重构/保留建议\r \r 适用范围：任何已存在的技能——用户技能、项目技能、市场技能等。\r \r ---\r \r

改造八步法\r

\r | 步骤 | 操作 | 要点 |\r |------|------|------|\r | 边界识别 | 识别技能覆盖的领域边界 | 明确技能包含什么、不包含什么 |\r | 存在理由分析 | 追问技能存在的根本原因 | 事情本身需要 / 人的局限需要 / 历史遗留 |\r | 消除可行性评估 | 评估技能是否可以完全消除 | 被其他技能吸收 / 功能分散 / 直接废弃 |\r | 独立存在必要性判断 | 判断技能是否值得独立存在 | 边界清晰度 / 功能内聚性 / 消除成本 |\r | 拆解 | 识别技能的每个组成部分 | 追问：这个部分存在是因为事情本身需要，还是人的局限需要？ |\r | 消除 | 去掉不必要的组成部分 | 去掉传递/协调/格式环节，保留核心和校准环节 |\r | 重整 | 基于需求重编技能内容 | 保留的核心部分→重新编排为完整技能 |\r | 改造输出 | 给出明确的消除/重构/保留建议 | 消除/重构/保留三选一 |\r \r ---\r \r

技能存在理由分类\r

\r | 类型 | 标记 | 说明 | 处理建议 |\r |------|------|------|---------|\r | 事情本身需要 | ✅必要 | 技能覆盖的领域有清晰的边界和内聚性 | 保留→重构技能内容 |\r | 人的局限需要 | ❌可消除 | 技能覆盖的领域是因为人的认知局限、历史遗留 | 消除→删除技能 |\r | 历史遗留 | ⚠️待评估 | 技能覆盖的领域是因为历史原因，当前必要性存疑 | 评估后决定 |\r | 外部约束 | 🔒不可消除 | 技能覆盖的领域是因为法规、标准、合同等外部约束 | 保留→重构技能内容 |\r \r ---\r \r

改造判断标准\r

\r 满足任一即建议消除技能：\r \r | 条件 | 阈值 | 示例 |\r |------|------|------|\r | 功能重叠度 | 技能功能≥50%与其他技能重叠 | "文档转换"与"格式处理"高度重叠 |\r | 领域过时度 | 技能覆盖的领域已不再需要 | "传真发送"技能在现代办公中已过时 |\r | 使用频率 | 技能近6个月使用次数\x3C3 | 长期未使用的技能可能已无价值 |\r | 维护成本 | 技能维护成本>收益 | 技能依赖的API已废弃，维护困难 |\r \r ---\r \r

改造后典型形态\r

\r | 形态 | 适用场景 | 执行方式 |\r |------|---------|---------|\r | 消除 | 技能领域不再需要、功能重叠、历史遗留 | 删除技能，功能合并到其他技能 |\r | 重构 | 技能领域需要存在，但内容需要优化 | 重构技能结构、内容、范本 |\r | 保留 | 技能已足够优化，无需改动 | 维持现状 |\r \r 选择原则：能消除的不重构，能重构的不保留。消除是最彻底的优化。\r \r ---\r \r

改造验证清单\r

\r 改造完成后必须逐项验证，十项全部通过才算改造完成：\r \r | # | 验证项 | 说明 |\r |---|--------|------|\r | 1 | ⬜ 领域评估准确 | 是否准确评估了技能领域的存在必要性 |\r | 2 | ⬜ 消除可行性评估合理 | 是否合理评估了消除的可行性 |\r | 3 | ⬜ 重构内容完整 | 如果重构，是否覆盖了技能的全部核心内容 |\r | 4 | ⬜ 结构一致性 | 技能结构是否合理完整 |\r | 5 | ⬜ 改造建议明确 | 是否给出了明确的消除/重构/保留建议 |\r | 6 | ⬜ 领域清晰度 | 技能覆盖的领域边界是否清晰 |\r | 7 | ⬜ 内容完整性 | 技能是否覆盖了领域的全部核心内容 |\r | 8 | ⬜ 结构规范性 | 技能结构是否合理（YAML frontmatter 建议保留 name/author/description，章节结构可灵活调整） |\r | 9 | ⬜ 可执行性 | 技能是否可直接使用，范本是否完整 |\r | 10 | ⬜ 独立性 | 技能是否独立，不依赖其他技能 |\r \r ---\r \r

任务体系\r

\r

领域清单与依赖拓扑\r

\r | ID | 任务类型 | 说明 | 依赖 | 能力需求 |\r |----|---------|------|------|---------|\r | S0-01 | 边界识别 | 识别技能覆盖的领域边界：包含什么、不包含什么、与其他技能的交集 | 无（入口） | 调研 |\r | S0-02 | 存在理由分析 | 追问技能存在的根本原因，标记为必要/可消除/待评估/不可消除 | S0-01 | 调研→设计 |\r | S0-03 | 消除可行性评估 | 评估技能是否可以完全消除：被其他技能吸收、功能分散、直接废弃 | S0-02 | 设计 |\r | S0-04 | 独立存在必要性判断 | 判断技能是否值得独立存在：边界清晰度、功能内聚性、消除成本 | S0-03 | 设计→执行 |\r | S0-05 | 拆解 | 识别技能的每个组成部分，标记为核心/校准/传递/协调/校验/格式 | S0-04 | 调研→设计 |\r | S0-06 | 消除 | 去掉传递/协调/格式环节，保留核心和校准环节 | S0-05 | 设计 |\r | S0-07 | 重整 | 基于需求重编技能内容，保留的核心部分→重新编排为完整技能 | S0-06 | 设计→执行 |\r | S0-08 | 改造输出 | 基于改造结果给出明确建议：消除/重构/保留 | S0-07 | 设计 |\r \r 依赖链路：S0-01 → S0-02 → S0-03 → S0-04 → S0-05 → S0-06 → S0-07 → S0-08（八步法）\r \r ---\r \r

领域要求清单\r

\r

S0-01 边界识别\r

\r

• 必选组件: 技能名称、技能覆盖领域描述（包含什么、不包含什么）、与其他技能的交集列表、边界清晰度评估（清晰/模糊/高度重叠）\r
• 可选组件: 技能创建时间、技能使用频率、技能维护成本\r
• 组装顺序: 技能确认→领域梳理→交集识别→边界清晰度评估→数据汇总\r
• 约束: 必须完整识别技能覆盖的领域，不可跳过"理所当然"的功能；边界清晰度必须基于客观标准，不可凭感觉\r
• 格式: 技能领域边界图（Markdown表格+交集标注）\r \r

S0-02 存在理由分析\r

\r

• 必选组件: 技能存在的根本原因（事情本身需要 / 人的局限需要 / 历史遗留 / 外部约束）、存在理由标记（✅必要 / ❌可消除 / ⚠️待评估 / 🔒不可消除）、标记理由\r
• 可选组件: 存在理由细分（组织架构/协作需要/认知局限/历史惯性/法规要求）、消除动机评估\r
• 组装顺序: 追问存在理由→根本原因判定→类型标记→理由记录→汇总统计\r
• 约束: 每个技能必须追问"如果组织是完全扁平的、没有部门壁垒，这个技能还需要独立存在吗？"；判定必须基于事情本身逻辑，不可因"行业惯例"保留\r
• 格式: 存在理由分析表（Markdown表格）\r \r

S0-03 消除可行性评估\r

\r

• 必选组件: 消除方案（被其他技能吸收 / 功能分散到其他技能 / 直接废弃）、消除成本评估（低/中/高）、消除风险评估（低/中/高）、消除后功能覆盖度\r
• 可选组件: 消除时间表、消除后需新增的协调机制、消除后需调整的依赖关系\r
• 组装顺序: 消除方案设计→成本评估→风险评估→功能覆盖度验证→消除可行性判定\r
• 约束: 消除方案必须具体到"功能A→技能X，功能B→技能Y"；成本评估必须基于实际数据，不可凭感觉；风险评估必须考虑最坏情况\r
• 格式: 消除方案表（Markdown表格）\r \r

S0-04 独立存在必要性判断\r

\r

• 必选组件: 边界清晰度评分（1-10）、功能内聚性评分（1-10）、消除成本评分（1-10，越高越不值得消除）、独立存在必要性评分（综合评分）\r
• 可选组件: 评分依据详细说明、敏感性分析（不同权重下的评分变化）\r
• 组装顺序: 边界清晰度评分→功能内聚性评分→消除成本评分→综合评分→必要性判定\r
• 约束: 评分必须基于客观标准，不可凭感觉；综合评分必须考虑三个维度的权重（边界清晰度30%，功能内聚性40%，消除成本30%）\r
• 格式: 评分表（Markdown表格）\r \r

S0-05 拆解\r

\r

• 必选组件: 技能的每个组成部分（章节、范本、规则等）、每个部分的存在理由（事情本身需要 / 人的局限需要）、部分类型标记（✅核心 / 🔶校准 / ❌传递 / ❌协调 / ⚡校验 / ❌格式）\r
• 可选组件: 部分间依赖关系、部分重要性评估\r
• 组装顺序: 技能内容梳理→逐部分追问→存在理由判定→类型标记→理由记录→汇总统计\r
• 约束: 每个部分必须追问"如果执行者是一个拥有无限知识能力和零协作损耗的AI，这个部分还需要吗？"；判定必须基于事情本身逻辑，不可因"行业惯例"保留\r
• 格式: 技能组成部分分析表（Markdown表格）\r \r

S0-06 消除\r

\r

• 必选组件: 消除清单（哪些部分消除、为什么可消除）、保留清单（✅核心部分+🔶校准部分+⚡关键校验部分）、消除后的内容传递方式\r
• 可选组件: 每个消除部分的风险评估、消除后需新增的关键校验点\r
• 组装顺序: ❌标记部分逐一评估→消除决策→🔶校准部分确认→保留部分确认→关键校验点插入→消除清单+保留清单\r
• 约束: 消除传递/协调/格式部分不可犹豫——这些是人的局限产物不是事情本身需要；校验部分精简为关键节点但涉及合规的不可消除；校准部分不可消除——起纠偏作用的必须保留\r
• 格式: 消除决策表（Markdown表格）\r \r

S0-07 重整\r

\r

• 必选组件: 重构后技能结构（YAML frontmatter + 章节结构）、重构后技能内容\r
• 可选组件: 重构前后对比、重构理由说明\r
• 组装顺序: 保留部分排序→技能结构设计→内容填充→范本编写→规则制定→验证清单\r
• 约束: 内容必须基于实际能力，不可夸大；范本中 ________ 为待用户提供的内容，不可AI编造；YAML frontmatter 建议保留 name、author、description 三个字段；章节结构可根据用户风格规范灵活调整\r
• 格式: 完整 SKILL.md 文件\r \r

S0-08 改造输出\r

\r

• 必选组件: 改造建议（消除 / 重构 / 保留）、改造理由、后续行动建议\r
• 可选组件: 改造置信度（高/中/低）、改造风险提示、改造后跟踪指标\r
• 组装顺序: 改造结果汇总→改造建议→理由记录→后续行动建议\r
• 约束: 改造建议必须明确，不可模棱两可；如果建议消除，必须说明消除理由；如果建议重构，必须提供重构后的完整技能内容\r
• 格式: 改造记录（Markdown）\r \r ---\r \r

领域范本\r

\r

SR-01 技能改造范本\r

\r 对应任务: S0-01 ~ S0-08\r \r 适用场景: 任何已存在的技能需要评估和重构\r \r 改造范本:\r \r

## 技能改造记录\r
\r
### Step 1：边界识别（S0-01）\r
\r
**目标技能**：________（如：workflow-refactor/domain-elimination-assessor/________）\r
\r
**技能覆盖领域描述**：\r
- 包含：________\r
- 不包含：________\r
\r
**与其他技能的交集**：\r
\r
| 交集技能 | 交集内容 | 交集程度 |\r
|---------|---------|---------|\r
| ________ | ________ | 低/中/高 |\r
| ________ | ________ | 低/中/高 |\r
| ________ | ________ | 低/中/高 |\r
\r
**边界清晰度**：清晰 / 模糊 / 高度重叠\r
\r
**技能信息**：\r
- 创建时间：________\r
- 使用频率：近6个月使用___次\r
- 维护成本：低/中/高\r
\r
### Step 2：存在理由分析（S0-02）\r
\r
**追问准则**：如果组织是完全扁平的、没有部门壁垒，这个技能还需要独立存在吗？\r
\r
**存在理由**：________\r
\r
**存在理由标记**：\r
- ⬜ 事情本身需要 → ✅必要\r
- ⬜ 人的局限需要 → ❌可消除\r
- ⬜ 历史遗留 → ⚠️待评估\r
- ⬜ 外部约束 → 🔒不可消除\r
\r
**标记理由**：________\r
\r
**存在理由细分**（如适用）：\r
- 组织架构：________\r
- 协作需要：________\r
- 认知局限：________\r
- 历史惯性：________\r
- 法规要求：________\r
\r
### Step 3：消除可行性评估（S0-03）\r
\r
**消除方案**：\r
\r
| 方案 | 具体描述 | 成本 | 风险 |\r
|------|---------|------|------|\r
| 被其他技能吸收 | ________ | 低/中/高 | 低/中/高 |\r
| 功能分散到其他技能 | ________ | 低/中/高 | 低/中/高 |\r
| 直接废弃 | ________ | 低/中/高 | 低/中/高 |\r
\r
**推荐方案**：________\r
\r
**消除后功能覆盖度**：\r
- 功能A → 技能X\r
- 功能B → 技能Y\r
- 功能C → 技能Z\r
\r
**消除成本评估**：低/中/高（理由：________）\r
\r
**消除风险评估**：低/中/高（理由：________）\r
\r
### Step 4：独立存在必要性判断（S0-04）\r
\r
**评分标准**：\r
- 边界清晰度（1-10）：边界越清晰，分数越高\r
- 功能内聚性（1-10）：功能越相关，分数越高\r
- 消除成本（1-10）：成本越高，分数越高（越不值得消除）\r
\r
**评分结果**：\r
\r
| 维度 | 评分 | 权重 | 加权分 |\r
|------|------|------|--------|\r
| 边界清晰度 | ___/10 | 30% | ___ |\r
| 功能内聚性 | ___/10 | 40% | ___ |\r
| 消除成本 | ___/10 | 30% | ___ |\r
| **综合评分** | ___/10 | 100% | ___ |\r
\r
**评分依据**：\r
- 边界清晰度：________\r
- 功能内聚性：________\r
- 消除成本：________\r
\r
**必要性判定**：\r
- 综合评分 ≥ 7：技能值得独立存在 → 继续重构\r
- 综合评分 4-6：技能存在必要性存疑 → 进一步评估或部分消除\r
- 综合评分 \x3C 4：技能不值得独立存在 → 消除\r
\r
### Step 5：拆解（S0-05）\r
\r
**追问准则**：如果执行者是一个拥有无限知识能力和零协作损耗的AI，这个部分还需要吗？\r
\r
| # | 组成部分 | 存在理由 | 类型标记 | 标记理由 |\r
|---|---------|---------|---------|---------|\r
| 1 | ________ | 事情本身需要 | ✅核心 | ________ |\r
| 2 | ________ | 事情本身需要 | 🔶校准 | 中间产出物起纠偏作用，保留为分步校准点 |\r
| 3 | ________ | 人的局限需要 | ❌传递 | 人之间信息传递 |\r
| 4 | ________ | 人的局限需要 | ❌协调 | 管理多人协作 |\r
| 5 | ________ | 人的局限需要 | ⚡校验 | 防止人出错，保留关键节点 |\r
| 6 | ________ | 人的局限需要 | ❌格式 | 满足组织流程 |\r
| ... | ... | ... | ... | ... |\r
\r
**统计**：✅核心___个 / 🔶校准___个 / ❌消除___个 / ⚡精简___个\r
\r
### Step 6：消除（S0-06）\r
\r
**消除清单**：\r
\r
| # | 被消除部分 | 原类型 | 消除理由 |\r
|---|-----------|--------|---------|\r
| 1 | ________ | 传递 | ________ |\r
| 2 | ________ | 协调 | ________ |\r
| 3 | ________ | 格式 | ________ |\r
| ... | ... | ... | ... |\r
\r
**保留清单**：\r
\r
| # | 保留部分 | 保留理由 | 类型 |\r
|---|---------|---------|------|\r
| 1 | ________ | 事情本身逻辑步骤 | ✅核心 |\r
| 2 | ________ | 中间产出物起纠偏作用 | 🔶校准 |\r
| 3 | ________ | 关键质量校验 | ⚡校验（精简后） |\r
| ... | ... | ... | ... |\r
\r
### Step 7：重整（S0-07）\r
\r
**重构后技能结构**：\r
\r
YAML frontmatter 建议保留 name、author、description 三个字段。\r
\r
**重构后章节结构建议**：\r
1. 核心理念\r
2. 方法论（步骤/分类/标准）\r
3. 典型形态\r
4. 验证清单\r
5. 任务体系\r
6. 领域要求清单\r
7. 领域范本\r
8. 使用规则\r
9. 事实纪律\r
\r
注：以上为建议结构，不同用户可根据自身风格规范灵活调整。\r
\r
**重构理由**：________\r
\r
### Step 8：改造输出（S0-08）\r
\r
**改造结果汇总**：\r
- 边界识别：________\r
- 存在理由：________\r
- 消除可行性：________\r
- 独立存在必要性：________\r
- 拆解结果：________\r
- 消除结果：________\r
- 重整结果：________\r
\r
**改造建议**：\r
- ⬜ 消除：技能不值得保留，建议消除\r
- ⬜ 重构：技能值得保留，建议重构\r
- ⬜ 保留：技能已足够优化，无需改动\r
\r
**改造理由**：________\r
\r
**后续行动建议**：\r
- 如果消除：________\r
- 如果重构：提供重构后的完整技能内容\r
- 如果保留：________\r
\r
**改造置信度**：高/中/低\r
\r
**改造风险提示**：________\r
\r
---\r
\r
### 改造前后对比\r
\r
| 维度 | 改造前 | 改造后 | 变化 |\r
|------|--------|--------|------|\r
| 技能状态 | 存在 | 消除/重构/保留 | ________ |\r
| 功能覆盖 | 集中在该技能 | 分散到其他技能/保持集中 | ________ |\r
| 结构一致性 | 不一致/一致 | 更一致/已消除 | ________ |\r
| 使用频率 | 低/中/高 | 更高/已消除 | ________ |\r
```\r
\r
**范本要点**:\r
- 改造的核心是"追问存在理由"——每个技能都必须回答"这个技能覆盖的领域是否还需要存在"\r
- 消除技能比重构技能更彻底——如果技能领域本不该存在，消除是最佳选择\r
- 评分必须基于客观标准，不可凭感觉——功能重叠度、领域过时度、使用频率、维护成本都需要量化\r
- 改造建议必须明确——消除/重构/保留三选一，不可模棱两可\r
- 范本中 `________` 为待用户提供的内容，不可AI编造\r
\r
---\r
\r
## 使用规则\r
\r
1. **判断是否需要改造**：当技能功能重叠、领域过时、使用频率低时，触发改造\r
2. **按八步法执行**：S0-01 → S0-02 → S0-03 → S0-04 → S0-05 → S0-06 → S0-07 → S0-08，不可跳步\r
3. **产出交付**：按领域要求清单逐项填充，或按SR-01范本结构替换实际内容\r
4. **用户主权**：AI按技能框架产出的内容是起点，不是终稿。用户对任何环节有独特的校准点、质量标准或业务约束，都可以也应当要求修改——尤其是评分标准的权重，只有用户知道哪些维度对他的场景最重要。用户还可以主动提供清单（该技能应包含的组件列表）和样本（高质量的同类技能作为参考）作为校准参考，让AI的产出更贴合实际需求\r
\r
---\r
\r
## 事实纪律\r
\r
1. AI工具能力描述必须基于实际能力，不得夸大\r
2. 改造结果必须标注为"参考范围"，实际效果取决于具体技能\r
3. 涉及法规、标准、合同等外部约束的技能必须明确标注，不可因改造而忽略\r
4. "技能存在必要性判断"必须基于客观数据，不可凭感觉\r
5. "技能内容重构"必须基于实际能力，不可夸大