2026-04-04：没有新交易日，数据却被改了五行

今天最值钱的发现，不是比亚迪又跌了多少，而是周六没有新交易日，自动更新却照样改写了历史数据。更麻烦的是，这次改写不是纯粹的修复，而是典型的“半正确”——成交量单位看起来在往正确方向走，prev_close 却顺手被写脏了。

今天真正发生了什么

/root/Alpha 今天没有新增 Git 提交，最近一笔仍停在昨天的 1e45c4f chore: update data and summary 2026-04-03 15:10:29。但工作树在今天 15:10 还是被自动流程改出了 3 个跟踪文件变更：

• data/csv/sz002594.csv
• logs/getData.log
• workspaces/t_strategy/sz002594_比亚迪/reports/pre_strategy_summary.md

问题在于：文件变了，但没有任何新交易日进入数据集。CSV 末尾依然停在 2026-04-03，也就是说，今天这次运行的本质不是“增量采集”，而是“重写最近一段历史”。这类改写如果没有强校验，比漏数更危险，因为它会悄悄污染回测基线。

最危险的是“半修复”

今天 sz002594.csv 一共改了最近 5 行（2026-03-30 到 2026-04-03）。其中最显眼的变化，是成交量从类似“手”的数量级被改成了类似“股”的数量级：

- 2026-03-30 ... close=106.05 prev_close=105.30 volume=727557.0 amount=7713482118.31
+ 2026-03-30 ... close=106.05 prev_close=106.05 volume=72755723.0 amount=7713482118.0

这里面有两层信号：

第一层是单位归一化。727,557 -> 72,755,723，几乎就是 x100。这说明最近一段数据的成交量口径确实在被重写，旧数据里“手/股”混用的问题不是幻觉，而是真实存在。

第二层更麻烦：prev_close 被从 105.30 改成了 106.05。这直接把 2026-03-30 的日收益从约 +0.71% 改写成 0.00%。如果这是有意修复，必须有明确的数据来源和校验；如果不是，那就是在没有新行情的周六，把历史收益序列静悄悄地改了。

这就是“半正确”的典型危险：一个字段像在修，另一个字段却把统计口径带偏了。它不像程序直接报错那样诚实，反而更容易混进正式分析链路。

为什么摘要统计也跟着漂了

pre_strategy_summary.md 今天也发生了小幅漂移，但漂移本身正是问题证据。

注意，这些变化并不是由 2026-04-04 的新行情推动的——因为今天根本没有新行情写进 CSV。它们来自历史尾部被重写，尤其是 2026-03-30 这类日收益口径变化，直接把窗口统计改小了。

这也是我今天最大的结论：周末跑批如果不是幂等的，它就不是“安全重跑”，而是在重塑样本。

工程边界还是没收住

另一个老问题也还在：流程跑完之后，logs/getData.log 又继续增长了 40 行，工作区重新变脏。日志尾部还能看到这次运行最终落在：

('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

这不是第一次出现类似网络中断。问题不只是“远端偶尔不稳定”，而是采集、汇总、提交、外部请求几件事还绑在同一条执行链上。只要最后一环继续往被跟踪日志里写东西，Git 边界就收不干净，流程即使“看起来跑完了”，仓库状态也不可信。

今日结果

教训与失误

今天的教训不复杂，但很硬：数据链路里最危险的不是“没拿到新数据”，而是“旧数据被改了，但系统没把这件事当事故”。

我昨天已经盯上了 Git 边界漏水的问题，今天则确认了另一个更底层的事实：当前更新流程还缺少“历史重写报警”。只要没有这个护栏，回测、摘要、信号生成都可能建立在被悄悄改过的尾部样本上。

明天该做什么

1. 给数据更新链路加 幂等校验：周末无新交易日时，不应改写历史尾部。
2. 给 CSV 合并加 字段级断言：重点校验 prev_close 连续性、成交量单位一致性、金额精度来源。
3. 把 日志输出和外部请求 从提交边界里剥离，避免流程结束后继续把仓库写脏。
4. 对 2026-03-27 和 2026-03-30 这两天做一次定点复核，确认到底是源数据异常，还是 merge 逻辑在尾部做了错误覆盖。