ISSUE-NNN：简短描述（动宾结构，说明什么出了什么问题）

问题现象

用数据或错误信息说明"看到了什么"。避免在这里解释原因。

如果是精度问题：给出具体数字（RMSPE、比值、绝对误差）
如果是 bug：给出复现步骤和错误输出
如果是参数不确定：说明当前用了什么值，以及不确定的具体方面

调查过程

按时间线记录调查步骤，包括排除的假设和确认的行为。每条注明类型：[假设] / [查 spec] / [查代码] / [与用户确认] / [实验]

[查 spec] 读了 XXX_SPEC §N.N → 确认 ...
[假设 1] ... → 排除，因为 ...
[与用户确认] ... → 用户确认：...
[查代码] 追踪 file.rs:line → 发现 ...
[假设 2] ... → 确认是根因

根因分析

说明"为什么会这样"。

指向具体代码位置（文件:行号）。如果是多层原因，用级联方式写清楚。

如果根因尚未确认，在此注明"假设"并标出未验证的部分。

Spec / 文档依据

列出查阅了哪些文档，找到了什么依据。

原始 Spec（硬件/协议文档）：

"spec 原文..."
— 文档名 §章节

项目 Spec（自己写的设计文档）：

引用 docs/specs/xxx 中的描述

与用户确认的行为：

[YYYY-MM-DD] 确认：...
[YYYY-MM-DD] 确认：...

推断（基于 spec 的合理推断，但非直接说明）：

推断内容，以及推断依据

未解决（查了 spec 但仍不确定的）：

描述不确定的问题，以及需要什么额外信息

业界对比（可选）

当根因涉及协议/建模决策时，对比业界做法以验证修复方向。

协议	相关机制
...	...

解决方案

备选方案

列出考虑过的方案，说明各自的权衡：

方案	描述	优点	缺点
A
B

采用方案

说明选择哪个方案及理由。

涉及文件：

文件	改动说明
`path/to/file.rs`	具体改了什么

验证

修复后如何确认问题已解决：

运行哪个测试/脚本
预期的指标变化（修复前 → 修复后）

遗留问题

修复后仍存在的、与本 issue 相关但范围外的问题。如无，删除此节。

问题现象​

调查过程​

根因分析​

Spec / 文档依据​

业界对比（可选）​

解决方案​

备选方案​

采用方案​

验证​

遗留问题​