晨会工作流与定时运行

晨会示例是一条直线：板块分析 → 多因子选股 → 拼接报告 → 交付。

第一节点读取板块数据，输出静态强度、阶段、综合分和排名；第二节点计算因子评分并筛选候选；第三节点将结构化结果转换为 Markdown 和 HTML；第四节点把已完成报告保存到指定位置。企业微信或钉钉推送需要单独配置，并取得明确授权。

LangGraph 可以统一 State、运行记录和后续扩展；如果流程简单，普通函数顺序执行也可以。选择框架的理由应是检查、恢复和扩展，不是让流程名称显得复杂。

State（状态）至少要保存：运行日期、数据截止时间、股票池、板块层级、Top-N、因子版本、阶段规则版本、板块结果、选股结果、报告路径、生成状态和交付状态。

Top5 板块与 Top5 股票是否强关联，必须提前写清：

• 如果目标是“强势板块内选股”，第二节点要用第一节点的历史成分映射筛选；
• 如果是独立扫描，就要分成两个结果，不能让读者误以为股票都来自前五板块。

每次运行还应生成唯一标识，例如交易日期加规则版本，避免同一份报告被重复交付。

晨报至少应包含：数据状态、市场概况、板块候选、股票候选、风险与冲突、待核验事项、方法和版本。每个候选都要能回答“为何入选”。

例如某板块当前强度高，但历史同类信号的胜率示例约为 27.3%，报告应写成“当前强、历史可靠性弱”，保留这条冲突，而不是只展示上涨的一面。是否过滤或降低权重，需要独立验证，不能因一次回测永久拉黑。

先保存 Markdown，便于检索和版本比较；再生成 HTML，便于阅读。不要暗示已经存在一个统一的成熟模板，模板本身也应纳入版本管理。

先触发日 K 增量更新，再运行工作流。盘前日线通常只能使用最近一个已经完成的交易日，不能把当天还没走完的日 K 当成完整数据。

如果更新失败，不能悄悄沿用旧文件并写成“今日最新”。可以停止运行，生成醒目标记为过期的报告，或按事先定义的降级策略继续；无论哪种方式，都要显示数据日期、失败原因和影响范围。

cron 和 APScheduler 都能安排任务。比如周一至周五 9:00 运行，但必须明确使用 Asia/Shanghai 时区。服务器可能配置成 UTC；如果不检查，任务可能错开 8 小时。服务器不一定都是 UTC，实际配置要核对。

周一至周五不等于交易日。节假日、临时休市和特殊安排需要交易日历。进程式调度器还要有常驻进程；关闭终端或退出程序，任务可能失效。正式运行需要进程管理、日志和失败告警。

还要处理重复启动、任务重叠、错过计划时间和重试。用交易日期加规则版本生成唯一运行标识，防止同一晨报被重复推送。

simulate 参数可以表示立即运行，不必等待定时点；不加参数则按计划触发。但参数名不能自动说明使用的是虚构数据，也不能保证不会外部推送。

至少把三个开关分开：

• 立即触发，还是按计划触发；
• 真实数据，还是测试数据；
• 只保存本地，还是推送外部渠道。

推荐先用立即触发、测试或只读真实数据、仅本地保存，回读报告确认数据日期和 Top-N，再启用定时和已授权的交付渠道。

不要只对照一个数字。比如板块事件数 11436 与上次一致，只能说明计数相同，不能证明计算完全一致，也不能掩盖运行中的报错。

每次运行至少核对：

• 退出状态是否成功；
• 输出文件的生成时间是否属于本次运行；
• 行数和关键字段是否完整；
• 数据哈希或抽样数值是否一致；
• 是否误读了上一次残留结果；
• 节点是否有错误、降级或过期提示。

多因子有效性看 IC、分层和稳定性；板块轮动有效性看事件研究和前推验证。晨会只负责组织这些结果，不能把尚未验证的研究包装成确定建议。