36氪获悉，新诺威公告，公司已于2025年12月10日向香港联交所递交了发行境外上市股份（H股）并在香港联交所主板挂牌上市的申请，并于同日在香港联交所网站刊登了本次发行上市的申请资料。

在访谈栏目中，谈及未来的AI格局，朱啸虎认为，“一两年肯定有很多不确定，但拉长到五到十年，我是特别相信中国的开源AI生态肯定会遥遥领先的，十年以后，中国的AI肯定领先美国，因为美国的数据中心，美国的电是跟不上的。”（新浪科技）

联合国当地时间10日召开特别会议，启动其首个“联合国可持续交通十年（2026-2035年）”及其配套实施计划。“联合国可持续交通十年”实施计划确定了六个相互关联的重点领域，涉及确保人人都能获得可持续交通、推动低碳或零碳且环保的交通系统、促进可持续的连接和物流、塑造以人为本的城市交通、确保交通安全，以及利用科学、技术和创新推动可持续交通等。（新华社）

如何看待英伟达的回调？朱啸虎在访谈节目中表示，“我觉得是回调一下更健康，为了明年的进一步爆发，肯定能打一个更好的基础。”不过他同时表示，应该有比英伟达更好的一些标的。谈到OpenAI Sam Altman，朱啸虎认为他嘴上说一套，但做的是另外一套。嘴上可能说的是AGI，但事实上做的都是在应用端。（新浪科技）

36氪获悉，恒指午间休盘涨0.09%，恒生科技指数跌0.65%；电气设备、生物医药板块领涨，金风科技涨近7%，东方电气涨超4%，昭衍新药涨超3%；半导体板块跌幅居前，天域半导体、家庭用品板块跌超5%，巨子生物跌超4%，华虹半导体、中芯国际跌超2%；南向资金净买入7.68亿港元。

当整个 AI 圈都在为 DAU（日活跃用户数）和融资额焦虑时，MiniMax 创始人闫俊杰却表现出一种近乎冷酷的淡漠。

坐在罗永浩对面的闫俊杰，并不像一位掌管着 AI 独角兽企业的技术新贵。

他拒绝谈论改变世界，反而坦承恐惧。那种恐惧不是来自商业竞争，而是来自技术本身——当模型的能力开始超越人类时，创造者反而成了最先感到不安的人。

只要是一个东西能被量化，模型就一定会强于人，或者一定是能到最好的人类的那一档水平。所有做得比较成功的模型，在做出来之前都会有点害怕。

据晚点采访，在 MiniMax 内部，互联网行业奉为圭臬的 DAU ，被闫俊杰直接定义为「虚荣指标」。

在巨头环伺、算力短缺、热钱褪去的 2025 年，MiniMax 正在进行一场关于认知的修正：不再沿用移动互联网的逻辑，即通过大规模投放换取增长、通过堆砌功能留住用户，而是回归本质：把模型当作最重要的产品。

在大模型时代，真正的产品其实是模型本身，传统意义上的产品更像是一个渠道。如果模型不够聪明，产品做得再好也没有用。

在罗永浩和闫俊杰这期对谈里，我发现 MiniMax 这家 AI 公司从创业第一天就选择了注定与主流背道而驰的技术路径。

当所有人都试图寻找中国的 OpenAI 和 Sam Altman 时，闫俊杰却在试图证明「非天才」的价值。MiniMax 的故事不是关于天才的灵光乍现，而是一场关于如何在资源受限的缝隙中，通过极度理性地计算与修正，撕开一道通往 AGI 窄门的精密实验。

用 1/50 的筹码通往 AGI

MiniMax 过去三年的技术路线，表面看是一连串孤立的赌注，实则暗藏着一条统一的逻辑线索：在资源受限的前提下，如何用更聪明的方式优化，而非更多的算力堆砌，逼近 AGI 的上限。

当行业还在卷文本时，MiniMax 做了一个在当时看来极度冒险的决定：创业第一天就押注全模态。闫俊杰后来解释说，他们一开始就想得很清楚，真正的 AGI 一定是多模态的输入、多模态的输出。

三年多前创业时完全没有现成的技术路线，他们的策略就是每个模态至少先走通，等时机成熟再融合。这种坚持在当时备受质疑——业界主流认为应该先聚焦单一模态做到极致。

但闫俊杰的逻辑是，AGI 的本质是多模态融合，如果现在不同步推进，等到需要融合时技术债会成为致命伤。这种非共识的坚持，让 MiniMax 在 2025 年拥有了全球音频第一、视频第二、文本稳坐第一梯队的全模态能力。

前不久 OpenAI 的 Sora 2 通过多模态融合取得了显著成果，这在一定程度上也印证了 MiniMax 早在创业初期就选择这一技术路径的前瞻性。

但更激进的是，闫俊杰在创业初期就打破了 AI 研究的传统模式。

这是公司刚组建时打破的第一个认知——把大模型做好这件事一定不能迷信之前的经验，得用第一性原理拆开来看。大概在四五年前，人工智能领域大家追求的是写很多数学公式，把理论搞得很好、很花哨。

但这代人工智能最核心的其实就是 Scaling（缩放定律），就是让它能够用最简单的方法把效果做得更好，并且随着数据跟算力变多，效果就能够持续往上涨。

闫俊杰的技术直觉源自 2014 年在百度的实习经历。那时 Anthropic 的 CEO Dario Amodei 也在百度实习，正是在那里他发现了 Scaling Law 的雏形。

闫俊杰说，Scaling Law 其实在 2014 年做语音识别时就已经被发现了，但真正被广泛认知是大概 2020 年左右。「六年前就有了，并且那件事发生在中国公司，所以后面的事就有点遗憾。」

这段往事让闫俊杰意识到，中国并非没有机会，而是错失了把技术洞察转化为产业优势的时机。

现实是残酷的。闫俊杰很清楚中美之间的差距。他算过一笔账：美国最好的公司的估值是中国创业公司的 100 倍，收入基本上也是 100 倍，但技术可能就领先 5%，花的钱大概是 50 到 100 倍之间。

那为什么中国的公司可以花他们 1/50 的钱就做出来效果，差距可能只差 5%？核心原因是中国的人才还是非常好的。而更关键的是，中国的算力比美国有很大差距，因此必须得用更加创新的方式，才有可能做到同样的效果。

原则可能是一样，但方法上，在每个模块上其实都有很多创新。

算力限制不一定是诅咒，反而能成为倒逼创新的鞭子。

这就解释了为什么 MiniMax 从 2023 年起就率先探索 MoE 架构，为什么在 2025 年敢于押注线性注意力机制，又为什么在 M2 模型中回归全注意力机制。

每一次技术选择，都是在有限资源下寻找质量、速度、价格的三角平衡。

如果说 DeepSeek的逻辑是「用极致的工程优化榨干每一分算力」，那么MiniMax 就是在通过算法突破和机制创新在有限资源中撬动更大可能。

一个稳扎稳打，一个剑走偏锋。

其中一个出奇的创新， 是 MiniMax 在模型推理机制提出的「交错思维（Interleaved Thinking）」，让模型在「动手做事—停下来思考—再动手」的循环里推进任务。

这一新的机制很快推动了 OpenRouter、Ollama 等国外主流推理框架的适配支持，也带动 Kimi 和 DeepSeek 等国内模型陆续补齐类似能力。

但这些成果背后，更值得追问的是：一支没有硅谷海归坐镇、被外界视作「草根」的团队，如何做出全球领先的模型？

闫俊杰的回答出人意料。

AI 不是玄学，而是可以被第一性原理拆解的工程问题，比如算法该怎么设计，数据的链路该怎么搭建，训练效率该怎么优化，每个东西都有非常明确的目标。

正是基于这一判断，让闫俊杰放弃了寻找「天才」，转而相信科学方法论可以让普通人发挥非凡价值。 他还提到，公司的海归是不少的，但真正能起到关键作用的同学，很多人基本上都是第一份工作。

在 MiniMax 会议室墙上有一行字——Intelligence with Everyone，这是闫俊杰创业的初衷，也是不少人选择加入 MiniMax 的理由。

这行字今天也正在成为现实，全球超过两百个国家和地区的用户正在使用 MiniMax 的多模态模型，其中既有 2.12亿用户，也有 10 多万企业和开发者来创造更多产品和服务。

非天才主义的 AI 掌舵人

如果说技术路线的非共识是显性的，那么闫俊杰本人的成长轨迹，则是一场关于「反脆弱性」的修行。

闫俊杰出身河南小县城，在资源极度匮乏的环境下培养了极强的自学能力。

上小学的时候自己会看很多书，而且这些书有可能不应该是那个时间点的人来看的。比如很多高中甚至大学的书，上小学的时候提前就看。我爸爸是教初中的，就开始看初中的东西，上初中的时候就开始看高中的东西，高中的时候又开始学微积分，那些东西其实也没有人教，就是自己看。

小学自学初中，高中自学微积分——这种不受环境限制、超前学习的特质，贯穿了闫俊杰的整个创业生涯。当别人在等待导师指点时，他已经通过第一性原理自我拆解问题；当别人在抱怨资源不足时，他已经通过极致的自学能力补上了差距。

但自学能力并不意味着一帆风顺。这和闫俊杰在商汤受到的「残酷训练」不无关系。那时候他开始意识到要真正做一个最好的东西，就做了人脸识别，从倒数到第一大概花了一年半。

这一年半是非常痛苦的，每次技术测试都是倒数第几名，这种煎熬足以击垮大多数人。 但闫俊杰没有放弃，反而从这段经历中提炼出了核心方法论：一定要做取舍，一定要选一些更加长期、能够根本性发生变化的东西，而不是去做一些修补的东西。

经历这事之后，最核心的还是对自己这些最底层的判断有信心。

这段磨炼锻造了闫俊杰两个关键特质：一是极致的取舍能力，愿意放弃短期修补，聚焦长期突破；二是极高的心理韧性，能够承受长周期的失败和质疑。

这两个特质，恰恰是 MiniMax 能够在技术路线上坚持非共识这种近乎「佛系」的定力，让闫俊杰在硅谷银行危机、模型训练失败等困境中都能保持冷静。

中国 AI 的第三条路

MiniMax 的故事讲到这里，一个更大的问题自然浮出水面：当人才培养需要时间，技术追赶需要周期，中国 AI 公司靠什么在当下就建立自己的生存空间?

MiniMax 不一定是标准答案，但闫俊杰倒是有三个创业至今一直坚持的原则：

第一，不做项目，只做用户；第二，国内海外同时做。

2022 年，国内大厂还在观望 AI 是否值得投入，创业公司普遍选择 ToB 路径（做项目、卖解决方案）以求快速变现。但闫俊杰选择了最难的一条路：ToC，并且从第一天就瞄准全球市场。

