当前位置: 首页 > ops >正文

硬核对话:“推理模型+智能体”给软件研发带来哪些新的应用场景与价值?

以下内容整理自2025AI+研发数字(AiDD)峰会上海站对话环节:(全文约9328字,预计阅读时间10分钟)。

对话主题:“推理模型+智能体”给软件研发带来哪些新的应用场景与价值?

主持人: 

彭靖田:谷歌开发者专家/谷歌出海创业加速器导师

对话嘉宾:

赵天成:联汇科技 CEO兼首席科学家

齐彦松:字节跳动 用户增长测试团队负责人  

杨 超:红西瓜半导体 大模型研发负责人

张 涛:商汤科技 小浣熊家族技术负责人

📑SHOWNOTES:

1. 推理模型如何提升软件测试的效率和智能化水平?

2. 大模型时代,企业如何平衡自研与开源技术栈的选择?

3. 多模态模型(如视觉+语言)在工业界落地的最大挑战?

4. 智能体技术在未来3年最可能颠覆哪些软件研发环节?

图片

正文

图片

▶主持人彭靖田:

各位观众,大家好。刚刚结束的五场精彩纷呈的Keynote演讲,为我们带来了丰富的知识盛宴。接下来,将由我主持本次的Panel讨论环节。今天的议题十分引人入胜,它聚焦于推理模型与智能体这两大热点的融合。在正式开启讨论之前,请允许我邀请各位嘉宾进行简要的自我介绍,首先有请联汇科技的赵天成先生。

▶赵天成:

大家好,我是联汇科技的赵天成。我们的团队长期深耕于多模态智能体领域,致力于将机器人及各类智能终端转化为智能体。从最初开源的多模态模型,到如今商业化产品在众多智能终端的成功落地,我们正推动多模态模型及智能体技术从电脑操作系统迈向更广阔的物理世界。

▶齐彦松:

大家好,我是字节跳动的齐彦松,隶属于用户增长团队。近期,我们团队正积极探索利用智能体及大模型技术优化软件测试流程,提升测试质量和效率。经过一两年实践,我们深刻感受到大模型技术对软件测试环节的巨大变革潜力。今天,非常荣幸能与大家分享我们的见解与发现。

▶杨超:

大家好,我是GAU半导体的杨超,负责公司座舱交互及大模型技术研发。从事语音交互工作已有十几年,见证了从传统方法到大语言模型及智能体技术的巨大飞跃。

▶张涛:

大家好,我是商汤科技的张涛,目前负责小浣熊家族产品的研发。早在2023年,我们就关注到了Code Interpreter技术,并基于此技术开展了一系列产品研发工作。如今,市场上热议的Agents等产品,其核心思路便是让模型直接编写代码进行操作,尽管实现难度较大,但潜力无限。

01

推理模型如何提升软件测试的效率和智能化水平?

▶主持人彭靖田:

感谢各位嘉宾的精彩介绍。今天的首个议题聚焦于AI coding领域,即利用AI编写代码。随着这一趋势的不可逆转,测试团队不仅要测试人工编写的代码,还需应对AI生成的代码。因此,我们的第一个问题是:推理模型如何提升软件测试的效率与智能化水平?下面,有请字节跳动的齐彦松先生分享见解。

▶齐彦松:

非常感谢彭老师的邀请。关于推理模型在软件测试环节中的应用,我们首先需审视当前软件测试过程中的效率瓶颈与痛点。在我看来,主要存在两大类问题:一是测试资源投入的有效性,二是软件测试的高效性。

测试有效性方面,我们投入的测试资源是否真正有价值?软件测试旨在发现并解决业务风险,但并非所有风险点都会转化为bug。随着AI能力及代码质量的提升,低bug或无bug的需求日益增多,继续投入QA资源无疑是一种浪费。因此,我们需利用大模型能力精确识别问题代码,提升测试有效性。为此,我们尝试对需求进行分级,包括版本粒度、需求粒度及功能点粒度,以实现不同程度的提效效果。同时,我们还进行了需求分级与bug精准定位的尝试,以前置发现潜在bug。

