每年年报季一到做财务分析的人就进入“甜苦参半”的状态甜的是终于有一年一度的全景数据可看苦的是几十上百页PDF要一页页翻、一张张表截、一个个数值敲进Excel。这次我收了苹果、微软、谷歌三家科技巨头的年报三份PDF加在一起共276页放在以前怎么也得耗上一个周末而这次我用 WorkBuddy 搭了一条提取流程从原文件到一张可核验的比较表整个过程压缩到了两小时左右。这篇文章就把完整的分析思路、操作步骤和踩坑记录原样分享出来。先说结论工具解决的是“体力活”但真正决定比较表质量的是“分析框架”和“核验机制”。WorkBuddy 在整个流程里承担了 PDF 解析、指标抽取、口径对齐和结果回填这几件事。如果你也经常处理年报、招股书、行业报告这类长文档并且不想在手动复制粘贴上浪费生命那么下面这套流程值得直接抄作业。1. 为什么要用 WorkBuddy 来做年报横向财务分析1.1 年报分析的真实痛点PDF 不是给你做表格用的年报这一类文档有一个共同点它本质上不是“数据文件”而是“排版文件”。PDF 内部记录的是每个字符放在页面哪个位置而不是“这一列是营收、那一列是净利润”。这也是为什么直接从 PDF 复制表格到 Excel 经常会得到一坨乱七八糟的文本数字和表头对不上换行断得莫名其妙有时还会混入页眉页脚。苹果、微软、谷歌这三家的年报都遵循美国证券交易委员会的 10-K 格式但每家排版风格差异很大有的用纯文本三线表有的用带底色的复杂表格有的把管理层讨论与分析部分写成大段叙述中间嵌几个关键数字。这种结构不规则的数据源恰恰是通用 PDF 阅读器最不擅长处理的场景。另一个痛点是“页数”。276 页听上去不多但人眼从里面找数据属于高密度重复劳动。我要做的横向财务分析至少需要从三份年报里提取几十个指标每个指标得在原文件中找到出处传统人工方案是先在目录里定位报表页再逐项抄录。中间只要走神一次数据就可能串行。等到最后核对时发现某一行数对不上已经不知道是提取错了还是录入错了。1.2 为什么不是手工、Excel 插件也不是直接把 PDF 丢给通用对话模型我先把市面上可用的替代方案简单排了一遍。手工方案最灵活但效率太差276页三份年报逐页翻阅加录入正常速度需要三到五小时而且复核成本成倍增加。Excel 里直接用“从 PDF 导入”功能对规则表格有效可遇到合并单元格、跨页续表、注释性小字就经常识别错位需要反复重试。通用大模型对话式处理 PDF 看起来聪明但真正跑起来有几个问题一是每次上传处理大文件时等待时间长二是长文档容易被截断后面的报表根本读不进去三是生成结果存在幻觉风险它会“合理猜测”一个数字填进去这在财务分析里是致命的。WorkBuddy 解决的恰恰是这三个问题。它先做本地化解析把 PDF 转换成带页面坐标和结构信息的中间格式再通过可编排的任务流让模型只看指定的页区避免了长文档截断。最关键是它保留了“操作过程可追溯”的能力每一处提取结果都能对应回源文件第几页、哪个表格、第几行。对于财务分析来说可追溯比“聪明”重要得多这也是我最终选择它的核心理由。1.3 项目目标与验收标准可核验是底线动手之前我先给自己定了三条验收标准避免做着做着就跑偏。第一输出必须是一张完整的横向财务比较表涵盖收入、利润、现金流、资产负债、研发投入等核心维度并且三家公司的数据放在同一张表里可以直观对比。第二表中的每一个数据点都必须有出处标记要么是原 PDF 页码加表格名要么是文件路径加搜索关键词让任何人都能回到原文验证。第三整个流程的可复现成本要足够低明年年报季能不能用同一套流程跑新数据决定了这个方案是一次性工具还是长期生产力。这里要特别强调“可核验”这三个字。财务分析领域的常见翻车现场是模型给出了看起来完美的表格但细究某一行数据时发现这个数字在原文件里根本不存在。所以我在整个流程里把“溯源”当成第一优先级任何无法回溯到源文件的数字一律视为无效结果。后面你会看到我在提示词和技能设计里都强制了“页码引用原文”的输出格式这不是为了形式上好看而是为了把幻觉风险压到最低。2. 分析框架与关键指标怎么定2.1 先定“骨架”三类报表为主辅助指标为辅很多人拿到年报就开始让工具提取数据这其实是反的。工具再强也不知道你想要什么。正确的顺序是先定分析框架再让工具去执行提取。年报横向分析最稳妥的骨架是利润表、资产负债表、现金流量表这么三大主表加上几个辅助指标维度。主表数据决定了公司赚不赚钱、资产稳不稳、现金流充不充足辅助指标则负责解释赚钱质量、成长性和投入方向。以三家科技公司为例我的指标清单大致长这样利润表取总营收、营业成本、毛利润、毛利率、研发费用、销售及管理费用、营业利润、净利润、摊薄每股收益资产负债表取总资产、总负债、股东权益、现金及短期投资、长期债务现金流量表取经营活动现金流、投资活动现金流、融资活动现金流、自由现金流辅助指标包括营收增速、净利润增速、研发费用占营收比、经营现金流与净利润比值。总共有三十多项指标每一项都得在三家年报里找齐数量不多但确认口径是个细活。2.2 最坑的一步口径统一尤其是财年和披露口径的差异三家公司的财年结束日不一致这是横向对比最容易翻车的地方。苹果的财年通常在三月底结束第一个季度整个财年在九月下旬结束微软的财年截止六月谷歌则是十二月截止。也就是说苹果 2023 财年的大部分月份落在 2022 年 9 月到 2023 年 9 月微软 2023 财年是 2022 年 7 月到 2023 年 6 月谷歌 2023 财年才真正对应自然年 2023。如果不加说明地把三个“2023财年”硬放一起比较虽然行业内可接受但严谨的表格必须标注清楚每家对应的起止时间。更麻烦的是口径内部的问题。三家公司都会在财报里同时披露 GAAP 和 Non-GAAP 口径的数据最典型的是研发费用、重组费用和股权投资损益的处理。苹果喜欢在 Non-GAAP 里剔除一些一次性项目微软则对云业务折旧调整比较敏感。如果只告诉工具“提取研发费用”它很可能把不同口径混在一起导致比较结果失真。所以我在框架阶段就明确要求优先使用 GAAP 口径并在每个指标旁标注“是否含非经常性损益”。这一点在后面的技能配置里会变成一条硬性规范。2.3 单位、币种和“小数位陷阱”三家公司都用美元计价省去了汇率换算的步骤但单位处理还是容易出错。苹果年报里的数字经常以百万美元为单位微软有时用百万有时用十亿谷歌的年报摘要部分干脆用十亿。单位不统一直接在表里相加或比较会得出完全错误的结论。我的处理方式是在提取阶段强制工具把原始单位记录下来再在汇总阶段统一折算成“百万美元”这个基准单位。如果原始单位是十亿就乘以一千如果是千美元就除以一千。这个换算逻辑我在提示词里写得很死防止工具自作聪明地四舍五入。小数位也值得留意。年报里有些指标保留到小数点后一位有些保留到两位横向比较时如果不统一表里会出现 23647 和 321.5 这种严重不协调的情形。我在最终表格里统一保留两位小数原始值如果只给了一位小数也不强行补零而是标注“原值”以便追踪。3. 实操用 WorkBuddy 搭出完整的提取流程3.1 环境准备先把文件和工作台准备好我这次用的是 WorkBuddy 的桌面端版本在三台设备上都跑过Windows、macOS 和 Linux 版的部署逻辑差别不大都是下载安装包后直接启动。安装完成后第一件事不是急着导文件而是设置工作目录。我给这个项目单独建了一个文件夹里面按“原始 PDF、中间解析结果、提取结果、核验记录”四个子目录划分好这样后面每一步生成的文件都有地方放找问题时不至于乱成一团。另外一个重要准备是模型配置。WorkBuddy 支持对接多种模型我这次选择的是通过 WorkBuddy 接入 DeepSeek 的接口原因有两方面一是长上下文处理能力足够覆盖单份年报的核心章节二是成本相对可控年报解析这种任务会产生大量文本输入输出逐页解析一整份 276 页的合集如果没有成本意识API 账单会很难看。如果你日常使用的是其他模型也可以用 WorkBuddy 的模型切换功能只要注意不同模型在工具调用和指令遵循上的表现差异即可。3.2 PDF 解析这一步别急着让模型“读”先让文件结构清晰很多人使用 AI 工具处理 PDF 时上来就让模型直接阅读全文这个做法在处理年报时效率很低。我的经验是先做“物理层解析”把 PDF 转成结构化的中间格式再让模型基于结构化内容做提取。这一步的目的纯粹是解决“机器可读”问题把每页的文本、表格、图片位置、页眉页脚关系梳理清楚。在 WorkBuddy 里我建立了一个解析任务专门负责逐页读取 PDF 并输出包含页码信息的 Markdown 文件。遇到文字版 PDF 时直接提取文本层遇到扫描版或图片型页面时我给它增加了 OCR 处理步骤。这里需要提醒的是OCR 之后的中文和英文混排表格经常出现字符错位尤其是表格线不明显的版式最好在解析后先抽样看几页再往下走。我遇到过一页“资产总计”被识别成了“资产总汁”如果后续没有核验步骤这种错误会悄悄混进表格里。另外一个提升解析质量的小技巧是“先分离表格页”。在完整解析之前先利用目录页定位“合并财务报表”相关的页码范围比如三家公司的合并利润表通常在 38 到 52 页区域内把这个范围单独提取出来只对这个区间执行高精度的表格解析可以显著降低后面指标提取的错乱概率。3.3 Skill 的写法把财务提取经验固化成可复用技能WorkBuddy 的 Skill 机制是我这次流程里最喜欢的部分。它的本质是把一段复杂的任务指令包装成可重复调用的“技能块”下次做类似任务时不用把几百字提示词重新敲一遍直接调用技能名称就能复用。我把三张核心报表的提取逻辑写成了三个技能分别叫“提取利润表指标”“提取资产负债表指标”“提取现金流量表指标”。每个技能的内部结构大致包含任务目标、输入文件、输出格式、口径规范和例外处理规则。以“提取利润表指标”为例我在输出格式里强制要求每个指标返回“指标名、数值、原始单位、页码、表名、所在行原文本”。这样既保证了提取结果有据可查也方便后面核验程序自动比对。口径规范区写明了“使用 GAAP 口径、排除 Non-GAAP 调整项目”的指令例外处理区则规定了当同一个指标在文中多次出现时以合并财务报表章节为主优先采用报表内数值而不是管理层讨论部分的叙述性数值。Sample 技能配置的简化示意如下实际使用时可以根据公司的报表格式做调整skill_name: extract_income_statement input: file_pattern: *.md source_range: 合并利润表所在页码 extraction_rules: - metric: 总营收 output_format: 数值, 原始单位, 页码, 表名, 行文本 dedup_priority: 合并财务报表章节 管理层讨论 摘要 - metric: 净利润 output_format: 数值, 原始单位, 页码, 表名, 行文本 gaap_only: true notes: - 如果同一指标出现多个数值全部列出并在备注中说明差异来源这个技能配置看起来简单但跑通之后收益很大。第二次解析另一家年报时我直接复用同一套技能在 WorkBuddy 里批量执行中间只需要人工抽样核查异常项。3.4 提示词里的“强制溯源”设计如果说 Skill 是整个流程的骨架提示词就是肌肉。我可以把一版核心提示词贴出来供参考这段提示词的作用是让模型在提取数据时强制带上出处逻辑上不给幻觉留空间。我使用的提取提示词大致如下你是一名严格的财务数据提取助理。你的任务是从给定年报内容中提取特定指标并填写到结构化表格中。 必须遵守以下规则 1. 只输出原始资料中明确出现的数值禁止根据上下文推测或计算指标值。 2. 每个数值必须附带三个溯源字段来源页码、来源表名、原文句子。 3. 优先采用合并财务报表章节的数据管理层讨论中的数据仅作为补充需在备注中标注“MDA”。 4. 区分GAAP口径与Non-GAAP口径默认提取GAAP口径数值若只找到Non-GAAP数值则必须标注“Non-GAAP”。 5. 数值的单位以原文为准同时记录原始单位不做任何转换。 6. 如果同一指标在文件中存在多份重复披露且数值不同请列出所有数值并在备注中说明可能原因。 7. 如果某项指标无法找到请明确输出“未找到”不要猜测。这段提示词里最关键的是第 1 条和第 7 条。前者杜绝了模型拿上下文估算问题后者允许模型“承认不知道”这两条配合起来基本可以保证输出结果不会出现凭空捏造的数字。需要说明的是完整年报里同一指标经常多次出现例如营收在“合并利润表”和“分地区收入表”里都披露分子公司明细里也有不同口径所以第 6 条的存在也非常重要它保证了我们在提取阶段能看到所有候选值而不是被工具随机挑一个。3.5 从原始数据到比较表汇总阶段的转换逻辑三份年报分别提取完成后得到的是三个结构相似的独立表格。接下来是把它们合并成一张横向比较表。这一步我同样在 WorkBuddy 里做但不再调用 PDF 解析技能而是建立一个“汇总转换”任务专门负责读入三份中间结果、做单位统一、对齐指标名称、输出最终比较表。单位统一在这个阶段彻底解决。我在任务指令里写了这样一条规则“若原始单位为十亿美元转换为百万美元时乘以 1000若原始单位为千美元转换为百万美元时除以 1000。转换后的数值保留两位小数并在备注列标明‘原单位及换算系数’。”这样避免了所有单位混乱问题。指标对齐是比较表能否成立的关键。三家公司的报表科目名称略有差异比如苹果叫“销售、一般及管理费用”微软叫“销售与营销费用”和“一般及行政费用”谷歌部分报表里两者合并披露。我在汇总任务里维护了一张“科目映射表”把相近含义的科目统一归类到同一行比较无法完全对应的科目单独列出并注明“口径差异”。最终表格输出的样子大致长这样| 指标 | 苹果 FY2023 | 微软 FY2023 | 谷歌 FY2023 | 口径备注 | 数据来源 | | --- | --- | --- | --- | --- | --- | | 总营收百万美元 | 383285 | 211915 | 307394 | 均为GAAP口径财年截止日不同 | 三份年报合并利润表详见核验索引 | | 净利润百万美元 | 96995 | 72461 | 73795 | 苹果含一次性税收影响微软含收购相关调整 | 三份年报合并利润表 | | 经营现金流百万美元 | 110543 | 87582 | 101746 | 三家均为持续经营口径 | 三份年报现金流量表 | | 研发费用百万美元 | 29915 | 27207 | 45427 | 谷歌研发费用会计口径含部分资本化调整 | 三份年报利润表及附注 |这里必须声明上表中的数值是演示用的占位数据仅用于说明表格结构真实使用时请以原始年报 PDF 的实际数值为准。我特意在演示表格里放了占位数就是为了避免读者把我的示例数值拿去引用。3.6 核验环节不能只依赖模型的输出提取完成后我建了一个“核验索引”文件专门记录每个指标在源文件中的位置。这个文件的本质是桥接“比较表”和“原始 PDF”的中间站任何人都可以拿着它回到原文复核。核验索引的一部分内容如下核对文件核验索引.md 1. 苹果FY2023总营收 - 来源文件apple_10k_2023.pdf - 页码第41页 - 表名Consolidated Statements of Operations - 原文行Net sales —— $383,285 million 2. 微软FY2023总营收 - 来源文件microsoft_10k_2023.pdf - 页码第32页 - 表名Income Statements - 原文行Revenue —— $211,915 million 3. 谷歌FY2023总营收 - 来源文件alphabet_10k_2023.pdf - 页码第36页 - 表名Consolidated Statements of Income - 原文行Revenues —— $307,394 million这一步不依赖模型而是靠 WorkBuddy 里的“文件定位”功能把提取结果反向映射到原始页。遇到不一致时我会直接把问题抛回解析阶段重新确认对应页码的表格解析是否正确。实践下来大部分数据错漏都能在这一轮被拦住真正要人工再翻原稿的情况一般出现在合并单元格或脚注特别复杂的页面上。4. 常见问题与排查技巧实录4.1 文件写入权限报错502 write eacces 的解决过程使用 WorkBuddy 时最常见的报错之一是类似 “502 write eacces” 的文件写入权限问题。我一开始也吓了一跳以为是网络或服务端故障排查之后发现根因在工作目录的访问权限上。WorkBuddy 在处理文件输出时默认需要运行进程对指定目录有写权限如果工作目录放在系统受保护路径下比如 Windows 的 Program Files 区域或 Linux 的 /root 目录就会触发这个报错。解决办法很简单第一种是把整个项目工作目录转移到用户目录下的普通路径比如 Windows 的 Documents\workbuddy_projects 或 Linux 的 ~/workbuddy_projects。第二种是在 WorkBuddy 的设置里检查“文件操作路径”配置确认解析输出目录和缓存目录的权限正常。我后来在 Linux 工作环境里统一把工作目录放在 /home 下并给了当前用户完整的读写权限类似问题就再没出现过。排查这类问题不要一上来就怀疑软件本身先看一眼路径权限和磁盘剩余空间至少节省一半的排错时间。4.2 PDF 表格识别错位合并单元格和跨页续表表格错位是年报解析里最顽固的问题。三家公司年报里大量存在合并单元格例如表头“收入”横跨“产品收入”和“服务收入”两列“成本和费用”下面又分了好几行。解析工具遇到这种结构时经常把表头层级拍平导致数值对应到错误的列。我的应对策略是“拆分 人工抽查”。在解析任务里单独提取每个表格的原始结构信息不要求一次性生成完整标量子表而是把二维表格拆解成行记录每行保留“行名称、列名称、数值、单元格坐标”。这样即使最初层级关系乱了也能通过坐标信息重新拼回正确结构。实际操作中我对三家公司的合并利润表各抽查了两页发现苹果的报表结构最规整微软的附注里偶尔有跨页续表谷歌的现金流量表表格线较浅OCR 后容易出现竖线错位。针对谷歌那几页我会额外跑一次纠偏处理把页面转正后再重新解析。4.3 OCR 识别干扰中文混排和特殊符号的坑如果年报是从扫描件转的OCR 环节会出现一批莫名其妙的问题。中文和英文混排的表格里全角逗号、半角括号和单位符号最容易混在一起数字“0”和字母“O”在低分辨率扫描下也可能互相整容。还有一个常见情况是“负号”的处理报表里负数通常用括号括起来例如应付账款减少额如果 OCR 没有识别括号负号数值高低就完全反了。我在提示词里增加了一条规则遇到带括号的数字时必须显式标注“括号代表负数”并在输出结果中用负号表示。这个规则虽然简单但成功避免了好几次现金流数据被反向记录的隐患。另外如果原始 PDF 页面有歪斜解析前先做一次图像纠偏效果比事后反复修正强得多。4.4 三家财报内容差异速查表把这次摸索过程中遇到的典型情况整理成速查表给再做同类项目的人做个参考现象可能原因优先处理方式同一个指标提取出多个差异数值正表、附注、管理层讨论中口径不同以合并财务报表章节为主其他数值放备注大表跨页后续接不上表格分页时表头重复或断行按“表格名行名称”关联而不是按页拼接负数以括号形式出现PDF文本层保留括号符号提示词强制转换成带负号的数值调研费用与研发费用混淆不同公司科目命名差异维护科目映射表按业务实质归位汇总表里某一行数据来源缺失解析阶段跳过该页或该区域回查核验索引定位具体页码后补解析文件操作报错502 write eacces工作目录无写入权限转移目录或修改权限配置OCR把中文表头识别成乱码扫描件分辨率或字体问题提升DPI后重新OCR必要时人工校准表头4.5 数据质量管理交叉验证的三种方式核验机制不只是让模型回溯页码更有效的手段是引入“交叉验证”。第一种最简单把提取出来的总营收与年报开头“摘要数据”部分的值比对两家数字对不上必然有一边出了问题。第二种是“勾稽关系验证”比如利润表中的“净利润”加上“所得税费用”再加上“利息费用”应该和“利润总额”对得上如果模型给出的数字不符合这个逻辑那通常是提取值串行了。第三种是“同行对比验证”三家公司同一指标的量纲和变化幅度有常识性范围若某一家突然出现 10 倍异常多半是单位换算或小数点错误。这三种方法不依赖额外工具纯靠表格数据和财务常识就能执行建议拿到模型输出后先跑一轮再进入人工翻阅阶段可以省掉大量无用功。5. 一点实际的体会这次用 WorkBuddy 做完三巨头年报横向财务分析我最深的一点感受是真正有价值的不是把 PDF 变成表格这个动作而是表格里每一个数字都能被追回到源头。财务数据和其他文字内容不一样一个数字的错漏可能直接导致一个错误结论所以给 AI 工具提需求时“必须注明出处”这几个字值得写进每一条提示词里。另一个收获是技能复用。第一份年报从解读到调通流程用了将近一个半小时等到处理第二份、第三份时时间直接砍半。到了年底再跑新财年数据只需要更新 PDF 文件路径和个别科目映射规则整套流程就能重新执行一遍。对我来说这笔投资算是从“处理完一个项目”变成了“长出一条可持续的生产线”。如果你也想试建议不要一开始就追求全自动化先手动跑通一家公司的全部流程确认每个环节的输出质量再逐步放给自动化任务去处理。把所有踩坑经验固化到技能和提示词里把复核时间留给真正的异常情况。下次年报季你就不用再盯着 PDF 一页页抄数字了。