paper-logical-consistency

Name: paper-logical-consistency
Author: Lambenthan

19stars0forks

How to install paper-logical-consistency?

lambenthan/paper-discipline-skills/paper-logical-consistency

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-logical-consistency

Installs into the current project.

Summary

当用户改动论文里的核心声明（研究问题、核心论点、因果关系、边界条件、假设、关键结论、对已有研究的态度）时，必须先扫描该声明在全文其他章节的出现位置，列出来让用户核对哪些需要联动修改，再开始动手。本 Skill 抓的是「论证一致性」（语义级），不是「术语一致性」（机械级）——两者互不替代。 Use when 用户改了核心论点、研究问题、主要结论、方法边界、假设；或要求重写涉及核心声明的段落；或在交付前要求"检查一下逻辑"。

Files · 1

View on GitHub

SKILL.md

1	# paper-logical-consistency：论证一致性
2
3	## 核心理念
4
5	论文不是字符的拼接，是论证链的组合。改一处核心论点，前后章节里同概念的出现都要回查——但人累了、赶时间最容易跳过，AI 改完也不会自己想起。
6
7	> 改一个观点，不是改一段话；改一段话，可能动了整篇论证的脊柱。
8
9	---
10
11	## 触发条件
12
13	满足任一条 → 触发：
14
15	- 用户改动「研究问题」「核心假设」「主要结论」「因果机制」
16	- 用户改动方法描述（边界条件 / 关键参数 / 适用范围）
17	- 用户对已有研究 / 竞品的批评力度变化
18	- 用户改动数据的解释（不是数据本身）
19	- 用户提到「我把 §X.X 的 [核心概念] 改了」
20	- 用户在交付前要求「检查一下逻辑」「看看有没有矛盾」
21
22	---
23
24	## 强制流程
25
26	```
27	检测到核心声明改动
28	│
29	▼
30	提取本次改动的「核心声明锚点」：
31	- 研究问题 / 假设的关键短语
32	- 因果关系的主词谓词宾语
33	- 方法的边界条件 / 关键参数
34	- 对已有研究 / 竞品的态度词
35	│
36	▼
37	grep / 全文搜索这些锚点的出现位置
38	（不只是逐字匹配，还要语义同义词）
39	│
40	▼
41	列出每个出现位置的上下文片段：
42	- §X.X 第 Y 段：「...原文摘录约 50 字...」
43	│
44	▼
45	告诉用户：「下面这些位置提到了同一概念，
46	本次改动后是否需要联动修改？」
47	│
48	▼
49	等用户对每处给出 ✅同步改 / ❌保持原样 / ❓我看一下
50	│
51	▼
52	按用户决定执行
53	完成后由 paper-verify-before-handoff 第 9 项「论证一致性」复核
54	```
55
56	---
57
58	## 标准回复模板
59
60	> 你这次改的是 [核心声明摘要]。我扫描了全文，下面 N 处提到了同一概念：
61	>
62	> 1. §1.2 第 3 段：「...原文摘录...」
63	> → 这里说的是改前的版本，是否要同步？
64	>
65	> 2. §4.5 第 1 段：「...原文摘录...」
66	> → 这里是结论部分，目前还在回答改前的研究问题。
67	>
68	> 3. §5.1 引言：「...原文摘录...」
69	> → 这里复述了你的论点，措辞需要重新对齐吗？
70	>
71	> 请你逐条回复 ✅同步 / ❌保留 / ❓我看一下，再决定下一步。
72
73	---
74
75	## 提取「核心声明锚点」的规则
76
77	\| 改动类型 \| 抓什么作锚点 \|
78	\| --- \| --- \|
79	\| 研究问题 \| 关键短语（"是否影响"、"通过 X 影响 Y"） \|
80	\| 因果机制 \| 主词 + 谓词 + 宾语三元组 \|
81	\| 方法边界 \| 边界条件 / 适用范围 / 关键参数 \|
82	\| 主要结论 \| 结论的核心断言（强 / 弱 / 条件） \|
83	\| 对已有研究态度 \| 评价词（支持 / 反对 / 修正 / 扩展） \|
84	\| 假设 \| 假设的强弱程度词 \|
85
86	锚点提取后，用 grep + 语义同义词扩展（同一概念的不同表述）做全文扫描。
87
88	---
89
90	## ❌ 反例
91
92	用户：「我把 §3.2 的研究问题从『XX 是否影响 YY』改成『XX 通过 ZZ 影响 YY』。」
93
94	错误做法：AI 只改了 §3.2 那一段，paper-verify-before-handoff 跑完前 9 项硬清单全 ✅，告诉用户「改完了」。
95
96	- §1.4 摘要还说「研究 XX 是否影响 YY」
97	- §4.5 结论还在讨论「XX → YY 的直接影响」
98	- §5.3 讨论部分又开始扯 ZZ
99	- 导师一眼看出：摘要、研究问题、结论自相矛盾
100
101	正确做法：扫出 §1.4 / §4.5 / §5.3 三处提到同概念的位置，列出来让用户决定每处是否联动改。
102
103	---
104
105	## 与 paper-protect-terminology 的差别
106
107	\| \| paper-protect-terminology \| paper-logical-consistency \|
108	\| --- \| --- \| --- \|
109	\| 抓什么 \| 术语字符没被改 \| 概念语义保持一致 \|
110	\| 检查方式 \| grep 字符串 \| 阅读上下文判断语义 \|
111	\| 谁来判断 \| AI（用 grep 数数） \| 用户（AI 只列疑点） \|
112	\| 例 \| 「BERT」没被改成「伯特」 \| §3.2 说「XX 通过 ZZ 影响 YY」，§4.5 也是这个表述 \|
113
114	两者互不替代，各管各的事。
115
116	---
117
118	## Rationalization Table
119
120	\| 念头 \| 现实 \|
121	\| --- \| --- \|
122	\| "用户只让我改 §3.2，其他章节不该动" \| 用户没意识到要联动改，AI 必须主动扫出来给他看 \|
123	\| "改一个研究问题，应该不影响其他段落" \| 研究问题是论证链的源头，下游全部受影响 \|
124	\| "全文搜索太重，差不多就行" \| 漏一处就是论证穿帮，导师一句"前后矛盾"全要返工 \|
125	\| "只看保护词术语就够" \| 术语一致 ≠ 论证一致；术语没换但语义可能已经矛盾 \|
126	\| "我能从 grep 结果直接判断哪些要改" \| 不能。语义判断必须用户做，AI 只负责"找疑点 + 呈现给用户" \|
127	\| "用户最后会自己复审，我不用扫" \| 用户复审容易漏，本 Skill 是给 AI 的纪律，不是给用户的提议 \|
128
129	---
130
131	## Red Flags
132
133	- 你改了核心论点 / 研究问题 / 主要结论，但没回头扫全文 → 停
134	- 你只改了一段就准备宣告完成 → 停，先扫全文
135	- 你打算"等 verify 阶段统一查" → verify 是机械检查，抓不到论证矛盾，必须本 Skill 提前介入
136	- 你扫出 N 处但凭自己判断哪些要改 → 不行，必须列给用户决定
137	- 你扫的范围只覆盖本章节 → 不行，至少覆盖摘要 + 引言 + 方法 + 结果 + 结论 + 讨论
138
139	---
140
141	## 配套 skill
142
143	- 触发后联动 `paper-confirm-before-doing`：让用户对联动改动方案确认后再动手
144	- 完成后由 `paper-verify-before-handoff` 第 9 项「论证一致性」做最后复核
145
146	---
147
148	## 来源
149
150	《Claude Code 科研手记》第 5 章「章节写作」、§5.4「导师反馈的处理流程」

