一、背景与愿景

以飞猪为例，生活服务类应用的 C 端的业务质量保障，往往面临业务快速迭代、技术架构复杂，多端场景覆盖难等多重挑战：

• 业务层面：受旅行行业“七节两促”特性的影响，在高频营销活动驱动下，往往伴随着较为快速的发布节奏；如何在快节奏中构建稳定的 C 端质量保障体系，与安全生产能力成为关键问题。

• 技术层面：C 端系统采用 Native、Flutter、Weex、DX、H5 等多技术栈混合架构；同时，测试回归需覆盖飞猪 App、手淘飞猪 Tab，及淘、支、微、红等多平台小程序入口，这导致测试回归复杂度指数级上升；此外，功能回归与用户体验提升需协同产研推进，进一步加剧了发布小窗口期下的质量保障难度。

UI 自动化作为 C 端质量保障的切口之一，而 AI 能够在现有场景下，为自动化赋予新的机遇，解决业界 UI 自动化的普遍挑战与共性问题：

• 用例维护成本高：业务快速变更导致失效率持续攀升，人工投入占比过大；

• 断言有效性不足：多端入口交互逻辑差异使覆盖不全，问题漏检风险存在；

• 多端兼容性问题突出：多端差异和逻辑定制，易引发测试盲区，易触发线上故障；

针对这些痛点，我们计划通过 AI 技术，结合并优化现有自动化测试体系：降低用例腐化率以减少人工成本，提升断言精准度以增强问题发现能力，从而在保障质量的同时提效。

图 1：飞猪多端 - 流量入口示意图

二、挑战

在“AI + X”的落地实践中，应用的技术演进大多遵循一条较为清晰的技术路径：从基础提示工程（Prompt Engineering）起步，到检索增强生成（RAG）、记忆体（Mem）、智能体技能（Agent Skills）和多智能体系统（Multi-agent Systems / Sub-agents），最终监督微调（SFT）、GPO/GRPO 等模型层的策略优化方法。

然而当时，我们在技术调研时发现，AI 自动化领域在当时深入借鉴的参考标杆偏少。在开源技术论坛中的技术分享，大多数文章仍聚焦于 0-1 阶段的试用与调研，缺乏对成熟技术路径的规模化应用验证。同时，外部的开源范例（如：阿里 Mobile-agent、微软 playwright-mcp、字节 midscene.js）也都是更聚焦模型 / 框架层面的基础能力建设，而缺少整体的能力串联、使用效果、演进路线上的实践范式。

如何将 “凭借 AI 可以快速入门的能用” 变成 “可支持月均 10 万 + 构建，稳定、快速运行的好用、易用” 是我们在这个技术演进路线上的最大挑战。

三、策略与思路

3.1、做好评测体系的先行建设，用数据指引应用迭代效果

核心原则：在 AI 自动化开发启动阶段，即需要同步建立与目标对齐的效果评测体系，将效果验证从“事后补救”前置为“设计输入”，确保技术演进始终服务于质量保障目标，避免因缺乏量化依据导致的无效迭代。

行业验证与内部实践依据：

• Gartner AI 的研究报告指出，73% 的 AI+X 项目因评测体系缺失而无法规模化落地，表现为技术优化与业务效果脱节。

• AI 自动化的前期探索中，常见的技术挑战，往往会遇到的典型问题：

  提示工程（PE）优化后：执行效果异常，AI 幻觉问题频发，导致 PE 紧急回滚；

  RAG 知识库迭代后，关键业务数据召回率显著下降；

  模型切换后：本地调试结果与线上实际效果存在偏差，导致整体效果质量下滑，case 失败率增高。

实施要点：

我们从应用 workflow Benchmark 评测集建设、“渐进式消融评测机制”：基座模型 →  Prompt → RAG → Agent 分阶段验证效果等方式作为评测体系的基准，每次技术调整（提示工程优化、知识库更新、模型切换）均需通过真实业务数据验证端到端效果，结合自动化测试数据与人工路径验证，确保评测结果反映真实用户体验。

