| 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]
- [任务 2]
- [任务 3]
一次会话同时做这几件，到后面 AI 的判断会越来越糊。
建议这次只做其中一件，其他的开新会话各自单做。
你想先做哪一件？
❌ 反例
用户：「帮我把第三章润色一下，顺便把参考文献按 GB/T 7714 统一，还有图 3 重新画一下。」
错误做法：依次做完三件事。
- 润色到一半切到引文，回来时忘了术语保护
- 引文做到一半切到画图，引文格式没检查完
- 画图时已经没有上下文带宽看清研究框架
正确做法：「这是 3 件独立的事，建议这次只做润色，引文和画图各开一个新会话——这样每件事的输出质量都最高。先做哪个？」
例外（可以同会话连做）
只有以下三种情况：
- 强依赖：A 的输出是 B 的输入（先确定 §3.2 的术语 → 才能更新引文里这个术语）
- 同一对象的多步骤：同一份文件的 grammar → 术语 → 风格（属于"润色"一件事的内部步骤）
- 5 分钟内的小操作：补一个引用、改一个错别字
Rationalization Table
| 念头 | 现实 |
|---|
| "都开着会话了，多做点更省事" | 省下了开新会话的 30 秒，赔进去 30 分钟的质量损失 |
| "用户既然一起说了，肯定希望一起做" | 用户希望"做完"，不是"一次说完一次做完" |
| "这几件事我看着不冲突" | 不冲突 ≠ 不污染上下文 |
| "我的上下文还没满，能装下" | 上下文质量不是布尔值，是滑变的 |
| "等我做完 A 再问要不要做 B" | 先把所有任务列清再让用户选才是专业 |
| "用户都打了 3 句话过来了，再让他选很啰嗦" | 不让他选，做错了更啰嗦 |
Red Flags
- 用户消息里出现"顺便 / 另外 / 还有 / 再 / 对了" → 停
- 你在做 A 任务时收到 B 任务 → 停
- 你看到任务列表 ≥ 2 项 → 停
- 你想"我都列出来了，干脆都做了" → 不行，必须让用户选
来源
《Claude Code 科研手记》§3.5「一次会话只做一件事」
