# 示例：单文档蒸馏 ## 用户输入 ``` 请把我的知识库蒸馏成一个可安装的 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] 示例充分（有正常通过和问题场景两个示例） ```