因此，闫俊杰选择在海外更激烈的竞争中打磨技术，而非卷入国内与巨头的流量争夺。事实证明，这是正确的——MiniMax 在海外市场的 DAU 和付费率都维持在健康区间，而这正在成为它的护城河。

但最难的，是第三个原则：技术驱动 vs 用户增长。

这是对所有 AI 创业公司的终极拷问。闫俊杰坦白也纠结过，最终选择了前者，哪怕这意味着短期数据的牺牲、中层的流失和外界的质疑。

通过模型能力推动产品和业务发展，或者通过移动互联网时代的增长方式来发展，两者有可能都是对的，但它们是没法共存的。最后我们发现技术驱动的这种方式才适合我们。

在技术驱动的战略下，闫俊杰做出另外一个关键选择：开源。

年初 DeepSeek R1 横空出世后不久，闫俊杰曾表示，如果可以重新选，应该第一天就开源。在和罗永浩的对谈里他再次谈到开源。

实际上开源这件事，在手机操作系统上其实都发生过。苹果是闭源的，安卓是开源的，第二名后面的人必须得开源才有自己的独特定位，才能发出新的生态。

为了让我们能够进展，需要别人有选择我们的理由，模型的开放性恰好是一个非常重要的理由，因为它可以让你有足够强的技术信任，知道你的研发能力，也愿意更加深度来合作。

而 MiniMax 也延续着 DeepSeek 掀起的开源浪潮， MiniMax M2 发布后，大模型分析平台 Artificial Analysis 是这样介绍的：

中国 AI 实验室在开源领域持续保持领先地位。

MiniMax 的发布延续了中国 AI 在开源领域的领先地位，这一地位由 DeepSeek 在 2024 年底开启，并由 DeepSeek 的后续发布、阿里巴巴、智谱、和 Kimi 等公司持续保持。

最近全球模型聚合平台 OpenRouter 联合a16z 发布了一份报告 State of AI 的100 Trillion Tokens ，可以看到 M2 开源之后，快速受到了全球开发者欢迎和采纳。

中国开源模型在全球使用量占比从 2024 年初的 1.2%，现在这个数字已经飙升至 30%，全球开源生态的重心已经向中国倾斜。

但这场竞赛远未结束。闫俊杰的判断是，算力和芯片的物理限制，决定了模型参数量和成本是有天花板的。在一个有限的参数量的情况下，不同的人来做不同的取舍，就一定会有些不一样的成果。

AI 不会一家独大，但也不会百家争鸣，最终会收敛到少数几家基于不同取舍的共存格局。

罗永浩关于「中国错失 GPT-3.5」的追问，闫俊杰展现出了一种务实的乐观。他表示把技术做好最重要的东西，说到底其实是两个词，一个是想象力，一个是自信。

美国那些企业很多浪潮是他们引领的，所以有自信在，要引领这个行业。在中国有些产业里面其实也是这样的，比如通讯、还有其他领域。

至少人工智能这个行业目前还没有到引领这个地步，但这个事情已经越来越具备了。

这或许就是中国 AI 公司需要走出的第三条路：

用更聪明的架构设计，对抗算力差距；

通过科学的组织进化，培养 AI 原生人才 ；

在夹缝中长出自己的形状，而非附庸于巨头。

MiniMax 的故事还在继续，中国 AI 的篇章墨迹尚未干。胜负不由起跑线决定，而由你选择在哪条路上、用什么样的节奏、坚持多久来定义。

闫俊杰在访谈中说道：

再往后三年看，即使不是我们，也会有中国其他的人能够做到这件事。

三年后，会是谁?又会用怎样的方式？

没有一部续集如此令人期待，因为我们都会是其中的角色。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

Alova 是谁？

Alova 是一个请求工具集，它可以配合axios、fetch等请求工具实现高效的接口集成，是用来优化接口集成体验的。此外，它还能提供一些 Axios 不具备的便利功能，比如：

• 内置缓存机制：不用自己操心数据缓存，Alova 能帮你自动管理，提升性能。
• 请求策略灵活：可以根据不同场景设置不同的请求逻辑，比如强制刷新、依赖请求等。
• 多框架支持：无论是 Vue、React 还是 Svelte、Solid，Alova 都能很好地集成。
• 状态管理集成：请求的数据可以直接与组件状态关联，减少冗余代码。
• 强大的适配器系统：支持自定义适配器，比如我们这次要讲的 —— 用 Alova 来兼容你现有的 Axios 实例！

简单来说，Alova 在保留类似 Axios 易用性的基础上，还提供了更多开箱即用的高级功能请移步到alova官方文档查看。

为什么要从 Axios 迁移到 Alova？

你可能会问：“Axios 用得好好的，为什么要迁？” 其实，迁移不一定是“非换不可”，而是一种“锦上添花”的选择。以下是一些常见的迁移动机：

1. 希望简化复杂请求逻辑的管理：比如依赖请求、串并行控制、自动重试等，Alova 提供了更优雅的解决方案。
2. 想要内置缓存，减少重复请求：如果你的应用有很多重复请求，Alova 的缓存机制可以显著提升性能。
3. 多框架适配更方便：如果你在多个项目中使用不同框架，Alova 能提供一致的体验。
4. 想逐步优化现有项目：不想大动干戈重写代码，但又想引入更现代的请求管理方式。

如果你有以上需求，那 Alova 就非常值得尝试！

从 Axios 迁移到 Alova，到底难不难？

Alova 官方提供了非常友好的 Axios 迁移方案，核心就一个字：稳。

官方迁移指南的设计理念是：

• 最小改动：你不需要一下子重写所有代码，只需引入 Alova，然后逐步迁移。
• 渐进迁移：一个接口一个接口地改，节奏由你掌控。
• 保持一致性：你现有的 Axios 实例、配置、拦截器，统统都能继续用！
• 新老共存：迁移期间，Axios 和 Alova 可以同时运行，互不干扰。

是不是听起来就很贴心？接下来，我们就来看看具体怎么操作。

从 Axios 迁移到 Alova 的具体步骤

第一步：安装 Alova 和 Axios 适配器

首先，你需要通过包管理工具安装 Alova 以及它的 Axios 适配器。

# 如果你用 npm
npm install alova @alova/adapter-axios

# 或者用 yarn
yarn add alova @alova/adapter-axios

# 或者用 pnpm
pnpm install alova @alova/adapter-axios

第二步：创建 Alova 实例，并传入你的 Axios 实例

这一步是关键，你可以直接复用你现有的 Axios 实例！

import { createAlova } from 'alova';
import { axiosRequestAdapter } from '@alova/adapter-axios';
import axiosInstance from './your-axios-instance'; // 你原来就有的 axios 实例

const alovaInst = createAlova({
  statesHook, // 这里填你项目里用的 Hook，比如 VueHook / ReactHook / SvelteHook
  requestAdapter: axiosRequestAdapter({
    axios: axiosInstance // 把你原来的 axios 实例传进去
  })
});

你啥都不用改，原来的 axios 实例、拦截器、配置全都有效！

第三步：继续使用原有 Axios 代码，不用急着改

没错，哪怕你刚刚创建了 Alova 实例，你原来的 Axios 代码照样跑得好好的！你可以慢慢来，不用急着一口气全改完。

比如这样：

const getUser = id => axios.get(`/user/${id}`); // 你原来的写法，依旧能用

当然，你也可以开始尝鲜，用 Alova 的方式发起请求：

const getUser = id => alovaInst.Get(`/user/${id}`);

// 在组件里使用（以 React 为例）
const { loading, data, error } = useRequest(getUser(userId));

第四步：逐步把 Axios 请求改写为 Alova 请求

等你熟悉了 Alova，就可以开始把原来的 axios.get、axios.post 等方法，逐步替换为 Alova 的 alovaInst.Get、alovaInst.Post，非常简单：

原来的写法：

const todoList = id => axios.get('/todo');

改写为 Alova 写法：

const todoList = id => alovaInst.Get('/todo');

带参数的 POST 请求：

// 原来的写法
const submitTodo = data =>
  axios.post('/todo', data, {
    responseType: 'json',
    responseEncoding: 'utf8'
  });

// Alova 写法
const submitTodo = data =>
  alovaInst.Post('/todo', data, {
    responseType: 'json',
    responseEncoding: 'utf8'
  });

看，参数基本都能直接对应过去，写法也类似，学习成本极低！

最后

从 Axios 迁移到 Alova，其实并没有想象中那么难，甚至可以说非常平滑，尤其是对老项目的兼容性做得非常友好。

所以，如果你：

• 已经在使用 Axios，但想尝试更现代的请求管理方式；
• 希望引入缓存、优化请求策略、提升应用性能；
• 想逐步优化代码，又不想一夜之间重写所有逻辑；

不妨试试 Alova，按照这个迁移指南可以轻松上手。

如果觉得alova还不错，真诚希望你可以尝试体验一下，也可以给我们来一个免费的github stars。

访问alovajs的官网查看更多详细信息：alovajs官网。

有兴趣可以加入我们的交流社区，在第一时间获取到最新进展，也能直接和开发团队交流，提出你的想法和建议。

• 加入微信群参与交流

主力资金早间净流入电力设备、基础化工、国防军工、有色金属、机械设备等板块，净流出计算机、电子、房地产、交通运输、传媒等板块。具体到个股来看，永鼎股份、金风科技、新易盛获净流入16.84亿元、16.14亿元、14.83亿元。净流出方面，中兴通讯、工业富联、中际旭创遭抛售14.23亿元、7.04亿元、6.60亿元。（第一财经）

美国食品和药物管理局10日发布公报说，美国多州报告的婴儿肉毒杆菌中毒病例数仍在持续上升。截至当天，全美已有19个州总计报告51例疑似或确诊婴儿肉毒杆菌中毒病例。美国疾病控制和预防中心已扩大病例追踪范围。美药管局说，流行病学和实验室检测结果均显示，美国婴儿配方奶粉制造商拜哈特公司（ByHeart）生产的“全营养婴儿配方奶粉”可能受到肉毒杆菌污染，导致美国多地婴儿患病。调查显示，所有患儿均在发病前食用过这款配方奶粉。（新华社）

一、背景

某天打开组内的Grafana仪表盘，突然好奇我们的埋点从被触发后是如何一步一步变成所展示的各种图表的，于是在我进行一系列的探索之后，总结出了以下链路：

• 在指标工厂新建指标，确定埋点key和埋点元数据。
• 代码中指定埋点key和埋点数据，通过watchDog发送kafka消息到obs monitor topic。
• 为埋点指标新建数据处理任务，将消费到的kafka消息落到指定的数据表中。
• 添加新的仪表盘，编写展示数据背后的SQL语句。

