政策动态订阅：区分政策发布、生效与申报窗口

技术档案

架构与流程

实现逻辑

问题定义：发布了政策，不等于可以申报

政策文件可能描述长期扶持方向，具体申报批次则由后续通知确定。把两者混为一谈，容易向客户推送“马上可申报”的错误结论。数据模型应分别记录公布时间、生效时间、有效期、申报起止时间，以及申报通知的证据地址。没有申报窗口依据时，明确标为未确认，而不是依据文件日期推算。

采集层：部门、栏目和文件编号构成来源档案

建议从客户关注地区的政府部门和主管机构公开栏目建立来源清单，记录栏目更新时间与采集成功时间。每份文件保留文号、发布主体、原文链接、附件摘要和版本指纹。政策转载用于补充发现，原发布机关页面优先作为证据。解析失败、附件缺页和原文不可访问都应显示为数据质量状态。演示数据使用虚构机构与example.invalid地址，不是可申报政策。

条件层：规则提取与适用性判断分开

AI可辅助把正文整理为地区、行业、企业规模、资质、经营年限等候选字段，但每个关键条件需要对应原文段落。复杂门槛应保留原句供人工复核，不能仅依据摘要下资格结论。演示只实现地区、关键词、排除词和申报开放标记；企业资格核验与复杂条款推理属于待接入能力。规则命中表示值得关注，不代表客户已经满足申报资格。

变更层：修订、废止与截止提醒各有触发条件

同一文件内容变化需要对比版本。废止是政策生命周期变化，不是简单地把旧记录删除。申报延期则是申报通知的窗口变化。生产事件应包含旧值、新值、证据和受影响订阅，向曾经收到该文件的客户补发更新。临近截止提醒必须以已确认的截止时刻为依据，文件没有明确截止时间时不能自行设置。

交付层：把可行动信息和待确认信息分栏

邮件正文可分为已确认窗口、值得关注、变更提醒三部分。每条包含政策主题、适用范围、关键条件、申报状态和原文地址；未确认的事项列出下一步核验动作。技术原型采用matched、review、excluded三态，未确认申报窗口进入review，不进入默认命中邮件。页面提供筛选和邮件预览；生产的栏目采集、审核权限、定时发送与投递回执仍需实现。

参考数据结构

下表是本专题的标准化字段，不是新发布的线上API响应契约。

{
  "id": "policy-1",
  "kind": "policy",
  "source": "fixture",
  "title": "示例数字化改造补助申报通知",
  "text": "面向安徽企业的数字化补助，本期申报窗口已在示例中确认。",
  "region": "安徽",
  "budget": null,
  "status": "published",
  "deadline": "2026-10-30",
  "updated_at": "2026-10-16T08:00:00+08:00",
  "published_at": "2026-10-16T07:30:00+08:00",
  "fetched_at": "2026-10-16T08:05:00+08:00",
  "application_open": true,
  "platform": "示例公开栏目",
  "source_url": "https://example.invalid/policy/1"
}

离线参考代码：三态目标匹配。完整文件和测试见资料包。

def match(record, rule, as_of):
    text = (record['title'] + ' ' + record['text']).casefold()
    reasons = []
    failures = []
    pending = []
    terms = [word for word in rule['keywords'] if word.casefold() in text]
    if not rule['keywords']:
        raise ValueError('At least one keyword is required')
    required = len(rule['keywords']) if rule['mode'] == 'all' else 1
    if len(terms) < required:
        failures.append('keyword')
    else:
        reasons.append('keywords: ' + ', '.join(terms))
    if any(word.casefold() in text for word in rule['exclude']):
        failures.append('excluded')
    if rule['region'] != 'all' and record['region'] != rule['region']:
        failures.append('region')
    if record['status'] in ('withdrawn', 'repealed'):
        failures.append('inactive')
    if record.get('deadline') and date.fromisoformat(record['deadline']) < as_of:
        failures.append('expired')
    minimum = rule.get('minimum_budget', 0)
    if minimum > 0:
        if record.get('budget') is None:
            pending.append('budget_unknown')
        elif record['budget'] < minimum:
            failures.append('budget')
    if record['kind'] == 'policy' and record.get('application_open') is not True:
        pending.append('application_not_confirmed')
    state = 'excluded' if failures else 'review' if pending else 'matched'
    return {'id': record['id'], 'state': state, 'reasons': reasons,
            'failures': failures, 'pending': pending}

复现方式

python -m unittest -v
python monitor.py policy-subscription.json --output output/policy-subscription

在资料包的 examples 目录运行，生成 analysis.json 与 digest.eml。没有真实采集或邮件发送。

页面展示

验收口径与实现边界

• 政策关键词命中但申报未确认时进入待复核
• 废止文件不进入新推荐结果
• 改变地区后结果与命中原因同步变化
• 邮件预览不发送实际邮件
• 文件版本改变后保留可识别的更新标记

生产化还需要来源适配器、权限与租户隔离、审核记录、调度、持久化和异常告警。建议记录抓取成功率、解析缺失率、人工复核通过率及投递失败率；不要用页面演示数据宣称覆盖率或准确率。

技术参考

• RFC 9110：HTTP语义与条件请求
• Python EmailMessage官方文档
• 本站现有AI监控API文档

配套发布文案

公众号导读

政策监测的难点，不只是“发现新文件”，而是分清发布、生效和申报三个时间点。本文给出政策订阅的参考数据模型，将地区、关键词和申报状态转成可解释规则；未确认窗口进入复核，废止与修订作为变更事件处理。配套页面可修改条件、核对证据并预览邮件。本文为技术设计和离线原型，不构成政策解读结论或客户申报资格确认。

朋友圈摘要

政策发布≠申报开始。把来源、条件、版本和窗口分开记录，才有可能做出可靠的政策订阅。新的技术专题已整理：可操作演示、代码和邮件预览一并提供。

配图建议：架构图用于说明流程，交互页面图用于说明配置与结果。发布时保留“离线演示”与样本口径。