技术更新 or 组织重塑，企业如何用好“数据智能”？

大模型浪潮正引领数据管理与分析迈入全新阶段，Chat BI、Agent+Workflow 等应用，使业务人员能够通过自然语言交互即时获取数据洞察，显著释放生产力。那么，如何构建高质量数据集、优化检索效率？如何让数据在大模型的应用中发挥最大效能？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了 DaoCloud 道客联合创始人兼首席技术官郭峰 担任主持人，和 中电金信研究院副院长单海军、数据项素产品副总裁覃睿、货拉拉大数据专家凌霄 一起，在 AICon全球人工智能开发与应用大会2025 北京站 即将召开之际，共同探讨智能化数据管理体系的搭建。

部分精彩观点如下：

• 多模态场景下，比如涉及视觉、语音等复杂交互的任务中，跨模态对齐仍然离不开人工标注和指导。

• 在 Chat BI 落地过程中，既要关注模型训练的科学性，也必须重视底层数据是否适配 AI 应用需求。

• Deep Research 不仅是传统 RAG 的扩展，它代表着大模型应用从检索辅助走向多阶段、可规划推理的质变。

• 大模型的角色应该像水一样，流向它真正能发挥作用的地方，而不是硬性地作为一个“主体”插入到流程中，让其他人去围着它转。

在 6 月 27-28 日将于北京举办的 AICon 全球人工智能开发与应用大会 上，我们特别设置了【大模型时代的数据处理与分析】专题。该专题将围绕数据科学家、工程师、技术管理者等不同角色的从业者，通过实际案例分析和专家分享，探讨如何提升数据质量、优化检索效率，构建智能化数据管理体系，让数据在大模型的应用中发挥最大效能。查看大会日程解锁更多精彩内容：https://aicon.infoq.cn/2025/beijing/schedule

以下内容基于直播速记整理，经 InfoQ 删减。

完整直播回放可查看：https://www.infoq.cn/video/FiSDqhipW2MwL9EoKXJH

数据构建的挑战与趋势

郭峰：像 SFT、RLHF 这些数据现在构建和处理上有哪些变化？

单海军： 第一，数据构建方式正从割裂的范式向统一的训练框架演进。以往的流程一般是先通过 SFT 进行高质量问答数据标注和初步调优，再通过 RLHF 等方式进行偏好对齐和精调。这一过程通常包括两至三个阶段，甚至还涉及预训练或增量预训练。但现在已有新方法，比如清华大学提出的 IFT（直觉微调），将 SFT 与 RLHF 融合，从而减少了对数据的依赖，同时提升了训练效率，缩短了后训练流程。

第二，数据构建正在趋于轻量化和自动化。以前 SFT 和强化学习的数据主要依赖人工标注，而现在大量合成数据的出现，尤其是偏好标注的自动化，大大减少了人工介入。

第三，数据量并非越多越好。当前越来越多团队开始重视数据蒸馏技术，用以从海量数据中筛选出最具价值的部分。例如，手头可能有 50 万条数据，但真正有效的可能只有 10 至 20 万条。因此，关键在于通过合理策略挑选出有价值的数据进行训练。

郭峰：有没有什么“坑”是大家常踩的？

单海军： 第一，数据配比至关重要。即便是训练垂直领域大模型，也不能完全舍弃通用数据。无论是增量训练还是 SFT 阶段，都需要合理融合通用与金融领域的数据。

第二，任务上的数据分布要均衡。即便目标是构建一个用于报告撰写的模型，也应涵盖问答、多轮对话、文本质检等多种任务类型，从业务和任务两个维度保证数据的全面性。

第三，最关键的是数据质量。必须对数据进行筛选和清洗，剔除低质量样本，同时提升数据的多样性和丰富度，这样训练出的模型效果才会更理想。

郭峰：现在也有像 DeepSeek 这样的模型走纯 RL 路线，很多人开始在问：我们还需要那么多标注数据吗？您怎么看未来数据的“标注”价值？

单海军： 去年我们在训练金融大模型时，自行构建了大约 60 万对指令数据。过去我们更关注数据的数量，而现在则更加注重数据的质量。并不是说数据变得不重要了，而是对高质量标注数据的重视程度提升了，同时对低质量、泛数据的依赖明显下降。

