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打分比较主观，用户不会看评分。

只需要在报告结尾做一个问题汇总即可，列出：

• 发现的主要问题类型和数量
• 最需要优先修改的内容
• 整体改进建议

使用方法

/logic-check

或在对话中：

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

针对特定部分：

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

使用建议

推荐流程：

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