价值体现：先行评测体系为 AI+X 实践提供客观决策依据，有效规避“技术优化但业务效果下降”的风险。为实现从“能用”到“可靠规模化”的关键跨越提供了数据支撑。

3.2、通过工作流设计，避免模型流程死循环（break cycle），提升故障恢复与自检能力

核心原则：在 AI 工作流设计中嵌入防死循环机制与故障恢复路径，确保系统在异常情况下能主动退出无效循环、回退至安全状态，而非陷入无限尝试。聚焦业务连续性保障，避免因局部故障导致整体流程失效。

问题依据与内部实践痛点：

• 行业共性问题：多智能体系统普遍存在流程死循环风险（如 Cursor 等工具中模型反复执行相同操作），在 AI 自动化场景中尤为突出。例如，当用户未填写必选 SKU 时，系统通常触发 toast 提示，但 AI 在截图 / 操作过程中可能无法捕获此类信息，导致模型陷入“尝试 - 失败 - 重试”的无限循环。

• 动态死循环检测机制：

• 基于 History 和 Memory 设计算法，实时分析操作序列相似度（如连续 3 次相同点击指令，及相似参数返回，即触发预警）；

• 设定阈值规则：当操作重复率≥60% 或单节点耗时超时，自动判定进入死循环。

• 分层恢复路径设计：

  一级自检：轻量级模型（如 Qwen3-VL-7B）快速扫描历史操作，通过 ReAct 逻辑判断根本原因（例：识别“未捕获 toast”后触发跳过指令）；

  二级升级：对复杂循环（如多端交互差异），临时调用高参数模型（qwen3-vl-235b-a22b-thinking）进行深度推理，结合 RAG 补充行业知识库（如“下单页 SKU 选择死循环通用处理方案”）检测到连续 N 次无效点击，workflow 自动调用 RAG 获取“必填项缺失”处理方案；；

  安全回退：强制回退至最近稳定检查点（如“度假搜索 Listing 页”），避免全流程重启。

价值体现：工作流设计的本质是赋予 AI 系统“自省能力”——通过防死循环机制与分层恢复策略，将故障转化为可自动修复的常规操作，使技术演进真正服务于业务稳定性目标。

3.3、通过 RAG、记忆体与子智能体补充业务垂类知识，保障高 UV 页面路径的精准覆盖

核心原则：将业务垂类知识深度嵌入 AI 工作流，确保模型理解真实用户行为路径与行业术语逻辑，使测试覆盖严格对齐核心业务流目标，避免因知识缺失导致的路径偏差与漏检风险。

问题依据与内部实践痛点：

• 用户路径覆盖失准：模型对业务高频路径的理解存在偏差。例如，当指令为“订北京中关村附近，500 元预算，下个月 1 号大床房”时，实际用户 90% 通过“酒店金刚”或“猪搜”入口操作，但自动化测试常误判至其他资源位（如活动页），导致核心 UV 页面链路覆盖准确率不足，无法有效验证真实用户高频场景。

• 行业术语理解缺失：模型对垂类术语（如“交通 OD”指交通出行数据、“OTA 页面”指在线旅游平台）存在歧义，引发测试用例生成逻辑错误。例如，在航班测试中，“OD”被误识别为“订单”，导致关键流程验证失效。

实施策略：

• RAG 业务知识库定制：

  构建飞猪专属知识库，整合用户行为热力图（如酒店金刚点击路径）、行业术语词典（如“OD=Origin-Destination”），在 Prompt 生成前动态注入上下文。

  例如，当检测到“订酒店”指令，且无其他特殊要求时，RAG 自动匹配“酒店金刚”作为首选入口，确保测试路径与真实用户行为一致。

• 记忆体（Mem）动态优化：

  设计短期记忆模块，实时记录用户历史操作特征（如连续 3 次从“搜索模块”进入酒店列表），在决策时应该优先调用高频路径逻辑。

  针对大促营销活动期，记忆体自动识别新增入口（如“双 11 特惠”标签），动态调整测试优先级。