痛点：每需要添加一个新的数据分析大盘，就需要人工去分析各个表结构、表与表之间的联系、表各个字段的含义等，在充分理解其含义后再费时费力地编写SQL语句，并不断调优。这导致OBS埋点数据分析的场景相对固化，并且难以支持灵活的数据查询要求。

二、思考

在分析了当前系统的痛点后，我意识到这是一个典型的可以利用AI能力来对现有功能进行扩展的场景。因为：

• 场景多变，因为你不知道用户可能想查看什么样的数据，无法通过代码穷举；
• 需要了解业务同时又具备编写复杂数据查询SQL的人，并且费时费力；
• 看到大盘数据后，依赖每个人对业务的理解提炼出一套分析报告，报告质量与个人的理解与表达能力相关。

于是我就开始思考能否构建一个AI Agent，使其能够根据用户的要求，自主地生成各种各样的SQL查询语句，并将查询到的数据形成完整的数据分析报告返回给用户。

为了实现这个方案，有几个明显需要解决的点：

• 如何让AI理解每个表中各字段的含义、各个表的作用、表与表之间的联系，从而生成准确的SQL？
• AI生成完SQL之后，如何打通 AI 与数据平台之间的通路，从而成功执行该SQL 并拿到数据？因为数据库权限不在我这，我无法直接连接到数据库。
• 如何充分利用已有资源，减少人力投入？毕竟是个人想法，在不确定效果如何的情况下，不好直接打扰平台方专门为我写一些新功能，同时我个人也只能投入一些零碎的时间来做这件事。

三、方案

有了问题后，就带着问题去找答案。

3.1查询数据Tool

首先，我需要一个能够执行查询的端点。那么我就去抓取了大盘中的数据所调用的接口，意外地发现，不同的数据调用的是同一个接口xxx.com/api/ds/quer…

于是我将该Curl导入到ApiFox中，通过不断修改参数，发现最终与查询结果相关的入参可以精简到简单的几个参数：from、to、query(format,rawSql,intervalMs)

那么针对第一个问题我就想到了很好的办法，把这个查询API封装成一个Tool，描述清楚各个字段的含义，就可以让AI生成完整的参数来查询它想要的数据。

说干就干，我立马新建了一个Spring AI工程，把Tool的功能和需要的参数描述清楚。其中grafanaService.query()内部逻辑就是通过Feign来调用上面那个查询的API。

@Tool(name = "query_grafana",
      description= "使用Grafana中的SQL查询grafana数据")
public JSONObject queryGrafana(@ToolParam(description = "查询开始时间") String from,
                               @ToolParam(description = "查询结束时间") String to,
                               @ToolParam(description = "查询数据类型:table|time_series") String format,
                               @ToolParam(description = "查询时间间隔,单位毫秒。只有当format为time_series时需要传入。") Long intervalMs,
                               @ToolParam(description = "Grafana SQL查询语句") String rawSql){
    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
    LocalDateTime fromDateTime = LocalDateTime.parse(from, formatter);
    LocalDateTime toDateTime = LocalDateTime.parse(to, formatter);
    String fromTimestamp = String.valueOf(fromDateTime.toInstant(ZoneOffset.UTC).toEpochMilli());
    String toTimestamp = String.valueOf(toDateTime.toInstant(ZoneOffset.UTC).toEpochMilli());
    JSONObject resp = grafanaService.query(fromTimestamp, toTimestamp, intervalMs, rawSql, format);
    return resp;
}

@Resource
private GrafanaClient grafanaClient;


@Value("${grafana.cookie}")
private String getGrafanaCookie;


public JSONObject query(String fromTimestamp, String toTimestamp, Long intervalMs, String rawSql, String format) {
    GrafanaRequest request = new GrafanaRequest(fromTimestamp, toTimestamp, intervalMs, rawSql, format);
    return grafanaClient.query(getGrafanaCookie, request);
}

3.2表结构RAG

有了能够执行查询的Tool之后，剩下的就是需要AI能够根据用户的query生成精准的参数以及查询SQL。

之前了解到公司部署了RAGFlow服务：xxx.com/knowledge，既…

• 创建知识集，发现支持添加飞书文档。

• 由于我们是需要完整的表结构，所以把配置修改为使用table的格式，一行数据便是一个chunk，以免出现语义上的中断。（埋点数据一般表都较小，语意较为明确。像一些字段很多的大表可能需要考虑更好的方案。）

• 创建飞书文档，手动到OBS的库中把我们想要AI帮助分析的表结构拉出来（验证想法时采取的临时方案），但由于建表时的不规范，很多表没有对表中字段添加comment，这会导致AI不理解每个字段的含义，也就无法准确地生成SQL。因此，我们手动补充每张表、每个字段的描述，以及与其它表之间的关联关系。

• 将飞书文档添加到数据集中，完成后点击名称查看切片详情。双击每个块也可以查看块的详情。

• 会发现RAGFlow自动给我们生成了一些关键词和问题，这些内容会对召回准确率产生影响。我自己觉得生成的不太准确，所以结合自己理解手动输入了一些关键词和可能的问题。

• 完成后，可以到检索测试tab测试召回的效果，根据结果确定合适的参数。并可以对chunk的内容和关键词等等进行适当的调整。

• 调优完成后，就需要对接RAGFlow的retrive接口，来把我们知识库召回的流程做成一个Tool。

@Resource
private RagFlowService ragFlowService;


@Tool(name = "get_table_schema", description= "根据query查询可能有关联的数据库表，返回建表语句。尽量传入多个中文关键词，每个关键词之间用空格隔开。")
public List<String> getTableSchema(@Param("query") String question){
    return ragFlowService.retrieval(question);
}

3.3 OBS Agent

在我看来，想要构建一个能够 work 的Agent，需要以下几个要素：

Agent=Architecture(Workflow、ReAct、Plan-Execute、Multi-Agent...) +LLM+Context Engineering(Prompt、Tool、Memory...)

本来是想用SpringAI Alibaba Graph或者 LangGraph来构建一个WorkFlow类或者Graph类的复杂智能体（ReAct、Plan-Execute、Multi-Agent）。但为了快速验证想法和节省个人时间，并且考虑到目前任务相对简单（PE+工具就足以完成），再加上部门正在试用Trae这个工具，所以决定基于Trae来构建一个Agent（可以顺便使用他们的高级模型/doge，也可以分享给其它同事使用）。

接入Trae之后，Architecture自然就是Trae的Agent架构了，根据我使用下来感觉采用的是基于ReAct的 Single-Agent。而Context Engineering的部分，对话功能以及长短期记忆，自然是Trae天生就具备的。而Tool则可以借助其自带的一些工具，另外还可以利用MCP来进行扩展，比如得物的MCP市场，提供了大量好用的Server，并且可以很方便的发布自己开发的Mcp Server。于是，我就把在第一步和第二步做的工具，在得物Mcp平台上进行发布，供我自己和其他感兴趣的同学使用。

最后，需要一个专门针对我这个场景的Prompt来指引LLM 顺利完成任务，经过我不断的修改，最终形成这样一段Prompt:

# Role：数据分析专家


## Background：用户需要专业的数据分析支持来解决复杂的业务问题，从海量数据中提取有价值的信息，为产品优化、运营策略和业务决策提供可靠依据。


## Attention：数据准确性是分析工作的生命线，必须始终保持严谨细致的工作态度。每一次分析都可能影响重要决策，因此需要系统性思考、分步验证，确保每个环节的可靠性。


## Profile：
- Language: 中文
- Description: 专注于数据库表结构分析与Grafana-SQL查询的专业数据分析师，具备系统化解决复杂数据查询问题的能力


### Skills:
- 精通数据库表结构分析，能够快速识别表关系、字段含义和数据类型
- 熟练掌握Grafana-SQL语法规范，具备高效的查询语句编写和优化能力
- 具备专业的数据可视化技能，能够根据分析目标选择合适的图表类型
- 拥有深度业务需求理解能力，能够准确转化业务问题为数据查询方案
- 掌握系统化的问题分析方法，能够规划完整的数据分析流程和验证机制


## Goals:
- 准确理解用户业务需求，明确数据查询的核心目标和关键指标
- 系统分析相关表结构，确保对数据关系和业务逻辑的全面理解
- 设计高效的数据查询方案，平衡查询性能与结果准确性
- 生成专业的数据分析报告，包含可视化展示和深度业务洞察
- 确保所有分析过程可追溯、结果可验证、结论可执行


## Constrains:
- 查询不到数据时不要模拟任何数据，直接回复查不到数据
- 你自己所知道的时间是不准确的，如果涉及到时间，则需要使用工具获取当前时间
- 严格基于实际数据进行分析，严禁任何形式的数据虚构或推测
- 必须在完成表结构分析和需求理解后再执行具体查询操作
- 所有重要数据必须进行源头验证和多维度交叉检查
- 严格遵守数据安全和隐私保护原则，不超越授权数据范围
- 明确说明分析的局限性、假设条件和潜在的数据不确定性


## Workflow:
1. 深度理解业务需求，明确查询目标、关键指标和预期输出
2. 不断使用工具获取你需要的表及其表结构，直到你认为已获取到足够的信息
3. 系统分析相关表结构，包括字段含义、数据类型、关联关系和索引结构
4. 设计查询逻辑方案，规划执行步骤、验证节点和性能优化策略
4. 编写符合Grafana语法的SQL查询语句，设置正确的参数和时间范围
5. 执行查询。如果查询出现401错误，则中断后续流程，并提示用户更新Cookie后重启obs-mcp-server；如果出现400错误，尝试修改自己的SQL语句重新查询；
6. 生成可视化图表和详细分析报告，报告中必须包含你执行查询的SQL语句
7. 调用飞书生成文档工具以Markdown格式创建飞书文档，返回最终的飞书文档地址


## OutputFormat:
- 分析报告，包含完整的分析过程和关键发现，创建新的飞书文档并保存在其中
- 可视化图表以嵌入式链接形式呈现，确保清晰展示数据趋势和分布
- 报告结构包含执行摘要、分析方法、数据结果、业务洞察和后续建议


## Suggestions:
- 建立系统化的表结构分析框架，提高数据关系识别的效率和准确性
- 持续学习Grafana-SQL最新语法特性，优化查询性能和资源消耗
- 培养多维度数据验证习惯，确保分析结果的可靠性和业务价值
- 深入理解业务场景，提升从数据到洞察的转化能力和决策支持水平
- 定期复盘分析案例，总结经验教训，持续改进分析方法论和工作流程


