写点什么

告别模板时代!妙多 VP 张昊然:生成式 AI 如何驱动 UI 设计的范式革命

  • 2025-08-12
    北京
  • 本文字数:8894 字

    阅读完需:约 29 分钟

告别模板时代!妙多VP张昊然:生成式AI如何驱动UI设计的范式革命

产品设计界面无处不在,从我们每天接触的手机、车载屏幕到各种智能设备。如今,生成式 AI 已在文字、图片、视频带来了诸多改变,它在 UI 领域又会产生哪些深远影响?


AICon2025 上海站上,妙多副总裁张昊然发表了题为《生成式 AI 在产品设计和 UI 领域:过去、现在和未来》的演讲。作为身处这一行业之中的创业者,张昊然分享了他对过去的观察、思考和未来的展望,并演示了这个领域的生成效果、产品化等随模型进展演进的过程。


1 初代生成式 UI:“套模板”技术路线


所谓 UI,UserInterface,就是用户界面。我们每天拿起来的终端设备,包括这里显示 PPT 的界面,本质也是一种 UserInterface。


妙多也是在这个领域做对应的事情。作为专业工具,生成式 AI 对于 UI 领域也是非常值得研究的。我们今天看到 AI 可以生成文字、图片、视频,但我们可能没有意识到在数字世界中, UI 也是一个隐形基础设施。


关于 UI 的生成,非常直觉的一种看法是闻声见面:我输入一段 prompt 来表达我的意图,然后这个界面就生成了。我们在最初探索的也是这么一件事情。


在这个领域最早的玩家有几个,除了我们还有 Galileo,他们其实比我们做的更早。这家公司其实已经躺尸很久了,直到上周谷歌开发布会时,宣布把他们给收购了,他们新的 speech 产品其实正是 Galileo 的团队孵化出来的。


Figma 也在这个领域做一些对应的事情。所以我们一开始去研究这件事情的时候,没有太多特别的想法,你想做一个弯道超车的事情其实是非常困难的,因为那个时候 Galileo 已经可以用我刚才说的 prompt 来生成界面了。所以我们的第一想法就是怎样能追上他们,或者说我们怎样能够做到这件事情。


大家可以想象一下,今天如果你是一个产品经理或者研发,你需要解决这么一个工程问题,就是我要生成一个 UI 界面,你最直觉的想法是什么?


其实应该是先有代码,再有界面。这个很有意思,这其实是同我们传统的工作流程相反的,因为我们传统工作流程是先有了 UI 界面,再有代码。


为什么是先有代码再有界面?主要原因还是在于 UI 本身并不是一个图片形式的东西,它其实是一个结构化信息的组合,本质上这件事情是和屏幕一起诞生的。


在 20 年前,这个世界并没有所谓的 UI 设计师,但我们看最初代的做产品界面的人,其实很多是前端工程师。比如说 Facebook 最早期的 UI 界面和代码是扎克伯格一个人写的,再比如说 Foxmail 是由张小龙一个人写的。实际上在最早的时候,界面和前端就是联系在一起的,只是在演进之后,我们对应有这么一个分工。


而大模型本身在代码这个层面上,它目前的能力是不言而喻的。所以我们一开始的思路也是这么一个逻辑,如果由大模型能够对应到一个界面的前端代码,它是不是能够转回到 UI 界面呢?


但现实相对来说是比较骨感的。去年 1 月,我们用当时可能是在代码领域最有成效的模型 GPT4,他们有一个 demo 是拍了一张纸上画的一个原型图,然后就生成了前端代码。我们用这套逻辑做了一些测试,效果如图。



它的核心问题是,它还是可以生成一个看起来不错的界面,但问题是这个界面的用户体验、美观程度与我们想要的交付物是有距离的。于是我们在那时换了一个思路,就想一种方式是通过现有技术与产品更有效结合的模式,看能不能用大模型解决一部分问题,再用产品化的方式解决一部分问题。



