Problem Framing Gate — 问题定义判断器
判断「这个异常 / 指标变化到底是不是值得解决的真问题」，输出判断 + 依据。
核心纪律（执行前必读）
- AI 是建议器，不是决策器：输出「判断 + 依据」，不输出「这个问题必须解决 / 必须不解决」。最终拍板在决策者本人。
- 指标变化 ≠ 问题：指标变化只是「发生了什么（What changed）」，只有它对重要业务结果产生不希望的影响（So what），才开始成为问题。
- 先问 So what，再问 Why：禁止从「发现异常」直接跳「找原因 / 给方案」。AI 越强，回答错误问题的速度越快——这一层闸门就是挡住它。
- 每次判断记录回写台账，事后校验「判断对了还是错了」——这是判断逻辑「像做实验慢慢校验」的落点。
首次使用：建立本地台账（必做一次）
本 skill 的长期价值依赖一本持续累积的决策台账。首次使用时：
- 检查当前项目下是否已有
.workbuddy/issue-ledger.md - 不存在 → 基于本 skill 的
references/ledger-template.md创建它（创建.workbuddy/目录如不存在），并告知使用者台账已建立及其位置 - 已存在 → 直接使用，并在台账中追加本次判断
- 若使用者在对话中指定了自定义台账路径，以使用者指定为准
> 台账是「问题判断 → 委派 → 复盘」全流水线的共用账本：同一件事挂同一个 ID，跨 skill、跨时间累积，事后回填「结果校验」验证判断逻辑。不建档 = 无法长期校验，本 skill 退化成一次性问答。
Trigger
- 「这个问题要不要解决 / 值不值得解决」
- 「这是不是问题 / 这是真问题吗」
- 「效率下降 X% / 某个指标异常，该怎么办」
- 「先别急着找原因 / 先确认值不值得做」
Inputs
- 异常 / 指标变化的事实描述：什么地方、什么指标、变化多少、什么时候发现的、涉及谁
- 可选：相关的背景数据（对比基线、历史趋势、影响范围）
- 信息不足时的处理：缺关键事实 → 先列出「还缺哪些信息」再判断，不脑补
核心流程：两道闸门
闸门一 · 值不值得解决（三连问）
看到任何异常，在「为什么」之前先问：
- What changed —— 人、货、流程、客户结构、系统，哪些变了？（客观发生了什么）
- So what —— 这个变化影响了哪个重要业务结果？（利润 / 客户 / 产能 / 质量 / 风险 / 合规，还是仅仅一个指标变难看了？）
- What if do nothing —— 不处理会怎样？值不值得占用组织注意力？
> 注意：第 3 问最容易被跳过，但最关键：很多异常「不处理」的成本是零，或远低于解决成本。先算「不作为的代价」，再决定动不动。
闸门二 · 定义对了吗（Problem vs Symptom）
过了闸门一，再确认「看到的是 Problem 还是 Symptom」，连续问三个「如果」：
- 消灭这个现象，结果真的会变好吗？（培训完财务还是拿不到业务上下文 = 解决的是表象）
- 换一个人 / 换一个环境，问题还会发生吗？（换 B 进来仍被 4 个老板插单 = 更像系统问题）
- 现象突然消失，底层原因还在吗？（员工不再投诉 ≠ 问题消失，可能只是放弃了）
重要业务结果清单（So what 的锚）
默认锚定这些，可随业务扩展：
- 利润 / 现金流
- 客户（流失、NPS、投诉）
- 产能 / 库容（Capacity）
- 质量（差错、破损、时效）
- 风险 / 合规
- 管理带宽（占用多少注意力）
输出格式
## 问题定义判断：{异常/指标变化}
### 闸门一：值不值得解决
1. What changed：
2. So what（影响哪个业务结果）：
3. What if do nothing：
→ 判定：{不是问题·接受 / 低优先级 / 真问题}
### 闸门二：定义对了吗
- 消灭现象结果变好吗：
- 换人/换环境还发生吗：
- 现象消失根因还在吗：
→ 判定：{Problem / Symptom / 需重新定义}
### 建议结论
{什么都不做 / 重新定义问题为 XXX / 进入 Problem Solving（Why→Options→Experiment→Evidence→Scale/Stop）}
### 依据（引用数据/事实，无证据不下结论）
判断记录回写（台账）
每次判断追加到台账 .workbuddy/issue-ledger.md 的对应事情 ID 下（没有 ID 就补一条，格式见模板）。同一件事在「problem-framing → delegation → transfer」三个阶段串在同一条记录里，事后回填「结果校验」验证判断逻辑。
与流水线的关系
- 本 skill 判断「问题值不值得解决」（第一步，先定义问题）
- delegation-check 判断「该交给谁解决」（第二步，再委派）
- capability-transfer 判断「复盘留什么」（第三步，收尾三留）
- 三者是同一系列（「管理决策三件套」，可在 SkillHub 按名搜索），可分别安装，建议配合使用；共用同一本台账，同一件事挂同一 ID
延伸参考（进入 Problem Solving 后）
- Mix-adjusted Performance：把客户 / SKU / 大中件 / 新老员工 / 操作复杂度标准化后，再看真实效率变化（别拿上个月 52 直接比这个月 41）
- System Economics：用 With customer vs Without customer 比较整个系统的人工/空间/设备/机会成本/管理复杂度
- Decision Space：不从异常直接跳单一动作，先列 Solution Classes（价格 / 限量 / 换仓 / 流程 / 自动化 / 服务等级 / 什么都不做）
- Person vs System Problem：产能 + 优先级 + 能力 + 资源都满足仍持续不交付，才有资格把问题定义为「个人执行力」
能力边界（不做什么）
- 不做根因分析（那是进入 Problem Solving 之后的事）——本 skill 只回答「值不值得解决、定义对不对」
- 不替决策者拍板「必须做 / 必须不做」
- 不评估人（人员判断用授权类 skill）
常见误用
- 把「不是问题」理解成「永远不用管」——它只是「现在不值得占用注意力」，条件变化后应重新过闸门
- 跳过第 3 问（What if do nothing）直接给方案——最省事的判断往往最贵
- 拿「有数据」当「有证据」——数据的方向和口径错了，判断跟着错
版本与变更记录
- 1.0.0：首个公开版。三连问 + 两道闸门 + 台账机制（首跑自动建档）。