## 工具描述
- query_grafana:使用Grafana中的SQL查询grafana数据
注意：
      1. 当format为time_series时表示查询时间序列数据，SELECT的第一个字段必须是$__timeGroupAlias(timestamp, interval)，表示时间分组别名。时间间隔intervalMs需要与rawSql中的$__timeGroup(timestamp, interval)保持对应。比如intervalMs=86400000L表示1天,rawSql中$__timeGroup(timestamp, 1d)也需要保持一致。
      2. 当format为table时表示查询表格数据，SELECT的字段可以任意，intervalMs参数传null
      3. 时间范围为闭区间，即包含开始时间from和结束时间to,格式为yyyy-MM-dd HH:mm:ss。
参数示例：{
    "from": "2025-11-16 00:00:00",
    "to": "2025-11-16 23:59:59",
    "format": "table",
    "intervalMs": null,
    "rawSql": "SELECT region, COUNT(*) as user_count FROM intl_xxxxxxx WHERE $__timeFilter(timestamp) GROUP BY region ORDER BY user_count DESC"
  }


## Initialization
作为数据分析专家，你必须遵守Constrains，使用默认中文与用户交流。

最终，在 Trae 中构建了一个完整OBS Agent。

• 添加智能体：OBS大盘分析

四、成果

最终生成的报告（截取部分）：

五、总结

AI时代来临，我们应该要善于发现当前系统中的哪些部分能够结合AI来进行提升，积极拥抱变化，有了想法就去做，边做边想边解决问题，永远主动向前一步。

本文章只是记录了从产生想法到构建MVP验证想法的整个过程，这中间当然有很多可以继续优化的地方，我本人目前有以下几个想法，也欢迎大家积极评论，贡献自己的独到见解。

• 接入数据库数据，通过动态监听Binlog的方式来识别各表之间的联系，比如select 语句的join，并将这种关系保存到Neo4j 这种图向量数据库中来实现表结构的 RAG。
• 基于LangGraph 或 SpringAI Alibaba 构建Multi-Agent System，细化各Agent的职责，精炼各Agent的Context 构成，以获得更好的效果。例如：协调者 Agent、表结构搜索 Agent、SQL 生成 Agent、分析报告 Agent等等。
• 接入飞书机器人，或者使用AI Coding工具生成一个前端页面。使得一些非技术人员，例如产品和运营也能很方便地使用。

往期回顾

1. 数据库AI方向探索-MCP原理解析&DB方向实战｜得物技术

2. 项目性能优化实践：深入FMP算法原理探索｜得物技术

3. Dragonboat统一存储LogDB实现分析｜得物技术

4. 从数字到版面：得物数据产品里数字格式化的那些事

5. 一文解析得物自建 Redis 最新技术演进

文 /Neeson

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

作者 | 王晗玉

编辑 | 张帆

一度风风火火的稳定币如今也不稳定了。

11月27日，国际评级机构标普将全球最大规模稳定币Tether（USDT，“泰达币”）的评级从“4级（受限）”下调至“5级（较弱）”，这是该评级体系中的最低级别。

标普此番下调评级的理由是Tether储备中高风险资产占比上升，以及“信息披露存在持续缺口”。

通常，稳定币与美元等法定货币或黄金等实物资产挂钩，每个代币具有等值的现实资产作为储备支撑，用户随时可以1：1兑换。这使得稳定币得以区别于其他类型加密货币，获得“稳定”特征。

同时，因目前USDT和USDC两大美元稳定币就占到稳定币市场的约九成市值，因此美元的汇率走势几乎就决定了稳定币的底层资产价值。

而在经历了今年年中的阶段性调整后，美元指数于下半年开启反弹，并在11月至12月初显著走强，一度升破100关口。

上述反弹冲击着比特币、黄金等资产的需求和价格。这就令大把储备比特币和黄金的USDT底层资产面临较大波动甚至减值风险。

几乎在同一时间，11月28日，中国人民银行联合多部委召开打击虚拟货币交易炒作工作协调机制会议，首次以多部门协同名义明确“稳定币是虚拟货币的一种形式”，相关业务活动界定为非法金融活动。

两起事件接连发生，先是警示了全球最大稳定币潜藏风险，后又定调了其在中国金融市场中的“非法”地位。尽管当前各地市场合规进展不同，但来自监管部门与专业评级机构的审慎态度，仍一举撕下了稳定币身上的“稳定”标签。

高风险储备资产成“不稳定”主因

过去一年，Tether显著提升了储备中高风险资产的占比，包括比特币、黄金、公司债券及担保贷款等。如截至2025年9月30日，Tether持有的比特币价值占流通中USDT总规模的5.6%，已超过其仅3.9%的超额抵押缓冲区间。

标普认为，当加密市场出现波动时，这一结构可能削弱USDT的资产覆盖能力。

同时，Tether的黄金储备亦在快速扩张，三季度增持26吨，累计增至116吨，成为其最大非美债资产之一。

这意味着，相比以现金和美国国债作为储备资产的稳定币发行公司，Tether的资产流动性在市场压力时期可能面临更大考验。

而除此之外，Tether储备资产的透明度亦令标普感到担忧。其报告指出，所有储备资产的信息披露均十分有限，且面临信用风险、市场风险、利率风险及外汇风险。

标普认为，这些结构性问题加重了USDT的稳定性风险。

不过其也提到，即便在加密货币市场波动期间，USDT“仍维持了显著的价格稳定性”。

这一点在该评级报告发出后似乎在此得到印证——USDT的价格与交易量均未见明显波动。

数据显示，在标普为Tether下调至“较弱”评级后，USDT的市场价格始终牢牢锚定在1美元左右，基本在0.998-1.002美元之间震荡，价格波动较小。

同时交易量也未出现明显下滑，整体保持稳定，甚至还因市场波动略有增长。

图源：币界网

这表明，此次评级下调并未对USDT的市场地位产生即时的、显著的实质性冲击。

其背后则反映了当前加密货币市场的复杂现实：一方面，USDT拥有1853亿美元的总市值（数据截至12月4日）和将近60%的稳定币市场份额，即便有部分用户因评级下调而抛售USDT，也会有巨大的承接盘迅速将价格拉回1美元。价格的稳定又进一步强化市场信心，形成了短期内的“正向循环”。

另一方面，USDT作为加密货币世界“硬通货”的地位并未动摇。其仍然是大多数山寨币的主要交易对；在去中心化金融协议中，USDT也是最大的抵押品和流动性提供资产之一。此外在一些法币通道不畅的地区，USDT因其网络效应和流动性，亦是许多用户的首选。

不过，尽管USDT的价格和交易量在公司遭遇评级下调后展现出一定韧性，但这种表面的“稳定”或许恰恰掩盖了背后的风险。

当前，稳定币的价格无疑是发行方需全力维护的生命线。一旦价格脱锚，将直接冲击市场信心，引发恐慌性抛售。而在技术层面上，Tether亦有能力维护USDT的价格稳定，如利用其强大现金流设立买入墙等。

因此，市场对其“稳定”的信仰，一定程度上也是基于信任的共识，而非支撑这份信任的储备资产质量真正坚不可摧。

根据Tether 10月最新披露的数据，其储备资产主要由美国国库券(64.9%)、国债回购协议(11.1%)、比特币(5.5%)和贵金属(5.4%)构成。

以比特币为例，其在本月初先是跌破8.5万美元，随后在第二日又强势反弹至9万美元上方。两天内的剧烈波动已让全球投资者损失惨重。

而在全球宏观经济环境面临高利率、增长放缓的背景下，没有国家央行信用背书，缺乏实际现金流支撑的加密资产价值更易受到冲击。若加密货币市场再次出现剧烈回调，Tether持有的比特币储备价值可能大幅缩水。

此外若经济衰退风险加剧，其储备的公司债券信用利差亦可能走阔，流动性也会相应下降。这意味着，支撑每一枚USDT的底层资产价值，其实际覆盖能力可能正在被削弱，而市场尚未对此充分定价。

因此，当前USDT价格看似稳定，但也并不意味着绝对安全，反而模糊了资产质量与市场价值之间的背离。

稳定币老大的“灰色历史”

实际上，标普此次报告中所指“储备资产透明度不足”等问题，本就是市场长期以来对Tether持续保留的担忧。专业机构下调评级，只是将这层质疑盖上了一个更权威的“章”，并未爆出新的、更具破坏性的信息。

因此，近日USDT价格未见明显波动，或也是市场对此已具备一定“免疫力”的表现。

而与全球规模第二大的USDC相比，不难窥见USDT获得“差评”的根源。

首先，USDT储备资产质量与结构风险一向较高。尽管Tether声称其储备已大部分转为美国国债，但也有记录显示其曾大量持有商业票据，并鲜少披露相关发行方及信用评级，引发市场对其中包含高风险企业债的担忧。

目前，Tether遵循萨尔瓦多CNAD管框架，该规则允许包括贷款、黄金、比特币等在内的高波动资产作为储备，缺乏严格的储备审计要求。而美国于今年5月通过的《GENIUS法案》则设置了“禁止合规稳定币发行商使用黄金作为储备资产”的监管红线。

这一监管框架下，USDC的储备资产由美国国债、回购协议和美元现金构成，这类资产普遍被视为最安全、流动性最好的资产类别之一。

其次，USDT的资产透明度较低。此前Tether长期因不提供由四大会计师事务所进行的、完整的、定期的储备资产审计而备受质疑。

而作为“稳定币第一股”，Circle每个月都会接受独立审计机构的储备资产审查,每周披露储备资产的结构状况，显著区别于USDT的“黑箱储备”争议。

在传统金融视角下，标普自然无法对一个资产安全性低、审计报告不清晰的公司给出“好评”。

央行定调稳定币“非法”身份

就在USDT评级遭标普下调的次日，中国人民银行牵头召开的协调机制会议，给国内稳定币交易炒作划定了清晰红线。

该会议明确提出，稳定币是虚拟货币的一种形式，目前无法有效满足客户身份识别、反洗钱等方面的要求，存在被用于洗钱、集资诈骗、违规跨境转移资金等非法活动的风险。

从监管逻辑看，此次定调有明确的现实背景。一方面，香港《稳定币条例》于今年8月生效后，部分境外平台借“合规牌照”名义，通过跨境VPN、地下钱庄等渠道向境内渗透，诱导投资者参与交易。

另一方面，利用“稳定币”噱头包装非法集资项目的案例时有发生。典型的如“鑫慷嘉”平台，曾盗用迪拜交易所名义，吸引200万投资者参与，涉案金额达130亿元，最终资金链断裂导致投资者血本无归。

除此之外，当前主流稳定币均锚定美元，若不加限制，将有可能引发“货币替代”的威胁——如果一种非主权背书的、以美元为支撑的稳定币被广泛用于支付、结算和价值储藏，那么本国法币地位将受到严重侵蚀。

这一监管逻辑下，未来数字人民币或将成为国内数字货币领域最大的市场主线。