此外，在多模态场景下，比如涉及视觉、语音等复杂交互的任务中，跨模态对齐仍然离不开人工标注和指导。所以，我认为有两个显著的变化：第一，从“重数量”转向“重质量”；第二，场景和领域适配的数据变得更为关键，甚至需求更多。举例来说，在企业级应用中，通用模型常常需要融合特定行业知识，比如金融领域中风控规则的多样性需要精确标注；工业质检中，缺陷样本本身就非常稀缺，收集和标注工作对于模型的实用化至关重要。

郭峰：在企业落地过程中，会不会觉得“数据准备”是最容易被忽视、但最难做好的环节？

覃睿： 首先，直观感受是——数据相关的工作“脏且累”。做过数据处理的同事都清楚，这项工作周期长、过程枯燥，往往缺乏直接成效的呈现，所以它的确是易忽视、难做好。从我们企业服务的实际情况来看，真正涉及模型微调的客户比例其实很低，大概只有十分之一到二十分之一。相较科技公司，很多传统企业并不是以大模型为核心技术能力，它们在数字化基础建设上仍有较大差距。对这些企业而言，无论是从认知还是准备工作来看，直接开展微调模型都存在较高门槛，只有在少数如客服等语料较为完备的场景中，我们才真正推动落地。

在数据相关的场景中，我们主要观察到以下三类问题：第一类是文档解析。企业内部存在大量非结构化数据，如 PDF、Word 文档等。如果一张表格跨页被错误切分，导致表头缺失，那么模型无法准确理解每一列的含义。因此，像表格识别、跨页拼接、段落标题识别与按逻辑结构切分等能力，都会直接影响大模型生成内容的准确性和可控性。

第二类是 QA 数据构建。这里的 QA 并非用于微调模型，而是直接根据用户问题匹配最相关的 QA，并返回对应的答案。这类 QA 可以由人工审核以确保 100% 可控性，适用于一些直接面向客户的应用。同时，我们发现一个常见误区：很多客户希望我们根据提供的文档自动生成大量 QA 对。然而在实际项目中，这种做法生成的问答看似合理，却往往与用户真正关心的问题存在明显偏差。因为模型生成的问题多基于通用逻辑，而不是业务需求。相比之下，我们更推荐在系统上线后，通过真实用户的使用行为，逐步积累高质量、具有代表性的问题，再用于优化系统，这样价值更大。

第三类是结构化数据处理，特别是“智能问数”场景（Chat BI）。这类应用的挑战极大，因此我们一般不会作为首选落地方案，而是推荐先从知识问答、文档审核、报告撰写等更成熟的场景做起。智能问数虽然是领导最关注的方向，但想要达到 99% 甚至 100% 的准确率，目前行业内还缺乏成熟、可复制的方法。比如市面上的一些开源框架如 SuperSonic，尝试通过构建“语义层”来让大模型理解数据库中的字段含义。但由于很多企业的底层数据治理质量不高，字段命名混乱，仅有开发人员清楚其含义，这就对语义层的构建提出了很高的要求。整个流程不仅复杂，调试成本也高，导致最终投入产出比比较差。最后，即使能实现 90% 的准确率，领导也会质疑那剩下 10% 的错误该如何处理，这种不确定性让企业难以完全信任模型结果。

所以从实际应用角度看，我们认为更务实的做法是：将核心数据通过标准接口暴露出来，确保模型调用的是准确、可信的输入，这样才能建立起查数场景的稳定性与可控性。

凌霄：Chat BI 场景天然涉及对结构化数据的精确查询，因此对数据的准备要求非常高。首先，在将自然语言转化为结构化表达这一过程中，货拉拉采用了 DSL 作为中间层，以避免直接生成 SQL 所带来的准确率问题。为了训练模型准确生成 DSL，我们在数据准备阶段就进行了大量前置工作，特别是在问题类型的分类上做了精细拆分。例如，一个用户提出的“今天单量是多少”看似简单，但背后可能涉及简单查询、聚合、排序、同比 / 环比等多种模式。我们将这类问题细分为十几个类型，针对每一类都准备了对应的数据样本，以确保模型能够区分不同的意图和逻辑结构。

