Anthropic把一套完整的AI技术栈交给了金融团队。我用真实工作跑了一遍——以下是我的发现。

26th Feb 2026
人工智能金融科技AnthropicMCP协议金融分析
Anthropic金融AI技术栈蓝图架构图——顶层为Claude + Skills,中层为四个专业模块,底层为11个机构级数据连接器

Anthropic本周发布了financial-services-plugins——五个Claude插件,覆盖DCF估值模型、LBO分析、股票研究报告、IC备忘录和财富管理工作流,并直接连接包括FactSet、标普全球、晨星、穆迪在内的11个机构级数据源。

我在一家金融公司做软件开发。这周我把整个repo读了一遍——然后真正跑了一遍:生成了一个DCF模型和一份客户报告。以下是我实际发现的东西。

里面有什么

五个插件。一个核心基础层需要先装(Financial Analysis),然后根据团队职能叠加四个专业模块:

插件做什么
Investment Banking起草CIM、构建买家列表、运行并购模型、追踪交易进展
Equity Research撰写财报报告、构建投资论点、覆盖行业研究
Private Equity寻源交易、开展尽调、起草IC备忘录、监控组合KPI
Wealth Management准备客户评审、再平衡投资组合、构建财务规划

每个插件都新增斜杠命令,直接在Claude里运行——

/comps [公司]
/dcf [公司]
/earnings [公司] [季度]
/ic-memo [项目]
。输出到Excel(带实时公式)、PowerPoint(你的品牌模板)或Word文档。零代码,安装即用。

大多数报道略过了最值得关注的部分:技能文件。它们不是套着金融术语的通用提示词,而是编码了资深分析师处理可比公司分析或IC备忘录时实际运用的那种推理框架。读几个就能感受到设计用心。

但命令和技能文件都不是这次发布最有意思的部分。

Repo架构:financial-analysis核心插件、四个专业插件、11个MCP数据连接器

数据巨头们刚刚宣告了一个标准

FactSet。标普全球。晨星。穆迪。LSEG。PitchBook——11家机构级数据供应商,全部在同一个发布窗口内构建了原生MCP连接器。不是初创公司,是深度嵌入每家主要金融机构工作流、签着多年期企业合同的数据基础设施供应商。

当这么多行业巨头同时朝同一个方向移动,这是一个标准在宣告自己的存在。历史对照:当Bloomberg和FactSet在2010年代开放REST API,整整一代金融科技公司在其上构建。MCP是2026年版的那个时刻。

数据提供商是管道,Claude是水管工。

MCP协议汇聚:11家机构级数据供应商全部接入MCP协议,经由Claude输出结果

在我的公司,问题不再是"要不要用AI"——那个已经有了答案。现在问的是:对于已经付费的数据供应商,开通MCP连接器要花多少钱?这是一个具体得多、可操作得多的对话。

我真的跑了一遍——DCF和客户报告

读repo是一回事。我想知道在真实工作上它实际产出什么。

我跑了两个测试:一个DCF模型,一份客户报告。下面的文件都是真实的——Claude直接生成的产出,没有经过任何编辑,原样分享出来,方便你看插件实际能产出什么。

DCF的产出:

回来的是一个真正的Excel工作簿——公式引用、关联单元格、内置敏感性分析表。结构遵循投行惯例:收入构建、利润率假设、终值、WACC计算、隐含估值区间。不是我会直接发出去的东西——有些假设我会调整,有几处会覆盖默认值——但脚手架是对的,从这个起点编辑比从零开始构建要快得多。

📎 下载:AMZN DCF模型(Excel)

/dcf AMZN
的实际产出,生成后未作任何修改

AMZN DCF模型 Excel 内页——情景假设、收入构建、WACC与敏感性分析表

客户报告的产出:

报告输出同样结构清晰——执行摘要、关键指标、组合评述,格式针对客户场景。语言专业,结构标准。同样不是直接发出去的状态,但是扎实的初稿,把"空白页问题"完全消除了。

