Review Thesis Integrity

博士论文整体性审查

核心规则

单层审查是本技能的基本原子单元。默认每次调用只审查一个层面，不要把所有层面混在一次回答里；只有当用户明确要求全层级审查、多层审查或总览式预检时，才启用多层审查编排模式。

优先用中文学术写作和盲审视角回答。审查重点不是润色句子，而是判断论文是否像一部有统一问题、清晰主线、明确创新和内在递进关系的博士学位论文。

盲审匿名性备注：博士学位论文盲审通常要求隐去作者身份，但允许在论文中陈述博士在读期间的论文发表成果、专利、项目或获奖等成果信息。审查时不要把“成果陈述”本身判为匿名性问题；只有当文本直接暴露作者姓名、已发表论文题名、专利题名，或其他可直接识别作者身份的信息时，才将其列为盲审匿名风险。

审查层级选择

如果用户指定了层面，直接审查对应层面。如果用户没有指定，先根据输入内容推断；仍不明确时，请用户从下列层面中选择一个。

审查流程

1. 明确本次审查层面、输入范围和证据来源。
2. 按对应层面的检查项审查，不要泛泛评价全文。
3. 输出问题时按风险等级排序：
   • P0：可能影响盲审总体判断的重大结构问题。
   • P1：明显削弱论文说服力的重要问题。
   • P2：局部表达、顺序、措辞或一致性问题。
4. 每条问题都给出“问题判断、证据位置、盲审风险、修改方向”。
5. 如果用户提供的是正文片段，可以给出少量示范性改写；如果用户提供的是全文或章节文件，优先给审查结论和修改清单。
6. 结尾给出本层通过判断：通过、基本通过但需修改、未通过。

多层审查编排

当用户明确要求检查多个层面或全部层级时，主 Agent 应作为“多层审查协调者”，把多层任务拆成若干单层审查单元，再汇总为一份最终报告。多层编排的目标是提高覆盖面和一致性，不改变“每个审查单元只负责一个层面”的基本原则。

编排规则：

• 先列出本次需要覆盖的层级集合，如 L0-L11 全部层级，或用户指定的若干层级。
• 为每个层级建立独立审查任务，任务说明必须包含层级代号、审查名称、输入范围、证据来源和本层输出格式。
• 如果当前环境支持子 Agent，且层级之间可以独立审查，优先按“一层一个子 Agent”并行执行；如果层级数量很少、上下文不足或没有可用子 Agent，则由主 Agent 顺序执行，但仍保持逐层隔离。
• 每个子 Agent 或单层审查单元只判断自己负责的层级，不跨层扩展结论；发现跨层问题时可以记录为“需交由协调者汇总判断”。
• 协调者汇总时不得简单拼接各层报告，应消除重复问题、统一风险等级、保留证据位置，并指出不同层级之间互相印证或互相冲突的地方。
• 若不同层级对同一问题给出不同判断，协调者应基于证据范围和盲审风险重新裁定，并在最终报告中说明取舍理由。

推荐的多层最终报告结构：

**多层审查范围**
列出本次覆盖的层级。

**总体结论**
说明论文整体是否具备送审基础，以及最主要的 1-3 个风险。

**跨层风险矩阵**
| 风险主题 | 涉及层级 | 严重程度 | 主要证据 | 总体修改方向 |
|---|---|---|---|---|

**优先修改清单**
按 P0、P1、P2 合并排序，避免同一问题在不同层级重复出现。

**分层审查摘要**
逐层给出通过判断、主要问题和必要证据。

**附录：分层详细报告**
需要时保留各层的完整检查表。

输出格式

使用以下结构：

**本次审查层面**
Lx：审查名称

**总体判断**
一句话说明本层是否通过，以及最大风险是什么。

**主要问题**
1. [P0/P1/P2] 问题标题
   证据：引用或概述具体位置。
   风险：说明盲审专家可能如何理解。
   修改方向：给出可执行修改建议。

**本层检查表**
| 检查项 | 结论 | 说明 |
|---|---|---|

**优先修改顺序**
1. 最先改什么。
2. 其次改什么。
3. 最后检查什么。

L0 成书性底线审查

目标：判断论文是否像一本博士论文，而不是若干小论文的合订本。

检查项：

• 能否用一段话讲清全文总问题、分问题、方法路径和总体贡献。
• 各技术章是否服务于同一总问题。
• 摘要、绪论、章节引言、总结是否互相呼应。
• 论文是否有总技术路线图或等价的结构说明。
• 是否存在某章与题目或主线关系较弱。

典型风险：

• 各章各自成立，但全文主线不成立。
• 总结章只是逐章复述，没有综合贡献。
• 读者读完摘要和绪论后仍不知道论文主要做了什么。

L1 主线统摄审查

目标：检查全文是否由一个总研究问题统摄。