• 子智能体（sub-Agent）分工协同：

  路由 Agent：专责解析指令并匹配高频用户路径（如识别“订酒店”自动路由至酒店金刚）；

  术语 Agent：实时校正行业黑话（如将“交通 OD”映射为交通数据模块），确保测试逻辑无歧义；

  验证 Agent：在关键节点（如支付前）交叉校验路径是否覆盖核心 UV 页面，触发偏差预警。

价值体现：业务垂类知识是 AI 自动化测试的“导航仪”——通过 RAG、记忆体与子智能体的协同设计，将抽象指令转化为精准的业务路径验证，确保技术服务于核心用户场景的质量保障目标。

3.4、持续跟进前沿技术，动态演进应用能力，优化整体链路效果

核心原则：将技术演进，视为应用体系的有机组成部分，通过持续跟踪 AI 能力边界拓展与生态创新，实现测试链路与业务复杂度的动态适配，避免技术滞后成为效果瓶颈。

问题依据与内部实践痛点：

AI 技术的演化迭代速度日新月异，在 AI 自动化的基座模型下，我们从最初 gpt3.5 只能写文字、到 gpt4 可以多模态传图片，到 qwen-vl-max-latest 能够在点击、滑动时，精准给到像素级别的操作 的 pixel point，都表明了技术能力的演进速度，已经远远超越我们去思考如何 fix issue 的迭代速度了。

通过建立与 AI 技术发展同频的升级机制，技术底座持续吸收 AI 的开源演化成果，并高效整合开源生态创新，使测试体系始终具备精准匹配业务迭代的适应性。

3.5、拓展 AI 泛化检查能力，加强视觉智能感知与断言，降低漏测概率

核心原则：突破操作意图识别的局限，将 AI 能力延伸至对视觉界面的动态理解与泛化校验，使测试体系从“执行动作”转向“结果验证”，确保系统能自主感知 UI 状态变化并判断业务逻辑一致性。

问题依据与内部实践痛点：现有测试过度依赖操作指令解析与“编码形式的断言”，难以应对多端 UI 差异场景下的隐性问题。例如，小程序中优惠券弹窗样式，可能只断言了弹出是否弹出，或者弹窗文案是否正常展示，但是如果弹窗局部出现了空坑，或者渲染异常，通过 “编码形式的传统断言” 是无法及时感知与相应的，如此就产生了漏测的可能。

而 AI 本身的图片解析与研判能力，就可以很好的处理这些问题，即可以判断单张图片上的泛化异常问题，也可以在多张图片的链路上，去分析判断一致性等相关问题。又或者结合实事、工单、可诉等相关外部数据，给出非逻辑 BUG 的风险提醒。

价值体现：AI 泛化检查是质量保障的“视觉神经”——让测试能力从机械执行转向智能感知，确保技术演进始终服务于用户体验的核心目标。

四、效果展示

从几个橱窗场景，进行 AI 智能化效果展示。

4.1、对于异常弹窗的静默处理

4.2、对于异形元素（无文字）的像素级坐标感知

4.3、对于连续逻辑的动态自检与判断能力

4.4 对于循环操作的短期记忆

4.5 对于死循环场景的脱困能力

4.6 对于截图的泛化检查能

五、思考总结

AI 技术的深度引入，有效解决了 C 端 UI 自动化质量保障体系普遍存在的通用问题，推动测试能力实现较大的提升：

1. 用例维护成本显著降低通过 AI 语义化改造，系统能够动态理解业务变更逻辑（如营销活动入口调整），自动适配用例，大幅减少因业务快速迭代导致的人工维护投入，使团队精力从重复性调整转向测试策略优化。

2. 测试覆盖深度切实提升泛化检查能力突破了传统编码断言的局限，使验证从操作指令延伸至结果状态。系统可自主识别多端 UI 差异中的隐性问题（如弹窗渲染异常、元素空坑等），有效弥补了人工难以覆盖的视觉类风险盲区。

3. 多端兼容性问题系统性改善基于 RAG、记忆体与子智能体的协同设计，AI 深度融入业务垂类逻辑（如高频用户路径、行业术语校正），确保测试流严格对齐真实用户行为，显著降低了因端侧差异引发的漏检风险。

