开发与调试
“接口变慢了，加缓存吧。”
问题来自数据库处理耗时、排队、下游延迟，还是测量方式？在同一时间窗口内，对比有代表性的慢请求与普通请求，核对端到端延迟和这些阶段的耗时。
如果排队时间上升而数据库耗时稳定，就会削弱数据库问题的定义。链路记录不完整时，可能仍无法判断。
先检验问题，再着手解决。
用于编码、调试、架构、科研与产品决策的开源 Agent Skill。在设计方案之前，先检验问题定义与关键假设。
先看看，方案里藏着什么假设
“加缓存。”“换更强的模型。”“多发推送。”每个方案背后，都可能藏着一个尚未检验的解释。先检验这个解释，有助于确定接下来该调查什么。
falsify-the-problem 区分观察与假设，比较有实质差异的问题定义，寻找足以改变判断的证据。Codex 是使用入口之一；这套方法适用于多个领域。
保留原来的问题定义，也是成功结果。KEEP 表示当前定义已得到足够证据支持，可以服务于待做的决策；它不能证明拟议方案一定有效。
三个使用示意
以下均为示意，不是实际生产事故、已执行的实验或实测结果。
科学研究
“实验结果不好，需要更强的模型。”
模型能力不足只是一个假设。固定模型与评分方式，让同一批已保存输入分别经过训练和评估两种预处理路径，检验输入路径不一致是否造成部分差异。
出现差异会支持输入处理存在影响；没有差异时，模型能力及其他解释仍需保留，不能据此确定原因。
产品决策
“留存下降了，多发点推送吧。”
用户是体验到了价值却忘了回来，还是从未体验到价值？核实首次价值事件后，在同一用户群中按该事件对比回访表现，并在这次对比中检查事件覆盖情况。
这种模式可以指导后续调查，但相关性不能证明推送能提升留存。预期回访周期是否合理，也可能需要检验。
不同领域，同一套检验流程
拆开各种陈述
保留证据来源，区分观察、解释、因果假设、问题定义与拟议方案。
比较问题定义
找出合理的替代定义及关键假设。必要时检查候选是否共享一个重要盲点。
选择一个检验
每轮选择一个主要区分性检验，说明不同结果如何影响判断，直接检查可访问且已获授权的证据。
更新并交回控制权
根据证据修正支持程度。调查仍有价值时继续，否则给出结论，交回宿主 Agent。
如何理解结论
KEEP- 原定义已得到充分验证，且获得最多支持。宿主可以继续已获授权的工作。
WEAKEN- 原定义失去了重要支持，但仍可能成立。尚未放行后续方案设计。
KILL- 原定义已无法成立，尚未确立有依据的替代定义。不能继续基于该前提求解。
REFORMULATE- 一个有实质差异的替代定义已得到充分支持。明确返回新定义，交给后续环节验证；旧方案没有因此获准实施。
INSUFFICIENT EVIDENCE- 现有证据不足以区分候选。调查仍有价值时继续，否则说明最少需要补充什么证据。
BYPASS 表示不启用 Skill，不属于证据结论。任何结论都不会授予新权限。在 REFORMULATE 之后，宿主可以利用已有证据验证新定义；若获得 KEEP，再继续已授权的工作。
安装，然后发起第一次调用
完整的 Skill 只有一个 SKILL.md 文件，本身无需软件包、API Key、服务器或数据库。宿主 Agent 需要单独配置。
使用 Codex 本地 Skill 时，选择一种安装范围。路径与 CLI / IDE 调用方式依据 官方 Skills 文档。
| 范围 | 包含 SKILL.md 的文件夹 |
|---|---|
| 项目级：该项目的会话 | <项目>/.agents/skills/falsify-the-problem/ |
| 用户级：当前用户的多个项目 | ~/.agents/skills/falsify-the-problem/ |
以下命令在已安装 Git 的终端中运行。项目级命令从目标项目根目录执行；用户级命令可在任意目录执行。目标文件夹已有内容时，克隆会失败；请保留已有安装。
Windows PowerShell
项目级
New-Item -ItemType Directory -Force -Path .agents/skills | Out-Null
git clone https://github.com/ordinary-s/falsify-the-problem.git .agents/skills/falsify-the-problem用户级
$skillRoot = Join-Path $env:USERPROFILE '.agents/skills'
New-Item -ItemType Directory -Force -Path $skillRoot | Out-Null
git clone https://github.com/ordinary-s/falsify-the-problem.git (Join-Path $skillRoot 'falsify-the-problem')macOS / Linux：Bash 或 Zsh
项目级
mkdir -p .agents/skills
git clone https://github.com/ordinary-s/falsify-the-problem.git .agents/skills/falsify-the-problem用户级
mkdir -p "$HOME/.agents/skills"
git clone https://github.com/ordinary-s/falsify-the-problem.git "$HOME/.agents/skills/falsify-the-problem"也可以从已下载的仓库中，只复制 SKILL.md 到所选文件夹。Codex 会自动发现变化；若未出现，请重启 Codex。在 Codex CLI 或 IDE 扩展内，可用 /skills 或输入 $ 选择 Skill。
接着，在 Codex CLI 或 IDE 扩展内调用
将下面内容粘贴到 Codex 对话框，不要在终端中执行：
$falsify-the-problem
我们的接口变慢了，正在考虑加缓存。
先检查可获取的证据，区分观察与假设，
在提出解决方案之前检验这个问题定义。这些安装命令不能证明 Skill 已成功启用或模型会如何表现。本次文档修改未验证 macOS、Linux 安装及跨宿主行为。
使用其他宿主？按其文档配置 Skill 文件夹，或加载完整的 Markdown 指令并显式要求使用。发现机制、调用方式与权限因宿主而异，不能保证行为一致。参见完整安装说明。
在问题定义影响决策时使用
适合调用的时机
- 你明确希望检验当前的问题定义。
- 不确定的诊断正在推动代价较大的架构或产品改动。
- 调试或研究反复失败，却一直保留同一个未经检验的前提。
通常不必自动启用
- 诊断已经得到验证。
- 任务只是改错别字、翻译、排版或修复明显的编译错误。
- 改动成本低、可逆，且没有实质性的问题定义不确定性。
自动启用需要同时满足：问题定义存在实质不确定性，且干预成本或风险不可忽略。显式调用时，若已有充分证据，可以用简短的 KEEP 结束检验。
查看评测，也了解它的局限
仓库包含 20 个合成案例、更难的问题定义案例、定向覆盖案例、评分标准，以及保留输出的开发评测记录。记录包含原始模型表现良好的结果、混合发现与已知失败。
这些是开发评测，不是具有统计效力的基准证明。它们不能证明 Skill 普遍优于原始模型，也不能证明跨模型或跨宿主有效。早期记录描述的是当时的测试快照，不代表之后的每个版本。
这是 Markdown 指令，无法强制执行运行时门槛或沙盒，也不是自动因果识别系统。它不能保证新的问题定义正确，不能替代专业审查。证据的可访问性与质量、宿主权限和模型判断都会影响结果。