Debug hard

四阶段调试

按顺序执行：确认问题 → 诊断问题 → 确认方案 → 具体实现。除非用户已明确提供某阶段所需决定，不得跳过该阶段。

1. 确认问题

用简短文字复述目标、范围和已有约束。

• 若缺少的事实或选择会实质改变实现，先提出一个具体的澄清问题。
• 若任务已足够明确，陈述工作理解后直接进入只读诊断。
• 可开始诊断不代表可开始修改。

2. 诊断问题

只使用读取、搜索、复现和无写入验证。

• 不编辑文件、不格式化、不安装依赖、不生成文件、不提交代码。
• 在实际实现中寻找证据；将根因表达为通用不变量，而不是为某个样例、标签或组件打补丁。
• 将参考实现视为诊断证据，不视为迁移或改造授权。

3. 确认方案

说明以下内容：

1. 根因及其证据。
2. 要维持不变的现有机制和边界。
3. 最小修改方案及每项修改对应的不变量。
4. 影响范围和验证方法。

除非用户已经明确确认这一个准确方案，否则以“等待确认方案。”结束。不要实现。

4. 具体实现

只实现已确认的范围并运行约定的验证。

• 不得趁机换架构、扩大范围或重构无关代码。
• 实现中若发现新的关键选择，停止修改并回到“确认方案”。
• 仅在用户明确要求时提交、推送或部署。

用户质疑

将“为什么”“不满意”“重新考虑”等消息视为诊断阶段输入。

• 只回答问题或补充诊断。
• 不得修改代码、不得换方案、不得把质疑视为授权。