所以就衍生出了这么一个技术路线,我今天会把这个技术路线简称为套模板。它具体的逻辑是当用户可能表述一个界面需求的时候,实际上那个时候的大模型是能够对意图做扩写,做一个合理的排布。当有这么一个文本能够对页面结构做详述的时候,假设我们在工程和产品上能够匹配这些不同的需求和对应的内容,并把它们组装起来,就有可能形成一个看起来不错的界面。


所以 24 年 6 月份也是我们对海外第一次发布了我们的产品,也是第一次有了 AI 生成 UI 这一类的功能。这个功能在当时就是通过这么一种方式来做的路径。我们在做完之后也做了一些评分和测评,对应的是我们想赶超的几家竞品。



在这个阶段,因为大家最终生成的界面都差不多,是复杂度不太高的质量,所以我们那个时候更多还是关注我们的生成质量,包括一些狭隘的产品场景是不是能够达到大家的需求。于是我们自己内部就衍生出了一套专家打分的机制,这套机制其实看起来也没有那么 sexy,它其实非常简单,就是一个主观打分。


我们希望一个界面从产品经理的视角,从设计师的视角,以及从做它的 AI Scientist 的视角和做它的研发的视角,分别对这个界面的用户可用性和用户体验做一个打分。在这个过程中我们大概沉淀了一套简单的效果评测机制。


首先我觉得比较关键的就是评测集。你的 Benchmark 需要建立从用户的角度去评测的样本,所以这个样本不一定是一个非常海量的样本,关键是它的复杂性和典型性要充分。


第二件事情就是专家打分这个事情是一个看起来非常人力的工作,看起来没有那么多科技感,但实际上它在早期就是一个非常有效的评测 AI 效果的方式。


同时我觉得评测集需要一些更新机制,大概就是几个点,第一个点是我们整个 Baseline 需要多样性,这个多样性是由用户在实际的产品使用过程中,根据他想生成什么样类型的界面,我们去总结出来的。


第二个是评分的标准,这个标准实际上是我们在生成结果中根据用户对生成结果的评价来做的。最后一点是自动化,我们还是希望这件事情的评测能够更敏捷一点。



2 表达力的灵感涌现:技术革新,回到生成代码为先


接下来,技术在某一个节点发生了一些变化。



我们先来看第一张图,第一张图的背景是在我们这个领域出现了一个焦点事件。24 年 Figma 推出了 AI 生成 UI 的功能之后,有设计师在推特上说他们生成的界面是在侵权苹果的天气界面,以及大家在探讨 AI 生成的 UI 是否会趋于雷同。


大家了解了套模板的技术路线之后,其实你不难发现为什么最终会出现这样一个结果。因为在模板的驱动下,实际上用户有一个意图之后,你的界面是通过你的库里已有的模板映射和拼凑出来的,你的多样性是非常有限的。天气界面之所以非常雷同于苹果,可能就是因为 Figma 在做这件事情的背后,使用了同苹果非常类似的组件和模板。


我们在这个过程中也在不断尝试,到底有没有其他的路径是能够达成目标的。我们其实最念念不忘的技术路线还是由模型生成代码,再把代码转换到一个可编辑的界面。



这是在 Claude 3.5 Sonnet 发布之初时我们的测试结果。大家可能现在回头去看,觉得 AI 编程这个领域最大的变化是 3.5 的发布,但其实真正发生奇点变化的时间,对于我们这个领域大概是在 24 年 10 月份到 11 月份。



这就是某一天我们在测试后拿到的结果,这一天对于我来说记忆犹新,因为我当时的感受是非常震惊。因为你突然会发现,AI 能生成的 UI 的复杂度、多样性,一下子像一个奇点一样转变到这么一个程度了。


看左下角这张图,这是一个 3D 的 Map Editor,如果按照我们之前说的套模板路线的话,你几乎永远不可能穷尽枚举到这样一个领域,因为它肯定在优先级上是非常滞后的。也是在那个时候我们感受到,可能这个领域真正非常大的变革或机会,它真的来了。