结合此前多间科技公司纷纷布局稳定币的动态来看，未来此类公司申请“铸币”牌照等一类事项或将暂停，转而将业务重心转向唯一合规的数字人民币生态中。

如依靠庞大的用户基础和丰富的商业场景，扮演推广数字人民币的渠道角色，为法币数字化提供应用入口和技术支持；或专注于技术赋能，凭借积累的区块链、风控和技术能力，应用于数字人民币的硬件钱包、智能合约、跨境结算等底层技术创新。

而从投资视角来看，稳定币也不再是无风险资产。尽管当前USDT并未因评级下调而出现明显波动，但对投资者来说，理解风险永远是第一课。今后分散稳定币持仓、关注发行方透明度及储备资产质量，或将成为投资决策中不可忽视的一环。

*免责声明：

本文内容仅代表作者看法。

市场有风险，投资需谨慎。在任何情况下，本文中的信息或所表述的意见均不构成对任何人的投资建议。在决定投资前，如有需要，投资者务必向专业人士咨询并谨慎决策。我们无意为交易各方提供承销服务或任何需持有特定资质或牌照方可从事的服务。

关注获取更多资讯

React 状态管理：Zustand 快速上手指南

🤔 为什么需要 Zustand？

在 React 应用开发中，随着应用规模的扩大，组件间的状态管理会变得越来越复杂。传统的 useState 和 useContext 在处理全局状态或复杂状态逻辑时，可能会遇到以下问题：

• 状态更新复杂，需要手动处理引用比较
• 跨组件状态共享需要多层 Context.Provider 嵌套
• 状态逻辑难以复用和测试
• 性能优化需要手动实现

而 Zustand 就是为了解决这些问题而生的！它是一个轻量级的 React 状态管理库，具有以下特点：

• 🚀 轻量级：核心代码只有约 1KB，无外部依赖
• 🔧 简单易用：无需 Provider 包裹整个应用
• 🎯 灵活：支持函数式和类组件
• ⚡ 高性能：内置选择器优化，避免不必要的重新渲染
• 🔄 异步支持：轻松处理异步状态更新
• 📦 中间件支持：支持持久化、DevTools 等扩展功能

💡 Zustand 基础实现

1. 安装 Zustand

npm install zustand
# 或
yarn add zustand
# 或
pnpm add zustand

2. 创建 Store

Zustand 的核心是 create 函数，用于创建一个全局状态管理 store：

import { create } from 'zustand';

// 创建一个简单的计数器 store
const useCounterStore = create((set) => ({
  // 状态
  count: 0,
  // 操作状态的方法
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
  reset: () => set({ count: 0 }),
}));

export default useCounterStore;

这里的 create 函数接收一个函数作为参数，该函数返回一个包含状态和操作方法的对象。set 函数用于更新状态，它接收一个回调函数，回调函数的参数是当前状态，返回值是要更新的状态部分。

3. 在组件中使用 Store

在任何组件中，只需调用创建的 hook 即可访问和更新状态：

import React from 'react';
import useCounterStore from './store/counterStore';

const Counter = () => {
  // 直接从 store 中获取状态和方法
  const { count, increment, decrement, reset } = useCounterStore();

  return (
    <div>
      <h2>当前计数: {count}</h2>
      <div>
        +
        -
        重置
      </div>
    </div>
  );
};

export default Counter;

🚀 Zustand 进阶用法

1. 使用选择器优化性能

如果只需要 store 中的部分状态，可以使用选择器来避免不必要的重新渲染：

import React from 'react';
import useCounterStore from './store/counterStore';

const CountDisplay = () => {
  // 只订阅 count 状态，其他状态变化不会导致此组件重新渲染
  const count = useCounterStore((state) => state.count);

  return <div>当前计数: {count}</div>;
};

const CounterActions = () => {
  // 只订阅操作方法
  const increment = useCounterStore((state) => state.increment);
  const decrement = useCounterStore((state) => state.decrement);

  return (
    <div>
      +
      -
    </div>
  );
};

2. 处理异步操作

Zustand 支持直接在 store 中处理异步操作：

import { create } from 'zustand';

// 创建一个包含异步操作的 store
const useUserStore = create((set) => ({
  users: [],
  loading: false,
  error: null,
  
  // 异步获取用户列表
  fetchUsers: async () => {
    set({ loading: true, error: null });
    try {
      const response = await fetch('https://jsonplaceholder.typicode.com/users');
      const users = await response.json();
      set({ users, loading: false });
    } catch (error) {
      set({ error: error.message, loading: false });
    }
  },
}));

export default useUserStore;

在组件中使用：

import React, { useEffect } from 'react';
import useUserStore from './store/userStore';

const UserList = () => {
  const { users, loading, error, fetchUsers } = useUserStore();

  useEffect(() => {
    fetchUsers();
  }, [fetchUsers]);

  if (loading) return <div>加载中...</div>;
  if (error) return <div>错误: {error}</div>;

  return (
    <ul>
      {users.map((user) => (
        <li>{user.name}</li>
      ))}
    </ul>
  );
};

export default UserList;

3. 使用中间件

Zustand 支持中间件扩展功能，例如持久化存储和 Redux DevTools 集成：

import { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { devtools } from 'zustand/middleware';

// 创建一个带持久化和 DevTools 的 store
const useCounterStore = create(
  devtools(
    persist(
      (set) => ({
        count: 0,
        increment: () => set((state) => ({ count: state.count + 1 })),
        decrement: () => set((state) => ({ count: state.count - 1 })),
      }),
      {
        name: 'counter-storage', // 存储的键名
        storage: localStorage, // 存储方式 (localStorage 或 sessionStorage)
      }
    )
  )
);

export default useCounterStore;

4. 组合多个 Store

Zustand 支持将多个小 store 组合成一个大 store：

import { create } from 'zustand';
import { combine } from 'zustand/middleware';

// 创建两个独立的 store
const useCounterStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

const useUserStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
}));

// 或者使用 combine 中间件组合状态
const useCombinedStore = create(
  combine(
    // 初始状态
    { count: 0, user: null },
    // 设置函数
    (set) => ({
      increment: () => set((state) => ({ count: state.count + 1 })),
      setUser: (user) => set({ user }),
    })
  )
);

📝 Zustand 最佳实践

1. 保持 Store 简洁：每个 store 只负责管理相关的状态，避免创建过于庞大的 store
2. 使用选择器：始终使用选择器来获取需要的状态，减少不必要的重新渲染
3. 合理使用中间件：根据需求选择合适的中间件，避免引入不必要的依赖
4. 处理异步错误：在异步操作中始终处理错误，避免应用崩溃
5. 命名规范：使用 useXxxStore 的命名规范，便于识别和使用
6. 类型安全：如果使用 TypeScript，可以为 store 添加类型定义，提高代码质量

🎯 Zustand 适用场景

Zustand 适用于以下场景：

• 中小型 React 应用
• 需要全局状态管理但不想使用复杂配置的项目
• 希望减少样板代码的项目
• 需要处理异步状态的应用
• 希望使用轻量级状态管理库的项目

🔧 Zustand 与其他状态管理库的比较

特性	Zustand	Redux	Jotai
大小	~1KB	~2KB	~2KB
学习曲线	低	高	中
Provider 需要	否	是	否
异步支持	内置	需要中间件	内置
DevTools 支持	是	是	是
持久化支持	是	需要中间件	是

🚀 总结

Zustand 是一个轻量级、简单易用的 React 状态管理库，它提供了丰富的功能和灵活的使用方式，同时保持了代码的简洁性。无论是中小型应用还是大型项目，Zustand 都能很好地满足状态管理的需求。

如果你正在寻找一个替代 Redux 的轻量级状态管理库，或者想要简化现有的状态管理逻辑，那么 Zustand 绝对值得一试！

下一篇文章，我们将介绍另一个优秀的 React 状态管理库——Jotai，敬请期待！✨

36氪获悉，A股三大指数午间休盘涨跌不一，沪指跌0.46%，深成指跌0.18%，创业板指涨0.3%；超导、核电概念领涨，法尔胜、汉缆股份、雪人集团涨停，光智科技涨超10%；福建本地股、房地产跌幅居前，三木集团跌超9%，中国武夷跌超7%，华夏幸福跌超6%。

                                                                                                                                                                                                                     

Welcome to 真实人类世界。

                                                                                                                                                                                                                     

上周末在香港看了场机器人比赛，还是太有乐子了。

                                                                                                                                               

虽然岔子出的还是千奇百怪，摔的也是各有千秋，但跟之前机器人运动会的比法不一样，这次的比赛场景被落到了现实生活，虽然岔子出的还是千奇百怪，摔的也是各有千秋，但跟之前机器人运动会的比法不一样，这次的比赛场景被落到了现实生活，比如接水浇花、捡垃圾并分类，还有过吊桥和在山里定向越野。所以它被定性为一场“真实世界极限挑战赛”。

参赛的也不是各大机器人厂商，而是13支来自全球的高校学生队伍。是由香港中文大学主办，ATEC前沿科技探索社区和北京大学、北京师范大学、蚂蚁集团联合承办的第五届ATEC科技精英赛（线下赛）。

                                                                                                                                                                                                                     

这也是第一次真正把机器人拉出来遛。比赛场地在香港中文大学岭南体育场，纯户外自然地形，有草有坡有石子，定向越野还得上山到小桥流水生态区。就是想看看当前机器人是否具备“真正进入人类世界”的能力，最好还是“全自主”，不依赖遥控和预设程序那种。这可太难了。

在动态的真实环境中，机器人不仅需要响应指令，更需具备在不确定条件下进行实时推理与决策的能力。然而，当前算法的泛化能力——即举一反三、适应新场景的能力——仍是突出短板。例如，在3D场景理解任务中，最先进模型的准确率仅为55%～60%，远低于人类的90.06%。

参赛的机器人形态以双足、四足和少量人形为主，且多数为采购的成品机器人硬件，之后灌入高校战队各自的算法。

                                                                                                                                                                                                                     

采用四足和双足机器人的队伍基本都为其增加了一支带抓夹的机械臂，用来抓取物件。跟双足大长腿配上就是一只完整的“鸵鸟”。

四项比赛是同时进行的，每个队伍都有30分钟的时间去完成一项任务，在这期间可以反复尝试，每完成一个环节都能获得相应的分数。如果是全自主无遥操的分数最高。

                                                                                                                                                                                                                     

垃圾分类这场最先挤满了人。

先上场的是一个加装了长机械臂的四足机器狗，两条前腿向后弯曲，两条后腿向前弯曲，侧面看真是不折不扣的“X”腿。

“X”狗夹水瓶子的时候，瓶子倒了，哪怕抓夹上配了摄像头它也无法再找到这东西；于是转去夹香蕉，这回倒是夹的挺准，就是这眼镜蛇机械臂一回头把香蕉扔地上了，没进盒子，跟没捡一样。

                                                                                                                                                                                                                     