检查项：

• 题目中的核心概念是否在摘要和绪论中被明确定义。
• 总研究问题是否被拆解为若干分问题。
• 每个分问题是否对应一个章节或一组方法。
• 技术路线是否解释“为什么先做这个、再做那个”。
• 总结是否回收到同一主线，而不是另起话题。

修改方向：

• 增加“总问题-分问题-章节任务”的映射段。
• 用同一组关键词贯穿摘要、绪论、章节引言和总结。
• 删除或重写不能支撑主线的游离贡献表述。

L2 摘要入口审查

目标：确保评审读完摘要后能立即明白论文做了什么、为什么做、创新在哪里。

检查项：

• 摘要开头是否先总述全文背景、总目标和总体路线。
• 是否避免直接把三四项工作并列堆放。
• 每项工作的第一句话是否说清“面向什么问题，提出什么方法，解决什么瓶颈”。
• 是否明确写出创新点，而不只是写“设计了系统/提出了架构/进行了实验”。
• 结果是否服务于贡献，而不是孤立罗列数据。
• 摘要结尾是否回到全文价值。

高风险信号：

• 读完摘要后“一头雾水”。
• 摘要像多篇论文摘要的拼接。
• 创新点需要评审自己从细节中猜。

L3 绪论总入口审查

目标：检查绪论是否承担全文共同背景、现状、动机和问题定义的总入口功能。

检查项：

• 是否统一交代全文研究背景，避免各章重复开题。
• 国内外现状是否服务于本文问题，而不是文献堆砌。
• 是否明确指出现有研究不足，并自然引出本文。
• 是否提出清晰的研究目标、关键问题和技术路线。
• 主要工作与创新点是否解释各章在总体路线中的位置。
• 论文组织结构是否说明章节逻辑关系。

修改方向：

• 把各章重复出现的共性背景前移到绪论。
• 将“章节列表式贡献”改为“问题驱动式贡献”。
• 在组织结构部分加入章节之间的递进关系。

L4 综述层审查

目标：检查研究现状是否体现作者的分析、归纳和判断，而不是对国内外工作的简单罗列。

核心链条：

• 为了解决什么问题。
• 已有人开展了什么工作。
• 这些工作得到了什么结果。
• 这些结果还存在什么不足。
• 未解决问题如何引出本文研究内容。

检查项：

• 是否按问题、技术路线、方法类别或发展阶段组织综述，而不是按作者或年份流水账排列。
• 每一类综述开头是否说明该类工作试图解决的核心问题。
• 介绍代表性文献时，是否同时说明其目标、方法、结果和局限。
• 每组文献之后是否有作者自己的比较、归纳或趋势判断。
• 是否明确指出现有研究尚未解决的问题。
• 未解决问题是否自然对应到本文的研究目标、章节安排或创新点。
• 是否避免只写“某某提出了……，某某设计了……，某某实现了……”。
• 是否通过表格、分类图或小结段形成对比维度，如性能、适用范围、安全性、资源开销、可扩展性、部署场景等。
• 引用是否覆盖关键代表性工作，而不是为了堆数量罗列不相关文献。

输出时优先给出“综述逻辑链”诊断表：

高风险信号：

• 综述段落主要由文献名和工作名组成，看不到作者自己的判断。
• 每篇文献单独成句，但文献之间没有分类、比较和综合。
• 只说明已有工作“做了什么”，没有说明“解决了什么、没解决什么”。
• 综述结束后不能自然推出本文为什么需要做。

修改方向：

• 把“文献罗列式综述”改为“问题驱动式综述”。
• 每个小节采用“问题提出-已有路线-代表性结果-不足总结-本文切入”的结构。
• 在综述末尾增加一段面向本文的归纳：现有研究留下了哪些空缺，本文分别如何回应。

L5 分章定位审查

目标：检查每个技术章是否清楚回答“本章解决全文主线中的哪一个分问题”。

检查项：

• 章引言第一段是否说明本章与全文主题的关系。
• 第一或第二句话是否直接点明本章核心问题。
• 是否避免大段重复绪论中的通用背景。
• 是否说明本章方法、贡献和实验验证之间的关系。
• 本章小结是否回到全文主线，而不是只复述细节。

建议句式：

• “针对……瓶颈，本章提出……，用于解决……问题。”
• “在前一章……的基础上，本章进一步面向……，重点解决……。”

L6 章间递进审查

目标：检查章节之间是否存在清楚的递进、扩展或互补关系。

检查项：

• 章节顺序是否有理由。
• 相邻技术章之间是否有承上启下段。
• 技术路线图、组织结构、总结章是否采用一致的递进逻辑。
• 是否说明从特定问题到一般问题、从性能到安全、从核心算子到系统场景等推进关系。
• 是否存在“并列拼接但缺少过渡”的章节。