测试高效性方面,传统软件测试流程需人工分析需求、设计测试用例、执行测试并回顾结果,效率低下。如今,借助大模型与推理模型,我们能够利用AI能力替代人工完成测试用例生成及断言等环节,显著提升测试效率。此外,我们还进行了全流程智能化、泛自动化研究及智能归因等尝试,以在事前、事中、事后实现技术提效。

▶主持人彭靖田:

感谢齐总的精彩分享。齐总从有效性和高效性两个维度为我们揭示了推理模型在软件测试中的应用价值。接下来,我们请商汤科技的张涛先生就测试部分的工作发表见解。

▶张涛:

相较于字节跳动,商汤科技在测试部分的工作更侧重于传统方法论,因为我们目前主要服务于产线产研工作。然而,在辅助编程产品的研发过程中,我们接触到了众多研发客户需求,并发现了一些有趣的现象。测试工作主要分为测试开发与测试执行两大部分。测试开发涉及测试用例编写与断言设计,而测试执行则依赖于现有测试基建以确保稳定正确的结果。因此,测试提效工作最终归结为开发任务,需人与AI共同协作以快速实现测试开发任务。然而,不同行业AI在测试开发中的提效程度存在差异。例如,半导体及硬件行业代码复杂度高、潜在规则隐晦,AI提效难度较大。此外,TDD作为一种优秀实践,因前置工作延后而难以推行。但随着AI的引入,这部分工作得以提速,可能促使更多团队采用TDD范式,进而提升整个软件行业的质量。

02

大模型时代,企业如何平衡自研与开源技术栈的选择?

▶主持人彭靖田:

接下来,我们进入第二个问题,这也是当前大模型时代,无论是技术团队负责人还是企业高层都普遍面临的一个难题:在大模型领域,企业该如何在自研与采用开源技术栈之间做出平衡?我们都知道,在当前经济环境下,企业不太可能大规模扩充团队,而开源方案因其低成本和灵活性,无疑具有很大吸引力。但与此同时,开源方案在安全性等方面也存在一定顾虑。那么,接下来我们就请各位嘉宾分享一下各自的看法。

▶赵天成:

确实,这个问题非常具有代表性。对于我们做模型的团队来说,其实也面临着两个维度的选择:一是作为模型开发者,是否应该将自己的模型开源;二是作为模型使用者,应该选择哪个模型。以我们团队为例,我们既有自研的模型,也开源了很多模型。在决定是否开源时,我们主要考虑的是“Model as a Product”这一理念。当前,基础模型发展迅速,尤其是大厂推出的模型,它们更多是在探索AGI的边界,而非直接针对具体产品。这些优秀的开源模型为应用开发者提供了快速尝试不同想法的可能,无需先花费大量时间训练模型。然而,当应用场景明确且需要不断迭代提升时,对模型进行后训练(post-training)就显得尤为重要。后训练可以与预训练模型解耦,企业可以根据需要随时更新到更好的基础模型。因此,我认为,当产品定位清晰、ROI合理时,进行后训练是提升产品竞争力的关键。

▶齐彦松:

我补充一点,企业在选择自研还是开源时,我认为主要需要考虑两个因素:一是公司规模和体量是否足以支撑自研的高成本和高复杂度;二是实际需求是否足够强烈。如果公司规模较小,或者需求相对简单,那么选择开源方案无疑是更经济的选择。随着技术的不断进步,未来甚至可能出现一人公司独立完成从需求分析到研发测试的全流程。因此,我认为开源技术将在未来发挥更加重要的作用。

▶杨超:

