🔗 开源项目地址：https://github.com/zer0quant/zer0share

这是本地股票数据系统系列的第四篇。前面几篇解决了数据同步、复权和 AI agent 调用，这一篇继续补上一个更基础、也更容易被忽视的环节：数据质量。

大概一个月没有更新文章了。

最近我一直沉迷于用 Fable 5 做策略研究，策略验证的速度确实快了很多。不过在研究过程中，我也越来越强烈地意识到一个问题：

数据能查、代码能跑，不代表数据真的可信。

前面几篇文章里，我已经把股票、指数、ETF 等数据同步到本地，并通过 zer0share-data skill 让 AI agent 可以直接调用。

但数据接进来之后，质量到底怎么样？有没有漏数据？内部逻辑是否自洽？复权因子是否可靠？这些问题如果不主动检查，平时很难发现。

所以这次，我决定给 zer0share 补上一套数据质检系统。

一、数据可用和数据可靠，是两回事

做研究久了会发现，几乎所有数据源都会存在或多或少的问题，无论免费还是付费。

有些问题很明显，比如整天行情缺失、字段为空、代码错误；有些问题则很隐蔽，比如 OHLC 关系异常、涨跌幅计算不一致，或者复权后收益率突然跳变。

早年我还听说过一个有意思的故事：某家数据商曾经通过淘宝购买数据，用来补充自己的数据库。

这个故事是否还能考证不重要，它至少提醒我们一件事：

付费只能降低数据出错的概率，不能替代自己的质量检查。

当然，很多早期历史数据里的细微异常，并不会明显改变研究结论。但量化研究的每个环节都建立在数据之上，问题最好被看见、被记录，而不是默认它不存在。

数据问题只有被持续监控起来，才会一个个暴露出来。

二、先收敛范围，再开始设计

我最初的想法比较大：希望质检系统同时适配股票、指数、ETF、期货和期权，并覆盖行情与复权因子。

但如果一开始把所有市场、所有表和所有规则都放进来，项目很容易失控。

所以我先用 superpowers 的 brainstorming 流程和 Codex 澄清需求，通过一轮轮选择题确定边界，再补充自己的定制要求。

这一步最重要的不是让 AI 立刻写代码，而是把输入和输出说清楚。

最终收敛出来的需求主要包括：

• 支持历史全量质检，也支持每天定时增量质检；
• 第一阶段聚焦行情数据和复权因子；
• 同时输出总体概况和具体异常明细；
• 单条规则失败时继续执行，不让整批任务中断；
• 限定首期接入的数据表，避免范围继续膨胀。

范围收敛后，后面的架构和规则设计就清楚了很多。

三、数据质检的四个基础维度

这套方案主要围绕四个维度展开：完整性、准确性、一致性和唯一性。

1. 完整性

完整性解决的是“数据缺不缺”。

例如，可以结合交易日历、股票基础信息和上市状态，检查某个交易日是否缺少应有的行情记录，或者某只正常交易的股票是否整段缺失。

只看实际数据本身是不够的。必须先知道“理论上应该有哪些数据”，才能判断“实际缺了什么”。

2. 准确性

准确性解决的是“数值到底对不对”。

最常见的方法是多数据源交叉验证。对于关键日期、关键标的和可疑异常点，可以用另一个独立数据源进行抽样比对。

第一版系统先把准确性检查的接口和输出结构留好，后续再逐步增加跨数据源校验。

3. 一致性

一致性检查的是数据内部是否自洽。

例如，日线行情可以定义下面这些基础规则：

open > 0
high > 0
low > 0
close > 0
amount >= 0
volume >= 0

high >= max(open, close)
low <= min(open, close)
high >= low
close / pre_close - 1 ≈ pct_change

单个字段看起来可能都像正常数值，但放到同一条行情里，彼此之间未必符合逻辑。一致性规则就是用来发现这类问题。

4. 唯一性

唯一性解决的是重复数据。

同一标的、交易日、时间戳和频率下，应该只有一条有效记录。否则可能出现重复写入、版本冲突，甚至同一查询返回两套不同价格。

四个维度合在一起，基本覆盖了第一版行情质检最需要关注的问题。

四、Codex 给出的完整质检方案

需求和规则确定后，我让 Codex 继续设计整体方案。

最终方案从设计目标、首期范围、系统架构、规则体系、严重级别、结果输出，到最后的调度集成都考虑得比较完整。

确认方案没有明显问题后，我继续让 superpowers 输出设计文档，再对设计文档做 review，最后拆成可以执行的 implementation plan。

这套流程对我来说很有价值：先把边界、规则和输出想清楚，再让模型进入实现阶段。后面即使切换模型，执行目标也不会漂移。

五、设计用强模型，执行可以换轻量模型

implementation plan 写完之后，每一步要改什么文件、实现什么逻辑、运行什么测试，基本都已经写清楚了。

这时候继续用 GPT-5.5 执行所有机械任务，token 消耗会比较高。

我的做法是把模型分工拆开：

• 用 GPT-5.5 收敛需求、设计方案、review 和生成测试计划；
• 用 GPT-5.4-mini 按计划执行大部分编码任务；
• 也可以把执行计划交给 Claude Code，再用 Sonnet 4.6 实现。

这样既保留了关键环节的推理质量，也能控制实现阶段的成本。

