作者：杜志伟 枫清科技技术架构师
开篇：先看两个回答，问的是同一个问题
用户问：X月公司营收表现如何？
回答A：
X月公司营业收入为 X 亿元，预算达成率95.5%，较预算差额 -X 千万元。同比增长11.4%，环比下降 4.2%。
按事业部营收排名：事业部A占35.0%，事业部B占24.2%，事业部C占 20.2%，事业部D占18.9%，其他占1.7%。
回答B：
1.营收总额与预算达成
X月营收未达预算目标，预算差额为 -X 千万元，达成率 95.5%。值得注意的是，同比去年同期增长超过 11%，说明业务整体仍在扩张；但环比上月下滑约 4%，节奏较预算计划偏慢。同比涨了，预算却没达------这一组数据的张力，是本月营收分析的核心线索。
2.营收结构下钻
4个核心事业部合计覆盖营收 98% 以上，其中事业部 A（35%）和事业部 B（24%）贡献超过半数，是营收的主要承压方，也是差距的主要来源。
3.结论与建议
本月预算缺口并非需求萎缩导致（同比仍增长），更可能源于季节性节奏偏差和部分订单的延迟交付，建议优先排查头部事业部的产能调配和交付达成情况。
两份回答，数据来源完全一样。差距在哪？
回答A 把数字报了一遍 ，读完知道发生了什么；回答 B 识别出「同比涨了但没达预算」这个数据内在的张力 ，解释了背后的逻辑，还给出了方向------读完知道接下来要做什么。
这中间经历了将近半年的迭代，这篇文章讲的就是这段过程。
一、从需求到产品形态：一开始谁都没谱
做AI项目，很多企业一开始对最终长什么样、好到什么程度 ，心里是没谱的------这往往并不是需求方不专业，而是经营分析与大模型结合 这件事，行业里本就没有多少可照搬的成熟范式：客户与实施方在很大程度上是同时第一次 在真实业务里「尝鲜」，用 AI 去支撑一类此前很少被完整产品化过 的能力。没有现成剧本，就意味着需求、效果与边界都要在共创里逐步显影；对团队而言，这也意味着要在开放场景下持续消化不确定性、把链路走通 ，本身就是对交付与工程能力的考验。
另一方面，大模型并非确定性系统：输出带随机性，幻觉与越界在开放域里难以根除。要把这样的能力用在严肃经营口径与可追责结论 上------本质上是在做一件事：驯服模型 ，让它在既定业务与数据边界内可靠工作。下文所述的迭代，也是把模型行为逐步压进可审计、可复用系统能力的过程。没有先例可循时，能否把业务、数据与工程拧成一股绳，决定了这类项目能不能真正落地 ；我们在项目中的做法，正是围绕这一前提展开。
在此前提下，我们配合业务咨询，把需求从面上那层大方向往能落地、能验收 里收：营收、毛利、净利、成本、费用......既有经营分析里通用的一套东西 ，也要叠上行业（如：半导体制造）这类行业语境 ，再加上客户公司自己的 分析口径和关注点。
需求理清楚之后，反而更难的一件事来了：产品形态和效果只能先妥协成「迭代」 ------第一版不可能一步到位，但每一版都得对得起「真的有人在用」这件事。
二、两版迭代：问数能跑，
但「答得好」和「跑得通」不是一回事
我们当时的直觉是：workflow能串起来就行。于是第一版很直白：
背后是把咨询梳理结果固化成「分析模板」：指标取数配置+ 提示词 ，再叠上我们已有的「指标问数」能力，把多条问数结果拼成一段回答。
这套模板库知识不是凭空来的------业务咨询阶段花了将近1~2 人/月 ，跨了经营、财务、运营多个业务条线，最终沉淀了100 多个分析模板 。每个模板的结构参考了Plan-Execute 类Agent few-shot 的写法，目的是让大模型能学着客户自己的分析方式来回答，而不是套通用话术。
这一版在「小范围、偏演示」的场景里其实还行 ------尤其是早期对接的多是公司管理层视角的咨询反馈，问题相对收敛。
一上线，真实用户一上来，画风就变了：
问题更口语、更发散， 模板只能盖住一小撮；很多回答显得「固定套路」，容易答非所问。
模板覆盖不了的时候，召回逻辑又是选或不选 ，没有「当参考用」的中间态，结果还是硬套，用户体感就是：一点也不AI 。
所以我们很快加了一条自由分析链路 ，缓解回答容易「跑偏」
模板匹配度高 ：走原来的「多指标问数+ 润色」。
模板匹配度低 ：先召回业务梳理过的知识，把问题拆成多条自然语言的问数，再走「多指标问数+ 润色」。
第二版抱怨少了些，但焦虑没消。 客户那边其实相当包容------他们没有简单地说「这东西不好用」，而是认真地提出了自己从经营管理视角 看报告的诉求：管理层要的不是「把数念一遍再总结两句」，而是一份真正能辅助决策的解读。这个反馈让我们意识到，问题不是链路有没有跑通，而是回答的深度和方式根本就不对 ------就像开篇里的「回答 A」，数字都对，但不是管理层想要的那种回答。
三、转折点：调参优化到头了，路线要换
那阵子我们很多时间花在：调模板召回、调问数准确率、调提示词------链条拆开看，每一段都能优化 ；但改完一环之后，客户的焦虑并没有跟着消散。
转折点发生在一次例会后。客户在群里分享了她自己用ChatGPT 做经营分析的完整步骤和效果截图，大意说了一句：「大模型越来越聪明，你看 ChatGPT 回答的思路就很好，为什么我们这个做不到？」
这句话当时挺刺的，但也是真正说清楚了问题所在------客户要的是垂直领域的经营分析知识 ，而不只是一个能接指标的问答框。通用大模型在经营分析领域的知识积累，在某些问题上确实比我们当时的产品更接近「分析师思维」。
这件事之后我们意识到两件事：
1.要对模型做系统性评测 ，而不是凭感觉调提示词------找到真正具备经营分析知识的模型（或通过知识注入的方式强化）；
2.整体路线要调整 ，不能只靠「模板+ 润色」的方式做到「像分析师写报告」的效果，需要让系统具备经营分析师的思维框架 。
跟客户往深聊之后，目标反而变清晰了：
1.输出要符合经营分析的思路 ------不是泛泛的问答，而是有方法论支撑的分析框架；
2.受众是经营管理者 ------更像「有个分析师帮你写经营分析报告」。
这就不是「再多接几条问数」能解决的问题了。我们归纳成几件硬条件：
于是路线从「模板为主」转向：自由分析（Agentic RAG）为主，模板为辅 ------整体链路做了比较大的重构。
四、当前主链路长什么样
用一句话概括：先尽量理解用户在经营分析里真正想问什么，再决定走「模板快车道」还是「自由分析链路」 。
模板快车道 还会新增一步：用问数润色结果作为知识，再围绕用户问题做一轮「经营向」的润色 ，让输出更贴管理层语境。
自由分析链路的核心：Plan至少是两步，不是一步
很多人理解的plan 是「大模型出一个分析大纲」，我们实际做下来发现这不够用。Plan 至少要分两个层次：
第一步------建骨骼 ： 识别用户在经营分析里的真实意图，在业务允许的范围内发散分析板块，输出回答框架+ 各分析点的思路要点 。这份框架是「分析师视角的报告提纲」，会作为上下文骨架贯穿后续全程。
第二步------填血肉 ： 根据框架里的每个分析思路要点，结合我们的指标问数方案，拆解出具体支持取数的标准化提问------这步决定了「想说的话」能不能被数据真正撑起来。
这两个步骤是通用的报告写作方法，但想要驾驭住大模型发挥的效果贴合用户的实际业务来做分析，那就需要两大法宝了：业务咨询的产物转成Plan-Execute类智能体fews-hot风格的业务分析知识作为缰绳、业务与指标关系的总览知识是马镫 ，这样我们在运行的道路上才不至于效果翻车。
业务咨询的产物 不只是模板，还有一批按CoT 结构转换的业务分析知识（带分析逻辑的结构化知识），这批知识在 Agentic RAG 路线里被召回，作为 plan生成的参考依据，让系统的分析思路能贴近客户自己的业务分析方法，而不是大模型凭空发散。
不过Plan 做得再好，前提是入口先对------分词和意图识别 的质量直接决定后续所有环节的上限，这块坑我们单独放下一篇 内容详细说。
智能体流程是在业务方法论 之上做自动化回答规划------技术链路和业务叙事需要能互相对上，才不会变成「技术自嗨」。
五、来点真实感受：再来一个case 拆解
以下内容已脱敏，具体数字和维度值仅作示意。
Case 1：库存归因分析------Agentic RAG怎么做「因果链」追溯
这个case 更能体现 Agentic RAG 方式的价值。用户问的是：「X 月公司库存增长的主要原因是什么？」
归因类问题以前最难处理------模板很难预设「答案是交付问题还是产能问题还是需求问题」，逻辑分支太多。
Plan第一步------先建因果框架
系统根据咨询的公司分析知识+ 通用的经营知识 识别出这是「产销存闭环」归因分析，plan 给出分析路径：
库存增长 ≈ 产量 − 发货量，分析要从三个方向追：生产端、销售端、交付端。
Plan 第二步------拆成三组取数
取数结果一步步「收口」到根因
步骤1：库存金额环比增长约 X%，主要集中在原材料类和几个核心事业部；
步骤2：订单需求量 > 实际发货量，缺口数十万片------市场需求是有的，****不是卖不出去；****
步骤3：多个核心事业部交付计划达成率偏低，部分重点客户（客户 A、客户 B）达成率极低，在 30% 以下------产品生产出来了，但出不了库。
最终结论水落石出：不是生产过量，不是需求不足，而是交付环节卡住了。
>（参考效果见下图，非产品截图）
如果没有先把「产销存闭环」这条因果逻辑铺出来，系统可能只会给一张库存汇总表。有了框架，取数顺序、成文叙事都跟着因果链走，最终报告读起来像「分析师在帮你排查问题」，而不是「数仓在帮你出报表」。
结语
经营分析这类场景，难的不是技术本身 ，而是业务咨询与技术服务业务需求要并重 ：前者把口径、场景和「经营分析」到底解决什么问题想清楚，后者把这些变成能跑、能迭代的链路。车轮缺一边，另一边再使劲也容易变成空转。真正把这事儿往前推的，是在这条路上持续跟客户对齐他们的高要求 ：多轮沟通、反复验收，产品才能一步步演进；当然，笨功夫也省不了------一遍遍测、改、回归，一点点给技术链路补上血肉。