前面两位嘉宾已经讲得很全面了,我再补充一点个人看法。在企业中无论是做产品还是项目,我们的目标都是把事情做好。在选择技术方案时,我们主要考虑的是成本和时间效率。当前开源社区非常繁荣,技术迭代迅速,因此我们在选择技术方案时通常会优先考虑开源方案。当然,我们也会关注开源方案的license是否满足需求、商业化是否有限制等问题。如果开源方案的质量达标且没有商业化问题,那么我们就没有必要重新开发。此外,我认为企业的类型也会影响这一决策。比如,对于专门做大语言模型技术的公司来说,自研预训练模型是必然选择;而对于应用层公司来说,则没有必要进行大规模投入。在自研方面,我们更多地是基于现有模型进行微调或补充能力,以形成场景化的模型或产品。

同时,我也想分享一下我们团队在开源方面的实践。我们在2021年开源了一款语音软件Wenet,快速推动了语音端到端算法的工业界落地。许多公司无需再组建自研团队从头研发新的语音算法,只需少量工程师就能利用开源技术完成各个场景的应用开发。我认为,开源不仅推动了行业的繁荣,还促进了技术的共同进步。比如Deepseek等公司也在积极开源其能力,并获得了大量反馈。这种共建社区的方式有助于推动整个行业的进步。因此,我呼吁大家更多地拥抱开源,即使进行自研也可以考虑将成果释放给社区,共同成长。

▶张涛:

在前几位嘉宾分享结束后,发现大家的观点竟高度趋同。在这个阶段,鲜少有人愿意主动踏上“造轮子”这条路——当然,谷歌这样的行业巨头或许是个例外。更多时候,所谓的“造轮子”实则是无奈之举,背后往往隐藏着两大压力源:成本考量与合规要求。

具体而言,尽管市场上存在开源方案,但它们往往难以完全契合实际需求,存在明显的差距。即便勉强引入,后续若想进行功能扩展,开发成本便会急剧攀升;又或者,这些方案的技术栈与现有技术体系不兼容,导致维护成本居高不下。面对这样的困境,企业往往不得不选择自研,以摆脱受制于人的局面。而这种出于实际需要的“造轮子”,在业内看来,实则是合理且必要的。

再将视线拉回到大模型开源与闭源的讨论上。早些时候,业界曾有声音质疑“大模型开源不过是噱头”,因为很多时候所谓的开源仅限于权重开放,远不足以满足开发者的实际需求。在实际应用场景中,模型仍需经历大量调优工作方能投入使用。然而,时至今日,情况已悄然发生转变。越来越多的人开始直接拥抱大模型,借助如ModelScope这样的平台迅速接入,并基于此构建自己的产品。这些产品的上层逻辑设计愈发精简,运行也愈发流畅。

这一变化深刻反映出,大模型的能力已迈上新台阶,泛化性能显著提升,开发门槛大幅降低。在此背景下,“造轮子”已不再是首选策略。在AI辅助研发日益盛行的今天,我们目睹了一个更加开放、协作且高效的产业生态正逐步成型。

▶主持人彭靖田:

非常感谢各位嘉宾的精彩分享。最后,我想对这个问题进行一个总结。其实,所有的权衡和决策都集中在项目的起始和收尾阶段。在起始阶段,我们需要从经济效益的角度考虑采用开源技术栈还是自研方案是否划算,并向上级做好沟通。在收尾阶段,我们需要评估开源技术栈的引入是否对产品本身产生了负面影响。正如天成总所提到的,如果开源技术栈能与产品正向结合,并且像插件一样即插即用,那无疑是最佳状态。同时,由于大模型具有数据积累和飞轮效应,无论是技术负责人还是产品负责人都需要重视数据的积累。这样,我们才能在大模型时代做出明智的决策,推动企业的持续发展。

03

多模态模型(如视觉+语言)在工业界落地的最大挑战?

▶主持人彭靖田:

接下来,我们探讨第三个问题,它与算法紧密相关,也是当前的技术热点。我想先问问在场的各位,是否有人关注过多模态大模型?如果有的话,请举手示意一下,这样我能大致了解现场的关注情况。我看到有举手的,不过比例似乎不高。可能大家更倾向于关注智能体这类前沿技术,但实际上多模态技术,尤其是视觉与语言的融合,正变得异常火热。再加上近期具身智能以及具备操作能力的VLA模型等新技术的兴起,使得多模态技术备受瞩目。那么,今天的第三个问题就是:多模态模型在工业界落地时,面临的最大挑战有哪些?接下来,我们先请两位算法负责人发表看法,首先有请天成总。

