金融报告智能体Harness理念与实操落地指南

1. 从“能聊”到“能干”报告智能体到底在解决什么问题金融行业里做报告这件事外人看着简单内行才知道有多磨人。一份像样的行业研究报告、信贷尽调报告、投后管理报告背后往往是三五个人的团队花上一两周时间翻几十份财报、扒几百条数据、打十几个电话核实信息最后还要反复校对格式和口径。更麻烦的是这类报告的需求量还在持续增长——监管要求越来越细业务节奏越来越快客户对时效的期待越来越高。传统的人海战术已经很难跟上节奏了。这两年大模型火了之后很多团队第一反应就是“能不能让AI帮我写报告”。但真正试过的人都知道直接把问题丢给一个通用对话模型得到的往往是一堆看起来像模像样、实际上经不起推敲的文字。数据可能是编的逻辑可能是断的引用来源可能是幻觉出来的。在金融这种对准确性要求极高的场景里这种输出基本等于废纸。所以问题的关键不在于“AI能不能写”而在于“AI怎么才能写得靠谱”。这就是报告智能体要解决的核心命题。而“Harness理念”这个词是我在跟几个做金融科技的朋友交流时反复听到的一个说法它指的是一套让AI真正嵌入业务流程、而不是飘在业务外面的工程思路。Harness这个词本意是“马具、挽具”引申出来就是“把能力约束住、引导好、用起来”的意思。放到报告智能体这个场景里它意味着我们不能只做一个聊天窗口而是要围绕报告生产的全流程给AI套上一套完整的“挽具”——包括数据接入、任务拆解、工具调用、结果校验、人工复核等环节。这篇文章适合三类人看一是金融业务团队里负责报告生产的管理者想了解AI到底能帮上什么忙二是技术团队里做智能体落地的工程师想知道金融场景有哪些特殊的坑三是对AI应用感兴趣的产品经理想理解“Harness”这套思路的完整逻辑。我会尽量用大白话把技术细节讲清楚同时给出可以直接参考的实操方案。2. Harness理念的核心逻辑为什么不能只做一个“聊天框”2.1 通用对话模型的三个致命短板先说说为什么直接把大模型当报告工具用会翻车。我总结下来主要是三个问题。第一个是数据 grounding 问题。通用模型的知识来自训练语料它不知道你公司内部的信贷政策、不知道最新的监管口径、不知道某个客户上个月的经营数据。你问它“某行业今年的市场规模”它可能会给你一个看起来合理的数字但这个数字很可能是从训练数据里拼凑出来的跟真实情况差着十万八千里。金融报告里一个数字错了整篇报告的可信度就归零了。第二个是流程可控性问题。写报告不是一锤子买卖它是有流程的先明确需求、再收集数据、然后分析、最后成文。通用模型是“你问一句它答一句”它不会主动去查数据库、不会主动去核对口径、不会在写完一段之后回头检查逻辑是否自洽。你让它写一段它就写一段写完就完了中间没有任何质量关卡。第三个是责任边界问题。金融报告是要署名的是要承担责任的。如果AI写错了谁来负责通用模型给不出可追溯的推理链路你没法知道它为什么得出这个结论也没法在出问题的时候定位到具体环节。这在合规要求严格的金融场景里是不可接受的。2.2 Harness理念的四个核心支柱Harness理念说白了就是承认AI不是万能的然后围绕它的能力边界设计一套“人机协作”的工程体系。我把它拆成四个支柱。第一个支柱是数据锚定。AI的每一句结论都必须有数据来源支撑不能凭空生成。这要求我们把内部数据库、外部数据接口、文档库都接进来让AI在需要的时候能查到真实数据而不是靠记忆瞎编。技术上通常用RAG检索增强生成来实现但金融场景对检索的精度要求更高后面会细说。第二个支柱是任务编排。把“写一份报告”这个大任务拆成若干个小任务每个小任务交给AI或者人来做中间设置检查点。比如先让AI生成报告大纲人工确认后再让AI填充数据数据填充完再让AI做初步分析分析完再人工复核。这样每一步都可控出问题也能及时止损。第三个支柱是工具调用。AI不能只会“说”还要会“做”。它应该能调用计算器算财务指标、调用图表工具生成可视化、调用文档接口读取原始材料、调用校验规则检查格式。这些工具就是AI的“手”让它从“动嘴”变成“动手”。第四个支柱是反馈闭环。每一次报告生产都是一次训练数据。人工修改了AI的哪句话、驳回了AI的哪个结论、补充了AI遗漏的哪个数据这些都应该被记录下来用来优化下一轮的提示词、检索策略和校验规则。没有这个闭环系统用一年还是老样子。2.3 为什么金融场景特别需要Harness有人可能会问其他行业写报告不也需要这些吗为什么偏偏金融场景要强调Harness我的观察是金融场景有三个特殊性。一是容错率极低。一篇营销文案写错了改改就行一份信贷报告写错了可能导致几千万的坏账。这种容错率倒逼我们必须把校验环节做扎实。二是数据密度极高。金融报告里全是数字、比率、同比环比这些数据之间还有复杂的勾稽关系。AI如果只是“看起来写对了”但数字之间对不上内行一眼就能看出来。三是合规要求极严。什么能写、什么不能写、什么必须写、什么必须标注来源这些都有明确规定。AI的自由发挥空间其实很小必须被“挽具”约束住。理解了这三点就能明白为什么Harness不是锦上添花而是金融报告智能体的生存底线。3. 报告智能体的技术架构拆解从数据层到交互层3.1 整体架构的分层设计一套完整的报告智能体我习惯把它分成五层来看。从下往上分别是数据层、检索层、编排层、生成层和交互层。每一层都有各自的技术选型和设计要点。数据层是整个系统的地基。金融场景的数据来源特别杂有结构化的数据库表有半结构化的Excel和CSV有非结构化的PDF研报和Word文档还有外部API返回的JSON数据。这一层要做的就是把这些数据统一接入、清洗、标准化。我的经验是数据层的投入往往被低估很多人上来就搞模型结果发现数据一团糟后面全是坑。检索层负责在AI需要数据的时候快速准确地找到相关内容。金融场景的检索不能只靠向量相似度因为金融术语的语义空间很密集“营业收入”和“营业总收入”看起来像但口径可能完全不同。所以通常要混合使用关键词检索、向量检索和结构化查询三种方式。编排层是Harness理念的核心落地层。它负责把报告生产流程拆解成任务图决定每一步是调AI还是调人是调哪个工具以及如何传递上下文。这一层通常用工作流引擎或者代码编排框架来实现。生成层就是大模型本身负责根据检索到的数据和编排层的指令生成报告文本。这一层的关键是提示词工程和输出格式控制。交互层是给人用的界面包括报告编辑、审核、批注、版本管理等功能。这一层要设计得好用因为最终报告是要人来定稿的。3.2 数据层金融数据的接入与治理数据接入这块我踩过最大的坑就是“以为数据很干净”。实际上金融数据源的脏乱差程度远超想象。同一个指标在不同系统里可能有不同的字段名同一个字段可能有不同的单位同一个单位可能有不同的精度。所以数据接入的第一步不是接而是建立数据字典。数据字典要定义清楚每个指标的标准名称是什么、口径是什么、单位是什么、数据来源是哪个系统、更新频率是多少、责任人是谁。这个东西看起来笨但后面所有环节都依赖它。没有数据字典检索层就不知道该匹配什么生成层就不知道该引用什么。接入方式上结构化数据用ETL工具定时同步非结构化文档用解析工具抽取文本和表格外部数据用API网关统一管理。这里有个细节金融文档里的表格特别多而且很多关键数据藏在表格里。普通的PDF解析工具往往把表格拆得乱七八糟所以要用专门的表格抽取模型把表格还原成结构化的DataFrame再存进数据库。实操心得数据接入阶段一定要做“数据质量报告”统计每个数据源的缺失率、异常率、更新延迟。这些指标直接决定了后面AI生成内容的可信度。如果某个数据源缺失率超过30%那基于它生成的结论就要打问号。3.3 检索层混合检索策略的设计前面说了金融场景的检索不能只靠向量。我的做法是“三路召回重排序”。第一路是关键词召回用BM25或者Elasticsearch的全文检索把包含查询词的文档片段捞出来。这一路对专有名词、代码、数字特别有效。第二路是向量召回把查询和文档都embedding成向量算余弦相似度。这一路对语义相近但用词不同的情况有效比如“盈利能力”和“利润水平”。第三路是结构化查询如果查询涉及具体的数值条件比如“2023年营收超过10亿的公司”那就直接走SQL查询不经过文本检索。三路召回的结果合并后再用一个重排序模型通常是cross-encoder做精排把最相关的片段排到前面。这里的关键是重排序模型的训练数据要来自金融场景用通用数据训出来的模型在金融文本上效果会打折扣。检索层还有一个容易被忽略的点元数据过滤。金融报告对时效性要求很高检索的时候要能按时间范围、按报告类型、按数据来源做过滤。比如写2024年一季度报告就不应该检索到2022年的数据除非是做同比分析。3.4 编排层任务图的动态生成编排层是Harness理念最集中的体现。我的设计思路是“模板动态调整”。先为每种报告类型定义一个任务模板。比如“信贷尽调报告”的模板可能是企业基本信息核查→财务数据分析→行业对比→风险点识别→结论建议。每个节点定义好输入是什么、输出是什么、由AI还是人来做、需要调用哪些工具。但模板不能是死的。实际写报告的时候经常会出现“写到一半发现某个数据有问题需要回头补充”的情况。所以编排层要支持动态调整AI在生成过程中如果发现某个数据缺失可以主动触发一个“数据补充”子任务等数据补齐后再继续。技术上我推荐用有向无环图DAG来表示任务流每个节点是一个任务边表示依赖关系。编排引擎负责调度这些节点管理上下文传递处理异常和重试。市面上有一些开源的工作流引擎可以用但金融场景往往需要定制因为要对接内部的权限系统和审计系统。3.5 生成层提示词工程与输出控制生成层看起来最简单不就是调模型吗但实际上坑最多。金融报告的生成提示词要解决三个问题格式约束、数据引用、风格统一。格式约束是指输出的文本必须符合报告的结构要求。比如“财务分析”这一节必须包含营收、利润、现金流三个子部分每个子部分必须先给数据再给分析。这个用结构化输出比如JSON schema来控制比较靠谱让模型按固定格式输出再由程序渲染成报告。数据引用是指模型生成的每个数字都必须来自检索到的数据不能自己编。实现方式是在提示词里明确要求“只使用提供的上下文中的数据如果上下文没有相关数据输出‘数据缺失’”。同时可以在后处理阶段做校验把生成文本里的数字和检索到的数据做比对不一致的就标红。风格统一是指整篇报告的语气、用词、句式要一致。这个可以通过few-shot示例来实现在提示词里放几段标准风格的范文让模型模仿。注意事项金融场景慎用“创造性”参数。temperature建议设到0.1以下top_p设到0.9左右尽量让输出稳定可复现。有些团队为了让文字“生动”把temperature调高结果数字都开始飘了这是大忌。3.6 交互层人机协作的界面设计交互层的核心原则是让人做决策让AI做苦力。具体来说界面要支持几种操作。一是逐段审核。AI生成的每一段旁边都有“采纳”“修改”“驳回”三个按钮。审核人可以快速过一遍大部分内容直接采纳少数需要修改的才动手改。二是溯源查看。每一段AI生成的内容都可以点击查看它的数据来源包括原始文档、数据表、计算公式。这样审核人才能判断这个结论靠不靠谱。三是批注反馈。审核人可以在任意位置加批注说明为什么修改。这些批注会被收集起来用于后续的模型优化和提示词迭代。四是版本对比。报告往往要改好几版界面要能清晰展示两版之间的差异方便快速定位改动。交互层做得好不好直接决定了业务人员愿不愿意用。我见过一些系统AI能力很强但界面难用得要命最后业务人员还是回到Word里手写。所以这一层的投入不能省。4. 实操落地从零搭建一个报告智能体的关键步骤4.1 第一步场景选择与需求拆解不要一上来就做“全能报告智能体”那是个无底洞。我的建议是选一个高频、结构化程度高、容错率相对较高的报告类型作为切入点。比如“周度市场动态简报”就比“年度战略规划报告”适合起步因为前者格式固定、数据来源明确、审核要求相对宽松。选好场景后做需求拆解。把报告生产的全流程画出来标出每个环节的输入、输出、耗时、痛点。然后判断哪些环节适合AI介入哪些必须人工。一般来说数据收集、初稿撰写、格式排版适合AI需求确认、结论定调、最终审核必须人工。这个阶段一定要拉上业务人员一起做不能技术团队闭门造车。我见过太多技术团队自己觉得设计得很合理结果业务人员一看就说“这跟我们实际流程完全不一样”。4.2 第二步数据准备与知识库构建数据准备的工作量往往占整个项目的一半以上。具体要做几件事。数据源盘点列出所有可能用到的数据源包括内部数据库、文档库、外部API、人工录入的Excel等。每个数据源标注清楚数据内容、更新频率、访问方式、责任人。数据清洗把不同来源的数据统一格式。比如日期统一成YYYY-MM-DD金额统一成万元公司名称统一成标准全称。这一步要写脚本自动化不能靠人工。知识库构建把非结构化的文档研报、政策文件、会议纪要等解析成文本块每个块加上元数据来源、时间、作者、主题然后存入向量数据库。文本块的大小要适中太大检索不精准太小上下文不完整。我的经验是500-800字一块比较合适重叠100字左右。数据字典维护前面提到的数据字典在这个阶段要正式建立起来并且指定专人维护。数据字典是后面所有环节的“共同语言”。4.3 第三步任务编排与工具开发任务编排的设计要跟业务人员反复确认。我通常会用白板把任务流画出来每个节点标注做什么、谁来做、用什么工具、输入输出是什么、异常怎么处理。画完之后让业务人员走一遍看是否符合他们的直觉。工具开发这块至少要准备这几类工具。数据查询工具输入指标名称和时间范围返回数值。这个工具要对接数据字典支持模糊匹配。计算工具输入原始数据返回计算后的指标。比如输入营收和成本返回毛利率。金融指标的计算公式往往有多个版本要明确用哪个版本。图表生成工具输入数据返回图表。金融报告里常见的图表有折线图、柱状图、饼图、瀑布图等。格式校验工具检查生成的报告是否符合格式规范比如标题层级、数字精度、单位标注等。合规检查工具检查报告里有没有敏感词、有没有未标注来源的数据、有没有超出授权范围的表述。这些工具的开发要遵循一个原则输入输出都结构化。这样编排层才能方便地调用和传递数据。4.4 第四步提示词设计与迭代提示词设计是个手艺活没有标准答案只能不断试。我的经验是分三步走。第一步写一个基础版提示词把任务描述、输入数据、输出格式、约束条件都写清楚。这个版本通常效果一般但能跑通流程。第二步收集bad case让业务人员试用把生成得不好的案例收集起来。分析这些案例的问题类型是数据引用错了是格式不对是语气不对还是逻辑不通第三步针对性优化。数据引用错了就在提示词里加强数据引用的约束格式不对就用结构化输出强制格式语气不对就加few-shot示例逻辑不通就把任务拆得更细。这个迭代过程可能要持续好几周不要指望一版提示词就能搞定。而且提示词要版本管理每次改动都记录改了什么、为什么改、效果如何。4.5 第五步人工审核流程的嵌入人工审核不是简单地“看一眼”而是要设计成流程的一部分。我的做法是设置三级审核。一级审核是AI自检。AI生成完初稿后先自己跑一遍校验规则把明显的问题数据缺失、格式错误、敏感词标出来能自动修的就自动修。二级审核是业务人员审核。业务人员逐段审核重点看数据是否准确、逻辑是否自洽、结论是否合理。这一级审核的界面要设计得高效支持快捷键操作减少鼠标点击。三级审核是负责人终审。负责人看整体确认报告可以发布。这一级主要看方向性的东西不纠结细节。每一级审核的修改都要记录下来形成反馈数据。这些数据是优化系统的宝贵资产。4.6 第六步效果评估与持续优化效果评估不能只看“AI写了多少字”要看几个硬指标。指标定义目标值数据准确率生成内容中数据正确的比例98%格式合规率生成内容符合格式规范的比例95%人工修改率需要人工修改的段落比例30%报告生产周期从任务发起到报告定稿的时间缩短50%以上业务人员满意度业务人员对系统的评分4分5分制这些指标要定期统计做成看板。哪个指标下降了就去找原因。是数据源出问题了是提示词需要更新了还是业务需求变了持续优化还包括模型微调。当积累了一定量的审核修改数据后可以用这些数据对模型做微调让模型更懂你们公司的报告风格和业务逻辑。微调的数据量一般要几千条以上才有效果太少容易过拟合。5. 常见问题与排查技巧实录5.1 数据引用错误怎么排查这是最常见的问题AI生成的内容里数字对不上。排查思路是从后往前查。先看生成层提示词里有没有明确要求“只使用上下文数据”有没有给出错误示例temperature是不是设太高了再看检索层检索到的数据片段是不是正确的有时候检索会召回不相关的片段模型被误导了。检查检索的召回率和准确率看看是不是需要调整检索策略。最后看数据层原始数据本身是不是就有问题数据字典里的口径是不是和业务人员理解的不一致这种情况最隐蔽需要跟业务人员一起核对。避坑技巧在生成层加一个“数字校验”后处理步骤。把生成文本里的所有数字抽出来和检索到的数据做比对不一致的自动标红。这个步骤能拦截大部分数据引用错误。5.2 生成内容“车轱辘话”怎么办AI写报告容易犯的一个毛病是“废话太多”一段话翻来覆去说同一个意思。这通常是因为提示词里给的约束不够具体。解决办法是用结构化输出替代自由文本。不要让模型自由发挥而是让它按固定模板填充。比如“财务分析”这一节模板可以是营收情况[数据] [同比/环比] [简要分析] 利润情况[数据] [同比/环比] [简要分析] 现金流情况[数据] [同比/环比] [简要分析]这样模型就没有空间去“发挥”了只能老老实实填数据和分析。另外可以在提示词里加一句“每段不超过150字直接给结论不要铺垫”。这个约束对减少废话很有效。5.3 审核人员觉得“不好用”怎么破这个问题往往不是技术问题而是流程设计问题。审核人员觉得不好用通常是因为系统增加了他们的工作量而不是减少了。我的经验是要让审核人员感受到“AI帮我省事了”。具体做法包括AI生成的初稿要尽量完整不要让审核人员从零开始写审核界面要支持批量操作比如“全部采纳”“全部驳回”修改要方便支持直接编辑而不是重新生成。还有一个关键是让审核人员参与设计。在系统开发阶段就让他们试用收集他们的反馈让他们觉得这是“自己的系统”。这样上线后接受度会高很多。5.4 模型输出不稳定怎么处理同一个输入两次生成的结果不一样这在金融场景里很让人头疼。原因是模型本身有随机性即使temperature设得很低也不能保证完全一致。处理办法有几个。一是固定随机种子如果模型API支持的话。二是缓存结果同样的输入直接返回缓存不重新生成。三是后处理标准化把生成结果里的同义词统一替换比如“营收”和“营业收入”统一成“营业收入”。但根本上要接受“AI输出不可能100%稳定”这个事实然后在流程上设计容错。比如关键数据不让AI生成而是从数据库直接取AI只负责组织语言。5.5 常见问题速查表问题现象可能原因排查方向解决措施数据引用错误检索召回不准/提示词约束不够检查检索结果和提示词优化检索策略加强数据引用约束内容重复啰嗦提示词太宽松/模型自由发挥检查输出格式约束改用结构化输出加字数限制格式不符合规范缺少格式校验/模板不明确检查格式校验工具增加后处理校验明确模板审核人员抵触流程设计不合理/界面难用收集审核人员反馈优化界面让审核人员参与设计输出不稳定模型随机性/参数设置不当检查temperature和top_p降低随机性加缓存后处理标准化敏感词漏出合规检查不全面检查敏感词库扩充敏感词库增加人工复核5.6 几个独家避坑技巧技巧一先做“报告助手”再做“报告智能体”。不要一上来就追求全自动先做一个辅助工具帮业务人员查数据、写初稿、做格式检查。等业务人员习惯了再逐步增加自动化程度。这样风险可控接受度也高。技巧二把“人工修改”当成训练数据。每次审核人员修改AI生成的内容都记录下来。积累到一定量后用这些数据做微调效果比单纯调提示词好得多。技巧三设置“熔断机制”。如果AI连续生成的内容都被驳回就自动切换到人工模式不要让AI继续浪费时间和资源。同时触发告警让技术团队介入排查。技巧四定期做“对抗测试”。找一些故意刁钻的输入比如数据缺失、数据矛盾、格式异常的情况看系统怎么处理。这些边界情况往往是最容易出问题的。技巧五保持“人在回路”。无论AI多强最终报告必须有人签字负责。这不是对AI的不信任而是金融行业的责任要求。系统设计上要确保人工审核环节不可跳过。6. 报告智能体的能力边界与未来演进6.1 当前阶段AI能做什么、不能做什么把AI用在金融报告生产上最怕的就是“期望错位”。期望太高觉得AI什么都能干结果失望期望太低觉得AI就是个玩具结果错失机会。我的判断是当前阶段AI能做好的是信息整合、初稿撰写、格式检查这三件事。信息整合是指把散落在不同数据源的信息汇总到一起按主题归类。这个AI做得比人快得多而且不会漏。初稿撰写是指根据整合好的信息生成结构完整、语言通顺的报告初稿。这个AI也能做得不错但前提是数据要准确、模板要清晰。格式检查是指检查报告的格式是否符合规范比如标题层级、数字精度、单位标注、引用格式等。这个AI可以做到接近100%准确。AI做不好的是判断性工作。比如判断某个数据异常是不是因为口径变化、判断某个风险点是不是足够重大、判断结论是不是符合公司当前的业务策略。这些需要业务经验和行业直觉AI目前还替代不了。6.2 从“辅助”到“协作”的演进路径报告智能体的演进我观察到的路径是三个阶段。第一阶段是“工具辅助”。AI作为一个工具帮业务人员查数据、做计算、检查格式。业务人员主导整个流程AI只是打下手。第二阶段是“流程协作”。AI嵌入到报告生产流程中承担一部分任务业务人员承担另一部分。双方有明确的分工和交接点。目前大部分做得比较好的团队处于这个阶段。第三阶段是“主动建议”。AI不仅能完成任务还能主动发现问题、提出建议。比如“这个数据跟历史趋势不符建议核实”“这个风险点在上次报告里提到过建议跟进”。这个阶段需要AI对业务有更深的理解目前还在探索中。6.3 技术演进的方向从技术角度看有几个方向值得关注。一是多模态能力。金融报告里有很多图表未来的智能体应该能直接“看懂”图表从图表里提取数据而不是依赖人工把图表转成表格。二是长上下文处理。金融报告往往要参考大量历史材料上下文长度是个瓶颈。随着模型上下文窗口的扩大这个问题会逐步缓解。三是推理能力增强。金融分析需要复杂的逻辑推理比如“因为A所以B因为B所以C”。当前的模型在长链条推理上还容易出错未来会有专门的推理增强技术。四是多智能体协作。一份报告可能涉及财务、行业、法律等多个维度可以由多个专业智能体分别负责最后汇总。这样每个智能体可以更专注、更专业。6.4 组织层面的配套调整技术只是一半另一半是组织。报告智能体要真正落地组织上要做几件事。一是设立“AI产品经理”角色。这个人既要懂业务又要懂技术负责把业务需求翻译成技术方案把技术能力翻译成业务价值。二是建立“数据治理”机制。数据质量是智能体的生命线要有专人负责数据字典维护、数据质量监控、数据源更新。三是调整考核方式。如果业务人员的考核还是“写了多少份报告”那他们就没有动力用AI。要改成“报告质量如何”“审核效率如何”让AI成为帮手而不是威胁。四是持续培训。业务人员要会用系统技术人员要懂业务逻辑这都需要持续的培训和交流。6.5 一个值得关注的趋势报告即数据产品最后说一个我观察到的趋势。随着报告智能体的普及报告本身可能会从“文档”变成“数据产品”。什么意思呢就是报告不再是一篇静态的文章而是一个可以交互的数据界面。读者可以点击某个数字看它的来源可以调整参数看不同情景下的分析结果可以订阅某个指标的更新提醒。这个趋势对报告智能体的要求更高它不仅要会“写”还要会“组织数据”“设计交互”。但这可能是金融报告的未来形态。那些现在就开始积累数据资产、建设智能体能力的团队会在未来占据先机。我在实际项目中的体会是报告智能体这件事技术不是最大的障碍业务理解和流程重构才是。很多团队花大力气搞模型、搞架构结果发现业务人员不买账因为系统没有真正解决他们的痛点。所以我的建议永远是先蹲到业务现场去看他们怎么工作、卡在哪里、最烦什么然后再回来设计系统。Harness理念的核心说到底就是“以业务为中心让AI适配业务而不是让业务适配AI”。这个顺序搞对了事情就成了一半。