--- name: auditing-manuscript-loopholes description: "Use whenever the user asks to 严格审稿、找茬、漏洞审计、pre-submission sanity check，或检查论文当前版本中的图文对应、表格数值、实验阶段与数据划分、方法/公式/实现一致性、可复现性、前后矛盾、结论强度、过度防御措辞、术语与大小写漂移、正式命名、方法提出与命名顺序、跨段指代、叙事断裂、不规范长难句、代码配置腔、工程口语或源码变量直接承担论文定义，以及项目级 AGENTS.md 论文规范的遵守情况。即使用户只提到其中一项，只要目标是论文内部证据审计，也应使用本 skill。默认只读、以当前呈现版本和适用的项目规范为准、给出最小修法，不默认新增实验或扩写；外部新颖性、文献事实和源码审计仅在用户明确纳入范围时执行。" --- # Auditing Manuscript Loopholes ## 目标 以接近苛刻审稿人的标准审查稿件当前版本，但只报告能够定位、能够验证、值得作者处理的问题。 核心原则： > 先确定当前版本和证据来源，再判断漏洞。历史报告、旧 PDF、后期源码默认值和合理猜测都不能自动替代当前证据。 > 每条批评必须说明稿件实际写了什么、证据能支持到哪里、为什么构成风险，以及不引入新事实的最小修法。 > 严格不等于多报问题。撤回误报、保留必要限定、确认当前没有问题，同样是高质量审计结果。 ## 默认边界 除非用户另有明确要求： - 检查主 LaTeX、当前编译 PDF、实际插入的图、表、公式、正文引用和编译呈现。 - 读取并遵守稿件所在作用域内适用的 `AGENTS.md` 或用户明确指定的项目级论文规范；把它们作为审计准则，而不是稿件事实证据。 - 把编译后读者实际看到的版本视为“呈现事实”；源文件与 PDF 冲突时报告版本漂移，而不是暗自选一边。 - 忽略高亮、颜色、下划线、批注等修订样式含义；删除线或删除宏排除的内容不进入语义审查。 - 历史审计报告只作为候选线索和状态记录，不直接当作当前问题证据。 - 不进行外部检索，不判断全球新颖性、发表状态或其他论文事实。 - 不默认核验代码、训练日志或原始预测；只有用户明确纳入范围，或把这些材料作为审计依据交付时才使用。 - 不补造实验、数据、实现、配置、引用、作者意图或图中不可辨认的细节。 - 不默认要求新增实验、指标、图、引用、章节或大段讨论。 - 不默认修改论文、图片或编译产物；用户只要求审稿时，仅输出审计结果。 - 不使用“三位模拟审稿人”或泛化的优缺点报告，直接列出可操作问题。 如果缺少 PDF、图源、表格、日志或代码，只审查能够读取的材料，并在结尾准确说明未核验边界。 ## 审计模式 根据用户授权选择最窄模式： 1. **内部一致性模式（默认）**：只使用稿件、当前 PDF、图表和仓库内直接呈现材料。 2. **实现辅助模式**：用户明确要求或授权核对代码、配置、日志、命令记录时，用这些材料验证论文流程与复现信息。 3. **来源核验模式**：用户明确要求核对比较方法、数据划分、引用或外部事实时，才查原论文或权威来源。 4. **修复复核模式**：用户要求检查修改是否闭合时，对照旧问题和当前版本，更新状态并重新验证呈现。 不要因为仓库里恰好存在源码、旧审计或外部链接就自动扩大审计范围。 ## 工作流程 ### 1. 锁定当前审计快照 在找问题前先确认： - 主稿件文件、编译入口和当前 PDF； - PDF 页数、生成时间和源文件状态； - 实际引用的图像文件、表格、公式、章节和参考文献； - 当前是修订显示版、clean/accepted 版，还是两者都存在； - 是否有历史审计，以及其中各项是 active、resolved、deferred、withdrawn 还是 superseded。 - 当前稿件适用哪些 `AGENTS.md`、期刊模板说明、项目术语表或用户明确给出的写作规范，以及各自作用域。 如果允许编译，优先在临时输出目录生成新 PDF 并与现有 PDF 比较，不覆盖用户的权威产物。若不能编译，明确记录只能核对现有文件。 不得把旧报告中的行号、图号、问题状态直接套到当前版本。先在当前源码和 PDF 中重新定位。 ### 2. 载入项目级规范并建立语言约束表 在语义审计前，先读取从稿件目录到项目根目录范围内实际适用的 `AGENTS.md`，以及用户明确指定的论文规范。遵守其中的排除目录，不为寻找审稿线索主动进入被排除区域。若没有项目级规范，记录“未发现适用的项目级论文规范”，然后继续通用审计。 规则冲突时，采用用户当前明确要求和作用域更具体的项目规则；不要把某个项目的命名习惯推广到无关论文。项目规则属于**审计准则**，不属于 E0--E3 稿件事实证据。报告问题时同时指出当前文字证据与被违反的规则来源。 至少建立以下语言约束表： | 名称/表达 | 要求形式或规则 | 适用上下文 | 首次实质使用 | 首次方案化陈述 | 正式提出/定义位置 | 状态 | |---|---|---|---|---|---|---| 逐项检查： - **先判定身份、语境和句法，再判定大小写**：大小写搜索只能产生候选，不能直接产生问题。对每个候选依次确认：（1）它是普通概念、阶段描述，还是固定专名/官方版本名；（2）它位于普通正文、标题/关键词、章节标题，还是图表标签；（3）它位于句首、句中，还是分号、冒号等不结束句子的标点之后；（4）当前 PDF 实际呈现的是哪个修订分支。缺少任一层判断时，不做全局替换。 - **首次提出或首次定义不自动触发 Title Case**：普通学科、任务、机制或技术类别即使首次出现并在同句定义缩写，仍按句法位置使用 sentence case；句首首词大写只是句法要求，不会把其余普通词升级为专名。例如正文句首可写 `Weakly supervised semantic segmentation (WSSS)`，句中可写 `class activation maps (CAMs)`。只有固定方法名、模块名、数据集名、模型名或其他确立的专名采用其正式大小写。把“先定义、后使用”和“是否为专名”作为两个独立判断。 - **区分正文、标题/关键词与标签语境**：普通正文默认 sentence case；论文标题、关键词和期刊要求的标题式环境按适用模板、项目规范或作者已确认风格处理，不能把正文规则机械扩展过去；图题、表题、表头、列标题和独立配置标签可因标签语境首字母大写，但同类标签内部必须一致。若期刊规则未核验，不凭猜测把关键词改成 sentence case，也不把现有一致风格列为 active 问题。 - **项目专属命名**：精确核对全称、大小写、连字符、缩写和图内标签。对于 DRCFormer 稿件，在没有更具体规则覆盖时，正式全称写作 `Dual-Region Calibration Transformer`，不得写作 `Dual-region Calibration Transformer`；DCC 写作 `Dual-region Consensus Correction`，不得写作 `Dual-Region Consensus Correction`。这些约束只适用于相应名称，不作为一般英文标题大小写规则。 - **正式模块名嵌入 sentence-case 标题时保持原形**：如果标题前半部分是已经定义并由缩写稳定指代的正式模块名，只保留该模块名的固定大小写，后续普通描述仍使用 sentence case。例如 `Structural Noise Suppression and response-distribution statistics`；不要把正式模块名降为 `Structural noise suppression`，也不要把整个标题机械改成 Title Case。 - **官方名称、版本后缀和缩写保持官方形式**：核对数据集、预训练版本、模型、算法及缩写的固定大小写和连字符，例如 DRCFormer 稿件中的 `ImageNet-1K`。不要仅凭局部频次自行“统一”官方名称；需要外部确认时进入来源核验模式。修订单个字符时，不重复或高亮未变化的数字、数学符号和相邻文本。 - **按真实句法处理图注和枚举**：句号通常开启新句；分号不会，因此普通词不会仅因位于分号后而大写。冒号后的大小写取决于适用风格以及后文是否为独立完整句，不能一律处理。区分 `Row 1 ...; rows 2--4 ...` 与 `Row 1 ... . Rows 2--5 ...`，避免对 `Row/Rows` 做脱离上下文的全局替换。 - **阶段指标的句中大小写（DRCFormer 稿件）**：在完整句子的普通正文中，非句首写作 `seed mIoU` 和 `pseudo-mask mIoU`，不得写成句中的 `Seed mIoU`、`Pseudo-mask mIoU`，也不得把后者缩成含义不完整的 `Pseudo mIoU`。句首可以写 `Seed mIoU` 或 `Pseudo-mask mIoU`；图题、表题、表头、列标题和独立配置标签属于标签语境，不因首字母大写自动报错，但同类标签内部仍须保持一致。检查修订显示版时排除 `\sout{}` 中的旧词，只判断当前保留或高亮的新分支，并注意 `\shortstack{Seed\\mIoU}` 等被宏或换行拆开的形式。完成这两项后，顺带核对同一阶段词在普通正文中的派生表达，如句中的 `seed stage` 和 `final segmentation mIoU`；除非它们是正式专名，否则采用相同的句中小写原则。这类问题通常列为 P2。 - **先定义、后使用**：方法、模型、模块、机制、损失函数、数据集别名和缩写，应在第一次实质使用之前或同一句中完成定义。摘要、正文及其他需要独立理解的上下文分别核对，不能以正文已经定义为由豁免摘要中的首次使用。 - **先正式提出/命名、后展开方案**：对论文的核心方法和主要模块，不只检查术语是否已定义，还要跟踪其论述状态：问题/空缺 → 正式提出并命名 → 结构与机制展开 → 后续指代。若 `our framework/method/model/approach` 已在一个自然段中具体介绍组件、数据流、训练策略或作用，下一段才用 `we propose/introduce X` 正式提出和命名，应标记为“先展开、后提出”及重复提案动作。最小修法通常是将提出/命名移到首次方案化陈述之前或同一句，或合并两段。 - **不误报正常预告**：仅笼统地说“我们将解决该问题”、章节路线预告、标题中出现方法名，或在同一句中完成提出与说明，不自动构成时序问题。关键是命名前的文字是否已让一个尚未明示建立身份的作者方案承担实质技术内容。 - **就地完整、自洽**：检查 `check/see/refer to Sec. ... for details`、`examined/discussed later` 等要求读者跳到尚未出现章节才能理解当前论点的表达。若当前论点依赖后文才能成立，最小修法是就地补足已有信息、调整顺序或删除冗余超前提示。 - **避免模糊前指**：检查 `below`、`later` 等依赖后续内容或排版位置的词。紧接枚举时可改为 `the following ...`；定义术语时优先直接使用 `we refer to ... as ...` 等自足表达。不要机械删除所有位置词，只有指向不稳定或理解依赖后文时才报告。 - **检查跨段回指的论述对象**：对段首的 `this observation/finding/limitation/motivation/strategy` 等表达，不只检查语法上能否找到先行词，还要核对前一段的论述功能。若前段已从“观察/局限”转入“我们的解决方案”，随后又以 `Motivated by this observation, we propose ...` 开启正式提案，`this observation` 会在研究空缺与已介绍的设计之间游移。最小修法优先是恢复“局限 → 提出 → 展开”顺序，再把代词改为明确名词；不要只孤立替换代词而保留重复的提案结构。 - **图表浮动例外**：正文先引用随后排版的 Figure 或 Table 是正常 LaTeX 浮动体写法，本身不构成违规；但引用附近的论述仍须自足，不能借图表引用变相要求读者查阅尚未给出的论证。 项目规范违规按实际后果分级，不因“违反规则”四字自动升为 P0。纯命名或放置问题通常是 P2；导致关键对象未定义、读者无法理解当前论点时可为 P1；只有形成确定事实错误、对象身份冲突或当前版本内部矛盾时才列为 P0。 ### 3. 过滤修订痕迹并确定呈现分支 - 忽略 `\hl{}`、颜色、下划线、批注等样式本身。 - 排除 `\sout{}`、`\deleted{}` 或等效删除内容。 - 对 `\revision{old}{new}`、clean-copy 开关等宏，以当前 PDF 实际呈现分支为准。 - 若修订版和 clean 版承担不同用途，分别说明：修订版用于核对修改痕迹，clean 版用于判断最终语义与版面。 - 高亮但仍保留的内容只按文字含义审查，不因高亮提高优先级。 - 对含修订宏的章节标题，同时检查正文标题和 PDF 书签；书签应呈现干净、唯一的新标题，不得暴露删除分支、重复新旧文字或 LaTeX 修订命令。 - 仅在源码中看到目标新词不足以证明修复闭合；还要确认当前 PDF 没有呈现 `old new` 式重复文本。反之，clean PDF 与仍含修订宏的源码用途不同，应准确标明版本关系，不把两者混为同一快照。 ### 4. 建立证据地图 对关键判断标注证据层级： - **E0 直接呈现**：当前 PDF、实际图像、表格、正文、公式和可见版面。 - **E1 内部推导**：由稿件现有数值、公式或算法定义直接计算或逻辑推出的结果。 - **E2 实现辅助**：代码、配置、日志、命令、权重元数据等仓库材料。 - **E3 外部或确认**：原论文、官方文档、作者明确确认等范围外证据。 证据使用规则： - E0 与源码冲突时，报告“当前呈现与源码冲突”。 - E1 可以支持数学或算法必然结果，但不能冒充实际观察到的案例或受控机制证据。 - E2 必须记录版本和来源。后期源码、默认参数或修改过的工作树只能说明该版本的实现，不能单独证明原论文实验设置。 - E3 只在用户授权的模式中使用，并与稿件内部证据分开标记。 - 作者确认可以补充缺失事实，但不能悄悄覆盖仍然冲突的可执行材料；需要说明确认解决了什么、哪些材料仍未闭合。 无法确定证据来源时，把结论降为“高风险歧义”或列入未核验边界，不伪装成确定错误。 ### 5. 建立两张核对矩阵 #### A. 实验阶段—数据—协议矩阵 至少记录： | 主张/结果 | 实验阶段 | 数据集与 split | 指标 | backbone/模型 | 后处理 | 数值来源 | |---|---|---|---|---|---|---| 重点防止： - 把训练图像上的 CAM、Seed、pseudo-mask 评估误写成最终分割 val/test 结果； - 把 val、test、train、trainaug 或不同数据版本混为一谈； - 把作者复现的定性图与原论文报告的定量表写成同一受控实验； - 把不同 refinement、backbone、训练数据或推理协议下的结果写成严格公平比较； - 把同域重新训练后的评估直接称为跨域 `generalization`。 相同数据集名称不代表相同阶段或协议。先闭合阶段和 split，再比较数值。 #### B. 配置—组件矩阵 至少记录： | 名称 | 摘要/引言 | 方法/公式 | 总体图 | 实验设置 | 表/图 | 实现材料 | |---|---|---|---|---|---|---| 用它发现组件改名、流程分支缺失、配置口径漂移、同一符号表示不同网格，以及消融配置无法隔离组件等问题。 ### 6. 按六个维度逐项审计 #### A. 版本、编译与版面语义 检查： - 当前 PDF 是否由当前源码生成，是否存在旧 PDF 或局部构建漂移； - 图片文件名大小写、路径、格式和实际插入资源是否一致； - 浮动表格是否跨入错误章节，书签层级是否破坏结构，图表或公式是否裁切、溢出或缺页； - 图表出现顺序是否让读者误判其所属章节或论据； - 编译日志中的错误、未定义引用和警告是否影响读者实际看到的内容。 不要把所有排版警告都列为论文漏洞。只有它改变呈现、阅读顺序、引用或可信度时才报告。 #### B. 图与正文 检查： - 子图编号、行列名、类别名、图注和正文引用是否一致； - 图内符号、箭头、终点、在线/离线分支和后处理是否与方法定义一致； - 重复列、双列或重复输入是否有必要说明； - 图中展示的案例是否真正承担正文论证； - 正文声称的改善、失败或机制能否从图中直接观察； - 定性结果的来源是否清楚，例如作者复现、原论文截图或当前方法输出。 不要要求正文逐一描述每个面板。只有未解释面板造成歧义、承担关键证据却未分析，或看起来像排版/数据错误时才报告。 #### C. 表格、数值与比较口径 检查： - 正文数值、排名、增益、下降、均值和百分点是否与表格一致； - 缺失值能否支持比较，分母、基线和统计单位是否明确； - 表头是否区分 CAM backbone、segmentation backbone、训练阶段和评估阶段； - 同一方法在不同表中的名称、配置和协议是否一致； - 参数扫描是否真正只改变一个变量，或把 baseline/容量变化混入扫描； - 消融表是否能隔离被声称独立归因的组件； - 来源报告值与本项目复现值是否被清楚区分。 逐项计算可疑差值，不用“约”“稳定”“明显”等词替代核对。 #### D. 方法、公式、流程与可复现性 检查： - 总体图、方法、公式、训练目标、实验设置和结果表是否描述同一流程； - 输入、输出、阈值、尺度、分支、掩码、归一化和后处理是否唯一确定； - 同一符号是否跨分辨率、阶段或对象复用而未说明； - 公式实际约束的对象是否与文字声称的作用一致； - 总损失是否包含图中或正文声称参与训练的分支； - 核心模块是否只有名称而没有可执行定义； - 某个效果是否被另一个同时变化的配置混杂； - 稿件是否把一次性流程写成循环、自训练或因果链。 在实现辅助模式下： - 先确定正式入口、配置覆盖关系和运行路径，再引用默认值； - 区分“当前代码如此”“历史代码如此”“原始实验已由日志确认”； - 不用后期工作树、备份命令或默认参数推翻稿件中有明确来源的实验事实； - 不把未进入正式路径的实验分支、GT 辅助分支或废弃选项带入论文结论。 #### E. 证据强度、创新叙事与必要限定 同时检查过强和过弱两类问题。 过强包括： - 相关变化写成单独因果归因； - 非受控比较写成严格优势； - 优化目标自身下降写成独立机制证据； - 整体指标改善写成特定错误已被解决； - 算法可能后果写成图表已直接观察到的机制； - `fundamentally`、`prove`、`inevitably`、`stable`、`high-fidelity`、`semantic correction` 等措辞超出证据。 过弱包括： - 表内最高或明确受控增益被无根据地降为 `competitive`； - 每个结果后重复加入“并不能证明……”而掩盖可以直接陈述的事实； - 构造正文从未提出的全称命题，再用防御句否认； - 摘要或结论遗漏已经有受控证据支持的核心模块和贡献映射。 保留必要限定，例如跨论文协议差异、指标只测量某个代理量、机制未被隔离。若同一限定在多处重复，优先集中声明一次，再正向陈述直接支持的结果。 #### F. 叙事、术语与长难句 检查： - 问题、模块、指标和结论是否一一对应； - 章节是否重复、顺序倒退、概念提前使用或残留旧版本文字； - 核心方法的正式提出和命名是否晚于首次实质展开，是否出现匿名的 `our framework` 段落之后又重新 `we propose X`； - 相邻段落是否按“局限/观察 → 提出方法 → 展开设计”推进，段首的 `this observation/limitation` 是否有唯一、论述功能相符的回指对象； - 同一概念、指标、模块和图内标签是否切换多套名称； - 项目专属全称、大小写、连字符和缩写是否符合适用规范； - 方法、模型、模块、机制、损失函数、数据集别名和缩写是否在各独立上下文中先定义、后使用； - 当前论点是否依赖尚未出现的章节、`below` 或 `later` 才能成立，同时正确排除正常的 Figure/Table 浮动引用； - 指代、转折、因果和并列关系是否明确； - 失败分析是否区分可见现象与 plausible diagnosis； - 方法、实验设置、图表标题和图注是否把配置语法、代码标识符或工程容器名直接当作学术定义； - 图表是否大量陈列却不承担论证作用。 不要按字数机械判定长难句。只有确实损害理解、逻辑层级或学术表达时才标记，例如： - 多层定语、插入语或括号连续嵌套； - 主语与谓语距离过远； - 一个句子同时承担背景、方法、结果和结论； - `which`、`it`、`this`、`they` 等指代有多个可能对象； - `while`、`whereas`、`thereby`、`respectively` 等连接关系不清； - 并列结构不平行，修饰范围或否定范围含混。 每条长难句必须说明具体结构障碍。不得只写“句子太长，建议拆分”。 **代码配置腔与工程口语是重点检查项。** 对方法流程、实验设置、粗体段落标题、图表标题和图注单独检查： - 原样搬入的配置语法或标识符，例如 `power=0.9`、`logt`、`foo_bar`、命令行 flag，是否解释了它控制的对象、单位、变换和算法语义； - `poly`、`dataloader`、`forward/backward`、`worker` 等实现简称或容器名，是否在论文中改写为准确的算法、训练阶段或数据处理位置； - `independent`、`parallel`、`iterative`、`online`、`offline` 等过程修饰词，是否与实际依赖关系一致，避免一个工程形容词悄然改变算法含义； - 同一设置是否一处使用论文术语、另一处使用代码变量或工程口语，造成配置口径漂移； - 数值虽完整，但读者是否仍须阅读源码才能知道变量代表什么或操作发生在哪里。 不要机械清扫所有技术词。标准算法/框架名称、`batch size`、`learning rate`、GPU、官方接口名，以及复现所需的精确 flag 可以保留；只有当代码形态遮蔽语义、搭配不合学术语域、与其他段落不一致，或修饰词改变流程含义时才报告。最小修法通常是写出学术全称、说明变量语义、把实现容器改为操作阶段，并在确需复现标识符时将其置于解释之后的括号中。 这类问题按后果分级：纯语域或搭配问题通常为 P2；使关键配置或流程必须靠猜测才能复现时为 P1；与公式、图或已明确流程形成确定冲突时才列 P0。 ### 7. 区分观察、推论和机制解释 对涉及原因和机制的候选问题，明确属于哪一层： 1. **直接观察**：图表或当前 PDF 能直接显示。 2. **内部推论**：由公式或算法定义必然推出，例如阈值增加会删去更多边。 3. **机制解释**：对具体语义后果、失败原因或性能来源的合理解释，但未被隔离验证。 正文可以把第 2 层写成算法后果，把第 3 层写成可能机制；不能把它们伪装成第 1 层的实测事实。反过来，也不要因为第 3 层未被隔离就否定第 1 层已经清楚展示的结果。 ### 8. 候选问题五道门 每个候选问题报告前逐项确认： 1. **当前性**：问题在当前源码和当前 PDF 中仍存在吗？ 2. **可定位性**：能否给出具体文件、章节、图表、公式、页码或原句？ 3. **证据性**：判断来自哪个证据层级？事实、推论和猜测是否分开？ 4. **独立性**：它是否只是已有问题的重复、下游症状或已解决/撤回项目？ 5. **可修复性**：是否存在不新增事实的最小修法？ 任一关键门无法通过时，降低优先级、列为待核验候选，或不报告。 对看似严重但最终排除的候选，可在“已核验但未构成问题”中简短记录排除理由。这样后续轮次不会反复误报。 ### 9. 分级与生命周期 严重度： - **P0：确定错误或内部矛盾。** 数字不符、错误引用、当前 PDF/源码冲突、流程或配置明确冲突、证据明确不支持比较等。 - **P1：高风险歧义或论证漏洞。** 读者必须猜测关键流程、复现链不闭合、因果强于证据、图文关系不清、消融归因被混杂等。 - **P2：表达与叙事问题。** 术语切换、必要信息放置不当、防御式重复、代码配置腔、工程口语、确实影响阅读的长难句等。 生命周期： - **active**：当前仍存在，需要处理。 - **deferred**：问题成立，但作者明确暂缓。 - **resolved**：当前版本已修复并完成必要复核。 - **withdrawn**：复核后确认原判断不成立。 - **superseded**：被更准确的新问题或新版本取代。 新审计默认只把 active 问题放入 P0/P1/P2 主清单。历史状态单独汇总，不把 resolved、withdrawn 或 superseded 项重新包装成当前问题。 ## 单条问题格式 ```markdown ### P1-X：问题标题 - **状态**：active - **位置**：文件、行号或章节；PDF 页码；图/表/公式编号 - **当前证据**：准确概括当前文字、数值、视觉呈现或配置 - **审计准则**：稿件内部一致性要求，或适用 `AGENTS.md`/项目规范的具体规则与作用域 - **证据层级**：E0/E1/E2/E3；直接观察/内部推论/机制解释 - **漏洞**：指出内部不一致、歧义或表达风险 - **为什么会被追问**：说明它如何影响理解、复现、比较或结论可信度 - **最小解决方法**：优先删除、收窄、改名、统一口径、补足已有事实、调整顺序或拆句 ``` 如果“为什么会被追问”与“漏洞”完全重复，可以合并。不要用模板化废话扩充篇幅。 ## 输出结构 ```markdown # 稿件现有内容漏洞审计 ## 1. 审计快照、范围与证据边界 ## 2. 结论摘要与当前问题计数 ## 3. P0：确定错误或内部矛盾 ## 4. P1：高风险歧义或论证漏洞 ## 5. P2：表达与叙事问题 ## 6. 已核验但未构成问题 ## 7. 最优先处理顺序 ## 8. 未核验内容与剩余风险 ``` 若某级没有问题，写“未发现”，不要凑项。 “已核验但未构成问题”只记录容易重复误报、对结论有价值的项目，不罗列所有正常内容。 若完整执行审计后 P0、P1、P2 均无 active 问题，且没有影响判断的关键未核验材料，可以明确汇报： > 当前稿件完成度符合本次审计标准，未发现必须继续修改的问题。 该结论只表示通过本 skill 定义的当前版本内部一致性、严谨性、可复现信息和表达审计，不等同于保证录用、全球新颖性成立或不存在范围外问题。 用户要求生成文档时，将结果保存为工作目录下的 Markdown 文件，并返回可点击路径。除非用户明确要求，不要顺手修改论文正文、图片或编译产物。 ## 修复后的复核 只有用户明确要求实施或复核修改时才执行： 1. 记录用户批准处理的具体问题，未批准项保持不动。 2. 对每项修改保留“原问题—最小修法—当前结果”的对应关系。 3. 修订预览遵循当前项目约定：只标记真正变化的词或字符，不为扩大高亮范围而重复未变化的数字、数学符号、引用或相邻文本；标题需要修订标记时，为 PDF 书签提供干净标题。 4. 用户确认生成 clean 版后，保留批准的新文字，移除对应旧文字并解包修订标记；只有在确认不再被其他内容使用时，才移除修订专用宏或宏包。若用户只要求处理修订标记，不改变底层文字、标点、引用、标签或结构。 5. 重新编译到安全位置，核对日志、页数、引用、图表、书签和受影响页面；分页变化时检查溢出到后续页面的内容。 6. 对 clean 版搜索残留删除/高亮宏，并从 PDF 文本中检查旧新文字重复、专名漂移和书签污染。源码与 PDF 均闭合后才能标为 resolved；只改源码未更新 PDF 不算完成。 7. 更新审计文档状态，但保留历史事实；不要把修正前“现状”伪装成当前状态。 ## 常见错误 - 没有锁定当前版本就复用旧报告的行号、图号和问题。 - 未读取当前稿件作用域内的 `AGENTS.md`，或把另一个项目的专属命名规则误用于当前稿件。 - 只在正文检查“先定义、后使用”，遗漏摘要等需要独立理解的上下文。 - 只检查名称或缩写是否定义，没有检查作者方案的论述状态，因而放过“先用 `our framework` 展开设计、后用 `we propose X` 正式命名”的顺序倒退。 - 孤立检查 `this observation` 的最近名词，却不检查前后段的论述功能，导致代词语法可回指但提案逻辑仍然重复或倒置。 - 把正常的 Figure/Table 先引用后浮动排版误报为超前引用，或反过来借图表引用放过依赖后文才能成立的论述。 - 把历史审计、后期源码默认值或工作树改动当作原始实验事实。 - 看到仓库里有代码就擅自扩大审计范围。 - 混淆 CAM/Seed/pseudo-mask 与最终 segmentation 的阶段、split 和协议。 - 只做字面搜索而未区分正文句中、句首与图表标签，误报表头中的 `Seed mIoU`，或漏掉被修订宏、`\shortstack` 和换行拆开的阶段指标大小写。 - 把“首次出现并定义缩写”误当作 Title Case 的理由，因而把普通任务或技术类别错误升级为专名。 - 把正文 sentence-case 规则机械应用到标题、关键词、表头和独立标签，或在未核验期刊规则时擅自改动已有一致的关键词风格。 - 对 `Row/Rows`、阶段指标或模块名做全局替换，忽略句首/句中、句号/分号以及正式专名嵌入普通标题的差异。 - 只检查 LaTeX 源码中的新分支，没有检查编译 PDF 是否仍显示旧新词重复，或 PDF 书签是否暴露删除分支和修订命令。 - 未看实际 PDF 就判断子图、双列、浮动表格、书签或流程图。 - 把算法必然后果、合理机制解释和直接可见事实混为一谈。 - 只看单个公式，忽略联合机制或上下文定义，制造可撤回的假问题。 - 把必要限定一律视为“过度保守”，或重复堆叠限定削弱已支持结果。 - 用“表述不严谨”“逻辑不清”代替具体证据。 - 仅因句子较长就判定为长难句。 - 只检查语法和长句，遗漏配置语法、源码变量、实现容器名或错误过程修饰词直接进入论文；或反过来机械删除所有标准技术术语。 - 把漏洞审计写成常规同行评审并默认要求补实验。 - 审稿后未经授权直接修改稿件。 ## 快速调用示例 ```text 使用 auditing-manuscript-loopholes 审计当前论文。先确认源码、当前 PDF 和历史审计的版本关系，只报告当前仍存在的问题。忽略高亮和删除线， 不要默认新增实验；对机制性结论区分直接观察、算法推论和可能解释， 结果保存为 Markdown。 ```