我自己的一个感受是所有的新的产品,包括我们今天看到的 AI 产品,如果我们要说它本质是什么,它可能都是模型的能力外溢。套用我们这个章节的内容,我会觉得我们所有的 AI 产品在一开始会假设你会解决一个用户需求和问题,但可能一开始模型并没有办法非常好地匹配你这么一个需求,所以你只能通过产品化的方式来给一个相对狭窄领域的解决方案。


但当这个模型真正的能力达到了对应水平时,它有可能会外溢到你原来的方案能被更好地解决的成都,就像我们今天举的这个例子。


所以对于我们来说,我们意识到要永远用最高优先级的方式去看待新模型的评测。对于一个做 AI 产品的团队来说,它可能重要到昨天发布会发出来,你就得关心你什么时候能第一手搞到评测。如果你能第一手搞到评测,能不能在 1~2 天之内对这件事情有一个对应的结果。


比如说我们的步骤,第一步是我们刚才介绍的,我们会构建一些对应的 Baseline 评测集,这些评测集会有多样本的方式来检验一个模型在生成这件事情上的效果是怎样。


第二步是当一个新模型出来时,我们能迅速通过评测集把整个评测结果全部跑一遍。这件事情我们的经验是如果能够工程化,你可以工程化地去做;但很多时候其实这件事情不一定能工程化,比如说 Claude 3.7 刚出来的时候可能还没有接口,但你其实可以去 Claude 上用。还有一些模型,很多时候 API 都是滞后于它首次在 C 端发布的时点。所以当你不能够工程化的时候也不要等,你应该先拿到一个定性的结果,这些定性的结果可能是类似于这样的一些感受。



比如说我们去看 4o 同 Gemini 的生图到底是什么样的水平,比如说我们去看 Gemini 2.5 Pro 和 Claude 3.7 的对比到底在什么水平,包括我们今天正在研究 Claude 4 也是一样。


当你有了一个定性的发现和结论时,它会驱动团队对产品进一步的决策做一个对应的变化。当这个模型最终能达到公用的 API 可用、稳定的时候,大家再去考虑定量。


排序其实并不具备参考性,因为不同的领域和不同的产品大家在意的事情不一样。比如说对于妙多来说,我们第一在意的是质量和速度,它们是同等重要的。速度决定了我们这个产品的用户体验。


我们每一个生成对应的时间,对于用户来说是 3 分钟还是 1 分钟,或者 30 秒、20 秒,这个体验是差距很大的,所以速度对我们来说是一个非常重要的指标。


第二点是稳定性,最后才是成本,这是因为我们在做一个创新产品,但如果你本身是一个流量类的产品,比如说你做 AIGC,生图,有可能成本是你首要的考量因素,因为成本决定了你的 ROI 可以投放的最大范围,这个是需要根据业务来动态看对应的评测机制。

3 让 AI 理解设计系统:妙多对打造 AI 产品的反思


第三部分,我们先来简单介绍一下什么是设计系统。设计系统是 UI 领域的专有名词,在研发领域也有对应的词汇。我们今天看到的美团的界面是一套,之所以是一套是因为他们共用了一个设计系统。


所以我们之前走套模板路线的时候,其实是有一个特制的设计系统。这个时候我们同国内的一些大团队去聊的时候,他们其实也给了我们一个方案,说你们其实已经有一个特制的设计系统来做事情,你们能不能也根据我们的设计系统来做?



所以我们当时衍生出了一条比较明显的路线,就是我们能不能把对应大厂的不同的模板也都呈现出来,然后套他们的模板,这是一个工程量和人工量都非常大的路线,但它看起来又是可行的。


但我们其实最终没有选择这个路线,我们选择了另外一条路线。我们认为当整个生成模型的复杂度达到上限时,或许我们可以从另外一个角度去理解这样一件事情。



所以要让 AI 能够基于你业务的设计系统去生成界面,我觉得我们需要像人一样去理解。从一个人的角度去做对应的生产工作,你会发现人并不是在一个固定的逻辑下先掌握,之后再跟随对应的指令做事,而是人往往是先习得了一些事情。所以我们也在研究另外一件事情,是怎样让 AI 来更好地“习得”一个业务的设计系统。



