用 DeepSeek 整理新闻并接入 CMS：日期核验、去重和发布结果回读

每天更新新闻时，常见问题包括把旧消息写成“刚发布”、同一事件重复建页，以及 CMS 写入后未确认公开状态。本篇给出可接入 DeepSeek 的应用流程，字段和规则均为示例。

1. 每条消息先建来源记录

保存原文 URL、发布主体、原文日期、事件日期、时区、核验日期与版本标签。搜索结果摘要用于寻找原文，最终依据应回到公告、论文或发行页。

例如 UTC 10 月 13 日 16:13 是北京时间 14 日 00:13；标题中的 Nightly 日期也可能与构建时间不同。“公告计划下月可用”应保留计划表述。

2. 让模型输出可审查的草稿字段

可使用 JSON Output提取以下应用字段：

{"event_key":"项目与版本组合","event_date":"原文事件日期","reviewed_at":"实际核验日期","facts":[],"source_urls":[],"uncertainties":[]}

对空输出、缺失日期和事实没有对应来源的结果，保留为待补资料。格式能解析，不代表已经完成核验。给来源编固定编号，使草稿中的每项事实可回到原文。

3. 用事件键与旧文状态去重

发布前查询同项目、同版本或同公告的旧文。已有页面且状态允许更新时，补充变化；独立新事件再创建页面。稳定版、预发布版与教程可以有不同选题，但应相互链接并说明范围。

人工下架或锁定的页面应遵守 CMS 状态规则，不由模型自动恢复。接口字段和权限以具体 CMS 文档为准。

4. 写入后回读

DeepSeek 工具调用将执行交给应用，因此 CMS 请求、错误处理和结果核对要在执行层实现。保存目标 ID 和事件键；超时后先查询真实状态，避免重复创建。

发布成功后核对后台状态、公开页面标题、正文与来源链接，再检查列表入口和站点地图。状态未知时记录未知，不能把请求已发出写成已经上线。

5. 形成可追溯的运营记录

记录新增或更新、页面 URL、来源日期、核验日期和失败项。后续报道变化时优先修订原页，并说明变化，避免每天用新 URL 重复同一结论。

本文没有向读者的 CMS 执行写入。具体重试设计可参考工具幂等与恢复教程。