常用递进模式：

• 从专用到通用。
• 从性能到安全。
• 从算法核心到系统应用。
• 从单一场景到综合场景。
• 从理论/方法到实现/验证。

L7 创新辨识审查

目标：让评审能够准确说出论文的创新点。

检查项：

• 创新点是否前置出现在摘要和绪论中。
• 每个创新点是否对应明确问题。
• 是否区分“完成的工作”和“形成的贡献”。
• 创新是否落在方法、机制、架构、模型、流程或验证体系上。
• 实验是否直接支撑创新点。
• 贡献表述是否可辩护，避免夸大。

不合格表达：

• “本文设计了一种系统，并进行了实验验证。”

更好表达：

• “针对……瓶颈，本文提出……机制，通过……实现……，从而解决……问题。”

L8 证据闭环审查

目标：检查论文声称的贡献是否被实验、图表、对比和分析充分支撑。

检查项：

• 每个主要贡献是否至少有一组直接证据。
• 对比对象是否合理，是否覆盖主流基线或必要消融。
• 指标是否与贡献匹配。
• 图表标题、正文分析和结论是否指向同一论点。
• 是否存在实验很好但没有回扣创新点的问题。
• 是否存在贡献很大但证据不足的问题。

输出时优先列“贡献-证据”映射表。

L9 总结升维审查

目标：检查总结章是否综合提升全文，而不是逐章复述。

检查项：

• 是否先回到总研究问题。
• 是否综合提炼全文方法论或体系贡献。
• 是否把各章贡献放回同一逻辑框架。
• 是否说明论文对学科、工程或应用场景的意义。
• 展望是否从全文局限自然引出，而不是随意罗列未来工作。

修改方向：

• 用“本文围绕……形成了……”统摄全章。
• 把逐章复述改为跨章节综合。
• 将展望与本文未解决的问题对应起来。

L10 成文一致审查

目标：检查全文是否具有统一、成熟、可送审的博士论文成文质量。

检查项：

• 关键术语、缩写、概念定义是否统一。
• 同一贡献在摘要、绪论、章节和总结中是否表述一致。
• 盲审版本中的成果、专利、项目或获奖陈述是否符合匿名要求：可以陈述成果类型、作者排序、发表/授权状态、期刊会议类别等必要信息，但不应直接出现作者姓名、论文题名、专利题名等身份线索。
• 图、表、公式、算法的命名风格是否统一。
• 是否存在大段重复背景。
• 是否存在章节语气、叙述粒度或术语风格明显不同。
• 是否有“论文改写痕迹”，如保留小论文的独立引言结构。

修改方向：

• 建立术语表和贡献表述表。
• 合并重复背景。
• 统一各章的引言、小结和实验分析写法。

L11 跨章节指标一致性审查

目标：检查摘要、绪论、技术章、总结和成果概述中的核心指标是否口径一致，并确认指标能从对应章节的图表、公式、实验数据或正文结论中直接获得或清晰推导。

检查项：

• 是否先列出全文核心指标清单，如性能提升、吞吐率、延迟、面积、功耗、能效、资源开销、安全性检测结果、支持算法数量、端到端加速比等。
• 同一指标在摘要、绪论、章节小结和总结中的数值、单位、有效数字、比较对象和限定条件是否一致。
• 指标表述是否明确区分“最高”“平均”“典型场景”“某算法”“某配置”“相对基线”“归一化结果”。
• 摘要或绪论中的每个关键数值，是否能在对应技术章的表格、图、公式或正文分析中直接找到。
• 若指标不是直接给出，是否能由论文中的原始数据推导，且推导公式、分母分子、基线和单位清楚。
• 是否存在同一实验结果在不同章节被改写为不同口径，如“提升 3.2 倍”“降低 68%”“达到 4.2x”之间缺少换算说明。
• 图表标题、正文分析、章节结论和总结性表述是否指向同一指标含义。
• 是否避免把单个最优实验点写成全文一般结论。

输出时优先给出“核心指标一致性台账”：

高风险信号：

• 摘要、绪论或总结中的亮点指标在技术章中找不到来源。
• 技术章表格给出的是原始数值，但摘要直接写百分比或倍数，且没有推导说明。
• 同一指标在不同位置使用不同单位、不同基线或不同限定条件。
• “最高/平均/端到端/核心算子/系统级”等限定词在跨章节转述时丢失。
• 章节结论只写“显著提升”“有效降低”，但没有回扣具体图表和数值。

修改方向：

• 建立“指标-位置-来源-推导”台账，先统一所有核心指标的标准表述。
• 摘要和绪论只引用能在技术章中直接查到或可复现推导的指标。
• 对推导型指标补充计算公式、基线说明或表下注释。
• 将“最高值”“平均值”“典型配置值”分开表述，避免过度泛化。