有不少小伙伴在问我一个问题：“Chrome 插件会不会偷偷监听我的输入？”这个问题其实很有必要关心，毕竟我们每天都在浏览器里输入各种账号密码、搜索内容，如果插件偷偷获取数据，那就真的很麻烦了。

今天就来跟大家聊聊 Chrome 插件的安全问题，同时教你 3 个实用方法 检测你的浏览器是否被监听。让你快速掌握自己的浏览器安全状况。

一、Chrome 插件监听输入的风险

首先要明确一点，并不是所有 Chrome 插件都会监听你的输入。但有些插件为了提供某些功能，确实可能获取你的浏览数据、键盘输入或者浏览器指纹信息。比如：

表单填充插件：为了自动填充账号密码，有时会读取你输入的内容。

广告/优惠插件：有些插件为了精准投放，会采集你的搜索行为或购物习惯。

主题和美化插件：虽然功能简单，但部分插件可能偷偷获取浏览器信息。

所以，即便插件看起来无害，后台也可能在悄悄采集数据，这就涉及 浏览器指纹检测。通过浏览器指纹，插件可以识别你独一无二的浏览器配置，包括分辨率、插件列表、字体和时区等信息，甚至无需 Cookies 就能追踪你。

二、如何检测 Chrome 插件是否监听你的输入

方法一：通过浏览器权限查看插件行为

每个 Chrome 插件都会请求一定权限，比如访问网站数据、读取剪贴板或者访问浏览器标签。我们可以这样操作：

打开 Chrome → 点击右上角菜单 → 更多工具 → 扩展程序。

找到可疑插件 → 点击“详情”。

查看“权限”是否包含“读取你在网站上的所有数据”或“访问剪贴板”。

如果插件权限过多，但功能又不相关，这就要小心了，说明可能会监听输入。

关键点：很多新手忽略了权限列表，其实这就是最直观的 浏览器插件检测 方法。

方法二：使用指纹查询

想要进一步检测自己的浏览器是否被采集信息，可以用指纹查询。这个工具可以帮你快速查看浏览器的指纹信息，包括：

浏览器类型和版本

操作系统

分辨率

插件列表

Canvas 指纹等

操作非常简单：

打开 ToDetect 指纹查询

点击“开始检测”

查看生成的指纹信息

如果你发现某些信息异常或者频繁变化，说明可能有插件在采集浏览器指纹，这就是另一种 浏览器指纹检测 方法。

方法三：观察浏览器行为

有时候插件监听行为并不直接表现出来，但可以通过观察浏览器行为来发现异常：

浏览器变慢或者卡顿

在输入账号或密码时出现莫名的弹窗

打开网站后出现奇怪的广告

插件后台持续请求网络

可以借助 Chrome 内置的 开发者工具 → 网络（Network）面板，查看插件是否频繁向外部服务器发送数据。如果有不明请求，就要谨慎处理。

这种方法偏技术向，但非常直观，是检测 Chrome 插件 是否监听你的输入的重要手段。

三、防止插件监听的实用建议

只安装必要插件：越少越好，功能越单一越安全。

检查插件来源：尽量在 Chrome 官方商店下载，并查看用户评价。

定期清理插件：长时间不使用的插件及时卸载。

使用浏览器指纹检测工具：像 ToDetect 指纹查询工具 可以定期检查，确保隐私安全。

注意插件权限：不要轻易授权不必要的权限。

四、总结

总的来说，Chrome 插件确实有可能监听你的输入，但通过 浏览器插件检测、浏览器指纹检测，我们可以大大降低隐私风险。记住三点：

留意插件权限

使用指纹检测工具检查浏览器安全

观察异常行为，及时清理可疑插件

只有掌握了这些方法，你才能在享受 Chrome 插件便利的同时，也保护好自己的隐私安全。

整理 | 华卫

 

1 月 28 日，智源多模态大模型成果"Multimodal learning with next-token prediction for large multimodal models（通过预测下一个词元进行多模态学习的多模态大模型）"上线国际顶级学术期刊 Nature，预计 2 月 12 日纸质版正式刊发。

 

Nature 编辑点评这项研究：Emu3 仅基于预测下一个词元（Next-token prediction），实现了大规模文本、图像和视频的统一学习，其在生成与感知任务上的性能可与使用专门路线相当，这一成果对构建可扩展、统一的多模态智能系统具有重要意义。

 

https://www.nature.com/articles/s41586-025-10041-x

 

2018 年以来，GPT 采用 “预测下一个词元（Next-token prediction，NTP）”的自回归路线，实现了语言大模型重大突破，开启了生成式人工智能浪潮。而多模态模型主要依赖对比学习、扩散模型等专门路线，自回归路线是否可以作为通用路线统一多模态？一直是未解之谜。

 

智源这项成果表明，只采用自回归路线，就可以统一多模态学习，训练出优秀的原生多模态大模型，对于确立自回归成为生成式人工智能统一路线具有重大意义。在后续迭代的 Emu3.5 版本，确实证明了这一范式的可拓展性，并达成预测下一个状态（Next-state prediction)的能力跃迁，获得可泛化的世界建模能力。

从语言到多模态：“预测下一个词元”的潜力与未解之问

“预测下一个词元”彻底改变了语言模型，促成了如 ChatGPT 等突破性成果，并引发了关于通用人工智能（AGI）早期迹象的讨论。然而，其在多模态学习中的潜力一直不甚明朗。

 

在多模态模型领域，视觉生成长期以来由结构复杂的扩散模型主导，而视觉语言感知则主要由组合式方法引领 ，这些方法通常将 CLIP 编码器与大语言模型（LLMs）结合。尽管已有一些尝试试图统一生成与感知（如 Emu 和 Chameleon），但这些工作要么简单将 LLM 与扩散模型拼接在一起，要么在性能效果上不及那些针对生成或感知任务精心设计的专用方法。这就留下了一个根本性的科学问题：单一的预测下一个词元框架是否能够作为通用的多模态学习范式？

 

就此，智源提出了 Emu3，基于“预测下一个词元”的全新多模态模型，将图像、文本和视频统一离散化到同一个表示空间中，并从零开始，在多模态序列混合数据上联合训练一个单一的 Transformer。这一架构证明了仅凭“预测下一个词元”，就能够同时支持高水平的生成能力与理解能力，并且在同一统一架构下，自然地扩展到机器人操作以及多模态交错等生成任务。此外，研究团队还做了大量消融实验和分析，验证了多模态学习的规模定律（Scaling law）、统一离散化的高效性、以及解码器架构的有效性。

 

Emu3 架构图

 

实验显示，Emu3 在生成与感知任务上的整体表现可与多种成熟的任务专用模型相媲美：在文生图任务中，其效果达到扩散模型水平；在视觉语言理解方面，可以与融合 CLIP 和大语言模型的主流方案比肩。此外，Emu3 还具备视频生成能力。不同于以噪声为起点的扩散式视频生成模型，Emu3 通过自回归方式逐词元（token）预测视频序列，实现基于因果的视频生成与延展，展现出对物理世界中环境、人类与动物行为的初步模拟能力。

从模型到范式：Emu3 对多模态学习的启示

不同于 Sora 的扩散式视频生成，Emu3 采用纯自回归方式逐词元（token） 生成视频，能够在给定上下文下进行视频延展与未来预测，并在文本引导下生成高保真视频。此外，Emu3 还可拓展至视觉语言交错生成，例如图文并茂的菜谱生成；也可拓展至视觉语言动作建模，如机器人操作 VLA 等，进一步体现了“预测下一个词元”的通用性。

 

智源研究团队对相关研究的多项关键技术与模型进行了开源，以推动该方向的持续研究。其中包括一个稳定且通用的视觉分词器（tokenizer），可将图像与视频高效转换为离散词元来表示。同时，研究通过大规模消融实验系统分析了多项关键技术的设计选择，例如：分词器（tokenizer）码本尺寸、初始化策略、多模态 dropout 机制以及损失权重配置等，揭示了多模态自回归模型在训练过程中的动态特性。研究还验证了自回归路线高度通用性：直接偏好优化（DPO）方法可无缝应用于自回归视觉生成任务，使模型能够更好地对齐人类偏好。

 

研究有力表明了预测下一个词元可作为多模态模型的核心范式，突破语言模型的边界，在多种多模态任务中展现了强劲性能。通过简化复杂的模型设计、聚焦统一词元，该方法在训练与推理阶段均展现出显著的可扩展性，为统一多模态学习奠定了坚实基础，有望推动原生多模态助手、世界模型以及具身智能等方向的发展。

 

在此研究基础上，悟界·Emu3.5 进一步通过大规模长时序视频训练，学习时空与因果关系，展现出随模型与数据规模增长而提升的物理世界建模能力，并观察到多模态能力随规模扩展而涌现的趋势，实现了“预测下一个状态”的范式升级。

采访嘉宾 | 天数智芯 AI 与加速计算技术负责人 单天逸

对于国产 GPU 行业来说，没有哪个时间节点比当下更宝贵。在政策支持硬科技企业上市的背景下，国产 GPU 迎来了难得的上市黄金窗口期。但上市并非终点，在敲钟的那一刻，下一战场大幕已经拉开——GPU 厂商的技术路线、产品能力和长期判断，被放到了更公开也更严苛的舞台上，谁能撑起资本市场和大众期待，谁就能撑起市值。

这也是为什么，天数智芯上市后的首场发布会能够在业内形成广泛讨论。它以极其务实的工程师表达方式，把架构放回到国产 GPU 技术叙事的中心。在 1 月 26 日召开的天数智芯“智启芯程”合作伙伴大会中，围绕架构层的创新与思考占据了相当比重。基于这些创新点与思考，天数智芯公布了过去一代以及未来三代的架构路线图：

  • 2025 年，天数天枢架构已经超越英伟达 Hopper，在 DeepSeek V3 场景中实测性能数据超出 20%；

  • 2026 年，天数天璇架构对标 Blackwell，新增 ixFP4 精度支持；

  • 2026 年，天数天玑架构超越 Blackwell，覆盖全场景 AI/加速计算；

  • 2027 年，天数天权架构超越 Rubin，支持更多精度与创新设计。

国产 GPU，开启 AI++ 计算新范式

根据天数智芯公布的架构路线图及阶段发展目标，在 2027 年之前，天数智芯将通过多代产品完成对英伟达的追赶；在 2027 年之后，将转向更富创新性的架构设计，聚焦更具突破性的超级计算芯片架构设计。看似宏大，但对于仍处于爬坡阶段的国产 GPU 行业来说，这条路径实际上相当务实——只有在工程化能力上完成对标甚至是超越，国产 GPU 才有资格进入更大规模的生产环境中。

而在规模化落地阶段的竞争，焦点早已从峰值性能指标转向有效计算能力。当 Token 成为 AI 时代最基本的生产资料，当算力消耗开始对标真实业务产出，无论是国际顶尖 GPU 厂商还是国内 GPU 企业，核心命题都只有一个：如何在真实业务中，把算力转化为有效的 Token。这似乎又将大家都拉到同一起跑线。

围绕这一命题，天数智芯提出了两条明确的架构判断：其一，回归计算本质；其二，提供高质量算力。

回归计算本质，核心在于“不设限”

过去十年，规模的快速扩张带来了阶段性的产业繁荣，也使得算力实现野蛮增长。但这种粗放式发展，也带来了能效比失衡、算力资源严重浪费等问题。背后的根因十分复杂。以开车行驶为例，路途中可能会遇到雨雪冰雹天气、崎岖道路等各种复杂情况。物理、芯片、系统世界也是如此，计算、通讯、存储都会带来各种障碍。所以，幻想奔跑在平坦的赛道上毫无意义，产业真正需要的，是能够翻山越岭的全能越野车。

广义上，芯片可分为专用芯片和通用芯片：专用芯片类似“应试教育”，它的优势和边界都很清晰，能加速特定算法、特定指令，比如矩阵乘法、Softmax 这些主流任务，但一旦计算范式发生变化，适应空间就会迅速收紧；通用芯片的设计哲学，不是为了押中某一类算法，而是回归计算本质，覆盖更广泛，甚至全新的计算需求。

这也是天数智芯坚持推出并量产通用 GPU 的根因。在其看来，硬件与算法的关系本来就不应该相互掣肘，算力的僵化不应限制算法的进化，而是通过通用算力为探索未知算法提供一个坚实的底座。

支撑探索未来算法的关键，实则就是“不设限”。

基于这一判断，天数智芯的芯片设计哲学，在计算层面追求的是覆盖几乎所有的数学运算图谱，而非某一类、某一种计算：从 Scalar、Vector、Tensor 到 Cube，支持从高精度科学计算到 AI 精度计算，从 MMA 到 DPX，不管是 AI 的 Attention 机制、前沿的科学计算，还是未来的量子计算相关模拟，天数智芯全都支持。

在执行层面，追求的是更高的算力利用率：大、中、小任务会被精准分配到不同的计算单元中执行，配合高密度的多任务核心设计，算力可以被拆解、调度得更加精细，从而减少算力浪费，提高计算效率。

这种“不设限”的设计哲学，让天数天枢架构得以实现三大创新，这也是天枢能够超越英伟达 Hopper 架构的根因：

  • TPC BroadCast（计算组广播机制）设计：不是简单粗暴地放大带宽，而是从单位带宽的使用效率入手，存在相同地址的数据时，芯片内部的 load store 单元不会进行重复、无用的访问，而是在上游进行 BroadCast，减少不必要的内存访问次数，从而有效降低访存功耗，等效提升访存带宽，用更小的功耗和面积实现相同的功能。

  • Instruction Co-Exec（多指令并行处理系统）设计：在指令执行层面，通过 Instruction Co-Exec 设计实现了多种指令类型的并行执行能力，不仅支持 Tensor Core 与 Vector Core 的并行协同，还将 Exponent 计算、通信等操作一并纳入统一调度。在天数 IX-Scheduler 模块中，通过极低的成本增强了不同指令之间的并行处理能力，无论是 MLA、Engram，还是面向更复杂模型场景的计算需求，都可以在这一并行框架下被同时处理，从而提升整体执行效率。

  • Dynamic Warp Scheduling（动态线程组调度系统）设计：随着 MoE 架构在大模型中被广泛采用，模型厂商普遍面临推理效率低等现实挑战。为提升并行度，微架构层面允许芯片中同时驻留更多 warp，但 warp 的增加也意味着对计算资源的竞争更为激烈。为此，天数智芯首创了 Dynamic Warp Scheduling 机制，通过动态调度让不同 warp 在资源使用上实现有序协作，避免计算资源闲置，也减少了对同一资源的无序争抢。

这三项设计的出发点本质上都指向相同的目标：高性能与高效率。数据显示，这些创新让天数天枢的效率较当前行业平均水平提升 60%，基于这些效率优势，实现在 DeepSeek V3 场景平均比 Hopper 架构高约 20% 性能。

从这三项设计中可以看出，天数智芯在架构层面的创新，并不是围绕某一个具体模型或算子展开，而是试图打破 GPU 通用范式边界。天数智芯 AI 与加速计算技术负责人单天逸在接受采访时表示，在天数智芯提出 Dynamic Warp Scheduling 设计之前，几乎没有人从调度机制的角度去思考，还能为 MoE 带来哪些性能空间。从更深层次意义来看，这类微架构层面的调度和优化，一直是英伟达、AMD 等巨头保持领先的“内功”，天数智芯在这些单点上的突破，实际上也是国产 GPU 向顶级玩家看齐的重要一步。

提供高质量算力：高效率、可预期、可持续

在天数智芯的架构语境中，回归计算本质并不是一个抽象的口号，而是实现高质量算力的前提条件。只有当 GPU 从底层开始真正对计算负责，高质量算力才成为可能。基于这一判断，天数智芯将高质量算力拆解为三个核心维度：高效率、可预期与可持续。

高效率意味着能为客户创造最优的 TCO（总体拥有成本），节省使用成本；可预期则通过精准的仿真模拟，让客户在拿到芯片、部署算力之前，就能清晰预判最终的性能表现，做到所见即所得；可持续指的是从现在主流的 CNN、RNN，到当下火热的 Transformer，再到未来还未诞生的全新算法，算力始终能无缝适配。

围绕这三个方向，天数智芯在架构及系统设计上，选择从多任务并行处理、长上下文 IX-Attention 模块、IX-SIMU 全栈软件仿真系统以及 IXAI++ 算力系统多个层面同步推进。这几项，其实哪个都值得单独展开探讨。

比如，基于“不设限”的设计理念，在当前 PD 分离的架构下，天数智芯的 GPU 不只做计算，还支撑通信、KV 数据传输这些关键任务，通过打造 Ⅸ 并行任务处理模块，GPU 能精准调度 KV 传输、多路多流、计算与通信等各类任务，让它们并行不冲突。在真实业务场景中，该模块成功帮助头部互联网客户实现了端到端 30% 的性能跃升。

为了提高算力可持续性，天数智芯统一了芯片内、外，来构建算力系统，并通过不断更新的软件栈和软件系统，三类库共同支持和保障多场景的高效运行。其中，AI 库、通讯库（ixccl）、加速计算库是基石，在基石之上，直接支撑各类神经网络模型 CNN、Transformer、LSTM 与高性能计算的各个领域，并以此提供各类 AI 应用，包括支持 AI4Sci 的相关应用，如蛋白质结构预测（AlphaFold）、医疗影像分析（Clara）、气候模拟（Earth2）等，以及量子计算的平台 cudaQ、分子动力学 Gromacs，大规模方程组求解器 HPL 等。

这套算力系统被命名为 IXAI++，寓意为自我迭代，不止于 AI。其最终的目标是，成为一座连接算法创新与物理世界的桥梁，带领人类科技通往未知探索。

但给业内带来最多惊喜的，是 IX-Attention 模块和 IX-SIMU 全栈软件仿真系统。前者解决的是当前大模型推理中最具代表性的效率难题，后者解决的是企业部署算力系统最头疼的不可控难题。

在大模型推理场景中，长上下文被普遍认为是最具代表性的效率难题之一。即便是在国际主流 GPU 架构上，Attention 的执行效率依然不高，如果不对其进行针对性优化，首字延迟将明显偏高，模型响应速度差，推理成本高昂，最终影响大模型在真实业务中的可用性。

围绕这一痛点，天数智芯设计了 Ⅸ Attention 模块，从底层对 Attention 的执行路径进行重构：Attention 底层涉及 exponent、reduce、MMA、atomic 等多类指令与算子，Ⅸ Attention 模块的核心思路，是将这些分散的组件有机地拼装到一起，如同指挥一支乐队一般，确保多种乐器能够和谐共鸣。

“其中的技术难点在于调度，多种乐器需要同时演奏，任何一个环节拖慢节奏，都会成为整个系统的瓶颈”，单天逸表示，在实际的长上下文推理中，Ⅸ Attention 模块有效改善了 Attention 的执行效率，带来了约 20% 的提升。