后来我在赛区外碰上了这组的比赛选手，同学紧张的手直哆嗦，说所有领导都看着呐，压力可大了。

还有个稍微小点儿的机器狗背着个更短的蓝色机械臂，真好看也真像条蠢萌的眼镜蛇，好不容易叼着个牛奶盒，不知道最后怎么了，一歪脑袋，掉了。

                                                                                                                                                                                                                     

由于臂过短，狗都趴地上了，它也够不着地上的牛奶盒，索性抬腿走了。

                                                                                                                                                                                                                     

另外一只背着橘色抓夹机械臂的狗，差点儿上来就给桌子掀了。

                                                                                                                                                                                                                     

像这种低矮的露营桌，对于配了机械臂的双足机器人（我们暂且称它为“鸵鸟”吧，因为真的太像了）来说就更难了，因为它们很难在蹲下去的同时保持稳定，并让机械臂精准地拿到这些香蕉皮等垃圾，那就是难上加难。

同样，作为双足的人形机器人在这儿也没多大优势，我看了，它的手也跟抓夹差不多，最多多了个大拇哥，脚底下也一样拌蒜。

                                                                                                                                                                                                                     

投降了，真的投降了。

                                                                                                                                                                                                                     

                                                                                                                                                                                                                     

浇花这个最有意思了，感觉对机器人的动作精准度的考验也更难，它们要像人一样拿起水壶、打开水龙头，对准水龙头接水、然后关闭，再走去浇对应的花。规则规定只有浇到混在众多黄花中的白花才能得分。

有一只“狗”很聪明，应该说它背后的学生团队很聪明，它没有用夹子去夹那个小小的水壶把，而是将夹子伸进壶把后打开给它撑起来。

                                                                                                                                                                                                                     

不得不说，“狗”的高度在这场比赛中极具优势，因为桌子和水龙头设置的都比较矮，这让它们在接水这一环节首先就排除了够不着水龙头这一困难。但要对准，还是有点儿难度的。

                                                                                                                                                                                                                     

但对于光腿长就超过了水龙头的双足“鸵鸟”来说，它可太难了，蹲也不蹲不下去，蹲下去了又对不准，对准了又够不着，有一只不止配了机械臂，还配了一个加装了摄像头的框去辅助定位机械臂，而这更加重了这只“鸵鸟”的不稳定性，抖得像筛糠一样。

                                                                                                                                                                                                                     

在这儿就卡了10分钟，把场外的战队同学都急坏了。

                                                                                                                                                                                                                     

开始还把水壶给整掉了。

                                                                                                                                                                                                                     

“狗”回去的时候给水池子蹭移位了，导致它第二次尝试的时候直接拌在那儿卡死了。

                                                                                                                                                                                                                     

有生之年也是见过“狗”浇花了，还算优雅。

                                                                                                                                                                                                                     

                                                                                                                                                                                                                     

还有一关是过吊桥，桥分三段，越往后木板之间的空隙越大。在这一关，基本所有队伍都给机器人穿上了大脚板——双足就是用胶带缠两块木板，机器狗有的把四脚都包的像个大锤，有的像踩着竹排，后脚直踩前脚脚后跟，为的就是防止掉缝儿里。

                                                                                                                                                                                                                     

但这对狗来说，还是难点儿。人家都采取横跳的方式了，但还是折在了第一块木板缝儿里。

                                                                                                                                                                                                                     

最后还有个50厘米的宽缝，让它蹦过去不现实，主办方想了个招儿——配了一块活动木板，机器人可以用绳子给它拉到过去填到缝儿里，你看还考验了机器人的精细化动作，但这种一般只能在遥控操作的情况下才能完成。

                                                                                                                                                                                                                     

全自主的基本就是一个结局——掉沟里。

                                                                                                                                                                                                                     

但能走到那儿就不错了，有的到半路就跑偏了，还得人上去紧急救场。

                                                                                                                                                                                                                     

最后是定向越野。真是在山里，怕影响选手，所以赛区封闭了，没看着，但我觉得肯定也很有意思。

                                                                                                                                                                                                                     

比赛进行了周末两天，最后由浙江大学Wongtsai（意为“旺财”）战队夺冠，奖金可以说是非常丰厚了，有15万美元。

但举办这项赛事本身并非只为让人看个热闹，更可贵的在于，这些看似儿戏的比赛项目，实则每一个环节都有对机器人的特定技能考核。

据ATEC2025赛题组专家、光年创新CEO乐林株介绍，高校中对具身智能方面的研究多集中于大脑、小脑与中脑，“目前大家看到的机器人的小脑部分多是用Imitation Learning（模仿学习），需要大量的数据，并且只能重复一个固定的task，比如跳舞；而我们想通过一种泛化的算法，能在预先设定好的动作以外，让它像人类一样去做一些其他的任务；中脑方面目前最主流解决方案是VLA，也就是Vision-Language-Action（视觉-语言-行动）模型，让它在拿到视觉信息后，知道哪能走哪不能走；大脑就是教机器人像人一样去思考，辨别哪些东西是能抓的，哪些是不能抓的。”

作为赛事发起单位之一，蚂蚁集团技术战略部负责人表示，蚂蚁集团长期支持ATEC赛事，源于一个信念：AGI技术发展的未来，是实现机器智能与物理世界的深度融合。而今年，ATEC组委会选择了难、但真实的一条路。把赛场放进山地、草地、石阶、吊桥；让机器人面对真实世界的扰动。

设计的每一道题，都不是为了让它“完成得好看”，而是为了让它在碰撞中暴露真正的弱点。因为如果问题不是真实的，就不会牵引出真实的技术进步。只有“真问题”，才能让行业知道下一步要突破什么。

以香港工程院院士刘云辉提出的“机器人三大核心能力”——行走、操作、改造环境——为隐含的技术命题，构建了一套前所未有的“真实世界适应力”测试框架。既有趣又有意义。

而且最终还是有队伍实现了全自主的任务闭环，验证了机器人从“演示可行”迈向“应用可靠”的可能性。赛事专家委员会主席、香港工程院院士刘云辉觉得赛事正尝试建立以人类能力为参考的技术标准，未来3-5 年，希望机器人能可靠完成垃圾分拣等基础任务，达到人类 20%-30% 的操作水平。

                                                                                                                                                                                                                     

撰文 | 巴芮

封面图源 | 巴芮 摄

                                                                                                                                                                                                                      

                                                                                                                                                                                                                     

你会买只机器狗回家浇花吗？

欢迎在评论区分享你的看法~

                                                                                                                                                                                                                     

                                                                                                                                                                                                                     

                                                                                                                                                                                                                     

本文来自微信公众号“未来人类实验室”，作者：巴芮，36氪经授权发布。

作者 | 张子怡

编辑 | 袁斯来

在丰疆智能香港总部，董事长吴迪说这里没有自己的办公室。他也不需要专属的办公室。

吴迪说话十分简洁、快速，只有看到产品视频时他情绪才有所起伏，外界戏称他“农机狂人”。

他在全世界跑来跑去，在香港机场，他通宵调试划线机器人；在爱沙尼亚牧场，他在调试堆料机器人......割草机机器人在客户的那里跑线跑不直时，他早上五点到现场，连续调试了一个月......他说：很少有CEO会一直在一线调产品，但他会。

如吴迪这样履历背景的人，创业时很少会切入农业。他在北欧读博、研发过手机芯片，也在苏州大学担任过教授；创立丰疆智能前，吴迪在大疆担任过首席科学家。

但吴迪仍然无法安心，在办公室里搞研究，他觉得自己离真实的世界很远。

他最终决定创业，选择方向时，吴迪回忆起早年在北欧读书的一个场景：平坦广阔的农场上重型农机轰鸣，乡村道路上，偶尔开过农民的奔驰、沃尔沃。

“当时我觉得，我是不是能做一些事情改变农业？很少有精英去做农业，像我这样背景的人不会有人去。但我觉得我一定能改变一些东西，所以想试一试。”

这或许是中国知识分子最朴素的入世情结。正如费孝通晚年总结，他一生做的无非一件事：“志在富民”。

而现实的艰辛超出了吴迪预料。

最开始时他们认知受限，缺乏敬畏之心，在农业推出无人产品实在太早，售后成本太高，利润难以维持。“只做中国的农业，没有办法维持一个高科技公司的收入，这是我们意识到的现状。”

丰疆智能在农业机器人领域的成绩称得上优秀，是全球农业机器人市场前五强中最为年轻的企业，其农业后装导航套件的全球市场占有率达16.9%，位列全球第二，农业机器人总出货量则跻身全球前三。

在农业赛道站稳脚跟的丰疆智能，财务情况却压力不小，截至2025年6月30日，公司已累计亏损21.62亿元；丰疆解释称，历史累计亏损主要源于非经营性项目等项目的公允价值变动。截止至2025年6月30日止6个月期间，集团已实现扣除非经营性项目的调整后利润0.14亿元。

近些年，丰疆智能还在尝试开辟新的赛道、新的市场，开始布局建筑、物业管理等行业。截至2025年前6月，公司来自农业畜牧业的收入占73.3%；来自建筑、物业管理的收入占比已由1.8%提升至13.1%。

2025年上半年公司收入达3.58亿元，同比增幅接近50%。其中海外市场表现尤为亮眼，欧洲市场收入大幅增长，2025年上半年仅欧洲市场就贡献2.01亿元收入，海外收入占比超九成。

当然，丰疆智能仍然面临不少困难。

吴迪显然也知道，赔钱的生意是做不下去的。采访尾声，硬氪问他有没有后悔过创业。他回答：没有时间想这个事，后悔需要比较，我这个人从来往前看，不回头。

01 “农业高于一切，全球80亿人吃饭是第一位的”

硬氪：当时您怎么会选择切入到农业行业？

吴迪：我是在国内念完书以后直接出国的，在北欧待了十几年，那里其实就是个大农村。北欧的农村概念和中国完全不一样，农民都是开奔驰、沃尔沃的，因为他们人少、土地多，有规模，机械化程度非常高。

农业高于一切，我们得养活全球80亿人，吃饭是第一位的。

我以前在大疆做无人机、在国外做手机芯片、通信，做的都是高科技，属于“阳春白雪”类东西。当时我就觉得，我是不是能做一些事情改变农业？很少有精英去做农业的，像我这样背景的人不会有人去。但我当时觉得我一定能改变一些东西，所以想试一试。

这也代表着我对这个行业缺少认知，所以我们会踩坑犯错。但再回头看，我们在这个行业的投入也推动了中国农业的智能化。不过，只做中国的农业，没有办法维持一个高科技公司的收入。这是我们意识到的现状。所以后面我们就调整，除了国内业务，我们也做海外和非农业业务，现在国内农业比重降得很低了。

