用途：Debug Mode 面向“诊断或调试”疑难缺陷，包括失败、偶发、变慢、仅生产环境出现的 bug。它要求先建立可复现的红色反馈回路，再用运行时证据确认唯一成因，只修已被证明的原因；一次通过的可疑修复不算证明。
主要能力与流程：1. 理解阶段，明确症状、受影响范围、预期与实际行为、复现路径。2. 红色回路，构造一条驱动该缺陷代码路径并断言其确切症状的命令，例如失败测试、curl 脚本、对固定数据的 CLI 运行、无头浏览器脚本或重放 trace；要求确定、快速、可无人值守运行，断言具体症状而非“没崩溃”；偶发 bug 需先提高复现率，变慢代码则以基线测量在超过阈值时变红，确实无法构造命令时明确说明并依赖埋点。3. 最小化，用回路逐项裁剪输入、调用方、配置、数据与步骤，直到每部分都必要；若无回路则直接进入假设。4. 假设，给出 2–3 个排序假设，各自指明可用于确认或否定它的观察。5. 埋点，对慢代码做性能剖析或在已知好与坏状态之间二分，其余情况加临时日志，观察应能区分假设且不泄露密钥、不改变行为。6. 复现，触发缺陷并收集证据，遇到需认证或用户特定流程时请用户复现并等待。7. 分析，证据确认某一假设或明确否定全部；全部被否定时据证据写新假设并回到埋点。8. 修复，先将最小复现转为回归测试，再应用最小且有证据支撑的修复，使原场景回路变绿并移除所有临时日志。
用法与限制：用户说“diagnose”时在修复前结束、不应用修复；说 debug 或无动词的 bug 报告则运行到修复。日志应结构化，含 hypothesis_id、event、把单次用户动作串起来的请求或会话 id、观测值与时间戳，并为临时日志加唯一前缀以便一次 grep 移除。报告格式包含症状、测试的假设、收集的证据、确认的根因、应用的修复、已移除的埋点、残余风险；未修复时须说明缺失的证据。平台、安装方式、价格等信息暂未提供。