2026-03-30：终于有了真实数据，但仓库还是被日志拖脏

今天最大的发现，是数据流水线终于干了一次真正有业务意义的活：sz002594.csv 补进了 2026-03-30 这一行新行情。烦人的部分也很稳定——这笔提交依然像没装滤网的吸尘器，把运行日志、Feishu 发送记录，甚至 Git 自己的提交回显都一起吸进了仓库。

一行真实数据，带动了一串真实指标

/root/Alpha 今天只有一笔提交：9fb010a chore: update data and summary 2026-03-30 15:10:31。和昨天那种“只有日志、没有业务变化”的空转不同，这次至少有两类内容确实值得保留：

• data/csv/sz002594.csv 新增了 1 行 2026-03-30 行情
• pre_strategy_summary.md 基于新数据重算了一批统计摘要

新增那根 K 线是：

sz002594,比亚迪,2026-03-30,103.51,108.0,103.25,106.05,105.3,727557.0,7713482118.31,369755361675.0,966878801768.25

也就是说，收盘价从前一交易日的 105.30 走到 106.05，单日涨幅大约 0.71%。别小看这一根新增样本——它已经足够把几个关键窗口的统计重新推了一遍。

统计摘要确实动了，而且不是装样子

今天真正该进版本库的，是 workspaces/t_strategy/sz002594_比亚迪/reports/pre_strategy_summary.md 的变化。几个值得记住的数字如下：

最有意思的一项，是 近120日区间涨跌从负转正：-0.28% -> 0.32%。这还不到推翻策略判断的程度，但它说明今天的更新已经不是“末尾补一行存在感很低的数据”，而是开始影响中期窗口的判断边界了。

真正难看的，是这笔提交的信噪比

问题在于，这仍然不是一笔干净的数据提交，而是一笔“业务数据 + 运行噪音”的混合提交。

git show --stat 给出的结构很直白：

• data/csv/sz002594.csv：新增 1 行真实数据
• pre_strategy_summary.md：约 30 行统计结果变动
• logs/getData.log：新增 147 行
• .vntrader/log/vt_20260330.log：新增 0 字节空文件

也就是说，今天仓库里最吵的文件，依然不是数据，而是日志。更离谱的是，提交刚做完，仓库立刻又脏了：

git status --short
M logs/getData.log

为什么？因为 logs/getData.log 还在继续追加，尾部直接写进了这些东西：

• Feishu 消息发送成功记录
• git commit 的标准输出
• Git 对 root@localhost.localdomain 默认身份的提示

这已经不是“日志比较多”的问题了，而是 自动化把自己的执行回声回灌进版本库。版本控制本该记录业务状态变化，不该顺手把“我刚刚执行了 commit”这种元噪音也一并存档。

今天的教训，比昨天更具体

昨天的问题可以概括成一句话：没有业务变化时，不该 commit。

今天看完这笔提交，结论得再进一层：

1. 有业务变化时可以 commit，但运行日志必须剥离。
2. 受版本控制的文件，不能在 commit 之后继续被同一流程追加写入。
3. 数据更新和运维痕迹要分层——前者进 Git，后者进独立日志或至少进 .gitignore。

否则后面不管是做回测、写日报，还是排查策略变化，都会被无关噪音拖慢。真正难维护的，从来不是数据量大，而是“看起来什么都变了，实际上只有一行有用”。

关键结果

• 今日唯一提交：9fb010a
• 新增真实行情日期：2026-03-30
• 新增行情收盘价：106.05
• logs/getData.log 在提交中新增：147 行
• commit 完成后仓库状态：logs/getData.log 再次变脏

明天该做什么

优先级已经很明确：先治理数据更新流水线的版本边界。

具体来说，就是把 logs/getData.log 和 .vntrader/log/*.log 从版本控制里剥出去，再补一个“只有业务文件发生实质变化才 commit”的判断。数据链路今天算是恢复了，版本卫生还远没恢复。