paper-confirm-before-doing

Name: paper-confirm-before-doing
Author: Lambenthan

19stars0forks

How to install paper-confirm-before-doing?

lambenthan/paper-discipline-skills/paper-confirm-before-doing

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-confirm-before-doing

Installs into the current project.

Summary

论文写作中遇到任何模糊指令（改、整理、润色、重写、找出、统一、清理、看看、处理一下…），在调用任何写文件 / 编辑文件 / 批量操作工具之前，必须先用一段话向用户陈述「我打算怎么做、改哪里、不改哪里」，并明确等待用户确认后再动手。 Use when 用户对论文 / 章节 / 段落 / 文献 / 图表 / 参考文献给出宽泛指令、未指定具体范围或方法、未限定「只改 X 不改 Y」等边界。

Files · 1

View on GitHub

SKILL.md

1	# paper-confirm-before-doing：先确认方案，再动手
2
3	## 核心理念
4
5	模糊任务最贵的不是执行成本，是做完发现不对再撤销的代价。
6	口头一句确认 = 30 秒；写完发现跑偏要回滚 = 半小时起。
7
8	> 你的 AI 越能干，越要在动手前停下来对一次表。
9
10	---
11
12	## 触发条件（命中任一即触发）
13
14	用户的请求包含以下模式：
15
16	- 宽泛动词：改、整理、润色、重写、优化、清理、统一、规范化、处理一下、看一下、帮我搞下
17	- 范围未指定：没说改哪几节、改哪几段、改哪几个文件
18	- 方法未指定：没说按什么标准改、保留什么、删掉什么
19	- 目标读者未指定：没说给导师看 / 给评审看 / 给毕业答辩用
20	- 量词模糊：「全部」「所有」「都」却没明确指哪个集合
21
22	只要命中任意一条，立刻进入"先确认"模式。
23	不要因为任务看起来小就跳过——书里的翻车案例 80% 是从"小活儿"开始的。
24
25	---
26
27	## 强制流程
28
29	```
30	用户给出模糊任务
31	│
32	▼
33	立即停下，禁止调用任何 Edit / Write / Bash 写操作
34	│
35	▼
36	在回答里写出四件事：
37	1. 我理解的任务边界（改哪里、不改哪里）
38	2. 我打算用的方法（按什么标准、保留与删除原则）
39	3. 一个最小样本（先改一段示例 / 一节 / 列一个示意）
40	4. 显式问句：「方案行的话，我就推全文。可以吗？」
41	│
42	▼
43	明确等待用户回复
44	│
45	▼
46	用户确认 → 按方案执行
47	用户调整 → 改方案后重新确认（不是改方案后直接做）
48	```
49
50	---
51
52	## 标准回复模板
53
54	> 我理解的任务是：[具体范围]。
55	> 准备这样做：[方法、标准、保留与删除原则]。
56	> 不会动的部分：[显式列出]。
57	> 先给你一个小样本：[一段 / 一节 / 一处示意]。
58	> 你看方案行的话，我就按这个推全文。可以吗？
59
60	---
61
62	## ❌ 反例（书 §3.2 真实案例）
63
64	用户：「帮我把第三章润色一下。」
65
66	错误做法：直接调用 Edit 改了 1500 字，结果发现：
67	- 把作者特意保留的口语化表达改没了
68	- 把导师让保留的引文改写了
69	- 改完用户要求恢复，但中间结果没存
70
71	正确做法：先回复
72	> 我准备按学术正式度统一术语、压缩冗余、保留你原文的段落结构和小标题。
73	> 不会动的：图表说明、引文原文、术语缩写表。
74	> 先改 §3.2.1 第一段给你看效果，确认后推全章——可以吗？
75
76	---
77
78	## Rationalization Table
79
80	\| 念头 \| 现实 \|
81	\|---\|---\|
82	\| "用户语气很急，先做了再说" \| 急的反义词不是快做，是少返工 \|
83	\| "这种小活儿不用确认" \| 没有不用确认的活儿，只有还没翻车的活儿 \|
84	\| "用户上次也是这种任务，我知道他要啥" \| 上次不是这次，章节不是同一章 \|
85	\| "我先做一遍，他不满意再改" \| "再改"在 AI 时代是从头来过，不是局部调整 \|
86	\| "确认太啰嗦了，影响体验" \| 改错了再撤销才影响体验 \|
87	\| "我理解很到位，不会跑偏" \| 你理解到位 = 你能用一句话说清——那就说出来等他点头 \|
88	\| "用户已经发了三次类似任务了" \| 三次类似 ≠ 第四次相同 \|
89
90	---
91
92	## Red Flags：以下情况 = 立即停止，回去确认
93
94	- 你已经在脑子里规划了改哪几个文件 → 停，先告诉用户
95	- 你正要打开 Edit / Write 工具 → 停，先告诉用户
96	- 你想"先改一点试试" → 停，先把"试试"的方案告诉用户
97	- 你觉得"这显然就该这么改" → 显然 = 用户和你想的一样 = 必须确认
98	- 你打算"边改边问" → 不行。先全部说完，再等回复
99
100	---
101
102	## 例外（极少数情况可以跳过确认）
103
104	只有以下三种情形可以直接动手：
105
106	1. 用户明确写出了完整方案："把这五段里的『论证』改成『论述』，其他不动。"
107	2. 纯查询类：用户问"这段在哪个文件里"、"这个引用对不对"——不修改任何文件
108	3. 回答用户的提问：不涉及写文件 / 跑批量
109
110	任何不属于以上三种的修改请求 = 必须确认。
111
112	---
113
114	## 来源
115
116	《Claude Code 科研手记》§3.2「先确认方案，再动手」