▶赵天成:

我们团队在多模态模型领域已经深耕了近十年。从最初将视觉与语言融合训练,到CLIP模型的诞生,再到如今以多模态语言模型(VLMs)为主流的结构,我们见证了整个行业的演变。那么,为何我们对多模态模型如此感兴趣呢?首先,人类获取的信息中,有70%来自视觉,因此具备视觉信息无疑具有巨大价值。其次,多模态模型的一大特点是将感知与决策融为一体,实现端到端的处理。

举个例子,在研发侧,多模态模型有着广泛的应用。比如手机操作智能体或电脑操作智能体,它们无需获取底层的HTML等元素,只需直接观察屏幕并执行指令即可。像operator这样的智能体,甚至可以盯着浏览器为你操作。此外,我们与浙江大学合作的一个项目是将多模态模型应用于测试领域。传统上,APP的测试需要依赖单元测试和人工操作,而多模态模型则能直接观察屏幕,模拟用户行为以找出潜在问题。这种“找茬”式的测试方式,是传统测试方法难以实现的自动化。

然而,多模态模型的落地也面临着诸多挑战。首先,成本问题不容忽视。相较于传统的视觉模型(如OCR、目标检测等),多模态模型的推理成本要高得多。其次,多模态模型在高精准场景下的表现仍逊色于传统的机器视觉模型。虽然多模态模型擅长抽象理解,但在需要精确定位和识别的场景下,其漏报率较高。尤其是在很多实际应用中,比如工业质检、自动驾驶、视频分析等,图像或视频数据的处理不仅需要高精度的结果,还必须具备实时性。正如白老师刚才提到的,在一些高标准的金融场景中对AI的准确性、可解释性和稳定性都有非常严苛的要求。而在视觉领域,这类“高精准+低延迟”的需求其实更为普遍。

当前的一大挑战,就是如何将偏抽象、生成式的模型能力,有效地与这些对精度和效率要求极高的实际应用场景融合起来 。这不仅是技术上的难点,也涉及到模型压缩、推理优化、软硬件协同等多个层面的问题。

因此,如何在保持生成模型强大表达能力的同时,满足具体行业对性能和质量的严苛标准,是目前AI在视觉领域落地过程中亟需突破的关键方向之一。

▶杨超:

多模态技术对我来说并不陌生,我们团队在过去四年里一直专注于座舱内的交互技术研发。从最初的语音交互到视觉交互,再到多模态交互,我们一直在不断探索和创新。在传统多模态技术中,我们主要实现了唇语、联合表情的语音识别以及手势与语音的协同控制等功能。然而,在大模型时代,多模态技术有了全新的发展。

现在的大模型时代,多模态技术更多地指的是在VLM或VLA技术框架下的能力。这种模型相比以前解决了许多难以解决的技术问题,比如将不同模态的信息都token化并整合到一个模型中。然而,在多模态模型的落地过程中,我们也遇到了一些挑战。

首先,数据问题是一个关键。虽然大语言模型已经充分利用了人类能找到的所有数据,但视觉预训练模型的数据利用却远远不足。我们每个人都可以看作是一个传感器,收集着世界上的数据,但这些数据往往没有被有效存储和利用。此外,视觉数据的隐私性也限制了其共享和利用。因此,如何获取和利用高质量的视觉数据是多模态模型发展的关键。

其次,技术问题也是一个不容忽视的挑战。虽然多模态模型在理论上具有很大的潜力,但当前的技术能力距离实际落地需求仍有一定差距。许多炫酷的demo在受限的演示场景下表现良好,但在实际应用中却难以达到预期效果。