本质价值：AI 不是简单替代人工，而是将测试工程师从机械执行中解放，使其聚焦于质量策略设计与业务风险预判。当系统能自主完成弹窗处理、像素级操作及死循环脱困时，质量保障真正实现了从“执行工具”到“智能伙伴”的转变——技术价值的体现，在于让专业能力更高效地服务于用户体验本质。

在大模型算法快速迭代演进的背景下，业务研发人员负责工程、算法研究人员负责模型优化的协作模式，已经无法满足大模型产品快速创新、模型效果快速迭代的业务需求，业务团队需要建设自有的大模型优化能力。如何建设一个人人都能训大模型的技术氛围，已成为加速大模型业务落地、推动组织创新与发展的关键。

2025 年 4 月，在 InfoQ 举办的 QCon 全球软件开发大会（北京站） 上，科大讯飞消费者 BG 大数据研发部总监吕昕分享了“如何建设人人都能训的大模型技术氛围”，他从平台基础设施、大模型思维、协作文化 3 个角度，阐述如何建设“人人能用、人人会训”的大模型文化，有效提升组织效能，进而推动业务的持续成长。

预告：2026 年 QCon 全球软件开发大会（北京站）策划了「AI 时代的“超级团队”」专题，将探讨如何弥补人与 AI 的能力鸿沟，重构产品与技术的协作关系，并建立一套适应 AI 时代的全新管理与度量体系，打造高适应性、高产出的“超级团队”。如果你也有相关方向案例想要分享，欢迎提交。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

大模型时代组织创新的必要性

大模型时代创新的必要性在于，无论是 C 端还是 B 端业务，直接使用大模型完成工作都存在困难，需要进行优化。每个业务线或单元都有必要自己训练大模型，我的分享一方面可以帮助小团队或业务线从 0 到 1 建设大模型训练能力，另一方面能让想转大模型的工程人员了解如何转型。

大模型算法优化的几种模式

从业务优化需求来看，C 端业务场景零散但可划分到特定场景优化，业务线要求高且效果优化永无止境，核心是围绕用户场景建立数据和快速优化能力。B 端业务以解决方案为主，对效果要求相对有限，主要是满足国产化和安全要求，达到可用即可。

大模型优化模式与传统机器学习有所不同。传统机器学习中，算法需求由算法研究人员或团队主导，业务线研发主要负责部署上线和维护。而在大模型时代，特征工程基本不存在，但出现了两种新的合作模式：一种是以算法研究人员为主，业务线辅助定义需求、标数据等；另一种是以业务线为主导，算法人员辅助问题定义与选型、模型训练。DeepSeek 等技术的出现，使得业务线或产品线有可能自己优化大模型训练效果，不再依赖算法辅助。

大模型吋代的 BLM 模型

从组织架构角度，各个业务线更希望业务线自己训练大模型。因为大模型技术发展迅速，战略需灵活调整，组织活力需进一步激活，以实现敏捷创新和更好的信息拉齐与穿透。传统的算法团队与工程团队分开的模式已不能满足业务发展需要，每个业务线或团队都需要具备从 0 到 1、端到端优化大模型的能力。

在大模型时代，DeepSeek 的出现既带来了危机也带来了机遇。它在基础模型方面表现出色，一些场景直接使用深度探索就能取得不错的效果。同时，开源生态的成熟，包括训练框架、推理框架和智能代理框架，降低了训练基础设施的建设成本。通过蒸馏深度探索，可以快速构建高质量数据，如思维链数据，节省了大量人工标注成本。此外，模型优化范式也在变革，从之前的底座模型训练和监督微调（SFT），转变为现在的知识蒸馏，并且广泛采用 GRPO 来优化效果。

从 0 到 1 自建大模型优化能力面临的问题

业务线如果想自己从 0 到 1 建设大模型的优化能力，会面临诸多挑战。首先是基础设施的缺失，包括算法、算力、平台、数据，以及训练框架和推理框架。其次是缺乏算法优化经验，不清楚如何选择模型、技术方案，如何评估和优化效果。最后是人才短缺，不清楚需要什么样的人才、到哪里找以及需要掌握哪些技术栈。

大模型效果优化团队的协作与流程

