用途
frame-check 用于在投入工作前检查“所陈述的问题是不是真正的问题”。作者认为，大多数失败的工作不是答案错了，而是针对错误的问题给出了正确的答案——这被称为“第三类错误”。工作本身严谨、执行干净，却指向了一个从来就不是问题的问题。本技能的目标是在工作commit之前拦住它。
核心判断
问题陈述通常听起来像观察：“上手太慢”“用户很困惑”“这是个竞态条件”。这些都不是观察——有人看到了什么、选取了其中一部分、判定其含义并下了结论，你收到的句子是去掉链条后的最后一环。任务是把这个链条补回去，并追问：链条底端还能支持哪些别的结论。
造成错误问题有两种不同失败，需要不同工具：
- 结论超出了证据——观察支持多种解读，其中一种被选中而无人意识到做了选择。对应工具是 Argyris 的“推理阶梯”：回溯到摄像机本会记录下来的东西。
- 证据可靠但目标错了——诊断成立，但指向一个从未被审视的目标。爬阶梯永远找不到这点，因为目标从未作为证据进入。对应工具是 Argyris 的“双环学习”：追问是哪个主导目标让这件事算作问题。
先查第一种，结束前再查第二种。
执行步骤
- 开口前先拿到第一级：第一级是可观察数据，即任何解读之前、记录设备能捕捉到的内容。要实际去找，而不是假设。第一级通常藏在：反复出现的 bug（查 git log，同一症状修过三次是框架错误的强证据）、事故或故障（原始堆栈与日志行，而非摘要）、指标（看仪表盘或事件定义实际如何计算，指标名常与定义漂移）、用户投诉（逐字原文，而非工单标题的转述）、“慢”或“不稳定”的说法（实际数字及其分布；“慢”从来不是第一级）。若确实拿不到，应明说，并指出能产生它的最小动作；不要在空的底层上编造分析。
- 区分“看到的”与“得出的”：不要产出逐级表格（经典阶梯有七级，多级在压力下无法清晰分离，填满七级只会得到工作表而非发现）。把阶梯当透镜用，只报告“抓到”的地方。依次自问：摄像机记录了什么？其中哪部分被关注、哪部分被丢弃？被理解为什么？得出了什么结论、正在对它做什么？答案比下一层答案“更大”之处就是那一跃，用一句话指出，并引用所述问题与其实际依赖的观察。
- 生成证据支持的框架：约三个，不多。每个框架都必须与第一级一致；编造替代方案比没有更糟。始终包含空框架：这不是问题，或不值得解决（信号是噪声、修复成本超过忍受成本、担心的人群本来就不会转化）。求解一个非问题同样是第三类错误，且无人检查。更多生成动作（换行动者、换层级、看边界外、亮点、反转、Ackoff 的“消解”）见 references/frame-moves.md，其中也含标准阶梯与跨 bug、产品指标、组织问题的示例。
- 落地一个区分性测试：目标是让推断可检验，而不仅是可见。以怀疑结尾的框架检查会让用户处境更糟——信心更少、信息不多。总要给出下一个观察。好测试要便宜（分钟或小时级）、有决定性（各框架预测不同结果）、可得（数据存在或当天能拿到）。在运行前说明哪个结果支持哪个框架；预先预测能防止结果被吸收进某人偏好的框架。若无便宜测试可区分，也要说明，并指出昂贵的那个。
- 双环检查：结束前问一次：是什么目标让这成为问题？再问这个目标是不是对的目标。目标才是烂掉部分的信号包括：同一问题反复以不同面目出现；修复总是拿某个无人愿提的东西做交换；“如果我们干脆不解决会怎样”的诚实答案是“没什么大不了”。若目标成立，就不要提；若不成立，这就是发现，且优先级高于以上一切。
输出格式
STATED <给定的问题，原文引用>
LEAP <第一级实际是什么，陈述在哪里越过了它>
FRAMES A. <框架> — 需要 <假设> B. <框架> — 需要 <假设> C. <空框架，若可行>
TEST <观察> — <成本>。 <结果 X> 支持 A；<结果 Y> 支持 B。
仅当双环检查触发时再加 GOAL 块。整体要短到一分钟内读完；这是一次重定向，不是报告。
提问与退出
先分析，再只问承重问题。承重问题指两种答案导向不同工作；若两条路终点相同，那只是好奇，会浪费用户时间。最多三个问题，每个附上你的最佳猜测，让用户纠正而非长篇作答。
当第一级存在、所述问题是其公允解读、且考虑过的替代方案被证据排除时，用两句话说明“框架成立”并停止。在框架健全时强行重构，本身就是第三类错误——你在解决一个并不存在的框架问题。只有能真心给出“这是对的，去做”，这个技能才值得拥有。
常见失误
- 工作表表演：七个标签级、没有发现。阶梯是给你自己用的。
- 无出口的怀疑：列出替代方案却不给测试，用户被卡住。
- 编造框架：第一级并不支持的替代方案。
- 个人偏好式重构：每个问题都变成你本来就想谈的东西。框架必须来自证据，而非来自你。
- 对小任务开火：一个规格明确的两小时活儿不需要这个。框架检查的成本应与出错的成本成比例。