ppw:logic

目的

此 Skill 会读取完整的学术论文，并核查各章节之间的逻辑一致性。它会识别四类问题——论证链缺口（AC-）、缺乏依据的论断（UC-）、术语不一致（TI-）和数字矛盾（NC-），并生成一份双语报告，分为两部分。第 1 部分以「论证链视图」表格列出各章节的主要论点，展示从引言到结论的论点如何衔接（或未能衔接）。第 2 部分对识别出的所有问题进行分类，并为每个问题提供问题描述、影响说明和一句话的方向性建议，每项内容后附有中文翻译。此 Skill 不会改写文本，只负责识别问题并提出建议。

核心提示词

来源：awesome-ai-research-writing — 逻辑检查

# Role
你是一位负责论文终稿校对的学术助手。你的任务是进行"红线审查"，确保论文没有致命错误。

# Task
请对我提供的【英文 LaTeX 代码片段】进行最后的一致性与逻辑核对。

# Constraints
1. 审查阈值（高容忍度）：
   - 默认假设：请预设当前的草稿已经经过了多轮修改与校正，质量较高。
   - 仅报错原则：只有在遇到阻碍读者理解的逻辑断层、引起歧义的术语混乱、或严重的语法错误时才提出意见。
   - 严禁优化：对于"可改可不改"的风格问题、或者仅仅是"换个词听起来更高级"的建议，请直接忽略，不要通过挑刺来体现你的存在感。

2. 审查维度：
   - 致命逻辑：是否存在前后完全矛盾的陈述？
   - 术语一致性：核心概念是否在没有说明的情况下换了名字？
   - 严重语病：是否存在导致句意不清的中式英语（Chinglish）或语法结构错误。

3. 输出格式：
   - 如果没有上述"必须修改"的错误，请直接输出中文：[检测通过，无实质性问题]。
   - 如果有问题，请使用中文分点简要指出，不要长篇大论。

触发条件

用户提出以下请求时激活：

• 检查、验证或查找论文中的逻辑问题
• 检查论文逻辑、验证论证链、帮我找逻辑问题

调用示例：

• “检查我的论文逻辑” / “检查我的论文逻辑”
• “验证各章节之间的论证链” / “验证论文各章节论证是否自洽”
• “查找我草稿中的逻辑矛盾” / “帮我找论文里的逻辑问题”

模式

模式	默认	行为
direct	是	一次性分析全文，不进行中间确认
batch		不支持——跨章节逻辑核查需要完整论文上下文

默认模式： direct。用户提供论文后，会收到一份完整的两部分逻辑报告。

参考资料

必需（始终加载）

逻辑核查会加载 references/bilingual-output.md，以规定中文翻译格式和退出行为。不需要表达模式叶节点，也不会加载反 AI 模式（符合 Reviewer Simulation Skill 惯例）。逻辑核查也与期刊无关；不会加载期刊模板。

叶节点提示

无。

提问策略

开始前询问：

1. 输入格式：文件路径还是粘贴的文本？（如果从用户调用 Skill 的方式中可以明确判断，则跳过）
2. 章节结构：只有在输入中的章节边界不明确时才询问（例如，没有标题的未编号文本）

规则：

• 在 direct 模式下，如果输入充分，则无需事先提问，直接开始。
• 开始分析前，提问不得超过 1 个。
• 如果可用，请使用 Structured Interaction；否则改为提出一个纯文本问题。

工作流

步骤 0：工作流记忆检查

• 读取 .planning/workflow-memory.json。如果文件缺失或为空，则跳至步骤 1。
• 检查最近 1–2 条日志记录是否构成包含 ppw:logic 的已识别模式，且该模式在日志中出现次数 >= 阈值。完整算法请参见 skill-conventions.md > Workflow Memory > Pattern Detection。
• 如果找到模式，通过 AskUserQuestion 提出建议：
  • 问题：“检测到常用流程：[pattern]（已出现 N 次）。是否直接以 direct 模式运行 ppw:logic？”
  • 选项：“Yes, proceed” / “No, continue normally”
• 如果用户接受：将模式设为 direct，跳过提问策略中的问题。
• 如果用户拒绝或 AskUserQuestion 不可用：按正常模式继续。

步骤 1 — 输入检查

• 接受文件路径（Read 工具）或对话中粘贴的文本作为输入。
• 全文检查： 如果输入看起来不完整——仅包含单个章节标题、少于约 500 个单词，或缺少 Methods/Results/Discussion 标记——则拒绝处理，并回复：

  “跨章节核查需要完整论文。请提供完整稿件。”

