Skill: gerrybin/jiaoyifu-workplanning (version 2.0.0)

--- name: jiaoyifu-workplanning description: | 运营方案与工作规划核心技能。覆盖所有运营体系下的方案输出场景。 核心原则：用数据把问题锁死，用四层路径把解法锁死。 五节主结构（所有场景通用）：核心结论 → 现状诊断 → 目标确定 → 方法路径 → 执行方案。 全场景内置「脚姨夫视角评估」两级审核：①每模块输出后自动六维审核（承诺可兑现/执行不自欺/受益方清晰/逻辑一致/数字可追/病因命中）；②全模块确认后整合完整版，触发整体终审，用户确认后收尾。问题在模块内解决，不等整体完成后返工。 使用场景：用户说"工作规划"、"运营方案"、"服务体系方案"、"4月规划"、"季度规划"、 "全年规划"、"目标规划方案"、"活动方案"、"汇报材料"、"xxx方案"等运营/规划/汇报类任务。 触发关键词：工作规划、运营方案、服务体系方案、业务规划、月度规划、季度规划、年度规划、 活动方案、活动策划、工作汇报、复盘报告、增长策略、目标拆解。 替代技能：operation-plan、monthly-goal-planning、annual-strategic-planning、work-planning。 --- # jiaoyifu-workplanning ## Step 0：场景识别（必须先判断） 收到任务后，先判断场景类型，加载对应 references 文件： | 场景类型 | 典型说法 | 加载文件 | |---------|---------|---------| | **规划类** | 月度/季度/年度规划、目标方案 | `references/planning.md` | | **活动类** | 活动方案、营销策划、ROI测算 | `references/campaign.md` | | **服务体系类** | 服务体系方案、学员服务、运营体系 | `references/service-system.md` | | **汇报复盘类** | 工作汇报、月度复盘、数据汇报 | `references/report.md` | 场景不明确时直接问：「这个方案是规划型、活动型、服务体系型还是汇报复盘型？」 --- ## 五节主结构（所有场景通用） ``` 第一节：核心结论 ← 先说结论，领导先看这里 第二节：现状诊断 ← 数据复盘 + 人物场 + 核心问题识别 第三节：目标确定 ← 数字化目标 + 合理性论证 第四节：方法路径 ← 体系层 / 产品层 / 技术层 / 运营层 第五节：执行方案 ← 分路径/分阶段，每条路径有流程+测算+步骤 ``` 详细内容模板见对应 references 文件。 --- ## 整合完整版输出格式规范 > **适用时机**：完整方案标准流程中「整合输出：完整版方案」环节，所有模块确认后按此规范排版输出。 ### 文档头部（必须包含） ``` [方案名称] [副标题/场景描述] [出品方] · [YYYY-MM-DD] v[版本号] · [用途说明，如：内部使用 / 汇报用] ``` ### 章节标题层级 - **一级标题（对应五节主结构）**：`一 · 核心结论` / `二 · 现状诊断` / 以此类推（不加左侧竖线装饰） - **二级标题（模块/子体系）**：`模块名 · 说明标签`（如：`分级阅读体系 · 1:10000规模化`） - **三级标题（具体内容块）**：动宾短语或名词短语（如：核心定位 / 执行路径 / 可见可追指标） - **禁止**：段落左侧竖线装饰（pBdr left border）——表格以外不使用任何竖线元素 - **禁止**：引用框（带底色+边框的 quote box）——重点观点改用加粗 + 品牌蓝色字体突出，无需边框/背景装饰 ### 表格使用规范（强制） 对比类、数据类、矩阵类信息**必须用表格**，不得散落在段落中： - 2-4列，必须有标题行（加粗） - 左列：维度/对象/阶段 → 右列：内容/数字/动作 - ✅ 产品对比、人力配置、时间节点、目标测算 → 表格 - ❌ 连续多个 key-value 散落在段落里 → 改表格 ### 列表使用规范 - 并列项 ≤ 4个 → 用 `·` 分隔写在一行（如：承诺可兑现 · 执行不自欺 · 数字可追） - 并列项 > 4个 → 用项目符号列表 - 列表层级不超过 2 层；超过说明结构设计有问题 ### 内容密度规范 - 每段正文 ≤ 3-4行，超过则拆为列表或加子标题 - 数字必须具体化：❌「大量」❌「显著」✅「12册/年」✅「续费率4%→8%」 - 核心定义句用「」引号标注，单独成行 - 产品/体系标签用 `·` 分隔内联（如：科学分级 · 名家带读 · 思维提升） ### 禁止清单 - ❌ 连续超过 5 行无任何子结构的纯段落 - ❌ 用「等等」「以及其他」「诸如此类」结尾（未穷举则不列） - ❌ 中英混排（统一用中文，专有名词除外） - ❌ 无来源的数字（没数据来源就标「待核实」，不编数字） --- ## 核心原则（写方案前必读） **原则1：逻辑链锁死** 每一节必须是下一节的充分条件： - 你说目标是X → 第二节数据必须支撑X的合理性 - 你说问题是Y → 第二节现状诊断必须证明Y存在 - 你说方法是Z → Z必须直接命中Y的病因，不是症状 **原则2：目标必须数字化** ❌「提升续费率」 ✅「4月续费率从4%→8%，绝对值+27人，贡献GMV+5万」 **原则3：方法对准病因，不是症状** 续费率低 ≠ 加强沟通。先诊断病因（价值未感知/信任未建立/产品体验差），再设计对应路径。 **原则4：四层路径覆盖度检查** 运营方案至少覆盖以下4层中的2层： - 体系层：流程/机制/规范设计 - 产品层：功能/界面/体验改造 - 技术层：系统/数据/自动化支持 - 运营层：人工干预/活动/内容/社群 --- ## 质量门禁（输出前自检） - [ ] 核心结论是否有数字？（目标GMV / 增长率 / 时间节点） - [ ] 现状诊断有数据支撑？（不是主观判断） - [ ] 每条路径有数据测算？（预计产出是多少） - [ ] 四层方法路径至少覆盖2层？ - [ ] 执行方案有时间线？（Step 1 第X天做什么） - [ ] 方法是否命中了诊断出的核心问题？（不是对症，是对因） --- ## 脚姨夫视角评估节点（全场景 · 两级审核） > **适用范围**：jiaoyifu-workplanning 覆盖的所有场景——服务体系/运营方案/活动策划/规划类/汇报复盘，无一例外 > **两级结构**：Level 1 每模块自动触发单模块审核 → Level 2 全模块完成后整合完整版再触发整体终审 > **核心原则**：问题在模块内发现并修复，不等整体完成后再返工 --- ### 脚姨夫说话方式（审核风格规则） 脚姨夫不写检查报告，脚姨夫直接说话。 - **直接说问题在哪，不说「建议考虑优化一下」** - **不只说「有问题」——说「这里在第几周会死，因为什么」** - **没验证过的数字，直接问：「这个数字你们算过吗？怎么算的？」** - **有根本性问题，直接说「返工」，不用委婉语** - **没问题的地方同样要说清楚：「这里是对的，理由是——」** - **批评要有具体理由：「这个承诺不是不能做，是你们现在的人力做不到」** --- ### 六维审核标准（全场景通用） | 维度 | 核心挑战 | 常见失误 | |------|---------|---------| | **R1 承诺可兑现** | 「这里有没有承诺了做不到的事？」 | 「手写×200份」/「全员100%覆盖」/数量级错误的承诺 | | **R2 执行不自欺** | 「人力/时间/成本，你们真的算过了吗？」 | 感觉合理≠可以跑，无具体测算，比例未验证 | | **R3 受益方清晰** | 「这个设计受益的是用户，还是公司自己？」 | 文案成人化/激励给了错误对象/机制满足公司需求不满足用户需求 | | **R4 逻辑一致** | 「和整体目标/核心定位，有没有悄悄飘走？」 | 前面定位一个方向，某模块变成另一个方向 | | **R5 数字可追** | 「目标有数字吗？方法有数字吗？测算有数字吗？」 | ❌「提升续费率」 ✅「续费率4%→8%，+27人，+5万GMV」 | | **R6 病因命中** | 「这个方法，是对准病因的，还是对准症状的？」 | 续费率低≠加强沟通，要先找根因再设计路径 | > R5/R6 在纯汇报/复盘类场景中可标注「N/A」，规划/方案/服务体系/活动策划类必须检查。 --- ### 单模块审核输出格式（Level 1） ``` 【脚姨夫视角 · 模块N审核】 R1 承诺可兑现 [✅/⚠️/❌] [直接说问题 或「这里没有问题」] R2 执行不自欺 [✅/⚠️/❌] [直接说问题 或「数字算过了，合理」] R3 受益方清晰 [✅/⚠️/❌] [直接说问题 或「受益方是用户，对」] R4 逻辑一致 [✅/⚠️/❌] [直接说问题 或「和整体定位一致」] R5 数字可追 [✅/⚠️/N/A] [直接说问题 或「目标/方法/测算均有数字」] R6 病因命中 [✅/⚠️/N/A] [直接说问题 或「方法直接对准根因」] ────────────── 结论：[✅ 通过，进入下一模块 / ⚠️ 修改后通过（具体N处）→ 确认后继续 / ❌ 返工，本模块重做] ``` --- ### 完整方案标准流程（强制，不可跳过） ``` Step 0：场景识别完成后，立即确认两件事（不可跳过） ① 方案名称（用于文件命名，如「小步读书服务体系」） ② 文件存放目录（默认：用户指定方案目录） ↓ 模块逐一生产 ↓ 每模块：脚姨夫视角单模块审核（Level 1，自动触发） → ⚠️/❌ → 定向修复 → 用户确认 → ✅ 确认后 → Write 写入 [方案名]-模块N-[模块名].md → 报告已写入路径 → 下一模块 ↓ [全部模块确认完成，所有模块文件已写入] ↓ 整合输出：Read 依次读取所有模块文件（按编号逐个，确认文件存在）→ 合并为完整版方案（统一格式） ↓ 脚姨夫视角整体终审（Level 2） ↓ 用户确认完整版 → 模块临时文件可删除（询问用户） ``` ### 模块文件持久化规范 **前置确认（Step 0 强制）**：方案开始前必须确认方案名称和存放目录，不得在生产过程中临时决定。 - 询问话术：「这个方案叫什么名称？文件存在哪个目录？（模块文件将按 `[方案名]-模块N-[模块名].md` 命名存入该目录）」 **写入时机**：每个模块通过 Level 1 审核、用户确认后，立即 Write 文件，再进入下一模块。不能等所有模块完成后再批量写。写入后报告路径，确认写入成功。 **文件命名**：`[方案名]-模块[N]-[模块名].md` 示例：`小步读书服务体系-模块0-服务分层地图.md` / `小步读书服务体系-模块1-人力层定位.md` **合并步骤**： 1. Glob 确认所有模块文件存在（若有缺失，停止并告知用户） 2. Read 所有模块文件（按模块编号顺序逐个读取） 3. 按整合完整版输出格式规范拼接 4. Write 输出完整版 `.md` **文件生命周期**：完整版确认后，询问用户是否删除模块临时文件（默认保留，避免误删）。 **为什么必须这样做**：5+个大模块生产完后，对话上下文窗口已满，早期模块内容被压缩丢失。模块写入文件后，合并阶段通过 Read 分块读取，完全绕开上下文溢出，不依赖记忆。 ### 整体终审三问（Level 2 专属） 整体终审不重复模块细节，只问三个整体性问题： 1. **前后漂移检查**：从第一节到最后一节，核心定位/数字目标/执行逻辑有没有悄悄漂移？ 2. **总体可承载性**：把所有模块叠加起来，这个团队实际上能扛得住吗？ 3. **结论兑现检查**：第一节的核心结论，后面每一节都真正支撑了吗？ --- ## 引用框架（通用工具） 详细框架见 `references/shared-frameworks.md`： - 增长路径漏斗模型（转化率逐层测算） - 人物场分析框架 - Q1-Q4战略解码结构 - 数据目标合理性分析法 - 预算ROI测算表


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