客户报告产出——面向客户的格式化报告

📎 下载:客户绩效报告(Excel) — 客户报告命令的实际产出,真实测试运行

我的核心感受:价值不在于最终输出是完美的,而在于起点是正确的。一个空白Excel和一个正确结构的工作簿是两件完全不同的事。一个空白文档和一份格式化的初稿是两件完全不同的事。前者是一项任务,后者是一个编辑工作。从空白页到结构化起点之间的那个间隙——那是大多数时间实际花在哪里的地方。

Skills正在成为产品本身

用过之后,我开始思考一个比这些具体插件更宏观的问题。

这里的架构——领域知识编码在Markdown文件里,组织为技能和命令,通过JSON连接数据源——是一个将远远超出金融服务范围而泛化的模式。软件不是Python代码,不是API调用。软件是Markdown。

这是对"构建"意味着什么的有意义的转变。面向技能的项目设计——核心IP存在于结构化的、人类可读的领域知识文件中,而不是在代码里——将变得越来越普遍。对于很多知识工作自动化来说,未来的代码库可能主要就是一套结构良好的Markdown文件。

面向技能的编程——专业知识编码在结构化文件中,而非代码里

由此衍生出几点:

技能文件本身就是护城河。 任何人都可以安装这个repo。差异化来自叠加在上面的公司专属技能——专有的交易框架、编码为约束条件的内部观点、被正式化为技能文件的机构沟通风格。那些被编码和版本控制的机构知识,比任何SaaS订阅都更难复制。

围绕技能配置会有真实的咨询市场。 把一个组织的实际流程翻译成结构良好的领域知识文件是一门技艺。一个认真配置这些文件的机构——把真实的工作流转化为精心设计的技能——得到的东西和安装默认配置就放在那里的机构是质的不同。随着这个模式扩散,知道如何做好那个翻译工作的人会有需求。

"只是Markdown"是对本周怀疑声音的错误解读。 流传的一个批评是:这些技能"只是提示词",用更便宜的模型可以更低成本复制。技术上正确,对企业买家实际上无关紧要。机构不会去雇人为41个金融工作流编写并维护自定义系统提示。这个repo里的文件是预置的、有版本控制的、经过专业设计的领域知识。"只是Markdown"是特性,不是缺陷——任何理解这个工作流的资深人员都可以读懂、验证、扩展,无需碰一行代码。

我内部实际上在考虑的事

基于这次使用体验,我在认真考虑把Claude Code加上技能集分别推给我们的销售团队和研发团队。

技能格式让这对非技术团队是可行的。我不需要构建自定义工具,不需要培训新界面,不需要维护集成。我写技能文件来编码我们的具体工作流,配置我们已经有合同的数据连接器,团队就有了一个从第一天就理解我们领域的AI协作者。

销售团队:编码我们产品、典型客户画像、提案格式、常见异议的技能集。

研发团队:编码我们研究框架、数据源、文档标准的技能集。

当前活在人脑中的机构知识——随着员工离开而流失的那些——被编码并变得可查询。这是和通用AI助手不同量级的价值。

一个真实的例子:从搭建 Agentic 工作流到写一个 Skill 文件

这个转变对我来说通过一次具体的对话变得非常清晰——就在这次发布前几周,我和客户团队的同事在讨论一个问题。

我们想解决的问题:自动化个性化投资建议。一个客户带着特定的投资组合、特定的目标、特定的风险偏好来找我们。以前,产出一份符合公司标准的、有针对性的投资建议需要大量手工工作——拉数据、梳理配置逻辑、按我们的格式起草文档。

最初的方案是从头搭建一个 Agentic 工作流。设计数据管道、写编排逻辑、构建输出模板、接入我们的系统、测试、维护。真正的工程工作——几周的开发周期,持续的维护成本,需要专人负责。

读完这些插件之后,我意识到用一个 Skill 文件就能实现大部分需求。

