Paper logical consistency
Skill Lambenthan/paper-discipline-skills/paper-logical-consistency
11 个面向中文科研写作的 Claude Code 纪律 Skill。
npx -y skills add Lambenthan/paper-discipline-skills --skill paper-logical-consistencyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
当用户改动论文里的核心声明(研究问题、核心论点、因果关系、边界条件、假设、关键结论、对已有研究的态度)时, 必须先扫描该声明在全文其他章节的出现位置,列出来让用户核对哪些需要联动修改,再开始动手。 本 Skill 抓的是「论证一致性」(语义级),不是「术语一致性」(机械级)——两者互不替代。 Use when 用户改了核心论点、研究问题、主要结论、方法边界、假设; 或要求重写涉及核心声明的段落;或在交付前要求"检查一下逻辑"。
SKILL.md
6.1 KB, as published. Nobody here has run it
paper-logical-consistency:论证一致性
核心理念
论文不是字符的拼接,是论证链的组合。改一处核心论点,前后章节里同概念的出现都要回查——但人累了、赶时间最容易跳过,AI 改完也不会自己想起。
改一个观点,不是改一段话;改一段话,可能动了整篇论证的脊柱。
触发条件
满足任一条 → 触发:
- 用户改动「研究问题」「核心假设」「主要结论」「因果机制」
- 用户改动方法描述(边界条件 / 关键参数 / 适用范围)
- 用户对已有研究 / 竞品的批评力度变化
- 用户改动数据的解释(不是数据本身)
- 用户提到「我把 §X.X 的 [核心概念] 改了」
- 用户在交付前要求「检查一下逻辑」「看看有没有矛盾」
强制流程
检测到核心声明改动
│
▼
提取本次改动的「核心声明锚点」:
- 研究问题 / 假设的关键短语
- 因果关系的主词谓词宾语
- 方法的边界条件 / 关键参数
- 对已有研究 / 竞品的态度词
│
▼
grep / 全文搜索这些锚点的出现位置
(不只是逐字匹配,还要语义同义词)
│
▼
列出每个出现位置的上下文片段:
- §X.X 第 Y 段:「...原文摘录约 50 字...」
│
▼
告诉用户:「下面这些位置提到了同一概念,
本次改动后是否需要联动修改?」
│
▼
等用户对每处给出 ✅同步改 / ❌保持原样 / ❓我看一下
│
▼
按用户决定执行
完成后由 paper-verify-before-handoff 第 9 项「论证一致性」复核
标准回复模板
你这次改的是 [核心声明摘要]。我扫描了全文,下面 N 处提到了同一概念:
§1.2 第 3 段:「...原文摘录...」 → 这里说的是改前的版本,是否要同步?
§4.5 第 1 段:「...原文摘录...」 → 这里是结论部分,目前还在回答改前的研究问题。
§5.1 引言:「...原文摘录...」 → 这里复述了你的论点,措辞需要重新对齐吗?
请你逐条回复 ✅同步 / ❌保留 / ❓我看一下,再决定下一步。
提取「核心声明锚点」的规则
| 改动类型 | 抓什么作锚点 |
|---|---|
| 研究问题 | 关键短语("是否影响"、"通过 X 影响 Y") |
| 因果机制 | 主词 + 谓词 + 宾语三元组 |
| 方法边界 | 边界条件 / 适用范围 / 关键参数 |
| 主要结论 | 结论的核心断言(强 / 弱 / 条件) |
| 对已有研究态度 | 评价词(支持 / 反对 / 修正 / 扩展) |
| 假设 | 假设的强弱程度词 |
锚点提取后,用 grep + 语义同义词扩展(同一概念的不同表述)做全文扫描。
❌ 反例
用户:「我把 §3.2 的研究问题从『XX 是否影响 YY』改成『XX 通过 ZZ 影响 YY』。」
错误做法:AI 只改了 §3.2 那一段,paper-verify-before-handoff 跑完前 9 项硬清单全 ✅,告诉用户「改完了」。
- §1.4 摘要还说「研究 XX 是否影响 YY」
- §4.5 结论还在讨论「XX → YY 的直接影响」
- §5.3 讨论部分又开始扯 ZZ
- 导师一眼看出:摘要、研究问题、结论自相矛盾
正确做法:扫出 §1.4 / §4.5 / §5.3 三处提到同概念的位置,列出来让用户决定每处是否联动改。
与 paper-protect-terminology 的差别
| paper-protect-terminology | paper-logical-consistency | |
|---|---|---|
| 抓什么 | 术语字符没被改 | 概念语义保持一致 |
| 检查方式 | grep 字符串 | 阅读上下文判断语义 |
| 谁来判断 | AI(用 grep 数数) | 用户(AI 只列疑点) |
| 例 | 「BERT」没被改成「伯特」 | §3.2 说「XX 通过 ZZ 影响 YY」,§4.5 也是这个表述 |
两者互不替代,各管各的事。
Rationalization Table
| 念头 | 现实 |
|---|---|
| "用户只让我改 §3.2,其他章节不该动" | 用户没意识到要联动改,AI 必须主动扫出来给他看 |
| "改一个研究问题,应该不影响其他段落" | 研究问题是论证链的源头,下游全部受影响 |
| "全文搜索太重,差不多就行" | 漏一处就是论证穿帮,导师一句"前后矛盾"全要返工 |
| "只看保护词术语就够" | 术语一致 ≠ 论证一致;术语没换但语义可能已经矛盾 |
| "我能从 grep 结果直接判断哪些要改" | 不能。语义判断必须用户做,AI 只负责"找疑点 + 呈现给用户" |
| "用户最后会自己复审,我不用扫" | 用户复审容易漏,本 Skill 是给 AI 的纪律,不是给用户的提议 |
Red Flags
- 你改了核心论点 / 研究问题 / 主要结论,但没回头扫全文 → 停
- 你只改了一段就准备宣告完成 → 停,先扫全文
- 你打算"等 verify 阶段统一查" → verify 是机械检查,抓不到论证矛盾,必须本 Skill 提前介入
- 你扫出 N 处但凭自己判断哪些要改 → 不行,必须列给用户决定
- 你扫的范围只覆盖本章节 → 不行,至少覆盖摘要 + 引言 + 方法 + 结果 + 结论 + 讨论
配套 skill
- 触发后联动
paper-confirm-before-doing:让用户对联动改动方案确认后再动手 - 完成后由
paper-verify-before-handoff第 9 项「论证一致性」做最后复核
来源
《Claude Code 科研手记》第 5 章「章节写作」、§5.4「导师反馈的处理流程」