最后,算力问题也是一个重要的制约因素。多模态模型需要处理文本、图像和视频流等多种数据类型,对算力的需求极大。尤其是在机器人或车辆行驶过程中,需要实时处理大量的视频流数据,这对算力的要求更高。因此,如何降低多模态模型的算力需求并提高其处理效率是当前亟待解决的问题。

▶张涛:

刚才听到两位算法负责人的讨论很深入,但我也有一些好奇和疑问想请教一下。

第一个问题是关于多模态模型的泛化性问题。虽然多模态技术在理论上具有很大的潜力,但当前其在泛化性上仍与语言模型存在一定差距。假设未来真的有一个统一表征的多模态大模型出现,我们能否预计其参数量和推理成本会达到什么量级?是否会在可控范围内?

▶赵天成:

我认为从参数量上来看,多模态模型并不会是一个简单的加法关系。最新的多模态研究都致力于实现真正的统一表征,即将多模态的理解与生成用一套架构全部完成。因此,模型体量可能仍然会像现在一样庞大,达到千亿级或万亿级,并可能沿用MOE架构。然而,这并不意味着每次增加一个模态就要将参数量翻倍。

当前很多多模态模型采用的是“两段式”结构,即通过一个视觉编码器加上一个大语言模型进行联合训练。在这种架构下,视觉部分的参数量其实远远小于语言部分 。比如,语言模型可能是千亿参数级别的大模型,而视觉编码器往往只有几亿到十几亿参数就已经足够。这说明在整个模型的计算开销中,主要瓶颈仍然集中在语言侧 ,而不是视觉部分。这也反映出一个现象:视觉部分更多承担的是“快速感知”的角色 ,负责提取图像中的关键信息;而真正的复杂推理和逻辑构建,还是由语言模型或多模态融合模块来完成 。

从这个角度来看,参数规模并不是当前多模态系统的主要挑战,更重要的是如何实现多模态的融合,从而提升整体模型的理解与生成能力。

▶杨超:

我再补充一点我们实践中的经验。由于我们更多地涉及到与硬件交互的多模态技术(如具身智能等),因此数据处理量较大且存在隐私问题。因此,我们通常选择在端侧进行方案部署以降低延时和功耗。然而,当前端侧芯片的算力有限,导致模型规模也受到限制(通常在10B以下甚至更小)。在这样的参数量下,模型的泛化能力可能不足,因此我们需要针对具体场景进行微调以利用预训练的基础能力。

▶主持人彭靖田:

好的,感谢杨超总的分享。最后,我简单总结一下我们第三个问题的讨论。多模态技术在工业界的落地仍面临诸多挑战,尽管它是一个极具前景的发展方向,但目前高质量数据的缺乏仍然是一个关键瓶颈。以大家使用DeepSeek的经验为例,尤其是在使用其联网搜索功能时,会发现中文网络上的信息质量整体偏低,这对模型训练和推理效果都带来了不小的限制。而近期 Google 推出的 Gemini 1.5 Pro 更新版本,在中文资料的检索能力上有了显著提升,体现出其背后所依赖的数据质量和覆盖广度具有明显优势。这也说明了一个重要趋势:拥有高质量、多语言、多模态的数据资源,在大模型基础架构的研发中具备显著竞争优势 。如何构建或获取高质量的训练数据,将是推动多模态技术真正落地的关键一环。尽管高质量数据的缺乏和算力成本的高昂为多模态技术在工业界落地带来诸多挑战,我们仍然相信随着基座大模型技术的快速发展和多模态技术的不断推进,这些问题终将得到解决。

04

智能体技术在未来3年最可能颠覆哪些软件研发环节?

▶主持人彭靖田:

那我们最后一个问题也是大家关心的——往未来看,智能体技术在未来三年最可能颠覆软件研发的哪些环节?下面依次请各位负责人分享观点。

▶赵天成:

我认为,首先从内部来看,许多代码已逐步由类似Cursor的系统生成。至少在初级程序员层面,大量工作可被AI替代。不过,架构设计仍需高水平架构师或高级开发人员把控,目前AI难以独立完成系统架构设计。但借助AI实现具体模块,可使一名高质量研发人员的工作效率提升10倍甚至100倍,这是当前可实现的第一步。

其次,AI在debug领域的应用前景广阔。它不仅能替代传统单元测试生成,还可模拟真实用户进行端到端测试,发现传统测试方案难以覆盖的问题。过去这类测试因成本高昂,只能依赖人工完成,如今AI的介入不仅能替代人工,还能开拓新的测试版图和场景。

▶齐彦松:

结合三年时间维度,我认为软件研发在以下环节将发生重大变化:

需求理解与生成:智能体能力不断增强后,将更深入理解用户需求和产品战略。通过用户反馈、日常调研和竞品分析,智能体可精准把握用户意图;结合企业知识库建设,理解产品战略和项目进度,主动提出产品优化建议和需求,推动产品核心目标达成。

管理决策:AI对软件开发周期中的项目管理、风险管理和项目流程理解加深后,可做出管理判断,识别风险并提出解决方案。同时,AI可参与产品进度管理、团队管理和决策支持,如隐私合规风险评估、解决方案制定和人员排期建议等。未来,AI将协同不同角色,形成协同网络,加速人员开发周期,提升开发效果。

▶杨超:

虽然预测三年周期的事情难度较大,但基于当前AI发展速度,我认为:研发流程高度AI化:从产品定义、需求提出(PRD实现)到软件开发、测试,整个研发流程已高度应用大语言模型技术,且效率提升显著。像cursor,windsurf这类辅助编程的工具已经是大部分研发人员的必备工具,若大家失去这类工具,可能需一两个月才能适应,甚至完全无法回到以前的开发方式了。

个人创业门槛降低:借助AI能力,个人可快速实现美工、UI、前端等工作,快速开发网站或手机应用。未来,AI可能不仅帮助修改,还能自发产生需求和idea,通过分析用户需求实时捕捉问题并反馈。

软件开发行业颠覆:随着更多人使用AI工具促进生态发展,三年后软件开发行业可能发生颠覆性变化。大部分工作可能由智能体完成,人类只需具备高层次视角统筹整体方向。

▶张涛:

我赞同杨超总的观点,大家可能低估了大模型的长期影响。目前AI写代码能力已对许多开发领域及其他需要使用工具的场景产生深远影响,开发者定义将更广泛。例如,自媒体从业者可利用AI开发多平台分发工具,满足个性化需求。未来,AI可能不仅改变开发领域,还将渗透到各行各业的工作环节中。

▶主持人彭靖田:

非常认同。人类互联网的最终受益者是AI,因为AI的信息处理上限和数据容量远超人类。智能体最大的挑战是取代标准化岗位和流程。在软件研发及其他行业,当存在SOP(标准操作程序)时,社会分工产生大量岗位,而信息化使这些岗位的工作内容在电脑上数据化完成,如今这些工作都将被智能体逐步取代。若工作属于标准类动作而非非标岗位,将面临被取代的巨大风险。未来,随着AI之间交流成本的降低,流程将大大简化,人人都有可能成为程序员(借助智能体),而非传统意义上的程序员。

*观众提问

Q1:

您好,我想请教一个问题。随着大模型的发展,程序编写越来越多地由机器和大模型完成。由于机器的不确定性,如何确保智能体生成的程序不会对人类造成危害?如何有效控制其安全性?

A:张涛

当前大模型的不确定性确实是一个不可避免的问题。但在实际工作中,我们和一些客户发现,一些确定性的工具和软件开发的基建仍然非常有用。过去,新增功能可能需要在软件基建中增加QA流程来确保质量控制,而现在,由于大语言模型的能力增强,这些工作可以交给模型来完成。因此,我们的关注点可以从把控AI编写的代码中的隐含问题,转变为把控模型帮我们检查完的内容是否完备。这样可以在很大程度上减轻我们的心理负担。