People who liked this also viewed

6 picks

Type

paper-confirm-before-doing

19stars0forks

View on GitHub

How to install paper-confirm-before-doing?

lambenthan/paper-discipline-skills/paper-confirm-before-doing

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-confirm-before-doing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# paper-confirm-before-doing：先确认方案，再动手
2
3	## 核心理念
4
5	模糊任务最贵的不是执行成本，是做完发现不对再撤销的代价。
6	口头一句确认 = 30 秒；写完发现跑偏要回滚 = 半小时起。
7
8	> 你的 AI 越能干，越要在动手前停下来对一次表。
9
10	---
11
12	## 触发条件（命中任一即触发）
13
14	用户的请求包含以下模式：
15
16	- 宽泛动词：改、整理、润色、重写、优化、清理、统一、规范化、处理一下、看一下、帮我搞下
17	- 范围未指定：没说改哪几节、改哪几段、改哪几个文件
18	- 方法未指定：没说按什么标准改、保留什么、删掉什么
19	- 目标读者未指定：没说给导师看 / 给评审看 / 给毕业答辩用
20	- 量词模糊：「全部」「所有」「都」却没明确指哪个集合
21
22	只要命中任意一条，立刻进入"先确认"模式。
23	不要因为任务看起来小就跳过——书里的翻车案例 80% 是从"小活儿"开始的。
24
25	---
26
27	## 强制流程
28
29	```
30	用户给出模糊任务
31	│
32	▼
33	立即停下，禁止调用任何 Edit / Write / Bash 写操作
34	│
35	▼
36	在回答里写出四件事：
37	1. 我理解的任务边界（改哪里、不改哪里）
38	2. 我打算用的方法（按什么标准、保留与删除原则）
39	3. 一个最小样本（先改一段示例 / 一节 / 列一个示意）
40	4. 显式问句：「方案行的话，我就推全文。可以吗？」
41	│
42	▼
43	明确等待用户回复
44	│
45	▼
46	用户确认 → 按方案执行
47	用户调整 → 改方案后重新确认（不是改方案后直接做）
48	```
49
50	---
51
52	## 标准回复模板
53
54	> 我理解的任务是：[具体范围]。
55	> 准备这样做：[方法、标准、保留与删除原则]。
56	> 不会动的部分：[显式列出]。
57	> 先给你一个小样本：[一段 / 一节 / 一处示意]。
58	> 你看方案行的话，我就按这个推全文。可以吗？
59
60	---
61
62	## ❌ 反例（书 §3.2 真实案例）
63
64	用户：「帮我把第三章润色一下。」
65
66	错误做法：直接调用 Edit 改了 1500 字，结果发现：
67	- 把作者特意保留的口语化表达改没了
68	- 把导师让保留的引文改写了
69	- 改完用户要求恢复，但中间结果没存
70
71	正确做法：先回复
72	> 我准备按学术正式度统一术语、压缩冗余、保留你原文的段落结构和小标题。
73	> 不会动的：图表说明、引文原文、术语缩写表。
74	> 先改 §3.2.1 第一段给你看效果，确认后推全章——可以吗？
75
76	---
77
78	## Rationalization Table
79
80	\| 念头 \| 现实 \|
81	\|---\|---\|
82	\| "用户语气很急，先做了再说" \| 急的反义词不是快做，是少返工 \|
83	\| "这种小活儿不用确认" \| 没有不用确认的活儿，只有还没翻车的活儿 \|
84	\| "用户上次也是这种任务，我知道他要啥" \| 上次不是这次，章节不是同一章 \|
85	\| "我先做一遍，他不满意再改" \| "再改"在 AI 时代是从头来过，不是局部调整 \|
86	\| "确认太啰嗦了，影响体验" \| 改错了再撤销才影响体验 \|
87	\| "我理解很到位，不会跑偏" \| 你理解到位 = 你能用一句话说清——那就说出来等他点头 \|
88	\| "用户已经发了三次类似任务了" \| 三次类似 ≠ 第四次相同 \|
89
90	---
91
92	## Red Flags：以下情况 = 立即停止，回去确认
93
94	- 你已经在脑子里规划了改哪几个文件 → 停，先告诉用户
95	- 你正要打开 Edit / Write 工具 → 停，先告诉用户
96	- 你想"先改一点试试" → 停，先把"试试"的方案告诉用户
97	- 你觉得"这显然就该这么改" → 显然 = 用户和你想的一样 = 必须确认
98	- 你打算"边改边问" → 不行。先全部说完，再等回复
99
100	---
101
102	## 例外（极少数情况可以跳过确认）
103
104	只有以下三种情形可以直接动手：
105
106	1. 用户明确写出了完整方案："把这五段里的『论证』改成『论述』，其他不动。"
107	2. 纯查询类：用户问"这段在哪个文件里"、"这个引用对不对"——不修改任何文件
108	3. 回答用户的提问：不涉及写文件 / 跑批量
109
110	任何不属于以上三种的修改请求 = 必须确认。
111
112	---
113
114	## 来源
115
116	《Claude Code 科研手记》§3.2「先确认方案，再动手」

People who liked this also viewed

6 picks

Type