菜单
论文写作中遇到任何模糊指令（改、整理、润色、重写、找出、统一、清理、看看、处理一下…）， 在调用任何写文件 / 编辑文件 / 批量操作工具之前，必须先用一段话向用户陈述 「我打算怎么做、改哪里、不改哪里」，并明确等待用户确认后再动手。 Use when 用户对论文 / 章节 / 段落 / 文献 / 图表 / 参考文献给出宽泛指令、 未指定具体范围或方法、未限定「只改 X 不改 Y」等边界。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when designing, restructuring, or auditing manuscript figures and you need to define one main claim per figure, assign panel roles, align legends with the text, or decide what belongs in main figures versus supplement.
Use when checking manuscript citations, bibliography hygiene, DOI or PMID completeness, placeholder references, or BibTeX consistency before submission or revision.
Use when acting as a journal or grant reviewer and writing formal reviewer-side evaluations focused on methodology, statistics, reporting standards, reproducibility, and constructive feedback.
Workflow 3: Full paper writing pipeline. Orchestrates paper-plan → paper-figure → figure-spec/paper-illustration/mermaid-diagram → paper-write → paper-compile → auto-paper-improvement-loop to go from a narrative report to a polished PDF. At `— effort: max | beast` (or explicit `— assurance: submission`), Phase 6 gates the Final Report on `tools/verify_paper_audits.sh`; the PDF is labelled `submission-ready` only when the external verifier is green. Use when user says "写论文全流程", "write paper pipeline", "从报告到PDF", "paper writing", or wants the complete paper generation workflow.
Polish, restructure, or translate academic prose into Nature-leaning English using the paper-architecture and writing-strategy principles from Scientific English Writing & Communication, with phrase-level support from Academic Phrasebank. Use whenever the user asks to polish a manuscript paragraph, abstract, introduction, results, discussion, conclusion, title, methods section, or Chinese academic draft for publication-quality English.
Use when writing or revising scientific manuscripts, abstracts, figures, or references for journal submission and you need full-paragraph prose, scientific structure, citation-style guidance, or reporting-guideline support.
| name | paper-confirm-before-doing |
| description | 论文写作中遇到任何模糊指令（改、整理、润色、重写、找出、统一、清理、看看、处理一下…）， 在调用任何写文件 / 编辑文件 / 批量操作工具之前，必须先用一段话向用户陈述 「我打算怎么做、改哪里、不改哪里」，并明确等待用户确认后再动手。 Use when 用户对论文 / 章节 / 段落 / 文献 / 图表 / 参考文献给出宽泛指令、 未指定具体范围或方法、未限定「只改 X 不改 Y」等边界。 |
模糊任务最贵的不是执行成本，是做完发现不对再撤销的代价。 口头一句确认 = 30 秒；写完发现跑偏要回滚 = 半小时起。
你的 AI 越能干，越要在动手前停下来对一次表。
用户的请求包含以下模式：
只要命中任意一条，立刻进入"先确认"模式。 不要因为任务看起来小就跳过——书里的翻车案例 80% 是从"小活儿"开始的。
用户给出模糊任务
│
▼
立即停下，禁止调用任何 Edit / Write / Bash 写操作
│
▼
在回答里写出四件事：
1. 我理解的任务边界（改哪里、不改哪里）
2. 我打算用的方法（按什么标准、保留与删除原则）
3. 一个最小样本（先改一段示例 / 一节 / 列一个示意）
4. 显式问句：「方案行的话，我就推全文。可以吗？」
│
▼
明确等待用户回复
│
▼
用户确认 → 按方案执行
用户调整 → 改方案后重新确认（不是改方案后直接做）
我理解的任务是：[具体范围]。 准备这样做：[方法、标准、保留与删除原则]。 不会动的部分：[显式列出]。 先给你一个小样本：[一段 / 一节 / 一处示意]。 你看方案行的话，我就按这个推全文。可以吗？
用户：「帮我把第三章润色一下。」
错误做法：直接调用 Edit 改了 1500 字，结果发现：
正确做法：先回复
我准备按学术正式度统一术语、压缩冗余、保留你原文的段落结构和小标题。 不会动的：图表说明、引文原文、术语缩写表。 先改 §3.2.1 第一段给你看效果，确认后推全章——可以吗？
| 念头 | 现实 |
|---|---|
| "用户语气很急，先做了再说" | 急的反义词不是快做，是少返工 |
| "这种小活儿不用确认" | 没有不用确认的活儿，只有还没翻车的活儿 |
| "用户上次也是这种任务，我知道他要啥" | 上次不是这次，章节不是同一章 |
| "我先做一遍，他不满意再改" | "再改"在 AI 时代是从头来过，不是局部调整 |
| "确认太啰嗦了，影响体验" | 改错了再撤销才影响体验 |
| "我理解很到位，不会跑偏" | 你理解到位 = 你能用一句话说清——那就说出来等他点头 |
| "用户已经发了三次类似任务了" | 三次类似 ≠ 第四次相同 |
只有以下三种情形可以直接动手：
任何不属于以上三种的修改请求 = 必须确认。
《Claude Code 科研手记》§3.2「先确认方案，再动手」