在训练数据构建方面，我们分为训练集、验证集和测评集三类。其中，训练集包含大约三十万条自然语言到 DSL 的转换样本；验证集用于每轮微调后的效果确认；测评集则检验模型生成结果是否符合预期标准。高质量的数据结构和合理划分，是模型调优效果的保障。此外，与一些拥有大量客服或外呼数据的场景不同，Chat BI 缺乏天然的检索链路，因此 RAG 数据的获取和更新也更为困难，是否采用需要结合企业自身的资源和需求来决定。

除了模型本身的数据准备，另一个更大的挑战来自底层数据体系的不一致。企业内部通常存在多套并行的数据体系，例如指标体系、埋点体系、AB 实验体系、订单体系等，它们多是为满足历史业务需求而建立，各自独立、缺乏标准化。这种分散结构导致 AI 系统在查询数据时经常“踩雷”。我们曾遇到一个真实案例，一位高管询问某小众指标在各业务线的昨日订单量。这本是一个常规聚合问题，但结果却遗漏了几个业务线。原因是 BI 数据体系中，出于管理层之前的要求，那几条实验性业务线的数据被单独存放在次表中，未纳入主报表，导致模型查询结果出现偏差。

这种问题的本质在于，AI 模型在执行任务时依赖于数据的一致性和可解释性，但现实中的数据往往如同“冰箱里被分门别类藏匿的肉”，不仅分布零散，还按不统一的逻辑命名。最终模型要正确查询数据，就必须首先理解企业内部复杂的数据建模和现有结构，这显然是极高的门槛。在 Chat BI 落地过程中，既要关注模型训练的科学性，也必须重视底层数据是否适配 AI 应用需求，否则再好的模型也无法交付可信的结果。

企业里怎么用好“数据智能”？

郭峰：DeepResearch 这个框架在企业里实践下来，哪些点让你觉得它真的跟上一代 RAG 不一样了？

覃睿： 传统的 RAG 模式在应对指向明确的问题时效果很好，比如询问某项公司报销制度的具体规定，只要能在知识库中定位到相关段落，可快速准确作答。但在面向更复杂的“research 型问题”时，这种简单的 RAG 框架就会显得力不从心。所谓的 research 型问题，往往没有一个可以直接检索得到的标准答案，它需要模型具备规划、拆解问题的能力，并且在多轮调用内部或外部知识库后，甚至还要结合实际工具的操作结果，才能完成整个问题求解流程。

回顾 2023 年初 auto-GPT 项目的诞生，其实那时整个行业已经开始畅想 AI 在复杂任务处理中的巨大潜力。只不过彼时模型的推理能力尚不成熟，实际执行效果远不如预期。如今，这项能力之所以重新受到重视并开始真正落地，核心原因在于基础大模型自身能力的飞跃：一方面是推理深度的显著增强，另一方面是模型对长上下文的处理能力也有了实质性提升。尤其是上下文支持，并非简单地通过工程手段塞进更多 token，而是模型真正能够“记住”长文档内容，并在推理过程中加以利用。这背后当然也离不开新的算法优化与更强算力的支撑。

因此，从能力框架上看，Deep Research 不仅是传统 RAG 的扩展，它代表着大模型应用从检索辅助走向多阶段、可规划推理的质变。这类能力将极大拓展 AI 的可用场景，也是我们目前最关注的未来方向之一。

郭峰：“控幻觉”非常关键，能不能讲讲你们是怎么在框架里平衡“效果”与“成本”的？

覃睿：“幻觉”是当前技术架构下无法彻底消除的问题。我们越把模型看作一个智能体，它就越像人——而人也不可能做到 100% 准确。所以，首要前提是接受幻觉不可避免，只能尽量降低其出现频率。对于一些要求高准确率的场景，我们的思路是通过更好的用户交互机制帮助用户进行验证。在不同垂直领域中，这类交互方式也会有差异化的设计和优化手段。

另一个角度是在企业中选取应用场景时，要根据幻觉的容忍度来做权衡。如果不想一开始就做得太复杂，也不具备投入人力进行高强度核验的条件，那么就应优先选择容错率高的场景。例如，我们公司部分对开源社区用户问题的支持中会使用，很多问题其实文档里已有答案，我们希望能通过一个基础的机器人来提升效率。即便机器人偶尔答错，这类用户的期望也不会太高，整体风险可控。

此外，对于效果和成本之间的平衡问题。我们认为当前阶段最关键的是先把效果提上来。只有当效果达到一定水平，真正解锁业务价值，供不应求之后才有必要去考虑优化成本。

