自动跟踪券商盈利预测：有新报告时才更新估值比较表
自动跟踪券商盈利预测，首先要区分“观察到一篇新报告”和“盈利预测数值发生变化”。识别报告身份后，比较同一公司、同一券商、同一财年的EPS，只重算数值输入改变的估值行。评级或标题变化可能值得阅读，但本身不能证明盈利上调，更不能自动变成经营判断。
本文用固定比较报价和合成研报事件手动重放更新流程，没有轮询供应商、调用模型或开启定时任务。CoTrading相关监测能力仍为规划或待核实；带日期窗口和数量上限的A股来源，也不能自动当作完整的全球或历史一致预期数据库。例子交付的是可检查的更新规则及运行记录。
先固定预期与报价的比较口径
至少记录公司及证券身份、券商、目标财年、EPS基础、单位和币种。本例使用虚构AAA、券商B、二〇二七年摊薄每股盈利、人民币口径以及固定报价二十。报价时点为十月十九日，研究重放截止为十月二十六日；其间到达的预测都对同一个旧报价计算，以隔离盈利假设变化的影响。
这是一份截止日上的情景比较，不代表后到的报告在报价当天已经可知。真实“当前估值”还需要独立的价格更新触发和新鲜度规则，不能因为预测刷新了，就把冻结报价重新标成最新市价。结果表应同时保留报价时点与预期观察时间，让读者看到两者的差别。
脚本拒绝证券或币种不匹配的记录，只接纳本例声明的摊薄、每股口径，检查报价有限且为正、EPS有限。负EPS可以是合法亏损预测，但不能进入这里的正盈利PE比较。这些门槛阻止缺值、口径变化或单位错误伪装成一个普通盈利修正。
报告身份与预测序列身份分开
标准化报告观察的去重键使用“证券、券商、报告ID、财年”，允许同一报告拆出多个年度预测；预测比较使用“证券、券商、财年”。前者回答是否处理过这一份年度观察，后者回答同一预测序列的数值是否改变。把两个目的塞进同一个键，可能丢掉旧报告，也可能让每篇新报告都被误当成全新的预测序列。
已处理身份旁保存规范化载荷摘要。Python哈希文档提供摘要计算机制，哪些字段进入规范化记录则由本流程明确选择。摘要只比较载荷，不证明报告由某券商发布，也不证明提取正确；原文定位和提取核对仍须单独保留。
同一身份、相同内容再次返回时跳过；身份不变而内容变了，应作为冲突停止，不能静默更新摘要后宣布去重成功。供应商更正要有明确修订关系。抓取时间也不是发布时间，不能用“今天才下载”把旧报告变成最新预期。
完成接纳检查后再替换状态
完整脚本先深复制当前状态，在副本里验证和处理整批记录，成功后才替换活动状态。已处理身份冲突或非有限EPS出现时，调用方的原状态保持不变。这只是内存事务演示，不是数据库持久事务或进程崩溃恢复保证，实际存储适配还需要额外验证。
合格事件按带时区的发布时间处理；研究截止以后的报告不参与。晚到的旧报告可以进入已见账，但不能把当前预测倒退。两个最新报告时间相同而EPS不同，则拒绝歧义，不能随输入行序择首。在只有日期、无法恢复日内顺序时，应取得可靠顺序证据再处理。
核心数值判断如下，省略部分仍然是必需的身份、时点和有限数检查：
key = (report["symbol"], report["broker"], report["year"])
previous = staged["latest"].get(key)
staged["latest"][key] = report.copy()
if previous is not None and eps == Decimal(previous["eps"]):
reason = "numeric_unchanged"
else:
forward_pe = price / eps if eps > 0 else None只复制这几行会丢失接纳保护。Decimal有限数检查帮助拒绝NaN和无穷，但不能替读者决定财务定义。预测年度、基本或摊薄、每股单位与币种仍需回到来源核对，不能靠数值相等就认定可比。
实际重放评级变化与盈利变化
下载完整示例，使用Python 3.12或更新版本运行python R558.py，只需标准库和脚本里的虚构数据。输出逐一保留事件及原因，而不是只显示“更新成功”。
| 事件 | EPS | 其他变化 | 数值处理 |
|---|---|---|---|
| 十月二十日r1 | 1.00 | 首次观察 | 建立PE20 |
| 十月二十一日r2 | 1.00 | 评级变化 | 记报告，不重算PE |
| 十月二十二日r3 | 1.25 | 盈利变化 | 重算PE16 |
| 再次返回r3 | 1.25 | 完全重复 | 不重算 |
计算为二十除以一点二五，等于十六。它不是未来价格估计，也不证明股票更值得投资，只隔离一个盈利假设如何改变冻结价格下的比率。相同数值不重算，也不代表新报告不值得阅读；定性内容由另一项研究任务处理。
还要区分最新观察到的报告与上次真正需要计算的来源。r2成为最新报告时，比率未变，计算来源仍可保留r1；已见账保存两者。不要为了显示“刚更新”，把同一个旧计算的时间戳改成今天，让读者误以为做过新的数值核查。
冲突、晚到与亏损分别验证
脚本把另一个EPS塞进已经处理过的r3身份，另外再注入NaN，两者都阻断且原状态不变。断言比较真实状态对象，不只是搜索错误文字。只有把冲突保留为冲突，才能避免同一报告ID在后台悄悄换成另一版预测，破坏历史结果的解释。
新见但更早的记录标成late_older_report，不能回滚当前预测。最后r4把EPS改成负零点二，这仍是数值变化，需要留下事件，但PE为空并标nonpositive_eps，不能把负比率混进普通正盈利倍数排序，制造便宜的错觉。
重复、数值未变、旧报告晚到、未来、身份冲突和盈利基础不适用，是不同原因。统一写“没有更新”会掩盖来源是否真正检查过、结果为何不变，以及是否需要人工解决输入问题。输出原因应足以指导下一步，而不是让摘要重新猜测。
不把去重账当成完整覆盖
定期请求可能只返回窗口内最新若干篇。去重只证明本地处理过什么，不能证明窗口外没有遗漏。保存请求日期、分页或条数限制、来源状态及研究截止；两次成功运行之间若有未查区间，要明确标注，再通过有权限的来源补齐。不要用新报告总数代替覆盖证据。
没有当前预期也不等于没有分析师覆盖，可能是来源失败、结构变化或没有返回所需财年。报告多了一篇同样不等于EPS上调。先检查数值观察和口径，再讨论含义，才能避免把执行状态写成公司经营结论。
本重放没有持久存储，也没有并发写入。生产适配应让处理身份与估值行原子落盘，并验证重启、重试、时间规则及价格更新触发。可用同一批重放事件验收新增适配，检查重启后是否重复计算、是否保留旧报价，以及失败是否真的没有污染活动状态。
交付能复算的更新包
把已处理身份、忽略原因、变化的预测序列和估值行一起交付。每个变化行保留旧新输入、报价时点、目标年份与计算来源；每个未变行说明是否真的检查了新报告。读者不用依赖摘要的语气，就能重建一次更新的依据和范围。
一份报告若改了多个年度，就按年度分别比较和重算，避免跨年覆盖。独立反例将同一r1拆成2027年EPS1与2028年EPS2，分别得到PE20和PE10；倒序精确重放不重算，同报告同年度载荷冲突则拒绝且状态不变。EPS基础、股数单位或币种改变需要新的可比性判断。自动监测的价值是稳定执行这些具体检查，不应把文档到达转换成买卖指令或盈利保证。
对照重算记录检查自动化价值
一次轮询结束以后，先核对发现多少新报告，再核对哪些预测数值变化，最后核对实际重算了哪些估值行。这三个数量并不必然相等。评级变化可以产生新报告，却不触发盈利驱动的重算；重复响应也不应该增加计算记录。保留这些差别，才能判断自动化究竟做了什么。
检查结果时还要看价格时点。本例为了分离预测变化而冻结价格，不能把旧价格与新盈利组合出的倍数称为当前实时估值。如果随后接入价格更新，应单独定义触发事件和版本，并在结果中解释变化来自股价还是来自盈利预测。
最后用同一批事件重放一遍，确认没有新的重算和状态漂移。幂等性检查能够发现重复消费问题，但不能证明供应商没有漏报；窗口截断、权限和来源覆盖仍要在抓取层另行验收。
常见问题
新评级是否一定重算PE？
本例固定报价、以EPS驱动，所以不会。评级单独留档和研究，数值EPS改变才触发这里的计算。
已处理账等于历史预期数据库吗？
不等于。它只记录实际抓取的窗口和观察，完整性需要额外覆盖证据。