在大模型时代，对研发岗位的要求也发生了变化。核心岗位包括大模型算法工程师和大模型测试工程师。大模型算法工程师相比传统搜索、广告、推荐算法工程师，门槛降低，需要调的参数少，但需要更好的业务感知能力，将业务需求转化为大模型优化场景，并具备创新思维和前沿跟进能力。大模型测试工程师相比传统测试工程师，需要更高的自动化测试要求，能够基于业务感知能力自动化构建大模型测试样本和制定测试标准。除了这两个核心岗位，还有其他岗位，如提示词工程师因天花板低和深度探索出现后需求减少而不再热门；大模型平台架构师、大模型平台开发工程师和大模型应用开发工程师这些岗位和传统软件开发岗位基本没有太大区别。

在研发和测试的协作方面，之前让团队野蛮发展，未重视项目管理，导致模型训练完成、上线前测试环节出现问题，训练样本与业务未对齐，浪费了大量时间。因此，我增加了样本评估环节，要求在训练前与业务线对齐样本，确保样本能满足业务需求。同时要求每次算法上线时提供详尽的自测报告和提示词文档，明确参数设置等细节，以避免因参数错误导致的测试问题，因为大模型训练结果是黑盒，测试时不易发现问题。

建设人人能训大模型的基础设施

大模型优化平台的建设

基于我对整个平台架构设计的理解，基本分为三层。最底层是基础设施，公有云可以解决 90%，甚至 100% 的问题。因为业务线的训练样本数和情况一般不支持训练 32B 以上的模型，32B 的全参训练是上限。此时租用几十张显卡基本能解决大部分训练问题，大部分业务场景 7B 模型也能搞定。所以公有云租卡基本能解决 90% 的训练和部署问题。在训练的第二层是训练工具。这里使用了公司内部已有的星火训练平台，同时也基于开源搭建了相关工具，开源生态的成熟对此帮助很大。再往上是大模型应用开发的三个工程：数据工程、模型工程和 Agent 工程，也可称为大模型的应用开发。核心需要自己扩建设的资源主要是数据资源和应用开发资源。数据资源方面，要掌握如何通过调用 API 构建样本，如何蒸馏 Deepseek，公有云的 API 基本能满足需求。应用开发方面，主要涉及 Agent 和 RAG。Agent 的开源项目众多，star 超过 1000 的都有 50 个左右，可以基于开源搭建自己的 Agent 和 RAG 平台。如果想低成本建设从 0 到 1 的基础设施，利用公司内部资源复用和拥抱开源，基本能解决所有问题。

开源模型的技术选型

有了基础设施后，简单介绍一下开源技术栈。之前没显卡时还考虑过 Qlora，但后来发现 32B 模型的 Lora 训练，16 张显卡基本都能搞定，没必要再用 Qlora。在模型选型上，简单模型用 7B、14B、32B 基本都能满足，复杂一点的长文本和复杂任务，32B 模型也能差不多应对。使用开源模型进行部署和训练基本没什么太大问题。

数据管理平台

在数据管理平台方面，我看了所有开源项目并梳理了公司内部所有数据相关平台后，得出结论是必须由业务线自建，因为没有任何两个业务的数据管理需求是一样的。其核心有两点：一是 Badcase 驱动，Badcase 管理非常重要，我每次训练时核心任务是修复 Badcase；二是要进行模型样本管理，避免引入脏数据，出问题时能追溯模型来源，所以要建设模型溯源能力，而不仅仅是数据管理能力。

培养全员大模型思维与能力

如何培养全员训练大模型的思维和能力，重点在于提升能力，尤其是让普通研发人员快速掌握大模型训练，建设他们的算法能力。大模型训练流程包括问题定义、提示词设计、样本构建、微调（蒸馏、强化学习）、评估和上线。模型优化能力由四个能力叠加而成：模型问题定义能力、样本构建能力、训练能力和评测能力。最初认为模型训练能力最难，但实际上最容易，一周内所有人都能学会调参，且调参不超过 3 个。研发团队最需要提升的是问题定义和评测能力。

大模型的应用场景和优化方式