• 解析章节结构：识别论文中各章节的边界和标题，标题须与原文完全一致。
• 记录工作流： 将 {"skill": "ppw:logic", "ts": "<ISO timestamp>"} 追加到 .planning/workflow-memory.json。如果文件不存在，则创建并写入 []。如果日志长度 >= 50，则删除最旧的记录。

第 2 步 — 分析四类问题

• 以上述 Core Prompt 约束为首要指令集，尤其是高容错阈值和“仅报错原则”。

在构建 Argument Chain View 表格之前，先完成全部四类问题检查。 表格的 Status 列根据此步骤发现的问题确定。

论证链缺口（AC-）

• 梳理各章节的主要研究主张或贡献。
• 检查：引言中的主张是否得到方法设计的支持？
• 检查：结果是否回应了方法中所述的测量指标？
• 检查：讨论中的结论是否由结果推导而来？
• 检查：结论是否与讨论中陈述的发现一致？
• 对每处论证链断裂，创建 Issue AC-N，并标注相关章节。

缺乏依据的主张（UC-）

• 扫描缺少证据、引文或数据引用的肯定性陈述。
• 重点关注引言和讨论中的强烈主张。
• 对每项缺乏依据的主张，创建 Issue UC-N，并引用主张原文。

术语不一致（TI-）

• 跟踪引言中引入的所有技术术语和模型／方法名称。
• 对比各章节中的用法，检查是否存在变化：明确重命名、在论文中途引入缩写，以及正式名称和非正式名称混用。
• 对每处不一致，创建 Issue TI-N，并逐字引用所有不同术语及其所在章节。
• 如果缩写在引言中首次出现时已定义，则不要将其标记为不一致。

数字矛盾（NC-）

• 提取引言中陈述的定量数值（样本量、准确率主张、改进幅度）。
• 与结果和结论中陈述的数值进行比较。
• 对每处差异，创建 Issue NC-N，并引用两处数值及其所在位置。
• 忽略非定量语境中的数字（图表标签、章节编号、脚注标记）。

第 3 步 — 构建 Part 1 Argument Chain View

• 完成 AC- 分析后，根据分析证据构建表格。
• 仅当没有 AC- 问题涉及该章节对时，Status 才为“Connected”。
• 当一个或多个 AC- 问题涉及该章节过渡时，Status 为“Gap”。
• 章节标题必须与论文中的标题完全一致。

第 4 步 — 编写报告

• 退出检查： 整理报告前，扫描用户原始触发提示，检查是否包含以下任一短语（不区分大小写，短语必须完全匹配）：english only、no bilingual、only english、不要中文。如果检测到任一短语：从报告中省略所有 > **[Chinese]** ... 引用块，只输出英文问题条目。如果未检测到：照常加入中文引用块。
• 按照输出约定中的锁定格式，整理为两部分报告。
• 报告先呈现 Part 1 表格（便于阅读），再呈现 Part 2 分类问题。
• 文件输入： 将输出文件名设为 {input_filename_without_ext}_logic.md；使用 Write 工具写入。
• 粘贴文本输入： 在对话中呈现报告。
• 在末尾说明问题数量摘要：“Found N issues: X AC-, Y UC-, Z TI-, W NC-.”

输出约定

输出	格式	条件
logic_report	Markdown 文件 {input_filename_without_ext}_logic.md	文件输入
logic_report	对话输出	粘贴文本输入

锁定的两部分报告格式：

# Logic Verification Report

**Paper:** [title or filename]
**Date:** [date]

## Part 1 — Argument Chain View

| Section | Primary Claim | Connects To | Status |
|---------|--------------|-------------|--------|
| Introduction | [claim] | Methods | Connected / Gap |
| Methods | [claim] | Results | Connected / Gap |
| Results | [claim] | Discussion | Connected / Gap |
| Discussion | [claim] | Conclusion | Connected / Gap |
| Conclusion | [claim] | — | Terminal |

## Part 2 — Categorized Issue List

### Argument Chain Gaps

**Issue AC-1: [Descriptive Title]**
**Section:** [Introduction]
**Problem:** [description]
**Why this matters:** [impact on argument coherence]
**Suggestion:** [one-sentence directional suggestion]
> **[Chinese]** 问题：... 为什么重要：... 建议：...

### Unsupported Claims

**Issue UC-1: [Descriptive Title]**
[same three-part structure + Chinese blockquote]

### Terminology Inconsistencies

**Issue TI-1: [Descriptive Title]**
[same structure — quote exact verbatim terms from the paper]

### Number Contradictions

**Issue NC-1: [Descriptive Title]**
[same structure]

说明：