DeepResearch 能力的另一个重要意义，不一定在于大幅提升最终效果，而是在于显著降低构建门槛和实施成本。当前企业内部最大的挑战是技术和业务之间的协作鸿沟——很多系统建设由科技部门主导，业务部门参与度有限。如果借助 Deep Research 框架，业务人员仅通过自然语言交互，就能实现“七八十分”的原型效果，看到“有用”的价值，他们自然会更愿意主动参与。

尤其对于一些对技术接受度较高的业务人员来说，这类体验非常关键。很多日常的长尾、零散、轻分析类需求并未被传统 IT 系统很好覆盖，例如让 AI 协助处理表格、优化文档等。这些需求虽小，却具有强烈的用户价值感知，是 DeepResearch 的天然落点。

从公司定位来看，我们并不强调微调。外界常谈的强化学习或领域微调，要求构建明确的业务反馈机制，形成训练闭环，这在企业内部是非常难落地的。大多数业务反馈并不像代码和数学那样具备清晰的正确性标准，环境模糊，无法满足 RL 的基础条件。

因此，我们在 DeepResearch 框架中更强调基于 SOP 的能力演进。在用户使用过程中，后台通过收集和分析用户行为，不断积累 SOP 并进行优化。这种方式不依赖微调或大规模数据标注，成本低、过程自然，也更适合企业真实环境。最近清华等机构也发布了相关研究，说明这种轻量优化路径在业内正逐渐被验证。

郭峰：货拉拉的业务场景非常典型，从你的角度看，数据在支撑企业智能场景时，最缺的是什么？

凌霄： 以货拉拉为例，我们这边比较认可和常用的一种方式，就是以数据智能的场景为核心，通过“场景驱动”的方式反向推导解决方案。通俗地说，就是现在数据智能能做的事情有很多，比如代码生成、报表生成、自然语言查询数据、甚至修改现有数据链路上的任务。但真正的问题在于：你们企业当前到底需要什么？这才是需要认真思考的。也就是说，不能只是从技术出发看“我能做什么”，而是要从场景出发看“我该做什么”。

在我们的内部方法论中，数据智能团队必须心中有“杆秤”——我们用一个类似“智能数据实体四象限”的模型来辅助判断。这个模型的 X 轴 是“大数据管理的数据体系”，也就是数据标准化程度。这个轴越往右，代表数据标准化越高，意味着它的解决方案就越多、可行性越高。Y 轴，代表“是否是指标数据”。这个维度主要是判断场景是否对数据准确性要求很高。比如如果是涉及经营分析的指标数据，那肯定就要求非常高的准确性。但如果不是，比如说只是 SQL 生成类的场景，就没必要上复杂的微调模型。

我们会基于这个四象限的分类方式，在不同象限里为不同场景制定相对“半流程化”的 SOP，不同的数据使用不同的实现方式这个 sense 很重要，这不仅适用于 Chat BI 类场景，也可以推广到更多的智能业务中。

观众：什么是高质量数据？如何获得？

单海军： 高质量数据可以从两个维度理解。首先是单个样本层面，高质量样本通常信息量更大，对模型训练更有帮助，尤其是“难例”样本——即模型处理难度高、提升效果明显的样本，这类数据价值更高。这类样本通常通过训练评测中的效果提升来判断。

另一个维度是整体数据集的质量，比如在领域微调中，我们会用几千到几万条的 SFT 数据集。评估时，首先看任务覆盖是否全面，比如问答、写作、对话、推理、计算等都需涵盖，而且各类数据分布应均衡，避免某类比例过高影响效果。

其次要看响应准确性，事实错误率应低于 1%，逻辑矛盾也要尽量减少，这通常需通过人工或交叉审核保障。最后是指令的泛化能力。同一个问题，用户可能会用多种方式表达，因此训练数据也应涵盖多种提问方式，提升模型稳定性和泛化能力。这些是我们判断高质量数据的核心标准。

覃睿： 从应用角度看，关键在于数据是否贴近真实业务。很多开源数据集与企业需求差距大，比如有的多步推理数据集中，问 2013 年某某奖电影男主角的老婆在 15 年演了什么电影。这类问题距实际应用非常远，只是为了方便评测，根据答案反推出来构造的问题。