People who liked this also viewed

6 picks

Type

paper-logical-consistency

19stars0forks

View on GitHub

How to install paper-logical-consistency?

lambenthan/paper-discipline-skills/paper-logical-consistency

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-logical-consistency

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# paper-logical-consistency：论证一致性
2
3	## 核心理念
4
5	论文不是字符的拼接，是论证链的组合。改一处核心论点，前后章节里同概念的出现都要回查——但人累了、赶时间最容易跳过，AI 改完也不会自己想起。
6
7	> 改一个观点，不是改一段话；改一段话，可能动了整篇论证的脊柱。
8
9	---
10
11	## 触发条件
12
13	满足任一条 → 触发：
14
15	- 用户改动「研究问题」「核心假设」「主要结论」「因果机制」
16	- 用户改动方法描述（边界条件 / 关键参数 / 适用范围）
17	- 用户对已有研究 / 竞品的批评力度变化
18	- 用户改动数据的解释（不是数据本身）
19	- 用户提到「我把 §X.X 的 [核心概念] 改了」
20	- 用户在交付前要求「检查一下逻辑」「看看有没有矛盾」
21
22	---
23
24	## 强制流程
25
26	```
27	检测到核心声明改动
28	│
29	▼
30	提取本次改动的「核心声明锚点」：
31	- 研究问题 / 假设的关键短语
32	- 因果关系的主词谓词宾语
33	- 方法的边界条件 / 关键参数
34	- 对已有研究 / 竞品的态度词
35	│
36	▼
37	grep / 全文搜索这些锚点的出现位置
38	（不只是逐字匹配，还要语义同义词）
39	│
40	▼
41	列出每个出现位置的上下文片段：
42	- §X.X 第 Y 段：「...原文摘录约 50 字...」
43	│
44	▼
45	告诉用户：「下面这些位置提到了同一概念，
46	本次改动后是否需要联动修改？」
47	│
48	▼
49	等用户对每处给出 ✅同步改 / ❌保持原样 / ❓我看一下
50	│
51	▼
52	按用户决定执行
53	完成后由 paper-verify-before-handoff 第 9 项「论证一致性」复核
54	```
55
56	---
57
58	## 标准回复模板
59
60	> 你这次改的是 [核心声明摘要]。我扫描了全文，下面 N 处提到了同一概念：
61	>
62	> 1. §1.2 第 3 段：「...原文摘录...」
63	> → 这里说的是改前的版本，是否要同步？
64	>
65	> 2. §4.5 第 1 段：「...原文摘录...」
66	> → 这里是结论部分，目前还在回答改前的研究问题。
67	>
68	> 3. §5.1 引言：「...原文摘录...」
69	> → 这里复述了你的论点，措辞需要重新对齐吗？
70	>
71	> 请你逐条回复 ✅同步 / ❌保留 / ❓我看一下，再决定下一步。
72
73	---
74
75	## 提取「核心声明锚点」的规则
76
77	\| 改动类型 \| 抓什么作锚点 \|
78	\| --- \| --- \|
79	\| 研究问题 \| 关键短语（"是否影响"、"通过 X 影响 Y"） \|
80	\| 因果机制 \| 主词 + 谓词 + 宾语三元组 \|
81	\| 方法边界 \| 边界条件 / 适用范围 / 关键参数 \|
82	\| 主要结论 \| 结论的核心断言（强 / 弱 / 条件） \|
83	\| 对已有研究态度 \| 评价词（支持 / 反对 / 修正 / 扩展） \|
84	\| 假设 \| 假设的强弱程度词 \|
85
86	锚点提取后，用 grep + 语义同义词扩展（同一概念的不同表述）做全文扫描。
87
88	---
89
90	## ❌ 反例
91
92	用户：「我把 §3.2 的研究问题从『XX 是否影响 YY』改成『XX 通过 ZZ 影响 YY』。」
93
94	错误做法：AI 只改了 §3.2 那一段，paper-verify-before-handoff 跑完前 9 项硬清单全 ✅，告诉用户「改完了」。
95
96	- §1.4 摘要还说「研究 XX 是否影响 YY」
97	- §4.5 结论还在讨论「XX → YY 的直接影响」
98	- §5.3 讨论部分又开始扯 ZZ
99	- 导师一眼看出：摘要、研究问题、结论自相矛盾
100
101	正确做法：扫出 §1.4 / §4.5 / §5.3 三处提到同概念的位置，列出来让用户决定每处是否联动改。
102
103	---
104
105	## 与 paper-protect-terminology 的差别
106
107	\| \| paper-protect-terminology \| paper-logical-consistency \|
108	\| --- \| --- \| --- \|
109	\| 抓什么 \| 术语字符没被改 \| 概念语义保持一致 \|
110	\| 检查方式 \| grep 字符串 \| 阅读上下文判断语义 \|
111	\| 谁来判断 \| AI（用 grep 数数） \| 用户（AI 只列疑点） \|
112	\| 例 \| 「BERT」没被改成「伯特」 \| §3.2 说「XX 通过 ZZ 影响 YY」，§4.5 也是这个表述 \|
113
114	两者互不替代，各管各的事。
115
116	---
117
118	## Rationalization Table
119
120	\| 念头 \| 现实 \|
121	\| --- \| --- \|
122	\| "用户只让我改 §3.2，其他章节不该动" \| 用户没意识到要联动改，AI 必须主动扫出来给他看 \|
123	\| "改一个研究问题，应该不影响其他段落" \| 研究问题是论证链的源头，下游全部受影响 \|
124	\| "全文搜索太重，差不多就行" \| 漏一处就是论证穿帮，导师一句"前后矛盾"全要返工 \|
125	\| "只看保护词术语就够" \| 术语一致 ≠ 论证一致；术语没换但语义可能已经矛盾 \|
126	\| "我能从 grep 结果直接判断哪些要改" \| 不能。语义判断必须用户做，AI 只负责"找疑点 + 呈现给用户" \|
127	\| "用户最后会自己复审，我不用扫" \| 用户复审容易漏，本 Skill 是给 AI 的纪律，不是给用户的提议 \|
128
129	---
130
131	## Red Flags
132
133	- 你改了核心论点 / 研究问题 / 主要结论，但没回头扫全文 → 停
134	- 你只改了一段就准备宣告完成 → 停，先扫全文
135	- 你打算"等 verify 阶段统一查" → verify 是机械检查，抓不到论证矛盾，必须本 Skill 提前介入
136	- 你扫出 N 处但凭自己判断哪些要改 → 不行，必须列给用户决定
137	- 你扫的范围只覆盖本章节 → 不行，至少覆盖摘要 + 引言 + 方法 + 结果 + 结论 + 讨论
138
139	---
140
141	## 配套 skill
142
143	- 触发后联动 `paper-confirm-before-doing`：让用户对联动改动方案确认后再动手
144	- 完成后由 `paper-verify-before-handoff` 第 9 项「论证一致性」做最后复核
145
146	---
147
148	## 来源
149
150	《Claude Code 科研手记》第 5 章「章节写作」、§5.4「导师反馈的处理流程」

People who liked this also viewed

6 picks

Type