Install
openclaw skills install jiaoyifu-workplanning运营方案与工作规划核心技能。覆盖所有运营体系下的方案输出场景。 核心原则:用数据把问题锁死,用四层路径把解法锁死。 五节主结构(所有场景通用):核心结论 → 现状诊断 → 目标确定 → 方法路径 → 执行方案。 全场景内置「脚姨夫视角评估」两级审核:①每模块输出后自动六维审核(承诺可兑现/执行不自欺/受益方清晰/...
openclaw skills install jiaoyifu-workplanning收到任务后,先判断场景类型,加载对应 references 文件:
| 场景类型 | 典型说法 | 加载文件 |
|---|---|---|
| 规划类 | 月度/季度/年度规划、目标方案 | references/planning.md |
| 活动类 | 活动方案、营销策划、ROI测算 | references/campaign.md |
| 服务体系类 | 服务体系方案、学员服务、运营体系 | references/service-system.md |
| 汇报复盘类 | 工作汇报、月度复盘、数据汇报 | references/report.md |
场景不明确时直接问:「这个方案是规划型、活动型、服务体系型还是汇报复盘型?」
第一节:核心结论 ← 先说结论,领导先看这里
第二节:现状诊断 ← 数据复盘 + 人物场 + 核心问题识别
第三节:目标确定 ← 数字化目标 + 合理性论证
第四节:方法路径 ← 体系层 / 产品层 / 技术层 / 运营层
第五节:执行方案 ← 分路径/分阶段,每条路径有流程+测算+步骤
详细内容模板见对应 references 文件。
适用时机:完整方案标准流程中「整合输出:完整版方案」环节,所有模块确认后按此规范排版输出。
[方案名称]
[副标题/场景描述]
[出品方] · [YYYY-MM-DD]
v[版本号] · [用途说明,如:内部使用 / 汇报用]
一 · 核心结论 / 二 · 现状诊断 / 以此类推(不加左侧竖线装饰)模块名 · 说明标签(如:分级阅读体系 · 1:10000规模化)对比类、数据类、矩阵类信息必须用表格,不得散落在段落中:
· 分隔写在一行(如:承诺可兑现 · 执行不自欺 · 数字可追)· 分隔内联(如:科学分级 · 名家带读 · 思维提升)原则1:逻辑链锁死 每一节必须是下一节的充分条件:
原则2:目标必须数字化 ❌「提升续费率」 ✅「4月续费率从4%→8%,绝对值+27人,贡献GMV+5万」
原则3:方法对准病因,不是症状 续费率低 ≠ 加强沟通。先诊断病因(价值未感知/信任未建立/产品体验差),再设计对应路径。
原则4:四层路径覆盖度检查 运营方案至少覆盖以下4层中的2层:
适用范围:jiaoyifu-workplanning 覆盖的所有场景——服务体系/运营方案/活动策划/规划类/汇报复盘,无一例外 两级结构:Level 1 每模块自动触发单模块审核 → Level 2 全模块完成后整合完整版再触发整体终审 核心原则:问题在模块内发现并修复,不等整体完成后再返工
脚姨夫不写检查报告,脚姨夫直接说话。
| 维度 | 核心挑战 | 常见失误 |
|---|---|---|
| R1 承诺可兑现 | 「这里有没有承诺了做不到的事?」 | 「手写×200份」/「全员100%覆盖」/数量级错误的承诺 |
| R2 执行不自欺 | 「人力/时间/成本,你们真的算过了吗?」 | 感觉合理≠可以跑,无具体测算,比例未验证 |
| R3 受益方清晰 | 「这个设计受益的是用户,还是公司自己?」 | 文案成人化/激励给了错误对象/机制满足公司需求不满足用户需求 |
| R4 逻辑一致 | 「和整体目标/核心定位,有没有悄悄飘走?」 | 前面定位一个方向,某模块变成另一个方向 |
| R5 数字可追 | 「目标有数字吗?方法有数字吗?测算有数字吗?」 | ❌「提升续费率」 ✅「续费率4%→8%,+27人,+5万GMV」 |
| R6 病因命中 | 「这个方法,是对准病因的,还是对准症状的?」 | 续费率低≠加强沟通,要先找根因再设计路径 |
R5/R6 在纯汇报/复盘类场景中可标注「N/A」,规划/方案/服务体系/活动策划类必须检查。
【脚姨夫视角 · 模块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
合并步骤:
.md文件生命周期:完整版确认后,询问用户是否删除模块临时文件(默认保留,避免误删)。
为什么必须这样做:5+个大模块生产完后,对话上下文窗口已满,早期模块内容被压缩丢失。模块写入文件后,合并阶段通过 Read 分块读取,完全绕开上下文溢出,不依赖记忆。
整体终审不重复模块细节,只问三个整体性问题:
详细框架见 references/shared-frameworks.md: