Paper One Session One Task

---
name: paper-one-session-one-task
description: |
  当用户在一次对话里同时提出多个论文写作任务（"顺便也帮我..."、"另外..."、"还有..."），
  必须先把这些任务列出来让用户挑一个，拒绝在同一个会话里串行做完所有事。
  Use when 用户的一条请求里出现两个以上独立的写作 / 修改 / 核查任务，
  或在已经在做 A 任务时临时追加 B 任务。
---

# paper-one-session-one-task：一次会话只做一件事

## 核心理念

每多做一件事，前一件事的上下文就被稀释一分。
Claude Code 的会话越长，决策质量越差——这不是它"懒"，是上下文窗口的物理规律。

> 一个会话搞定 5 件小事 = 5 件事的质量都打了折。
> 5 个会话各自做 1 件事 = 5 件事都干干净净。

---

## 触发条件

用户的请求里出现以下任一信号 → 触发：

- **顺承词**："顺便"、"另外"、"还有"、"再帮我..."、"对了"
- **多动词并列**："改一下第三章**并且**统一参考文献"
- **多目标连接**："改完之后再帮我画个图"
- **会话中追加**：你已经在做任务 A，用户说"对了，你再..."
- **隐式多任务**：「把整个论文检查一遍」（实际是术语 / 引用 / 格式 / 数据 N 件事）

---

## 强制流程

```
检测到多任务
        │
        ▼
立即停下，不开始任何子任务
        │
        ▼
列出所有任务，标号
        │
        ▼
告诉用户：「这看起来是 N 件独立的事。
为了不让它们互相污染上下文，建议这次会话只做其中一件。
你想先做哪一件？其他的我们下次开新会话。」
        │
        ▼
等用户选 → 只做被选中的那件
```

---

## 标准回复模板

> 我看到这里其实是 **N 件事**：
>
> 1. [任务 1]
> 2. [任务 2]
> 3. [任务 3]
>
> 一次会话同时做这几件，到后面 AI 的判断会越来越糊。
> 建议这次只做其中一件，其他的开新会话各自单做。
> 你想先做哪一件？

---

## ❌ 反例

用户：「帮我把第三章润色一下，**顺便**把参考文献按 GB/T 7714 统一，**还有**图 3 重新画一下。」

**错误做法**：依次做完三件事。
- 润色到一半切到引文，回来时忘了术语保护
- 引文做到一半切到画图，引文格式没检查完
- 画图时已经没有上下文带宽看清研究框架

**正确做法**：「这是 3 件独立的事，建议这次只做润色，引文和画图各开一个新会话——这样每件事的输出质量都最高。先做哪个？」

---

## 例外（可以同会话连做）

只有以下三种情况：

1. **强依赖**：A 的输出是 B 的输入（先确定 §3.2 的术语 → 才能更新引文里这个术语）
2. **同一对象的多步骤**：同一份文件的 grammar → 术语 → 风格（属于"润色"一件事的内部步骤）
3. **5 分钟内的小操作**：补一个引用、改一个错别字

---

## Rationalization Table

| 念头 | 现实 |
|---|---|
| "都开着会话了，多做点更省事" | 省下了开新会话的 30 秒，赔进去 30 分钟的质量损失 |
| "用户既然一起说了，肯定希望一起做" | 用户希望"做完"，不是"一次说完一次做完" |
| "这几件事我看着不冲突" | 不冲突 ≠ 不污染上下文 |
| "我的上下文还没满，能装下" | 上下文质量不是布尔值，是滑变的 |
| "等我做完 A 再问要不要做 B" | 先把所有任务列清再让用户选才是专业 |
| "用户都打了 3 句话过来了，再让他选很啰嗦" | 不让他选，做错了更啰嗦 |

---

## Red Flags

- 用户消息里出现"顺便 / 另外 / 还有 / 再 / 对了" → 停
- 你在做 A 任务时收到 B 任务 → 停
- 你看到任务列表 ≥ 2 项 → 停
- 你想"我都列出来了，干脆都做了" → 不行，必须让用户选

---

## 来源

《Claude Code 科研手记》§3.5「一次会话只做一件事」