比如说我们做了一些实验,发现有一个现象,当你用比较通用的大模型,告诉它一些常见的大众产品去做生成时,你发现它其实生成得还不错。



乍一看你还以为是 AIrbnb 出了一个外卖应用,但其实这就是我们用 Uber 的界面让它套了一下 Airbnb 的风格,它生成的一个结果。之所以它在这件事情上的遵循是能做得不错的,是因为大模型在整个预训练中还是接触了非常多这样的事情。


所以我们就有了一个新的技术路线,这个路线是通过把意图和设计系统本身的结合,让大模型去生成结果。



我们目前的阶段性成果是,我们已经可以控制非常多的主流大型系统,你可以在妙多中成套生成这些界面。我们还是果断选择了右边这样一套逻辑。



主要的原因是我们看待 AI 产品的思维模式产生了一个本质的变化,因为我们原来的逻辑是怎样更好地围绕你已有的技术去做产品,但我觉得 AI 的产品有一个比较大的区别是,其实你不知道技术在哪里,你也不知道明天的技术在哪,更重要的一件事情是你的预判。

4 妙多 AI 2.0:无壁垒?智能以外、上下文、演进的壳


在 AI 时代做产品,大家可能都会常说的两个词,一个叫无壁垒,也就是没有壁垒;第二个叫套壳,感觉一切的 AI 应用其实都是一个 wrapper。我们来聊一下我们对这个事情是什么样的理解,主要分三个方向。


第一,我觉得 AI 时代的产品更重要的一件事情是要关注 AI 也就是智能之外的事情。逻辑在于,你是把 AI 和你的产品结合起来的,你需要看产品和 AI 之间是否能产生一个很强的协同效应。


比如说我们自己的一个感受是如果交互能够快一倍,体验就能好 10 倍。比如说你要改一个配图时,你肯定不希望回到 GPT4o 中,重新把对应的文本全部输一遍,得到一张图再换回来。你希望是一个直接的交互,就在你对应的工作区,不需要太多的输入就把这件事情做完。


还有就是关注最后一公里。我们自己团队内部有一次在测试的一个例子,看起来没那么智能。我们当时让 Claude 3.7 基于我桌上的一个计算器的照片,把它还原成了一个计算器的界面,还原之后最难的一件事情是什么?



最难的一件事情是要把加号在界面上对应出来,看起来是非常简单的事情,然后我们很成熟的 AI 和提示词工程师,大概用了一两个小时,最终也没有把这个事情调到一个很好的状态。这里的原因在于你生成的前端中,其实很多是在 flex box 里的。


然后你不断用 AI 的方式告诉它再去调整,它都很难真正理解说你怎样把这件事情完全匹配到右边。你的产品如果能够提供一些价值去解决类似这样的最后一公里的问题,我觉得它是在基础模型层之外产生了一个非常大的价值。


第二件事情是上下文。最近在业内有一个更好的词来形容这个共识,叫做 memory。我觉得上下文是一个长期都被忽略的问题,主要原因在于我们都很关注模型和产品最终能达到什么样的效果,但实际上用户用的是你的产品,他们需要更多的是一些直觉的交互和体验。


我们以妙多为例,当你想修改一个 card 的时候,实际上你的上下文是非常多的。就像我同 AI 交互的时候,你会说请注意我的业务是什么样,然后最终请帮我生成一个什么样的界面。


当你生成第二个界面时,你又怕第一个界面时你的信息没有说清楚,可能又会复制粘贴过来改一改。但我们同人交流的时候,可能只会说小张你看一下我们最近的文档,然后把这个界面设计一下。这里最大的区别在于 AI 是否能够理解和读懂你业务对应的上下文信息。



第三点,我们要去看壳的本身是什么。大家都说现在的 AI 的很多应用是套壳,但我觉得这样的声音其实越来越少了,因为你会发现壳就是你的产品的壁垒之一。所以我们可以回归到一些更本质的东西。从妙多的角度,我们有一些比较朴素的拆分方式。


