[w-tong2004]

关联

Closes #85

改了什么

模型从程序编号的日期候选中选择时间。本次调查初筛标注集的 129 条相关通知，补齐常见日期写法，并保留日期内部点号对应的完整原文证据。

• 支持完整四位年份的数字年月日，如 2026-06-30、2026/6/30、2026.6.30，同一日期的分隔符一致，也支持后续时刻。
• 支持「号」与「日」、中文数字的年月日和月份/旬精度，以及「（6月30日）17:00」这样的括号后时刻。
• 中文日期范围沿用省略首端日/号、右端年月继承及跨年规则，非法日期和未解析完整的范围整体失效。
• 编号层复用全文识别结果，保护完整数字日期内部的句点，保留原文、字符偏移、附件顺序和证据。

6.30、6/30、6-30 等短数字月日按普通文字保留，标签、动作、日/号后缀、括号和范围上下文均适用。原文明示的未识别时间通过现有 unresolved_dates 协议交接原文和证据供人工审核。范围与总体设计 §8.2 已按维护者确认的意见同步。范围确认

129 条通知来自 16 个网站，每条通知各发起一次抓取，统一经过共享 Fetcher。同站请求完成时间的最小间隔为 5.061 秒。127 条返回 HTTP 200，其中 119 条有可读正文、8 条正文无可读文字，另有 1 条 404 和 1 条 410。调查时对 6 页使用本地脚本读取 gp-article 正文容器。

复核确认的缺口	出现次数	涉及通知数	完整识别前后
中文数字月份或旬	3	3	0 → 3
中文数字年月日	2	2	0 → 2
括号日期后紧邻时刻	2	2	0 → 2

这 7 处按日期表达式及精度统计，其中 2 处是正文署名日期。13 个短数字候选中，4 个为分数或面积，9 个为列表编号与后续中文月份相邻。完整数字年月日、短数字月日和「号」字日期在本批正文中的真实日期正例均为 0，保留范围内的新增支持用合成回归验证。

表格跨行的 39 个时刻、同日第二段区间的 2 个时刻，继续按同一行表达式边界保留原文。调查结果

怎么验证的

• crawler/./check.sh 通过，生成类型一致性、Ruff 格式和 lint、Pyright 严格类型检查及 389 项测试全部通过。
• web/pnpm check 通过，16 个测试文件、100 项测试全部通过。数据库迁移、seed、数据库类型校验、OpenAPI 一致性检查、生产构建及 34 份静态资源压缩校验通过。
• 日期解析和编号回归覆盖完整年月日、中文日期、日/号、括号后时刻、单数字日与时刻边界、无效日期、跨年、版本号、URL/邮箱和字符偏移。短数字变体验证按普通文字保留。
• 正常抽取入口使用固定响应，验证未识别短数字时间可交接到 unresolved_dates，原文及附件证据准确还原，对应时间字段保持空值。
• 同一份缓存与发布日期证据上，最新 main 的 437 个匹配变为 442 个，七页发生预期变化。除两处升级到分钟精度外，其余原有匹配一致。442 个匹配的原文偏移和证据引用均通过核对，七个真实案例的时间值符合预期。
• git diff --check 通过。测试使用合成数据、固定响应和本地数据库，缓存复算使用本地保存的正文。

影响

影响抓取节点的日期候选识别和编号分句，复用 DateMatch、TimeValue、原文证据和现有未识别时间协议。接口、MCP 工具和表结构无改动。

调查正文、原始响应和取证材料保存在本地。提交内容为解析与编号代码、合成测试和设计文档，一次性调查脚本已清理。

[JunieXD]

感谢！短数字日期按上次说的不认了，要保留的写法也都做全了：完整年份的数字日期、6月30号、中文数字的年月日和旬、括号里的日期后面紧跟时刻。6月1日-6月14号 这类原有用例因为「号」能认了，改成 31号 继续测非法的右端，行为变了的测试也照实改了。我们拉到本地跑了 ./check.sh，389 个测试全部通过。

