# Logic Check

> 检查论文全文逻辑自洽性和严密性，包括整体结构、实验设计和段落逻辑

- Skill: `xlinsist/logic-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add xlinsist/logic-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/xlinsist/logic-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: xlinsist (https://skillmd.com/u/xlinsist)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/xlinsist/logic-check

---


# Logic Check Skill - 学术论文逻辑检查

专门用于答辩前全面检查学术论文的逻辑自洽性和论证完整性，帮助提前发现评委可能提出的问题。

## 适用场景

- 论文初稿完成后的整体逻辑检查
- 答辩前的全面自查
- 摘要、引言、结论一致性验证
- 实验设计完整性检查
- 论证链条漏洞识别

## 检查清单

### ✓ 整体逻辑结构（重点检查摘要、引言、结论）

**基础逻辑链条完整性：**
- [ ] 背景和动机：研究任务定义清晰（输入输出）、依托方法说明清楚
- [ ] 核心问题：明确列出几个关键问题，每个对应一个贡献点
- [ ] 相关工作：有明确分类、每类有优缺点总结、清晰界定贡献范围和创新点
- [ ] 核心洞察：你的独特观察
- [ ] 解决方案：系统设计/方法实现/创新点
- [ ] 实验结果：做了什么实验，得到什么结果
- [ ] 结论与讨论：结果推出的结论、局限性、对领域的指导意义

**三大核心检查：**
- [ ] **核心问题陈述完整性**：检查是否明确包含以下要素
  - 研究场景（在什么领域/环境）
  - 具体问题（解决什么问题）
  - 输入输出（处理什么数据，产生什么结果）
  - 量化提升（相比基线在什么指标上提升了多少）
- [ ] **摘要-引言-结论一致性**：三者是否覆盖相同要点，表述自洽，无夸大或遗漏
- [ ] **创新点区分度**：明确区分"改了什么"（贡献） vs "用了什么"（工具）
  - 每个创新点说明：为什么要改，改的难点在哪，改后效果如何
  - 直接使用的现有方法应一笔带过

**问题的有效论证：**
- [ ] 每个问题有实验数据或直观图表支撑（揭示问题的性能后果）
- [ ] 问题的严重性是可量化的（性能差距、准确率下降等）
- [ ] 关键论点有 case study 或实验数据支撑
- [ ] 研究内容具体、量化、可拓展，避免歧义和虎头蛇尾

### ✓ 研究内容与方法论证

**完整论证链条（动机→数据→启发→方法→验证）：**
- [ ] **动机（哪里需要改）**：明确指出现有方法的不足
- [ ] **预实验数据支撑**：用实验数据证明"不改的话性能上不去"
  - 性能差距要量化（准确率差多少、时间慢多少倍）
  - 性能后果要反映成可见风险
- [ ] **启发（可以这么改）**：给出改进思路的理论分析或直觉解释
  - 说明为什么这么改是有效的
  - 为什么不能直接用其他场景的方法
- [ ] **方法（具体怎么改）**：详细描述改进方法
  - 提到算法必须有算法流程图或伪代码
  - 提到系统必须有系统框架图
  - 提到关键参数要说明如何设置（超参数、规则设计）
- [ ] **实验验证**：用实验证明改进有效
  - 量化改进效果（提升百分比、倍数等）
  - 效果要能用常识理解（如"从3小时降到30分钟"比"加速6倍"更直观）

### ✓ 实验设计完整性

**实验设置的四大要素（必须明确说明）：**
- [ ] **优化对象**：优化的是算子、模型、端到端系统，还是其他？
- [ ] **比较方法（基线）**：对比什么方法，为什么选这些基线
  - 是否包含领域 SOTA
  - 是否包含直接相关的近期工作
- [ ] **评估指标**：使用什么指标评估性能
  - 是否是该类方法的通用指标
  - 是否与研究目标匹配（如优化推理速度就看延迟，优化准确率就看 accuracy）
- [ ] **实验平台**：实验环境的软硬件配置
  - 硬件平台（CPU/GPU 型号、架构）
  - 软件环境（操作系统、框架版本）
  - 数据集规模和特征

**实验设计结构：**
- [ ] 总体性能评估（与基线的全面对比）
- [ ] 消融实验覆盖所有关键创新点和规则设计
- [ ] 灵敏度分析（关键参数影响）
- [ ] 适用范围和局限性的诚实讨论

**简化与假设：**
- [ ] 做出的简化和假设需满足：其他工作也这么做，或说明在多大程度上有效

### ✓ 表述规范

**术语使用（引入义务 + 一致性）：**
- [ ] 领域通用术语直接用，自创术语需显式定义
- [ ] 缩写首次出现时给出全称（如"LSTM (Long Short-Term Memory)"）
- [ ] 同一概念在全文保持术语一致（不要一会儿叫"特征提取"，一会儿叫"特征抽取"）
- [ ] 非必要场合不引入术语，优先用通俗语言
- [ ] 术语引入时的解释义务：
  - 提到"启发式"→ 说明规则是什么、如何降低搜索开销
  - 提到"算法"→ 给出伪代码或详细流程
  - 提到"知识库"→ 描述规则集合和内容
  - 提到"大模型"→ 说明 prompt 工程和采样策略
  - 提到"系统"→ 给出框架图和典型用例
  - 提到"优化/加速"→ 说明优化什么指标、跟什么比、量级多少

**数据表述（量化 + 常识解释）：**
- [ ] 性能数据同时给出绝对值和相对值（如"从100ms降到50ms，加速2倍"）
- [ ] 数据的绝对值要说明程度（是好是坏）
- [ ] 从常识或领域标准解释数据（如"延迟50ms对实时系统是否可接受"）
- [ ] 数量描述包含参照系（如"50台设备"需说明对应实际规模）
- [ ] 明确提升了什么方面的性能，跟什么相比，量级是多少，得出什么结论

**段落逻辑：**
- [ ] 每段服务于所属小节标题，段首句能概括段落内容
- [ ] 段落间有逻辑联系和过渡句
- [ ] 句子间逻辑连贯（因果/递进/转折关系清晰）
- [ ] 每个论点有充分论据支撑，推理过程完整
- [ ] 删减正确但与文章关系不大的内容

## 检查输出

完成检查后，你将收到按优先级组织的问题清单（每个问题附带具体位置和改进建议）：

**严重问题**（可能被评委质疑）
- 整体逻辑链条缺失或不一致（动机→数据→启发→方法→验证）
- 存在问题缺乏数据/图表支撑
- 核心问题陈述要素不完整（场景、问题、输入输出、量化提升）
- 创新点区分不清（改了什么 vs 用了什么）
- 实验设计四要素缺失（优化对象、比较方法、评估指标、实验平台）
- 术语引入但未解释（尤其是"算法"无伪代码、"系统"无框架图）
- 相关工作未界定贡献范围

**中等问题**（影响论文质量）
- 段落逻辑跳跃
- 论证不充分（论点缺乏数据或案例支撑）
- 性能表述不精准（未说明跟什么比、提升多少）
- 数据缺乏常识性解释，读者不理解这个数据差异有什么现实意义
- 简化假设缺乏论证

**轻微问题**（建议改进）
- 过渡句不够流畅
- 部分内容与主题关联不强
- 术语使用不一致

### 报告呈现要求（新增，必须遵循）

- 不要只给“文件路径/行号”式引用。每条问题都要直接贴出相关原文片段，让用户一眼看到问题。
- 对“具体改写项”优先使用三段式固定模板：原句 / 建议 / 理由。
  - 例子：
    - 原句：被广泛用传感器的设计。
    - 建议：被广泛用于传感器设计。
    - 理由：缺少“于”，搭配错误。

### 分类与计数规则（新增，必须遵循）

- 每条问题只允许归入一个类别，采用主因归类法。
- 若同一问题同时涉及多个维度，只归入“主要影响”的类别，其他影响写入该条的“理由”中说明。
- 统计时不得重复计数，确保分类结果互斥。

## ⚠️ 重要提醒

**不要打分！** AI打分比较主观，用户不会看评分。

只需要在报告结尾做一个**问题汇总**即可，列出：
- 发现的主要问题类型和数量
- 最需要优先修改的内容
- 整体改进建议

## 使用方法

```bash
/logic-check
```

或在对话中：

```
请帮我检查全文的逻辑自洽性
```

针对特定部分：

```
请检查引言的整体逻辑结构
```

## 使用建议

**推荐流程：**
1. 论文初稿完成后先运行 `/logic-check`
2. 根据检查报告修改论文结构和论证
3. 将报告生成在跟源文件同目录下的`logic-check-report.md`；里