另一个重点是结构清晰度。比如一个有章节的文档显然比无结构文档更好，数据库也是一样，治理良好、服务于 BI 的数据库，数据质量自然高于原始数据。总体而言，结构清晰、治理规范的数据，才是真正优质的应用数据。

观众：某一业务指标如何与具体数据关联起来？

凌霄： 这个问题目前大概有四种解决方案。第一种是通过自然语言将用户的提问映射到 DSL。在这种方式中，模型先识别出具体的指标名，再结合 DSL 和数据系统，将查询指向具体的底层数据表。这种“半站源、半工程”的路径现在用得非常多，因为它可以最大程度减少映射错误，避免模型把指标关联到错误的数据源上。

第二种方式是直接从自然语言生成 SQL 查询，也就是 NL 2SQL。这条路径的挑战在于模型的精调必须非常精准，同时还需要控制数据实体的复杂度。比如一个简单的指标“GMV”，在不同业务线可能分布在多个不同表中，如果模型出现幻觉，很容易查询到错误数据，因此这条路径的风险相对较高。

第三种是近年兴起的 agent 路线。它将查询动作分配到不同的 agent 上，由大模型根据指标选择对应的 agent，再由该 agent 生成 SQL 或 DSL，通过 API 查询到相应的物理表。这种方法的优点是灵活性高，支持跨异构数据源查询，基本上能对每个问题都给出回应。但它对路由模型和 agent 实现的精度要求很高，整体实现较为复杂，属于前沿探索。

第四种是更直接的“大 token”方法，也被戏称为“大力出奇迹”路线。比如使用 DeepSeek-R1、Qwen3 等支持超长上下文的大模型，直接把几千行结构化数据作为输入，再提问模型。这种方式在我们内部也做过 POC，确实能得到一定准确的结果，但推理速度极慢，容易超时，而且对模型算力和 token 容量要求极高，适用于特定场景但不具备通用性。

数据智能在业务侧的真实挑战

郭峰：ChatBI 这类工具，在业务一线真正被用起来的最大挑战是什么？

凌霄： 当前 AI 产品已经过了初期探索阶段，接下来更大的挑战是如何真正落地到有实际业务价值的场景中。以数据分析为例，查询数据只是第一步，真正有价值的是生成报表、完成数据任务、或将数据分发出去服务实际业务。这就需要 AI 系统能与现有报表平台、线上业务系统打通，支持报表生成或数据投递，而这涉及到模型如何与现有工程系统交互。当前这一“AI 服务协议”层，如 MCP、A2A 等，还处于探索阶段，尚无成熟统一的解决方案。

另一类场景是提效领域，我们尝试通过 agent 实现一些重复性或人工成本高的任务。尽管 POC 阶段可以由产品或运营团队主导，但要真正落地，还需业务用户如运营、BI 或分析师自己去维护 agent 逻辑，包括低代码规则或判断逻辑。但现实是，无论平台设计多简洁，用户仍然觉得学习成本高，推广起来非常困难。

还有一个挑战是，很多成功的 AI 落地实践都要求 AI 系统与业务共担 KPI，即 AI 产品必须在业务指标上达到与现有系统相同甚至更高的水平。然而，当前大模型的幻觉是普遍存在的，难以彻底避免。如果不共担 KPI，AI 很难真正嵌入核心业务；但要共担，就必须投入大量精力去降低误差，这对所有团队都是巨大挑战。

郭峰：Agent + Workflow 的结合是否是你们目前看到的方向？未来会不会反过来推动业务流程标准化？

凌霄： 在 Chat BI 这个领域，未来一定是 “Agent + Workflow”的模式。比如：用户看到数据后，通常会产生“为什么有变动”这类疑问，也就是所谓的数据归因。很多云产品或开源方案都在解决这个问题，但真正可解释、可维护、有科学性的方案，基本都是基于 Agent 和 Workflow 构建的。

归因这件事，本质是一个有步骤、有逻辑的过程。比如货拉拉内部归因流程：业务会定义一个通用逻辑，先看城市维度，再看关联因子，如 GMV 对应的用户下单、司机接单等，然后基于贡献度、阈值、同比环比得出结论。这就像评判湖南菜辣椒炒肉好不好吃，第一步看有没有辣椒和肉，再看原材料是否正宗，然后是烹饪顺序、佐料是否得当。这个比喻说明归因逻辑必须清晰、系统化，大模型或传统机器学习很难直接处理，因为它们难以提供可解释性的确定性判断。