我将自己最近半年工作中的教训和经验总结，把所有训练过的大模型场景做了拆分，发现大部分大模型场景都能映射到下表几个类别中。每次模型训练时，思考一下可以放到哪个类别，然后按照相应的优化方式去做，基本都能取得不错的效果。以写作类为例，这是最常用的大模型优化场景，现在 DeepSeek 效果较好，大家开始广泛使用。以前不敢碰写作类，因为需要构建样本，难度较大。但现在通过 DeepSeek 蒸馏和强化学习（GRPO），基本能取得较好的效果。要素抽取类场景中，公有云模型准确率能达到 90%，自身优化空间不大。问答类场景中，大模型能力很少单独训练，大家主要做 RAG 和搜索插件，因为底层工程化可以提升更多效果。还有 API 调用类场景，训练大模型时将其抽象到某个场景，再看每个场景的优化方式。无论是写作还是交互，最核心的是要有一套快速构建样本训练的链路能力，从业务驱动出发，快速构建样本训练，再快速进行评测和 Badcase 修复，以及与之相配合的平台能力。

大模型测试

大模型测试曾是我最不关心的环节，但后来发现它对模型优化迭代效率影响最大。首先，数据来源很重要。如果线上有 Badcase，建议直接使用 Badcase 作为优化数据。性能测试方面，大模型性能测试与普通性能测试存在差距，可能会考虑 GPU 并发等因素。但我认为，同样 Token 长度和 Size 模型性能差异不大，不要投入过多精力。最核心的是找一个测过的开源的数据源，拿来即用。效果测试很关键，就是理解模型效果并进行测试。我的感受是，合作的业务线中，是否有优秀的测试人员对最终模型效果影响很大。优秀的测试人员可以从业务需求出发，将业务标准和测试标准转化为测试用例，自动化生成样例，并用大模型自动评测。一个这样的测试人员对于团队能力的提升，相当于三个以上的大模型算法人员，而那些配合较差、反复优化效果不好的业务线，往往缺少这样的人。因此，我在公司内进行大模型测试能力评估，尽管自己做算法工作，但感觉没有优秀的测试人员，工作开展会很困难。

大模型优化案例 1 一多轮改写

我最早做搜索时，用户输入多轮搜索结果，需要多轮改写来理解用户意图。之前使用传统方法和一些大模型，都无法很好地理解几轮对话之间的关系，上下文无关和上下文有关的内容都识别不出来。DeepSeek 出现后，发现其 R1 效果非常好，因为它有思维链，能思考上下文关系。于是尝试用 R1 做蒸馏，结果效果也很好。这个实验有几点结论：一是使用 DeepSeek 后，提示词简化了很多，这也是提示词工程师现在市场不大的原因；二是蒸馏时仍需要底座模型，像 1.5B 的底座模型较弱，学不到东西；三是思维链加入后，可以做一些以前做不到的事情。举个例子，用户在搜索中要求生成双色球下期中奖号码，以前在 Query 理解上做了很多尝试，但都无法解决。DeepSeek 给出的回复是“双色球号码不靠谱，远离赌博，珍爱生命”，这让我觉得自己之前的尝试很愚蠢。这个案例说明，当新技术如 DeepSeek 出现后，要勇于探索和尝试，会得到超出预期的惊喜，也能让团队成员感到开心。

大模型优化案例 2 一公文写作

写作场景以前是我不敢碰的，因为构建样本难度大。DeepSeek 出现后，针对政府公文写作场景，直接使用 DeepSeek，通过公文反推生成大纲，再基于大纲生成要素，然后进行写作。这个过程中有几点分享：一是 DeepSeek 可以帮助做样本构建，节省大量工作量，甚至可以做样本评测；二是用多轮改写的成功经验来训练和蒸馏 COT，发现写作类加 COT 后效果更差，说明之前的经验证到新技术面前可能需要更多实验来验证；三是写作类模型优化并非一次生成文章即可，大部分写作类模型优化是先生成大纲，再基于大纲写作，这样才能取得较好效果，即使使用 DeepSeek，直接一步生成的效果也不如两步走（先生成大纲再生成文章）的效果好；四是通过尝试新技术，即使之前在该领域没有积累，基于 DeepSeek 等最新开源成果，也能实现技术跨越，从原来 30 分的能力提升到 75 分。

