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「一次会话只做一件事」