比如说界面是由图片、文字和图文的布局构成的,在这三个领域我们会思考我们的壳怎样建立得更厚。比如说设计行为的本质是生成、编辑、做原型,在这件事情上我们又能做什么?


比如说流程的本质是如何理解一个需求,如何做调研,如何做方案,我们会围绕这么一件事情去做。当你基于这些场景构建你的壳时,你就会发现实际上你的产品也会随着这个过程做得越来越厚重。


因此我们团队在过去的一年,在思想上做的一个最大的转变是我们原来比较信奉 Product-Technology Fit,产品与技术的 Fit,但我们这一年来最大的经验教训是可能这个思路在绝大部分时候不是那么可行。


你可能得做一件事情叫 Pre-Tech,你得在技术演进之前想好你的方案。如果你的预判是技术演进会随着你的方案变得越来越好,那么实际上你的产品化也会有对应的价值。但如果你的产品本身是随着技术在变化,你可能会失去价值,这个时候你可能要对这个方向保持警惕。

5 演绎游戏:关于未来 UI 工具的四个假设


最后一部分,我们来看一下我们对未来产品界面这个领域的一些看法。


我比较欣赏两类对 AI 软件这个行业的分类方式。第一个方式是木森的创始人童超在某一次演讲提出的一种分类。他觉得现在看到的 AI 产品就有两类,一类叫 AI+,一类叫 +AI。


所谓 + 就是我们原来说的 AI Native 的产品,这些产品上手都很炸裂,问题是完成最后一公里非常难。你会发现最后一公里决定了这个东西能不能拿到你现实的工作场景中去用。


另外一类叫 +AI,就是 AI 驱动,因为我们先有一个比较全面的产品设计工具,然后我们再加了这么一个 Copilot,你会发现编辑器既是你的壁垒——因为你有别人没有,你又做得很厚重,但它又是你的负担。因为相比那些第一类的产品,你的门槛会高很多。


第一类的产品可能交互只要一句话,整个 workflow 就已经转起来了,用户的第一感受会很好。但一个复杂编辑器的产品就没有那么性感。所以它们面临的一个问题是怎样从一个有用的工具变成一个好用的工具。



我欣赏的第二个分类方式是海外独角兽向凯奇的分类,他用了一个 2×2 的矩阵。横轴是你这个工具到底是对应大众还是专业群体,纵轴是你这个东西更接近于 Copilot 的形式还是 Agent 的形式,这两件事情不是绝对的,所以它们是一个光谱程度的问题。



如果你是在做右上角的工具,我们以一些 AI 编程辅助产品为例,你的第一感受就是很酷,因为你是大众人人都能用的,是技术平权。


然后这个东西又是一个偏向 Agent 的形式,你可能不需要做太多的事情,它可以帮你全部代理了。但你如果是在做左下角的产品,你可能会没那么酷,但大家又觉得好像确实在平常的工作中能用。


如果你直接做左上角的产品,我会觉得一个字就是难,这就是目前 Devin 在这个领域遇到的困境。你会发现 Devin 同 Cursor 其实选择了两个路径,但其实我认为它们最终是殊途同归的,因为你今天看 Cursor,虽然它早期是一个 Copilot,但它能完成的任务粒度越来越大时,你说它同 Agent 之间的边界是什么?其实也在变得很模糊。右下角我们看到了一些老的东西,比如说原来的一些传统工具加上了 AI。


虽然有人说未来不是线性外推的,但我觉得我们今天还是在这里做一个简单的演绎。那么对于整个 UI 的领域,我们到底会觉得未来会是什么样子?我大概提出了 4 种假设。


第一种假设是它仍然是有编辑器同 Copilot 的形式存在,后者是在帮助专业人群。


第二种假设是你的技术进步足够快,实际上你的编辑器已经被磨平了,不再重要。AI 能够做所有的事情,你的编辑器是 Figma 也还是别的谁,我生成的物料都可以在画布上直接绘制。


