想让 AI 帮你查 A 股，最麻烦的从来不是写策略，而是把数据接进来：K 线藏在腾讯的分段参数里，盘后包是通达信的二进制格式，研报 PDF 要带东财的 Referer 头，龙虎榜和两融散在不同域名下，还要防着哪天 IP 突然被风控。a-stock-data 把这件事压缩成了一个文件：408 KB 的 SKILL.md，15 层、85 个端点、34 个数据源、零鉴权（只有一家要 Key）。
我把它 clone 下来做了独立复核：作者自带的 142 条测试我跑了，全过；我把 SKILL.md 里 89 个代码块里的代码全部抠出来，用真实参数调了 103 个函数名，76 个返回了非空真实数据。最大的那个端点一次给我 52,314 行，那是一个交易日沪深北全部证券的日线，下载加解析 10.4 秒。
但同一个文件也藏着一个代价：一次加载约 11 万 token。
一个文件，34 个数据源，零鉴权
先说清楚它是什么。simonlin1212/a-stock-data 2026 年 5 月 11 日建仓，到今天 132 天，9,992 星、1,819 fork，Apache-2.0，最新版本 V3.9.0 发布于 9 月 20 日（昨天）。
它不是 Python 包，没有 requirements.txt——作者明确说过这是有意设计的：整个项目就是一个 SKILL.md，拷进 ~/.claude/skills/a-stock-data/，Claude Code / Codex / OpenClaw 都能直接识别。文件里内嵌了 89 个 Python 代码块、5,638 行可运行代码，不是「文档告诉你怎么写」，而是「代码直接抄」。
覆盖的范围按作者自己的分层是 15 层：行情 K 线（腾讯日周月前后复权 + 1 至 60 分钟、通达信官网盘后包、百度、新浪复权因子）、研报（东财 + 新浪 + 同花顺 + iwencai）、市场信号（强势股归因、北向、板块归属、龙虎榜、解禁）、资金面与筹码（两融、大宗、股东户数、分红、ETF 份额、本地推演的筹码分布）、新闻（财联社、东财、华尔街见闻、新闻联播文字稿）、财务三表与 F10、公告（巨潮）、打板四池、ETF 期权希腊字母、舆情互动、宏观与利率（社融、PMI、中债收益率曲线、回购定盘利率、LPR、宏观日历）、指数与交易日历、期货与大宗商品（五家期货交易所）、事件驱动、可转债。另有 5 个备胎源，主源被封时降级用。
34 个数据源里，只有 iwencai 需要 API Key。这一点我实测验证过：不填 Key 调 iwencai 的两个函数，返回的是 HTTP 401 no auth / not_found_apikey，报错清清楚楚，没有拿空表糊弄。
它的测试工程值得单独说：142 条测试，测的是 SKILL.md 里那份代码
这是我这次复核里最意外的部分。仓库根目录只有 14 个文件，其中两个测试文件合计 11.4 万字节。它们的加载方式是这样的：
skill = (Path(__file__).resolve().parents[1] / "SKILL.md").read_text(encoding="utf-8")
# 按 之类的标记块切出来，再正则取 ```python 段
exec(compile(block, "SKILL.md:official-data-core", "exec"), namespace)测试不测第二份实现，而是把 SKILL.md 里的代码当场抠出来执行。这个选择很关键：绝大多数「文档型工具包」的测试会和文档漂移，这里从机制上漂不了。
我跑的完整离线套件：142 条测试，23.1 秒，全部通过（2 条跳过）。断言写得也很具体，比如「腾讯 K 线三段窗口每段都回同一根日期时，只按总区间过滤会静默返回 1 根」「盘后包里空的北交所文件会被沪深 13,000 行盖过去」「代码表用 replace 解码会把坏字节变成 �00000 放行」。
作者在 docs 目录留了两份《数据源整合记录》，里面写了验证方法：每个修复都做变异检查——把修复改回去，对应测试必须失败。V3.9.0 那份记录里写着 209 处变异，发布前复跑适用的 190 处，186 处全部失败，4 处属双重保护。
同一份记录里还有一句很诚实的话：「本次没有重跑旧版 60 个入口的全部真实请求，它们的历史验证日期保留在原章节。」——这也正好说明我这次独立复核补上了什么。
我的独立复核：76 个端点返回真实数据，两次扫描的失败项还不一样
先说作者自带的联网测试。V3.9.0 的 31 个新入口用真实交易日跑，我跑了两轮，每轮 30/31 通过，但两轮失败的不是同一个端点：第一轮挂在通达信盘后包（下载被截断，BadZipFile），第二轮挂在 ST 名单（返回空，报「不能当成完整快照」），而单独复跑这两个端点又都正常（ST 名单 208 行，盘后包 52,314 行）。同一份代码、同一个网络，失败项在漂——这就是这类工具的日常。
官方数据源的联网用例 142 条里 140 过 2 错：中证指数那台 xls 主机连不上（同一次运行里国证成分 100 行是好的），以及上交所两融备份报「该日数据未发布或分页不完整」，而同一天的深交所版返回 2,105 行。
然后是我自己的扫描。用真实参数（贵州茅台 600519、2026-09-18 交易日）逐个调用：
| 端点 | 拿到什么 | 行数 |
|---|---|---|
| tdx_daily_package | 一个交易日沪深北全部证券日线 | 52,314 |
| options_daily（中金所） | 股指期权日行情与 Delta | 6,546 |
| sge_spot | 上海金现货日线 | 2,368 |
| equity_pledge | 股权质押 | 2,212 |
| lpr_history | 1 年 / 5 年 LPR 全历史 | 1,538 |
| futures_position_rank | 会员持仓排名 | 1,320 |
| etf_shares | 上交所 ETF 份额 | 912 |
| repo_fixing_rates | 回购定盘利率 | 747 |
| eastmoney_reports | 个股研报 | 500 |
| st_stock_list | 沪深京 ST 名单 | 208 |
| em_zt_pool | 涨停池（78 只） | 78 |
| sina_research_reports | 新浪研报列表（第二来源） | 40 |
103 个函数名里 76 个返回非空真实数据。没通过的那批，我把原因分成了三类：沙盒环境（申万站点在这台机器上 SSL 证书校验失败，curl 同样失败；通达信 TCP 那条路因为 #52 已经失效，报错前要等 93.57 秒逐台验活 10 台服务器）、源侧风控（东财 push2 系连着调之后直接拒连）、我自己的参数（期货实时接口不吃股票代码）。
还有一类要特别点出来：报错质量。北交所快照接口传旧日期会明确抛「北交所快照不是请求的交易日；本接口不提供历史回填」，而不是给你一份错的行情。这个项目把「确实没有数据」和「接口坏了」分开报错，是它跟一般爬虫脚本最大的区别。
装上去才会撞见的六个坑
第一，lxml 不在安装命令里。SKILL.md 的安装说明是 pip install mootdx requests pandas stockstats numpy baostock xlrd openpyxl，但 ths_eps_forecast()（机构一致预期 EPS）和 full_valuation() 走的是 pd.read_html，缺 lxml 就直接 ImportError: Missing optional dependency 'lxml'。我补装后，这两个端点分别返回 3 行和 12 行。有意思的是，被拒的社区 PR #22 里恰好有一条改动就是「ths_eps_forecast() 增加 lxml 依赖说明」。
第二，baostock 是硬依赖。估值历史（PE/PB/PS/PCF + 换手率 + 停牌 + ST）和上市退市日这两个端点只走 baostock，装上才有数据（6 行标的信息、14 行估值历史）。作者在 CHANGELOG 里承认过：「零第三方封装依赖」这句话现在只适用于其余端点。
第三，日期格式是 YYYYMMDD，填错不报错。em_zt_pool("2026-09-18") 返回 0 行、没有任何提示；em_zt_pool("20260918") 返回 78 行。同一个库里多数端点的日期参数是 YYYY-MM-DD，只有打板层这几个要紧凑格式，是很容易踩的静默空。
第四，东财风控是真的，而且表现为「静默空表」。作者的对策做得很扎实：所有东财请求统一走 em_get()——串行、最小间隔 1 秒加随机抖动、复用 Keep-Alive 会话、403 不重试（重试反而加重）、带正常 UA 与 Referer。但我连着扫了一百多次调用之后，push2 系端点开始连接被拒；更麻烦的是同一组参数在两次扫描里，资金流端点第一次返回 100 行、第二次返回 0 行。调用方拿到的不是报错，是空表。
第五，通达信那条路已经半废。tdx_client() 依赖的 mootdx 库 2024 年就停更了，2026 年 9 月起通达信公开服务器的 K 线、盘口、逐笔全部返回 0 行（issue #52，作者自己开的）。现在只剩财务快照和 F10 能用，K 线改走腾讯和通达信官网盘后包。作者没有删掉这个端点，而是让报错直接指路——这个处理是对的，但你要是照抄了半年前的教程，会先浪费 90 秒等它失败。
第六，SKILL.md 里没有免责声明。README 的最后有「本项目仅提供数据获取工具，不构成任何投资建议」，但这份 408 KB、真正被 AI 读进上下文的文件里，一个字都没有。它面对的是「帮我看看这只股票」这类问题，而投资建议的边界只写在不会进模型上下文的那个文件里。
争议：社区要拆四次，作者的原话是「有意产品决策，长期保持」
a-stock-data 最有意思的地方不是它写了什么，是它长成了什么形状。
SKILL.md 现在是 408,549 字节、7,289 行，其中 41,945 个汉字、89 个代码块、5,772 行代码。Anthropic 官方《Skill 编写最佳实践》里有一句：「将 SKILL.md 正文保持在 500 行以内以获得最佳性能；接近此限制时将内容拆分为单独的文件。」这里是那个数的 14.6 倍。
它不是一天长成的。我把每个提交点的文件大小拉了出来：5 月 30 日的 v3.2.1 是 2,090 行 / 78 KB，7 月 10 日 2,648 行，8 月 19 日 4,137 行，9 月 20 日的 v3.9.0 一步从 4,552 行加到 7,288 行——113 天里行数涨了 3.5 倍，字节数涨了 5.2 倍。
社区不是没看见。6 月 2 日 issue #21 的原话是「当前 skill 巨大，读一次 token 就没好多」；6 月 3 日有人交了 PR #22，一份完整的渐进式披露重构：把 SKILL.md 改成轻量路由入口，端点实现拆进 scripts/，说明拆进 references/，连 agents/openai.yaml 和 smoke test 脚本都写了；6 月 17 日 #27 建议用 Anthropic 的 skill-creator 重新 review；6 月 22 日 #29 逐条给出了拆分方案，包括统一 JSON 输出契约。
作者 7 月 10 日给了最终答复，并把理由摊开：单文件自包含是有意产品决策，长期保持，不做目录化拆分。三条理由——① 「形态即卖点」，拷一个文件就能用，过去两周有 3,000+ 人 clone、1,400+ 人直接在 GitHub 上读 SKILL.md，拆分换不来这种可携性；② 单人维护下「拆分版 + 单文件版」双形态必然漂移，漂移比 token 成本更伤用户；③ token 痛点用不改形态的方式缓解——把 description 收窄，因为「误触发才是最大的浪费」，当时的口径是「此前任何 A 股话题都可能误触发加载 50K token」。
第 ③ 条是真的落地了：现在的 description 明确写着「仅在需要调用数据接口取数时使用」，并且点名排除「A 股概念解释、投资观点讨论、策略问答」；文首还有一张「端点路由速查」总表，鼓励按需局部读取。
但数字也摆在明面上：他当时说「误触发一次 5 万 token」的时候，文件是 2,177 行；现在是 7,289 行。按常见分词器粗算，一次完整加载约 11 万 token（我的算法：4.2 万个汉字约 1 token 一个，26 万字符的代码与英文按约 3.5 字符一个 token，实际数字取决于分词器，但量级没有争议）。他自己在 #21 里留了后门：「如果未来端点规模翻倍、单文件确实不可持续，会重新评估」——v3.2 到 v3.9，端点从大约 30 个走到 85 个。
还有一个数字值得一起看：这个仓库 12 个 PR，一个都没合并。作者在 issue 里承认过 PR 里的问题，然后自己重写一遍进 CHANGELOG（比如 PR #20 的巨潮 orgId 动态化，v3.2.2 里以作者自己的改动落地）。这不一定是坏事——issue #27 里一位用户让 GLM 跑 review，报的五条里最重的一条被作者核对后确认并修掉：full_valuation() 按列位置 iloc[2] 取 EPS，实际取到的是同花顺的「最小值」列而不是「均值」，导致 PE 与 PEG 长期系统性偏差。作者改成了按列名取。但你也该知道，这个仓库的演进节奏完全由一个人决定。
顺带一句：这类工具的地基一直在动。CHANGELOG 的 FAQ 里有一节叫「已死透别用」——网易财经整站下线、和讯、凤凰行情、腾讯资金流接口、雪球免登录数据，全死了；mootdx 库 2024 年停更；2026 年 9 月通达信公开服务器的行情命令集体返回 0 行。「34 个数据源」不是一个稳定数字，而是一份随时会过期、需要有人持续跟进的快照。
判断：什么时候该拷这个文件
它值得用的场景很明确：你要让 AI 或者脚本以最低的安装摩擦拿到 A 股数据，能接受「一个人维护、会随版本跟进」；你在国内网络（我这台机器出口是广州联通的 IP，实测 76 个端点直接返回真实数据）；你需要的是单次或低频取数，认可它把数据边界写清楚的做法——每个端点标注数据来源、口径、实测日期，连「大商所官网有 JS 反爬、HTTP 返回 412 所以没接」都写在文档里。这种诚实度在国内数据接口项目里并不多见。
不该用的场景也一样明确：别把它装成常驻自动触发的 skill，除非你已经想好每次触发 11 万 token 的代价，更划算的做法是把它当一个手册放在项目目录里，让 agent 按层局部读——这也正是作者推荐的用法；别拿它做高频批量，东财的风控会以「空表」而不是报错的形式找上你；别指望回测，作者的 FAQ 里写明了本 skill 不带回测；也别指望所有源永远活着，你真正买到的是「源死了有人改」这条流水线。
类似的取舍在其他评测里也出现过：零密钥的方案往往要靠轮换多个不稳定的公开源来换取免注册（Wigolo，18 个搜索源实测只剩 1 个在干活）；而当一个生态由单人维护时，社区贡献会以「被采纳但不合并」的方式落地，这一点在 Spec Kit 那份评测里也能看到同一个规律。
至于「单文件还是渐进式披露」，这不是一个非黑即白的工程问题。作者用 113 天和一个 408 KB 的文件给出了他的答案：可携性优先，token 靠收窄触发来省，而不是靠拆目录。这个答案在「拷走就能用」的传播场景里是成立的，在「长期常驻、天天触发」的用法里就不成立——所以真正需要你自己判断的，不是他对不对，而是你打算怎么用它。