技术论文 / 方案骨架模板（填空版）

# 【标题：方法名 + 它做了什么 + 在什么前提下】
#   好标题示例：FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness
#   三个要素：方法名 / 收益 / 关键限定词（exact、lossless、training-free…）

## Abstract                                   ← 四段式各一句
【① 瓶颈】在【场景】下，【量】随【变量】增长，导致【后果】，实测【指标】=【数值】。
【② 问题】我们研究：在【约束】下，能否把【指标】改善到【目标】。我们不处理【非目标】。
【③ 方法】我们提出【方法名】，其核心洞察是【一句话】；它通过【机制】实现【目标】。
【④ 结果】在【条件】下，【指标】从【原值】到【新值】（【倍数】），且【与基线的一致性声明】。
        代价是【代价】，因此适用区间是【区间】。

## 1 Introduction
### 1.1 现象与量化                              ← ①
- 场景：【硬件 / 模型 / 负载 / shape】
- 观测：【指标】=【数值】；对比【基线】=【数值】，差【倍数】
- Profiler 证据：【kernel / 操作】占【时间 / 带宽】的【X%】
- 机制解释：为什么是它 → 【归因】
- 时效性：为什么现在必须解决 → 【规模 / 场景的变化】

### 1.2 问题与约束                              ← ②
- 目标：把【指标】从【现状】改善到【目标】，方向【↑/↓】
- 约束：
  C1 【精度 / 分布一致性】
  C2 【显存上界 / 延迟上界】
  C3 【兼容性 / 接口稳定性】
- 非目标（out of scope）：【明确不解决什么】
- 成功判据：【阈值】，由【④的哪个实验】验证
- 难点：【目标 1】与【约束 2】的直接冲突

### 1.3 现有方案为何不够                        ← Gap
- 类别 1【近似类】：不够的原因是【X】，违反约束【C?】
- 类别 2【系统类】：不够的原因是【Y】，触及上界【C?】
- 类别 3【硬件类】：不够的原因是【Z】，在目标场景不可得
- 结论：剩下的唯一方向是【方向】

### 1.4 贡献列表（3 条，每条可证伪）
1. 【洞察】，并据此提出【机制】
2. 【机制 2 / 系统实现】，解决【约束 C?】
3. 在【条件】下验证：与【强基线】相比【指标】改善【倍数】，并给出适用区间

## 2 Background / Problem Formulation          ← ② 的正式化
- 符号表：【符号】=【含义】
- 目标函数：【形式化写法】
- 约束的数学表达：【形式化写法】
- 【必要的前置知识，只写读者看不懂的部分】

## 3 Related Work                               ← 逐类否定，不是罗列
- 【类别 A】：解决了【哪部分】，但在【维度】上与我们正交 / 不足
- 【类别 B】：与我们目标相同，但【不足】，因此【我们的差异】
- 一句话定位：我们是【类别】里第一个同时满足【约束 C1、C2】的工作

## 4 Method                                     ← ③
### 4.1 核心洞察
一句话：【……】。
为什么这个洞察成立：【机制解释】。

### 4.2 设计
- 组件 1【名称】：对应约束【C?】，解决【什么】
- 组件 2【名称】：对应约束【C?】，解决【什么】
- 组件 3【名称】：对应约束【C?】，解决【什么】
- 伪代码 / 数据流图：见【图 N】

### 4.3 取舍与替代方案
- 我们放弃了【X】，代价是【Y】；接受它，因为【Z】
- 为什么不直接【更简单的做法】：因为【会违反约束 C?】

### 4.4 实现细节（可复现性）
- 关键参数：【值】
- 并行划分 / 分块大小：【值】
- 已知的边界处理：【……】

## 5 Evaluation                                 ← ④
### 5.1 实验设置
- 硬件：【GPU / 显存 / 互联】
- 模型：【名称 / 规模 / 精度】
- 负载：【batch / 序列长度 / 并发 / 模式】
- 测量方式：【工具 / 轮次 / 取中位数还是均值】
- 原始数据：【路径或附录】

### 5.2 与判据逐条对应                          ← 不要换指标
- 判据 1【阈值】：实测【数值】→ 达成 / 未达成
- 判据 2【阈值】：实测【数值】→ 达成 / 未达成

### 5.3 闭环到瓶颈                              ← 用 ① 的同一个指标
在【①的同一场景】下，【①的指标】从【原值】改善到【新值】。

### 5.4 基线与消融
- 对比基线：【SOTA 名称】、【自己改之前】、【理论下界】
- 消融：去掉【组件 1】→【指标退化多少】；去掉【组件 2】→【……】

### 5.5 代价与适用区间                          ← 补丁 2，必填
- 代价：【代价指标】=【数值】
- 不划算的场景：【条件】，此时不如【基线】
- 降级策略：【自动回退到什么路径】

### 5.6 失败实验
- 尝试过【方案】，未成功，原因是【机制解释】

## 6 Limitations & Discussion
- 【边界 1：未做的评估，例如 PPL / 下游质量】
- 【边界 2：未验证的规模，例如多卡 / 长上下文】
- 【边界 3：指标本身的局限，例如 exact agreement ≠ 语言质量】

## 7 Conclusion
四段式各一句，不复述数字，只给结论与适用区间。

