用途：当用户说“solve problem”“solve this problem”或调用 /solve-problem 时使用，提供一套有条理、证据优先的问题解决方法。目标是抑制“看到第一个听起来合理的修复就动手”的直觉，避免错误修复和反复试错。该方法与领域无关，适用于代码缺陷、设备故障、销售下滑、失败流程等。
主要能力与步骤：按顺序执行以下动作，不得跳步。1) 理解意图：用自己的话复述问题，确认期望、实际发生的情况以及“解决”的标准；仅在问题确实模糊时向用户澄清，清晰的问题只需回显理解后继续。2) 亲眼、可重复地观察问题：先确认问题真实存在再找原因，直接观察并在可复现条件下验证，不要依赖二手报告、工单、摘要或单条过期日志；最好能按需复现或检查。若无法看到，或发现并非真实问题（期望错误、已修复、环境问题），就说明并停止，不要为未观察到的问题编造修复。3) 提出假设：调查事物本应如何工作、现实在哪里偏离，至少列出两个候选原因；禁止只提一个假设，以避免隧道视野。4) 收集证据：针对每个假设，运行最便宜的鉴别性检查，最好能否证假设而不只是与其一致；相关性证据较弱。用一手证据确认或排除，假设和记忆不算证据；便宜检查无法隔离时，用更多仪表直接观察，而非更用力猜测，直到只剩一个经得起证伪尝试的原因。5) 提出方案：基于证据提出修复，说明置信度和仍不确定之处；默认到此为止，只提方案，除非用户要求实施。6) 验证解决：修复应用后，在显示原始症状的相同条件下重新观察，问题未被验证消失就不算解决；若症状仍在，说明修复或诊断有误，不要基于同一推理继续补丁，应带更多仪表回到第 2 步。
防急躁规则：先读定义再读周边，配置、frontmatter、schema 或源码通常是最便宜、最决定性的证据；未亲眼看到问题且原因有证据前不提出方案；测试任何假设前至少有两个假设；证据而非记忆或假设确认原因；问题复发说明之前错了。报告中的说法是假设而非证据，表面信号（菜单标签、状态徽章、错误字符串、仪表盘数字）也是假设。恒定值（如重复出现的同一 15 秒）是线索，可能是截止时间或间隔，而非工作耗时。呈现方案时应展示完整推理轨迹，结构为：问题、我如何确认、考虑的假设（逐个标注排除/确认）、证据、根因、拟定方案、置信度、验证（应用后重新检查原始症状是否消失）。references/ 中提供完整端到端示例，例如“SSE keepalive 被误诊为超时”，展示证伪多个看似合理原因、升级仪表、阅读依赖源码作为证据并端到端验证修复。
适用场景：需要避免草率修复、强调证据与验证的排查任务，包括代码、设备、业务指标、流程等。限制：资料未提供具体安装命令、收费、价格、平台或额外效果信息；若问题无法亲眼观察且非真实问题，应停止而非编造修复。