剩下的问题集中在一处：数字日期防了很多正文里没出现过的写法，代码和测试都因此多出不少。

必须改

1. 数字日期去掉空格、版本号和分隔符混用这几层防御：调查的 119 条正文里，完整年份的数字日期一次都没出现，2027. 6. 30、版本2027.6.30、v1.2027.6.30、2027/6-30 这些就更没有了。AGENTS.md「只在边界校验」要求不为想象中的情况加检查；而且就算把版本号认成了日期，也只是多一个候选编号，模型要选中它才会用上。改成：

   • _NUMERIC_DATE 中间不带空格，三种分隔符分开写，混用的自然匹配不上：

     _NUMERIC_DATE = (
         r"(?<![A-Za-z0-9/])[0-9]{4}(?:-[0-9]{1,2}-|/[0-9]{1,2}/|\.[0-9]{1,2}\.)[0-9]{1,2}"
         r"(?![0-9年月]|[./][0-9])"
     )

   • _point 里把数字日期换成「年月日」的那段正则也去掉 [ \t]*，「Mixed numeric date separators」这个检查删掉。
   • 删掉 _numeric_date_context，find_dates 改回 for match in _EXPRESSION.finditer(text):。
   • parse/indexing.py 整个退回 main 的写法：分句只在「.」后面跟着空白时才断开（_BREAK），不带空格的 2026.6.30 本来就不会被切开，全文识别一次、保护日期里的句点这套改动就不需要了。

   我们在本地按上面试改过：失败的只有测这几种写法的 17 个测试，其余 372 个都通过，中文数字、括号加时刻、编号列表开头的日期都不受影响。

2. 测试删到同一个行为只测一次：这次测试从 242 个增加到 389 个，很多是同一个行为在几层重复测。

   • 随第 1 条一起删：test_unrelated_numeric_expressions_are_not_promoted_to_dates 里版本号的用例（Python 3.14、一二三月、一二六月一日 留着）、test_rejected_numeric_candidates_do_not_hide_a_later_date、test_a_version_label_on_the_previous_line_does_not_hide_a_date、其他测试里带空格和分隔符混用的用例，以及 indexing_test.py 新加的全部测试。数字日期在网址里不算日期这一点，可以作为一个例子加进原有的 test_dates_in_addresses_are_excluded_but_anchor_labels_are_kept。
   • 短数字不认，只在 dates_test.py 测，留三四个有代表性的用例就够了（裸的 6.30、带标签的、括号加时刻的、6.1至6.30 这样的范围）。extract_test.py 里新加的三个短数字用例删掉：交到 unresolved_dates 的流程和原文怎么写无关，原来「下周二17点」那个用例已经测了。
   • numbered_test.py 给「选中的截止保留分钟、证据是原文」加的三种写法删掉：证据取的是原文，和日期怎么写无关，各种写法在 dates_test.py 已经测过。
   • test_numbered_lists_can_start_with_a_complete_numeric_date 和 test_numbered_dates_after_sentence_boundaries 是为 _numeric_date_context 防误伤加的，函数删了以后合成一个测试、留一两个用例就行。

3. 总体设计 §8.2 跟着改：

   • 删掉「日期在全文识别一次，编号分句复用这些匹配并保护日期内部的句点，原文和字符位置保留不变。」（实现细节，退回后也不成立了）和「完整数字日期前紧邻版本标识时排除。」
   • 「带标签、动作、日/号后缀、括号或范围上下文时也如此」改成「不论前后写了什么」。
   • 「同一日期的数字分隔符一致」后面补上「中间不带空格」。

建议一起改

• 以后合进 main 和自己的修改分成两个提交：这次 fac9a6c 既是合并提交又带着改动，复审时只能拿整个分支和 main 比，看不出上次之后改了哪里。

说明

• 改完转为待审，或者在这里说一声，我们就复审。推了新提交后 CI 要我们再批准一次才会跑，这是 fork 来的 PR 的正常情况。