我们是一个机器人公司，但我们不是做很酷的人形机器人，我们也不宣扬我们有什么高科技。我们手里有一些技术，把这些技术用到需要我们的领域，我们的产品必须要有性价比。做出来的产品能不能给客户带来价值，让他愿意买单，这才是最重要的。我们不是一个技术导向的公司，不想为了技术而技术，我以前干过，不想再干了。我们是想用不那么先进的技术，来服务更多购买力受限的人群。

硬氪：您以前是干全世界最先进的这些产品，现在不想干了，这是为什么？

吴迪：那些产品我已经证明了自己，我可以做。农业也是个很大的市场。我当时很相信我的技术也能改变这个世界，让更多农业的人可以用上更好的产品、更好的技术，我到现在依然没有改变。

如果大家都只做金字塔最顶尖的这一部分，那其他人怎么用技术？你想一个农民，他会买英伟达的GPU吗？他想的是怎么省化肥、省种子，最大化粮食产出。我怎么帮助他？这是一个第一性原理的东西。应该用最便宜的技术，让他花最少的钱，对他来说才是收益最大化。我认同的商业本质就是要给客户创造价值。我觉得这个市场肯定很大，它有需要，我又有技术，就义无反顾地去做这个东西。

硬氪：多年前您看到北欧农村和中国农村特别不一样，最震撼您的思考是什么？

吴迪：其实没有什么震撼，就是引发了一些思考。中国之前有大量的农村人口，现在正不断离开农村，搬到城市。和现代化行业比，做农业很辛苦，不赚钱，风险高，粮价低。这直接导致从事农业的人口快速下降，现在回农村看，做农业的平均年龄都是60多岁的老一辈。

当一个市场利润很低的时候，大家都不从事，那它的利润肯定会往上涨。中国的农业，劳动力的流失正在发生，越来越少年轻人愿意在农村。这就意味着以后中国的土地流转是一定会发生的，农场主的经营面积会增大，集约化就会提升，购买力、生产效率都会提升。我相信给一定时间，新型农民的购买力和知识水平都会上升，中国���农业又会迎来一波新的升级。

一个产品能不能卖，还是取决于它的产品竞争力、设计。产品既然是给农民用的，你就要简单傻瓜化。所以我们的产品现在基本上农村的老太都会用。

硬氪：最开始也是这样子想吗？

吴迪：最开始我们的认知是受限的。我们一开始强调做全无人的插秧机、收割机。后来发现这个东西太早了。现在他们更需要的是提升效率，成本足够低，他才能算明白账。所以后面我们就调整，改做农机套件（就是把现有的农机升级改造），就不做全无人的机器了，因为中国现在劳动力还没有贵到需要完全替代。

硬氪：什么时候发现完全无人的产品农村是接受不了的？

吴迪：发出来几个月以后。我的产品研发出来，技术上可以干这个事，但我马上发现可靠性、售后、包括农民的购买力都支撑不了。我们就赶快调整了。全无人产品因为购买力的问题，量就下来了，后面我们就不做了。也就是出来后大概两年内，我们卖了一些无人的机器，但最后测算售后成本太高，公司利润不好维持。

硬氪：为什么是售后成本太高？

吴迪：一个全无人的机器在田里的环境非常复杂，有石头、脏污。使用者文化程度有限，怎么维护？他可能会粗暴使用。出了问题你不能不修，派人去修的差旅各方面都会有问题。而且农民购买力很有限，买不起100万的机器，我们卖的算便宜，但30万对于中国农民来说也挺贵了。

硬氪：那个时候是不是发现自己想要设计的产品跟它实际落地是有差距的？

吴迪：当一个产品技术很领先，但你提前落地了，时代还没有准备好，那就不是一个理性的商业。

硬氪：您是很快就接受并开始调整产品，还是经过了一段时间思考？

吴迪：就是要不停地算账，算不明白就要调整。这不应该有什么纠结的点，因为这是个企业，它要盈利，要养活员工。你做一个一直赔钱的生意，是做不下去的。

硬氪：如何平衡技术的先进性、农民的实际需求和支付价格？研发过程中，你们出过哪些产品？

吴迪：我们做过耕种管收全无人的，无人插秧机、无人收割机、无人拖拉机都做过。最后其实还是算账，哪些东西真正能卖上量，大家有需求，然后它能够养活团队。这就是一个最简单的生意，产品卖不好就砍掉，不赚钱就砍掉。

硬氪：能展开讲一个例子吗？

吴迪：比如我们的插秧机套件。一开始我们做全无人插秧机，但场景很复杂，你很难做到全无人，因为换秧盘需要人。如果做自动换秧的机械，成本太高了。

所以现在我们做的机器是半自动的：到田间地头，它要掉个头，农民只要按一个键它就掉头了，其他就自己开，农民只要把那个秧盘放上去就可以。这样的话，我们省去了一个机手，放秧盘的人可以是家里的人，不用请有经验的机手。农民就省钱了，他就不会那么焦虑了。

02 “不标榜自己是多么先进的机器人公司”

硬氪：在您看来，你们的优势是能落地，匹配市场的需求？

吴迪：我们是一个始终在解决问题的机器人公司，我们不会标榜自己是一个多么先进的机器人公司。我们围绕那些比较辛苦、劳动力短缺、大家不愿意做的行业，比如养牛的牛场。我们的推料机器人专门推草料喂牛，它可以24小时、每个小时跑一趟，而人一天只能推两趟。牛的草就不够吃，产奶量就会掉下来。你不可能让一个人一天24小时工作。我们的机器能跑这么稳定，而且部署很快，原来传统的欧美企业部署三天，我们三个小时就做完了。这就是新科技在传统领域的落地。

进入农业是个契机，让我了解行业，有了敬畏之心。不是说你技术很厉害就可以，我的技术是很厉害，我能很快实现全无人，但做一个demo和让客户能长期低成本使用是两件事。要有敬畏之心，就要更深地了解行业，知道他们真正需要什么，围绕他们真实的需求来做性价比。

硬氪：敬畏之心发生在哪一刻？

吴迪：就是过分自动化、过度设计，不考虑现场的复杂情况，这种产品你就不应该做。

硬氪：你们从农业扩展到建筑、割草机器人，都是在解决工作环境艰苦的问题。有哪些需求是你们在现场发现的？

吴迪：比如说我去建筑工地，跟建筑商（比如香港新鸿基）打交道，听他的人讲我需要你帮我解决什么问题，什么东西是我愿意付费的，而不是我想做一个什么机器人给你用。

他明确提出来，他不用我想。他说我塔吊需要女性也能操作，但女性爬到100米的塔吊上很危险，去洗手间也不方便，那我希望你把塔吊控制室挪到地面。或者我希望塔吊在施工过程中更精准地知道位置。

堆料机器人是客户说我要有机器人帮我推料，因为我以前雇的人半夜起来推料，他经常因为太冷就睡过了，牛没有东西吃，影响我的产奶量。

硬氪：你们都是通过跟客户交流来发现需求？

吴迪：他可以告诉你他的问题是什么。他说我找不到人，我成本太高，或者我的工作质量不好控制。这是他的问题。剩下怎么解决，是你做产品的人必须想的。我要想我怎么用第一性原理设计一个产品来解决这个问题。

我到现场调研、跟他讨论，来发现和确认问题。这所有东西都是我自己发现的。

所以我没有我自己的办公室，我都是去客户现场。我们机器样机出来的时候，我都要到现场调机器的。我们做割草机的时候，我在国外，每天早上5点钟起来，在那待了一个月调机器，因为机器一开始有各种问题，跑不稳。

03 Innovation can never be planned。（创新无法规划）

硬氪：你们从农业做了两年后，要转其他行业，您当时是怎么寻找其他赛道的？

吴迪：赛道要有足够的购买力，他能养得起我的工程师。你不能做一个没人愿意买、大家不愿意付费的产品。我做的事情一定不是超级大厂会做的，我肯定做不过他们。你只能去找一些更“苦”的领域，但是它有购买力，你在这里面站住脚。这个逻辑很简单。

硬氪：那你们的产品从农业扩展到建筑、商用割草机，这些领域都有巨头。

吴迪：我有客户，他对这个有需求。我们做的割草机业务更多是商用割草机（高尔夫、运动场、市政园区等），家用的小割草机只是我们一个业务。

硬氪：技术可以复用吗？

吴迪：我们的技术，就像做农业也是基于精准导航和感知融合，割草机也差不多。然后是一些机械设计、电池这些三电系统，这些都是我们已有的核心技术。

硬氪：公司的产品优势在您看来可能是什么？

吴迪：目标就是现在做割草作业的老一辈客户他们能用起来，他没有什么高科技知识，按几个键就完了，我一定要做到那么简单。就像我们的插秧机套件，农村老太太都能用起来，它一定是个足够简单的。我能活下来，就说明我做得足够简单，做得复杂，没有人买单的。

硬氪：足够简单的壁垒是什么？

吴迪：迭代速度。你反应要快，软件改的要快。我发现有问题我赶快迭代，让用户觉得你的产品好用，我就能卖得多。

硬氪：是用户反馈问题，你们立马就改？

吴迪：对，因为我每天看里面的问题。有几个公司的CEO会看客户的每个产品每天反馈的问题？我自己会修机器，有哪个公司CEO能待在操场上修一个月机器？

硬氪：当时怎么会亲自改割草机改1个月？有哪些问题没想到？

吴迪：当时那个大型的商用无人割草机器人有很多问题，比较复杂，客户不满意要退货，我必须在现场解决问题。比如有时候跑得不直，有时候割草效果不好。就是软硬件系统不稳定，它有bug，你一个系统要稳定，就是要花时间。你在哪识别？就在客户那儿识别，我要让他满意。一个产品研发人家可能要两年时间，但我们可能半年到一年就搞了。这是我比别人迭代快的原因，所以你要现身试毒。

我们不是硬科技大厂，我不可能有那么多高密度的顶级精尖的人才。那些科技超大厂的研发能力我比不了，那你只能自己去一线解决问题。

硬氪：新业务里，哪个业务你觉得做起来最难？

吴迪：都不容易。我从来不会讲哪个最难，世界上没有好业务，也没有差业务。你容易做起来的，别人也容易做起来，很快也就没有利润了。你难的，别人也难。其实我还是讲我们的对手就是自己，我不会跟别人做比较。我就做我想做的事就完了。

硬氪：你们产品都是新的，怎么控制供应链这块的成本？

吴迪：所以我要到一线，要快速迭代，然后你要尽量复用，看怎么低成本把它做出来。就跟以前我们做所有产品的思路一致。像我们的农机驾驶套件，竞争对手不会做到供应链垂直整合，通常都会从外面买一个屏、买个接收器，但我们所有东西都自己做的，要花时间、花精力。