针对企业部署算力系统最头疼的不可控难题，天数智芯搭建了IX-SIMU 全栈软件仿真系统，这套仿真系统的目标，就是零意外、可预期。通过对芯片等硬件与软件执行策略的联合仿真，能精准输出任意模型的性能表现，提升算力在真实场景中的可控性。

单天逸表示，在算力系统的仿真与评估中，最难建模的是指令级别的硬件行为。IX-SIMU 的核心能力在于，能够对底层指令执行进行精细建模。在实际使用中，用户只需输入软件代码，IX-SIMU 便会自动整合 GPU、CPU、网卡、PCIe 等硬件组件，匹配网络拓扑，再结合软件策略、投机策略、Streaming LLM 策略、前缀匹配等各类策略，最终精准输出 Deepseek、千问等任意模型的性能表现，实现从单卡到万卡集群的 “精密扩展”。

围绕高效率、可预期、可持续三大判断，天数智芯在算力侧从硬件架构到系统设计进行了整体布局，并用未来三代架构路线图提前回答下一个问题：当算力僵化开始掣肘未来计算，架构层还能怎么演进？

决定上限的，最终还是应用和生态

架构代表的其实是下限，决定上限的，最终还是应用和生态。数据显示，截至 2025 年年底，天数产品已在互联网、大模型、金融、医疗、教育、交通等超过 20 个行业落地应用，服务客户数量超过 300 家，并通过软硬件协同优化，完成 1000+ 次模型部署，让产品能力真正达到商用级别。

支撑这些场景应用的，早已不是一个产品的能力范畴，而是“产品 + 解决方案” 双轨模式，这一模式其实与英伟达定位非常相近，聚焦的都是解决方案落地。在大模型深入产业应用的当下，这套组合打法相当务实，毕竟应用落地才是唯一真理，谁能在企业真实业务场景中快速部署、持续稳定运行，谁就能赢得先机。在速度和兼容性上，天数智芯也交出了一份不错的答卷：国内新的大模型发布当天便能跑通，目前已稳定运行 400 余种模型、数千个已有算子与 100 余种定制算子，数千卡集群稳定运行超 1000 天。

在这次发布会上，天数智芯面向物理 AI 场景落地，一口气发布了四款边端算力产品“彤央”系列：包括边端 AI 算力模组 TY1000、TY1100，以及边端 AI 算力终端 TY1100_NX、TY1200。 据了解，“彤央”系列产品的标称算力均为实测稠密算力，覆盖 100T 到 300T 范围。数据显示，在计算机视觉、自然语言处理、DeepSeek 32B 大语言模型、具身智能 VLA 模型及世界模型等多个场景的实测中，彤央 TY1000 的性能全面优于英伟达 AGX Orin。

在发布会中，天数智芯展示了“彤央”系列产品在具身智能、工业智能、商业智能和交通智能四大边端核心领域的落地应用：具身智能领域，为格蓝若机器人提供高算力、低延迟的“大脑”支撑；在工业智能领域，落地园区与产线，推动产线自动化升级；在商业智能领域，瑞幸咖啡数千家门店部署彤央方案，高效处理视频流、挖掘消费数据价值；在交通智能领域，与“车路云一体化”20 个头部试点城市合作，验证车路协同方案。

整体来看，天数智芯走的路线虽然是底层技术自研，但在生态上并非封闭。在生态建设上，天数智芯与硬件厂商、解决方案提供商等多家生态伙伴签署战略合作协议，进一步完善国产 AI 算力生态闭环。通过兼容主流开发生态，持续开放底层能力，降低开发者迁移和使用门槛。未来，天数智芯还会持续增加在生态共建上的资本与人力投入，从应用到芯片与开发者一同优化 AI 应用系统，共同为应用落地提供性能、性价比与生态易用的价值。

从底层架构到产品，从应用到生态，国产算力正在实现完整闭环，这种从芯片到生态的协同能力，不仅让国产算力更可用、更可持续，也为行业探索新模式提供了更多想象空间。

Matrix 首页推荐 

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 

文章代表作者个人观点，少数派仅对标题和排版略作修改。

创作声明：
这篇文章本身就是文中所描述的工作流的一次实践。

核心思考通过文中所提及的 Tana #WritingFunction 框架来梳理观点、案例，以及文章主体的构建。最终通过与 Claude 的讨论，完成逻辑的验证以及表达的润色。

文章的核心思想、个人经历、使用案例和观点均为原创，所有 AI 辅助生成的内容均经过人工审核和确认。

写在前面

「选 A 还是 B？」这可能是每个垂直领域的工具讨论中都绕不开的问题。在笔记管理这个圈子也总能看到类似的讨论：Logseq 还是 Obsidian？Notion 还是 Roam Research？而对我来说，让我纠结了很长一段时间的 A 和 B，正是 Heptabase 和 Tana。

说实话这可能就是一种执念吧。我们总希望找到一款 All in One 的工具，能够一次性解决所有问题。记录、整理、思考、输出，最好全都能搞定。事实上，有很多工具也的确是往这个方向发展的。

但问题在于，当你试图用一个工具照顾到所有场景时，你会发现每个场景都只能做到「还行」，没有一个真正做得很好。这不是工具的问题，而是我们对工具的期待本身存在矛盾。更重要的是，我们很容易被各种工具的 feature 带跑偏。过度关注「这个工具能干什么」，却忽略了更本质的问题：「我究竟想要获得什么？」

说到底，知识管理这件事，技巧和功能都只是表层。真正重要的是如何构建自己的思考模式、如何理解知识，以及最终能沉淀出什么真正属于自己的东西。

Heptabase 和 Tana 都是我非常喜欢的产品。它们都是我希望能够长期用来学习、沉淀的平台。但这两款产品无论从理念还是功能上看都是截然不同的。如何选择？这个问题在很长一段时间里困扰着我，也消耗了我不少时间和精力。

我记得自己反复尝试在其中一个工具里 All in One 又反复失败，试图找到那个「最适合」的，却发现每个都有不可替代的优势。两边来回切换，既焦虑又低效。

不过也正是这段纠结摇摆的时间，让我逐渐想明白了几件事。

我为什么需要它们？我究竟想用它们来帮助自己解决什么问题？

当这些问题的答案逐渐清晰，困扰我许久的选择难题豁然开朗。我不再纠结「选哪个」，而是决定两款工具「双修」。这也是这篇文章最原始的思考起点。今天的这篇文章，我怕不会详细介绍两款工具的具体功能——那些内容在各自的官网和教程里都能找到。我更想从产品理念和真实需求的角度，聊聊我对这两款工具的理解，以及为什么我最终选择了「双修」。

如果你也在为类似的问题困扰，或许这篇文章能给你提供一些不一样的思路。

篇首语

2023 年我离开了公司。十多年陆陆续续记下的各类笔记信息，都随着电脑一起交还了回去。那一刻的感觉其实挺好的，因为我终于不用再去维护那些零散、混乱的信息了。接下来对我来说是一次从零开始的机会——没有历史包袱、不用考虑数据迁移，我可以重新搭建一套属于自己的知识体系，围绕我真正关心的领域和命题，重新构建思考框架。

不久后，我陆续接触到了 Heptabase 和 Tana，开始尝试在某一个工具里解决所有知识管理的工作。这几年里我在它们之间来回切换，想找到一个最合适的方式。可是每次的坚持都过不了几个月，但总觉得哪里不太对，却又说不清缘由。

问题到底在哪儿？

直到很久之后我才慢慢意识到，问题根本不在工具本身。这两款工具的思路完全不同。一个强调空间，一个强调结构。其实并不太具备可比性。而我把自己困在了「All in One」的执念里，总想着在一个工具里解决所有场景的需求，结果什么都顾不上，也什么都没做好。

说实话这个思维的转变花了我不少时间。

所以这篇文章，我想重新聊聊知识管理这件事。聊聊我这几年在工具之间的反复和困惑，以及我现在怎么看「如何选择知识管理工具」这个问题。

Heptabase vs Tana

这两款产品的特点非常鲜明，差异也很大。

Heptabase 本质上是一个空间化思维工具。它把笔记彻底从线性文本的逻辑中解放出来，让我们能在一个二维平面上组织信息。这有点像在做复杂问题的拆解，把所有变量、关系、逻辑放在同一个视野里。

比如我们经常在影视作品中看到的案情分析：

那些原本散落在不同文档里的想法，被转化成可移动的卡片，你可以随时调整它们的位置、建立连接、形成分组。这个过程其实就是在可视化你的思考路径。

但真正让我决定付费的不是这种交互形态，而是这款产品背后对「知识」的理解：Heptabase 的核心不是「记录信息」，而是「理解知识」。它认为思考是一个空间性的活动，需要看见全局、发现关联、建立结构。这和传统笔记软件「写完就完了」的逻辑是完全不同的。

创始人 Alan 在 My Vision Project Meta 这篇文章里讲得很清楚：笔记工具的终极目标不应该是存储，而是帮助人们理解复杂的事物。这个理念我很认同。

相比之下，Tana 的路径则完全不同。它关注的不是「全貌」，而是「结构」——更准确地说，是如何通过结构化来组织信息。

我一直偏好大纲型工具，原因很简单：快速、灵活，最适合即时记录。在公司的那些年，我用过很长时间的 Logseq 和 OmniOutliner。它们在记录层面没什么问题，但有个致命缺陷——信息是扁平的、离散的，缺乏语义层面的关联。你记了很多东西，但它们只是一个个独立的节点。你知道它们在那儿，但很难形成体系化的知识网络。

Tana 的核心创新在于 Supertag，也是让我决定付费的核心能力。它让每个节点不再只是一段文字，而是可以承载结构和属性的「对象」。这意味着我们可以把信息从「记录」层面推进到「建模」层面。

举个例子：同样是记录一本书，在传统大纲工具里，你只能写书名+笔记。但在 Tana 里，你可以定义这本书的作者、出版年份、领域分类、阅读状态，甚至关联到自己的思考以及写作。这不只是功能上的差异，而是认知层面的升级。我们可以开始用结构化的方式去理解知识，而不只是堆砌信息。

当然，另一方面 Tana 也是我接触过学习门槛最高的工具。它要求我们具备一定的抽象思维和建模能力。你得自己去定义本体（Ontology）、设计结构化字段、构建查询逻辑。这个过程有不小的难度，注定需要反复试错，需要耐心和坚持。

坦白讲，对于 Tana 我中途放弃过好几次。直到最近一年对结构化思维的理解加深，这才真正把它用顺手了。

进一步展开聊聊

工具类产品有很多，但真正有生命力的，从来不是因为功能堆得多。而是因为它背后有一套独特的思考方式。每个好的工具产品，本质上都是创始团队对某个领域认知的外化。他们怎么看问题，决定了产品长什么样，也决定了你用这个工具会被引导着怎么思考。

换句话说，工具不只是个被动的载体。它也在表达一种思维方式。

Heptabase 和 Tana 就是两个典型的例子。一个把「思考」空间化，一个把「知识」结构化。你可能会说，这不就是界面和交互上的差异吗？

不是。这背后代表的，是对知识管理、信息处理的两种完全不同的认知。Heptabase 关注的是「看见关系」。它相信思考需要全局视野，需要在空间中发现那些隐藏的连接；而 Tana 关注的是「定义关系」。它相信知识需要被结构化，需要通过明确的语义来组织信息。

一个是自下而上的涌现，一个是自上而下的建构。说到底，这两个工具在回答同一个问题：

我们应该如何处理信息，才能真正把它变成知识？

Heptabase 的思考空间化

我们前面提到过， Heptabase 做的事情是把笔记从线性文本里解放出来。听起来似乎没什么，但这其实就是对「思考」这件事的一个重新定义。

在 Heptabase 里，每一条信息都是一张卡片。卡片可以在白板上自由摆放、分组、连接。随着卡片的增加，你会发现一件事：你不再只是在记录，而是在构建一张思考地图。

为什么要这样做？因为人脑处理复杂问题时的过程，本来就不是线性的。我们需要看到全局，需要发现那些隐藏的关联，需要在不同的信息之间来回穿梭，才能涌现新的认知。但传统笔记是一页页的文档，你只能在有限的视野里思考。Heptabase 把这个过程外部化了。

举个例子。最近我在梳理一个关于日本利率政策的白板，起因是 BOJ 考虑提升利率的新闻。我当时就在想：这事儿背后的逻辑是什么？会有什么连锁反应？

然后我开始往白板上放卡片：这次加息的背景、触发原因、日元升值对国际市场的影响、日本历史上几次重要的利率政策调整……每放一张卡片，就会引出新的问题。慢慢的，整个白板开始呈现出一个结构。我发现自己对「失去的三十年」和「十年轮回」有了完全不同的理解。那些过去零散读到的信息，突然之间连成了线。

这就是 Heptabase 的核心价值。它不是帮你存储笔记，而是帮你理清思路。当你把碎片信息变成可移动的卡片，在白板上不断调整位置、建立连接时，你其实也是在做一件事：把脑子里的思考过程，变成可以看见、可以操作的对象。

这是传统笔记工具做不到的。在那些工具里，写完就是完了；但在 Heptabase 里，写完只是开始。真正的思考发生在你重新整理这些卡片的时候。你会发现新的关系，会产生新的疑问，会推翻原来的结论。思考不再停留在脑海里，而是变成了一个可以被「看见」的结构。

所以 Heptabase 入门不难，但用好很难。难在哪儿？难在你得主动去搭建。你得愿意花时间拆解问题，愿意反复调整卡片的位置，愿意在这个过程中跟自己的思维较劲。这个过程很慢，也很累。

但这才是真正的深度思考。

另外，我上面这个白板只能算个开始。大家可以看看官方提供的 Chip War 案例，那个更完整，更能感受到这种思考方式的威力。

Tana 的思考结构化

如果说 Heptabase 是帮你「看见思考」，那 Tana 就是帮你「组织思考」。

它的核心是什么?把你脑子里的思考逻辑,变成可以被定义、被复用的结构。

在 Tana 里每条信息都是一个节点，但和传统大纲工具不同的是，这里的每个节点都可以通过 Supertag 携带语义结构，你可以定义这个节点是什么、有哪些属性、和其他节点是什么关系。当这些节点彼此引用、关联、嵌套时，你会发现它们逐渐织成了一张动态的知识网络。

这意味着你的笔记不再是记完就落灰的文本，而是可以被组织、被推理、甚至触发行动的结构化信息。

这里也给大家举几个我自己的例子。

日常思考的捕捉

我用 #Signal 这个标签记录每天的思考和摘要。但不只是记录，我会同时做好结构化标注：

  • Domain：这条思考属于哪个领域？比如宏观经济、产品设计、AI 应用……
  • Context：在什么场景下产生的这个想法?
  • Content：具体的思考内容是什么?

比下图中这条关于日本央行加息的笔记。我不只是记录「BOJ 可能加息」这个事实，而是同时标注了它的领域（宏观经济）、触发场景（日元升值压力），以及具体的分析内容。

这样做的好处是，我可以在后续按领域、按场景、按时间，用不同的维度去检索和组织这些思考。每条信息不再是孤立的，而是带着「身份标签」的知识节点。

写作框架的固化

写作这件事就更典型了，对我来说它就是结构化思考的过程。所以我专门建了一个 #WritingFunction 标签，把文章写作「打散」成若干固定问题：

基础问题（每篇必答）:

  • 核心表达：这篇文章要说什么？
  • 背景语境：为什么写、在什么场景下写？
  • 焦点洞察：我有什么新的发现？
  • 核心观点:我的立场是什么?

可选模块（按需使用）:

  • 观点支撑：有哪些材料可以佐证？
  • 类比映射：能不能用类比帮助理解？
  • 切换视角：换个角度讲会不会更清楚？
  • 认知递进：这篇文章能引发什么进一步的思考？

这套框架其实就是我的写作「思维框架」。它能让我每次的写作都不是临场发挥、写到哪儿算哪儿，而是将它变成一次系统化的推理过程。我不用每次从零开始想怎么写，而是按框架填空、补充、延展。这篇文章就是在这个 Writing Function 下完成的草稿，再通过与 AI 的交流完成优化调整。

另外这个框架是可以迭代的，当我发现某个问题反复有价值，我就把它固化到模板里，当某个问题不好用，我就删掉。

公司分析的建模

同样的逻辑，我还用将它用在构建了公司分析的模型上。这是一个针对公司基本面分析的本体论（Ontology）结构。什么意思？就是我定义了理解一家公司需要看哪些维度。

比如上图中的这个 Palantir 的案例:

  • 业务模式：主要产品是什么？收入来源是什么？
  • 客户群体：服务谁？政府、企业还是个人？
  • 成长路径：怎么扩张？靠产品迭代还是市场拓展？

当这套模型搭建完成后，我就可以用它去快速分析任何一家新公司。不是每次从头想「该看什么」，而是按模板去填充、去对比。这就走出了传统记笔记的逻辑，把自己的思考方式，变成可以被复用的结构。

所以在这些场景里 Tana 的核心价值到底是什么？我觉得肯定不是记录信息，而是让你把自己的思考逻辑显性化、结构化，让它变成可以被构建、被复用、被迭代的对象。换句话说，Tana 中的这些由 SuperTag 组成的框架，就是我们思维方式的外化。

这也是为什么 Tana 学习门槛很高。因为它要求我们必须有足够的结构化思维能力，得知道自己是怎么思考的，才能把这套逻辑用 Supertag、字段、查询给搭建出来。这个过程也需要不少时间，我自己中途放弃过好几次，直到最近一年才真正把它用顺了。

但坦白说这个过程还是挺有价值的。我对自己的思维方式有了更清晰的认知，它总会逼着你去想自己到底是怎么理解一个问题的？我的思考框架是什么？这个过程本身就很有价值了。

回到根本，知识管理的逻辑是什么

聊完这两个产品，其实我们得回到一个更根本的问题：

我们究竟是如何理解「知识」这件事的？我们认为自己在管理的到底是什么，又该如何管理？

这个问题很重要。因为工具的形态我们无法决定，但自己的理念可以。一个具备独立思考能力的人，应该有属于自己的知识观。这个理解才是我们选择工具的真正逻辑。

很多时候你会发现，别人推荐的工具看上去让人特别有想去试试的冲动，但真上手后才发现，自己用起来却是怎么都很别扭。

问题出在哪儿？其实不在工具本身，而在于它不契合你的思考方式。或者说你当下还没有形成足够清晰的方法论去驾驭它。这也并不是坏事。相反，这恰恰是在提醒我们那应该停下来想一想自己对知识管理的逻辑是什么。

我们不必追着各种新的工具跑、去反复试错，而应该先想清楚自己是怎么思考的。

