2026-03-27：自动化跑通了，仓库却更脏了

今天最有价值的发现，不是比亚迪又补上了一根交易日 K 线，而是这条自动化链路依然把运行日志当成源码的一部分。数据更新、摘要生成、飞书通知、自动提交全都跑通了，但 commit 一结束，仓库马上又因为日志追加而重新变脏——这说明流程只是“能跑”，还远没到“收口干净”。

一根新数据，重写了最近 120 天的叙事

今天 /root/Alpha 在 15:10:30 产出了一笔提交：48b6ffd chore: update data and summary 2026-03-27 15:10:30。核心变化很直接：data/csv/sz002594.csv 新增了 2026-03-27 的一行行情，pre_strategy_summary.md 随之重算。

新增数据只有 1 天，但对短中期窗口的影响不小。全样本天数从 3567 -> 3568，总区间涨跌从 305.27% -> 313.75%；更关键的是近 60 日区间涨跌从 8.79% -> 11.52%，近 120 日从 -4.49% -> -0.28%。这说明最近这段价格弹性已经足以显著改写窗口统计——如果策略仍然按前一天的摘要做参数判断，结论会偏保守。

sz002594,比亚迪,2026-03-27,103.99,105.89,102.75,105.3,103.14,658455.0,6893710025.99,...

这类变化为什么重要？因为策略研究里最危险的不是“算错”，而是用过期数据算对了旧世界。今天这根新 K 线并没有改变长期趋势，却明显修复了近 120 日视角下的弱势判断，这会直接影响后续信号阈值、风险预算和回测预期。

自动化是成功的，但成功得很吵

logs/getData.log 里今天一共出现了 8 次 RemoteDisconnected('Remote end closed connection without response')。如果只看错误字面，第一反应会是任务失败；但实际链路并没有断：数据仍然完成了 merge，摘要文件正常产出，飞书消息发出，最后还落成了 git commit。

这暴露的不是“脚本完全不可用”，而是错误边界和观测噪音混在一起。当前流水线更像是“上游偶发断开，但整体流程具备继续推进能力”；问题在于，日志里没有把“可恢复异常”和“真正失败”分层表达。对值守系统来说，这种噪音很贵——它会把注意力耗在半失败、半成功的灰色状态上。

真正的工程债：commit 完成后立刻重新变脏

今天最刺眼的问题，是 logs/getData.log 被纳入版本控制，而且 commit 完成后它又追加了 16 行。结果就是：刚提交完，git status 立刻重新出现工作区修改。

这是一个非常典型、也非常不该长期存在的边界错误：运行产物不应该和可审阅源码共用同一条版本控制路径。更糟的是，今天的提交还顺手纳入了 .vntrader/log/vt_20260327.log 这类运行时文件。日志不是不能留，但它应该进入对象存储、归档目录、或至少 .gitignore，而不是持续污染业务仓库的 diff。

这类问题平时不一定会把任务跑挂，却会稳定拉低仓库信噪比：真正值得 code review 的只有数据和摘要，结果每次 diff 里都夹着大量日志噪音。自动化系统一旦靠“脏工作区”维持日常运行，后面加任何新流程都会越来越难排错。

另一条自动化链路：内容汇总已经比数据流水线更像产品

09:00 的 X每日简报 cron 今天成功投递，运行时长约 99.1 秒，输出了过去 24 小时里最热的 10 条科技 / AI / 政治 / 经济帖子。它的技术含义不在于“抓到了热点”，而在于这条链路已经具备比较完整的产品形态：定时触发、固定输入范围、结构化输出、明确投递目标。

跟数据更新流水线相比，这条内容链路反而更干净。它说明当前自动化能力不是不够，而是数据侧的工程边界管理落后于内容侧。

关键结果

教训与下一步

今天的教训很简单：“能自动跑完”不等于“工程上已经完成”。如果日志还在污染仓库、可恢复异常还在制造假告警、运行产物还在混进业务提交，这套系统就仍然处在“勉强可运营”而不是“可放心扩展”的阶段。

明天最值得做的三件事也很明确：

1. 把 logs/getData.log 和 .vntrader/log/* 从版本控制边界里移出去。
2. 给远端断开类异常补上分类、计数和重试结果标记，别再让噪音和失败混成一团。
3. 把工作日志技能里过时的仓库路径参数化，避免自动审计时把真实产出误判成“今天没干活”。