pinned commit 55be4f7 · 核验日期 2026-09-28
AI Berkshire 事实与版本：把互相矛盾的数字逐个核到文件
同一个项目，第三方文章会写成 16 个、18 个、20 个 Skill，Star 数也各不一样。 原因不神秘：官方仓库内部本来就有不止一套口径。 本页把每个数字拆成「官方怎么写 / 实测是多少 / 为什么会对不上」，并给出你可以自己复核的命令。
- 依据 commit
55be4f7（2026-09-27 最后提交 · 2026-09-28 核验） - Skill 数 21（README 标题写 20）、报告文件 3,018（README 横幅写 2377）
- 没有 Release、没有 WebUI、没有 REST API、没有本地模型——逐条给依据
- 另附 7 处「上游文档与实现不一致」，含本站实跑反例
AI Berkshire · VERIFICATION SNAPSHOT
核验快照：本页数字的出处与采集方式
| 核验项 | 本页取值 | 来源 | 采集方式 |
|---|---|---|---|
| 仓库全名 | xbtlin/ai-berkshire（非 fork） | GitHub API repos | API 直读 |
| 默认分支 | main | GitHub API default_branch | API 直读 |
| 依据 commit | 55be4f77ba9c1aeb0cfb98c0eed78babc2433706 | GitHub API commits | API 直读 |
| 提交总数 | 1,553 | git rev-list --count HEAD | 真实 clone 后本地计数 |
| 许可 | MIT | GitHub API license.spdx_id + 仓库根 LICENSE | API 与文件双核对 |
| Star / Fork | 16,562 / 2,477 | GitHub API stargazers_count / forks_count | API 直读，截图同值（16.6k / 2.5k） |
| 创建 / 最后推送 | 2026-04-07 / 2026-09-27T18:07:45Z | GitHub API created_at / pushed_at | API 直读 |
| 仓库体积 | 73,733 KB（约 72 MB） | GitHub API size | API 直读 |
| 主语言标记 | HTML（不是 Python） | GitHub API language | API 直读，成因见下方问答 |
本页所有数字都可复核：git clone https://github.com/xbtlin/ai-berkshire.git 后执行 git checkout 55be4f7 与 git rev-list --count HEAD 即可复现提交数。会随时间变化的字段（Star / Fork / issues）已标注采集日期，引用时请一并带上日期。
本板块依据 AI Berkshire 官方仓库 commit 55be4f7 与本站 2026-09-28 实测整理。
AI Berkshire · COUNT CONFLICTS
为什么同一个项目会被写成不同数字
| 口径 | 官方怎么写 | 本站实测 | 为什么会不一样 | 读文章时怎么判断 |
|---|---|---|---|---|
| Skill 数量 | README 小标题「Skills 一览（20个）」 | skills/*.md = 21 个文件 | 标题没跟上：同一张表实际列了 21 行，标题仍是 20 | 数文件，不数别人的文章 |
| Codex 侧 Skill | README 未单独给数字 | codex-skills/ = 22 个目录 | 多出的 investment-memo-craft 是 Codex 专用手写包，不在生成链里（同步检查脚本只核对 21 个） | 先分清「Claude 侧 21」与「Codex 侧 22」 |
| 报告份数 | README 横幅与 reports/README.md 均写「2377 份报告」 | reports/ 真实 3,018 个文件 | 横幅由 tools/reports_index.py 自动写入，统计口径是「报告」；3,018 是文件数，含审计工作区、JSON、PDF 等 | 看口径：文件数 ≠ 报告数 |
| 公司数 / 专题数 | 「111 家公司 · 23 个专题」 | 专题子目录 153 个 | 23 个专题指策展专题，153 是仓库里全部一级子目录，两者不是同一个集合 | 问「这个数字统计的是什么」 |
| 报告目录构成 | 未说明 | 平铺 .md 83 个 + 嵌套 2,933 个 | 嵌套目录里混着「审计-20260906」这类工作区（含抽取 txt、判决 txt、复算脚本） | 同一个数字可能指不同东西 |
| issues 数 | 仓库页显示 Issues 24 + Pull requests 7 | GitHub API open_issues_count = 31 | GitHub API 把 Pull Request 也算进 issues 计数，所以 31 = 24 + 7 | 两个都对，看口径；引 API 值要说明含 PR |
| 测试覆盖 | docs/ROADMAP.md 把「为核心工具增加单元测试」列为 P2（6 个月+） | tests/ 已有 26 个测试且全部通过 | ROADMAP 是计划文档，落后于实际进展；测试只覆盖 financial_rigor.py 与 report_audit.py | 以仓库现状为准，别按计划文档估进度 |
| A 股数据源 | ROADMAP P0 = 「A 股数据源接入（akshare、东方财富）」 | tools/ashare_data.py 已存在（12,845 B，零依赖，4 个子命令） | 同为计划落后于实现：P0 想做的东西已经做了一部分 | 同上；但已有 ≠ 覆盖全部 A 股场景 |
这八行是本页最值得先看的内容：它解释了为什么同一个项目会被写成不同数字。每条都给了「官方写法 / 实测值 / 原因 / 使用建议」四列，请按最后一列决定该信哪个——本文不评价作者，只记录 commit 55be4f7 的实测结果。
本板块依据 AI Berkshire 官方资料与本站实测输出整理，证据等级见事实与版本页。
AI Berkshire · EVIDENCE LEVELS
本站的四级证据与判定标准
docs/ 直接写明的。例：MIT 许可、Star 16.6k、issue 模板要求附可核实来源。.bat 覆盖式安装、report_audit.py 容差 1%、A 股推荐源是东方财富 + 巨潮。| 等级 | 判定标准 | 本项目实例 | 页面上怎么标 |
|---|---|---|---|
| 官方确认 | README / GitHub API / docs/ 直接写明 | MIT 许可、Star 16,562，以及「Skills 一览（20个）」这个标题本身 | 「官方确认（README）」 |
| 源码推断 | 必须读文件内容才能得到 | .bat 先 rmdir 再 xcopy；verdict 容差常量 1%；A 股主源是东财 + 巨潮 | 「源码已核验」 |
| 本站实测 | 本机真实跑出来的输出 | 15 条 CLI 命令 exit=0；26 个单元测试全通过；偏差 3% 且副源命中时仍输出【准出】 | 「本站实测」 |
| 尚未证实 | 没有任何支撑，或无法由第三方复现 | 作者本人的实盘业绩；某个标的的研究结论是否正确 | 留白不写，或显式标注「未实测」 |
| 版本敏感 | 数字会随时间变化 | Star / Fork / issues 数、报告份数 | 标采集日期 + 「会随社区变化」 |
| 计划文档 | 作者写的路线图，不等于现状 | ROADMAP 的 P0/P2 与 tests/、ashare_data.py 的实际进度不一致 | 「官方计划，非现状」 |
这张表就是本站的核对口径。凡是没能落进前四行里某一行的说法，本页不写；凡是落进「尚未证实」的，一律留白——这也是本站与「把 README 换个说法重写一遍」的教程最直接的区别。
本板块依据 AI Berkshire 官方仓库 commit 55be4f7 与本站 2026-09-28 实测整理。
AI Berkshire · BOUNDARIES
它没有的东西：逐条给依据
| 容易被误以为有的能力 | 实际情况 | 依据 |
|---|---|---|
| 可下载的 Release 安装包 | 没有 Release | GitHub API 无 release 记录；仓库页只有分支与 1 个 Tag |
| pip / npm 一键安装 | 没有发布包，安装方式是 clone 仓库后运行安装脚本 | 官方给出的两条路线都是「装客户端 + 跑 scripts/ 下的安装脚本」 |
| 网页版 / WebUI | 没有 | commit 55be4f7 的真实文件树中无 server / web 目录，README 亦未提及 |
| REST API 服务 | 没有 | 同上：仓库不含任何 HTTP 服务入口 |
| 本地模型 / GPU 推理 | 没有 | 仓库不含模型权重与推理代码；Skill 依赖外部客户端及其模型配额 |
| 行情数据库 | 没有 | 约 72 MB 的仓库里绝大部分是 reports/ 的文本与 HTML |
| 交易执行 / 下单 | 没有 | 官方定位是研究工作流；工具层只做计算与报告抽检 |
| 自动选股 / 保证收益 | 没有，也不该这样用 | 官方 README 与本站边界页口径一致：只做研究，不构成投资建议 |
这一栏是本站补的，官方 README 没有做这类否定式说明。之所以要写，是因为第三方文章曾把它描述成本地代码助手、WebUI 与 REST API 服务——那些能力在真实文件树里不存在。判断方法很简单：clone 之后列一遍根目录，看不见的功能就是没有。
本板块依据 AI Berkshire 官方资料与本站实测输出整理，证据等级见事实与版本页。
AI Berkshire · DOC VS IMPLEMENTATION
上游文档与实现不一致的七处
| 项目 | 文档怎么写 | 实测行为 | 影响 | 规避做法 |
|---|---|---|---|---|
report_audit.py verdict 打回条件 | skills/investment-research.md：「任意点偏差 > 1% → 打回」 | 只有主来源与第二来源同时超 1% 才判【打回】（exit 1）；单侧超标只给「⚠️ 警告」，仍输出【准出】（exit 0） | 单侧偏差的报告不会被脚本拦住 | 把「警告」当人工复核触发条件，别只看 exit code |
| 未提供第二来源时 | 要求交叉验证 | 只给 fetched_value 时永远不会打回 | 单源报告无法被脚本否决 | 强制填第二来源，缺则视为未完成审计 |
cross-validate 容差 | skills/financial-data.md：≤1% ✅ / 1–5% ⚠️ / >5% ❌ | 工具默认 --tolerance 2.0 | 1%–2% 的偏差在工具里显示「数据一致」 | 显式传 --tolerance 1.0 |
verify-market-cap 分档 | 同上 | ≤1% ✅ / >1% 且 ≤5% ⚠️ / >5% ❌ —— 与文档一致 | 无 | 照文档用即可 |
benford 前置条件 | README 未写 | 样本 < 50 时输出「⚠️ 样本量不足: 8 < 50, Benford分析不可靠」，且不报错、exit 0 | 容易把不可靠结果当成好结果 | 先看样本量，再看结论 |
stock_screener.py 参数 | README 未写 | 不接受 --help：会被当成 ticker 继续跑完整扫描，并在调用目录的上一级创建 data/watchlist.json | 误用会静默跑错并写文件 | 先读源码，或确认参数后再传 |
docs/ROADMAP.md 与现状 | P2 才计划「为核心工具增加单元测试」；P0 是「A 股数据源接入」 | tests/ 已有 26 个测试全通过；tools/ashare_data.py 已存在 | 按 ROADMAP 判断会低估项目进度 | 以仓库现状为准，计划只作方向参考 |
这七行的意义不是挑错，而是给使用者两样东西：一是别把文档当成实现（照文档写「1% 就打回」，你会以为脚本能拦住所有超标数据）；二是知道该自己补哪一道关。完整复现步骤与本机输出原文见报告审计页。
本板块依据 AI Berkshire 官方仓库 commit 55be4f7 与本站 2026-09-28 实测整理。
AI Berkshire · VERSION TIMELINE
版本、时间线与自查命令
| 字段 | 值 | 含义 |
|---|---|---|
| 仓库创建 | 2026-04-07 | 项目起始时间 |
| 最后推送 | 2026-09-27T18:07:45Z | 最近一次代码或内容变更 |
| 依据 commit | 55be4f77ba9c1aeb0cfb98c0eed78babc2433706 | 本站所有引用的事实基线 |
| commit 时间 | 2026-09-28T02:07:42+08:00 | 与该 commit 对应的时间（本地时区） |
| 提交总数 | 1,553 | 迭代密度参考 |
| 分支与标签 | main + 2 Branches / 1 Tag | 有 tag，但没有对应的 Release 记录 |
| 三语 README | 35,166 B / 35,517 B / 43,041 B | 中 / 英 / 日三份，日文版体积更大 |
| 根目录约定文件 | AGENTS.md（Codex）、CLAUDE.md（Claude Code）、ai_CLAUDE.md 3,646 B | 两个客户端各有一份行为约定，是本项目「双客户端兼容」的落地方式 |
自己复核的命令（Windows / macOS / Linux 通用）：git clone https://github.com/xbtlin/ai-berkshire.git → cd ai-berkshire → git checkout 55be4f7 → git rev-list --count HEAD（应得 1,553）。再执行 python -m unittest discover -s tests -v 应得 26 个测试通过，python scripts/sync-codex-skills.py --check 应打印「Checked 21 Codex skills」。
本板块依据 AI Berkshire 官方资料与本站实测输出整理，证据等级见事实与版本页。
AI Berkshire · FAQ
AI Berkshire 事实与版本常见问题
这些数字会不会过期？
会。Star / Fork / issues 数、报告份数每天都在变，本页这些字段都标了采集日期（2026-09-28）。相对稳定的是结构性事实：许可（MIT）、安装方式、目录布局、文件数量级。引用本站数字时请连采集日期一起带；如果日期已过去很久，可以直接 clone 仓库重跑本页给出的自查命令。
为什么 GitHub 把主语言标成 HTML，而不是 Python？
因为 GitHub 的语言统计按字节体积算，而这个仓库体积的绝大部分是 reports/ 下的研究产出。实测 reports/ 有 3,018 个文件，其中相当一部分是 HTML 与 Markdown；而真正实现逻辑的 tools/ 只有 15 个文件（12 个 Python）。所以「主语言 HTML」不等于「这是个前端项目」——这一点第三方文章经常误读，甚至据此推测它有 WebUI。
没有 Release 包，我要怎么安装？
clone 仓库后运行安装脚本，官方提供两条客户端路线：Claude Code 与 Codex。Windows 用 scripts\install-*.bat，macOS / Linux 用对应的 .sh。需要注意两点：一是 Windows 脚本会覆盖式写入 %USERPROFILE%\.claude\commands 或 %CODEX_HOME%\skills（同名子目录先删后复制）；二是仓库有 1 个 Tag，但没有对应的 Release 记录，所以不存在「下载压缩包」这条更省事的路。分平台步骤与常见报错见开始上手页。
issues 到底是 31 还是 24？
两个都对，看口径。仓库页面显示的是 Issues 24 与 Pull requests 7；而 GitHub API 的 open_issues_count 字段把 PR 也算进去，所以是 31（= 24 + 7）。这正是不同文章数字对不上的常见来源之一——引用 API 值时应当说明「含 Pull Request」。
我该信第三方文章，还是信这里？
都不用直接信，可以自己验。本站的做法是把每条说法降级成「官方怎么写 / 实测是什么 / 原因 / 建议」四列，并把复核命令一起给出——git checkout 55be4f7、git rev-list --count HEAD、python -m unittest discover -s tests -v。如果本站写的与你在该 commit 上跑出来的结果不一致，以你的复现结果为准。本站不采用任何无法由第三方复现的说法（例如作者的实盘业绩），这类内容在边界页只作反面案例出现。
为什么本站要专门做一页事实核验？
因为这是同类教程最容易出问题、又最难被读者发现的地方。Skill 数量、报告份数、Star 数三个数字在本项目里官方自身就有多套口径，任何一篇只抄一段的文章都会写错，而读者没有动力去数文件。本站把冲突摆到台面上，并说明「读文章时怎么判断」——这比再复述一遍 README 有用。