本质上来说，无论是知识管理还是建立对世界的理解，第一步可能都不是去瞄准某个工具。而是先找到属于自己的逻辑与理念。只有这样，你才能真正选择、甚至塑造出与你思维方式匹配的工具。

举个例子，如果你希望对知识的管理方式是从混沌到清晰，那么我们你可能需要的是先把所有信息铺开，在空间中寻找关联，那 Heptabase 可能就是你需要的；但如果你的思考方式是标准化的。那么你可能需要先定义框架，再往框架里填充内容，那 Tana 可能会更适合你。

两种方式没有对错，关键是你得先知道自己想要的是哪一种。

不要痴迷于 All in One

知识管理本身是个很大的命题。它有很多不同场景组成，每个人的侧重点也不同。所以叠加起来，逻辑会变得很复杂。

对我来说，核心关注点只有两个：

  1. 如何快速记录并结构化信息，形成我的底层知识物料，为未来自己的模型训练做准备；
  2. 如何基于某个问题或领域，把这些物料整合成完整的知识框架，做到对特定主题的研究延展。

这两个听起来没特别，Tana 和 Heptabase 似乎都能干，但实际上实践下来都不太行。Heptabase 的白板在信息组织、发散思考上很强，但快速记录和结构化处理上不好用，效率很低；Tana 在记录和结构化上很强，但因为它以节点为核心的产品设计理念，并不擅长做全貌的思考。

想在一个工具里同时做到既要聚焦细节还能俯瞰全局。至少目前来看不现实，确切的说是不好用。所以今年开始我换了个思路，让 Tana 和 Heptabase 并行使用。Tana 负责前期的快速记录和结构化，作为基础资料库；Heptabase 负责后期用白板沉淀内容，面向问题和领域构建全局思考。

有意思的是，当我真这样跑了一段时间后，发现我之前担心的在两个工具之间的复制粘贴的操作并没增加太多的工作量（相较于 All in One）。

为什么？因为在 Tana 中，每一类信息都有属于它的结构化字段。记录的过程就是对信息的理解、消化的过程。通过这种「问答」的模式我已经可以获得完成度很高的信息。导入到 Heptabase 后，不需要做太多调整，直接就能用。

这其实又回到了我们前面说的那个核心问题：工具只是承载逻辑的方法。关键是你如何理解知识，如何构建自己的思考框架。这个想明白了，Tana 和 Heptabase 就不再是竞争关系，而是不同场景下的能力互补。

所以我说，对于知识管理这件事，不要执着于 All in One。因为相比在多个工具间交换信息的少量成本，All in One 的代价往往更大。它不仅让效率下降，还容易让你的思考被工具的边界限制住。

更重要的是，当你痴迷于找一个完美工具时，你其实是在逃避一个更根本的问题。工具永远只是工具，你对自己思维方式的理解，才是决定工具能发挥多大价值的关键。

所以我建议在确定选择某一个工具之前，不妨先想清楚自己的需求是什么，思考流程是什么，然后找到最适配每个环节的工具。哪怕要用两个、三个，只要它们能组合起来支撑你的思考流程，就是好的。

相较于一个成熟的体系，多一两个工具的成本其实不值一提。

写在最后

从产品层面看，所有笔记工具归根到底就是「增删改查」加「视图呈现」。功能上不会有太大差异。但这不是重点，重点是我们为什么要做知识管理？这个问题听起来很虚，但想清楚了，很多困扰就不存在了。

如果你做知识管理的目的，是为了存储更多信息，那任何工具都能满足你。但如果你的目的是更好地思考，那工具的选择就变成了另一个问题：它能不能帮我把思维过程显性化？能不能让我看见自己是怎么思考的？

这才是 Heptabase 和 Tana 真正吸引我的地方。

它们不只是在帮我管理信息，而是在逼我去理解自己的思维方式。Heptabase 让我看见思考的空间结构，Tana 让我定义思考的逻辑框架。同时你也不再会纠结用哪个功能、怎么分类、放在哪儿之类的问题，因为系统已经和你的思维方式融为一体。

所以回到我们今天文章的两位主角，如果你问我，Heptabase 和 Tana 到底该选哪个？我的回答会是先别着急选。先花点时间想清楚自己是怎么思考的，需要什么样的思考支持。然后你会发现，选 A 还是 B，还是A、B 都要，你已经有答案了。

当然最后还是得多说一句，知识管理的终点并不是建立一个完美的系统，而是让自己成为一个更清晰的思考者。工具只是起点，思考才是终点。

> 关注 少数派小红书，感受精彩数字生活 🍃

