3,018 个文件 · 2377 份报告 · 111 家公司 · 153 个专题目录
AI Berkshire 的报告在哪、怎么找、怎么读
这个项目最容易被低估的部分不是 Skill，而是它攒下来的报告语料：
reports/ 目录在 commit 55be4f7 下有 3,018 个文件，
官方横幅则写「2377 份报告 · 111 家公司 · 23 个专题」。
两个数字不一样，原因本文会讲清。更重要的是怎么读才能不被它骗。
- 索引是自动生成的：
reports/README.md由tools/reports_index.py写出，不要手工编辑 - 公司目录里常带独立审计工作区，里面有抽检清单、判决与工具原始输出
- 数字口径来自本站实测：文件数 3,018 / 平铺 83 / 嵌套 2,933 / 专题目录 153
一眼看懂这堆报告
按 commit 55be4f7 实测（2026-09-28）：
- 3,018 个文件（其中 .md 平铺 83 个、嵌套 2,933 个）
- 153 个专题子目录被索引工具识别
- 2377 份报告 / 111 家公司 / 23 个专题，是官方横幅口径
- 205,116 字节 =
reports/README.md的索引体积 - 更新痕迹：仓库首页显示 reports 目录 8 小时前有新提交
AI Berkshire · WHERE THE REPORTS LIVE
报告都在哪、怎么组织
| 位置 / 分区 | 放什么 | 怎么找 | 更新频率 | 注意点 |
|---|---|---|---|---|
reports/ 根目录（平铺 .md 83 个） | 单篇报告直接放在根下 | 按文件名读，文件名里带公司或主题 | 每出新报告 | 平铺是因为归档需要时间，新报告常常先落在根目录 |
reports/<公司名>/（例：拼多多） | 同一家公司的多份报告与审计 | 先按公司目录进，再看里面的子目录 | 每次研究该公司 | 目录名用中文公司名，不含股票代码 |
reports/<公司名>/审计-YYYYMMDD/ | 抽检工作区：sources.md、审计判决.txt、工具原始输出.json | 看目录名里最新的日期 | 每做一轮审计 | 同一家公司会有多轮，日期不同就是不同批次 |
reports/<专题名>-YYYYMMDD/ | 横评与专题研究 | 扫 reports/ 下一层的目录名 | 专题完成时 | 这类目录常带完整核查工作区，例：七公司五年回报与资金配置-20260906 |
reports/README.md（205,116 字节） | 自动生成的总索引，五个分区 | 直接打开这一个文件就够 | reports_index.py 每跑一次 | 标注「请勿手工编辑」，手改会在下次生成时被覆盖 |
根目录 README.md 的横幅 | 只给汇总数字（2377 份 / 111 家公司 / 23 个专题） | 在仓库首页第一屏就能看到 | 同上 | 横幅是汇总口径，与逐目录数文件得到的数字本来就不是一回事 |
reports/MINIMAX/审计-20260906/ | 年报 PDF + 抽取文本 + audit-*.json + 复算脚本 | 审计目录里逐个看 | 每轮审计 | 能看到原始 PDF 与机器抽取结果的对照，这是最完整的形态 |
本表按 commit 55be4f7 的目录实测整理。找报告时优先信目录结构与文件本身，再看索引里的汇总数字。
本板块依据 AI Berkshire 官方仓库 commit 55be4f7 与本站 2026-09-28 实测整理。
AI Berkshire · HOW THE INDEX IS BUILT
索引是怎么自动生成的
自动索引是怎么跑出来的
索引不是手写的，是一条命令的产物。理解这条链路，就能判断「2377 份报告」这句话到底指的是什么。
python tools/reports_index.py在仓库根目录执行，它会重新生成 reports/README.md 的索引区，并同步根 README 的横幅数字。这是官方指定的生成方式。
预期输出：打印扫描到的报告与公司数量，随后写回索引文件。
<!-- REPORTS-BANNER:START --> … <!-- REPORTS-BANNER:END -->
<!-- REPORTS-INDEX:START --> … <!-- REPORTS-INDEX:END -->横幅与索引区都用 HTML 注释标记夹住。工具只替换标记之间的内容，标记之外的说明文字保持不动。
预期输出：手工写在标记外的段落不会被覆盖；标记本身写错则结果不可预期。
工具遍历 reports/，把目录归到「按公司」「专题研究」等分区，并从文件里读出类型标签与日期。
预期输出：按公司区里每家公司显示成「N 份 · 最近 YYYY-MM-DD」。
仓库里用 local/ 存放不该公开的内容（例：tools/twstock_data.py 的 token 放在 local/finmind_token.txt）。工具会跳过被忽略的文件，以免私有内容被写进公开索引。
预期输出：被忽略的文件不会出现在索引里——所以索引条数天然小于磁盘文件数。
最近更新 / 按公司 / 专题研究 / 大师研究 / 筛选池 五个区一次性整体重建，不做增量拼接。
预期输出：索引区旧内容全部被替换；重复运行结果稳定。
| 标记 / 约定 | 作用 | 写错或忽略会怎样 | 谁维护 |
|---|---|---|---|
REPORTS-BANNER 标记 | 界定根 README 里被自动刷新的汇总数字 | 标记缺失时横幅不再更新，数字会停在旧值 | 生成工具 |
REPORTS-INDEX 标记 | 界定 reports/README.md 的索引区 | 标记错位会让索引把手工说明一起吃掉 | 生成工具 |
| 类型标签 | 给每条记录标注它是研究、公众号还是底稿 | 标签缺失则该条在分区里无法归类 | 报告作者 |
日期后缀 -YYYYMMDD | 区分同一主题的多轮产出 | 无日期时无法判断哪一版最新 | 报告作者 |
local/ 目录约定 | 存放 token 等不公开内容 | 放错位置会被写进公开索引 | 仓库维护者 |
N 份 · 最近 YYYY-MM-DD 文案 | 让读者一眼看出这家公司的报告量与新鲜度 | 文案被手改后会被下次生成覆盖 | 生成工具 |
这张表把「哪些能手改、哪些会被覆盖」讲清楚。判断方法很简单：在标记区里的内容都是生成物。
本板块依据 AI Berkshire 官方资料与本站实测输出整理，证据等级见事实与版本页。
AI Berkshire · FIVE SECTIONS
五个分区怎么用
| 索引分区 | 收录什么 | 适合谁 | 怎么用 | 局限 |
|---|---|---|---|---|
| 最近更新 | 按时间倒序的最新报告 | 想跟进度的人 | 每周扫一次，看有没有自己关注的标的 | 只反映提交时间，不代表结论新鲜 |
| 按公司 | 以公司为单位的全部报告，折叠展示，标注份数与最近日期 | 研究单一标的的人 | 搜公司名 → 展开 → 按斜体小标题（如审计、系列名）挑 | 公司名是中文名，按拼音或代码搜不到 |
| 专题研究 | 横评、行业与主题类研究 | 做横向对比的人 | 按专题名进目录，看目录里的核查工作区 | 专题粒度不一，有的含十几家公司，有的只一家 |
| 大师研究 | 按巴菲特、芒格、段永平、李录视角整理的合集 | 想学方法论的人 | 当方法论案例读，而不是当推荐清单读 | 视角是分析方法，不是买卖建议 |
| 筛选池 | 经过筛选逻辑筛出来的候选集合 | 想找研究起点的人 | 把它当候选池，再逐只用单公司流程验证 | 入池不等于值得买，筛选条件本身也要核对 |
reports/README.md 总索引 | 以上五个区的统一入口，205,116 字节 | 第一次来的人 | 先看开头横幅，再用五个分组锚点跳转 | 文件很大，不要试图通读，按需跳转 |
五个分区解决的是「从哪进来」的问题；进来之后每份报告值不值得信，要靠下一节的三查清单和报告审计流程。
本板块依据 AI Berkshire 官方仓库 commit 55be4f7 与本站 2026-09-28 实测整理。
AI Berkshire · TYPE LABELS
报告类型标签体系
| 类型标签 | 含义 | 典型内容 | 读者该拿它做什么 |
|---|---|---|---|
| 研究 | 完整的研究报告，通常来自深度研究类 Skill | 公司基本面、估值区间、结论与风险 | 当主线索读，但要自己核对数据来源与假设 |
| 公众号 | 面向公开发布的改写稿 | 更口语、更短、带叙事 | 当入门读物，不要当数据来源 |
| 底稿 | 研究过程中的原始材料与中间结论 | 数据摘录、计算过程、对照表 | 核对结论时最有用的一类，优先看它 |
| 财报 | 对一手财报文件的精读产物 | 按季度的经营数据与解读 | 核对数字是否来自原始财报，而非二手平台 |
| 深度系列 | 同一主题的多篇长文系列 | 例：《看懂拼多多》这类成组文章 | 按系列顺序读，单篇可能缺上下文 |
| 横评对比 | 多家公司同口径对比 | 同一指标下的横向排名与取舍 | 注意口径是否统一，跨市场对比尤其要查币种 |
| 估值仓位 | 估值结论与仓位建议的结合 | 目标价区间、仓位比例 | 仓位建议属个人判断，不能直接照搬 |
| 筛选 | 按规则筛出的候选集合 | 入选名单与筛选条件 | 先看筛选条件是否合理，再看名单 |
类型标签决定「该信到什么程度」：底稿与财报类最硬，公众号类最软；横评类要先确认口径统一。标签本身是作者标注的，本站未逐份复核。
本板块依据 AI Berkshire 官方资料与本站实测输出整理，证据等级见事实与版本页。
AI Berkshire · ANATOMY OF A REPORT
一份报告该有什么
| 一份报告该有的组成部分 | 为什么重要 | 缺了会怎样 |
|---|---|---|
| 信息丰富度评级（A/B/C） | 先声明这家公司资料够不够，决定后面能说多硬的话 | 读者会把「资料少」误当成「确定性高」 |
| AI 研究局限性声明 | 明确这是研究辅助而非投资建议 | 容易被当成买卖信号使用 |
| 数据来源与口径（来源、日期、复权方式） | 同一指标不同口径能差出几十个百分点 | 复权方式不明时，历史价格对比全不可信 |
| 事实 / 推断 / 假设分开写 | 让读者能逐句判断哪部分是硬数据 | 推断被当事实读，是 AI 报告最典型的失真 |
| 反方证据与失败路径 | 避免只列优点的单向叙事 | 结论看起来完美，但没回答「什么情况下会死」 |
| 估值与安全边际（含全部假设） | 假设写不清，估值区间就没有意义 | 无法复核，也无法做敏感性判断 |
| AI 分析置信度 vs 投资确定性 | 两个概念被官方要求分开写 | 把「分析很确定」误读为「这笔投资很确定」 |
| C 级标的的「需要一手验证的问题清单」 | 资料不足时必须列出该去查什么 | 读者拿到一份看起来很完整、实则无依据的报告 |
以上对齐 skills/investment-research.md 对输出的硬性要求。深度研究报告按约定写到 ~/[公司名]投资研究报告.md，所以你在本地也能找到自己跑出来的那一份。
本板块依据 AI Berkshire 官方仓库 commit 55be4f7 与本站 2026-09-28 实测整理。
AI Berkshire · HOW TO READ IT SAFELY
怎么读得放心，以及发现错误怎么反馈
| 检查项（三查清单） | 怎么查 | 能用的工具 | 发现问题怎么办 |
|---|---|---|---|
| 一查数字：关键值是否可复现 | 把市值、PE、营收等关键数字按公式重算一遍 | financial_rigor.py verify-market-cap（实测 510 HKD × 9.11e9 股 → 偏差 0.08%） | 偏差超过 1% 就在报告里标注，不要静默改数 |
| 二查来源：是否一手、是否同日同口径 | 看数据来源与日期，跨市场要确认币种 | cross-validate（注意其默认容差 2.0% 与规范的 1% 分档不一致） | 口径不一致时补第二来源，并在报告里写清差异原因 |
| 三查结论：有没有反方证据与假设 | 读结论段，看是否写了失败路径与关键假设 | 人工阅读，比任何脚本都有效 | 缺反方证据就退回重写，不要只补一句免责声明 |
| 抽查比例是否达标 | 一份长报告按 15% 抽样核对点数 | report_audit.py extract（实测 8 行 × 5 列 → 抽 6 个点） | 抽样不足时补抽，或直接退回 |
| 是否经过终值复算 | 含十年折现估值的报告要再跑一次硬约束校验 | terminal_value.py audit 的三条硬约束 | 写报告时若回头改过 g 或 r，必须重跑 |
| 结论能否被复现 | 换一个人按报告里写的来源与公式能否算出来 | 无工具可替代，只能实测一次 | 不能复现的部分，降级为「未验证」并写清楚 |
发现报告里的数据错误时，官方准备了专门的数据错误 issue 模板，它强制要求填五项：标的 + 出错的 Skill 或报告路径 + 错误值 + 正确值及其可核实来源链接 + 复现命令。模板里明确写了「只说『数据经常错』而不给具体例子无法核实」。所以反馈时请直接给出可以点开的来源，而不是一句结论。
想系统学核验流程，去看报告审计页；只想确认数字口径，去看事实与版本页。
本板块依据 AI Berkshire 官方资料与本站实测输出整理，证据等级见事实与版本页。
AI Berkshire · FAQ
AI Berkshire 报告索引常见问题
2377 份和 3018 个到底哪个对？
两个都对，只是口径不同。2377 份报告是官方横幅的汇总口径（由 tools/reports_index.py 写出），3,018 个文件是本站直接数 reports/ 目录得到的（其中平铺 .md 83 个、嵌套 2,933 个、专题子目录 153 个）。差异有三个来源：一份报告常伴随多个附属文件（抽取文本、审计判决、原始输出 JSON、复算脚本）；生成工具会跳过被 .gitignore 命中的私有文件；盘点时点不同也会有增减。所以看数量时先问自己：数的是「报告」还是「文件」。
这些报告是官方结论吗？我能直接抄吗？
它们是这个开源项目作者的研究产出，不是监管机构或交易所的结论，也不是可引用的第三方研究。直接照搬结论有两个风险：一是报告有明确的数据截止日期，过了时点结论会失效；二是每份报告都建立在假设之上（增长率、折现率、可比公司选择），假设换了结论就变。更稳妥的用法是把报告当成研究底稿——看它怎么取数、怎么推理，然后自己复核关键数字。本站不做任何标的推荐，也不转发报告里的收益类表述。
报告会过期吗？怎么看它的时效？
会。判断方法有三层：看目录名或文件名里的日期后缀（同一主题常有多轮，如 审计-20260906）；看报告里写的数据截止日，而不是文件提交时间；看估值结论是否依赖了会变的输入——依赖未来增速假设的估值，比依赖当期资产负债表的分析更快失效。官方横幅统一标「更新至 2026-09-28」，但这是索引整体的时点，不等于每一份报告都截止在那一天。
为什么索引文件这么大、还没法手工整理？
reports/README.md 有 205,116 字节，因为它把每一家公司和每一个专题都列了进去，而且文件头明确写着「由 tools/reports_index.py 自动生成，请勿手工编辑」。任何手工润色都会在下次运行生成工具时被覆盖。正确用法是把它当可跳转的目录：先看开头横幅建立总量概念，再用五个分区锚点直接跳到目标公司或专题，不要试图通读。
有没有英文或日文的报告？
仓库根目录的说明文档有三语版本（README.md 35,166 字节、README_EN.md 35,517 字节、README_JA.md 43,041 字节），但报告语料本身以中文为主，公司目录用的是中文公司名。本站没有逐份统计报告的语言分布，所以不能给出准确的多语言比例；如果你需要特定语言的资料，请直接在目录里核对，不要依赖本页的推测。
发现报告里的数据错了，怎么反馈才有效？
官方专门提供了数据错误 issue 模板，它强制要求五项信息：标的、出错的 Skill 或报告路径、错误值、正确值及其可核实来源链接、复现命令。模板里明确写了「只说『数据经常错』而不给具体例子无法核实，会被要求补充」。换句话说：给对方一个能点开的来源 + 一条能重跑的命令，比写十句抱怨都有用。