第三种假设是这种 for citizen 的产品能够逐步占领一个新的市场方向。


最后一种假设是有可能专业的产品设计工具这个历史长达 40 年的市场在未来不存在了,它会变成只是我们今天看到的一站式代码工具中的一个 feature 或者一个环节。



我们今天很难论证这四个假设最终到底哪个会成为主流,而且它们可能也不是非此即彼的,它可能会在市场上是细分的,对应不同的人群。


再分享一些我在流程这一块的感悟同洞察。


第一个感受是现在硅谷的 Startup 几乎没有设计师,很少有人用 Figma,研发一敌五。大家实际的工作就是在用 AI 编程的工具,用一个研发带来超高人效,用一个产品设计人员带来超高人效。


第二个感受是对于新起的项目,其实已经有 80% 的代码是由 AI Coding 创建的,这是一个真实的现象。因为大家没有技术债,所以更信奉让 AI 先生成的路径。


第三个感受是我们会发现现在国内的很多公司在出海,也有很多华人可能在海外读书,在那边的大厂工作,也有这边的公司去到那边的。我们会发现一个很有趣的现象是越来越多的华人就驻扎在了硅谷去打磨产品,但他们同时可能又会在国内招对应的研发团队。国内的研发红利仍然是存在的。


对应这些新的变化,我的感受是可能整个产品设计和研发领域的新逻辑,新范式,新 workflow 真的已经存在这里了,只是我们现在没有均匀分布地看到它。



最后分享我自己对我们产品的一些反思。


我觉得过去两年,我们大概反复纠结和做错的一些事情有这么几个。


第一个就是慢,我觉得慢的原因有很多,最主要的原因是总有一些新发现,总发现模型又能做一些什么,所以你总想做得更多。


第二点是大家很理性,总容易下一些判断,觉得模型不会怎样。


第三点是因为我们原来在做整个互联网业务,特别是移动互联网时代,确实想清楚未来是非常重要的,因为你想清楚不了你的未来,你可能在今天的做的事情没有意义。


但在今天,未来变得非常难预测,因为你没有办法过度预测技术的未来。第四件事情是我觉得我们的产品和设计不一定是没有用户视角的,但这里最值得谨慎的是,我们有过多的传统用户视角。传统用户视角意味着你没办法以今天新的 workflow 去看待一个事情,而容易束缚你原来很多事情的做法。


所以我们希望我们团队的产品人做产品的时候能更 ENTJ 一点。



首先我希望大家做产品是在 public 中做贡献,你还是要围绕你的用户的需求,你能积极地听到你用户的反馈。其实最好的是没有什么技巧,而是你用户今天告诉你想法,你明天给他做出来,然后问他这是不是你想要的。不要去憋大招,不要觉得我们半年之后有一个什么样的新版本,然后炸裂,一炮而红。


这个时代不是这样的,这个时代是每天每周和你的用户一起去做你的产品,持续发布和迭代的时代。


第二是动态看待我们今天所处的未来。创业也好,做一个新项目也好,你总要下注一个事情。我建议大家去下注模型的演进,因为很多东西你不一定要自己相信,当你发现很多人都相信时,这件事情大概率会实现。


就像我们今天看到硅谷的很多人都去相信一带多的 Agent 是研发未来的模式,这件事情就有无数的人、钱在这个领域为这个方向做新的探索。


第三,虽然这个年代想不清楚问题,我觉得更重要的是认知有效,你从中有一些收获,但经验就需要警惕。硅谷很多人其实是从大厂出来创业的,也有很多是已经在自己的领域获得成功的,几乎所有人都会同你说一句话是不要有过去的经验,因为你会发现过去的任何经验在今天看起来都是失效的。


最后一点就是少感受,当下就做。我们今天看到非常多优秀华人团队的产品,他们的团队的文化都是一个非常直的逻辑。


