目录
一、引言
二、参会内容分享
1. LLM赋能声明式前端框架调试的实践与思考
2.WebNN，Web 端侧推理的未来
3.AI Native 化的大前端开发模式
4.利用 LLM 改善研发过程里答疑体验
三、圆桌会话题分享
1.鸿蒙的现状及相关数据
2.HarmonyOS NEXT与AOSP
3.鸿蒙生态的原生开发框架ArkUI
4.关于圆桌会话题的总结
四、分享感想
QCon 全球软件开发大会是由极客邦科技旗下 InfoQ 中国主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。自2007年3月份开始举办以来，已经有超万名有多年从业经验的技术人员参加过QCon大会。QCon 内容源于实践并面向社区，演讲嘉宾依据热点话题，面向5年以上工作经验的技术团队负责人、架构师、工程总监、开发人员分享技术创新和实践。本次QCon全球软件开发者大会上海站为期2天，总共有17个主题专场，主要包括GenAI 和通用大模型应用探索、LLM 时代的性能优化、 LLM 时代 的大前端技术、加速生成式 AI 落地的最佳实践等，几乎所有的专场都离不开AI这个热门话题 ，可以说是一次以AI为主题的技术分享盛宴。此次作为参会者听了LLM 时代的大前端技术的主题分享，对前端领域与AI的结合有了一些不一样的认知，拓宽了技术视野，收获很多。本文也主要对这个主题的内容进行分享。本次大会主要参与了LLM 时代的大前端技术这个专题下的4场分享，与会的分享嘉宾结合具体的应用场景分享了他们在 LLM 时代的大前端技术发展趋势中的机遇和挑战。 此场分享的内容主要是LLM在前端调试领域的场景，结合 record&replay 对声名式框架进行交互式调试。开发者通过调试聊天框与模型互动，大模型对缺陷库进行学习增强程序分析推理能力并基于时间戳给出调试建议，开发者结合经验执行调试给出反馈，可以帮助开发者高效准确定位问题根因，为开发者带来全新开发调试范式。 起初我还很好奇，AI辅助编码也就算了，现在还来个AI自动调试，并分析问题根因，协助开发者解决问题。听了嘉宾的分享，增长了不少见识。 分享嘉宾前期做了不少调研，AI赋能前端的方向主要发力点有：AI生成页面、 增强AI能力调用的DSL设计和AI辅助开发，唯独在debug领域没有很好的实践，如下图所示： 所以分享嘉宾结合了公司的实际应用场景，探索了AI在前端debug领域的实践。具体实践过程中涉及的主要技术：程序切片和大模型智能定位分析。 这里不对技术的具体实现过程展开分享，整体的技术架构如下： 大模型基于时间戳给出调试建议，开发者执行调试给出的反馈 分享嘉宾对传统调试工具和AI调试工具做了对比，如下图所示： 可以看到传统的调试工具基于浏览器本身提供的调试能力可以分析问题的原因，AI调试工具通过录制的视频，结合大模型对程序片段的分析，最终定位到问题的原因，甚至可以定位到具体的代码行数，如下是人机交互的UI展示： 在嘉宾分享过程中，我一直在思考，通过这么复杂的技术实现和交互来做AI智能调试真的有必要吗， 在分享结束之后，我也问了一个问题：在录制阶段的成本其实是很大的，需要实时上报代码片段，操作频繁的话，这个上报的数据就很大，这么大的数据如何存储？大模型智能分析依赖于回放，那么对于一些需要紧急修复的问题，这个过程势必比较长，这么做真的合适吗？ 嘉宾给的回答是，具体场景具体分析，AI智能调试有其适用场景，对于短时就能定位的场景不合适，对于长时间很难定位的问题，通过AI智能分析还是比较合适的，并且他们也做过数据分析对比，对于长时间难以定位的问题，AI智能分析的解决效率会高于人工的解决效率。 by 胡宁馨&张敏 英特尔 SA TG Web 平台工程 WebNN是Web Neural Network API 简称，作为一种允许通过浏览器进行神经网络推理硬件加速的方法 。由W3C发布的公开工作草案以及一直在开发的Web神经网络API。WebNN在设计时就考虑到了一些用例，比如人检测、人脸识别、超分辨率、图像字幕、情感分析、噪声抑制等。除了通过 CPU 和 GPU 进行推理之外，Web Neural Network API (WebNN) 提供了 Web 应用访问此类专有 AI 加速器 NPU 的途径，以获得卓越性能及更低功耗。 作为 JavaScript ML 框架的后端，WebNN 将会在几乎不更改前端代码的前提下，为 Web 开发者及他们的产品带来相较于 Wasm，WebGL 更为优异的性能体验。本次嘉宾分享的是关于WebNN API 的 W3C 标准进度，对 CNN，Transformer 以及更广泛的生成式 AI (Generative AI) 模型的支持情况和计划，以及在 Chrome，Edge 等浏览器的实现进展。 WebNN草案地址：https://www.w3.org/TR/2023/CRD-webnn-20231219/ 2.4 WebNN的编程模型及在Chromium中的实现
WebNN对于不同的模型提供了不同的ML框架，比如ONNX模型，可以通过如下方式引入： import { InferenceSession } from "onnxruntime-web" 引入之后就可以基于此模型去开发一些应用场景的功能了。 WebNN提供了一种web应用访问专有AI加速器NPU的途径，能够合理的利用硬件资源在web端运行大模型，可以获得卓越性能及更低功耗。随着草案的提出以及后续支持的模型越来越多，基于Chromium内核的webview在不同设备里面的应用场景会越来越广泛。作为前端研发还是需要了解下其后续的进展，拓展更多业务场景的使用视野。 by 周廷帅 百度前端资深工程师，文心一言 App 大前端负责人 AI Native化的概念是基于目前对话流已经成为大部分交云互动的主流方式下 提出的，在嘉宾的分享中主要是将传统的交互方式与对话流相结合，比如LUI是和AI对话中的文本类交互，VUI是和AI对话中的视图类交互，如下图所示： AI Native化是在和AI对话流中不仅有文本类描述、视图类描述、还要有上下文之间的状态流转等设计策略， 分享嘉宾结合文心一言的交互实现，分享展示了如何将传统的交互方式与对话流相结合，并且除了交互设计本身，还探讨了特定场景下的 PatternPlugin，将涉及如何将状态机技术应用于肉鸽游戏和活动设计。 UI扩展插件的设计主要包含UI、上下文和交互 ，具体实现流程如下所示：
从流程上看，这里简单的理解就是在对话流中，通过接入插件技术，在不同的场景中识别到不同出话的时候，去调用插件的能力，使得展现出来的不是生硬的文本，而是更加友好的交互，提升用户的体验。 这种场景跟客服机器人的多轮对话中展现的订单卡片、退换货等动作有点类似，当然实现方式是不太一样的。 EDD是评估驱动开发的简称，通过对AI的模型效果进行评估来提升开发对模型的优化。 举个很常见的场景：当我们遇到问题的时候，会去问ChatGPT，一般ChatGPT都会给出相关的答案，但是答案不一定是准确的，所以细心的研发会发现，ChatGPT给出的每个答案下方都有小拇指，点击向上的小拇指表示赞同，点击向下的小拇指表示答案不符合预期，点击的动作其实就是在给模型做标注，模型会根据给的标注进一步自主学习，这个过程中就是模型自我评估的过程。如下图所示： AI Native化主要讲述了在与AI对化过程中如何通过插件的设计思想给用户带来好的交互体验，提供了一些可借鉴的实现思路。以前对人机交互的场景没有这类感知，特别是之前在使用文心一言的时候，既能展示文本，又能展示图片，觉得这个是基本的功能，无非就是通过消息类型来展示不一样的交互，听了嘉宾的分享之后，明白了通过插件去展示不一样的交互更加的灵活，受益匪浅。 在研发领域，不论是提出问题的一方还是解答问题的工程师，答疑工作都是一个避不开的重要环节。平时答疑遇到的体验问题如下： 提问者视角：等待排队对及时性的影响，了解新技术时通读文档的成本问题 值班人视角：接到过多的简单重复问题，常用知识沉淀的成本问题 此次分享嘉宾从研发答疑机器人为切入点，聚焦于研发答疑这一场景，探讨如何利用 LLM 技术协助值班人员提升回复效率 ，同时帮助提问者更快地找到问题的解决方案，从而整体优化答疑体验。 建设知识库，涵盖已有沉淀的实践文档、手册文档、组件库文档站等内容，为常用的咨询类问题利用 LLM + 知识库自动提供回复 利用 LLM 提供答疑过程总结，帮助值班人员快速沉淀 FAQ 通过自动回复前置拦截 → 未解决进入人工答疑 → 自动沉淀 FAQ 闭环，逐步完善，提升自动答疑的覆盖范围
分享嘉宾分享了两种建设智能客服的思路：RAG和FineTuning 。RAG的优势主要是方便集成现有知识，方便动态更新知识，尽可能消除模型幻觉；FineTuning的优势主要是定制模型生成内容的风格以及优化模型效果。在业务场景探索之后，分享嘉宾对这两个技术理念进行融合提供了更优的解决思路。 这里具体演进过程不做细节分享了，主要对其中内容消费中遇到的文本切割方案的实现 思路做个分享，还是很有借鉴意义的。 解决的问题：模型上下文长度限制问题；文本语义被切断问题。 存在的问题：全文语义丢失问题；上下文关联丢失问题。 解决的问题：模型上下文长度限制问题；文本语义被切断问题；上下文关联丢失问题 存在的问题： 全文语义丢失 问题； 消耗更多的存储空间； 检索结果需要消除重叠内容 解决的问题：模型上下文长度限制问题；文本语义被切断问题；上下文关联丢失问题；利用模型提炼文档摘要。 最终的实现：通过结合RAG和FineTuning的最优解 嘉宾分享的内容虽然比较常见，但是真正从0到1去训练这样的机器人还是需要掌握很多大模型相关的知识，平时使用ChatGPT答疑习惯了之后，对具体实现没有太多的感知，真正听完别人分享之后，了解其原理细节，才意识到实现有其一定的复杂性。从嘉宾分享过程中，也学到了另外一种品质，就是做事情的思路要有条理且清晰，通过不断的实践来验证其可行性，使得技术实现能够达到最优解 。具备这种品质当然离不开扎实的基本功和领域专业知识技能，学无止境，后续需要学习的地方还有很多。 在分享大会的第一天上午有幸参与了由InfoQ的技术运营组织的圆桌会话题，话题的内容主要围绕鸿蒙操作系统的发展现状以及目前各大公司与华为的对接情况 ，参会人员来自平安、美团、百度、华为、阿里和字节的客户端研发和部门负责人，当然也包括我们公司客户端的研发同学。我很有幸受公司技术运营叶兰的邀请参与了整场圆桌会的讨论 ，了解了鸿蒙操作系统及生态的一些进展。会后我也查阅了相关的资料以及华为开发者中心相关的文档，来加深对话题内容的印象。觉得很有必要给前端研发同学分享下鸿蒙生态的现状及相关的技术框架，或许对于前端研发来讲是一个不错的技术发展方向。 如下图所示是2023年8月4日在华为开发者大会上分享的关于HarmonyOS的理念及开发者预览版的信息： 上面明确提到2023年8月对企业开发者开放，2024年Q1对所有开发者开放 。以下是摘自网站上关于HarmonyOS的一些信息： 在2023年12月19日的开源产业生态大会上，华为终端BG软件部总裁龚体介绍，鸿蒙生态设备总量超过7亿台 ，其中华为自有设备3亿多台。他预计，到2024年，鸿蒙生态设备数量逐步达到8亿台至10亿台。 IDC数据显示，截至2023年11月，华为手机在国内手机市场的份额达到了14% 。天风国际分析师郭明錤此前预测，2024年华为手机出货量有望将至少达到6000万部，预计会增长近一倍。 在2023年12月29日公开的新年致辞中，华为轮值董事长胡厚崑提及，“与伙伴共同加快移动应用鸿蒙化，实现鸿蒙生态的历史性跨越 。” 在2024年1月1日，华为终端BG、首席运营官何刚更新了自己的微博，并透露了2024年的一个重要方向：“今天，是2024年的第一天，这一年将是鸿蒙生态全面进化的关键一年。 ” 在2024年1月2日，华为常务董事、终端BG CEO、智能汽车解决方案BU董事长余承东发布全员信直言，“2024年是原生鸿蒙的关键一年，要加快推进各类鸿蒙原生应用的开发，集中打赢技术底座和三方生态两大最艰巨的战斗。 ” 自2023年11月23日起，HarmonyOS官方微博每一到两天就会宣布一家启动鸿蒙原生应用开发的厂商消息，从阿里钉钉、支付宝、同花顺，到搜狐、新浪、360，再到麦当劳、爱奇艺、京东等，短短两月时间内，就有超百家头部互联网应用厂商牵手鸿蒙。 从2023年下半年以来，华为对于鸿蒙生态的建设明显加快了推进进程，截止到目前已经有很多的APP是基于鸿蒙原生APP开发并且已经投放使用。 在了解鸿蒙技术框架之前先简单介绍下什么是AOSP。AOSP是一个由谷歌维护的开源操作系统开发项目。对于过往鸿蒙开发者来说，基于AOSP将安卓应用针对鸿蒙适配后即可兼容使用，这也是早期为什么很多人吐槽说HarmonyOS是套壳的Android系统的原因 ，因为HarmonyOS和Android都是基于底层AOSP二次开发的。但鸿蒙原生应用将基于华为自研的鸿蒙开发框架或底座进行开发，HarmonyOS NEXT将不再含有AOSP的代码。换言之，未来鸿蒙将全面“脱钩”安卓，形成一套自己的独立生态。 ArkUI是华为方舟开发框架的简称 ，为HarmonyOS应用的UI开发提供了完整的基础设施，包括简洁的UI语法、丰富的UI功能，以及实时界面预览工具等，可以支持开发者进行可视化界面开发。分享嘉宾的汇总如下： 从分享嘉宾的内容来看，鸿蒙生态的原生开发框架语言ArkTS，是基于JS/TS进一步演化而来的，在JS/TS基础上，扩展了声明式UI语法 ，对于前端研发来讲，很容易就能够上手。ArkUI官方文档链接：方舟开发框架（ArkUI）概述 从组件定义的代码来看，类似于JS里面的class类型组件的定义 ，同时用了注解/装饰器模式来扩展其功能。 从上图可以看到，通过ArkTS编写的声明式语法在编译之后，和Java代码非常类似，基本上是一样的。编译之后的代码，在方舟引擎里面运行，通过ArkUI渲染引擎呈现最终的页面展示。 ArkUI内部提供了原生的响应式组件，其实现原理包括栅格布局、媒体查询等 ，跟前端H5在移动设备的响应式布局原理基本上是一样的。 鸿蒙原生应用ArkUI框架提供了XComponent定义插件的方式 ，来扩展其生态。XComponent定义的插件可独立编译和发布，无冗余的数据拷贝， 并且插件和框架渲染是解耦的。 此次圆桌会关于鸿蒙话题的讨论，参与的人员都说了和华为那边对接的进度以及对鸿蒙系统的看法，其实从他们的表述来看，对接的并不是那么的顺利，过程中有很多的问题。每个公司客户端技术栈存在很多的差异性，比如美团那边主要以动态化为主，平安那边主要以RN为主，如果都让鸿蒙去适配不同厂商的实现也不太现实。会上也讨论了关于鸿蒙生态的崛起给研发带来的一些机会，比如目前市场上对鸿蒙研发的招聘诉求，如果鸿蒙操作系统真能在国内发展起来，那么对技术研发是一个很不错的机会，特别是对于TS技术掌握的比较好的前端研发同学，毕竟国内那么多的应用如果都要转成鸿蒙系统的原生APP的话，对这个技术掌握的诉求市场是非常大的。此次圆桌会收获真的很大，之前只是听说过鸿蒙操作系统，通过此次圆桌会的讨论，对鸿蒙的生态有了进一步的认识。 作为参会者参与此次QCon上海站的软件开发者大会，收获真的很多。此次大会不仅参与了LLM在大前端的一些应用场景，也在会场线下了解了一些展厅展示AI产品的应用场景，拓宽了对AI技术的视野。虽然很多还听得不是很明白，但是对于一些实现有了初步的认识，后续再遇到，只需要花些时间 去熟悉相关内容就可以了。通过此次分享大会，和一些分享嘉宾的交流，也进一步认识到在前端这个领域，技术栈逐步成熟之后，当很多公司都在降本增效的时候，作为前端研发该如何提升自身的竞争力。AIGC、鸿蒙研发、高性能解决方案 或许都是不错的发展机遇，多掌握一些技术，多实践前沿的技术，总是对的，机遇也总会留给那些有准备的人。希望以后公司还能继续提供这样的机会给到技术研发同学，因为很多前沿的技术以及技术实现框架流程，真的只能从分享嘉宾的演示文档里面才能挖掘出来 。也希望公司的技术研发同学能够作为分享嘉宾参与到此类大会里面，分享公司内部基于一些业务场景的解决方案，提升公司的技术影响力。 五
分享资料
见大会官网：2023上海QCon大会官网
关注得物技术，每周一、三、五更新技术干货
“
扫码添加小助手微信
如有任何疑问，或想要了解更多技术资讯，请添加小助手微信：