• Part 1 Argument Chain View 表格仅使用英文（结构性内容，不受语言影响）。
• Part 2 问题条目使用双语：先写英文问题／原因／建议，随后立即添加 > **[Chinese]** ... 引用块。
• 各类别的问题编号连续（AC-1、AC-2、……；UC-1、UC-2、……）。

边界情况

情况	处理方式
输入不完整（只有一个章节或不足 500 个单词）	拒绝：“跨章节验证需要完整论文。请提供完整稿件。”
论文没有 Discussion（例如，Results 后直接是 Conclusion）	根据实际存在的章节调整链条视图；在表格中将缺失章节标注为“N/A”
论文使用中文章节标题	在表格和所有章节引用中原样使用中文标题
某个类别未发现问题	在第 2 部分中保留该类别标题，并注明“No issues identified in this category.”
用户要求 Skill 重写已识别的问题	拒绝：“此 Skill 仅识别问题并提出修改方向。请使用 Polish Skill 进行重写。”
数字出现在非定量语境中（图表标签、章节编号）	忽略；仅关注实证论断和定量结果
缩写在 Introduction 中首次出现时已有定义	不要将其标记为 TI- 不一致；已定义的缩写是有意使用的

后备方案

情况	后备方案
Structured Interaction 不可用	直接模式下继续，不进行预先提问；只有在确实不清楚时，才通过纯文本询问用户提供文件还是粘贴文本
Read 工具失败（文件未找到或无法读取）	请用户改为粘贴论文文本
Write 工具失败	在对话中提供逻辑报告；建议用户手动保存为 _logic.md
论文特别长（超过 20,000 个单词）	提示：“对特别长的稿件进行分析可能不够准确。”如有需要，可提供聚焦特定章节对的选项

示例

最简调用（文件输入）：

用户：“检查我的草稿逻辑：/papers/urban_model.pdf”

询问策略（直接模式——已提供文件路径，无需预先提问）

第 2 步分析发现：AC-1（Introduction→Methods 链条断裂），TI-1（术语变体） 第 3 步根据 AC-1 推导 Status 列

截断输出（urban_model_logic.md）：

# Logic Verification Report

**Paper:** urban_model.pdf
**Date:** 2026-03-12

## Part 1 — Argument Chain View

| Section | Primary Claim | Connects To | Status |
|---------|--------------|-------------|--------|
| Introduction | Urban sprawl prediction framework proposed | Methods | Gap |
| Methods | Gradient boosting model trained on parcel data | Results | Connected |
| Results | 82% accuracy on hold-out set | Discussion | Connected |
| Discussion | Model generalizes to mid-size cities | Conclusion | Connected |
| Conclusion | Framework advances urban planning practice | — | Terminal |

## Part 2 — Categorized Issue List

### Argument Chain Gaps

**Issue AC-1: Introduction Framework Not Reflected in Methods Design**
**Section:** [Introduction], [Methods]
**Problem:** The Introduction proposes a "multi-scale prediction framework," but Methods describes a single-scale gradient boosting model with no multi-scale architecture.
**Why this matters:** Reviewers will note the mismatch between the stated contribution and the actual implementation, undermining the novelty claim.
**Suggestion:** Either update the Introduction to describe a single-scale model, or add a multi-scale component to Methods with justification.
> **[Chinese]** 问题：引言提出"多尺度预测框架"，但方法章节仅描述单尺度梯度提升模型，无多尺度架构。为什么重要：审稿人会注意到声明贡献与实际实现之间的不一致，削弱新颖性声明。建议：修改引言以描述单尺度模型，或在方法中补充多尺度组件并加以说明。

### Unsupported Claims

No issues identified in this category.

### Terminology Inconsistencies

**Issue TI-1: "Urban Sprawl Prediction Framework" vs. "Urban Growth Model"**
**Section:** [Introduction, 第2段], [Methods, 第1段]
**Problem:** The Introduction uses "urban sprawl prediction framework" while Methods refers to the same system as "urban growth model" without an explicit rename or definition.
**Why this matters:** Readers and reviewers may interpret these as different systems, reducing clarity.
**Suggestion:** Choose one term and use it consistently throughout, or introduce the alternative as a defined synonym on first use.
> **[Chinese]** 问题：引言使用"城市蔓延预测框架"，方法章节将同一系统称为"城市增长模型"，未作明确说明。为什么重要：读者和审稿人可能将其理解为不同系统，降低论文清晰度。建议：统一使用一个术语，或在首次出现时将替代名称定义为同义词。

### Number Contradictions

No issues identified in this category.

发现 2 个问题：1 个 AC-、0 个 UC-、1 个 TI-、0 个 NC-。

---

Skill：logic-skill 约定：references/skill-conventions.md