A:齐彦松:

我补充一下。我认为有两个方面非常重要。首先,无论使用大模型还是其他方式,都需要设定一些规则来限制模型的使用。这些规则可以防止模型生成对人类有害的程序。过去有机器人三定律等规则,但现在可能需要制定新的规则来适应新时代。其次,需要有兜底措施。无论是小问题还是可能对人身造成伤害的大问题,都需要有相应的兜底行为或能力来确保安全。这种兜底思维、熔断思维在大模型时代仍然非常重要,只是具体实现方式可能有所不同。例如,我们可以使用分隔离的小程序Agent来帮助我们完成一些任务,它们可能具有更高的规范性和自我约束性。但总体来说,规则和兜底是两个关键点。

Q2:

老师您好,我想请教一下。目前大模型和智能体主要应用于互联网、网络空间或云端。那么它们对车端嵌入式软件的开发会产生哪些影响?与云端软件相比有哪些区别?

A:杨超

您是指对软件开发本身的影响对吧?我从效率提升的角度谈谈。现在很多场景都在利用大模型来提高效率。比如测试环节,无论是哪个层面的测试用例,大家都在拥抱大模型技术。我们公司覆盖从芯片设计到车机系统软件再到各个预控软件的开发,每一层都在利用大模型进行单元测试生成和代码开发提效等工作。这些方面云端和车端嵌入式软件可能没有太大区别。不过车端嵌入式软件的代码可能更专业、更少见一些,在网上可能找不到开源代码。但只要有代码仓库的所有信息,大模型通过其能力仍然可以起到很好的提效作用。另外,如果车厂有足够的研发资源,它们也可以自己开发内部的代码相关模型。

http://www.xdnf.cn/news/14032.html

相关文章:

  • MySQL索引优化:回表
  • 上位机如何和PLC通讯(西门子举例)
  • 《解锁B4A:安卓开发的小众利器》
  • 侧向层析检测粘稠样品爬速太慢?默克HF065硝酸纤维素膜带来完美解决方案
  • 单北斗芯片AT9880B
  • pycharm 安装通义灵码插件
  • 基于LLM的图表理解和绘制
  • ONLYOFFICE 的AI技巧-1.集成OCR、文本转图像、电子表格集成等新功能
  • vLLM用2*(8 H800)部署DeepSeek-R1-0528-685B
  • 终端警告“加载用户设置时遇到错误找到一个带有无效“icon“的配置文件。将该配置文件默认为无图标。确保设置“icon“时,该值是图像的有效文件路径“
  • Linux服务器自动发送邮件
  • java爬虫框架,简单高效,易用,附带可运行案例
  • 深入 Java 泛型:基础应用与实战技巧
  • 现在可以买到的方便携带的吹奏乐器
  • Python 爬虫入门 Day 2 - HTML解析入门(使用 BeautifulSoup)
  • 中小企业申请商标避免使用误认名称!
  • 一个小错误:Content-Type ‘text/plain;charset=UTF-8‘ is not supported 的粗心
  • ONLYOFFICE协作空间API指南:使用JavaScript SDK为每个用户结构化协作房间
  • 利用DeepSeek将docx生成程序迁移至minidocx
  • 【6S.081】Lab1 Xv6 and Unix utilities
  • git提交错误 [remote rejected] HEAD -> refs/xxx
  • PHP:Web 开发领域的常青树
  • Jmeter压测手册:脚本配置、服务器环境搭建与运行
  • PIN to PIN兼容设计:MT8370与MT8390核心板开发对比与优化建议
  • react 使用 postcss-px-to-viewport 实现 px 自动转 vw 自适应
  • Docker Compose 部署 Prometheus + Grafana
  • NORA:一个用于具身任务的小型开源通才视觉-语言-动作模型
  • 基于Netty的TCP Server端和Client端解决正向隔离网闸数据透传问题
  • 轻量级顺序监控器监控 LLM 中的分解攻击
  • sticky设置了top但还是有大约1px空隙