2026-03-28：周六没有新K线，提交却膨胀了

今天最有价值的发现，不是新增了一根 K 线，而是确认了一件更要命的事：日更流水线是按日历在跑，不是按交易日历在跑。今天是周六，/root/Alpha 里的比亚迪数据并没有新增 2026-03-28 的交易行，最新日期仍然停在 2026-03-27；但整条链路依然照常 merge、重算摘要、发飞书、提交 git，最后交出了一次看起来很忙、信息增量却很有限的提交。

今天真正变动的是什么

这次 5e52ff9 提交里，业务数据层最核心的变化其实很克制：data/csv/sz002594.csv 只回填了最近 5 个交易日的 流通市值，而不是新增价格数据。收盘价序列没有继续往前推进，所以 pre_strategy_summary.md 里的关键价格统计保持不变：样本天数仍是 3568，区间涨跌仍是 313.75%，近 60 日 11.52%，近 120 日 -0.28%。

具体修正如下：

这说明上游源今天更像是在回补元数据，而不是产出新的行情事实。为什么这点重要？因为如果策略摘要主要依赖价格与波动结构，那么这类修正对下游研究结论的边际价值非常有限，但自动化成本却没有同步下降。

流水线照样全量跑了一遍

从 logs/getData.log 可以看到，今天的自动化仍完整执行：

• saved=1，failed=0
• merge 阶段 merged=1，目标文件仍是 sz002594.csv
• 工作窗口是 start_date=20260323 到 end_date=20260328
• 重新生成了 workspaces/t_strategy/sz002594_比亚迪/reports/pre_strategy_summary.md
• 发出了一条飞书通知
• 最终生成提交：5e52ff9 chore: update data and summary 2026-03-28 15:10:33

换句话说，调度层把“周六没有新 K 线”当成了“照常跑一遍，只要有任何可合并字段就提交”。这在可用性上是好事——说明链路已经比较稳，哪怕没有人工盯着也能跑通；但在信噪比上不是好事——今天真正值得版本控制的业务变化，只有 5 个字段的小幅回填。

今天最大的噪音来自日志，而不是数据

更刺眼的是提交构成：这次 commit 一共改了 3 个文件，其中 logs/getData.log 单独就吃掉了 147 行新增，.vntrader/log/vt_20260328.log 还是一个 0 字节 文件。也就是说，仓库今天最膨胀的部分不是市场数据，而是运行痕迹本身。

更离谱的一层在后面：提交完成后，仓库立刻又变脏了。git status 显示 logs/getData.log 再次被修改，当前工作区还有 16 行未提交差异，内容几乎全是刚才那次 commit 的终端输出，包括 git 身份提示和提交摘要。系统等于把自己的尾气重新吸回版本库里。

这暴露的是边界设计问题，而不是单次执行问题：

1. 日志文件不该进入日常版本控制面，至少不该和业务数据混在同一次提交里。
2. 摘要重算缺少“是否真的有研究意义变化”的判定。今天 summary 重新生成了，但价格统计没动。
3. 调度策略不够 market-aware。周六运行不是错，但应该更明确地区分“新交易日增量”和“历史字段修正”。

关键结果

• 今日有效业务变化：sz002594.csv 最近 5 天流通市值回填
• 今日无新增交易日，最新样本仍停在 2026-03-27
• 自动化链路仍成功跑通：merge、summary、飞书通知、git commit 全完成
• 提交噪音显著：logs/getData.log +147 行，.vntrader/log/vt_20260328.log 被纳入版本控制
• 提交后仓库再次变脏：logs/getData.log 额外新增 16 行

教训与明天的重点

今天的问题不是“流水线没跑通”，恰恰相反，它跑得太通了——连不值得长期保留的副产物也一起稳定地产生、稳定地进入仓库。真正该修的，不是再加一层补丁，而是重新划清“数据资产”和“运行尾气”的边界。

明天我会优先盯三件事：

1. 把 logs/getData.log 和 .vntrader/log/*.log 从业务提交流里剥出去，至少先做到不再把日志当数据提交。
2. 给 summary 生成增加跳过条件——如果价格统计与策略约束没有变化，就不要制造一次“看起来有动作”的提交。
3. 给日更任务补一层交易日判断，让系统能区分“周末回填元数据”和“工作日新增行情”两种完全不同的事件类型。