# 【方案名称】技术方案

## 0 一页纸摘要
- 瓶颈：【一句话 + 一个数字】
- 目标：【一句话 + 判据】；非目标：【一句话】
- 方案：【核心洞察一句话】+【3 个关键机制】
- 预期收益：【指标】从【原值】到【目标值】
- 主要风险：【风险 1】；退路：【对策】

## 1 背景与瓶颈                                 ← ①
- 现状：【系统 / 业务现状】
- 观测数据：【指标】=【数值】，来源【监控 / 压测 / 线上】
- 定位与归因：【瓶颈在哪个环节，为什么】
- 不解决的后果：【业务影响】
- 时效性：为什么现在做 → 【规模 / 成本 / 竞品 / 依赖变化】

## 2 目标与非目标                               ← ②
- 目标：【指标】从【现状】到【目标】，判据【阈值】
- 硬约束：C1【…】C2【…】C3【…】
- 非目标（本方案明确不做）：
  × 【不做 X】—— 理由【…】
  × 【不做 Y】—— 理由【…】
- 难点：【冲突点】

## 3 现有方案评估                               ← Gap
| 方案 | 能解决什么 | 为什么不采用 | 违反哪条约束 |
|---|---|---|---|
| 【A】 | 【…】 | 【…】 | 【C?】 |
| 【B】 | 【…】 | 【…】 | 【C?】 |
| 【C】 | 【…】 | 【…】 | 【C?】 |
- 结论：剩下的方向是【方向】

## 4 技术方案                                   ← ③
### 4.1 架构总览
【分层 / 模块图】
### 4.2 关键机制
- 机制 1【名称】→ 对应约束【C?】，解决【…】
- 机制 2【名称】→ 对应约束【C?】，解决【…】
- 机制 3【名称】→ 对应约束【C?】，解决【…】
### 4.3 取舍
- 放弃【X】，代价【Y】，可接受因为【Z】
- 为什么不直接【更简单做法】：【…】

## 5 预期结果与验证方式                         ← ④ 的 proposal 版
| 判据 | 当前值 | 目标值 | 验证方式 | 验证环境 |
|---|---|---|---|---|
| 【指标 1】 | 【…】 | 【…】 | 【压测脚本 / A-B 实验】 | 【环境】 |
| 【指标 2】 | 【…】 | 【…】 | 【…】 | 【…】 |
- 预期代价：【…】；预期适用区间：【…】；降级策略：【…】

## 6 可行性论证
- 已有基础设施：【可复用的模块 / 能力】
- 前人验证：【论文 / 开源实现 / 内部实验】证明了【哪一步可行】
- 原型数据：【已经跑通的 PoC 及数据】
- 依赖项：【上游团队 / 三方组件 / 硬件】

## 7 风险与对策
| 风险 | 触发条件 | 影响 | 对策 | 退路 |
|---|---|---|---|---|
| 【风险 1】 | 【…】 | 【…】 | 【…】 | 【回退到…】 |
| 【风险 2】 | 【…】 | 【…】 | 【…】 | 【…】 |
| 【风险 3】 | 【…】 | 【…】 | 【…】 | 【…】 |

## 8 里程碑与验收标准
| 阶段 | 交付物 | 验收标准 | 依赖 |
|---|---|---|---|
| M1 | 【…】 | 【可测量的通过条件】 | 【…】 |
| M2 | 【…】 | 【…】 | 【M1】 |
| M3 | 【…】 | 【…】 | 【M2】 |

## 9 资源估算
- 人力：【角色 × 人月】
- 算力：【GPU 卡时 / 存储 / 带宽】
- 时间：【总周期 + 关键路径】

## 附录
- 接口定义 / 数据结构 / 伪代码 / 配置示例

【① 瓶颈】
[ ] 有数字，不是形容词
[ ] 有 profiler / 监控证据
[ ] 有机制解释（能回答「换个场景还成立吗」）
[ ] 瓶颈与第 ③ 段解的是同一件事（不是显存→算力这种错位）

【② 问题】
[ ] 目标可度量，有方向有幅度
[ ] 有约束（否则方法像是随便选的）
[ ] 有非目标（保护自己）
[ ] 判据的阈值写清楚了，且能在 ④ 里逐条对应

【Gap】
[ ] 现有方案分了类
[ ] 每类都说了「为什么不够」
[ ] 每条「不够」都对应②里的一条约束

【③ 方法】
[ ] 核心洞察能用一句话说完
[ ] 每个组件都能指回①②里的某一条
[ ] 取舍写清楚了，并解释了为什么可接受
[ ] 回答了「为什么不直接 ___」

【④ 结果】
[ ] 逐条对应②的判据，没有换指标
[ ] 用①的同一指标做了闭环
[ ] 基线是 SOTA，不只有「我们改之前」
[ ] 有消融
[ ] 有失败实验
[ ] 代价 / 适用区间 / 降级策略都写了
[ ] 硬件、模型、shape、模式、原始数据可复现

【整体】
[ ] 摘要就是四段式各一句，且读得顺
[ ] 按「④→③→②→①→Gap→摘要」的顺序写的
[ ] 能回答审稿人五问：瓶颈真吗 / 为何不用更简单的 / 基线软吗 / 指标对齐吗 / 代价是什么