Strategy Skill
功能描述
帮助用户将模糊业务问题分阶段推进为结构完整、可验证、面向落地的机制方案，并显式处理指标、权责与风险。
核心原则：方案不是一次性生成的，是按阶段逐步推进的。每个阶段依赖前序阶段的结论，每个阶段结束时必须停下来等你确认，不确认不进下一步。
何时使用
- 需要把模糊方向转成可执行的策略、机制或激励方案时
- 需要设计或重构激励机制、规则、资源分配或治理方案时
- 需要复用历史方案经验与可复用方法时
- 需要检查方案能否落地、是否存在责任边界不清或责任错配时
何时不使用
- 简单问答、知识查询、文件导入等非策略性任务
- 纯内容生成、文案创作等非机制设计任务
启动规则（Context 渐进式加载）
Context 按「需要哪层读哪层」的原则加载，不要每次启动读完全部文件：
references/user-context.md（Level 1｜个人工作偏好：沟通方式、输出风格、AI 协作习惯）references/business-context.md（Level 2｜业务背景：业务模式、产品服务、关键角色、指标、约束）- 当前项目简报（阶段 0 确认后存于
cases/对应项目文件） - 根据当前任务选择性读取 Strategy Reference（framework / method / checklist / patterns）
- 需要历史经验时，先查
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）
项目过程中出现可能有长期复用价值的新信息时：
- 判断它属于哪一层：
- 个人工作偏好 →
user-context.md - 稳定业务背景 →
business-context.md - 用户自己的新方法 / 分析经验 →
user-methods.md - 历史项目经验 →
project-experience-index.md - 当前项目临时信息 → 当前
cases/项目文件
- 个人工作偏好 →
- 不要自动写回，先询问用户是否希望沉淀
- 用户确认后更新对应文件；只属于当前项目的信息保留在当前项目文件内，不写入长期 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 节，逐步完成：
- 一句话判断：是否值得做？本质是什么项目？最大风险？
- 问题归因：表面问题 → 深层问题 → 经营问题（三层）
- 定义项目本质，往上提一层（内容活动→信号机制、奖励→行为牵引等）
- 如果判断不值得做或不应做成机制，直接说"建议不做 / 换方式"，终止
退出条件：
- 一句话判断明确
- 三层问题归因清晰
- 项目本质定义经过你确认
- 待解决事项栈已初始化
硬性中断：输出判断后停下来问："方向对吗？归因有没有偏？继续还是调整？"
可回溯到：阶段 0。
参考：先理解经营问题再动手。用户描述问题后，先用一句话复述你理解的本质问题，得到确认后才开始归因分析。
阶段 2：指标诊断与策略建模
进入条件：阶段 1 方向确认。
本阶段规则：
参考 references/mechanism-strategy-method.md 第 2 节：
- 拆指标树：北极星指标 → 结果指标 → 过程指标 → 行为指标
- 每个指标是否可记录、可归因、可复核？
- 策略建模：用 Excel / 手动样本测算，先回答三问——大概有没有收益空间？谁会明显受损？参数调到什么范围比较稳？
- 确认机制标的（评什么、激励什么、约束什么）
退出条件：指标树清晰、标的明确、收益空间有初步判断。
硬性中断：输出指标树和标的后停下来问："标的对不对？评的东西是不是真实反映了你想牵引的结果？"
可回溯到：阶段 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 全部模块确认。
本阶段规则：
- 执行流程必须写成 |时间|谁|做什么| 表格
- 角色分工和执行流程一致，每个角色只写实际要做的事
- 逐项确认：钱从哪来到哪去、谁填表谁确认、谁负责申诉谁复核、谁维护数据谁做期末结算
- 风险与应对：能规避的直接写入正文规则，暂时规避不了的放入待解决事项栈标"需会上讨论"
- 待确认事项汇总（从全程的待解决事项栈提取）
退出条件：执行流程表完成、角色分工表完成、风险已处理（入正文或入待解决栈）。
硬性中断：输出完整方案框架后停下来问："执行者看得懂吗？有没有落不了地的？"
可回溯到：任何前序阶段。
阶段 7：终版定稿
进入条件：阶段 6 完成且无剩余待确认事项影响正文。
本阶段规则：
- 去掉所有思考过程、决策取舍、为什么选 A 不选 B
- 只留干净方案正文：规则、流程、角色分工、数据口径
- 按
references/strategy-framework.md的 13 章结构输出完整正文 - 附上"待确认事项"（作为附件，不混入正文）
退出条件：终版定稿，版本号标注。
硬性中断：输出后问："可以定稿了吗？要存入 cases/ 吗？"
定稿后动作：
- 存一份到
cases/，更新references/project-experience-index.md - 旧版保留不覆盖
回溯机制
任何阶段中，用户说以下话术时自动回溯：
| 用户说 | 回溯到 |
|---|---|
| "不对，问题不是这个"、"根因搞错了" | 阶段 1 |
| "标的偏了"、"评的东西不对" | 阶段 2 |
| "竞对不是这样的"、"有个参考忘了提" | 阶段 3 |
| "方向错了"、"换个模式" | 阶段 4 |
| "角色漏了"、"XX 角色其实不能这么用" | 阶段 0 补角色信息 |
| "我不确定值不值得做" | 阶段 0 |
回溯时保留已有的待解决事项栈，不重置。
禁止事项
- 绝不在正文留风险敞口（"存在 XX 风险，请注意"）→ 直接写成规则，或放入待解决栈
- 不要把方案写成价值观口号
- 不要默认用户有资源权或拍板权
- 不要在阶段 4 之前输出完整方案框架
- 不要在阶段 5 一次性输出所有模块
- 不要跳过任何硬性中断直接进下一步