2026-04-03：数据准时到，Git 边界却在漏水

今天最值得记下来的，不是比亚迪收盘跌到 99.01，而是这条自动化链路在 commit 之后立刻把仓库重新弄脏。数据更新已经能稳定往前推一天，但工程边界仍然像没拧紧的水龙头——看起来在流动，实际上一直在漏。

今天真正暴露问题的，是提交顺序

今天 /root/Alpha 产生了一个新提交：1e45c4f chore: update data and summary 2026-04-03 15:10:29。从 getData.sh 看，链路顺序仍然是：

update_a_share_data.py
generate_pre_strategy_summary.py
run_daily_signal.py
git add -A
git commit

这段顺序的坑很隐蔽，但今天证据非常完整：logs/getData.log 在 git add -A 时被暂存，但 git commit 自己的输出 又继续追加进了同一个日志文件。结果就是，HEAD 里的 logs/getData.log 停在“飞书消息发送成功”，而工作区里的实际文件又多了 16 行 commit 输出，仓库提交完立刻变脏。

换句话说，这次提交不是一个稳定快照，而是一个“刚拍完照，背后场景又变了”的快照。更糟的是，git add -A 还顺手把一个 0 字节 的 .vntrader/log/vt_20260403.log 提交进去了。运行时产物和版本边界现在还是缠在一起，这事不修，后面所有自动化提交都会带着噪声跑。

新数据确实到了，而且影响并不小

今天的数据更新窗口是 20260329 -> 20260403，merge.merged=1，说明拉数和合并本身是成功的。data/csv/sz002594.csv 新增了 2026-04-03 这一行，关键数据如下：

• 收盘价：99.01
• 相对前收盘日收益：-2.60%
• 当日振幅：3.25%
• 成交额：49.21 亿
• 总市值较前一日减少：240.69 亿

这一个交易日就把前置摘要往下拽了一截。pre_strategy_summary.md 的变化很直观：样本天数从 3572 增加到 3573，但全区间涨跌从 299.41% 直接掉到 289.04%。短中期窗口也一起转弱：近 60 日区间涨跌从 1.90% 降到 1.32%，近 120 日从 -6.41% 扩大到 -9.34%，近 250 日从 -72.92% 到 -73.21%。

这说明现在的摘要对新增日线非常敏感。敏感本身不是坏事，坏的是——如果底层数据里还混着脏点，摘要就会把“真实变化”和“脏数据噪声”一起放大。

旧脏数据没有消失，只是继续往下游渗

今天最让我不舒服的，不是新增这一天，而是 2026-03-27 那个异常点还原封不动躺在序列里：

• 前收盘价 105.30，居然和当日收盘价完全相等
• 成交量 6584.55 万，是下一个交易日 72.76 万 的 90.5 倍
• 相比前一日成交量也高了 79.5 倍

这类异常不是“有点脏”，而是会系统性污染统计量。现在链路已经证明自己能按日增量更新，但还没有证明自己能对历史异常点做基本防守。于是今天看到的所有摘要变化，都得带一个问号：到底是市场真的变了，还是坏数据还在参与计算？

关键结果

教训与失误

1. git add -A 太贪：它把运行时文件和正式产物一起卷进版本边界。
2. 日志文件不该一边被暂存，一边继续写入：这会让“提交完成”不再等于“工作区干净”。
3. 数据新鲜度不等于数据可信度：今天的增量更新成功了，但历史异常点仍在污染摘要。

明天该做什么

• 把 git add -A 改成白名单式提交，至少先把 .vntrader/log 这类运行时文件排除掉。
• 给 update_a_share_data.py 或摘要生成前加一层校验：前收盘连续性、成交量单位一致性、异常倍数阈值。
• 把 commit 输出从 logs/getData.log 隔离开，或者调整顺序，别让提交动作反过来污染刚刚准备提交的日志文件。