简诗 AI 团队OKR头脑风暴

产品团队做季度规划时，最常见的痛点是目标听起来很正确，但到了季末无法复盘。如果 Objective 只写“提升用户体验”，团队很难判断什么算达成、什么算失败。@user_fccf428b/brainstorm-okrs 要做的，就是把这个模糊阶段转成可讨论、可量化的 OKR 草案。

核心机制：生成三组可衡量草案

该 Skill 把 Agent 设定为资深产品负责人。它不会只丢一句“帮我写目标”，而是要求输出 三组结构完整、彼此独立的 OKR 方案。其关键步骤包括：

• 读取上下文：用户提供公司战略或团队背景文件时，先充分理解；缺少信息时，通过搜索补充行业基准。
• 区分 Objective 与 Key Results：Objective 描述方向与意图；Key Results 必须锁定为 3 个量化指标，并保持在 60-70% 置信度的 ambitious 水平。
• 强调结果而非动作：它不会把“上线 5 个功能”当作 KR，而会追问“上线后对用户留存或转化的影响”。
• 输出 Markdown 文档：结果会整理为 OKRs-[team-name]-[quarter].md，可以直接贴进飞书、Notion 或 Wiki 进行团队讨论。

与 KPI / North Star Metric 的关系

资料里特别强调，OKR、KPI 和 NSM 不是互相替代的选项。Key Results 可以是 KPI，也可以是 NSM 的变化预期；KPI 还可以作为 OKR 的健康指标，防止团队为了短期数字牺牲长期质量。这让生成的草案不只是追数字，而是带有平衡视角。

适用边界

这个 Skill 更适合 策略起草阶段，不是自动执行器。它不会替你拍板，也不会自动抓取数据验证某个 KR 是否真实可得。输入上下文不足时，草案可能偏通用。使用时应注意：

• 对数据可得性做人工确认；
• 把三组方案当作讨论起点，而非最终结论；
• 外部写入、发布、部署等动作仍需要明确确认。