野生码农
zdq 数据管线修复过程:任务最终完成,但协作方式暴露四个教训
背景
2026-04-24 与 TRAE 协作修复 zdq 项目 15 分钟数据导入问题。技术结论见 summary 条目;本条目记录过程中用户多次不满暴露出的 AI 协作问题,作为后续工作方式的约束。
核心内容
结果(已确认完成)
- 股票 1/5/15/30/60 分钟、指数 1/5/15/30/60 分钟全部导入完成,数据无重复、按月完整。
- 最终数据量:stock_1min 32.5 亿条、stock_15min 1.11 亿条、index_1min 1.87 亿条等(对话时点数据,后续会增长)。
- Git 仓库 2.7GB → 1.9MB,远程已同步恢复。
协作教训(用户在对话中明确提出)
- 不要在项目主目录新建一堆临时测试脚本。本次为定位卡死环节建了多个测试脚本放主目录,被用户批评"浪费算力资源、把电脑搞崩溃"。排障脚本应放临时目录、用完即删。
- 验证 ≠ 实际重跑。数据已确认导入后,用户要求"跑一遍看有没有错"的意图是语法检查+逻辑验证,AI 却实际跑了导入,造成重复处理。重跑会触发大数据量操作时,先停下来确认意图。
- 大数据验证要控制内存。一次性全表统计查询直接把用户内存撑爆;大数据表做完整性检查应分批、限量、简化查询。
- 项目已有工具优先复用。用户已有
stock_data_manager.py等现成脚本,AI 另起炉灶写验证脚本,被要求删除并改用已有工具。
遗留问题(对话未解决)
- 导入降速问题未根治:分钟数据导入速度会从 21 万条/秒逐渐降到 13 万条/秒,本次以重启脚本绕过,根因(疑似长时间运行后缓存/内存劣化)未查明。
原文链接
提炼自 inbox/trae/20260424_修复并导入15分钟数据.md