[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 原文和证据交接流程。范围确认

调查覆盖 16 个网站，每条通知各经过共享 Fetcher 发起一次抓取。127 条返回 HTTP 200，其中 119 条有可读正文、8 条正文无可读文字；另有 1 条 404 和 1 条 410。调查时对 6 页使用本地脚本读取 gp-article 正文容器。

确认的漏识别或精度缺口	出现次数	涉及通知数
中文数字月份或旬	3	3
中文数字年月日	2	2
括号日期后紧邻时刻	2	2

共 7 处，其中 2 处是正文署名日期。13 个短数字候选中，4 个为分数或面积，9 个为列表编号与后续中文月份相邻。完整数字年月日、短数字月日和「号」字日期在本批正文中的真实正例均为 0，保留格式使用合成测试验证。

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

怎么验证的

• 在 crawler/ 下运行 ./check.sh：生成类型一致性、格式、lint、类型检查和 311 项测试通过。
• 在 web/ 下运行 pnpm check：16 个文件、100 项测试通过。数据库迁移、seed、数据库类型验证、OpenAPI 一致性和生产构建通过。
• 日期测试覆盖保留格式、分钟精度、年份推断、非法日期、范围和原文位置；短数字拒绝识别保留代表用例，数字网址过滤补入原有测试。
• 在相同缓存和发布日期证据下，对照 main（3bf0118）回放 127 份缓存：437 → 442 个匹配，7 页发生预期变化。原先 7 处改进全部保留，全部解析结果与简化前一致，正常编号入口的原文位置和证据核对通过。
• git diff --check 通过。测试使用合成数据、固定响应和隔离的本地数据库；回放使用已保存正文，没有重新请求通知网站。

影响

抓取节点可为上述写法提供日期候选，复用现有分句、编号和未识别时间交接流程。接口、MCP 工具和表结构无改动。

最终差异包括日期解析、对应测试和总体设计 §8.2。调查正文、原始响应和取证材料仅保留在本地，一次性调查脚本未进入仓库。

[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 的正常情况。

[JunieXD]

感谢！上一轮的意见都改到了：数字日期的正则照建议改了，_numeric_date_context 和分句里保护句点的改动都删干净了，indexing.py 回到了 main 的写法；重复的测试删到同一个行为只测一次；§8.2 也跟着改了，这次的提交也和合并分开了。我们把最新的 main 合进来跑了 ./check.sh，335 个测试全部通过。这就合并。