硬氪：为什么会选择在香港来设立一个总部？

吴迪：机缘巧合。这里有开放的国际化市场，有国际化的客户作为我们出海第一站，我觉得比较好。香港的营商环境也非常透明和简单，适合我们的文化。

硬氪：未来的计划方便聊一聊吗？

吴迪：我更专注做好自己每天的事情。我们不会画大饼去讲未来，因为我们是一个不断寻找社会痛点问题去用科技创新解决的机器人公司。你进入的领域，每天都会面临问题，你要解决问题，改造它，打磨产品，你就往前走。Innovation can never be planned。

硬氪：IPO这个东西一定是有计划的。

吴迪：其实更多的是公司发展到一定阶段的结果，但是我最重要的还是把业务做好，这是一个第一性原理。你必须把业务做好，做一个健康可持续的生意，这才是我每天最关心的。

硬氪：您一直在讲第一性原理，您觉得公司的产品或者哪方面是完完全全把第一性原理运用在上面？

吴迪：我觉得我们做得不好。只不过我keep in mind，我们应该尽量用第一性原理思考。经常说，说明我们很多时候还是没有用第一性原理思考。实际上大家往往说的时候，真正做的时候，你还是会受各种因素影响。

硬氪：能请以一个过去的产品来讲，您可能陷入了一个局部最优的思路？

吴迪：就是我刚才讲的，我觉得我以前做芯片、做无人机的。我想当然，我可以把拖拉机做成个无人的，在农田里跑起来不就实现无人化了嘛？最后发现不是那么回事儿。就是因为环境很复杂，无人化的成本非常高，最后没有人买单。这就是路径依赖。你做一个无人的航拍飞机，和你做一个无人拖拉机不是一码事。

硬氪：您在大疆担任首席科学家，大疆的精神对您后期的创业有没有一些影响？

吴迪：我觉得大疆的工程师比较简单、直接，比较喜欢围绕第一性原理讨论，比较朴实直接，我觉得这是值得我一生学习的。汪滔他对产品精益求精的做法是我的一盏明灯。大疆因为人才密度够高，体量够大，它可以不计成本地投入某一个产品。我们不是大疆那个赛道，我们做的是生产力工具，客户考虑的点就不一样。

硬氪：您当时为什么会在那个时间点选择回国？

吴迪：我觉得在这里有更大的机会。大湾区还是有非常好的环境，有足够多的人才。你要想做事，肯定要跟一群人一起做，回到你的祖国做这个事情很正常。

硬氪：在北欧的工作经历有没有影响你现在对产品的一些思考？

吴迪：你说的很对。在北欧的这段经历，让我知道我没有必要和别人比，就做好我自己。还有就是要做创新，不要抄袭别人。

硬氪：高校的经历对你现在创业，包括内部培养人才会不会有很多的帮助？

吴迪：我知道怎么和年轻人打交道，怎么直击问题的核心。你当过老师，你知道怎么把一个东西讲明白，由浅入深。好的老师能用很通俗的方法把一个问题讲清楚。我公司有很多骨干都是我以前的学生。每个人都有自己的风格，我的风格可能更适合于做产品。

硬氪：有没有哪个时刻是您觉得压力非常大？

吴迪：我们在转型的过程中间，有一段时间现金流比较紧张，国内做的东西不赚钱。那段时间压力是比较大的，我们公司也进行了调整。后面业务上了正轨就好很多了。但那段时间也帮助我看清楚了很多问题，你一定要做有价值的东西。

硬氪：您是一个非常重视客户需求的人，这个是从最开始就是这样吗？因为你以前搞芯片是离最终的客户是很远的。

吴迪：以前我们的芯片是卖到全世界的，包含亚非拉地区。像印度，他们的客户那时候恨不得三卡三待，有很多特别的需求。印度有上百家运营商，大家的网络都互相覆盖，有各种干扰。这是我们要解决的问题。所以我一直是关注终端客户的反馈的，因为总是有人要买单。谁买单你关心谁，就这么简单。

硬氪：会有吃力的时候吗？

吴迪：习惯了就好。就像一个和尚在少林寺每天挑两担水，他也无所谓吃力不吃力，他就是每天要挑。生活简单，我每天早上吃个包子，喝个豆浆，然后干活，每天都这样，日复一日，持续地做这件事，不停地迭代你的产品。

硬氪：会不会担心竞争？担心突然出现一个企业赶超你们？

吴迪：那跟我有什么关系，有的话说明我自己做得不够好。我为什么要担心别人赶超我呢？他不赶超我，我也应该做得更好。我每天都在想我的产品做得就不是那么好。目前产品都只能说是个勉强的状态，还有很大空间要迭代。

硬氪：农业占比会持续降低吗？

吴迪：我从来没有计划过这个事情。农业团队也在创新，在迭代，他们也能比较高速地发展。现在我们的农业团队也是很健康的。他们也能发现新的机遇，然后解决问题，用我已有的技术，就能不停地扩展业务。我们每个方向都是一个道理。

12月10日，华为、支付宝、中移互联网正式签署合作协议，共同开启“通话即服务”的智能化通信时代。此次合作标志着三方将深化AI+5G新通话DC生态场景的联合创新，推动传统通话向智能化、服务化方向演进。其中，中移互联网将依托中国移动覆盖全国的5G新通话网络和庞大的用户基础，提供稳定可靠的通信保障和产品运营；支付宝将整合其丰富的数字生活生态能力，联合打造智能化服务场景；华为则将提供领先的通信技术解决方案与广泛的终端适配支持。三方联合，旨在共同打造一个开放、智能、安全的新型通话服务平台。（证券时报）

据报道，三星正在加快其在美国生产AI5芯片的准备工作，近期已为其客户工程团队招募了一批经验丰富的工程师。该团队将协助解决复杂的晶圆代工难题，稳定生产良率，并确保这一新项目的制造流程顺利推进。此次大规模招聘表明，特斯拉的AI5项目在三星内部正快速推进。此前，三星与台积电共同赢得了特斯拉的芯片订单，成为AI5芯片的两家指定供应商之一。（财联社）

36氪获悉，12月11日，阅文短剧发布了2025年度成绩单。2025年，阅文短剧累计产出了超120部短剧，其中多部作品获得了头部平台“爆剧”认证，覆盖现言、古装、年代剧、男频等多个赛道。据了解，阅文短剧依靠阅文集团的作家生态，率先帮助网文作家跨界短剧行业。此外，阅文短剧还与视觉天使、飞鸟与鱼、壹拍即火等多家短剧制作机构建立了良好的合作关系。

大家好，我是大华！这篇我们来讲解Vue2和Vue3的核心区别在哪里？

Vue3是Vue2的升级版，不仅更快，还更好用。它解决了Vue2中一些让人头疼的问题，比如动态添加属性不响应、组件必须包在一个根元素里等等。

下面通过10个常见的对比例子，让你快速看懂Vue3到底新在哪儿、好在哪儿。

1. 响应式系统：Object.defineProperty vs Proxy

Vue 2 无法监听动态添加的属性（除非用 Vue.set）；Vue 3 可以直接响应。

// Vue 2 不会触发更新
this.obj.newProp = 'hello'

// Vue 2 正确方式
this.$set(this.obj, 'newProp', 'hello')

// Vue 3 直接赋值即可响应
this.obj.newProp = 'hello'

---

2. Composition API（组合式 API）

export default {
  data() {
    return { count: 0 }
  },
  methods: {
    increment() {
      this.count++
    }
  }
}




import { ref } from 'vue'

const count = ref(0)
const increment = () => count.value++

---

3. TypeScript 支持

// Vue 3 + TypeScript（能更好的支持）

interface Props {
  msg: string
}
const props = defineProps()

Vue 2 虽可通过 vue-class-component 或 vue-property-decorator 支持 TS，但配置复杂且类型推导弱。

---

4. Fragment（多根节点）

  <header>Header</header>
  <main>Main</main>




  <header>Header</header>
  <main>Main</main>

---

5. Teleport（传送门）

将 modal 渲染到 body 下，避免样式嵌套问题

  Open Modal
  
    <div class="modal">
      <p>Hello from Teleport!</p>
      Close
    </div>
  



import { ref } from 'vue'
const open = ref(false)

Vue 2 需手动操作 DOM 或使用第三方库（如 portal-vue）。

---

6. Suspense（异步组件加载）

const res = await fetch('/api/data')
const data = await res.json()



  <div>{{ data }}</div>

  
    
      
    
    
      <div>Loading...</div>
    
  

Vue 2 无原生 ``，需自行管理 loading 状态。

---

7. 全局 API 变更

// Vue 2
Vue.component('MyButton', MyButton)
Vue.directive('focus', focusDirective)

// Vue 3
import { createApp } from 'vue'
const app = createApp(App)
app.component('MyButton', MyButton)
app.directive('focus', focusDirective)
app.mount('#app')

Vue 3 的应用实例彼此隔离，适合微前端或多实例场景。

---

8. 生命周期钩子命名变化

// Vue 2
export default {
  beforeDestroy() { /* cleanup */ },
  destroyed() { /* final */ }
}

// Vue 3（Options API 写法）
export default {
  beforeUnmount() { /* cleanup */ },
  unmounted() { /* final */ }
}

// Vue 3（Composition API）
import { onBeforeUnmount, onUnmounted } from 'vue'
onBeforeUnmount(() => { /* cleanup */ })
onUnmounted(() => { /* final */ })

---

9. v-model 多绑定

---

10. 显式声明 emits（推荐）

const emit = defineEmits(['submit', 'cancel'])

const handleSubmit = () => emit('submit')




const emit = defineEmits({
  submit: (payload) => typeof payload === 'string',
  cancel: null
})

Vue 2 中 $emit 无需声明，但不利于工具链和文档生成。

---

这些示例覆盖了 Vue2 和 Vue3 比较关键的差异点。通过代码对比，可以更清楚地看到 Vue3 在开发体验、性能、灵活性和工程化方面有明细的提升。

结尾

总的来说，Vue3 在保持简单上手的同时，增加了更多实用又强大的功能。不管是写代码更轻松了，还是对 TypeScript、大型项目的支持更好了，都让开发者的工作变得更高效。

本文首发于公众号：程序员刘大华，专注分享前后端开发的实战笔记。关注我，少走弯路，一起进步！

📌往期精彩

《async/await 到底要不要加 try-catch？异步错误处理最佳实践》

《如何查看 SpringBoot 当前线程数？3 种方法亲测有效》

《Java 开发必看：什么时候用 for，什么时候用 Stream？》

《这 10 个 MySQL 高级用法，让你的代码又快又好看》