作 者：老余捞鱼
原创不易，转载请标明出处及原作者。
文中示例仅用于技术讨论，不构成任何操作建议。
量化策略开发应以学习和技术交流为目的。
本号不荐股、不卖课、不承诺收益。
市场有风险，请合法合规投资。
本文约 2800 字 | 预计阅读 5-8 分钟，后有开源项目地址，建议先收藏。
· · ·
我最近看了GitHub上的AI Berkshire。读者里如果有人已经刷到过它，大概知道它是一个“用 Claude Code / Codex 做价值投资研究”的开源项目。但我在把它 underlying workflow 拆开之后，觉得它更像一个“研究系统设计样本”，而不只是一个投资分析项目。
这篇文章不是推荐项目，我想聊的是：它为什么值得做量化、做 AI 工具、做研究系统的人认真看一遍。
这不是一个选股神器，而是一套投研流水线
这个项目最值得看的，不是“AI 能不能帮你分析股票”，而是它有没有把投研流程做成可复现的工程系统。
图1：Skill / Agent / Tool 三层结构
第一层是 Skill 入口，中间是 Agent 分工，第三层是数据和验证工具。用户面对的不是一个聊天框，而是一组明确的工作流入口：深度研究、财报精读、行业筛选、持仓复盘、股价异动归因、写投研文章。
图2： 三层架构细化分析（本图片来自于GitHub原文）
仓库当前对外公开的 Skills 有 20 个，覆盖深度研究、财报分析、行业筛选、持仓管理、思维工具五大类。你可以在 README 里直接看到这些入口：/investment-research、/investment-team、/earnings-review、/industry-funnel、/news-pulse等。每个 Skill 都规定了输入、输出、验证步骤和报告结构，而不是一句“请帮我分析一下腾讯”。
对做量化和研究系统的人来讲，这种“把复杂任务拆成可调用流程”的思路，比单次问答更值得借鉴。它本质上是把研究 SOP 翻译成了机器可执行的 workflow。
把四位大师的方法论拆成可执行工作流
AI Berkshire 把巴菲特、芒格、段永平、李录四个人的视角，分别嵌入不同分析角色。一个研究任务会被拆成商业模式、财务估值、行业竞争、风险管理层四个维度，由不同 Agent 独立完成。最后不是简单拼稿，而是让 Team Lead 把冲突判断摆出来。
这四个人为什么这么分？项目里的设计其实很清楚：
- 段永平：负责先回答“这是不是一门好生意”，包括收入结构、客户价值、复购机制、生态锁定；
- 巴菲特：负责回答“价格有没有安全边际”，包括 PE、PB、ROE、自由现金流、历史估值分位；
- 芒格：负责反过来想“这家公司怎么会死”，包括竞争反噬、技术替代、监管冲击、空方论点；
- 李录：负责拉长时间看“10 年后还在不在”，包括文明级趋势、TAM、产业链位置、长期确定性。
图3：四个独立视角先各自研究，再汇总冲突
这不像四篇独立报告的拼接，更像四个独立研究员分别做完作业后，开一次综合会。会议的主旨不是“谁写得长”，而是“谁发现了别人没看到的盲区”。
多 Agent 并行，不是四段提示词拼接
很多项目也会做“多视角分析”，但大多只是把一个长 Prompt 拆成四段，再拼成一篇更长的文章。这个仓库的团队型路径更像是并行研究：四个视角各自搜索、各自取证、各自判断，再汇总综合结论。
如果你看过 /investment-team 的设计，会发现它要求每个 Agent 独立完成搜索、交叉验证和结论输出，而不是共享同一份素材后各写一段。Team Lead 最后要做的是冲突综合，不是格式统一。
这其实是工程实现上最有价值的一点：不是“更长的输出”，而是“更多独立样本”。量化里常说“多空对抗才能发现真实暴露”，这套思路在这里被用到了研究流程设计上。
我们最该看的，是它的验证纪律
这个仓库里最打动我的，是它对数字不准这件事几乎偏执地防守。
README 里举过一个腾讯市值验算的例子：股价乘以总股本后，与报告市值对比，偏差只有 0.08%。关键财务数据要求至少两个独立来源交叉验证；tools/financial_rigor.py 用 Python 精确十进制处理计算，避免 LLM 心算和单位混乱；tools/report_audit.py 还会对报告做 15% 随机抽检，偏差超过 1% 就打回。
这些工具不是摆设。你直接看仓库里的调用方式就能感觉到它在刻意避免“模型口算”：
python3 tools/financial_rigor.py verify-market-cap \ --price 510 --shares 9.11e9 --reported 4.65e12 --currency HKDpython3 tools/financial_rigor.py three-scenario \ --price 510 --eps 23.5 --shares 9.11e9 \ --growth 12 8 5 --pe 28 22 16 --currency HKD翻译成量化语言就是：它不仅要求结论可追溯，还把“证据是否准确”也做成了回归测试。更严格的是，凡是出现十年期 IRR 或终值倍数的研究，还要再用tools/terminal_value.py 跑一遍 audit，检查 r 与 g 是否同币种、r-g 分母是否过窄、离散风险有没有被错误塞进折现率。
这些细节让我觉得，这个仓库的核心竞争力根本不是“更会写报告”，而是“更会约束报告过程”。
图4：精确计算、交叉验证、报告抽检
边界要清楚：这个项目不是“告诉你怎么下单”。它真正解决的是研究结构化、可复现、可暴露盲点。
它解决的不是“会不会买”，而是“研究会不会跑偏”
很多人用 AI 做投研，最后拿到的是“有机会，也有风险，请自行判断”。这种回答不一定错，但很难拿来决策。这个项目更在意的是：同一家公司，能不能经过多视角检验后， still 留下明确结论。
为此它做了多层防守：信息丰富度评级、芒格式逆向检验、快速否决清单、反共识检查，以及在数据不足时主动标注灰色地带。对我而言，这套设计最有价值的地方，是它承认“不是所有问题都能靠资料堆出来”。
举个例子，项目要求研究前先给目标公司做信息丰富度评级：A 级是上市多年、券商覆盖多的公司，重点是找反面证据；B 级是上市不久、覆盖有限的公司，推算数据必须标置信度；C 级是冷门股、新上市公司或新兴市场公司，不硬凑完整报告，而是改用第一性原理提问。这个分级本身就是对 AI 幻觉的约束。
再比如，它强制要求输出“镜子测试”：如果你不能用 5 句话说清为什么买/不买，那就不做。这个标准很粗暴，但非常有效。很多研究看起来长而完整，其实只是把市场已知信息重新排版了一遍。
图5：五句话讲不清楚，就先不急着下结论
如果你也想在自己的系统里复用这套思路
我写这篇，不是鼓励大家都去跑它的Skill。而是觉得它给出了一个很清晰的模板：复杂研究任务应该先拆成角色、先定验证规则、先设准出标准，再把生成留给模型。
对我而言，最值得迁移的有三点：
第一，把“研究 SOP”显式写成 workflow，而不是藏在每个人脑子里，或隐含在一段长 Prompt 里。
第二，把“数字准确性”当成系统功能做，而不是靠作者自觉。精确计算器、交叉验证、报告抽检，这些都应该成为研究系统的默认模块。
第三，把“不确定性管理”也写成流程。不是所有标的都值得深挖，也不是所有结论都必须给出明确买卖建议。允许灰色地带，反而会提高系统长期可靠性。
我的判断：如果你更关心系统设计、验证纪律、Agent 协作和可复现研究，这个项目值得细看；如果你只想要一个直接给出买卖结论的工具，那它不会让你满意。
这次整理的 GitHub 仓库原始地址在下面，方便你对照原文细节：
https://github.com/xbtlin/ai-berkshire
数据查询基线：2026-08-22；其中 GitHub Star/Fork/Issue 数来自 GitHub API，README 内容来自官方 raw 文档。
如果大家留言踊跃，下一篇我就继续深入拆它 Skill 层的具体设计：哪些路径值得直接迁移到量化研究系统里，哪些地方又明显带有个人工作流烙印，不能直接照搬。
#AI Berkshire #ClaudeCode #Codex #多Agent #量化研究 #价值投资 #金融工程 #LLMOps
Be First to Comment