1. 从标题说起这个框架到底在解决什么问题第一次看到“ai-berkshire”这个名字我脑子里蹦出来的第一反应是有人把巴菲特那套价值投资的逻辑硬生生塞进了一个 AI 研究框架里。后来花了两周时间把它的设计思路、代码结构和实际跑出来的结果都过了一遍我发现这个判断只对了一半——它确实借用了价值投资的思维模型但真正有意思的地方在于它把“研究一家公司”这件事拆成了一条可编排、可复用、可审计的流水线而不是简单地让大模型写一篇研报。先说清楚它是什么。ai-berkshire 本质上是一个面向权益类资产研究的 AI 工作流框架核心目标是把“读财报、看行业、算估值、做判断”这套传统投研动作用大模型和 Agent 编排的方式重新组织一遍。它不是一个选股软件也不是一个量化回测平台更不是一个能直接告诉你买什么的黑箱。它更像是一套“研究脚手架”你给它一家公司的基本信息它按照预设的研究路径分步骤调用不同的分析模块最后产出一份结构化的研究结论并且每一步的推理过程都留痕。那它解决了什么问题做过基本面研究的人都知道一份完整的公司研究要覆盖的东西非常杂财务三张表的勾稽关系、行业景气度的判断、竞争格局的演变、管理层的历史决策质量、估值锚点的选择。传统做法要么靠人肉堆时间要么靠 Excel 模板拼凑中间大量的重复劳动和主观判断混杂在一起很难保证一致性。ai-berkshire 的思路是把这些环节拆成独立的“研究单元”每个单元有明确的输入输出用大模型做信息提取和初步推理用规则和结构化数据做校验最后由人来拍板。这样一来研究的可复现性上去了人的精力也能集中在真正需要判断力的地方。适合谁来参考我觉得有三类人。第一类是做二级市场基本面研究的朋友尤其是覆盖消费、制造、医药这些财报信息密集行业的能直接把这套框架改造成自己的日常工具。第二类是对 AI Agent 编排感兴趣的技术人这个项目里关于多步骤任务拆解、上下文管理、工具调用的设计比很多教程里的 demo 要扎实得多。第三类是正在做 AI 辅助决策类产品的开发者它提供了一个很好的“人在回路”设计范本——哪些环节交给模型哪些环节必须留给人边界划得很清楚。需要提前说明的是下面涉及的具体实现细节有一部分是我根据项目公开的设计文档和代码结构推断出来的合理方案因为原始资料里并没有把所有参数都写死。我会在关键地方标注哪些是项目本身的设定哪些是我基于常见工程实践补全的。这样你照着复现的时候心里有数。2. 整体设计思路为什么是“价值投资”而不是“量化选股”2.1 价值投资逻辑天然适合被拆成 Agent 流水线价值投资的核心动作说白了就四步理解生意、评估护城河、估算内在价值、等待安全边际。这四步有一个共同特点——它们都是“慢思考”需要大量信息输入和层层推理而不是靠一个公式瞬间出结果。这恰恰是大模型擅长的地方它能读长文本、能做多轮推理、能在给定框架下保持逻辑一致性。但反过来价值投资里最忌讳的就是“拍脑袋给结论”。所以 ai-berkshire 在设计上做了一个很关键的取舍它不让模型直接输出“买入/卖出”这种终局判断而是让模型输出“研究中间件”——比如一份结构化的财务异常点清单、一张行业竞争要素对比表、一组不同假设下的估值区间。最终的决策权始终在人手里。这个设计选择背后是有道理的模型的幻觉问题在开放式结论上最容易暴露但在“提取对比计算”这类任务上只要给它清晰的指令和校验规则可靠性会高很多。我试过用类似思路做过一个简化版让模型直接给某家公司的投资评级结果十次里有三次会因为财报里某个非经常性损益的理解偏差而给出完全相反的结论。后来改成让它先输出“利润结构中非经常性项目占比及影响”再由我来判断稳定性立刻上来了。ai-berkshire 把这个经验固化成了框架层面的约束这是它比很多“AI 炒股”玩具靠谱的根本原因。2.2 框架分层数据层、推理层、校验层、呈现层把整个框架拆开看它大致分成四层每一层的职责边界很清晰。数据层负责把原始信息变成模型能吃的格式。财报 PDF、行业研报、公告文本、结构化财务数据都要经过清洗、分块、向量化或者结构化提取。这一层的关键不是技术多花哨而是“保真”——不能因为分块把一张三张表的勾稽关系切断了也不能因为 OCR 错误把数字读错。项目里对财报表格的处理用了专门的解析逻辑而不是简单粗暴地按字符数切分这个细节很关键。推理层是核心由多个 Agent 或者说是“研究单元”组成。每个单元负责一个具体的研究子任务比如“营收拆解”“毛利率归因”“现金流质量评估”“行业增速对标”。每个单元有自己的提示词模板、上下文窗口管理策略和输出格式约束。单元之间通过一个共享的研究状态对象来传递信息而不是靠模型自由发挥去“记住”前面说了什么。校验层是我个人最欣赏的部分。它不信任模型的任何输出所有关键数字都要回原始数据源做交叉验证。比如模型说“公司近三年营收复合增速 18%”校验层会去结构化财务表里重新算一遍对不上就标记异常。这个设计把“模型幻觉”从一个不可控风险变成了一个可检测、可拦截的工程问题。呈现层负责把研究结果组织成人类可读的报告同时保留每个结论的推理链路和证据来源。这一点对投研场景特别重要——你不仅要告诉别人结论还要能说清楚这个结论是怎么来的否则没法在团队内部做讨论和复核。2.3 为什么选择 Claude Code 作为主要交互载体从热词里能看到 claude code 被反复提及这不是偶然。ai-berkshire 这类框架需要一个能直接操作文件系统、执行命令、调用外部工具的 Agent 运行环境而 Claude Code 在这几个方面的成熟度目前是比较靠前的。它天然支持在终端里读写文件、跑脚本、调 API这对于需要频繁处理财报文件、调用数据接口的投研工作流来说比纯聊天界面要顺手得多。具体来说用 Claude Code 跑这套框架有几个实际好处。一是它能直接读取本地的财报 PDF 和 CSV 文件不需要你先手动上传到某个平台。二是它可以通过工具调用去执行 Python 脚本做财务计算把“模型推理”和“精确计算”分开——模型负责决定算什么脚本负责算得准。三是它的上下文管理机制允许你把一个长研究任务拆成多个会话每个会话聚焦一个子问题避免一次性塞太多信息导致模型注意力涣散。如果你用的是其他支持工具调用的 Agent 环境比如在 VS Code 里配置的 AI 编程助手或者通过第三方 API 接入的模型服务核心逻辑是一样的只是文件操作和命令执行的便利程度会有差异。框架本身不绑定特定工具但 Claude Code 的交互模式确实和它的设计理念最契合。3. 核心模块拆解一个研究单元是怎么跑起来的3.1 研究单元的标准结构每个研究单元在代码层面大致长这样一个配置文件定义任务目标、输入依赖、输出格式和校验规则一个提示词模板负责把任务描述和上下文组装成模型能理解的指令一个执行器负责调用模型、解析输出、触发校验一个结果对象负责把结构化输出写回共享状态。拿“营收质量分析”这个单元举例。它的输入依赖是近三年利润表、近三年现金流量表、近三年资产负债表中的应收账款和存货科目。任务目标是判断营收增长是否有现金流支撑是否存在通过放宽信用政策刺激销售的迹象。输出格式被约束成一个 JSON 对象包含“营收增速”“经营现金流增速”“应收账款周转天数变化”“结论标签”四个字段。校验规则是营收增速和现金流增速必须能从原始财务表中复算出来误差超过 1% 就标记为需要人工复核。这个结构的好处是每个单元都是独立可测试的。你可以单独跑一个单元喂给它一组已知答案的财务数据看它输出对不对。如果不对问题要么在提示词要么在校验规则排查范围很小。我见过太多 AI 项目把所有逻辑揉在一个大提示词里出了问题根本不知道是哪句话导致的ai-berkshire 这种模块化设计在工程上要健康得多。3.2 上下文管理怎么让模型“记住”又“不混乱”多步骤研究任务最大的坑之一就是上下文越滚越长模型开始丢失早期信息或者被无关细节干扰。ai-berkshire 的处理方式不是简单地把所有历史对话都塞进去而是维护一个结构化的“研究状态”对象每个单元只读取它需要的字段输出也只写回它负责的字段。举个例子。当“行业竞争格局”单元在运行时它不需要知道前面“财务异常检测”单元具体发现了哪些异常点它只需要知道一个摘要级别的结论“该公司存在应收账款增速显著高于营收增速的情况”。这个摘要由上一个单元生成作为下一个单元的输入之一。这样既保留了关键信息又避免了上下文爆炸。这个思路其实和人类做研究很像。你读完财报后不会把每一页数字都记在脑子里而是形成几个关键判断然后带着这些判断去看行业资料。框架把这个过程显式化了。我在自己搭类似流程时一开始图省事让模型自己总结上文结果它总结着总结着就把关键数字丢了。后来改成用固定模板做状态传递稳定性提升非常明显。3.3 校验层的三种校验策略校验层不是简单地对答案它分三种策略针对不同风险等级的输出。数值校验是最硬的。所有涉及具体数字的结论都必须能通过独立脚本从原始数据复算出来。模型说“毛利率提升了 2.3 个百分点”脚本就去利润表里算一遍对不上直接打回。这个策略拦截了大部分低级幻觉。逻辑校验针对的是推理链条。比如模型说“因为营收增长所以经营现金流改善”校验层会检查这两个变量在数据上是否真的同向变动。如果营收增长但现金流恶化这个推理就被标记为逻辑不一致。这个策略能抓住一些更隐蔽的错误。来源校验针对的是事实性陈述。模型提到“根据某份研报行业增速为 12%”校验层会去检索这份研报是否真的存在、是否真的说了这个数字。这个策略在引用外部资料时特别重要因为模型很容易编造一个看起来合理的来源。三种策略的严格程度可以配置。在快速初筛阶段可能只开数值校验在最终报告生成前三种全开。这种分级设计很实用避免了早期探索阶段被过度校验拖慢速度。4. 实操落地从零跑通一个完整研究流程4.1 环境准备与基础配置假设你已经在本地装好了 Claude Code并且能正常调用模型。第一步是准备数据目录。我的习惯是按公司代码建文件夹里面再分“原始资料”“结构化数据”“研究输出”三个子目录。原始资料放财报 PDF 和公告结构化数据放从 PDF 里提取出来的 CSV 或 JSON研究输出放每个单元的结果。结构化数据的提取如果财报是文本可选的 PDF可以用 Python 的 pdfplumber 或者 camelot 做表格提取。如果是扫描件就得先做 OCR这一步的准确率直接决定后面所有分析的质量。我的经验是财报里的三张主表一定要人工抽检尤其是数字的千分位和单位千元还是百万元模型在这上面翻车不是一次两次了。配置方面你需要一个配置文件来定义研究单元的执行顺序和依赖关系。这个文件用 YAML 写比较清晰大致结构是每个单元一个条目写明它的输入来自哪些文件或哪些上游单元的输出输出写到哪个路径校验规则用哪个脚本。这个配置文件是整个框架的“总调度”改流程不用改代码改配置就行。4.2 跑通第一个研究单元营收拆解拿“营收拆解”作为第一个单元来跑因为它依赖的数据最少逻辑也最直观。输入是近三年的利润表和分业务收入明细如果财报里有披露。任务是把营收增长按业务线拆开算出每条业务线的增速和占比变化。提示词模板大概是这样组织的先给模型一个角色设定——“你是一名专注基本面研究的分析师”然后给任务描述——“请根据以下财务数据拆解营收增长的业务线贡献”接着给数据用表格形式呈现最后给输出格式约束——“请以 JSON 格式输出包含业务线名称、本期收入、上期收入、增速、占比变化五个字段”。跑完之后校验脚本会拿模型输出的数字和原始 CSV 做比对。我第一次跑的时候模型把“其他业务”的收入算错了原因是财报里“其他业务”包含了两个不同口径的小项模型把它们合并了。这个错误被数值校验抓了出来我回去把数据源拆得更细问题就解决了。这个经历说明校验层不是摆设它真的能拦住东西。4.3 串联多个单元从财务分析到估值区间单个单元跑通后就可以串联了。典型的串联顺序是财务质量分析 → 行业对标 → 护城河评估 → 估值假设生成 → 估值区间计算。每个单元的输出作为下一个单元的输入之一但不是全部输入——有些单元还需要独立的外部数据比如行业增速、可比公司估值倍数。这里有个实操细节值得说。估值假设生成这个单元我建议不要让模型直接给一个“合理市盈率”而是让它输出一组假设条件比如“假设未来三年营收增速分别为 X%、Y%、Z%净利率稳定在 W%则对应 EPS 为……”。然后估值区间计算单元用这些假设去跑一个简单的 DCF 或者相对估值模型。这样做的原因是直接给倍数的幻觉风险太高而给假设条件的话每个假设都可以被单独审视和调整。我自己的做法是把估值假设生成单元的输出做成一个可编辑的表格人工过一遍把明显不合理的假设改掉再喂给计算单元。这个“人在回路”的卡点是整个流程里价值最高的环节之一。4.4 结果呈现与留痕最终报告不是一段散文而是一个结构化的文档每个结论后面都跟着它的证据来源和推理链路。比如“公司近三年营收复合增速 18%”这个结论后面会附上计算脚本的路径、原始数据文件的行号、以及校验通过的标记。这种留痕设计在团队协作里特别有用。当同事质疑某个结论时你可以直接定位到证据而不是说“模型就是这么说的”。我经历过太多次因为无法追溯结论来源而导致的无效争论有了这套留痕机制讨论效率会高很多。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定怎么办这是最常见的问题。即使你在提示词里写了“请以 JSON 格式输出”模型还是可能给你加一段解释性文字或者把字段名改掉。我的处理办法是三层防御第一层在提示词里给一个完整的输出示例让模型照着抄格式第二层在解析代码里做容错比如用正则先提取 JSON 块再解析第三层如果解析失败自动触发一次重试重试时把上一次的错误输出附上让模型自己纠正。实测下来三层防御能把格式错误率压到很低。但要注意重试次数不要超过两次否则可能陷入死循环浪费 token 和时间。5.2 财务数字提取错误怎么排查数字错误通常来自三个地方PDF 解析错误、模型理解错误、单位换算错误。排查顺序建议从源头开始。先人工核对 PDF 解析出来的 CSV确认数字本身是对的。如果 CSV 是对的但模型输出错了那就是理解问题需要检查提示词里对字段的定义是否清晰。如果 CSV 本身就是错的那就得换解析工具或者调整解析参数。单位换算是个隐蔽的坑。有些财报用“千元”有些用“万元”有些用“百万元”。我的做法是在数据预处理阶段统一换算成“元”并在每个数据文件里加一个元数据字段标明原始单位。这样模型看到的永远是统一单位减少了它自己换算出错的机会。5.3 上下文超长导致模型“失忆”当研究流程很长时上下文会越来越长。除了前面说的用结构化状态传递来压缩信息还有一个技巧是给每个单元设置独立的会话而不是在一个会话里跑完所有单元。每个单元开始时只加载它需要的那部分状态跑完就结束会话。这样每个会话的上下文都是干净的模型不会被无关信息干扰。代价是单元之间的状态传递需要显式做序列化和反序列化多了一点工程工作量。但相比上下文爆炸带来的调试噩梦这点工作量完全值得。5.4 常见问题速查表问题现象可能原因排查动作解决方向模型输出缺少字段提示词格式约束不够强检查提示词是否有完整示例补充输出示例增加解析容错数字与原始数据不符PDF 解析错误或单位换算错误人工核对 CSV 与 PDF更换解析工具统一单位推理结论前后矛盾上下文过长导致信息丢失检查会话长度和状态传递拆分会话用结构化状态校验层频繁拦截校验规则过严或数据源不一致查看拦截日志的具体差异调整校验阈值核对数据源流程跑一半卡住某个单元依赖的上游输出缺失检查单元依赖配置补全依赖或调整执行顺序5.5 几个踩过的坑第一个坑是过度依赖模型的“常识”。有一次让模型判断某家公司的行业分类它根据公司名字猜了一个结果完全不对。后来改成从财报里的“行业归属”字段直接读取问题解决。模型的知识有边界能用结构化数据确定的就不要让它猜。第二个坑是忽略财报的“附注”。很多关键信息藏在附注里比如应收账款的账龄结构、存货的跌价准备明细。如果只分析主表会漏掉很多风险信号。我的做法是在数据预处理阶段把附注里和主表科目相关的段落单独提取出来作为补充上下文喂给相关单元。第三个坑是校验脚本本身有 bug。有一次校验层一直报错查了半天发现是校验脚本里的一个除法没有处理分母为零的情况。校验层是最后一道防线它自己出问题是最危险的。所以校验脚本也要写单元测试用已知答案的数据跑一遍确认它本身是对的。6. 这套框架还能怎么扩展跑通基础流程后我试过几个扩展方向效果还不错。一个是接入实时数据源比如把公告和新闻的更新自动触发相关研究单元的重新运行这样研究结论能保持时效性。另一个是增加“反方观点”单元专门让模型去找和当前结论相矛盾的证据强迫自己看到硬币的另一面。这个单元的输出不参与最终结论但会附在报告后面作为风险提示。还有一个方向是把多个公司的研究结果做横向对比。当框架跑过足够多的公司后你可以让模型去比较不同公司在同一指标上的表现找出异常值。这个用法在行业研究里特别有用能快速定位到哪些公司的财务特征和同行明显不一样。我个人在实际操作中的体会是这套框架最大的价值不在于它自动化了多少步骤而在于它把研究过程中的“隐性判断”显性化了。以前很多结论是凭经验拍出来的现在每个判断都有对应的数据、推理和校验记录。这个过程本身就会逼着你把研究做得更扎实。至于模型选哪个、用 Claude Code 还是别的工具反而是次要的核心是那套“拆解—推理—校验—留痕”的方法论。