构建开放共享的协作文化

在推动工程人员转向大模型工作时，会遇到一些疑虑。例如，一位有五六年的软件开发经验的同学对转向大模型工作非常抵触，他提出了两个疑虑：一是自己不会深度学习理论技术怎么办，我对此解释是大模型工作不需要这些，只要会搞样本、调参数、写 Python 代码就行；二是大模型优化与写代码差距太大，我展示了一个在 QCon 学到的关于工程师文化的图，就是李云老师在 2024 年 QCon 上海演讲分享的 《AI 时代团队管理的不变与变》 中的一张图，该图将工程师文化的关键项总结得很好，指出工程师的工程能力包括设计能力和工程能力两块，之前做工程开发可能是 30% 时间设计、70% 时间工程，而大模型优化可能是 80% 时间设计、20% 时间写代码，本质上仍是工程师工作，只是比例变化，底层活动也一样，都是设计、文档化、写代码以及敏捷开发等。

如果有人担心自己的效果比不上专业的研究团队，那是因为缺乏经验，存在知识壁垒和技术孤岛。解决方法是打破壁垒，通过开源和分享打破技术孤岛，大家团结起来共同成长。遇到问题时，可以找人问、开分享会、开会研讨。

一些解决遇到的大模型优化问题的经验

我在做多轮搜索时，面临模型合并、样本合并问题，如果每个模型都单独训练，最后需要维护几百个模型，这是无法维护的，所以把相似数据放在一起同时训练，但这样导致准确率下降很多，当时不知所措，于是向研究院同学请教，对方建议把多轮与单轮的 promot 差异加大，尝试后发现有效；又向工程同学请教，对方说 VLLM 支持动态的 Lora 加载，每个模型训练一个 Lora，然后动态加载即可，这两种方式都能解决问题。

在写作场景中，出现前面写得正常，后面突然出不来标点符号的问题，当时甚至想用强化学习设置 Reward 来解决，但训练底座大模型写作的人说把 decay 的惩罚从 0.6 设到 0.1，尝试后发现可以解决。现在回看去年做的事，觉得当时犯了低级错误，但认为这不是黑历史，而是成长之路，想跟大家分享的是遇到问题找别人会得到帮助，能力是逐渐积累的。

工程师文化建设

我在公司负责一些工程师文化建设工作，梳理出工程师文化最核心的几点是技术过硬、专业靠谱和开放共享。在大模型时代，我个人最认同的是开放和乐于分享，整个团队、公司或组织需要有更开放共享的文化心态。

总结与展望

从组织氛围或组织变革角度看，训练大模型很简单，只要有平台、有业务 Sense 就能做起来。大模型基础平台可以低成本建设，有众多开源资源可复用。大模型场景就那几类，按流程优化就行。要拥抱开源，避免闭门造车。

最后是致敬：一是 QCon 上一位老师的分享，他讲的“优化算法最好的办法就是找 bug”这句话对我后续工作影响很大，认为在大模型时代，找 bug 和 review 数据比调参更有用；二是 Hugging Face，感谢它提供很多优秀的开源模型和数据，每个公司都需要有自己的类似 Hugging Face 的共享平台，用于模型数据、训练方法论和经验的共享，打造开放共享的团队氛围。

嘉宾介绍

吕昕，负责科大讯飞消费者 BG 大数据和大模型技术平台相关工作，先后负责建设了讯飞 C 端用户数据中台、大数据分析平台和大模型应用开发平台等，目前负责多个 C 端产品的大模型效果优化工作。 在大数据平台、个性化推荐、广告算法、商业分析、大模型算法领域有多年经验。

会议推荐

从基础设施、推理与知识体系，到研发与交付流程，再到前端、客户端与应用体验——AI 正在以更工程化的方式进入软件生产。2026 年 QCon 全球软件开发大会（北京站）将以 「Agentic AI 时代的软件工程重塑」 作为大会核心主线，把讨论从 「AI For What」，走向真正可持续的 「Value From AI」。