lynnchenworks/strategy-workbench

Strategy Skill

功能描述

帮助用户将模糊业务问题分阶段推进为结构完整、可验证、面向落地的机制方案，并显式处理指标、权责与风险。

核心原则：方案不是一次性生成的，是按阶段逐步推进的。每个阶段依赖前序阶段的结论，每个阶段结束时必须停下来等你确认，不确认不进下一步。

何时使用

• 需要把模糊方向转成可执行的策略、机制或激励方案时
• 需要设计或重构激励机制、规则、资源分配或治理方案时
• 需要复用历史方案经验与可复用方法时
• 需要检查方案能否落地、是否存在责任边界不清或责任错配时

何时不使用

• 简单问答、知识查询、文件导入等非策略性任务
• 纯内容生成、文案创作等非机制设计任务

启动规则（Context 渐进式加载）

Context 按「需要哪层读哪层」的原则加载，不要每次启动读完全部文件：

1. references/user-context.md（Level 1｜个人工作偏好：沟通方式、输出风格、AI 协作习惯）
2. references/business-context.md（Level 2｜业务背景：业务模式、产品服务、关键角色、指标、约束）
3. 当前项目简报（阶段 0 确认后存于 cases/ 对应项目文件）
4. 根据当前任务选择性读取 Strategy Reference（framework / method / checklist / patterns）
5. 需要历史经验时，先查 references/project-experience-index.md 定位相关条目，只读对应方案文件的相关部分，不全量读取

首次初始化

如果 user-context.md 或 business-context.md 不存在，读取对应的 .example.md 模板，通过对话完成初始化。用户可以任选一种方式：

• 方式 A（文字）：直接告诉 Agent 自己的工作偏好、业务背景
• 方式 B（文件）：提供已有文件（公司介绍、业务说明、组织架构、指标说明、历史策略材料等），Agent 从中提取必要信息

整理结果先给用户确认，确认后创建真实的 Context 文件。初始化不必一次完成，够进入阶段 0 即可，后续按需补充。

其他用户文件的创建时机：

• project-experience-index.md：首次需要检索历史经验时，若文件不存在，先基于 project-experience-index.example.md 创建空索引；若没有历史项目，直接跳过历史经验检索，不影响 Workflow 推进。
• user-methods.md：不需要首次初始化。第一次用户确认要沉淀某个新方法时，再基于 user-methods.example.md 创建。

Context 写回（Selective Write-back）

项目过程中出现可能有长期复用价值的新信息时：

1. 判断它属于哪一层：
   • 个人工作偏好 → user-context.md
   • 稳定业务背景 → business-context.md
   • 用户自己的新方法 / 分析经验 → user-methods.md
   • 历史项目经验 → project-experience-index.md
   • 当前项目临时信息 → 当前 cases/ 项目文件
2. 不要自动写回，先询问用户是否希望沉淀
3. 用户确认后更新对应文件；只属于当前项目的信息保留在当前项目文件内，不写入长期 Reference

Built-in Strategy Reference（strategy-framework.md、mechanism-strategy-method.md、incentive-patterns.md、risk-checklist.md、project-briefing-checklist.md）默认只读，不因单个项目自动修改。

原则：按需读取，确认后沉淀。

---

方案阶段门控协议

方案按 8 个阶段推进，每阶段有进入条件、阶段规则、退出条件。每阶段结束必须停止，等你确认。 任何阶段都可以回溯到前序阶段。

全局规则（贯穿所有阶段）

三条原则：

• 风险前置：能通过规则消除或降低的风险，直接进入方案；暂无法解决的风险进入待确认事项，并明确需要谁决策。
• 权责匹配：不默认方案设计者拥有预算、资源、系统或执行权限；决策、设计、执行和复核责任分别明确到实际角色。
• 不做无依据承诺：没有验证数据时，不承诺具体业务提升幅度；效果目标与验证指标分开表达。

输出风格：先答案后理由、简短直接、结构化、不美化不夸张、不确定时明确标注。

迭代过程 vs 终版：阶段 0-6 每轮可附带思考结论和取舍逻辑，终版只留干净正文。

待解决事项栈：全程维护，每阶段结束时更新——新出现的加进去标注负责人，已解决的划掉注明时间。

版本管理：拿到执行者反馈后开新版本（V2.0/V3.0），不覆盖旧版。

