84 lines
4.9 KiB
Markdown
84 lines
4.9 KiB
Markdown
# arXiv 提交边栏戳为什么能自动删除
|
||
|
||
## 1. 可观察的问题
|
||
|
||
部分 arXiv 论文转换为 Markdown 后，会把提交页边栏中的编号、分类和日期留下来，形成一整行独立文字。它不是
|
||
论文正文，却会进入后续分块、检索和对比。与此同时，论文参考文献也可能包含 `arXiv:`；只要见到这个子串就删行，
|
||
会损坏合法引用。
|
||
|
||
当前组件只处理前一种格式固定的独立行。它的决策来自已批准的
|
||
[`0004-arxiv-submission-stamp-component.md`](../design/0004-arxiv-submission-stamp-component.md)，项目范围编号为 H1。
|
||
精确模式、类名和返回对象以
|
||
[`arxiv_submission_stamp.py`](../../src/mdpolish/components/arxiv_submission_stamp.py) 及其
|
||
[`测试`](../../tests/test_arxiv_submission_stamp.py) 为准。
|
||
|
||
## 2. 当前识别边界
|
||
|
||
组件逐个读取物理行，只在整行同时具有以下结构时提出删除：
|
||
|
||
```text
|
||
arXiv:<新版数字编号和版本> [<ASCII 分类>] <日> <英文月份缩写> <四位年份>
|
||
```
|
||
|
||
首尾空格、列表或引用前缀、缺少版本、旧式编号、错误月份以及句子中的 `arXiv:` 都不会命中。组件没有参数，
|
||
调用方不能传入更宽松的正则表达式改变同一版本的语义。
|
||
|
||
当前版本有意不解析 Markdown 块结构。围栏代码、HTML 注释或其他块中如果存在一行完整目标文字，同样会被删除。
|
||
这是 `0004` 明确接受的代价，不是实现遗漏。以后出现必须保留的真实反例时，需要重新评审识别边界并更新组件版本。
|
||
|
||
## 3. 删除如何保持原文边界
|
||
|
||
每个命中行产生一个候选修改和一个删除型文本编辑。删除范围包含该行自己的 `\n`、`\r\n` 或单独 `\r`；
|
||
没有行尾的末行只删除文字，不拿走前一行已有的行尾。
|
||
|
||
| 输入位置 | 当前行为 |
|
||
| --- | --- |
|
||
| 首行且有行尾 | 连同行尾删除，后续正文成为首行 |
|
||
| 文档中间 | 连同目标行自己的行尾删除，前后内容保持两行 |
|
||
| 末行且没有行尾 | 只删除目标文字，保留前一行原有行尾 |
|
||
| 多个目标行 | 每行一个候选，按原文顺序记录，作为一个组件批次原子应用 |
|
||
|
||
组件不整理空行、不统一换行符，也不改变未命中的字符。候选修改绑定当前快照哈希和准确原文，仍由公共修改执行器
|
||
验证和应用；组件本身没有文件读写或独立 `transform()`。
|
||
|
||
## 4. 审计与稳定性
|
||
|
||
组件标识为 `paper.arxiv_submission_stamp`，版本为 `1.0.0`，参数为空。每条实际删除记录固定理由，并保留删除原文、
|
||
原始范围、组件位置以及批次修改前后的哈希。
|
||
|
||
删除完成后目标行已经不存在。流水线最终复查不应再得到候选修改；把成功输出再次交给同一组件，也应保持原文不变
|
||
且产生零条实际改动。
|
||
|
||
## 5. 已完成验证
|
||
|
||
合成测试覆盖严格匹配、反向引用、首行/中间/末行、三种行尾、多个命中、围栏中仍删除、审计字段、确定性和
|
||
第二次运行零修改。测试只使用短小的虚构字符串，不含真实论文片段。
|
||
|
||
2026-08-22 先对本地 5 份 ClinDB-ReviewBench Markdown 做了只读、纯内存复核：
|
||
|
||
| 复核项 | 结果 |
|
||
| --- | --- |
|
||
| 输入范围 | dmp、jama、ejhf、sim、springer 各 1 份，共 5 份 |
|
||
| 实际删除 | sim 1 行、springer 1 行，其余 0 行，共 2 行 |
|
||
| 合法反向样例 | springer 的 2 处 `arXiv preprint arXiv:` 修改前后均保留 |
|
||
| 第二次运行 | 5 份合计 0 条修改 |
|
||
| 源文件复读 | 5/5 与处理前内存内容一致，没有回写 |
|
||
|
||
这次早期复核没有保存清洗后 Markdown，也没有把真实原文复制进测试、日志或仓库。它是 `0004` 当时验证边界的
|
||
历史事实。
|
||
|
||
`0005` 批准本地产物机制后，同日又完成一次保存型实验：5 份文档全部为 `success`，仍然只修改 sim 和 springer
|
||
各一处；输出哈希全部匹配，输入运行前后字节不变，Springer 两处合法引用仍保留。产物位于
|
||
`artifacts/2026-08-22/runs/clindb-arxiv-stamp-artifacts-v1/`，只在本机保留并受 Git 忽略。具体产物结构和验证结果见
|
||
[`local-experiment-artifacts.md`](local-experiment-artifacts.md)。安装、静态检查和完整测试命令仍只在根目录
|
||
[`README.md`](../../README.md#当前可用检查) 维护。
|
||
|
||
## 6. 剩余边界
|
||
|
||
这个组件最初证明了第一条严格删除规则能够在公共核心上闭环。此后 ClinDB 第一批另外 7 个组件已经按 `0006` 实现，
|
||
当前完整组合见 [`clindb-first-batch-components.md`](clindb-first-batch-components.md)。这仍不表示论文内容问题全部解决；
|
||
通用文件接口、profile、公共 CLI、图片资产和通用批处理仍不存在。
|
||
|
||
如果出现新的提交戳格式，默认行为是保留。必须先补充真实证据、反向样例和 design，再决定是否放宽模式，不能为了
|
||
提高命中数量直接修改正则表达式。
|