因为这个年代机会涌现得非常多,我们原来很怕做错,但今天你不做的代价是比做错更大的,因为你可以很快调整和迭代你的产品。

嘉宾介绍


张昊然,现任妙多副总裁,负责 Motiff 妙多的全球化产品运营。妙多定位 Figma 下一代设计工具,在 2024 年 6 月正式发布,已获得全球用户广泛使用和好评。曾是儿童数字内容行业领先者「斑马 App」早期产品经理,增长方向负责人,对 AI 产品设计研发流程有一定理解。曾带队打造了中国首个少儿 3D 互动百科数字内容「斑马百科」。


2025-08-12 18:335062

评论

发布
暂无评论

YashanDB TYPEOF函数

YashanDB

数据库

Milvus + n8n:通过分析GitHub文档打造垂直领域的智能问答

阿里云大数据AI技术

GitHub Milvus n8n 智能问答

北京市十一学校×火山引擎:全球AI少年齐聚北京,以代码会友

新消费日报

企业 IM 即时通讯BeeWorks

BeeWorks

即时通讯 IM 私有化部署

YashanDB TRUNC函数

YashanDB

数据库

YashanDB TREAT函数

YashanDB

数据库

无监督训练在NLP中的价值体现

qife122

自然语言处理 词元化

算力不开放,智能难平权:万亿参数时代,谁为开源模型托底?

脑极体

AI

哈尔滨等保测评中的 “神秘角色”:测评师

等保测评

通过自动化工具实现亚马逊云上资源标签管理

亚马逊云科技 (Amazon Web Services)

京东店铺所有商品API技术指南

tbapi

京东API 京东数据接口 京东店铺所有商品接口 京东店铺数据采集

深度剖析银狐APT攻击链,最终载荷竟是致命远控

塞讯科技

网络安全 信息技术 APT攻击 安全验证

家用机器人指令跟随训练新数据集发布

qife122

人工智能 数据集

京东图片搜索API秘籍!轻松获取相似商品数据

tbapi

京东API 京东图片搜索接口 京东拍立淘接口 京东图片搜索API 京东图片API

Prometheus 告警时为何无法获取现场值

巴辉特

Prometheus 监控告警 夜莺监控 运维监控 开源监控

华为阅读独家首发《金字塔在中国:古埃及文明大展炼成记》精品书

最新动态

黑龙江等保测评核心指标解析:技术安全与管理安全的双重保障

等保测评

从纳秒到毫秒的“时空之旅”:CPU是如何看待内存与硬盘的?

poemyang

计算机基础 IO模型 CPU Cache #存储

ClkLog埋点与用户行为分析系统2.0:架构升级性能跃迁,限时优惠速来体验

ClkLog

开源 用户行为分析 CDP 客户画像 埋点分析系统

YashanDB TRIM函数

YashanDB

数据库

YashanDB UNISTR函数

YashanDB

数据库

Pixi vs Conda:7 个让我切换到 Pixi 的理由

肩塔didi

人工智能 机器学习 GitHub

Awesome Claude Code 资源大全

qife122

开发工具 Claude-Code

GPT-5多模态与情境感知AI技术解析

qife122

人工智能 企业应用

ROPE 阅读苏神博客有感

antonio

工程师团队如何打造4K流媒体设备的创新技术

qife122

无线系统设计 天线创新

蒸馏大型语言模型并超越其性能

qife122

机器学习 模型蒸馏

黑龙江等保测评全流程解析:从定级到整改的完整指南

等保测评

大数据-65 Kafka 高级特性 Broker ISR 宕机重平衡 实测详解

武子康

Java 大数据 kafka 分布式 消息队列

私有化部署局域网 IM:BeeWorks支持内网使用

BeeWorks

即时通讯 IM 私有化部署

全前维护LED显示屏优势和选购指南

Dylan

LED显示屏 全彩LED显示屏 户外LED显示屏 led显示屏厂家 户内led显示屏

告别模板时代!妙多VP张昊然:生成式AI如何驱动UI设计的范式革命_AI&大模型_李忠良_InfoQ精选文章