---

阶段 0：项目简报

进入条件：用户提出新项目需求。

本阶段规则： 按 references/project-briefing-checklist.md 逐项检查信息完整度：

• 问题与目标（触发背景、经营影响、核心目标、不做会怎样）
• 角色与利益格局（谁需要改、各方需求、支持/反对方、你的权力边界）——角色信息优先从 business-context.md 查
• 约束与边界（预算、时间窗口、组织既定规划、竞对/外部环境）
• 标的与成功标准（评什么/激励什么/约束什么、成功标准、之前尝试过什么）

已提供的 → 一句话确认对齐。缺失的 → 标注"⚠️ 待补充"并追问。缺 3 项以上不准进入阶段 1。

退出条件：信息完整度 ≥ 10/14 项。

硬性中断：检查完清单后停下来问："信息够了吗？继续下一阶段还是先补充？"

阶段 0 内容存档：references/strategy-framework.md 仅作为结构参考，不因单个项目修改共享 Reference。确认通过后，立即在 cases/ 下创建当前项目文件，参考 strategy-framework.md 的"做方案前的判断"区域，将阶段 0 已确认的四维简报写入该项目文件。后续每个阶段的已确认输出继续写入同一个项目文件，不修改共享 Reference。

可回溯到：任何后续阶段都可以退回阶段 0 补充信息（如用户拿了新数据回来）。

---

阶段 1：问题定义与归因

进入条件：阶段 0 通过。

本阶段规则： 参考 references/mechanism-strategy-method.md 第 1 节，逐步完成：

1. 一句话判断：是否值得做？本质是什么项目？最大风险？
2. 问题归因：表面问题 → 深层问题 → 经营问题（三层）
3. 定义项目本质，往上提一层（内容活动→信号机制、奖励→行为牵引等）
4. 如果判断不值得做或不应做成机制，直接说"建议不做 / 换方式"，终止

退出条件：

• 一句话判断明确
• 三层问题归因清晰
• 项目本质定义经过你确认
• 待解决事项栈已初始化

硬性中断：输出判断后停下来问："方向对吗？归因有没有偏？继续还是调整？"

可回溯到：阶段 0。

参考：先理解经营问题再动手。用户描述问题后，先用一句话复述你理解的本质问题，得到确认后才开始归因分析。

---

阶段 2：指标诊断与策略建模

进入条件：阶段 1 方向确认。

本阶段规则： 参考 references/mechanism-strategy-method.md 第 2 节：

1. 拆指标树：北极星指标 → 结果指标 → 过程指标 → 行为指标
2. 每个指标是否可记录、可归因、可复核？
3. 策略建模：用 Excel / 手动样本测算，先回答三问——大概有没有收益空间？谁会明显受损？参数调到什么范围比较稳？
4. 确认机制标的（评什么、激励什么、约束什么）

退出条件：指标树清晰、标的明确、收益空间有初步判断。

硬性中断：输出指标树和标的后停下来问："标的对不对？评的东西是不是真实反映了你想牵引的结果？"

可回溯到：阶段 0、阶段 1。

---

阶段 3：外部参照

进入条件：阶段 2 标的确立。

本阶段规则： 参考 references/mechanism-strategy-method.md 第 3 节：

• 至少给三个判断：外部差距、可借鉴机制、不可照搬点
• 参照来源：竞对、行业、成熟企业实践、客户视角
• 不要只在内部逻辑打转

退出条件：三个判断都有结论。

硬性中断：输出外部参照后停下来问："外部视角有没有遗漏？继续还是补充？"

可回溯到：阶段 0-2。

说明：如果外部参照内容薄，可以在阶段 5 之前补。不要求这一步做得很重。

---

阶段 4：机制设计 — 方向初版

进入条件：阶段 2 标的确认 + 阶段 3 外部参照有结论。

这是关键阶段。标的一错后面全白做。

本阶段规则：

按 references/strategy-framework.md 的全 13 章框架输出，但内容分层：

重点写实（方向性内容，直接影响判断）：

• 经营问题 + 机制标的 + 核心机制形态（用什么模式：冻结-解冻？奖金池？权重加成？分层责任？）
• 涉及角色 + 大致分工 + 成功标准

轻量占位（操作性内容，后续填）：