而 Workflow 的价值在于，它既能固定这些复杂逻辑，又具备灵活性，能作为触发器连接大模型或其他工程逻辑。所以我们认为，在这类场景中，“Agent + Workflow” 是唯一能兼顾科学性、可解释性与可维护性的路径，而且这种架构和大模型结合的边际成本也低。

至于这个机制是否能反过来推动业务流程的标准化，我认为肯定可以。比如我们在多数据源接入时，会通过 Agent 自动完成源数据探查、模型路由注册、配置改动等。这些原子化 Agent 可复用于工单系统中的数据查找、答疑等场景，从而逐步推动业务 SOP 流程的规范化和自动化。

覃睿： 企业真正的利润来自于标准化和可规模化，而不是天天创新——创新意味着持续的验证和成本投入。企业要做的是把事情流程化，也就是 Workflow。不论是核心业务，还是辅助业务，比如各种报告，其实本质上都是标准流程、规范操作。大模型的角色应该像水一样，流向它真正能发挥作用的地方，而不是硬性地作为一个“主体”插入到流程中，让其他人去围着它转。正确的方式是以业务流程为主，大模型嵌入其中，找到自己的价值点。

数据智能落地的本质挑战

郭峰：你们认为“数据智能”更像一次技术升级，还是组织流程的重塑？能否结合落地场景的真实经验来分享下你们的看法？

单海军： 首先，这轮是一次明显的技术升级，从数据到智能，过去几年其实一直在围绕数据和智能不断演进，包括架构和算法的升级。技术升级背后，企业组织流程其实也在发生深刻变化。

第一，企业的组织模式正在从“以业务流程为中心”转向“以数据流为中心”。以前像制造业，组织结构是围绕原料、生产、销售这些环节来设定的。但现在，在数字时代，企业越来越以信息的获取、加工与辅助决策为核心，组织架构也慢慢往这个方向走。

第二，数据赋能业务，尤其是制造、研发、营销等环节，越来越依赖跨部门的协同与融合，特别是业务和技术之间的界限在逐渐消融。比如说，我们要做智能决策，第一步得有数据，那哪些业务数据能用、怎么用？这些问题其实只有业务方能梳理清楚。而模型怎么训练、技术怎么落地，这又是技术团队的任务。

所以，未来真正有效的组织架构，可能是一种业务与技术深度融合、扁平化、能快速协同的模式，只有这样，企业才能更好地利用这些数字化工具和智能化手段来推动转型升级。

覃睿： 从我们目前落地的项目来看，真正成功的案例里，大模型的技术占比其实并不高，可能只有 30% 左右。更多的价值，其实是来自于数据的打通，以及业务部门的协同，把一些原来“想做但做不了”的事给做成了。这里我觉得有个很有意思的变化：过去是 CIO 在推动数字化，现在是 CEO 在推动智能化和大模型。以前 CIO 推不动的项目，现在 CEO 亲自上阵，推得动了。

当然，大模型技术是一种创新，是新的生产力，但它并没有像移动互联网那样带来立竿见影、爆炸式的变革。比如移动互联网在 4G、5G 到位后，很多新业态迅速爆发，但智能化不太一样，它的提升不完全靠技术堆砌，有时候“智能”这件事本身还有点玄学，智能增长的速度和曲线也不太可控。所以我们不确定这条技术曲线是否还会像过去两三年一样高速增长。

从当前阶段来看，组织层面的打通与协同，可能反而带来了更显著的价值。当然，从长远来看，如果技术持续进步，最终“智能”的成本趋近于 0，让智能广泛存在，这将带来更深层次的颠覆性变革。

凌霄： 目前大模型能力更多是一场技术升级，是改革而非革命。所谓革命，是彻底推翻原有体系，但 AI 现在还没达到这个程度。比如服务协议框架、业务接入、数据准备等细节仍存在很大挑战。

我们跟多个团队交流也发现，目前很难把所有原有业务和数据完全承接到 AI 系统里，但过去两年大模型及基础设施有明显进步。大家焦虑是正常，但应相信模型会持续进步，基础框架和基础设施也会逐步完善。同时，要控制用户预期，目前 AI 产品还达不到像“人”一样多面能力。总结来说，战略上应保持积极乐观，看到未来发展潜力；战术上则需保持一定悲观，做好边界管理。