一次用 WorkBuddy 拆开腾讯、阿里与 DeepSeek 的行业研究实践：先核口径，再写结论。
做财报的人大概都见过这种时刻：一份中报刚出来，收入在涨，利润也在涨，旁边再摆着"AI 拉动增长"几个字。标题好像已经自己写好了------AI 赚钱了。
我这次差点也这么写。
后来把腾讯、阿里、DeepSeek 放进同一个 WorkBuddy 工作区，事情忽然没那么简单了。腾讯利润增长，二季度自由现金流却是负数；阿里云和算力业务增长很快，集团经营利润却在下滑；DeepSeek 的技术报告写着推理更省算力，但它压根不是一张公司利润表。
真正有用的问题不是"谁的 AI 更厉害"，而是：这些数字到底能说明什么，又不能说明什么？
这篇文章就是我拿 WorkBuddy 做完这份行业研究底稿后的复盘。它没有替我拍板"买还是不买"，倒是帮我把一堆很容易混在一起的数字，一点点拆开了。
先把结果摆出来：这次到底做出了什么
先说交付物。整个任务最后落下来的，不是一篇漂亮的总结，而是几样能继续翻、能继续查的东西：
- 腾讯：100 行指标表、分析备忘录、校验日志；
- 阿里：65 行指标表，以及生成表格和复跑的脚本；
- DeepSeek：39 行技术经济性证据矩阵；
- 跨公司：20 个对比维度、一份对比备忘录、一份校验日志；
- 其中 DeepSeek 的预设校验实际跑了 72 项，全部通过；跨公司底稿留下了 6 条修正及对应复核方式。
最后得到的判断，其实不花哨：
| 样本 | 这次看到了什么 | 这次不该说什么 |
|---|---|---|
| 腾讯 | 业务增长与投入前置可以同时发生 | 现金减少全是 AI 造成的 |
| 阿里 | 云与算力业务增长快，但集团层面的账要分开看 | 云增长就等于集团利润增长 |
| DeepSeek | 技术效率是重要线索 | "更省算力"等于公司更赚钱 |
这张表看着很朴素，但它就是这次实践最想保住的东西：不把一个好听的结论，当成一个已经被证明的结论。
图 2：真实校验日志。白框里是 6 条已经落实的修正：发布日期靠人工核对；"研发、折旧、资本开支不能全部归 AI"被写成边界；两期自由现金流要在 CSV 里分开标来源。这里不是一句"已检查"，而是把怎么检查也留了下来。
我是怎么让 WorkBuddy 开工的
这不是一个"给我写篇财报分析"的任务。
我先在"行业应用指南"工作区里放进公开披露材料：腾讯 3 份 PDF、阿里 3 份公告材料、DeepSeek 的模型卡和技术报告。权限设置只涉及工作区文件访问；这次实际处理的也只有这些公开文件和输出目录。没有接外部数据库，也没有额外使用专家、MCP 或连接器。
接着，我把任务拆成四份 Markdown 提示词：腾讯、阿里、DeepSeek、跨公司对比。这样做有个很现实的好处：以后换一家公司，不用重新口述一大段要求，改材料、改期间，再让它从同一套规则起跑就行。
图 3：任务刚开始时，WorkBuddy 没有直接下结论，而是先列出计划：盘点文件、提取指标、标页码、核对 IFRS/non-IFRS、季度/半年和分部口径；遇到差异就记录，不自己补数。
我给它的核心要求只有几句话：
md
只使用我指定的公开材料。
先提取，再计算，再写观察。
每个数字都要带文件、页码、原文短摘和验证状态。
没有披露就写 N/A，不能猜，更不能用别的数字硬补。
把公司事实、公司解释、研究判断分开写。听上去像常识，真正做起来却很管用。因为财报里最容易出错的，往往不是算错 1+1，而是把同名但不同口径的"1"拿来相加。
第一步：腾讯这关，先别把利润和现金混成一件事
腾讯是我先跑的样本。它的材料最齐，正适合拿来试规则会不会漏。
上半年，腾讯收入 401,243 百万元，归母净利润 114,115 百万元，同比分别增长 10.1% 和 10.3%。如果只看到这里，故事很顺：业务在涨，利润也在涨。
可再往下翻，经营活动现金流净额是 154,061 百万元，同比增长只有 1.9%；资本开支 84,720 百万元，同比增长 81.9%；二季度自由现金流则是负 13,800 百万元。
这就像一家店铺，账面利润不错，但收银台里的现金并没有跟着轻松起来。不能说店铺不赚钱，只能说钱去了别的地方，得把去向看明白。
腾讯二季度公告给出的自由现金流口径是：
md
52,700 经营现金流
－59,300 资本开支付款
－ 5,000 媒体内容付款
－ 2,200 租赁负债付款
＝－13,800 自由现金流这里 WorkBuddy 帮我抓到一个很小、但很关键的区别：二季度"资本开支"是 52,784 百万元，"资本开支付款"却是 59,300 百万元。名字只差两个字，放进现金流公式里，结果就不是一回事。
它还曾经把同一个 130,115 匹配到了错误科目。数字是真的，页码也是真的，但上下文不对。后来回查后发现，那不是上半年游戏收入的出处。这个小插曲让我更愿意相信"留下回查路径"这件事：AI 不怕犯错，怕的是它犯了错，你找不到它从哪儿拐弯了。
图 4：真实运行过程。白框突出的是回查原文页码、处理口径差异和后续校验的记录。工具留下了动作轨迹，后面的人才能接着核。
我最后保留的说法是：腾讯的成熟业务仍在增长，AI 相关投入也在前置；但"现金减少全是 AI 导致"没有足够依据。这个分寸，恰恰比一句豪言壮语更值钱。
我查的是腾讯公开的 2026 中期报告、中期业绩公告 和 二季度演示材料。
第二步：换到阿里，先确认"云"是不是同一块云
轮到阿里，最容易踩的坑不是数字，而是时间。
阿里的 2026 财年截至 2026 年 3 月 31 日。要是把财年数字直接叫成"2026 年上半年"，文章从第一行就跑偏了。所以我把主对比窗口固定在 4---6 月；只有定义兼容的集团流量指标，才允许把 1---3 月和 4---6 月加起来，并且明确标为算术合计。
6 月季度，阿里集团收入 268,953 百万元，同比增长 9%；AI 云与算力服务收入 48,437 百万元，同比增长 45%；其中披露的 AI 相关产品收入为 12,376 百万元。
这组数据确实亮眼，但也别急着把它念成"某个产品的 API 收入"。公司怎么披露，底稿就怎么记；没有拆分，研究者就别替公司拆分。
图 5：阿里案例的真实过程截图。展开 Process 后，可以看到生成脚本、检查指标表、修改后再生成的过程。能留下脚本，意味着以后换期间或换口径时，不必从头猜。
再看现金流。阿里当季经营活动现金流为 22,945 百万元，自由现金流为负 44,670 百万元。公告里的调节表是这样算的：
md
22,945 经营活动现金流
－67,660 物业及设备购买额
＋ 45 买家保障基金存款变动
＝－44,670 自由现金流中文摘要里还有一个 67,678 百万元的资本性支出。只差 18 百万元，看着像小数点后的毛边，但它们来自不同披露位置，不能为了把公式凑整就偷偷互换。
所以，阿里这个样本给我的不是"云增长所以一切都好"，而是另一句更老实的话：业务增长、持续投入、减值和拨备，可能同时出现在一张季报里。把它们都塞进"AI"这个盒子，反而看不清。
我查的是阿里公开的 6 月季度发布页、完整业绩公告 和 3 月季度及财年公告。
第三步：DeepSeek 这题，空白比硬填更有价值
DeepSeek 是这次最容易让人"脑补过头"的样本。
模型卡和技术报告里有不少很吸引人的数字：V4-Pro 总参数 1.6 万亿、每个 token 激活 490 亿；报告还写到，在百万 token 上下文的特定条件下，V4-Pro 单 token 推理 FLOPs 约为 V3.2 的 27%，KV cache 约为其 10%。
这些都是很好的技术经济性线索。但它们不是公司收入、不是毛利率、更不是利润表。
我在提示词里把这条写死：没有公司层面的收入、利润、经营现金流和资本开支披露，就写 N/A。不拿媒体估值、训练 GPU 小时或 API 单价来补空。
_图 6：DeepSeek 案例的过程。它先保存网页材料的当时记录，再和模型卡、__技术报告 _一起核对，最后才建校验脚本。网页会更新，留一份当时看到的文本，后面才知道自己研究的是哪个版本。
图 7：WorkBuddy 展开"Final verification run"后，校验脚本实际运行成功，随后生成 72 项全部通过的证据矩阵。它证明的是预设规则被跑通，不是说我重新跑了模型 基准测试__。
这一段最让我满意的结果，不是多写了几个数字，而是保住了几个 N/A。行业研究里，知道哪里还不知道，往往比把表填满更专业。
我查的是 DeepSeek 的 透明度中心、V4 中文模型卡 和 V4 技术报告。报告里的效率数据只代表报告描述的实验条件，本次没有重新运行模型测试。
把三家公司放在一起，WorkBuddy 最有用的地方出现了
单家公司还好说，横向一比，真正麻烦的地方才冒出来。
腾讯用 IFRS，阿里用 US GAAP；两家"调整后利润"的加回项和归属口径不一样；自由现金流的公式也不是同一道题。把它们按金额排个名，看上去很像研究，实际上很可能是在比两把不同刻度的尺子。
图 8：跨公司对比备忘录的结果截图。统一期间、IFRS 与 US GAAP 的调整口径差异，以及两家自由现金流公式。它最后没有给"谁更高"的排名，而是先把不能直接比的理由写清楚。
这个动作很像做饭前先看量杯：你当然可以把水倒进去，但得先确认两只杯子是不是同一刻度。
对比日志里还保留了 6 条修正。比如，日期要人工复核；"提前买下未来几年算力"这种说法不能写成确定事实；"现金流变差排除盈利质量问题"也不能贸然下结论。这些不是什么炫技，都是在拦住一句可能写过头的话。
如果你也要复现，提示词别只写"帮我分析一下"
我把这次实际使用的提示词分别保存为 01-tencent-original.md、02-alibaba.md、03-deepseek.md、04-cross-company-comparison.md。换公司时，下面这段通用要求可以直接拿去改：
md
只读取我指定的公开材料。先列文件、发布日期、覆盖期间和页数。
每条指标都写清：期间、口径、单位、当期值、比较值、文件、页码、原文短摘、公式、验证状态。
相同数字必须回看前后科目名称；只有一个出处时标为单一来源。
没有材料写 N/A，不得用常识、估值或别的口径补数。
输出指标表、分析备忘录、校验日志，并保留提取文本、脚本和实际运行结果。然后再给每家公司补一条"家规"。腾讯要分开 IFRS 和 non-IFRS；阿里要分开财年和自然年、旧分部和新分部；DeepSeek 则先判断它拿到的是技术材料还是财报。
别一上来就让工具同时分析十家公司。先挑一家跑通。哪怕第一轮发现了一个页码错配，也比十家公司一起错得整整齐齐好修。
收尾：我需要的不是一句 AI 万能，而是一份能查错的底稿
这次实践里，WorkBuddy 干得最像同事的地方，不是替我写出一句多漂亮的话，而是把那些重复、细碎、又最容易漏的动作摆在台面上：翻页、抽取、标注、换算、留脚本、跑校验、记下修正。
我负责的部分也没少：决定看什么，判断哪些口径不能混，看到一句过头的话时把它按住。
最后，腾讯、阿里和 DeepSeek 没有被压成一个"AI 公司排行榜"。它们变成了三种不同的观察入口：成熟业务怎么承接 AI，云和算力怎么穿过集团报表，技术效率又该怎样和公司经营分开看。
下一次换一家公司，我大概还是会先让 WorkBuddy 建底稿，再慢慢写结论。因为在财报里，最让人安心的不是一句"我觉得"，而是你随时能问一句：这个数字，是从哪儿来的？