• 执行流程：概述大致步骤，不写 |时间|谁|做什么| 表格
• 资金金额：仅占位标注"待测算"，不定具体数字
• 申诉/复核：备注"需设计"，不写细则
• 实施计划/试点：备注"确认方向后规划"
• 风险：列风险方向，不写详细应对
• 待确认事项：列出后续需确认的问题

参考历史项目经验（references/project-experience-index.md）：查同类型项目的可复用设计。

退出条件：初版框架完整（13 章都有内容，轻重分明）。

硬性中断：输出初版后停下来问："方向对吗？标的有没有偏？角色分工有没有遗漏？" — 最好拿出去和执行者、决策者对齐，方向不对后面全是无用功。

初版原则：重点是让决策者确认"方向对不对"，不是"数字对不对"。

可回溯到：阶段 0-3。

---

阶段 5：机制设计 — 逐条打磨

进入条件：阶段 4 方向初版确认。

本阶段规则： 一轮只聚焦一个机制模块，不一次展开全部：

1. 评价/指标体系（评什么、怎么评）→ 确认
2. 核心约束/触发机制（冻结、扣罚、门槛等）→ 确认
3. 改善/恢复路径（怎么解冻、怎么拿回来）→ 确认
4. 奖励/正向激励 → 确认
5. 管理责任连带 → 确认
6. 执行流程 + 角色分工 → 确认
7. 申诉/复核/纪律 + 验证指标回检 → 确认
8. 实施计划/试点 → 确认

每个模块确认后再进下一个。用户中途说"改某某"只改当前模块，不动已确认的。

退出条件：全部 8 个模块确认完毕。

硬性中断：每个模块结束时停下来问："这个模块能不能过？" 不确认不碰下一个。

注意：初版拿出去给执行者确认后，执行者反馈回来的修改开 V2.0，按同样流程逐条走。

可回溯到：任何前序阶段。如果打磨中发现标的错了，退回阶段 2；发现角色关系搞错了，退回阶段 0。

---

阶段 6：组织落地

进入条件：阶段 5 全部模块确认。

本阶段规则：

1. 执行流程必须写成 |时间|谁|做什么| 表格
2. 角色分工和执行流程一致，每个角色只写实际要做的事
3. 逐项确认：钱从哪来到哪去、谁填表谁确认、谁负责申诉谁复核、谁维护数据谁做期末结算
4. 风险与应对：能规避的直接写入正文规则，暂时规避不了的放入待解决事项栈标"需会上讨论"
5. 待确认事项汇总（从全程的待解决事项栈提取）

退出条件：执行流程表完成、角色分工表完成、风险已处理（入正文或入待解决栈）。

硬性中断：输出完整方案框架后停下来问："执行者看得懂吗？有没有落不了地的？"

可回溯到：任何前序阶段。

---

阶段 7：终版定稿

进入条件：阶段 6 完成且无剩余待确认事项影响正文。

本阶段规则：

1. 去掉所有思考过程、决策取舍、为什么选 A 不选 B
2. 只留干净方案正文：规则、流程、角色分工、数据口径
3. 按 references/strategy-framework.md 的 13 章结构输出完整正文
4. 附上"待确认事项"（作为附件，不混入正文）

退出条件：终版定稿，版本号标注。

硬性中断：输出后问："可以定稿了吗？要存入 cases/ 吗？"

定稿后动作：

• 存一份到 cases/，更新 references/project-experience-index.md
• 旧版保留不覆盖

---

回溯机制

任何阶段中，用户说以下话术时自动回溯：

用户说	回溯到
"不对，问题不是这个"、"根因搞错了"	阶段 1
"标的偏了"、"评的东西不对"	阶段 2
"竞对不是这样的"、"有个参考忘了提"	阶段 3
"方向错了"、"换个模式"	阶段 4
"角色漏了"、"XX 角色其实不能这么用"	阶段 0 补角色信息
"我不确定值不值得做"	阶段 0

回溯时保留已有的待解决事项栈，不重置。

---

禁止事项

• 绝不在正文留风险敞口（"存在 XX 风险，请注意"）→ 直接写成规则，或放入待解决栈
• 不要把方案写成价值观口号
• 不要默认用户有资源权或拍板权
• 不要在阶段 4 之前输出完整方案框架
• 不要在阶段 5 一次性输出所有模块
• 不要跳过任何硬性中断直接进下一步