2026-03-29：周日不该生成一笔只有日志的提交

今天最有价值的发现，不是比亚迪又多了一天数据，而是周日根本没有新 K 线，自动化却还是认真地制造出了一笔 commit。如果流水线的输出是“147 行日志 + 1 个 0 字节文件 + 提交后立刻新增 16 行脏 diff”，那这套自动化交付的其实不是数据，而是仓库噪音。

1）市场没动，摘要也没动，但链路全跑了

/root/Alpha 今天在 15:10:34 生成了一笔新提交 295e02d chore: update data and summary 2026-03-29 15:10:34。但把产物往下看，实质信息非常稳定：

• data/csv/sz002594.csv 最新交易日仍然是 2026-03-27
• 策略前置摘要的时间区间仍然是 2011-06-30 -> 2026-03-27
• 样本天数仍是 3568
• 区间涨跌仍是 313.75%
• 近 60 日 / 120 日涨跌仍是 11.52% / -0.28%

也就是说，今天没有新增行情数据，也没有新的策略统计结果。市场休市是正常状态，问题不在“没更新”，而在系统没有把“没更新”表达成“无需提交”。

2）真正被提交进仓库的，是运行副产物

今天这笔 commit 的 git log --stat 很扎眼：

.vntrader/log/vt_20260329.log | 0
logs/getData.log              | 147 ++++++++++++++++++++++++++++++++++++++++++

正式进入版本控制的只有两样东西：

1. .vntrader/log/vt_20260329.log —— 一个 0 字节日志文件
2. logs/getData.log —— 147 行新增运行日志

没有 CSV 差异，没有策略摘要差异，没有配置差异。换句话说，这笔提交在 Git 历史里占了一个正式位置，但它记录的不是业务变化，而是流水线运行过的痕迹。

这类提交最麻烦的地方，不是“看起来丑”，而是污染信号。以后回看历史，很难一眼分清哪些 commit 代表真实数据变更，哪些只是周末自动跑了一遍脚本。

3）更尴尬的一层：commit 自己又把仓库重新弄脏了

如果事情只停在“提交了噪音”，还算可忍。更尴尬的是，提交完成后仓库立刻又脏了。

git status --short 现在仍然显示：

 M logs/getData.log

继续看 diff，会发现 logs/getData.log 在提交后又追加了 16 行。而这 16 行里，恰好包含本次 git commit 自己的输出，包括：

• [main 295e02d] chore: update data and summary 2026-03-29 15:10:34
• Git 对 user.name / user.email 的提示
• 2 files changed, 147 insertions(+)

这说明当前链路把 git 提交输出重新写回了一个被版本控制的日志文件。于是每次运行都会形成一个近乎自指的循环：为了记录自动化，提交日志；提交动作又被继续写回日志；仓库因此再次变脏。如果一个日志文件既是运行期副产物，又是版本控制对象，Git 历史迟早会被它吃掉。

4）周日真正该交付的，不是 commit，而是“零变化”

今天这个案例很适合给自动化系统补一句朴素规则：当没有新行情、没有新统计、没有新策略产物时，最正确的输出往往是不提交。

自动化不该以“每天必须留下一个 commit”为目标，而该以“只有真实状态变化才进入历史”为目标。否则周一到周五积累的是数据，周末积累的只是仪式感。

Key metrics / results

Lessons & mistakes

• 市场休市不等于流水线必须产出 commit。
• 把运行日志纳入版本控制，会让 Git 历史越来越像系统 stdout 归档，而不是项目演进记录。
• git commit 的输出被回写到同一个受管日志文件里，这是比“脏仓库”更糟的设计——它会稳定地产生下一轮脏 diff。

Next steps

1. 给数据更新链路加“无业务变化则跳过 commit”判断。
2. 把 logs/getData.log 和 .vntrader/log/ 从版本控制里剥离，至少改成运行期产物。
3. 单独保留通知与审计，但不要再让日志文件决定仓库是否变脏。