一个技能文件,编码我们的投资建议逻辑——我们的配置框架、客户沟通标准、必要的合规披露、输出格式。一个命令,拉取客户的投资组合数据,通过这套推理逻辑处理。输出:一份结构化的投资建议文档,按我们的标准格式化,准备好供顾问审阅。

我做了一个可运行的版本,用一个样本客户档案跑了一遍。

产出:基于技能文件生成的个性化投资建议,按公司标准格式化

📎 下载:投资建议(Markdown) — 针对样本客户档案的技能实际产出,未作修改

让我意外的不是输出的质量,而是构建的速度。我原本估计是几周的工程项目,变成了几个小时写一个结构良好的 Markdown 文件。技能文件本身对团队里任何资深人员都是可读的——可以被审阅、质疑、迭代,不需要碰一行代码。

从"我们需要搭建一个 Agentic 系统"到"我们需要写一个技能文件"——这个间隙就是范式的转变。不只是针对投资建议,任何可以被编码为结构化推理的工作流,现在都属于技能文件,而不是定制化的 Agentic 管道。

范式转变:搭建 Agentic 工作流(数周工程量)vs 写一个技能文件(数小时)

什么会真正被采用

几点从技术和实际使用角度的判断:

会快速落地的: 已知格式的交付物,且数据订阅已经到位。财报摘要、可比公司分析表、研究报告初稿、客户报告。增量工作量:安装插件,配置

.mcp.json
指向已付费的供应商,完成。几个月内,而不是几年。

会慢的: 完整模型直接进入客户材料。合规和风险团队需要在模型架构和审核流程上签字后,AI生成的DCF才能进路演PPT。这不是Claude的问题——这是Excel模板上就已经存在的管控问题,当AI介入时更加正式。

真正的阻力是数据,不是工具。 如果你的公司没有FactSet或Capital IQ的合同,MCP连接器无法充分释放价值。但开源性质改变了中型机构的可行性计算:fork这个repo,配置

.mcp.json
指向你有合同的那一家供应商,加入你公司自己的模型和术语。以前需要软件项目的事,现在需要一个会编辑Markdown的人。

在你准备好部署之前就开始合规对话。 技术工作量比预期的轻。组织层面的工作——合规审批、IT安全、数据治理——才是时间线真正的所在。等到技术准备好再开始,已经损失了两三个月。

快速落地 vs 需要更长时间——中型金融机构的采用现实框架

蓝图

Anthropic本周发布的不只是插件,而是一份设计规范——AI原生金融机构的工具层应该是什么样子的。

架构:带共享建模基础设施的核心插件、各职能专用的附加模块、机构级数据的MCP连接器、直接输出到Excel和PowerPoint。模块化,数据连通,工作流专用,Markdown可定制。

我越来越觉得技能文件模式才是这里持久的贡献,而不是任何具体的命令或产出。领域知识编码在结构化的、有版本控制的、人类可读的文件中,该领域任何足够资深的人都可以扩展。这是一个真正新的软件基元。

现在就把机构知识编码进技能文件的机构——他们的交易框架、研究方法论、客户沟通标准——在构建一种复利增长的东西。不只是生产力工具,而是一个随时间变得更有用的组织知识系统。

等待供应商把这些打包成授权产品的机构会付出三倍代价,拿到一个已经落后一代的解决方案。这个模式在金融技术领域发生过,正在以更快的速度再次发生。

下载 — 本文引用的真实产出文件

以下文件均为本文测试过程中Claude生成的原始产出,未作任何修改,供参考。

文件格式对应章节
AMZN DCF模型Excel我实际跑了一遍
客户绩效报告Excel我实际跑了一遍
投资建议Excel从Agentic工作流到技能文件
投资建议Markdown从Agentic工作流到技能文件

我写的是在金融服务和技术产品交叉地带构建AI原生——从一家真实机构内部看是什么样的。Newsletter在这里:

Ship with AI on Beehiiv