> 实用、好用的 正版软件，少数派为你呈现 🚀

    老家五线城市，离省城大概 200 公里，去年 10 月左右，让二老在家尝试代购了两次

    前期准备：
    小红书和抖音发了简单的《 XX 需要山姆代购的吗》，都设置地区投了流，小红书投了两次，每次 66 元，抖音投流一次 99 元。小红书私信+评论问的大概 20-40 人，抖音一个没有

    第一次是我在上海买了，寄顺丰回去，冰箱里面拿出来的寄了生鲜，其他的寄了普通，代购费收入 50 ，快递费支出 80 ，还不算二老在老家骑电动车送货的钱

    第二次是用我攒的 12306 积分，给我妈买了张去省城的高铁，买好了东西后然后坐我舅舅回家的顺风车回来，不算高铁票和顺风车的话，这次等于没有支出，代购费收入了 90 元

    就做了两次，随后我爸觉得没有钱赚，还会亏很长一段时间，就叫停了
    山姆的开卡费第一次是我自己开的，第二次我妈开的，我俩后来都退掉了，等于没花钱

    大家或者身边的人有没有做这个的呢，感觉最重要还是圈子集中不起来，有没有好的建议，准备年后再试一次看看

    历时 10 个月，我开发了个记录 APP

    大家好，在断断续续开发了 10 个月后，我想给大家重新介绍一下这款 APP 。（以下内容有小部分由 AI 写成）

    开发背景

    简单说一说开发这款工具的背景，之前那篇文章也说过：在 AI 记录应用满天飞的时代，我却反其道而行，做了个纯粹的记录应用 - 少数派 ，这里再简单说说：

    在 2025 年 3 、4 月份：那段时间我非常厌倦写代码，每天上班都在想“要不要离职”，感觉非常痛苦，当时想着如果离职想法超过 20 次，就提离职，所以我需要一个记录离职想法的地方，用于量化我的内心想法——想记下每次的心情、原因，还要标注“想离职的强度”，偶尔不爽时还想录段语音吐槽。

    我翻遍了 App Store ，却没找到一款能满足这种「量化想法 + 情感记录」的工具：要么功能太复杂，要么数据存在第三方服务器不放心，要么就是满屏广告。既然找不到，那就自己开发吧！

    没想到 App 还没做完，我就提了离职了，不过最后也没离职，因为我厌倦的是写代码，所以内部转岗了，后续又出差了大半年，就是在出差过程中，这个“记录想法”的需求却越来越清晰：它不仅能记“离职倒计时”这种有目标的念头，还能记录生活里的闪念、灵感、吐槽，甚至是不想发朋友圈、微博的“私密碎碎念”——毕竟那些平台有审查风险，谁也不想哪天自己的记录突然消失。

    好了，这大概就是「加一 - 想法量化与决策助手」的由来。

    ‎加一 - 想法量化与决策助手 App - App Store

    有想法就记录

    有想法，然后针对这个想法去记录。这是我日常的记录。

    实际上我已经记录了 500 多条了，是该应用的疯狂使用者，每天都记录很多内容，也正是因为自己大量使用，所以才发现 APP 一个又一个问题，以及贴近使用者的最真实的需求。

    添加想法、添加记录就是这么简单。

    内置两种想法模式，一种是带有目标的，一种是备忘录模式

    想法和记录都有不同的视图，自由切换随你自己。

    Local First ，把数据主动权握在自己手里

    用任何工具之前，我先会想到的是这个 APP 把用户的数据存放在哪里？会不会后续不再维护了，那我的数据怎么办？再者如果会存放一些私密数据的，还会考虑数据是否会泄露出去。

    因为这些原因，我开发的 APP 最主要的目标是，Local First 。

    特性 理想 Local First 工具标准 「加一」实测体验
    数据存储 本地为主，云端仅作同步/备份 ✔ 主数据存在本地，iCloud 同步（后续将支持 WebDAV ），云端只存备份副本
    离线工作 断网不影响核心功能 ✔ 地铁、电梯、飞机里照样随手记，完全不受网络限制
    响应速度 无延迟，即时反馈 ✔ 打开 App 、写记录、搜内容都是秒开，比依赖云端的工具快太多
    数据所有权 可自由导出、迁移 ✔ 支持 Html 、PDF 、JSON 、markdown 等多种格式导出，导出能够本地打开，还能完整导入回「加一」
    隐私安全 敏感数据不泄露 ✔ 除了主动开启 AI 分析时会上传到 Deepseek ，无任何后台偷传数据

    所有数据支持多种数据格式导出（图片、音频、文字等等），同时支持将导出数据导入到 Obsidian 或者苹果备忘录、或者以时光回忆录模式导出为 PDF 文档。

    导出后的数据，还支持完整恢复导入到加一应用中，同时支持 flomo 数据导入，方便数据迁移。

    并且现在有 AI 大模型加持，很多人会将数据发给 AI 进行分析，所以也支持将所有数据（图文、音频等）全部导出。

    你的数据，随时可以搬家，我们不搞围墙。

    自定义主题 + 字体，原生也能有个性

    除了本地优先原则，我个人对个性化也非常推崇，所以加一 APP 内置了多个开源和可商用的字体，个人非常喜欢霞鹜文楷的字体，感谢作者开源。

    同时内置了诸多个性主题，我本人是一个锤子手机爱好者，所以还特别内置了锤子风格主题，我很喜欢。

    生物解锁，守护隐私安全

    有时候记录了一些事情不想让别人知道，所以还加了个锁，后续如果有必要的话，还可以针对每个想法进行加锁，允许用户设置密码等操作。

    搜索和小组件

    APP 里面有多种搜索方式，支持快速找到想要的内容。

    同时还支持桌面小组件和锁屏小组件，一切都是为了快速记录。

    AI ，让想法更有价值

    如果你想让 AI 分析你的想法，那么设置一下自己的 API key 即可。所有数据直达 DeepSeek ，APP 不会获取你的一丁点信息。

    统计分析：量化你的“起心动念”

    数据多了就可以进行统计分析，很酷的，细节非常多，快来体验体验。

    谁适合用「加一」？

    • 不放心数据存在第三方平台的「隐私敏感型用户」；
    • 喜欢随手记闪念、吐槽、灵感，不想被 AI 打扰的「纯粹记录党」；
    • 需要量化想法、分析趋势的「决策纠结症患者」；
    • 用过 Obsidian 、Craft 但觉得“移动端不好用”“太复杂”的「工具党」；
    • 想找一个“无广告、无冗余功能”的「轻量化记录工具」。

    欢迎体验，几乎所有国家都可体验，有任何问题可以在 APP 内提交反馈。 ‎加一 - 想法量化与决策助手 App - App Store

    最后说句心里话

    最后，我想说一些我个人的一点小看法：

    Ai 时代，一些知识获取的成本极大降低，很多时候都不需要特意去记录，比如大段的代码，大批量的数据，很多技巧之类的，因为你随时可以问到，不用求教于其他人，成本极低且准确度很高。

    所以我觉得这个时代，仅从我自身来说，我已经很少做笔记了，之前还收藏有用的代码，一些配置，现在 Obsidian 我就用于写长文，或者会议纪要，年终汇报，以及日常遇到复杂问题的解决方案。

    这时代来临，我觉得反而内心的一些小触动，小想法，起心动念是容易被自己忽略掉的，这也是这个时代属于自己弥足珍贵的资产，因为你不是 ai ，你的想法是原汁原味的，是最纯粹的。AI 变化再快，你还是你，你还是有自己一地鸡毛的生活，或是在当牛做马或者逍遥快活。

    AI 时代，留住你的本真。👉 App Store 传送门 ‎加一 - 想法量化与决策助手 App - App Store。

    ToB企业获客-转化闭环能力横评：超兔、Capsule、Pipedrive、Insightly谁更适配？

    在ToB市场，“获客难、转化低、流程散”是企业的共同痛点。从精准定位潜在客户，到高效推进商机转化，再到流程优化迭代，一套完整的获客-转化 闭环系统成为企业破局的关键。本文选取四款主流CRM产品——超兔一体云（全链路深度整合）、Capsule（精准触达决策人）、Pipedrive（销售流程可视化）、Insightly（中小企入门），从工商搜客、客户查重与补全、AI跟单、销售目标管理、自动日报与行动分析五大核心维度展开横向对比，为企业选型提供参考。

    一、对比框架：ToB获客转化的底层逻辑

    ToB获客-转化闭环的本质是“数据驱动-流程自动化-策略迭代”的循环：

    1. 从工商/多源数据中精准筛选潜在客户；
    2. 补全客户信息、避免重复跟进；
    3. 用AI预判需求、自动推进商机；
    4. 将销售目标分解为可执行任务；
    5. 通过行动记录分析优化策略，反哺获客环节。

    基于这一逻辑，本文从“精准获客→信息完善→商机推进→目标管控→策略优化”五大环节展开对比。

    二、核心维度横向对比

    1. 工商搜客精准获客：从“广撒网”到“精准钓”

    工商数据是ToB获客的“源头”，但传统模式需跨多平台检索，效率低下。四款产品的差异在于数据来源的丰富度和筛选的精准度：

    维度超兔一体云CapsulePipedriveInsightly
    数据来源整合官方工商登记、工商信息查工商+招投标动态+招聘需求+融资记录工商数据+API集成第三方平台工商数据
    筛选能力支持“行业+规模+地域”多标签组合筛选，精准定位目标客户同样支持多标签组合，且关联“招聘/融资”动态（如“招聘智能工厂岗位”=潜在产线升级需求）基础工商搜索，需API扩展数据维度基础工商搜客，满足精准定位
    效率提升替代多平台交叉检索，直接获取线索多源数据整合，避免“漏查”潜在客户API集成减少平台切换，但需额外配置中小企快速入门

    总结：Capsule的“多源数据”适合挖掘“隐藏需求”（如通过招聘动态预判采购意向）；超兔的“精准筛选”更侧重“直接匹配客户”。

    2. 客户查重与工商信息补全：避免“无效沟通”的关键

    ToB销售中，“撞单”和“信息不全”是两大痛点。四款产品的差异在于查重的全面性和信息补全的深度：

    维度超兔一体云CapsulePipedriveInsightly
    查重机制自动比对“名称、手机号”，支持自定义规则+企业简称模糊查重（如“阿里”=“阿里巴巴”）自动识别重复客户信息自动查重，避免销售撞单自动查重
    工商信息补全同步补全“注册资本、成立时间、参保人数”，额外支持： - 手机号关联微信/支付宝头像； - 工商地址标记经纬度补全“注册资本、参保人数、高管架构”，核心优势是“关联企业图谱”——锁定决策链核心人员（如实际控制人）需手动录入或API集成补全自动补全基础工商信息
    决策链价值地址经纬度辅助线下拜访直接锁定“拍板人”，减少无效沟通无明确决策人定位无明确决策人定位

    总结：超兔的“简称模糊查重”适合ToB企业；Capsule的“关联企业图谱”是其核心亮点，适合需要触达决策层的行业（如工业设备）。

    3. AI跟单智能体：从“被动跟进”到“主动预判”

    AI的价值是用数据替代经验，预判需求并自动推进商机。四款产品的差异在于AI与业务数据的融合深度：

    维度超兔一体云CapsulePipedriveInsightly
    智能体配置低门槛自定义智能体，嵌入“客户/行动视图”，融合历史沟通、需求偏好等业务数据基于“AI意图预测模型”，分析招聘、专利等外部动态聚焦“销售管线”，生成跟进时机建议基础AI功能，自动推进商机
    自动化能力自动生成“个性化跟单策略”（如推荐话术、跟进时间），创建待办提醒；支持调用Coze工作流自动触发跟进提醒，生成“针对性话术”（如“产线升级解决方案”），并通过邮件/社交触达拖拽式调整商机阶段，自动触发跟进动作自动推进商机，减少人工遗漏
    数据依赖深度融合业务数据，AI建议更贴合实际依赖外部动态数据，适合“需求未明确”的客户依赖历史销售数据，适合流程标准化业务依赖客户交互数据，基础功能

    总结：超兔的“自定义智能体+业务数据融合”适合业务复杂的企业（如定制化解决方案）；Capsule的“AI意图预测”适合需求隐藏的行业（如企业服务）。

    4. 销售目标管理：从“抽象目标”到“可执行任务”

    销售目标的核心是“分解”与“追踪” ——将公司目标拆解为个人任务，并实时监控进度。四款产品的差异在于目标分解的颗粒度和追踪的直观性：

    维度超兔一体云CapsulePipedriveInsightly
    目标分解从“公司→部门→个人→具体业务指标”（如“本月应收款100万”“新增客户20个”）支持“团队/个人目标”，未明确到业务环节支持“团队/个人目标”，聚焦业绩预测基础目标设定，满足中小企需求
    进度追踪用“红绿灯标识”直观展示目标完成情况（红=危险、黄=卡滞、绿=顺利），关联客户行动记录实时追踪商机转化进度，但无可视化标识可视化销售漏斗，展示“线索→成单”转化比例基础进度监控，无可视化增强
    考核与激励内置激励机制，根据目标完成情况自动计算奖励无明确考核功能支持团队绩效分析，辅助考核决策无明确考核功能

    总结：超兔的“目标分解到业务环节”和“红绿灯追踪”适合强目标管控的中大型企业；Pipedrive的“业绩预测”适合数据驱动决策的团队。

    5. 自动日报与行动记录分析：从“经验复盘”到“数据复盘”

    日报与行动分析的价值是将隐性经验转化为显性策略，反哺获客环节。四款产品的差异在于记录的全面性和分析的深度：

    维度超兔一体云CapsulePipedriveInsightly
    日报生成自动汇总“签约金额、新建客户、跟进情况”，支持销售人员补充主观分析（如“客户顾虑是预算”）自动记录沟通/跟进动作，生成简洁日报自动记录客户交互历史，生成详细报告自动生成日报，基础功能
    行动分析分析“沟通内容、跟进频率、转化瓶颈”（如“某客户跟进5次未成交”=“需求未匹配”），给出优化建议生成“行为分析报告”，可视化客户转化路径（如“从线索到成单需8次跟进”）可视化转化路径，分析跟进效率（如“某环节转化率低”=“话术优化”）基础行动分析，辅助策略优化
    迭代价值分析结果反哺“获客策略”（如“某行业转化低”=“调整工商搜客条件”）反哺“跟单策略”（如“某类客户需7天内跟进”）反哺“流程优化”（如“简化某环节”）基础迭代支持，适合中小企

    总结：超兔的“主观分析+瓶颈定位”适合深度优化策略的企业；Capsule的“转化路径可视化”适合流程标准化的业务。

    三、整体闭环能力：谁的循环更“丝滑”？

    ToB闭环的关键是各环节无缝衔接——数据自动流转，无需人工重复录入。四款产品的闭环完整性如下：

    品牌闭环完整性核心优势适合场景
    超兔一体云全链路深度整合：工商搜客→查重补全→AI跟单→目标管理→日报分析全链路数据融合，策略迭代更精准中大型ToB企业，业务复杂
    Capsule聚焦“获客-触达-转化”：多源数据→AI意图预测→决策链定位→行动分析精准触达决策人，适合长周期业务工业设备、企业服务等“需求隐藏”行业
    Pipedrive聚焦“销售流程管控”：工商搜客→商机阶段→业绩预测→行动分析销售流程可视化，适合流程标准化业务SaaS、软件销售等“短平快”业务
    Insightly基础闭环覆盖：工商搜客→查重补全→AI跟单→目标管理→日报分析功能全面，价格亲民初创/中小ToB企业，预算有限

    四、可视化呈现：用图表看懂差异

    1. 获客转化闭环流程图

    graph TD
    A[工商搜客精准获客] --> B[客户查重与工商信息补全]
    B --> C[AI跟单智能体推进商机]
    C --> D[销售目标管理]
    D --> E[自动日报与行动记录分析]
    E --> A[优化获客策略]

    2. 核心能力脑图

    mindmap
    root((ToB获客转化核心能力))
        工商搜客精准获客
            超兔：工商数据整合+精准筛选
            Capsule：多源数据（工商+招投标+招聘）
            Pipedrive：工商搜索+API集成
            Insightly：基础工商搜客
        客户查重与补全
            超兔：模糊查重+微信/地址补全
            Capsule：关联企业图谱+决策人定位
            Pipedrive：手动/集成补全
            Insightly：基础补全
        AI跟单智能体
            超兔：自定义智能体+业务数据融合
            Capsule：AI意图预测+自动触达
            Pipedrive：销售管线+自动化
            Insightly：基础AI功能
        销售目标管理
            超兔：目标分解+红绿灯追踪
            Capsule：团队/个人目标
            Pipedrive：业绩预测+可视化
            Insightly：基础目标管理
        自动日报与分析
            超兔：主观分析+瓶颈定位
            Capsule：转化路径可视化
            Pipedrive：流程优化
            Insightly：基础分析

    3. 雷达图：各维度能力分值（1-5分）

    维度超兔CapsulePipedriveInsightly
    工商搜客5433
    客户查重与补全5433
    AI跟单智能体5443
    销售目标管理5343
    自动日报与分析5443
    整体闭环能力5443

    五、选型建议：根据需求选对工具

    1. 中大型ToB企业，业务复杂：选超兔一体云——全链路深度整合，贴合复杂业务需求，尤其是“业务数据融合”和“策略迭代”能力，提升转化效率。
    2. 需要精准触达决策人：选Capsule——关联企业图谱锁定“拍板人”，避免无效沟通，适合工业设备、企业服务等“长周期”业务。
    3. 注重销售流程可视化：选Pipedrive——销售漏斗、业绩预测等功能，让流程更可控，适合SaaS、软件销售等“短平快”业务。
    4. 初创/中小ToB企业，预算有限：选Insightly——基础功能覆盖，价格亲民，适合快速入门。

    结语

    ToB获客-转化闭环的核心是“数据驱动”与“流程自动化”的结合。超兔的“全链路整合”、Capsule的“精准触达”、Pipedrive的“流程可视化”，代表了当前ToB CRM的三大方向。企业选型时，需结合业务场景、客户类型、团队规模，选择最贴合自身需求的工具——适合的才是最好的。

    随着人工智能（AI）技术的不断进步和广泛应用，AI已经渗透到金融、医疗、制造、自动驾驶等多个行业。尽管AI带来了巨大的创新和效率提升，但随着其应用范围的扩大，AI的安全性问题也逐渐暴露出来。AI应用安全不仅仅局限于算法模型的本身，更多的是涉及数据隐私、对抗攻击、模型滥用、合规性问题以及垂直行业应用中的特殊风险。因此，企业需要全面识别并应对这些AI应用中的潜在风险，构建健全的AI安全管理体系。

    一、AI应用安全的核心挑战
    AI应用的安全风险源自多个层面，既包括算法层面的风险，也涉及数据、系统、法律等多维度的安全隐患。
    1.1 AI模型算法滥用风险
    随着AI生成内容的普及，模型算法的滥用已成为迫切需要解决的安全隐患。特别是在生成式AI领域，AI模型可能被用来生成虚假信息、深度伪造内容等，直接影响社会舆论，甚至对企业造成直接经济损失。

    1. 虚假有害信息的传播：生成的AI内容可能被恶意用于传播虚假信息、误导公众、制造恐慌或进行欺诈活动。例如，某些不法分子利用AI生成的新闻报道或虚假视频，制造社会不稳定因素。
    2. 多模态深度伪造的风险：深度伪造技术融合了视频、音频、文本等多模态内容，生成高度逼真的虚假信息。这类攻击不仅可能带来经济损失，还会破坏公众的信任基础，影响法律和社会规范的实施。
    3. 模型透明性不足：AI应用在实际运行中，许多模型尤其是复杂的深度学习模型，往往缺乏足够的透明度，用户无法理解模型的决策过程。这种“黑箱”性质不仅增加了用户的使用风险，也使得当出现错误决策时，问题难以被迅速定位和解决。

    1.2 AI应用开发安全风险
    AI应用开发不仅仅是技术问题，还涉及硬件、软件以及协同环境的整合，这就使得AI开发中的安全风险更加复杂和多样化。

    1. 端侧AI安全风险：在边缘计算环境中，由于端侧设备的硬件限制，AI模型可能需要进行压缩或优化，这样的处理虽然可以提升运行效率，但也可能导致模型的鲁棒性和安全性下降，出现性能下降或“安全税”现象。此外，端侧部署通常要求在设备端实现实时推理，并依赖云边协同架构进行模型更新和任务调度，这也带来了异构硬件兼容性和网络延迟等潜在风险。
    2. 智能体的安全风险：AI智能体是由AI模型驱动的自主系统，能够执行复杂任务。随着AI智能体与外部环境的不断交互，智能体的安全风险也在增加。攻击者可能通过篡改协议或利用自主决策链路的不可预测性，导致智能体做出错误决策，从而产生安全漏洞。
    3. 具身智能的安全隐患：具身智能涉及到现实世界中的物理行动，其安全风险不容忽视。传感器设备可能泄露个人信息，具身智能体的物理行为可能被恶意攻击者控制，从而导致人身伤害或财产损失。例如，服务机器人操作不当，或自动驾驶汽车发生事故，都是具身智能安全风险的典型表现。
    4. 智能物联网（AIoT）安全：智能物联网设备融合了AI算法与物联网的物理特性，部署在受限的边缘环境中，面临着传感器噪声、物理攻击、以及复杂环境干扰等问题。与传统物联网设备相比，AIoT还面临着AI特有的安全威胁，如对抗样本攻击、训练数据投毒和模型窃取等问题。

    1.3 AI垂直行业应用的安全风险
    AI技术在垂直行业的应用，虽然带来了行业的革新，但也带来了独特的安全风险。不同的行业面临的AI应用安全问题各具特点。

    1. AI在医疗行业的安全风险：AI在医疗领域的应用极大地提高了诊断效率和精确度，但也伴随着巨大的技术与伦理风险。训练数据的偏差、系统漏洞可能导致医疗设备发生错误，甚至误诊。此外，AI系统在处理敏感的患者信息时，若未采取充分的加密与权限管理，可能会导致患者隐私泄露，进而带来法律与伦理上的问题。
    2. AI在新闻领域的滥用风险：随着AI生成内容技术的普及，新闻行业面临着虚假新闻传播的风险。某些不法分子可能利用AI模型生成虚假报道、伪造证据，借此操纵舆论或进行诈骗活动。如何确保生成内容的真实性与可信度，成为新闻行业亟待解决的安全挑战。
    3. AI在金融行业的安全风险：金融行业的AI应用包括身份验证、交易监控等多个方面，面临着深度伪造技术带来的身份验证问题。攻击者通过深度伪造技术伪造身份信息，可能突破金融机构的身份核查系统，实施盗刷或恶意注册等欺诈行为，造成极大的经济损失。
    4. AI在编程领域的安全风险：AI辅助编程不仅提高了开发效率，但也带来了代码安全隐患。AI生成的代码可能存在常见漏洞（如SQL注入、跨站脚本攻击等），同时AI生成的代码缺乏架构设计，可能导致后期维护困难。由于过度依赖AI生成的代码，开发人员可能减少了必要的人工审查，从而放大了潜在的安全风险。

    二、AI应用安全的解决方案与应对措施
    针对上述AI应用中的安全风险，企业需要采取多维度的防护措施，构建全方位的AI安全管理体系。
    2.1 提高模型的鲁棒性和透明性
    为了应对AI模型的滥用风险，企业应加大对AI模型的鲁棒性和透明度的建设。例如，采用对抗训练增强模型的抗干扰能力，采用可解释性AI（XAI）技术提升模型的透明度，帮助用户理解决策过程，从而降低不当信任的风险。
    2.2 强化数据保护与隐私管理
    在AI应用过程中，数据是最核心的资产之一。企业应实施数据加密、访问控制、数据脱敏等技术，确保数据的隐私性和安全性。此外，企业应遵守相关的法律法规，如GDPR等，确保数据使用的合法合规。
    2.3 强化安全检测与监控
    企业需要在AI模型开发与应用过程中加入安全检测与监控机制，实时发现潜在的安全隐患。例如，利用自动化工具扫描AI模型的依赖组件，识别潜在漏洞，及时修复，并部署AI安全监控系统，实时监控模型的运行状态和异常行为。
    2.4 建立合规性框架
    AI应用不仅要在技术上保障安全，还需要满足法律法规的合规性要求。企业应构建全面的AI合规性框架，制定AI应用的合规性审查标准，确保AI技术在法律法规框架下运行。

    三、艾体宝Mend价值
    Mend通过其全面的软件组成分析（SCA）与依赖治理功能，在模型安全方面发挥了关键作用，帮助企业应对AI模型开发、训练、部署和维护过程中面临的安全挑战。具体价值体现在以下几个方面：

    3.1 识别和治理AI应用依赖中的安全风险
    AI应用往往依赖于多个开源库和第三方组件，而这些组件可能带有安全隐患。Mend通过自动化的SCA工具，能够深入识别和分析AI应用中所依赖的开源库及第三方组件，实时扫描每个依赖组件的安全风险。无论是AI平台、训练框架、容器镜像，还是MLOps流水线中的每一层，Mend都能够精确检测出潜在的漏洞、许可证问题和版本不兼容等安全风险。企业可以借助Mend的实时扫描功能，提前识别并解决这些隐患，避免将不安全的依赖组件引入AI应用，从而减少因依赖漏洞带来的应用安全风险。

    3.2 构建透明的SBOM体系，确保合规性
    AI应用不仅需要从技术层面防护，还必须符合相关的合规要求。Mend帮助企业构建和管理全面的安全SBOM（软件物料清单）体系，生成覆盖整个AI应用栈的SBOM清单。这一清单为合规审计、漏洞报告和监管备案提供了透明和准确的数据支持。通过Mend的SBOM工具，企业能够清晰地掌握AI应用中每个组件的来源、版本及其安全状况，从而确保模型和应用的安全性与合规性，避免因信息不透明而引发的法律和合规问题。通过这种全面的管理，Mend帮助企业在复杂的合规环境中确保AI应用的合法性与合规性。

    3.3 防范对抗攻击与漏洞利用
    Mend通过对AI模型进行真实的红队模拟交互，模拟攻击者的行为，测试模型对恶意输入、提示词注入以及其他对抗攻击的防御能力。Mend通过模拟各种可能的攻击情境，实际验证模型在面对各种恶意输入时的响应能力和稳定性。通过这种方式，Mend能够识别出潜在的安全漏洞，并提供针对性的防御策略，帮助企业提前发现并修复可能被攻击者利用的弱点。

    摘要：
    OceanBase联合成都信息工程大学的数据库缺陷实证研究，被软件工程顶刊IEEE TKDE录用。研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题，提出一种分层协作的多智能体框架，通过创新的训练机制与协同策略，有效破解传统调优方法的瓶颈，为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。

    近日，成都信息工程大学与 OceanBase 研发团队合作完成的研究《CMA+DB: How to Automatically Tune Database Parameters through Collaborative Multi-Agents》，被《IEEE Transactions on Knowledge and Data Engineering》（TKDE，CCF A 类、SCI 一区）录用。

    研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题，提出一种分层协作的多智能体框架，通过创新的训练机制与协同策略，有效破解传统调优方法的瓶颈，为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。

    以下为论文介绍：

    研究背景与挑战

    随着分布式与云计算技术的发展，数据库工作负载日趋多样化、复杂化。从高并发的在线交易场景（TPC-C），到随机读写的云服务场景（YCSB），再到高实时性的社交互动场景（Twitter），不同场景对参数配置的需求差异显著。

    传统调优方式逐渐难以适配这些实际需求：人工调优高度依赖 DBA 的专业经验，不仅需要耗费大量时间梳理参数关系，而且无法应对动态变化的工作负载，往往出现 “调优即过时” 的问题；搜索式调优方法依赖启发式规则，在简单场景下表现尚可，但面对多参数交互的复杂场景时，搜索空间急剧扩大，调优效率大幅下降；贝叶斯优化方法需要手动筛选关键参数，若参数定义不全面，难以找到最优配置；现有强化学习调优方法多采用单智能体设计，仅能对参数进行粗粒度调优，无法充分挖掘不同类型参数间的深层交互影响，调优精度和泛化能力受限。

    如何实现参数调优的自动化、精准化与高效化，成为数据库领域亟待解决的关键问题。


    图1 数据库参数调优主要步骤

    核心理论创新：CMA+DB 多智能体协作框架

    CMA+DB 框架以 “分类协作、分层训练” 为核心设计理念，构建了三级递进式训练机制，整合单智能体预训练模型 SAPM、多智能体联合训练模型 MATM 与基于概率选择的联合训练模型 PJTM，既保障了单个参数类别内的调优深度，又实现了跨类别参数的协同优化。

    三个子模型并非孤立存在，而是以级联方式递进工作，前一阶段的训练成果直接作为后一阶段的输入，形成 “基础专精—交互探索—精准强化” 的完整调优链路，确保框架在参数交互捕捉、调优效率与泛化能力之间实现最优平衡。


    图2 CMA+DB 模型工作原理

    在技术实现上，CMA+DB 基于深度确定性策略梯度（DDPG）与多智能体深度确定性策略梯度（MADDPG）构建核心算法架构，采用 Actor-Critic 网络结构实现智能体的决策与优化。每个智能体都具备独立的观测空间与动作空间，通过与数据库环境的持续交互获取反馈，不断优化参数调优策略。


    图3 多智能体 Actor 和 Critic 网络结构

    在第一阶段，提出单智能体预训练模型 SAPM。训练初期，每个 Agent 负责调优一类功能或参数级别相似的参数，目的是探究单个 Agent 对数据库性能的影响，进而优化其网络，使得其神经网络偏向于调节重要参数。该过程 Agent 之间相互不影响。与传统的单智能体模型相比，SAPM 模型的优点在于更深入地探究相似参数之间的关系，也更容易识别出一些重要参数。

    这一阶段对于识别关键参数和实现快速收敛至关重要。通过使智能体能够初步掌握参数调整策略，SAPM 为后续更复杂的多智能体训练奠定了坚实的基础，并减少后续阶段的耦合干扰，从而提高了整体效率和效果。

    在第二阶段，提出多智能体联合训练模型 MATM，在 MATM 模型训练阶段，使用组合算法将多个 Agent 的预测动作组合并映射为一组数据库的推荐配置，要求 Agent 之间不能存在相同的数据库参数。

    这种协作方法不仅增加了可调参数的数量，还显著增强了模型的表现力和调整能力。此阶段虽然存在耦合，但通过联合训练，能够让智能体逐步适应彼此的行为模式，实现协同优化。

    在第三阶段，提出了联合动作概选模型 PJTM，在 SAPM 和 MATM 模型训练之后进行训练，算法为每个 Agent 设置了一个概选因子 Pi， Agent 根据 Pi，随机地参与联合动作推荐。当一个 Agent 控制的数据库参数对数据库性能的提升微乎其微时，就可以根据 Pi 减小该 Agent 的动作参与，进而降低其对其它 Agent 所做动作的负面影响。这一机制有效减少了低影响智能体对整体调优过程的干扰，缓解了耦合带来的负面影响。

    基于上述三种方式，提出协作型多智能体模型 CMA+DB，其整合 SAPM、MATM 和 PJTM 模型进行分阶段训练，实现分功能、分级别地对数据库参数进行调优。探究了相同类型参数之间的相互影响以及不同类型参数之间的协作关系。有效地解决了离散环境和异步反馈的挑战，确保多个智能体的动作是协调的，并针对数据库性能进行了优化，提高了数据库参数的调优数量，提升了数据库参数调优的效率。

    关键验证成果

    相关研究成果已在 PostgreSQL 数据库环境下，在 TPC-C、YCSB、Twitter 三种典型工作负载上，与主流调优方法进行全面对比验证，核心性能指标表现突出且稳定。

    在调优效率方面，CMA+DB 的收敛速度优势显著。在 TPC-C 高并发交易场景中，这一优势尤为明显，CMA+DB 的平均收敛速度（达到最大吞吐量时）优于其他三种算法。能帮助数据库更快脱离性能波动期，进入最优稳定状态，大幅缩短调优耗时，降低系统上线或扩容后的性能适配成本。

    在性能提升方面，CMA+DB 展现出持续优化的能力。经过 SAPM 预训练后，框架的吞吐量已优于现有部分主流方法；后续经 MATM 的跨类别参数协同优化，以及 PJTM 的精准强化，在 TPC-C 场景下，其延迟显著低于 OtterTune、CDBTune+ 等方法，有效保障了系统在峰值压力下的响应稳定性，避免了因参数配置不当导致的延迟突增问题。

    在泛化能力方面，CMA+DB 表现出极强的适应性。实验结果表明，不同参数规模与智能体数量的组合测试显示，CMA+DB 能够根据实际场景灵活调整，无需人工干预即可适配不同规模的数据库参数调优需求，解决了传统方法在参数规模变化时泛化能力下降的问题。

    总结与展望

    作为一种兼具理论深度与工程价值的数据库参数自动调优方案，CMA+DB 框架通过多智能体分类协作与分层训练的创新设计，有效解决了传统方法在参数交互探索、调优效率与泛化能力上的短板，为 AI 赋能数据库优化领域提供了新的技术思路。

    该框架的核心优势在于，不但实现了参数调优的自动化与精准化，而且无需依赖大量人工干预与领域知识，降低了数据库性能优化的门槛，具备较强的应用价值。

    未来研究将进一步优化框架结构，通过算法改进降低计算复杂度，提升框架在超大规模参数场景下的运行效率；同时，将尝试适配 MySQL、OceanBase 等更多主流 DBMS，针对不同数据库的内核特性调整智能体的参数分类与协作策略，推动相关技术在金融、电商、社交等实际生产环境中的广泛应用，为数据库系统的性能优化提供更高效、更通用的解决方案。

    欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

    简介
    在生成式AI快速普及的背景下，企业的数据安全体系正遭遇前所未有的冲击。除了传统攻击与人为失误风险之外，AI工具带来的“影子AI使用”、训练数据泄露、提示词注入攻击等新型风险正在重塑数据泄露的威胁版图。本文系统分析AI驱动的数据安全挑战，并提出面向企业的数据安全策略。文末重点介绍了 Lepide 数据安全平台如何通过数据发现、权限治理和持续监控三大能力，为企业构建“可见、可控、可预警”的 AI 安全基础。
    关键词
    数据安全、AI安全、生成式AI、DLP、UEBA、零信任、影子AI、数据治理、Lepide

    一、AI时代的数据安全风险在加速叠加
    根据 IBM《2023年数据泄露成本报告》，全球数据泄露的平均成本已上升至 488万美元，同比增长 10%，达到历史最高水平。这一增长源于 传统风险 与 AI引发的新型风险 的同步扩张：
    ● 传统风险依然严峻

    • 人为误操作
    • 弱口令与权限滥用
    • 云资源配置错误
    • AD 环境老化与脆弱性

    ● AI带来的新兴风险快速增加

    • 员工将敏感内容输入 ChatGPT 等公共AI
    • AI 模型训练数据误泄露
    • AI生成内容的版权与治理争议
    • 大模型接口连接带来的供应链安全风险
      传统弱点与AI风险的叠加，使得企业需要重新审视数据安全体系的可控性。

    二、企业应采取的 AI 数据防泄漏核心策略
    1.数据分类与持续监控
    建立企业级数据资产清单是 AI 时代的首要任务。
    需要重点识别与持续监控的内容包括：

    • PII/个人隐私数据
    • 商业机密与知识产权
    • 财务及法律文件
    • 研发资料与源代码
      建议利用自动化扫描构建 动态数据地图，并至少每季度更新一次敏感数据资产清单。

    2.强化访问控制与零信任治理
    采用 RBAC + 零信任模型，持续收紧高风险权限，包括：

    • 强制 MFA + SSO
    • 微隔离策略阻断横向移动
    • 按需赋权（Just-In-Time Access）
    • 全量记录权限变更日志
      特别是在部署 Copilot、ChatGPT 企业版等 AI 工具前，务必确保敏感数据仅对必需人员可见。

    3.AI工具准入与治理体系建设
    为 AI 工具建立完整治理流程，包括：

    • 安全评估与供应商审计
    • 加密传输要求
    • 日志留存要求
    • 接入流程与审批机制
    • 私有化部署优先处理敏感信息场景
      建议企业建设 受批准的 AI 工具目录（AI Allowlist）。

    4.影子AI检测与策略执行
    影子AI是2024–2025年增长最快的安全威胁之一。
    企业应：

    • 制定《AI 使用规范》
    • 网络层识别与阻断未授权 AI 服务
    • 建立异常使用监测机制（例如：大量复制粘贴文本到AI工具）

    5.增强型生成式AI防泄漏（Next-Gen DLP）
    下一代 DLP 需重点应对以下风险：

    • 提示词注入攻击（Prompt Injection）
    • 训练数据提取攻击
    • 向量数据库（Vector DB）泄露
    • 大模型接口暴露风险
      DLP 不再仅仅是内容关键字匹配，而是需要支持深度内容检测与 AI 行为分析。

    6.全生命周期审计与风险评估
    建立从输入提示词 → AI 输出结果的 完整交互审计链。
    采用 UEBA（用户行为分析）模型监控：

    • 异常下载量
    • 异常访问敏感文件夹
    • 高风险权限的频繁操作
    • 用户越权访问模式
      每半年进行一次 AI 风险专项评估，持续优化策略。

    7.员工培训与安全文化
    构建 AI 使用安全文化：

    • 专项 AI 安全意识课程
    • 《AI 数据红线清单》
    • 跨部门经验分享会
    • 通过案例强化“不能输入到AI中的数据”意识

    典型案例：
    三星 2023 年三起因员工将芯片设计代码输入 AI 工具而导致的泄密事件，正是缺少制度与意识教育的直接体现。

    三、Lepide：AI安全时代的智能化数据与权限治理平台
    Lepide 数据安全平台通过 数据发现、权限治理、持续监控 的三位一体架构，为企业构建 AI 安全基石。以下为优化后的描述，更突出产品核心能力与AI场景适配性。

    1.智能数据资产发现：为AI治理先建立“可见性”
    Lepide 通过专利扫描技术自动识别：

    • 文件服务器、NAS、SharePoint、M365 的敏感数据
    • 未授权存放的源代码、设计文件、PII
    • 敏感数据的访问频率、拥有者与暴露范围
      其“数据地图”实时更新，使企业在部署 AI 工具前即可明确哪些数据不可暴露给模型。

    2.高效权限治理：为AI安全打下“最小权限”基础
    Lepide 的权限分析引擎可在秒级完成一次全面权限扫描，自动识别：

    • 冗余权限
    • 开放共享
    • “全域可读”风险
    • 高权限账户异常
    • AD 中的危险委派与特权漂移
      在企业部署 Copilot、ChatGPT 企业版之前，这是确保安全基线的关键步骤。

    3.实时行为分析：在AI运行过程中持续“可控”
    Lepide UEBA 模型可：

    • 监控 AD 和 M365 中的关键操作
    • 捕获异常数据导出行为
    • 检测向 AI 工具大量复制敏感内容的可疑模式
    • 追踪试图规避访问控制的操作行为
      对于正在使用 AI 工具的企业，可以在出现“疑似泄密行为”前提前预警。

    4.自动化合规审计：满足 ISO27001、GDPR 等监管要求
    Lepide 可一键生成 AI 时代所需的关键报告：

    • 权限暴露报告
    • 数据敏感度报告
    • AD 关键操作审计
    • 风险评分与整改建议
    • 合规映射报告（ISO、GDPR、HIPAA 等）
      大幅降低 IT 与安全团队的手工审计工作量。

    5.AI风控专用能力：预警插件/API接入带来的风险
    针对越来越多企业通过插件、API 接入大模型，Lepide 可：

    • 监控第三方集成后数据的访问模式变化
    • 分析 AI 工具调用后是否增加敏感数据访问
    • 识别异常调用链条与跨系统数据流扩散
    • 在风险系数升高时触发主动防护策略
      帮助企业提前识别隐藏在“看不见的数据流”中的 AI 风险。

    四、总结：用Lepide构建AI时代的自适应数据安全体系
    随着 AI 深度融入企业业务流程，数据泄露风险不再局限于传统攻击面，而是渗透在员工日常使用 AI 工具的每一次交互中。

    Lepide 通过数据发现 → 权限治理 → 行为审计 → 风险预警的完整链路，为企业构建自适应数据安全屏障。

    采用 Lepide 的企业能够：

    • 在部署 AI 之前完成安全基线治理
    • 在 AI 使用过程中实现持续监控与预警
    • 在 AI 集成扩展时提前识别潜在风险
    • 在合规方面保持长期可持续性

    帮助企业在不牺牲安全的前提下，更安心地拥抱 AI。
    在数字化转型和AI技术日益普及的今天，确保企业数据安全变得尤为关键。通过部署 Lepide 数据安全平台，企业能够有效应对AI带来的新型数据泄露风险，并在合规与安全方面保持长期可持续性。如果您对Lepide解决方案感兴趣，欢迎联系我们的艾体宝IT团队，了解更多信息。

    常见问题解答（FAQs）
    Q1. 为什么防止生成式AI数据泄漏如此重要？
    数据泄漏可能导致财务损失、合规风险（如GDPR、HIPAA等）、公司声誉损害，以及可能的商业机密和知识产权泄露。因此，防止生成式AI的数据泄漏至关重要。

    Q2. 员工如何在不知情的情况下使用生成式AI工具导致数据泄漏？
    以下是几种常见情况：

    1. 在未经过合规性测试的情况下使用AI生成的工作成果；
    2. 请求AI设备分析或协助处理私人电子邮件；
    3. 分享未经去标识化的客户或个人数据；
    4. 将敏感和/或私人文档复制到AI对话中。

    Q3. 如果怀疑发生数据泄漏，应该怎么办？
    立即通知公司安全或合规团队，根据公司的事件响应政策采取行动，并记录泄漏数据的内容以及使用的工具。

    原文链接：https://www.nocobase.com/cn/blog/weekly-updates-20260129

    汇总一周产品更新日志，最新发布可以前往我们的博客查看。

    NocoBase 目前更新包括的版本更新包括三个分支：main ，next和 develop。

    version.png

    main ：截止目前最稳定的版本，推荐安装此版本。

    next：包含即将发布的新功能，经过初步测试的版本，可能存在部分已知或未知问题。主要面向测试用户，用于收集反馈和进一步优化功能。适合愿意提前体验新功能并提供反馈的测试用户。

    develop：开发中的版本，包含最新的功能代码，可能尚未完成或存在较多不稳定因素，主要用于内部开发和快速迭代。适合对产品功能前沿发展感兴趣的技术用户，但可能存在较多问题或不完整功能，不建议在生产环境中使用。

    main

    main.png

    v1.9.40

    发布时间：2026-01-25

    🚀 优化

    • [Office 文件预览] 支持更多文件类型在微软在线预览工具中预览 (#8500) by @mytharcher

    🐛 修复

    • [client]

      • 修复 nanoid 字段在表单提交后不重新生成数据的问题 (#8491) by @katherinehhh
      • 修复级联组件必填校验重复提示的问题 (#8476) by @katherinehhh

    • [database]

      • 修复数据表重载后使用 empty 操作符筛选报错的问题 (#8496) by @2013xile
      • 修复嵌套关联的深度更新问题 (#8492) by @chenos
    • [文件管理器] 修复上传文件时请求中的文件名被重复解码产生的乱码问题 (#8481) by @mytharcher
    • [数据源：主数据库] 修复在多对多关系表格区块中删除数据时，未遵循关系字段 onDelete: 'restrict' 约束的问题 (#8493) by @2013xile
    • [区块：iframe] 修复 Iframe 添加聚合变量报错的问题 (#8482) by @zhangzhonghe
    • [工作流：Webhook 触发器] 修复未配置请求体解析时触发器数据中该数据缺失的问题 by @mytharcher
    • [模板打印] 复了联合角色时打印按钮权限逻辑错误 by @jiannx

    • [工作流：审批]

      • 修复并发提交导致流程被重复恢复执行的问题 by @mytharcher
      • 修复分支模式的审批未能正确退回至指定节点的问题 by @mytharcher
    • [迁移管理] 修复迁移异常后打印异常对象所包含 SQL 过大容易卡死进程的问题 by @cgyrock

    next

    next.png

    v2.0.0-beta.17

    发布时间：2026-01-29

    🐛 修复

    • [client] 修复筛选相关的已知问题 (#8514) by @zhangzhonghe
    • [AI 员工] 修复构建后系统无法启动问题 (#8523) by @cgyrock
    • [AI: 知识库] 修复构建后系统无法启动问题 by @cgyrock

    v2.0.0-beta.16

    发布时间：2026-01-27

    🎉 新特性

    • [client] 新增子表格（弹窗编辑）字段组件 (#8280) by @katherinehhh
    • [工作流] 为移动节点增加 API (#8507) by @mytharcher

    🚀 优化

    • [client]

      • 修复单元格更新导致表格整体重渲染 (#8349) by @katherinehhh
      • 改进对多子表单默认包含一个对象，无需点击 Add New，未填写时不创建记录 (#8458) by @katherinehhh
    • [文件管理器] 为文件管理器增加可扩展的预览组件 (#8501) by @mytharcher
    • [工作流] 修改工作流子页面的路由路径，将工作流页面都统一在 /admin/settings/workflow 路径之下 (#8519) by @mytharcher

    🐛 修复

    • [client]

      • 修复筛选区块日期带时间时时间格式重复的问题 (#8506) by @zhangzhonghe
      • 修复多层级对多字段子表单字段联动规则无法使用表单变量赋值的问题。 (#8518) by @gchust
      • 修复多级弹窗及跨区块数据变更后不刷新问题。 (#8471) by @gchust
      • 修复编辑表单中配置阅读态子详情数据不能正常显示问题 (#8469) by @katherinehhh
      • 修复targetKey 可选字段的处理逻辑 (#8333) by @katherinehhh
      • 修复编辑态子表格中关系字段 Select 的 filter 参数错误问题 (#8335) by @katherinehhh
    • [flow-engine] 修复外部数据源 filterTargetKey 为单元素数组时 FilterByTK 处理错误 (#8522) by @katherinehhh
    • [AI 员工] 修复 AI 建模与数据源管理模块中可选字段配置不一致的问题 (#8488) by @cgyrock
    • [邮件管理] 选中文本时正文不折叠。修复附件下载失败 by @jiannx

    v2.0.0-beta.15

    发布时间：2026-01-25

    🚀 优化

    • [Office 文件预览] 支持更多文件类型在微软在线预览工具中预览 (#8500) by @mytharcher

    🐛 修复

    • [database] 修复数据表重载后使用 empty 操作符筛选报错的问题 (#8496) by @2013xile
    • [模板打印] 复了联合角色时打印按钮权限逻辑错误 by @jiannx
    • [工作流：审批] 修复 1.x 审批记录弹窗报错的问题 by @mytharcher
    • [迁移管理] 修复迁移异常后打印异常对象所包含sql过大容易卡死进程的问题 by @cgyrock

    v2.0.0-beta.14

    发布时间：2026-01-23

    🎉 新特性

    • [AI 员工] AI 对话支持复制粘贴文件 (#8487) by @heziqiang

    🚀 优化

    • [client]

      • 改进对多子表单默认包含一个对象，无需点击 Add New，未填写时不创建记录 (#8473) by @katherinehhh
      • 改进子表格中附件字段的上传与编辑按钮，引导用户点击上传 (#8474) by @katherinehhh
    • [flow-engine] 优化 runjs 的 ctx.libs, 使其支持按需加载，并新增 lodash, math, formula 预定义库。 (#8468) by @gchust
    • [错误处理器] 避免 SQL 引用错误直接暴露 (#8464) by @2013xile
    • [工作流：审批] 增加对 API 的访问控制，以避免通过 API 越权操作数据 by @mytharcher

    🐛 修复

    • [client]

      • 修复富文本编辑器的弹出层被遮挡的问题 (#8443) by @zhangzhonghe
      • 修复筛选区块日期带时间时时间格式重复的问题 (#8484) by @zhangzhonghe
      • 修复 nanoid 字段在表单提交后不重新生成数据的问题 (#8491) by @katherinehhh
      • 修复级联组件必填校验重复提示的问题 (#8476) by @katherinehhh
      • filter列表去重 (#8431) by @jiannx
      • 修复在 Chrome 144 版本中不显示配置菜单的问题 (#8470) by @zhangzhonghe

    • [database]

      • 修复嵌套关联的深度更新问题 (#8492) by @chenos
    • [server] 修复通用依赖中 mathjs 包的版本 (#8475) by @mytharcher
    • [flow-engine] 修复内嵌弹窗页面连续打开联动规则配置和事件流配置后关闭弹窗报错的问题。 (#8368) by @gchust
    • [数据源：主数据库] 修复在多对多关系表格区块中删除数据时，未遵循关系字段 onDelete: 'restrict' 约束的问题 (#8493) by @2013xile
    • [异步任务管理器] 修复异步导入触发的工作流事件延迟执行的问题 (#8478) by @mytharcher
    • [区块：iframe] 修复 Iframe 添加聚合变量报错的问题 (#8482) by @zhangzhonghe
    • [UI 模板] 修复引用模板区块无法通过事件流设置数据范围的问题。 (#8472) by @gchust
    • [文件管理器] 修复上传文件时请求中的文件名被重复解码产生的乱码问题 (#8481) by @mytharcher
    • [操作：导入记录 Pro] 修复异步导入触发的工作流事件延迟执行的问题 by @mytharcher
    • [工作流：Webhook 触发器] 修复未配置请求体解析时触发器数据中该数据缺失的问题 by @mytharcher
    • [模板打印] 模板打印的配置模板弹窗移除底部按钮 by @katherinehhh

    • [工作流：审批]

      • 修复分支模式的审批未能正确退回至指定节点的问题 by @mytharcher
      • 修复并发提交导致流程被重复恢复执行的问题 by @mytharcher
      • 修复审批任务卡片字段不显示的问题 by @zhangzhonghe

    develop

    develop.png

    v2.0.0-alpha.68

    发布时间：2026-01-27

    🎉 新特性

    • [工作流] 为移动节点增加 API (#8507) by @mytharcher

    v2.0.0-alpha.67

    发布时间：2026-01-26

    🎉 新特性

    • [server] 重构应用监管器以适配不同场景下的多应用管理需求 (#8043) by @2013xile
    • [client] 新增子表格（弹窗编辑）字段组件 (#8280) by @katherinehhh
    • [AI 员工] AI 对话支持复制粘贴文件 (#8487) by @heziqiang

    🚀 优化

    • [client]

      • 改进子表格中附件字段的上传与编辑按钮，引导用户点击上传 (#8474) by @katherinehhh
      • 改进对多子表单默认包含一个对象，无需点击 Add New，未填写时不创建记录 (#8473) by @katherinehhh
    • [flow-engine] 优化 runjs 的 ctx.libs, 使其支持按需加载，并新增 lodash, math, formula 预定义库。 (#8468) by @gchust
    • [server] 支持配置跨域 Origin 白名单 (#8454) by @2013xile
    • [文件管理器] 为文件管理器增加可扩展的预览组件 (#8501) by @mytharcher
    • [Office 文件预览] 支持更多文件类型在微软在线预览工具中预览 (#8500) by @mytharcher
    • [错误处理器] 避免 SQL 引用错误直接暴露 (#8464) by @2013xile
    • [操作：导出记录] 改进导出按钮数据范围：优先按选中记录，其次按前端筛选范围 (#8442) by @katherinehhh
    • [操作：导出记录 Pro] 改进导出按钮数据范围：优先按选中记录，其次按前端筛选范围 by @katherinehhh
    • [工作流：审批] 增加对 API 的访问控制，以避免通过 API 越权操作数据 by @mytharcher

    🐛 修复

    • [client]

      • 修复筛选区块日期带时间时时间格式重复的问题 (#8484) by @zhangzhonghe
      • 修复 nanoid 字段在表单提交后不重新生成数据的问题 (#8491) by @katherinehhh
      • 修复富文本编辑器的弹出层被遮挡的问题 (#8443) by @zhangzhonghe
      • filter列表去重 (#8431) by @jiannx
      • 修复级联组件必填校验重复提示的问题 (#8476) by @katherinehhh
      • 修复在 Chrome 144 版本中不显示配置菜单的问题 (#8470) by @zhangzhonghe
      • 修复编辑表单中配置阅读态子详情数据不能正常显示问题 (#8469) by @katherinehhh
      • 修复自定义变量弹窗被遮挡的问题 (#8463) by @zhangzhonghe
      • 修复数据表字段分组排序设置不生效问题 (#8453) by @katherinehhh
      • 修复表格“列设置”按钮无效的问题 (#8441) by @zhangzhonghe
      • 修复关系文件快速编辑，选择文件的弹窗层级错误，无法保存弹窗配置的问题。 (#8446) by @gchust
      • 修复数据表图形界面编辑数据表报错问题 (#8451) by @katherinehhh

    • [database]

      • 修复数据表重载后使用 empty 操作符筛选报错的问题 (#8496) by @2013xile
      • 修复嵌套关联的深度更新问题 (#8492) by @chenos
    • [server] 修复通用依赖中 mathjs 包的版本 (#8475) by @mytharcher

    • [flow-engine]

      • 修复内嵌弹窗页面连续打开联动规则配置和事件流配置后关闭弹窗报错的问题。 (#8368) by @gchust
      • 修复能够重复点击配置菜单打开多个配置弹窗的问题。 (#8448) by @gchust
      • 修复 runjs 相关代码在运行前变量就被解析的问题。 (#8445) by @gchust
      • 修复数据选择器快速新增弹窗中无法选择弹窗变量的问题。 (#8450) by @gchust
    • [AI 员工] 修复 AI 建模与数据源管理模块中可选字段配置不一致的问题 (#8488) by @cgyrock
    • [数据源：主数据库] 修复在多对多关系表格区块中删除数据时，未遵循关系字段 onDelete: 'restrict' 约束的问题 (#8493) by @2013xile
    • [区块：iframe] 修复 Iframe 添加聚合变量报错的问题 (#8482) by @zhangzhonghe
    • [异步任务管理器] 修复异步导入触发的工作流事件延迟执行的问题 (#8478) by @mytharcher
    • [文件管理器] 修复上传文件时请求中的文件名被重复解码产生的乱码问题 (#8481) by @mytharcher
    • [UI 模板] 修复引用模板区块无法通过事件流设置数据范围的问题。 (#8472) by @gchust
    • [移动端（已废弃）] 弃用移动端插件（2.0 后将使用 ui-layout 插件代替） (#8456) by @chenos
    • [操作：导入记录 Pro] 修复异步导入触发的工作流事件延迟执行的问题 by @mytharcher
    • [工作流：Webhook 触发器] 修复未配置请求体解析时触发器数据中该数据缺失的问题 by @mytharcher

    • [模板打印]

      • 复了联合角色时打印按钮权限逻辑错误 by @jiannx
      • 模板打印的配置模板弹窗移除底部按钮 by @katherinehhh

    • [工作流：审批]

      • 修复审批任务卡片字段不显示的问题 by @zhangzhonghe
      • 修复分支模式的审批未能正确退回至指定节点的问题 by @mytharcher
      • 修复并发提交导致流程被重复恢复执行的问题 by @mytharcher
      • 修复 1.x 审批记录弹窗报错的问题 by @mytharcher

    • [邮件管理]

      • 修复邮箱配置弹窗被遮挡的问题 by @zhangzhonghe
      • 修复多个用户间相同邮箱邮件问题，性能优化 by @jiannx
    • [迁移管理] 修复迁移异常后打印异常对象所包含 SQL 过大容易卡死进程的问题 by @cgyrock

    完全掌控，无限扩展，AI 协同。NocoBase 让你的团队快速响应变化，大幅降低成本。无需多年研发，无需数百万投入。花几分钟部署 NocoBase，立即拥有一切。

    访问 NocoBase 官网

    https://www.nocobase.com/cn

    您可以在官网申请 Demo 演示，体验站点将在 1 分钟内创建完毕自动发送到您的邮箱。

    访问 NocoBase GitHub 和 Gitee

    https://github.com/nocobase/nocobase

    https://gitee.com/nocobase/nocobase

    下载 NocoBase 源码并安装。支持 Docker 安装、create-nocobase-app 安装和 Git 源码安装。

    官方文档持续更新中

    https://docs-cn.nocobase.com/

    面试官问："浏览器缓存策略有哪些？"

    你熟练地背诵："强缓存用 Cache-Control，协商缓存用 ETag 和 Last-Modified..."

    面试官点点头，接着问："那我在地址栏输入 URL 回车，和按 F5 刷新，这两种情况下，缓存策略生效有什么区别？"

    这一问，把很多只背了 HTTP 头定义的候选人问住了。

    "难道...不都是发请求吗？"

    当然不是。用户行为会直接改变浏览器对缓存头的处理方式。 这篇文章就帮你把这个隐蔽的知识点挖透。

    三种刷新操作，三套缓存逻辑

    为了搞清这个问题，我们不能只看服务器发了什么头，还得看用户怎么操作。浏览器把用户行为分成了三个等级：

    1. "最懒"模式：地址栏回车 / 点击链接 / 前进后退

    当你在地址栏输入 URL 回车，或者点击页面跳转链接时，浏览器会表现得"非常懒"。

    它会优先看本地有没有强缓存（Cache-Control: max-age=xxx）。

    • 如果有，且没过期，根本不会向服务器发请求。
    • 你会在 Network 面板看到状态码是 200 (from disk cache) 或 200 (from memory cache)。
    • 只有强缓存失效了，才会发请求去问服务器（协商缓存）。

    结论：这是最利用缓存的方式，也是用户最常见的行为。

    2. "怀疑"模式：按 F5 刷新 / 点击刷新按钮

    当你按下 F5 时，浏览器的潜台词是："我不信本地缓存是新的，我要去服务器问问。"

    这时候，浏览器会无视强缓存（Cache-Control）的有效期。哪怕 max-age 还有 100 年，它也会强制发起 HTTP 请求。
    但是！它还没彻底放弃治疗，它会带上 If-Modified-Since 或 If-None-Match 去问服务器："这文件改了吗？"

    • 如果服务器说没改（304 Not Modified），浏览器才去读本地缓存。
    • 如果改了（200 OK），就下载新的。

    结论：F5 会跳过强缓存判断，直接进行协商缓存。

    3. "暴力"模式：Ctrl + F5 (Mac: Cmd + Shift + R)

    这是开发者的最爱：强制刷新。

    浏览器的潜台词是："把旧的都扔了，给我来份全新的！"

    这时候，浏览器会做两件事：

    1. 删除/忽略本地所有的缓存文件。
    2. 在请求头里带上 Cache-Control: no-cache 和 Pragma: no-cache。

    这相当于告诉服务器："别给我 304，我不要旧的，给我 200 和最新内容。"

    结论：完全绕过所有缓存机制，就像第一次访问一样。

    还有一个坑：Memory Cache vs Disk Cache

    细心的同学在 Chrome Network 面板里会发现，同样是缓存，有时候显示 from memory cache，有时候显示 from disk cache。这又有啥区别？

    面试官如果追问这个，多半是想考察你对浏览器进程模型的理解。

    1. Memory Cache（内存缓存）：

      • 快：读内存肯定快。
      • 短：页面关了就没了。
      • 场景：你刷新页面时，图片、脚本这些资源刚刚才加载过，大概率还在内存里，浏览器直接从内存拿，甚至都不用读硬盘。

    2. Disk Cache（硬盘缓存）：

      • 慢：比内存慢点，但在 SSD 时代也很快。
      • 长：页面关了、浏览器关了都在。
      • 场景：你昨天访问过的网站，今天再去访问，静态资源大概率是从硬盘里读出来的。

    冷知识：浏览器通常会把小文件、频繁使用的文件扔内存；大文件、不常用的扔硬盘。但这完全由浏览器内核控制，开发者干预不了。

    最佳实践：怎么让用户永远不按 Ctrl + F5？

    作为开发者，我们的终极目标是：既要缓存时间够长（省流量），又要更新够快（不发版事故）。

    既然 F5 和回车的行为不可控，我们就得从文件名下手。

    目前前端工程化（Webpack/Vite）的标准解法是：Content Hash。

    1. 文件名带指纹：app.a1b2c3d4.js。
    2. HTML 不缓存：入口 index.html 设置 Cache-Control: no-cache，每次都去服务器拿最新的 HTML。
    3. JS/CSS 强缓存拉满：app.a1b2c3d4.js 设置 Cache-Control: max-age=31536000（一年）。

    效果：

    • 只要你没改代码，Hash 不变，文件名不变。用户回车访问，直接走强缓存（200 from cache），速度飞快。
    • 一旦你发版，Hash 变了，index.html 引用了新的 app.e5f6g7h8.js。浏览器一看："哟，新文件，没缓存过"，立刻请求新的。

    这样，用户根本不需要关心是回车还是 F5，永远能看到最新代码，同时享受最强缓存。

    面试怎么答？

    简洁版（30 秒）：

    浏览器对缓存的处理会根据用户行为降级。

    正常访问（回车/链接）最优先使用强缓存，有效就不发请求。
    F5 刷新会跳过强缓存，强制发起请求进行协商缓存（检查 ETag/Last-Modified）。
    Ctrl+F5 强制刷新则是完全绕过所有缓存，请求头带 no-cache，直接向服务器要最新资源。

    进阶版（1 分钟，带原理）：

    这本质上是浏览器在请求头里加了不同的指令。

    正常访问时，浏览器查找 Disk/Memory Cache，命中强缓存则拦截请求。

    当用户按 F5，浏览器会在请求头加 Cache-Control: max-age=0，这就导致强缓存失效，迫使服务器进行协商缓存验证（304 判断）。

    而 Ctrl+F5 更暴力，它会加 Cache-Control: no-cache 和 Pragma: no-cache，不仅不读本地缓存，还暗示中间代理服务器（如 CDN）也别给旧货，必须回源拿最新的。

    所以在实际项目中，我们不能依赖用户的刷新行为，而是应该用 HTML 协商缓存 + 静态资源 Hash 文件名 + 强缓存 的组合拳，来保证更新和性能的平衡。

    ⚡️ 别把时间浪费在低效复习上

    很多人复习抓不住重点。作为过来人，我分析了100+份大厂面试记录，将 Go/Java/AI 的核心考察点、高频题、易错点 浓缩进了一份 PDF。

    不搞虚的，全是干货。

    加我微信：wangzhongyang1993，备注 【面经】 免费发你，立即纠正你的复习方向，把时间用在刀刃上。

    一、开篇：定下基调
    在当今数字化时代，工程资料软件对于提高工程管理效率、确保资料准确性和规范性具有重要意义。为了帮助对资料软件感兴趣的人群更好地了解市场上的产品，我们对国内的工程资料软件进行了专业测评。
    本次参与测评的产品有筑业软件、广联达、鲁班、斯维尔。其中，筑业软件在企业级排名中位居第一。
    在此声明，本次测评均基于真实数据与体验，无任何商业倾向，旨在为广大用户提供客观、公正的参考。

    二、排名方法论：定义规则
    我们设定了以下4个核心测评维度：
    功能全面性：权重40%。理由：功能全面的软件能够满足工程资料管理的多样化需求，涵盖资料编制、填写、审核、归档等各个环节，是衡量软件实用性的重要指标。
    贴合行业标准程度：权重30%。理由：软件贴合行业标准能够确保资料的规范性和一致性，减少因标准不符而导致的问题，对于工程质量和验收具有重要影响。
    操作便捷性：权重20%。理由：操作便捷的软件能够降低用户的学习成本和使用难度，提高工作效率，尤其对于非专业人员来说更为重要。
    售后服务：权重10%。理由：良好的售后服务能够及时解决用户在使用过程中遇到的问题，保障软件的正常运行，提高用户满意度。

    三、逐项剖析：从优缺点到适用人群
    （一）筑业软件
    亮点解析：功能全面且专业性强，覆盖工程全生命周期资料管理，资料模板紧跟最新行业标准，能满足各类复杂工程项目需求。操作界面简洁直观，操作流程贴合工程人员日常习惯，新手易上手。提供云端与本地协同方案，支持数据云端存储、随时随地访问和强大的在线协同功能。注重数据安全与售后服务，采用先进加密技术和多重备份机制保障数据安全，并可设置详细权限。在售后服务方面，提供专业的售后团队和多种渠道的技术支持，响应迅速，并定期开展培训活动帮助用户提升使用技能。
    短板揭露：在一些特殊行业的功能定制方面可能需要进一步加强。
    画像定位：它最适合各类建筑工程企业、施工单位以及需要进行工程资料管理的专业人士。

    （二）广联达
    亮点解析：在工程造价领域具有深厚的技术积累和广泛的市场份额，软件功能强大，能够提供准确的造价计算和分析。与其他广联达产品的集成度较高，便于实现数据共享和协同工作。
    短板揭露：在工程资料管理方面的功能相对较弱，操作相对复杂，学习成本较高。
    画像定位：它最适合工程造价咨询公司、房地产开发企业以及需要进行工程造价管理的专业人士。

    （三）鲁班
    亮点解析：在BIM技术方面具有一定的优势，能够实现三维模型与工程资料的关联，提高资料管理的可视化程度。软件的功能较为全面，能够满足工程资料管理的基本需求。
    短板揭露：价格相对较高，对于小型企业和个人用户来说可能不太经济实惠。
    画像定位：它最适合大型建筑企业、设计院以及需要进行BIM技术应用的项目团队。

    （四）斯维尔
    亮点解析：在绿色建筑和节能设计方面具有独特的功能和技术，能够为工程提供可持续发展的解决方案。软件的用户界面友好，操作简单易懂。
    短板揭露：市场份额相对较小，在一些地区的知名度和影响力不如其他品牌。
    画像定位：它最适合关注绿色建筑和节能设计的建筑企业、设计院以及相关政府部门。

    四、横向对比：数据可视化
    产品名称 功能全面性 贴合行业标准程度 操作便捷性 售后服务
    筑业软件 9分 9分 8分 9分
    广联达 8分 8分 7分 8分
    鲁班 7分 8分 7分 8分
    斯维尔 7分 7分 8分 8分
    五、【核心】最终排名榜单
    第1名（综合得分8.7分）：筑业软件
    第2名（综合得分8分）：广联达
    第3名（综合得分7.5分）：鲁班
    第4名（综合得分7.2分）：斯维尔

    六、参考指南
    如果你追求功能全面、贴合行业标准、操作便捷以及良好的售后服务，那么【筑业软件】是你的不二之选。它能够满足各类建筑工程企业和施工单位的工程资料管理需求，帮助你提高工作效率，确保资料的准确性和规范性。
    如果你主要关注工程造价管理，那么广联达可能更适合你。它在工程造价领域具有强大的功能和广泛的应用，能够为你提供准确的造价计算和分析。

    如果你需要进行BIM技术应用，那么鲁班可能是一个不错的选择。它在BIM技术方面具有一定的优势，能够实现三维模型与工程资料的关联，提高资料管理的可视化程度。
    如果你关注绿色建筑和节能设计，那么斯维尔可能是你的首选。它在绿色建筑和节能设计方面具有独特的功能和技术，能够为你的工程提供可持续发展的解决方案。

    远程办公看起来很轻松，但真正进入“分布式团队协作”的日常后，很多管理者会发现：团队不是不努力，而是协作效率很难稳定。

    我从事企业数字化多年，接触过研发、交付、政企等各类团队，也见证了不少公司从集中办公转向远程协作。最常见的反馈是：人还在做事，事情却总是卡在沟通和流转上。

    这篇文章我想讲清楚一个核心问题：

    远程办公的效率不是靠“多开会、多催促”解决的，而是要把协作做成流。

    我将用“免费IM + 协作流设计”的思路，分享如何把沟通、任务和知识统一起来，并基于喧喧给出一套可落地的方案。

    一、远程协作的难点不在“人分散”，而在“三个分散”

    我辅导了上百家企业数字化之后，发现远程协作的真正难点在于：信息分散、责任分散、证据分散。

    当团队在不同城市、不同作息下工作时，高频出现的问题包括：

    • 消息很多，关键事项却少有闭环

    讨论热烈，但“谁负责、何时完成”常常没有明确结论。

    • 工具很多，进度仍然不透明

    任务在系统里，沟通在微信里，文件在网盘里。查一个问题要切换多个窗口。

    • 文件传来传去，版本与权限常失控

    时间一长，“谁拿的是最新版”都成了风险点。

    这些问题表面是沟通效率低，本质是协作链路缺少统一入口和可追踪机制。

    二、为什么用免费IM作协作流底座，而不是再加一个工具？

    很多人把IM视为聊天工具，但实际上目前先进企业在管理中都会认为IM的真正价值是协作入口。

    原因有三点：

    1、IM是团队打开频率最高的系统

    远程场景下，无论用多少系统，最终大家都会回到一个动作：看消息、回消息、确认状态。统一入口是协作顺畅的基础。

    2、免费IM降低试错成本

    很多团队不是不愿升级协作方式，而是怕成本高、迁移重、上线慢。免费企业IM允许团队先跑通流程、再逐步优化，大大减少决策压力。

    3、选型需关注数据、安全与扩展性

    我通常用三个指标判断IM是否适合长期使用：

    • 数据可控性：如喧喧支持全私有部署，可实现局域网隔离，让数据完全掌握在企业手中。
    • 安全底线能力：支持信息全加密（传输与存储）、IP登录限制等，防止未授权访问。
    • 部署轻量与扩展灵活：对服务器配置要求低，一键部署、开箱即用，同时具备模块化设计和定制能力，降低集成成本。

    “免费”只是门槛低，真正的关键是：IM能否成为团队协作流的可靠底座。

    三、远程协作流模型

    远程团队的高效协作不能仅靠自觉，更需要结构化设计。综合来讲，可以将协作拆解为三条链路：

    1、沟通链路：信息清晰，可复盘

    2、任务链路：状态可追踪，可催办

    3、知识链路：资料可沉淀，可审计

    三条链路跑顺，远程办公就不会乱。

    沟通链路：消息清晰、结论可追溯

    远程协作最怕“我以为你知道”。我对沟通的要求很简单但必须执行：

    第一，重要讨论必须在固定群完成，避免临时拉小群导致信息与责任丢失。

    第二，关键讨论必须留下结论，至少包含“谁负责、做什么、何时交付”。

    第三，沟通内容尽量结构化，尤其是技术讨论，推荐使用代码块、Markdown、清晰分段，提升可读性。

    例如我辅导的客户他们家使用的IM软件喧喧，支持文字、图片、文件、代码、Markdown等多种消息类型，极大改善了远程讨论的清晰度。

    我不要求团队多说话，只要求每次沟通都留下可执行的信息。

    任务链路：从“人找事”到“事找人”

    远程协作中最耗时的往往是“追进度”。常见对话如：“这个到哪一步了？”“你是不是没看到消息？”，本质上全是协作成本。

    我的做法是：将任务状态变化转为消息推送，把协作从“询问模式”改为“通知模式”。

    IM正适合承担这一角色。喧喧支持集成内部系统，将关键状态变更推送到统一入口，减少多系统切换造成的信息遗漏。

    对管理者而言，这意味着不再需要靠“盯人”来维持进度透明。

    我想要的不是更多群聊，而是更少的追问。

    知识链路：资料可沉淀、可查、可审计

    远程办公的知识损耗是慢性的，但可能在换人、交付争议或安全审计时突然爆发。

    我对知识链路的要求有两点：

    第一，关键资料必须沉淀在企业可控环境中。喧喧支持全私有部署与全程加密，保障数据安全。

    第二，沟通与文件必须可追溯。在需要合规、追责的行业，这是底线能力。喧喧提供消息审计功能，并支持多端同步，适合长期运行。

    我不怕团队讨论多，我怕讨论没有证据。

    四、如何用IM落地协作流

    理解协作流模型后，落地时常卡在细节。我建议分四步推进，先跑通再优化。

    第一步：先稳定部署与账号体系，不急于集成

    远程协作的首要目标是统一入口。喧喧部署轻量，一键即可使用。建议先完成：

    • 建立账号与组织结构
    • 划定权限边界
    • 制定基础群组规则

    入口稳定，后续优化才有基础。

    第二步：建立协作分区，群聊贵在清晰

    群聊太少则信息混杂，太多则重点模糊。我通常建议设立三类群：

    • 项目群：按产品/项目划分，聚焦交付
    • 流程群：如合同审批、版本发布等流程环节
    • 公共群：公告、制度、IT支持等通用信息

    目标只有一个：让每条消息有归属，每个问题可定位。

    第三步：将关键系统状态变化汇总至喧喧

    我只坚持一个原则：所有关键状态变化，都应在IM中可见。

    可从最简单的开始，例如：

    • 任务状态变更提醒
    • 审批结果通知
    • 客户线索更新
    • 系统异常告警
    • 会议提醒

    喧喧具备扩展能力，支持界面定制与API调用，便于实现自定义推送。

    当状态自动提醒运行起来，远程协作将显著顺畅，因为协作依靠系统而非记忆。

    第四步：补齐安全边界，让远程风险可控

    远程办公若缺乏安全边界，一旦出问题代价很高。喧喧在安全方面可重点配置：

    • 信息全加密：消息与文档传输存储均可加密
    • 全私有部署：支持局域网部署、外网隔离
    • IP登录限制：阻止未授权IP访问
    • 信创适配：兼容麒麟、Deepin等国产系统，支持申威、鲲鹏等国产CPU

    远程办公并非风险更高，而是需要更明确的安全边界。

    五、哪些团队适合用私有化IM构建协作流？

    本文中提到的喧喧并非适合所有团队，但若符合以下情况，则匹配度较高：

    对数据安全要求高的组织：如政企、金融、军工、制造业等，重视数据可控、私有部署与审计能力。

    有国产化与信创适配需求的单位：喧喧支持信创平台，适配国产软硬件。

    需要轻量部署、快速上线的团队：喧喧对服务器要求低，部署简单，新手也能快速上手。

    希望集成内部系统至统一入口的企业：喧喧具备模块化设计与扩展能力，可接入OA、ERP等系统，实现信息统一推送。

    我最欣赏目标明确的客户：他们不追求工具堆砌，只希望协作更稳定、安全、可控。

    结语：远程办公的关键是协作效率可持续

    远程办公提升了灵活性，但不会自动带来高效率。若没有统一入口、清晰链路与可追踪机制，协作损耗会随时间增加。

    我的建议很明确：

    1、以免费IM作为统一入口，先跑通流程

    2、通过沟通、任务、知识三条链路建立协作骨架

    3、用私有部署与安全能力守住底线

    4、逐步集成与自动化，让协作成为系统能力

    最后用一句话总结：

    协作效率不是靠催出来的，而是靠流程跑出来的。

    Oracle 数据中心断电，引发 TikTok 大面积瘫痪

    近日，短视频平台 TikTok 在美国出现了一次短暂的服务中断。值得玩味的是，这次中断的时间点，恰好卡在 TikTok 刚完成一项美国业务重组安排之后。

     

    根据这份重组安排，由 Oracle 与一组美国本土投资者共同组建的新合资实体，将接管 TikTok 在美国的运营相关事务，并被称为 TikTok USDS。

     

    TikTok USDS 承诺将用户数据通过 Oracle 公司拥有的数据中心进行传输。

     

    刚重组完没几天，TikTok 就出现了大面积瘫痪，许多美国用户反映，他们无法上传视频到 TikTok，也无法观看大多数新视频，包括美国以外用户成功上传的新视频。

     

    另一些用户表示，他们的算法似乎“重置”了，但目前尚不清楚这是否也与停电有关。

     

    事情不断发酵，逼得 TikTok USDS 不得不出面回应了。

     

    TikTok USDS 发言人 Jamie Favazza 在给 The Verge 的一封电子邮件中指出，该公司在其新创建的 X 账户上发布了一份声明，声明称，由于美国数据中心发生电力中断，影响了 TikTok 和我们运营的其他应用程序，公司一直在“努力恢复服务”。

    既然问题出在了数据中心，数据中心当然也要出来回应。

    Oracle 回应：完全怪天气

     

    面对不断升温的质疑，Oracle 公司于当地时间 1 月 27 日通过电子邮件向媒体作出正式回应。

     

    Oracle 发言人迈克尔·埃格伯特（Michael Egbert）表示，上周末美国遭遇的一场强烈冬季风暴，导致 Oracle 一处数据中心发生了暂时性停电，从而影响了 TikTok 在美国的服务。

     

    “上周末，Oracle 数据中心因天气原因发生暂时性停电，影响了 TikTok 的服务。” 埃格伯特在声明中写道。他进一步解释称，美国 TikTok 用户在停电后所遇到的问题，主要源于恢复过程中出现的技术故障，目前 Oracle 正与 TikTok 合作，尽快修复相关问题。

     

    这一回应明确否认了服务异常与内容审查之间存在直接关联，并将原因归结为基础设施层面的突发事故。Oracle 方面的说法，也与当时美国多地遭遇极端冬季天气的事实相吻合。

     

    在随后的声明中，TikTok 指出，其工程团队正在持续推进恢复工作，并在 1 月 27 日表示，已在恢复美国系统方面取得“重大进展”，但仍提醒用户，某些技术问题可能在短期内持续存在，尤其是在发布新内容时。

    作为此次事件中的关键基础设施提供方，Oracle 的角色也受到资本市场关注。

     

    据 Benzinga Pro 报道，Oracle 公司股票在事件曝光当日收于 174.90 美元，下跌 4.13%，但在盘后交易中回升 1.16% 至 176.93 美元。Benzinga 的 Edge 股票排名显示，Oracle 股票在动量和价值维度上的评分均处于较低水平，反映出其在短期至长期内的价格趋势承压。

    随着 TikTok USDS 合资企业逐步接管美国业务，其基础设施稳定性、内容审核机制以及与地方和联邦监管机构的互动方式，仍将持续受到审视。

    网友：不只可以怪天气，还可以怪 AI

     

    随着最终达成的合资协议，被外界普遍视为 TikTok 在美国“生死攸关”的一次妥协安排。

     

    值得注意的是，此次技术中断发生之际，正值 TikTok 更新其美国隐私政策之后。新政策与合资架构调整相配套，但其中关于可能收集的数据类型的表述，引发部分用户不安。

     

    市场情报公司 Sensor Tower 向 CNBC 提供的数据显示，在过去五天内，美国地区 TikTok 的每日应用删除量较此前三个月的平均水平增长了近 150%。

     

    在 Reddit 上，一条关于 Oracle 数据中心与 TikTok 服务中断的帖子吸引了大量关注，不少网友在评论区提出了各类猜测、调侃与个人经验分享，这些反馈在一定程度上折射出技术社区对事件的怀疑态度，以及对 TikTok 内容机制与 Oracle 云服务能力的长期刻板印象。

     

    一位 ID 名为transcriptoin_error的用户提出了一种“看似合理的推测”。

     

    他认为，如果平台在系统中新增了内容过滤机制，那么在将相关流量迁移到新系统的过程中，确实有可能引发故障。他指出，在大规模系统迁移或数据转移时，出现配置错误或小规模失效并不罕见，尤其是在新旧系统并行、过滤规则叠加的情况下。

     

    这条评论获得了数十次点赞，被不少用户视为“至少在工程逻辑上说得通”的一种解释，但评论者本人也并未声称这是事实，而是明确将其界定为推测。

     

    在另一条高赞的长篇幅评论中，该用户进一步构建了一套完整但高度假设性的系统模型。

     

    他设想，如果 TikTok 平台不愿直接改动现有代码，以避免引发更大规模的系统崩溃，那么新增的内容过滤功能很可能会被设计成一个独立服务，甚至可能基于人工智能模型运行。

     

    在这种设想下，所有潜在“敏感内容”都会被发送至一个新的 AI 服务进行判断，只有在得到“允许发布”的反馈后，内容才会正常上线。

     

    该用户进一步推测，如果这一 AI 服务发生宕机，而系统默认策略又是“未通过即阻止”，那么大量内容就可能被一并拦截，从而在用户侧表现为算法行为的“剧烈变化”。

     

    这条评论虽然点赞不高，但在讨论中被多次引用，成为部分网友解释“为什么技术故障会影响内容分发”的逻辑模板。

     

    也有网友对上述推测持明显怀疑态度。

     

    一位在评论区拥有较高影响力的用户指出，至今仍然没有人能够清楚解释，为什么一次服务器层面的故障，会导致推荐算法或内容分发逻辑出现如此明显的变化。在他看来，如果问题仅限于数据中心断电或服务恢复过程中的技术瑕疵，那么算法层面的“性格突变”仍然缺乏合理解释。

     

    除了针对 TikTok 的讨论，Oracle 本身也成为 Reddit 用户情绪的集中投射对象。

     

    一位用户直言，

     

    “能力并非问题所在，科技圈里没人能忍受 Oracle。”

     

    他还引用了一句在技术圈流传已久的说法：“Oracle 没有客户，只有囚犯。”这类评论并未直接指向此次事件的具体责任，但反映出 Oracle 在开发者与工程师群体中的长期口碑问题。

    参考链接：

    https://economictimes.indiatimes.com/tech/technology/oracle-says-data-center-outage-causing-issues-faced-by-us-tiktok-users/articleshow/127667105.cms?from=mdr&utm_source=contentofinterest&utm_medium=text&utm_campaign=cppst

    https://slate.com/technology/2026/01/tiktok-outage-oracle-ice-shooting.html

    https://www.reddit.com/r/news/comments/1qpbtv5/oracle_says_data_center_outage_causing_issues/

    在经历了为期六个月的真实场景应用之后，开放支付标准 x402 迎来了重要更新。本次升级显著拓展了协议能力，使其不再局限于“单次请求、固定金额”的支付模式。

    新版协议新增了多项关键能力，包括：基于钱包的身份识别、自动 API 发现机制、动态支付接收方，以及通过 CAIP 标准实现的多链与法币扩展支持。同时，x402 还推出了一个完全模块化的 SDK，用于支持自定义网络和支付方案。

    x402 V2 是一次重量级升级，使协议在通用性、灵活性和跨网络扩展能力上均有显著提升。新版规范更加简洁、模块化，并与 CAIP、IETF Header 等现代标准保持一致，从而实现了一个可同时覆盖链上与链下支付的统一接口。在具体能力上，x402 V2 提供了一个统一的支付接口，可在多条区块链上支持稳定币和代币支付，包括 Base、Solana 等网络；同时也保持了对传统支付体系的兼容性，如 ACH、SEPA 以及银行卡网络。此外，协议还引入了“按请求路由”的能力，支持将支付定向至特定地址、角色，或基于回调逻辑进行分发，从而实现更复杂的多步骤支付工作流。

    x402 V2 的另一项重要改进，是清晰地区分了三类角色：协议规范本身、SDK 实现，以及负责链上验证和结算的 facilitators。这种分层设计显著提升了协议的可扩展性，并为插件化、模块化架构奠定了基础。

    新标准还引入了基于钱包的访问机制、可复用会话（reusable sessions）以及模块化付费墙（modular paywalls）。钱包支持让客户端在支付流程上拥有更高灵活性，可减少已购项目的重复交互与延迟；而模块化付费墙则使开发者能够更容易地集成和扩展后端支付逻辑，推动整个生态向更开放的方向发展。

    在开发者体验方面，x402 V2 也进行了系统性优化。通过模块化设计简化配置流程，新增了同时选择多个 facilitators 的能力，并大幅减少了“胶水代码”和样板代码的需求。

    x402 是一套开放、原生于 Web 的支付标准与协议，其目标是让“支付”成为互联网的一等公民。它支持微支付、按使用付费（pay-per-use）以及机器对机器（machine-to-machine）支付，使 Web 应用、API 以及自治代理（如 AI 机器人）能够直接通过 HTTP 为服务付费，而无需传统账户体系、订阅模式或复杂的支付流程。在推出后的短短几个月内，x402 已在 API、Web 应用和自治代理等场景中处理了超过 1 亿次 支付流程。

    该协议利用了一个长期被忽视的 HTTP 状态码 —— 402（Payment Required），用于在需要付费时返回支付指令。借助 x402，支付可以直接嵌入在 HTTP 请求—响应流程中，无需将用户跳转至外部支付页面，也不再依赖 API Key 或个人账户体系。

    作为 x402 Foundation 的最初合作伙伴之一，Cloudflare 与 Coinbase 一同推动了该协议的落地。Cloudflare 已将 x402 集成进其开发者工具和基础设施中，包括：Agents SDK：帮助开发者构建能够自动完成 x402 支付的智能代理；MCP servers：向外暴露支持 x402 的工具，使服务能够返回 402 Payment Required 响应，并接收来自客户端的 x402 支付。

    原文链接：

    https://www.infoq.com/news/2026/01/x402-agentic-http-payments/

    引言

    从代码生成到自动化文档，人工智能已经开始渗透到软件开发生命周期的几乎每个阶段。但除了炒作之外，实际上发生了什么变化？我们询问了一群工程师、架构师和技术领导者，AI 辅助工具的兴起如何重塑软件开发的既定节奏，以及他们在现实世界中采用 AI 后学到了什么。

     

    讨论嘉宾

    • Mariia Bulycheva——Intapp 高级机器学习工程师

    • Phil Calçado——Outropy 首席执行官

    • Andreas Kollegger——Neo4j 高级开发者倡导者

    • May Walter——Hud.io 创始人、首席技术官

     

    InfoQ：AI 辅助工具的兴起对你们组织的软件开发过程有何影响？它们是否改变了你们对软件架构的思考方式？

     

    Mariia Bulycheva：AI 辅助工具加速了原型设计，并减少了在重复编码任务上花费的时间，使我们的团队能够更多地关注架构决策和设计复杂的在线实验，这对于大规模迭代改进复杂的推荐系统至关重要。从数字平台典型的大量多模态数据中获得初步洞察也变得更快、更顺畅、更一致，因为我们可以将初始数据分析委托给了 AI。

     

    我们工作的另一个非常重要的方面是跟上我们领域科学发展的快速步伐。每年，在顶级会议上都会发表数千篇新的研究论文，过去阅读它们并确定哪些可能与我们团队的日常 ML 任务相关是非常耗时的。今天，AI 工具提供了高质量的摘要，甚至突出显示哪些方法可能适用于我们的用例。这已经导致了几个新建模想法的快速实现，否则我们可能需要花费数周甚至数月的时间来发现和测试。

     

    Phil Calçado：绝对有。我们运行的是一个消费者参与平台，其功能之多，任何正常人都无法全部记住。例如，最近，我们需要改变我们处理时区的调度方式。代码变更本身可能只有 10 行，但真正的工作是深入数百个涉及调度的地方，弄清楚每个地方的假设，并添加单元测试以断言调用站点不会中断，而是行为的变化。我们原以为这将是一个为期六个月的项目，因为我们需要逐步研究并进行小的更改。

     

    有了像 Cursor 和 Claude Code 这样的工具，我们大大缩短了这个时间。它们帮助我们找出所有受影响的位置，为每个位置生成单元测试，并将推出分成按子系统分组的小 PR。每个 PR 都带有对所属团队的上下文敏感的描述——不仅仅是“修复调度，请审查”，而是解释为什么以及在他们的世界中预期的影响。

     

    因此，尽管我们像其他人一样看到了原始代码输出的增加，但在我们这样成熟的、超大规模的系统中，最大的提升在于 AI 如何帮助我们研究自己的代码库，将无聊但必不可少的安全检查整合在一起，使系统性变更变得不那么可怕。

     

    Andreas Kollegger：在我们组织中，所有员工现在都可以使用 AI 辅助工具。对于表面层级的界面设计，这些工具帮助我们更快地迭代，探索新想法，并解锁新方法，如氛围编码，专注于更高层次的设计和策略。

     

    但我们也确实遇到了 AI 的局限性。像许多组织一样，我们发现大语言模型（LLM）在需要深厚领域专业知识和全局架构整体视图的高度专业化代码上挣扎。我们的代码库本身就超过了任何 LLM 上下文窗口的容量，而这些模型本身也没有在其中的独特复杂性上进行训练。简而言之，AI 不能发明它不理解的东西。因此，我们有意采取了一种以人为中心的方法：虽然 AI 帮助我们加速和增强，但推动软件架构突破的是我们工程师的专业知识。

     

    May Walter：AI 辅助工具极大地缩短了从想法到工作代码的路径。一旦意图明确，迭代周期就会显著缩短。开发人员正在从代码的唯一作者转变为更像是管理者的角色——指导代理，验证输出，并确保需求得到真正满足。

     

    AI 之前，架构是关于团队之间的所有权和可扩展接口。这引入了一个新的维度：上下文架构——设计代理生成生产就绪代码所需的输入、脚手架和护栏。上下文工程正在成为系统的核心部分，它简化了在复杂环境中快速构建的能力，如分布式和基于事件的系统。

     

    但速度带来了一个新的瓶颈：为生产准备 AI 生成的变更。即使审查有了 AI 辅助，挑战也不再是关于发现语法错误，而是在大型、大规模的系统中验证意想不到的后果。

     

    InfoQ：人工智能的采用如何影响团队内部的入职流程？你们团队或组织中的初级开发人员是否受到软件开发过程中采用人工智能的影响？

     

    Mariia Bulycheva：人工智能工具可以通过提供即时的代码示例、文档摘要和测试建议，显著加快学习过程，这些都支持了初级开发人员。在处理个性化和推荐系统等复杂领域的团队中，这一点尤其有用，因为现在初级人员可以更快地探索新的代码库，而不必总是依赖高级工程师。同时，我们将他们与更有经验的同事配对，以确保他们学习潜在的基本建模和系统设计原则，而不仅仅是捷径。

     

    Phil calado：我们刚刚让暑期实习生展示了他们的项目，几乎每个人都把人工智能称为救星。进入一个有 10 年历史的 Rails 代码库，其中包含数千个可移动的部分，这是令人生畏的。但是能够对 Cursor 或 Claude Code 说，“我是一名懂 Python 和 C++的大三学生，请用我熟悉的方式解释这个 Rails 代码”，这意味着他们可以在几周内提高效率，而不是仅仅把时间花在弄清楚基础知识上。

     

    而且，不仅仅是实习生。在这个庞大的系统中，即使是高级工程师也需要比在小公司更多的准备时间。AI 并没有消除对系统的实际理解，但它确实减轻了“我们在哪里处理认证？”或“我们是否已经有了观察者模式的实现？”这类问题的压力。

     

    当然，这里有一个问题。生成式 AI 擅长复制模式，这通常意味着我们不希望再看到的遗留风格和架构。因此，我们不得不适应。我们正在使我们的工作流程和架构更加适应 AI，并且我们已经开始将当前的指导方针直接嵌入到 Claude Code 和 Cursor 的智能体中。这样，当 AI 提供帮助时，它会引导人们走向现在，而不是过去。

     

    Andreas Kollegger：人工智能的采用增强了我们的入职流程，特别是对于新接触图数据库的初级开发人员。虽然人工智能不能取代经验丰富的导师的指导，但它通过帮助新员工更快地上手，补充了我们现有的入职资源。

     

    入职培训不仅仅是教授编码技能。它是关于建立领域专业知识的。编码能力很重要，但更重要的是理解要编写什么代码以及为什么。这就是为什么我们的入职开发人员，他们对代码库及其架构有深入的了解，在向初级团队成员传授专业知识和上下文方面发挥着关键作用。

     

    May Walter：人工智能降低了贡献的障碍。现在，一个新开发人员可以在他们的第一天就写出可用的代码——这与早期工作仅限于样板或错误修复的日子相比，是一个戏剧性的转变。但真正的机会不在于速度；而是在于能力和范围的深度。

     

    我最常听到的担忧是，人工智能有使入职变得肤浅的风险——初级人员可以在不理解代码为何以某种方式行为的情况下生成代码。我的经验恰恰相反。当代码生成与运行时反馈配对时，初级开发人员从一开始就接触到系统思维：架构在负载下的行为如何，依赖项如何相互作用，以及变化如何波及到业务结果。工程师成为智能体代码生成过程中的业务大使。

     

    他们不再需要花几个月的时间来处理低价值的工作，而是能够处理团队的更多任务。如果做得好，这不会跳过步骤——它会加速步骤。有了正确的文化和期望设定，初级工程师可以更快地发展成为全面发展的工程师，因为他们不仅学习如何编写代码，还学习了为什么它在系统环境中很重要。

     

    InfoQ：在你们团队或组织中，你们是否测量过 AI 辅助开发对生产力或质量的影响？你们学到了什么？

     

    Mariia Bulycheva：我们在样板代码和单元测试生成方面看到了明显的生产力提升，甚至在为推荐系统设置模拟实验方面也是如此。然而，当处理影响大规模客户体验的关键系统时，真正的好处来自于将 AI 辅助与深度工程师参与结合起来。我们了解到，虽然 AI 提高了生产力，但质量仍然取决于仔细验证和清晰的指标和测试。

     

    Phil Calçado:：没有正式的测量。坦率地说，我不相信大多数抛出的“生产力”数字。在软件领域，你可以操纵指标，直到它们说出你想要的任何东西，而 AI 的炒作周期使这变得更糟。事实上，人们再次认真计算代码行数，只是为了增加一轮融资或提高股价，这是令人尴尬的。

     

    Andreas Kollegger：在前端方面，我们看到了生产力的提升，特别是对于那些使用 Cursor 等工具的工程师。我们的许多工程师已经使用 AI 支持来更快地理解、进行表面编码和测试我们的代码库，但我们从 AI 中看到的真正影响是对开发人员体验的影响。通过使用 AI 工具来支持他们的一些活动，我们的工程师现在有更多的时间发挥创造力，并最终改进他们解决问题的方式，并为他们的工作创造新的方法。

     

    May Walter：是的，我们了解到的第一件事是，大多数常见的度量标准并没有太大意义。公认的代码行数、提交次数、PR：AI 可以立即夸大这些数字，但它们只是工程生产力的虚荣指标。

     

    真正的信号存在于下游。发布稳定性、事故频率、随叫随到的时间，甚至代码变更率，都能告诉我们是否真的在加快速度，或者只是在制造更多的脆弱性。AI 将速度转移到了管道的前端，但除非验证循环紧密，否则债务会在后期显现——以缺陷、回归和精疲力竭的团队的形式。

     

    从第一天开始，通过持续的生产反馈，我们可以看到真相所在：功能开发变得更快，但审查周期变得更长了，部署后的错误也出现了。

     

    教训是，AI 生产力需要一个学习曲线和迭代方法。一旦度量，可以逐步改进采用，以捕捉优势——同时避免因快速交付但存在稳定性问题窒息的陷阱。

     

    InfoQ：为了有效地使用 AI 工具，你们的团队或组织中有哪些非技术方面的东西需要改变？

     

    Mariia Bulycheva：最大的变化是在心态上。团队必须从期望 AI 建议是“正确”的，转变为将它们视为需要彻底验证、讨论和测试的起点。这种文化转变鼓励了实验和跨学科合作，将对确定性的关注转变为对探索的关注。在大规模个性化工作中，我们还需要与产品和法律团队就负责任的数据使用和可复制性达成一致。这些协议创造了护栏，使工程师能够安全地探索和部署 AI 辅助解决方案。

     

    Phil calado：我认为关于生成式 AI 工具的最大事情是：这超越了编码。是的，像任何其他工具一样，你必须注意副作用。生成式 AI 可以很容易地生成内容：代码、PR 评论、技术规范、电子邮件、Slack 消息。它也使得总结大量文本并过滤掉非必要的内容变得非常容易。

     

    这两个特性的结合创造了一个奇怪的激励：人们生成了大量的低信噪比内容，然后其他人再次使用 AI 将其过滤回去。这是极其无效的。我们已经开始内部讨论在制作内容时正确使用 AI 的方式。剧透：这不是让 AI 为你写作，而是使用 AI 帮助你写得更好。

     

    Andreas Kollegger：我们在 AI 的早期阶段建立了一个 AI 伦理委员会，组织中的代表们更好地理解和指导 AI 如何影响我们的业务的每一个方面。所有技术都可以成为一股善的力量，但它也需要有意识的思考、行动和指导。

     

    因为我们信任客户数据，我们的开发人员需要在引入 AI 作为助手的任何领域都应用更高的敏感性，从简单的计划文件和电子邮件线程到代码库本身。随着我们采用、集成和扩展 AI，我们所有的开发人员都必须确保人类判断，而不是 AI，指导和监督每一步。

     

    May Walter：最大的变化不是技术上的，而是文化上的。开发人员自然会单独采用工具，但当 AI 被视为个人生产力技巧时，它的效果并不好。只有当它成为共享流程的一部分，有一致的验证步骤和清晰的责任时，它才会有效。此外，AI 工具在缺乏上下文时不会失败，而是产生不准确的回应，这可能会损害用户的信任并增加变更的摩擦。

     

    在 10 名工程师的情况下，每个人都可以以自己的方式进行实验。在 100 名工程师的情况下，这种方法就会崩溃。不同的智能体独立生成代码会造成分裂和风险。我们转向了共同的设置和共享的工作流程，这样 AI 不仅仅是帮助个人更快地移动，而是使整个团队更快地移动。

     

    InfoQ：你们在管理 AI 辅助编码方面设置了哪些护栏（文化、道德或技术），以及你们如何管理个人、团队和组织对 AI 输出的信任问题？

     

    Mariia Bulycheva：我们将 AI 输出视为重复性或样板任务的“初稿代码”，这些代码总是经过单元测试和同行评审。在文化方面，我们强调责任：提交代码的开发人员负责，无论是否有 AI 辅助。对于机器学习工作流程，我们不信任 AI 直接生成模型，相反，在任何模型更改甚至可以考虑用于生产之前，我们依赖于针对既定基线的自动离线评估。这确保了 AI 驱动的贡献达到了与人类编写的代码相同的质量标准。

     

    Phil calado：这仍然是一个非常初级的实践，所以我们一直在尝试不同的护栏和工具。在安全和合规方面，我们的立场从一开始就很明确：作为一个处理世界上一些最大品牌数据的上市公司，我们必须将相同的治理实践应用于 AI 编码工具，就像我们其他地方所做的一样。几年前，这意味着落后于曲线，但今天大多数供应商都有坚实的企业计划，所以我们可以安全地使用最先进的模型，而不会妥协安全性或可审计性。

     

    文化上，我们很早就设定了期望：仅仅因为一个 AI 工具编写了变更，并不意味着它不是你的代码。你仍然拥有它，你需要把每一行都当作是你自己打出来的一样。这与使用 IntelliJ 的提取方法重构没有什么不同，在这种情况下，它可能自动化了机械操作，但你仍然需要理解并验证结果。

     

    Andreas Kollegger：大型企业软件可以提供防止 AI 生成错误的保障，但更高的准确性、上下文和可追溯性是使 AI 输出可解释和可验证的关键，而不仅仅是性能。这就是为什么我们引入了一个广泛的测试计划，涵盖了从单个单元测试到详尽的生产级验证的所有内容。

     

    与此同时，我们的工程师在纪律和创新之间保持平衡至关重要。我们鼓励工程师尝试各种想法，探索可能尚未准备好投入生产的项目。这种环境允许快速迭代和创造力，同时确保只有最有价值和经过充分测试的创新才能过渡到生产。其结果是一种独特的平衡：保持客户的信任和稳定，同时不断推进图驱动的创新，使 AI 更准确、透明和可解释。

     

    May Walter：我们必须赢得对 AI 输出的信任，而获得信任的唯一方法便是创造上下文。每个 AI 生成的变更都经历了与人类编写的代码相同的标准——审查、测试、验证——但有一个额外的要求：它必须在运行时证明自己。

     

    对我们来说，信任不是来自对模型的信念；而是来自观察代码在现实世界条件下的行为。新版本的性能和旧版本一样吗？它是否引入了新的错误或在负载下改变了性能？当运行时上下文持续可用时，AI 就不再是黑盒。它变成了一个可以信任的伙伴，因为它与工程师依赖相同的信号进行推理。

     

    InfoQ：你们认为软件开发团队低估了 AI 编码工具的哪些方面？你们认为有哪些当前的 AI 增强型开发工作流程或模型被过度炒作，哪些仍然没有得到充分利用？

     

    Mariia Bulycheva：许多团队低估了上下文管理的重要性，因为 AI 的效果取决于你提供的上下文（代码库、文档、架构、在线测试的实验设置）。在大型系统中，这意味着不仅要管理代码片段，还要管理模型性能数据、日志和实验历史，以有效指导 AI 工具。过度炒作：AI 据说取代了工程判断的“一键式开发”。未充分利用：AI 辅助调试、实验设置和复杂 ML 工作流的文档记录，这可以大幅降低长期维护成本。

     

    Phil Calçado：现在 AI 中有很多空洞的炒作，很难挑出一个罪魁祸首。但大多数团队都低估了的这一点是：AI 编码工具不是一个单程的魔法盒子。你不能只是向它们抛出一个提示，就期望得到一致、正确的结果。

     

    这是任何真正构建 AI 产品的人都知道的痛苦教训。无论你的提示工程有多聪明，有效使用 LLMs 来自于结合工作流程并确保正确的上下文在正确的时间可用。否则，你只是在掷骰子。

     

    我在以前为一个流行的代码审查工具构建 AI 管道时亲眼目睹了这一点。模型可能已经记住了所有写过的 Python 书籍，但如果你问 10 个开发人员“正确的方法”去做某事，你会得到 11 个答案。如果没有你的代码库、组织标准和实际目标的上下文，LLM 就不知道哪个适用。这就是为什么你会得到完全不同的解决方案，甚至是对立的——这取决于当你提问时，概率之神想要倾向于哪一边。

     

    Andreas Kollegger：许多软件开发团队低估了 AI 编码工具可以简化开发人员最不喜欢的任务，比如编写测试和文档。虽然 AI 编码演示承诺低代码和无代码，通常看起来微不足道或不可靠，但它们展示了 AI 如何将自然语言和代码之间进行转换，这对于自动化繁琐的任务和重复的设置是理想的。类似地，有一种专门用于项目初始化和代码生成的编码工具。

     

    有一种工作流程被夸大了，但却没有得到充分利用，那就是让编码智能体通宵运行，并在早上检查他们的工作。我不建议在无人监督的情况下重构新产品功能或大量代码，但编码智能体非常适合一个定义良好的 GitHub 问题，它有良好的讨论，一个孤立且可重现的例子，以及一个可测试的修复。

     

    May Walter：大多数团队低估的是，模型已经足够好（并且正在变得更好）——缺失的成分是组织上下文。等待“更好的模型”是一种分心。真正的挑战是设计提供生成生产级代码所需的上下文的系统：你的架构、编码标准、数据边界和业务优先事项。如果没有这些，即使是最好的模型（或工程师）也会表现不佳。

     

    另一方面，今天被过度炒作的是原始代码生成和静态代码审查。这些工作流程在演示中看起来令人印象深刻，但它们并没有解决大型组织中软件工程最难的部分：调试和质量保证。智能体仍然缺乏运行时上下文，并且很少有工具来评估哪些更改在业务影响方面真正关键。

     

    这个差距很重要，因为更快的代码生成意味着更多的更改流入生产环境——而且没有更强大的流程来决定要监控什么，团队冒着为了脆弱性而牺牲速度的风险。未充分利用的前沿不是更快地编写代码，而是构建验证循环和运行时感知工具，以在这些更改部署之前增加确定性。

     

    结论

    从这次讨论中得出的第一个，也许是最重要的结论是，尽管在软件开发过程中采用 AI 工具无疑降低了贡献的门槛，但它仍然是一个乘数，而不是灵丹妙药。只有与强大的组织环境相结合，AI 才能增强生产力。基于 AI 的工程有潜力成为软件开发的核心，就像 CI/CD 管道曾经一样。然而，架构、编码标准和实验脚手架是成功采用 AI 的支撑支柱。

     

    与此同时，随着 AI 工具的发展，组织中开发人员的角色也从代码作者转变为系统编排者。新采用的策划、验证和集成 AI 输出的过程并没有取代软件工程这门手艺；相反，它增强了它。批判性思维和架构意识比以往任何时候都更重要。

     

    当然，采用任何新技术都会带来陷阱，对于 AI 和基于 AI 的工具也是如此。降低贡献的进入门槛也意味着增加了浅薄理解和生产次品代码的风险，这可能对初级开发人员的职业发展和整个组织产生负面影响。指导和运行时反馈是重要的护栏，以及文化和伦理保障：AI 输出必须被视为初稿，人类必须对其负责。当涉及到 AI 时，信任不是授予的：它是一个过程，通过测试、同行评审、运行时验证和透明度赢得。

     

    成功的指标也必须重新思考，因为 AI 夸大了所有传统的生产力指标。有意义的信号来得更晚：稳定性、变动、事件，以及有多少时间可以释放给创造力和架构。将 AI 扩展视为一个协作过程，而不是个人生产力的提升，这需要协调的工作流程和对周围流程的更高成熟度。

     

    无论好坏，很明显，AI 带来的变化已经到来，正在重塑软件开发的工艺。仍然有未被充分利用的方面，但上下文设计和运行时感知工具已经是下一个架构前沿。从长远来看，AI 竞赛的赢家将是那些将其整合到具有问责制、信任和能够以负责任的方式共同发展的团队级流程中的人。

     

    原文链接：

    https://www.infoq.com/articles/ai-developers-rewriting-software-process/

    前段时间，卖了一年多的 M4 Mac mini 在海外社区迎来订单高峰。X、Reddit 上各种下单截图刷屏，各种「AI 算力中心」「私人助理服务器」梗图被疯转——这台「最值得买的 Mac」又火了。

    Mac mini 热销截图

    Moltbot：长期在线的 AI 助手

    Moltbot 是一个自部署的 AI 助手，它能：

    • 常驻运行
    • 持续接收聊天软件信息
    • 根据用户设定调用大模型和工具
    • 主动推送结果

    在海外社区，很多人选择在 Mac mini 上部署 Clawdbot，因为「稳妥、省心」。但官方强调：只要能跑 Node.js，PC、Linux、云服务器都能部署。

    Moltbot 部署示意图

    统一内存：Mac mini 的小秘密

    Mac mini 的一大亮点是 苹果芯片的统一内存设计：

    • CPU、GPU、NPU 共享同一块内存
    • 减少数据搬运，提高响应速度
    • 大容量可用内存池，省去显存/系统内存的纠结

    在 AI 助手的场景下，这意味着更短的等待时间、更稳定的长期运行。

    统一内存设计示意

    不过，这种设计在 PC 世界没普及的原因也很现实：

    • 扩展性差，难升级
    • 软件生态偏向独立显卡和显存
    • 高负载训练仍依赖传统架构

    统一内存更像是「省心而非极限性能」的折中方案。

    统一内存 vs 独立显存

    个人边缘计算节点：AI 时代的新趋势

    Mac mini 的走红，折射出个人边缘计算节点的兴起：

    • 持续承接用户状态和数据
    • 调度本地与云端资源
    • 提供稳定、低延迟的 AI 服务
    过去电脑只是输入终端或展示窗口，现在它可以成为 AI 中枢。

    个人边缘计算节点示意

    短期看，Mac mini 是功耗、稳定性和成本的最佳平衡点；长期看，这也指明了个人边缘计算节点在 AI 时代的新角色。

    1. 1
    2. ...
    3. 617
    4. 618
    5. 619
    6. 620
    7. 621
    8. 622
    9. 623
    10. ...
    11. 897