长任务运行过程中，agent 经常需要文件或命令权限。Codex CLI 可以通过 /permission 调整权限，Claude Code 可以用 Shift+Tab 切换 auto mode。

不过自动授权只适合在计划明确、工作目录和命令范围都确认过的情况下开启。任务跑完之后，代码和执行结果仍然要重新 review。

大约半小时后，GPT-5.4-mini 完成了第一版实现。

六、先跑小数据，再跑全量历史数据

数据质检的测试原则很简单：先用小范围数据验证规则，再跑全量历史数据。

如果一开始就扫描全市场、全历史，不仅耗时更长，规则本身有问题时也很难快速定位。

所以我先选择一个月的数据进行测试，确认命令、规则、输出和异常处理都能正常工作。

当然，也可以先让 GPT-5.5 生成一份测试计划，再让它根据实际命令输出汇总测试结果。

第一轮结果很快就发现了问题：股票复权因子缺了一天；期货和期权数据里则出现了不少 NaN 和空值。

为了避免第一版范围继续扩张，我决定暂时跳过期货和期权，先把股票、指数和 ETF 的质检链路跑完整。

这也是前面收敛范围的意义：发现某个市场的数据问题过多时，可以先记录并隔离，不必拖住整套系统。

七、全量质检真的找出了不少问题

小范围测试通过后，我开始跑股票日线行情和复权因子的全量质检。

Codex CLI 跑长任务时有一个体验问题：界面里只能看到 background terminal，不容易知道任务具体跑到哪里。有时只能通过 /btw 继续询问进度，这方面 Claude Code 的交互会更完整一些。

股票日线行情

股票日线的大部分异常集中在 1991 到 1993 年的早期行情，包括 OHLC 关系异常、涨跌幅不一致和成交额缺失。

这些数据在日常研究里基本不会使用。我的处理方式不是强行修复，而是记录异常、明确影响范围。

质检还发现了少量交易日行情缺失，可能是同步时的网络问题。重新执行同步后，缺失数据已经补齐。

ETF 行情与复权因子

ETF 数据里发现了一批异常代码，部分代码甚至出现了七位数字，导致无法匹配对应的复权因子。

确认属于无效代码后，我把这些记录删除，也不再为它们匹配复权数据。

ETF 整体没有发现严重错误，主要问题是少量行情 amount=0，以及部分交易日 fund_adj 覆盖率不足。

到这里，行情数据的完整性、内部一致性和唯一性检查基本跑通。

八、复权后仍然跳变，问题藏得更深

最后我又增加了一类检查：先根据复权因子计算后复权收盘价，再计算连续收益率，观察复权后的价格是否还会异常跳变。

这个检查比单纯判断复权因子是否缺失更深入。

因为一条复权因子记录即使存在，也不代表它的数值一定正确。只有把它应用到价格上，再检查收益率连续性，才能发现隐藏的问题。

结果确实发现了一些标的在复权后仍然发生明显跳变。

我随机抽查了其中一个案例，确认问题来自复权因子本身。

异常主要集中在 1994—1995 年、2006—2007 年，近年的数据里也有少量需要人工核对的点，例如 001331.SZ 在 2026-07-01 附近的记录。

这也让我重新思考复权因子的来源。

相比完全依赖上游累计因子，后续可以基于日线行情里的 pre_close 自己推导单次调整关系，并把计算结果作为独立校验，必要时用于修正累计复权因子。

ETF 的同类检查没有发现明显的复权收益率跳变。

九、最终结论：整体可用，但必须持续监控

第一版质检完成后，我对当前数据的判断是：股票和 ETF 日线及复权数据整体可用，但仍然存在需要记录、修复和持续观察的问题。

目前发现的问题可以归纳为三类：

• 早期股票行情存在少量 OHLC 关系异常、涨跌幅不一致和成交额缺失；
• 少量日线数据因同步异常缺失，可以通过重新同步补齐；
• 部分股票复权因子会造成后复权收益率跳变，需要进一步核对和修正。

ETF 数据整体更稳定，主要是少量 amount=0、异常代码，以及部分交易日复权因子覆盖不足。

这次最大的收获，不是证明数据库“完全没有问题”，而是建立了一套能够持续发现问题的机制。

数据质检不是上线前跑一次的验收，而应该成为数据同步之后的固定环节。

后续每天增量同步完成后，都可以自动运行核心质检规则；出现异常时记录明细和严重级别，但不阻塞其他规则继续执行。

这样一来，我们面对的就不再是“数据到底有没有问题”这个模糊问题，而是一份可以查询、追踪和处理的异常清单。

一起交流

如果你也在做本地量化数据库、数据质检或 AI 投研工具链，可以通过公众号菜单「认识我」找到我交流。

我也很好奇，大家平时会怎样检查行情和复权数据，又遇到过哪些比较隐蔽的数据问题。

参考链接

• 本地数据系统项目：zer0share
• 数据系统系列第一篇：我用 Tushare + Claude Code，手搓了一套本地股票数据同步系统（已开源）
• 数据系统系列第二篇：我用 Tushare + Codex，把本地股票数据库补上了前后复权行情（已开源）
• 数据系统系列第三篇：我用 Hermes Agent + zer0share-data skill，把本地数据库变成了可对话的投研助手

如果这篇文章对你有帮助

• ⭐ Star 一下项目：https://github.com/zer0quant/zer0share
• 关注公众号，后面继续更新本地数据系统、数据质检和 AI 投研工具链

我们下篇见。