技能介绍

要解决的问题

读一份 10-K，往往意味着先在 EDGAR 的检索页里按 CIK 和表单类型筛选，再从几十个 HTML 附件里找到主文档，最后手动把资产负债表和利润表的数字抄进表格。10-Q 和 8-K 的问题在于结构不统一：有的把附注拆成多个 exhibit，有的表格直接嵌在正文里，行内 XBRL 标签也不尽相同。

结果是，同一套分析流程换个季度就要重新对一遍字段，自动化脚本很容易在一次改版后静默失效——数字取错了，可能几周后才在回测里被发现。

这个技能做了什么

把整条链路拆成两步：先定位文件，再取结构化数据。

文件检索：通过 EDGAR Full-Text Search API 和 company filing API 按公司与表单类型拉取 10-K、10-Q、8-K 的申报清单，拿到文档地址和申报日期，而不是靠人眼在网页上翻。
结构化提取：走 SEC 的 XBRL API，直接读取公司事实（company facts）与实例文档，把 us-gaap 命名空间下的科目映射成机器可用的键值，而不是解析 HTML 表格。
财务分析：以结构化结果为基础做资产负债表和利润表分析，跨期比较和同科目对齐都在数据层完成，不需要重新定位表格位置。

这样做的好处是口径稳定：XBRL 标签由申报方在提交时声明，字段含义由 US GAAP 分类标准定义，比 HTML 表格的行列位置可靠得多。

适用边界与注意点

覆盖范围有限：结构化能力集中在资产负债表和利润表相关的科目；现金流量表、附注中的明细项目，以及 8-K 里的文字性披露仍需要回到原始文档处理。
XBRL 并不总是干净：同一概念可能同时存在 us-gaap 与 dei 两个命名空间，也可能有 FY、QI 不同的期间定义。直接按标签名聚合之前，先确认期间口径，否则季度值会被年度值污染。
重述与修订：公司会在后续申报中重述历史数据，XBRL API 通常返回最新快照。如果分析需要与当时披露一致的数值，需要回到具体文档的 fact 版本。
上游说明缺失：SKILL.md 中未能自动提取到有来源依据的安装与使用说明。在接入财报校验、风控回测这类对正确性敏感的流程之前，先阅读上游项目并自行验证一次完整调用。