包含关键字 typecho 的文章

整理 | 华卫

 

3 月 2 日,Anthropic 旗下聊天机器人 Claude 及其编程平台 Claude Code 出现服务中断。该初创公司表示,过去一周其服务遭遇了前所未有的需求高峰,公司正全力应对。

 

据服务监测网站 Downdetector 数据,其故障高峰期有近 2000 名用户报告 Claude AI 服务异常。Anthropic 通过 WhatsApp 发表声明称,claude.ai 官网及公司旗下应用等面向消费者的服务端口均已下线,而将 Claude AI 模型集成至自有系统的企业客户则未受影响。

10 小时内,Claude 连续崩了四次

3 月 2 日晚, Claude 接连发生了四次严重的全球性技术故障。

 

根据 Claude 官方状态页面显示,首次故障于北京时间 3 月 2 日 19:49 开始,当时公司排查发现 claude.ai 官网、开发者控制台以及 Claude Code 全线出现大量报错。大多数用户反馈,在尝试登录时遇到了错误。该公司称,“我们遇到的问题与 Claude.ai 以及登录/注销路径有关。”更新信息显示,部分 API 接口在修复前无法正常使用,该问题于 23:47 得到解决。

 

第二次影响 Claude Opus 4.6 模型的故障记录于北京时间 3 月 2 日 22:35,于 22:42 修复,并在 23:50 完全恢复。第三波故障发生在北京时间 3 月 3 日凌晨 00:50–01:08 期间,Claude Opus 4.6 模型与 claude.ai 官网再次出现大量报错。第四次故障发生在北京时间 3 月 3 日凌晨 01:56,Claude Haiku 4.5 模型出现大量报错。到北京时间 3 月 3 日早上 05:16,全部故障都已恢复,所有系统恢复正常运行。

 

此次服务中断对普通用户的影响范围十分广泛。24 小时内,故障监测平台 Downdetector 共收录到美国用户提交的 1952 条 Claude AI 故障报告。

 

对于 Claude 和 Anthropic 来说,这次中断发生在一个敏感时期。Anthropic 在声明中表示:“过去一周 Claude 需求激增,我们正努力恢复服务,感谢所有人的耐心等待。”

被“封杀”后夺榜首,用户量激增

宕机事件的发生,正值 Anthropic 面临的局势动荡之际。

 

近期,特朗普下令联邦机构停止使用 Claude,五角大楼已将 Anthropic 列为供应链风险,这一针对美国本土企业的举措前所未有,恐对其业务造成深远影响。该公司表示,“无论战争部(国防部)如何威胁或施压,都不会改变我们的立场。”Anthropic 明确规定,其产品不得用于监控美国民众,也不得用于研发完全自主武器。该公司誓言将在法庭上挑战任何将其列为供应链风险的正式通告,其首席执行官 Dario Amodei 称此举是 “报复性且惩罚性的”。

 

就在 Anthropic 被列为供应链风险数小时后,其规模更大的竞争对手 OpenAI 宣布,将在国防部机密网络内部署自家 AI 模型。OpenAI 称,双方达成的协议符合公司原则,即禁止国内大规模监控,并要求 “武力使用需由人类负责,包括自主武器系统”。随后,OpenAI 又为这项新合作辩护,称已在合同中加入多项保障措施,确保模型在部署过程中得到正确使用并正常运行。

 

Anthropic 数据显示,自 1 月以来,Claude 免费用户数量增长超 60%;自 10 月以来,付费订阅用户数量更是翻倍。而该公司如今因被下禁令一事,新增用户再次激增、关注度大幅上升。从上周起,Claude 应用已连续多日在美国苹果应用商店免费应用排行榜上位居榜首。其他人工智能应用,包括 OpenAI 的 ChatGPT 和 Alphabet 旗下的谷歌应用 Gemini 在 App Store 中分别排名第二和第四。

 

值得一提的是,Claude 在政府内部的应用似乎并未完全终止。据外媒报道,就在特朗普禁令宣布仅数小时后,美国中央司令部在针对伊朗的一次重大空中行动中,仍在继续使用这套 AI 系统,用于辅助情报分析、目标识别与战场模拟。

祭出 60 秒记忆搬家杀招,ChatGPT 卸载量暴涨 295%

与此同时,上周已有不少网友在社交平台呼吁,取消 ChatGPT 订阅。

 

市场情报机构 Sensor Tower 的数据显示,受 OpenAI 与美国国防部达成合作消息的影响,ChatGPT 移动端应用在美国的卸载量环比暴涨 295%,这一涨幅远高于 ChatGPT 过去 30 天内日均 9%的常规环比卸载率。此外,ChatGPT 的下载增长也受到冲击。消息公布后不久,其美国地区下载量在上周六环比下降 13%,上周日继续环比下跌 5%。

 

其他第三方数据机构也印证了 Sensor Tower 的结论。例如 Appfigures 指出,上周六 Claude 在美国的单日总下载量首次超过 ChatGPT。该机构统计的涨幅更高:Claude 美国下载量上周六环比大涨 88%。第三家市场情报提供商 Similarweb 表示,Claude 过去一周在美国的下载量约为 1 月的 20 倍。

 

用户也在应用评分中表达了对 OpenAI 合作协议的态度。Sensor Tower 数据显示,ChatGPT 的 1 星差评上周六暴增 775%,上周日环比再增 100%;同期五星好评则下降 50%。

 

就在成千上万的用户为抗议 OpenAI 迁移到 Claude 之际,Anthropic 直接下场提供了一个不到 60 秒的“搬家流程”。昨天,Anthropic 专门升级了 Claude 的记忆功能,不仅从仅对付费订阅用户开放改为向免费版用户开放,同时新增专用提示词与导入工具,可直接迁移其他 AI 中的用户数据。这些升级能让 OpenAI ChatGPT、谷歌 Gemini 等用户,快速将原 AI 记录的个人信息与偏好复制到 Claude 中,无需“从零开始”重新让 Claude 学习上下文与历史信息。

 

如今,所有 Claude 用户只需将一段预设提示词复制到原 AI 中,再把输出结果粘贴回 Claude 导入工具即可完成迁移,大大降低了从其他聊天机器人迁移至 Claude AI 的门槛。

 

“ChatGPT 完全完蛋了,Anthropic 拿捏的时机再精准不过了。”网友纷纷表示,“现在唯一让用户留在 ChatGPT 的因素就是迁移成本,而他们直接把这道门槛彻底拆掉了。”还有人感叹,“这彻底改变了游戏规则,用户不再被绑定在某一个 AI 上,而是可以无数次自由选择最好用的那个。”

 

参考链接:

https://www.bloomberg.com/news/articles/2026-03-02/anthropic-s-claude-chatbot-goes-down-for-thousands-of-users

https://status.claude.com/

 

前言:当“免费”的代价开始显现

在构建AI知识库或文档解析系统时,许多技术团队会遵循一个看似完美的路径:首先拥抱开源。理由充分——零授权成本、源码透明、社区活跃。在概念验证阶段,这一切运转良好。然而,随着项目从试点走向规模化部署,一系列连锁问题开始集中爆发,往往让团队陷入“骑虎难下”的困境。

本文将剖析这一普遍现象背后的真实原因,并基于多个行业的实际案例,梳理从开源验证到生产部署的关键认知转变。

一、为什么早期选开源文档解析是合理的

在项目初期,选择开源方案具有其合理性。

  • 成本透明:没有授权费,一次性投入只是开发成本。相比商业产品的license,开源的“免费”特性具有天然吸引力。
  • 技术自主:源码在手,有问题可以自己改。这种“可控性幻觉”对技术团队特别有诱惑力——感觉一切都在掌握中。
  • 学习曲线短:PoC 阶段效果通常还不错。国内外各款开源工具在单页文档、标准场景下表现通常令人满意,足以通过早期的Demo评审。
  • 风险感知低:没有供应商依赖,从组织风险的角度看起来“更安全”。

所以,选择开源做试点,本身没有错。真正的误区在于,把试点阶段的成立性,误认为是生产阶段的可行性

二、真实项目中,哪些变化开始出现?

当从PoC转向真实业务部署时,挑战接踵而至。

1、文档复杂性的指数级增长

试点时使用的“教科书式”PDF与业务中的真实文档相去甚远:

  • 案例A(国家级大数据平台):需处理成千上万页的学术文献、专利和标准,内含大量复杂跨页表格。
  • 案例B(国内顶级律所):文档布满手写签名、印章、涂改痕迹,且扫描质量参差不齐。
  • 案例C(头部私立医院):病历、医学文献、诊疗指南格式杂乱,图表注释专业性强。

开源工具通常针对“标准 PDF”优化,一旦遇到真实业务数据的多样性时,准确率往往断崖式下跌。

图片

                         标准PDF文档

图片

                         真实医疗场景下的复杂文档

2、性能与运维瓶颈暴露

  • 速度问题:某基金公司反馈,国内某主流开源方案解析速度慢,且缺乏详尽的性能基准数据。
  • 资源利用不足:国家某大数据平台项目,在RTX 4090显卡上单页解析仍需2秒,硬件资源没吃满,性能调度不清楚。
  • 部署不确定性:某券商团队花费4-5天才测出效果,部署推荐配置让人不放心。

开源方案的性能优化多停留在“能用”层面,远未达到“可靠运维”的生产级标准。

3、维护成本突然增加

  • 支持缺失:某律所遇到Bug时,发现开源社区响应缓慢,自有团队难以深入修复核心代码。
  • 定制两难:某ISV面对客户对效果的更高要求,陷入“自己改造开源代码”或“投入大量资源成本”的两难境地。
  • 责任真空:某基金公司采用开源方案后效果未达预期,却找不到任何一方为此负责。

问题出现了,没有官方支持、没有SLA承诺。要么自己改源码(需要开发人力成本),要么搁置(项目延期)。

4、任务调度和多租户问题

真实业务部署后,会有:

  • 优先级管理:不同业务方的任务优先级不一样
  • 队列堆积:某个业务方突然大量上传,占满了资源
  • 监控缺失:不知道每个任务的处理进度、卡在哪步了

开源方案通常没有生产级的任务调度能力。例如一个典型场景:高中低优先级不生效,高优任务要等低优任务跑完才能开始。

5、结果稳定性难以保障

  • 跨页表格效果效果不好,官网与开源部署后的体验不一致;Excel会有内存溢出问题。
  • 多页扫描件中间页不识别,当成图片了。
  • 同一套代码,在不同条件下结果不一致。

这种输出的不稳定性,对于下游严重依赖其结果的RAG、抽取系统而言,是致命的。

三、这些问题为什么不是“优化能解决的”?

很多技术负责人的第一反应是:“我们再调调参数、优化一下代码”。但真相往往更复杂:

1、错误的不可逆性

文档解析的很多错误是不可逆的。比如:

  • 表格识别错了,把表头当成内容,下游的Embedding、RAG就基于错的数据。
  • 段落切分错了(本来应该分两个段落,却糅合成一个),后处理无法恢复层级关系。

解析阶段必须一次做对,否则下游再强大的大模型也救不了。

图片

                  解析对下游Chunking质量存在决定性影响

2、多文档类型的覆盖问题

开源工具通常是一个通用方案。但不同行业、不同文档类型的要求差异很大:

  • 法律文书:需要识别条款、编号、注脚。
  • 医学文献:需要识别图表注释、参考文献类型。
  • 财务报表:需要识别跨页表格、合并单元格。

要让一个开源工具覆盖所有场景,要么维护一套庞大的 if-else 规则(难以维护),要么接受效果不够好(业务受影响)。

3、工程可观测性缺失

开源方案没有生产级的日志、监控、告警体系。当效果下降时:

  • 不知道是哪个环节出问题(OCR?切分?还是后处理?)
  • 不知道是普遍问题还是特定文档问题
  • 无法快速定位和回溯

真实场景一般需要:调度链路公开,明确每个任务跑的过程、每个步骤的耗时。但开源方案很难提供这样的透明度。

四、技术问题会如何转化为业务/组织风险?

技术层面的挑战很快会向上渗透,转化为实实在在的业务风险:

1、项目延期风险

  • 某知识库项目用于施工参考,识别准确率有问题 → 建议不可用 → 项目无法上线。
  • 某大数据处理项目需要在2周内上线系统,用开源工具实现可能性较小。

2、数据质量问题引发决策风险

  • 银行、证券的 AI 平台:如果 RAG 的源数据有问题,最终给分析师的建议就是误导。
  • 医疗领域:病历识别错了,可能影响诊疗建议。

这不只是“效果差”,是业务风险

3、隐形人力成本爆发

一开始觉得“免费”,但到了项目后期:

  • 需要负担一个专职团队的人力成本去维护、修改源码。
  • 需要手工处理那些识别错的文档。
  • 需要不停地调参、优化。

最终的总成本(开发投入+人力成本)往往超过一开始选商业方案的成本。

4、组织风险:决策链条被拉长

  • 有的团队一上来选择主流开源方案,结果发现又要审核开源、又要做定制开发。
  • 也有的团队选自研解析,后续发现效果不符合预期,仍需要进一步外采,试错成本高。

每次变更都意味着重新论证、重新测试和重新部署。

五、成熟组织通常如何处理这类问题?

我们和各行业头部客户接触下来,大家有一些共同模式:

1、阶段性思维:POC 和生产要分开

  • 某数据厂商:2023年试过开源,效果不行就中止了。直到2024年验证有更好的方案,才重新立项。
  • 某基金:经过数月测试,最初关注的是解析能力本身,最后意识到开源的问题在于没有服务支撑。

不是开源不行,而是PoC有效 ≠ 生产可行。

2、建立评估标准,在规模化前验证

某数据厂商:对精度要求极高,否则会发生误报。因此选择时特别谨慎,要使用跨页表格最好的引擎。
某证券:注重文档底层能力,作为建设AI中台的基础设施使用。

他们发现:解析质量直接影响下游应用的可信度。

3、把解析当作专业化能力,而不是“一个模块”

领先的运营商和医院客户普遍经历了一个认知进化过程:从自研或开源,最终转向专业的商业方案或API服务。他们视文档解析为影响业务质量的“能力中心”,而非可妥协的“成本中心”。

六、本质上发生了什么?

问题的核心并非开源工具本身“不行”,而是在于阶段错配

阶段开源方案商业方案
PoC验证✓ 成本低,效果够用× 成本高,过度配置
试点扩大△ 开始暴露问题△ 需要运维支撑
生产规模× 维护成本高,效果不稳定✓ 生产级 SLA,专业运维

开源方案在PoC阶段的优势明显。然而,一旦进入生产规模,其隐性成本会呈几何级数增长,最终总拥有成本可能远超商业方案:

  • 人力成本(维护、调试)
  • 质量风险(错误率无法保证)
  • 机会成本(技术团队被牵扯,无法做更有价值的工作)

七、值得思考的问题

如果你的团队现在在用开源方案做文档解析,可以问自己:

  • 选择开源,主要是出于成本控制还是技术考量
  • PoC的效果验证,是基于理想的标准文档,还是具代表性的真实业务数据?
  • 如果效果不达预期,是否有明确的升级或备选方案?
  • 当下游业务系统已深度依赖当前解析结果时,更换方案的代价有多大?
  • 谁在承担效果不足带来的业务风险?

如果答案显示:你们已处于生产环境、处理复杂数据、下游高度依赖且无备选,那么很可能已走到了必须进行架构评估与升级的十字路口。

小结

开源文档解析方案绝非能力不佳,它们是技术探索和原型验证的宝贵工具。真正的教训在于,不应将PoC的成功直接等同于生产部署的可行性

两者之间存在一条由工程化能力、专业维护、稳定性和商业支持所构成的鸿沟。许多团队在项目后期才发现这个问题,那时已背负业务承诺并投入大量沉没成本,改方案的成本反而更高。

明智的做法,是在规模化前主动进行这场关键的评估: 不仅要问“这个工具技术能力牛不牛?”,更要追问“用它支撑核心生产系统,我们面临的真实成本与风险是什么?

毕竟,在AI落地的道路上,选择的代价,往往在做出选择很久之后才会完全显现。

上海自如口碑一直较差,以前看 diygod 在家睡觉被破门而入,没想到今天也轮到我了。

上午自如管家突然说让我 2 天内补交尾款,否则冻结门锁。我赶紧看合同,3 个月总金额 1.6w ,7k 定金已交,本来尾款约定 15 天内对公打款,入住第 8 天,开始用冻结门锁威胁我在第 11 天必须打款。我让他提供冻结门锁的合同依据,给不出来。

我是企业租房,知道他想借此施压让我去催公司付款流程。确实被恶心到了,更不可能帮他催流程。

后面准备安装阻门器+录音+摄像头,防止整别的死出。

大家用自如租房得注意避坑,租客没违约的情况下,管家是没有权利以冻结门锁提要求的,合同上也没写这种条款。自如很多贴牌房,很不正规,看房某自如寓,对公转账+开发票,要求租客补 3%税点。企业租房整体成本比链家这种收半个月中介费更高。

最讨厌被威胁,有机会的话,我要推动部门换掉自如😡。

https://s41.ax1x.com/2026/03/04/pe9MxAI.jpg

如果您想确保 iPhone 数据的安全,可以将 iPhone 备份到 Mac。当系统出现故障、设备丢失或 iOS 设备恢复出厂设置时,您可以轻松地使用备份恢复内容。本指南提供了 5 种有效的备份方法,您可以按照步骤将 iPhone 备份到 Mac。

图片

比较以下5种备份方法:

图片

第一部分:如何使用 Finder 将 iPhone 备份到 Mac

自 macOS Catalina 起,Finder 已成为本地备份的主要工具,取代了传统的 iTunes。因此,您可以使用 Finder 通过 USB 将 iPhone 备份到 Mac。

以下是步骤:


使用 USB-C 数据线将 iPhone 连接到 MacBook。打开 Finder,然后在侧边栏的“位置”下选择您的 iPhone。


如果出现提示,请在 iPhone 上轻点“信任”,然后输入您的密码。在“通用”标签页中,选择“将 iPhone 上的所有数据备份到此 Mac ”。


选择“加密本地备份”以包含密码和健康数据(如果需要)。然后单击“立即备份”。

图片

第二部分:如何使用 iReaShare iPhone Manager 将 iPhone 备份到 MacBook

对于觉得 Finder 功能过于局限的用户来说,iReaShare iPhone Manager这款灵活的工具会更合适,它支持“选择性备份”的方式。您可以在界面上预览 iPhone 数据,从而有选择地将联系人、信息、照片、视频、音乐、书籍、备忘录、日历等内容从 iOS 设备备份到 MacBook。

iReaShare iPhone Manager 的主要功能:

  • 无需 Finder 或 iTunes,即可通过 USB 将 iPhone 一次性备份到 Mac。
  • 使您能够查看和选择性地将 iPhone 文件传输到您的计算机。
  • 支持传输短信、书签、电影、语音备忘录、歌曲、文档等。
  • 轻松将 Mac 上的数据恢复到 iOS 设备。
  • 允许您访问计算机上的备份数据。
  • 兼容 iOS 5.0 或更高版本,包括 iOS 26。

请在电脑上下载这款iPhone备份软件。

下载 Mac 版下载 Win 版

以下是如何使用 iReaShare iPhone Manager 将 iPhone 备份到 MacBook:


在您的Mac电脑上下载并安装此备份软件的Mac版本。然后打开软件,并使用USB数据线将您的iPhone连接到电脑。


在 iPhone 上点击“信任”,程序就会识别你的设备。要一次性备份多种数据类型,你可以点击“超级工具包”>“ iTunes 备份和恢复”。

图片


选择“备份”功能,然后选择您的 iPhone 设备。接下来,您可以选择一个文件夹来保存备份数据。最后,点击“确定”开始备份过程。


第三部分:如何使用隔空投送将 iPhone 备份到 MacBook

如果你只想将几个文件备份到 MacBook,可以使用隔空投送 (AirDrop)。它可以在没有互联网连接的情况下将文件从 iPhone 发送到 Mac。

以下是指南:


请在 iPhone 和 Mac 设备上启用“蓝牙”和“ Wi-Fi ”。然后打开“访达”>“隔空投送”,并将“允许以下用户发现我”设置为“所有人”或“仅限通讯录”。


在 iPhone 上,前往“设置” ,轻点“通用”>“隔空投送”,然后选择“所有人,10 分钟”。接下来,找到您想要备份的文件。

图片


在 iPhone 上选择文件,然后点击“共享”>“隔空投送”。接着选择 Mac 的名称。然后在 Mac 上点击“接受”>“保存到下载”。

图片

第四部分:如何使用 Google 云端硬盘将 iPhone 备份到 MacBook

对于不想使用 iCloud 的 iPhone 用户来说,Google 云端硬盘提供了一种替代的云端备份服务。虽然它不像 iCloud 那样备份所有内容,但它可以存储照片、视频、联系人和文档。此外,上传后您还可以将文件下载到 Mac 上。

以下是如何通过 Google 云端硬盘将 iPhone 备份到 MacBook 的方法:


在 iPhone 上打开 Google 云端硬盘应用。登录或注册一个帐户。然后点击“菜单”图标 > “设置” > “备份”。


选择要备份的内容,然后单击“开始备份”。

图片


完成后,您可以通过访问 Google 云端硬盘网站或使用桌面应用程序在 MacBook 上访问这些文件。

图片

第五部分:如何通过图像捕捉将 iPhone 备份到 MacBook

如果您只想备份 iPhone 中的视频和照片,可以使用 macOS 内置的应用程序“图像捕捉”。

通过“图像捕捉”将 iPhone 备份到 MacBook:


使用 USB 数据线将 iPhone 连接到 Mac。


在 Mac 上打开“图像捕捉” (位于“应用程序”文件夹中)。然后从设备列表中选择您的 iPhone。


选择要保存照片和视频的文件夹。然后在底部的“导入到”下拉菜单中选择目标文件夹,然后点击“全部下载”。

图片

第六部分:关于在 Mac 上备份 iPhone 的问答

问题1:将iPhone备份到iCloud还是电脑更好?

这取决于您的优先级。iCloud 更方便,因为它可以通过 Wi-Fi 自动备份。但是,电脑备份(Finder)恢复大量数据速度更快,而且不需要每月订阅费。

Q2:为什么我的 iPhone 无法备份到我的 Mac?

iPhone 无法备份到 Mac 可能有以下几个原因:

连接问题:请确保您的 iPhone 通过有线或无线网络正确连接到 Mac。
软件版本过旧:请确保您的 macOS 和 iOS 系统均为最新版本。
存储空间不足:您的 Mac 可能没有足够的空间进行备份。
信任设置:检查您的 iPhone 是否信任 Mac,并输入正确的密码。

Q3:Mac 上的 iPhone 备份是否包含所有内容?

差不多。Finder 备份几乎包含您设备上的所有数据和设置。但是,出于安全考虑,它不包含已同步到云端的内容(例如 iCloud 照片或 Apple Music)或 Face ID/Touch ID 设置。另外,备份内容还取决于您选择的 iPhone 备份方式。

结论

将 iPhone 备份到 Mac 电脑很简单,对吧?使用上述方法,您可以通过 USB 或无线方式备份 iPhone 数据。如果您需要更全面、更精细的文件管理功能,可以试试iReaShare iPhone Manager 。这款工具支持一键备份和恢复,以及选择性文件传输。您可以将 iPhone 备份到 Mac,而不会丢失任何数据。

如果说两年前,AI 编程还只是“智能补全几个函数”;那么今天,它正在彻底掀翻整个软件工程的牌桌。

在最新的一期播客中,软件行业的传奇老兵、拥有 40 年编程经验的 Steve Yegge 分享了一个极其疯狂的日常:他刚刚在自己的机器上,关掉了 320 个 Claude Code 实例。

这意味着什么?这意味着他不再是一个“敲代码的程序员”,而是一个同时指挥着 320 个“数字实习生”的将军。有人在写代码、有人在修 Bug、有人在发起合并请求(PR),它们互相等待、互相打断,甚至偶尔还会失控搞砸一切。

在这场深度的技术访谈中,Steve Yegge 抛出了一个极其炸裂的预判:“到今年(2026)年底,人们开发软件将不再是敲代码,而是像玩即时战略(RTS)或模拟经营游戏一样。” 与此同时,他也给出了一个关乎所有软件公司生死的“未来生存公式”。

一、 个人开发者遭遇“团队级复杂度”:多智能体协作的失控与救赎

随着大模型能力从 GPT-3.5 的“步履蹒跚”进化到 Claude 4.5 的“狂飙突进”,开发者对 AI 的信任度与日俱增。

但一个致命的悖论出现了:信任度越高,耐心越低,唤醒的智能体就越多。过去,你可能只开一个 Claude 窗口帮你写段脚本;现在,你会习惯性地把一个大项目拆成十几个任务,同时扔给十几个智能体并行处理。

当规模达到这种程度时,个人开发者突然撞上了一堵墙——他们遭遇了以往只有大型工程团队才会遇到的管理难题:状态同步、代码合并冲突、上下文遗忘。大模型是“顾头不顾尾”的,它们只关注眼前的任务,根本记不住三小时前做过的架构决策。

为了解决这个问题,Steve Yegge 开发了两个重量级工具:

  1. Beads:一种基于图结构和 Git 原生数据库(Dolt)的“共享记忆系统”。它把所有智能体的任务、决策、状态全部记录在案,让 AI 拥有了不被篡改且可追溯的“长期记忆”。
  2. Gas Town:一个多智能体编排系统。它把智能体分门别类,有的当“镇长(发号施令)”,有的当“工兵(干脏活累活)”,让它们在一定的规则下自行运转。
【笔者观点:从“代码搬砖”到“架构调度”的职能跃迁】
我们正在见证程序员职业生涯中最伟大的一次职能跃迁。当 320 个 AI 在替你写代码时,你如果还把精力花在纠结某个 JS 语法上,那就是严重的失职。
未来的顶尖工程师,本质上是一个“数字包工头”或“Prompt 架构师”。你需要具备强大的宏观系统思维能力,把大问题拆解给 AI,然后像玩《星际争霸》一样去调度这几百个单位,最后负责最核心的“验收与兜底”。写代码不再是壁垒,“把问题说清楚、把上下文喂对”才是真正的护城河。

二、 AI 时代的极限拉扯:精简上下文 vs 填鸭式喂养

在指挥 AI 大军时,怎么给它们下达指令成了最玄学的问题。Steve 透露,即使在 Anthropic(Claude 母公司)内部,也存在极大的路线分歧:

  • 最小化派:认为应该尽量减少上下文。把任务拆得极细,一次只让 AI 专注解决一个明确的小问题(用完即弃)。这样能大幅节省 Token 成本,且运行速度最快。
  • 最大化派:认为应该把所有的背景信息、架构文档、历史决策全部塞进上下文窗口。因为只有“喂饱了”信息,大模型才能像资深架构师一样,做出真正符合全局利益的战略设计。

Steve 认为,这两种模式在实战中缺一不可。他甚至为 AI 发明了一条名为“飞机降落(Land the Plane)”的终极提示词——当项目进入收尾、AI 开始迷失在海量细节中时,这句提示词能强行唤醒大模型的“强迫症”,逼迫它放下一切发散思维,严格按照验收标准逐项核对,完成最终交付。

【笔者观点:驯服 AI 的艺术,在于理解它的“拟人性”】
我们过去写代码是“面向机器编程”,有着严格的编译逻辑;现在用大模型,更像是“面向人学编程”。大模型有常识、懂战略,但它同时也很“懒”、容易“分心”、甚至会“敷衍了事”。
所谓的“飞机降落”提示词,本质上就是对数字员工的“职场极限施压”。谁能掌握这种和 AI 沟通的心智博弈技巧,谁就能榨干它最大的生产力。

三、 颠覆认知:阅读别人的代码,将成为历史?

当 AI 开始疯狂输出代码时,代码的海洋将彻底淹没人类的阅读能力。

过去,接手别人的 30 万行代码是一场灾难;未来,即使是自己麾下 AI 昨晚刚写的 30 万行代码,你可能也完全看不懂了。

面对这种代码爆炸,Steve 给出了一个极度硬核但也有些无奈的解法:你必须强迫自己定期去审查那些从未见过的代码片段,通过向大模型提问(比如“不好意思,我们的插件系统到底是怎么跑的?”),在脑海中重新构建出整个系统的心理模型。因为只有你,才是那个能拍板“这东西到底对不对”的最终防线。

【笔者观点:代码即垃圾,意图即资产】
我们必须接受一个残酷的现实:在 AI 时代,由人类亲手一行行阅读、审核每一行代码的古典敏捷开发模式,已经彻底破产了。
当 AI 每秒能生成几千行代码时,代码本身变得极度廉价。未来的软件工程不再是“Show me the code(给我看代码)”,而是“Show me the prompt & Spec(给我看你的提示词和系统规范)”。人类只需要掌控意图和测试闭环,至于中间那几百万行冗长、枯燥的实现逻辑,就让 AI 自己去折腾吧。

四、 终极预判:软件的“热力学”生存法则

在播客的最后,Steve 抛出了一个决定未来所有软件公司生死的“万能公式”。

在很多人担忧“AI 将吞噬一切软件(比如各种 SaaS、IDE、刷题工具都在死掉)”时,什么样的产品能活下来?

Steve 给出的答案是:“热力学定律”——谁能帮大模型节省 Token 和计算能量,谁就能活下去。

大模型是非常“懒”的,它永远倾向于走最短、最省力的路径。如果你的工具(比如数据库、消息队列、索引系统、API)能够让 AI 以极低的 Token 消耗,快速拿到精准的数据和结果,那么 AI 就会把你纳入它的“默认工具箱”。

反之,任何可以通过大模型自身的“矩阵乘法”和“推理”来完成的工作(比如简单的计算器、文本处理工具、粗糙的增删改查 SaaS),都会被大模型无情地绕过并吞噬。

【总结陈词:成为 AI 的“基础设施”,或者被 AI 摧毁】
这是一个极具压迫感但也极度清醒的论断。
未来的两年内,我们手机和电脑里的 App 可能会消失 80%。你不再需要各种花哨的独立软件,你只需要一个类似 Claude 或 ChatGPT 的超级入口,它会帮你搞定一切。

在这场大洗牌中,留给创业者和开发者的路只有两条:
要么,你去做大模型本身(属于巨头的游戏);
要么,你去做那些大模型嫌麻烦、算不准、或者没权限碰的基础设施和数据源(成为 AI 的基建)。

属于手工敲代码的古典时代已经结束了。准备好迎接这场疯狂的“即时战略游戏”吧,无论你是期待还是恐惧,它都已经开始了。


👇 欢迎关注我的公众号

在 AI 爆发的深水区,我们一起探索真正能穿越周期的技术价值。
微信搜索 【睿见新世界】 或扫描下方二维码,获取每周硬核技术推文:

微信图片_20260301232734_225_35.jpg

欢迎关注【睿见新世界】!

Apple Music 免费领取半年订阅会员活动到 3 月 5 日截止,还没领取的 V 友可以领取一波。

但之前被薅了一波苹果也改了规则,现在订阅后不能立即取消,不然权益就没了,所以大家要自己设置个提醒事件在半年到期前提醒自己取消续订,不然会自动扣款,11 元/月。

原则上只能 iOS 、macOS 、iPadOS 等设备领取,其他设备应该也可以,但能不能领取半年就不知道了,有可能只有 1 个月。

曾经取消订阅的老用户也可以,具体视账号情况而定,有 V 友反馈老用户也领取半年,但也有 V 友反馈 1 个月都没,必须付费开通。

领取地址:https://ourl.co/amsc (不要 PC 点击,不然可能只有 1 个月)

iOS 相机可以直接扫码,安卓用户也可以使用微信扫码并使用自带浏览器打开:

点击链接后自动跳转到 Apple Music 看到领取提示(若未安装会先跳转商店安装)

本文作者是「测试套件」功能的产品负责人,旨在分享该功能背后的设计思路,包括我们为什么这样设计产品、决策的理由是什么。欢迎所有关心 Apifox 产品设计理念的朋友阅读了解\&讨论。

“我有 200 个用例,但发版只想跑其中 20 个”

先说一些我们经常听到的真实用户反馈。

自动化测测试真实用户反馈

你会不会有同样的想法?或者你是不是也有印象在我们的群里看到类似的言论?

这些需求有一个共同点:用户不是要“运行用例”,而是要“按条件组织用例,然后运行”

现有的功能是按“用例”维度设计的——你选择用例,然后运行。但用户需要的是按“规则”维度:告诉系统一个条件,符合条件的用例自动执行。

按条件组织用例

回看我们的现状

场景用例是我们自动化测试能力的核心。它允许你自由编排多个接口请求,按照真实的业务流程顺序执行——登录、创建订单、支付、查询订单状态。这套能力我们打磨了很长时间,用户反馈也相当正向。围绕场景用例,我们还提供了丰富的运行方式:

  • 按目录批量运行:选择目录 - 在目录中再选择想要运行的场景用例,然后批量运行目录中所有被选中的用例;
  • CLI 与流水线集成:通过命令行工具接入 CI/CD,代码合并自动触发测试;
  • 定时任务:设置定时器,根据定时器触发自动执行巡检;

这些能力覆盖了“怎么跑”的问题。但用户的需求并没有完全被满足。所以我们收到了上面的那些吐槽。

自动化测试的两个层次

我们一直在思考:如何让用户在 Apifox 上完成从 API 设计、开发、调试到测试的完整闭环?

设计阶段有 API 文档,开发阶段有 Mock 服务,调试阶段有接口测试,那测试阶段呢?场景用例解决了“如何编排一个完整的业务流程”,但没有解决“如何在不同阶段、不同需求下灵活组织测试范围”。

于是我们把自动化测试的需求拆分为两个层次:

层次核心问题对应功能
编排层如何把多个接口按业务流程串起来?场景用例
执行层如何按条件灵活选择“跑哪些用例”?测试套件
  • 场景用例是“造积木”:你定义每一块积木长什么样(一个完整的业务流程)。
  • 测试套件是“搭积木”:你决定这次要用哪些积木搭成什么形状(按条件筛选、组合、执行)。

两者不是替代关系,而是分层协作。场景用例管“内容”,测试套件管“组织和执行”。以上就是测试套件这个新资源类型诞生的背景。

分层协作

一、静态还是动态?

在设计测试套件时,我们面临一个根本性的问题:

用户把用例加入套件后,套件里的内容是固定的,还是会跟着变化的?

场景一:冒烟测试——软件行业的“健康体检”

“冒烟测试”这个词来自硬件行业:给一块新电路板通电,如果没有冒烟,说明起码没有短路,可以进行下一步测试。

在软件行业,冒烟测试的核心思想是:用最小的成本验证系统是否“基本正常”。它不追求覆盖所有功能,只验证最核心的业务路径——用户能登录吗?能下单吗?能支付吗?

冒烟测试有几个典型特点:

  1. 用例数量少但精选:通常只有 5-15 个核心场景
  2. 变动频率低:经过评审确定,不会轻易增删
  3. 执行频率高:每次代码提交都可能触发

这种场景需要“静态模式”:我指定了哪些用例,就永远跑这些用例,除非我手动修改。

场景二:按模块回归——用规则代替人工维护

假设你负责支付模块,有一个文件夹叫“支付功能”,里面有 50 个用例。每周可能新增几个,也可能删除几个。你希望每次回归都覆盖这个模块下的所有用例,不用每次都去检查有没有新增的。

这种场景需要“动态模式”:我告诉系统一个规则(支付功能目录下的所有用例),系统每次运行时自动匹配。这个设计在 AI 时代尤为重要。 随着 Copilot、Cursor 等 AI 编程工具的普及,代码生成的速度在加快,测试用例的产出也在提速。如果每次新增用例都要手动维护回归列表,维护成本会随着 AI 生产力的提升而线性增长。动态模式让用例的“生产”和“组织”解耦——你只管写用例,套件会自动把符合条件的新用例纳入进来。

静态模式与动态模式

我们的决定

经过长时间研究、收集用户反馈与调研,我们认为两种模式都是真实需求,我们选择都支持

但这带来一个用户体验问题:选项太多会让人困惑。所以,在产品界面的设计上,我们加上了很多的思考:

  1. 不过于强调“静态”和“动态”这两个词: 对用户来说,这是引入了新的概念,可能会有一定的理解成本,所以不能在界面上过于强调这两个概念,并且不能在使用的位置只暴露这两个概念文案,这样会增加用户思考,带来较差的体验。
  2. 用操作和界面元素引导: 当用户选择“静态”时,右侧的详情列表会出现复选框引导用户要选择具体的接口、场景用例,并且最后一步确认按钮会明确告知“选择 X 个选项”;当用户选择“动态”时,右侧的详情列表仅是只读模式,不可选择其中的一部分,从而告知用户你是在使用“这个条件下的全部内容”。
  3. 文字介绍辅助: “后续如有新增且符合当前条件的用例,会自动加入”这些文案,会再次告知用户动态的意义,让用户知道这个套件会“活着”。

这样设计的好处是:用户不需要花过多的精力去思考与理解“静态”和“动态”的概念差异,阅读大量文本,只需要按自己的场景操作,在操作的过程中就自然而然的对这两个模式有个基本的理解。

二、统一配置还是各跑各的?

每个测试场景可能有自己的运行配置:用开发环境、测试环境还是预发环境?循环多少次?这些配置在创建场景时已经设置好了。现在把多个场景放到一个套件里,问题来了:用谁的配置?

用户的两种诉求

诉求 A:“我想让套件里的所有用例都跑测试环境,不管它们原来的配置是什么。”

这在全量回归时很常见。你希望有一个统一的“回归环境”,消除环境差异带来的干扰。

诉求 B:“每个场景跑自己的环境就行,我设置好了的。”

这在日常执行时很常见。支付服务跑支付测试环境,用户服务跑用户测试环境,配置早就设好了,没必要改。

我们的决定

这两种诉求看似矛盾,但我们发现可以用“默认值 + 可选覆盖”的模式来调和。

关键问题是:默认值选哪个?

默认情况下,每个场景按自己保存的配置运行(除了环境)——这是最“符合直觉”的行为。你之前怎么配的,现在还怎么跑。

环境配置会很特殊,因为在测试套件的运行配置里,是很直观可见的一个配置。而且针对不同类型的资源,使用环境的方法差别很大:

  • 单接口用例:无论动态还是静态的单接口用例,环境都是使用套件指定的环境——跟单接口本身指定的环境方式一致,很好理解。
  • 静态场景用例:在多数情况下,静态的场景用例都期望使用测试套件中的环境配置,所以我们为此情况单独设置了一个“继承自套件”的默认值——这样套件一切整个套件内的用例统一联动,方便使用。
  • 动态场景用例:在多数情况下,动态的场景用例同样期望使用测试套件中的环境配置,所以默认是一套自定义的配置并且环境是继承套件中设置的环境。不过当然,如果你期望这些用例使用你已经在场景用例中编排设置好的各种配置,你可以选择从这些场景用例里面来继承运行配置实际运行。

如果用户需要统一配置,可以选择“使用相同配置运行”,然后指定一套独立配置。这个选项的位置放在“高级配置”里,不干扰常规使用路径。

并行执行,让你的套件快快跑

当测试套件增长到数百个时,串行执行会成为自动化交付的瓶颈。一个完整的回归测试可能需要一小时才能完成,这会延迟发布流程并减慢生产监控中的问题检测。

并行执行

测试套件默认支持并行执行。只需在串行和并行模式之间一键切换——系统会根据运行机器可用资源自动确定最佳并发性。无需手动调整。这可以将60分钟的回归测试缩短至30分钟以下,而无需更改测试逻辑。

并行执行自动处理依赖隔离。每个场景都在自己的上下文中运行,确保一个场景的共享变量或环境状态不会干扰另一个场景。对于真正相互依赖的场景,你需要将其分组为具有顺序步骤的单个场景。

并行执行与串行执行

三、和目录批量运行的边界

Apifox 已经有“测试场景”的批量运行功能——在场景目录上右键,可以批量运行整个目录下的场景。

测试套件不就是换了个名字吗?有什么区别?

本质区别

  1. 场景目录是按“物理结构”组织的——你把用例放进哪个文件夹,就属于哪个分组。一个用例只能属于一个文件夹。
  2. 测试套件是按“逻辑规则”组织的——你定义一套筛选条件,符合条件的用例自动归入。一个用例可以同时属于多个套件。

物理结构与逻辑规则

举个 🌰:

  • “支付模块回归套件”包含所有“支付”标签的 P0/P1 用例
  • “全量冒烟套件”包含所有 P0 用例
  • 某个用例如果同时是 P0 且带有“支付”标签,它会同时出现在两个套件里

这种灵活性是目录结构做不到的。

为什么还需要一个新的资源类型?

你可能会问:场景用例已经可以跑了,目录批量运行也有了,为什么还要专门做一个“测试套件”?

答案是:

我们在为“场景化测试”的未来做准备。

现代软件开发的一个趋势是:测试场景的数量随着 AI 生产代码会越来越多,但测试方法是会越来越标准化的。

想想看,你的团队可能面临这些情况:

  1. 日常开发:跑冒烟测试就够了;
  2. 版本发布:要跑全量回归;
  3. 紧急修复:只跑受影响模块的 P0 用例;
  4. 线上巡检:每小时检查核心接口;
  5. 灰度发布:对比新旧版本的接口响应。

这些场景对“跑哪些用例”的要求完全不同,但底层的用例是同一批。你只应该编排功能的业务流程并保存为一个个用例,为了“回归”这种测试的执行需求,从而编排一个用例来解决,这是不合逻辑、也不好维护的。

场景化测试

更重要的是,这种“积木化”的思路可以大幅降低测试环境的模拟成本。过去你可能需要为每个测试场景搭建专属的沙箱环境,现在你可以用同一套环境、同一批用例,只是组合方式不同。套件成为连接“测试资产”和“测试需求”的桥梁。

这就是我们做测试套件的真正意图:不只是让自动化测试 “能跑”,而是让自动化测试 “可复用”、“能按期望自动运行”

功能定位适用场景
场景用例业务场景的请求流程编排自动化测试基础搭建、构成业务功能单元
场景目录用例的物理归档位置日常用例管理、团队协作
目录批量运行快速跑一个目录下的所有用例功能回归、全量回归、探索性测试
测试套件可复用的测试执行单元版本回归、冒烟测试、定期巡检

第一版暂时没做的事情

做产品需要取舍。以下是我们讨论过但决定暂时不做的功能:

1. 套件嵌套

  • 场景:把多个套件组合成一个更大的套件。比如“全量回归”包含“支付模块回归”+“用户模块回归”+“订单模块回归”。
  • 为什么暂时不做:增加复杂度,而动态模式已经能解决大部分需求。如果你想跑多个模块,可以用动态模式匹配更大范围的标签或目录。
  • 如果用户确实需要:我们会观察数据,如果发现大量用户在创建内容高度重叠的套件,说明嵌套是真实需求,我们会重新评估。

你有“套件套套件”的需求吗?如果有,你的场景是什么?

2. 失败自动重试

  • 场景:某个用例因为网络抖动失败了,自动重试一次。
  • 为什么暂时不做:担心掩盖真实问题。如果一个接口偶发性失败,这本身可能就是需要关注的问题,而不是通过重试来“消除”。
  • 如果后续做:可能会作为可选策略提供,并在报告中明确标注“重试后通过”,确保问题不被隐藏。

你觉得自动重试是必要的吗?你更希望看到“干净的结果”还是“真实的结果”?

写给正在读这篇文章的您

测试套件这个功能,从用户反馈到产品上线,我们思考了很多,也放弃了很多。但我们深知,真正好的产品不是设计出来的,而是用出来的

我们可能漏掉了你最需要的功能,也可能把某个细节设计得让你用着别扭。这些问题,只有你告诉我们,我们才知道。

如果你试用了测试套件,欢迎告诉我们:

  • 哪个设计让你觉得“终于有人懂我了”?
  • 哪个操作让你卡住了、困惑了?
  • 你还期待什么能力?

你的反馈会直接影响我们下一版的优先级排序(真心!)期待听到你的声音 🙌

如果你对功能背后的设计有任何疑问,欢迎加入我们的微信、飞书等各种 IM 群中讨论。

这个工具看起来简单,实际开发时我先做了一件事:不急着写界面,先把“提取逻辑”做好。因为用户输入可能会非常杂,可能一段话里同时有中文、英文、数字、空格和符号,如果核心函数不稳,前端交互再漂亮也没用。

在线工具网址:https://see-tool.com/text-number-extractor
工具截图:

我最后把功能拆成两块:

  • extractTextNumbers:只负责提取。
  • countChars:只负责统计。

页面层只做参数传递和按钮动作,避免把业务细节塞进组件里。

先说提取函数是怎么定下来的

函数签名是这样:

export function extractTextNumbers(
  text,
  extractChinese = true,
  extractEnglish = true,
  extractNumbers = true,
  extractByLine = false,
  removeDuplicates = false,
  sortChars = false
) {
  if (!text || !text.trim()) return ''
}

这几个布尔值其实对应页面上的勾选项。这样有个好处:页面不需要做复杂映射,用户怎么选,函数就怎么跑。

我一开始想过用一条“大正则”把三种字符一次性提取完,但后来放弃了。原因很简单:可读性太差,后面再加规则会麻烦。所以改成逐字符判断,逻辑更长一点,但直观。

逐字符提取,比花哨写法更稳

核心循环没有技巧,就是老老实实遍历:

for (let i = 0; i < line.length; i++) {
  const char = line[i]

  if (extractChinese && /[\u4e00-\u9fff]/.test(char)) {
    lineResult += char
  } else if (extractEnglish && /[a-zA-Z]/.test(char)) {
    lineResult += char
  } else if (extractNumbers && /[0-9]/.test(char)) {
    lineResult += char
  }
}

这里我保留了 if / else if 结构,目的就是“一个字符只走一个分支”。这能减少边界行为,输出顺序也和原文一致,用户更容易理解结果。

按行提取和整体提取,走两条分支

extractByLine 打开时,流程是:先按换行切分,再逐行处理,最后把每行结果再拼回去。

const lines = text.split('\n')
const processedLines = []
// 每一行独立提取
return processedLines.join('\n')

这个模式很实用。比如用户在整理多行数据时,通常希望“第几行对第几行”,不希望全部揉成一串。

关闭按行模式时就简单了,直接整段提取,适合一次性清洗长文本。

去重和排序,顺序不能乱

提取完之后我把后处理固定成:先去重,再排序。

if (removeDuplicates) {
  result = [...new Set(result)].join('')
}

if (sortChars) {
  result = result.split('').sort().join('')
}

如果先排序再去重,结果也能对,但中间会多做无效工作,而且阅读代码时不如“先减量再整理”自然。

统计函数单独维护,页面就轻很多

统计逻辑我没有混进提取函数,而是单独写在 countChars

  • 普通模式:直接看长度。
  • 按行模式:行数只算非空行,总字符数不含换行。

页面里通过 computed 串起来:输入一变,提取结果自动变;提取结果一变,统计自动变。用户看起来就是实时更新,代码上也比较干净。

按钮动作只做三件事

页面脚本里和结果相关的动作只有三个:复制、下载、清空。

  • 复制:navigator.clipboard.writeText(extractedText)
  • 下载:Blob + URL.createObjectURL + a.click()
  • 清空:只改输入值,结果和统计由计算属性自动归零

到这里,这个工具的核心 JS 基本就闭环了:输入文本进来,规则提取,按需后处理,统计结果,再做复制或导出。没有绕太多层,但每个环节都能单独看懂、单独改动。

在工程设计、建筑施工、市政园林等行业,CAD 图纸版本不兼容是每天都在上演的难题。你刚画好的图纸,发给甲方、监理、施工班组,对方打开却提示:文件无效、版本过高、无法读取。为了一张图,要么求人转换,要么被迫安装高版本 CAD,既占空间又耗时间。其实解决这个问题,根本不用这么麻烦。
图片
浩辰CAD看图王,自带专业级 CAD 版本转换功能,轻松实现高版本图纸转低版本,让所有设备都能正常打开。它支持从高版本 DWG、DXF 图纸,批量转换成各年代通用版本:R14、2000、2004、2007、2010、2013、2018 等无论对方用多老的 CAD 软件,都能完美打开、编辑、查看。转换过程中,图纸内容完整保留:图层结构、线型样式、文字标注、图块属性、尺寸约束全部不变,不会出现丢线、丢字、乱码、图形错位等问题。操作步骤极简,三步搞定:
1.用浩辰 CAD 看图王打开图纸
2.点击「另存为」
3.选择需要的低版本,保存即可全程几十秒,轻松解决版本不兼容的行业痛点。
不管是设计师、资料员、现场管理人员,使用浩辰 CAD 看图王,CAD 版本再也不是沟通障碍。

平时整理聊天记录、表单内容、网页抓取文本时,常会遇到“只想保留文字”或“只想保留数字”的需求。为了让普通用户不用写代码也能快速处理内容,我做了这个文字/数字提取在线工具。

这个工具是我用 Vue(Nuxt 3) 开发的,打开浏览器就能用,电脑和手机都支持。输入内容后,页面会立即给出提取结果,适合日常办公和学习场景。

在线工具网址:https://see-tool.com/text-number-extractor
工具截图:

常见使用场景:

  • 从一段混合文本中提取手机号、快递单号、金额等数字信息
  • 从包含符号和编号的内容里只保留可读文字
  • 批量清洗复制来的杂乱内容,方便二次编辑和统计

使用方法非常简单:

  1. 把原始内容粘贴到输入框;
  2. 选择提取模式(仅文字 / 仅数字);
  3. 按需开启去重、去空格或保留换行;
  4. 实时查看结果并确认是否符合预期;
  5. 一键复制处理后的内容。

为了保证使用体验,提取过程在浏览器本地完成,不需要上传文本。对普通用户来说,这样既快又省心,尤其适合处理包含个人信息的内容。如果你经常需要从复杂文本里“拿出有用信息”,这个工具会比手动删改高效很多。

在硅谷,流传着这样一句话:“Jeff Dean 的简历,就是一部现代 AI 的发展史。”

作为谷歌首席人工智能科学家、Gemini 的核心缔造者,Jeff Dean 极少接受深度专访。近日,在一场长达 46 分钟的对谈中,这位亲手重写过谷歌搜索全栈、缔造了 TPU 硬件神话的传奇工程师,罕见地抛出了大量关于 AI 演进的犀利预判。

从“蒸馏技术”的底牌,到“万亿 Token”的野心;从“大一统模型”对垂直专家的降维打击,到未来职场“一人指挥 50 个虚拟实习生”的科幻场景。这场对话不仅是谷歌 AI 战略的底牌大揭秘,更是一份写给所有开发者的“未来生存指南”。

一、 速度即正义:为什么谷歌死磕 Flash 小模型与能耗?

在各大实验室拼命卷模型上限、争夺跑分王座时,谷歌却把极大的精力放在了 Gemini Flash 这种“高能效比”的小模型上。很多人不解,这是否意味着谷歌在向算力妥协?

Jeff Dean 给出的答案非常现实:前沿模型是为了探索能力的边界,而小模型是为了霸占真实世界的场景。

他透露,将庞大的前沿模型(如 Ultra、Pro)通过“蒸馏(Distillation)”技术压缩成轻量级的 Flash 模型,是谷歌的核心策略。通过蒸馏,小模型能够学到大模型处理逻辑的“暗知识”,从而在低成本、低延迟的前提下,达到甚至超越上一代大模型的水平。

更有意思的是,他从一个极其底层的工程师视角,解释了为什么“延迟和能耗”才是 AI 现阶段最大的瓶颈。他指出,计算本身(如乘法运算)极其便宜(不到 1 pJ),但把数据从内存搬运到计算单元的代价极其高昂(高达 1000 pJ)。“如果你花 1000 的力气搬数据,只做 1 的计算,那是极大的浪费。” 这就是为什么加速器必须用批处理(Batching),也是为什么极低精度(如三值精度)将成为未来的大杀器。

【笔者观点:不要被“跑分”骗了,低延迟才是杀手锏】
Jeff Dean 揭示了一个被很多人忽视的商业真相:在真实业务中,“快”比“聪明”更重要。
当 AI 的响应速度从 100 Token/秒提升到 1000 甚至 10000 Token/秒时,人机交互的范式将彻底改变。就像自动驾驶,你不需要车脑子里装满莎士比亚,你只需要它在 0.1 秒内决定刹车。谷歌疯狂推广 Flash 模型,甚至将其塞进搜索、Gmail 和 YouTube,本质上是在用“极低延迟+白菜价成本”对竞争对手进行生态降维打击。

二、 大一统模型的降维打击:垂直领域的“专家”要失业了?

过去几年,AI 界流行一种思路:通用模型搞不定专业问题,我们需要专门训练“医疗大模型”、“法律大模型”或者“奥数大模型”。

但 Jeff Dean 毫不客气地宣告:大一统模型的时代真的来了。

他以解决国际奥数难题为例,过去人们试图把神经系统和符号系统结合,搞各种专用工具;但现在,谷歌直接把所有的任务都塞进了统一的 Gemini 模型里,靠着更强的推理资源,纯语言模型就能解出数学竞赛题。“通用模型在绝大多数情况下,都会胜过专用模型。”

那么,垂直领域模型还有存在的意义吗?Jeff 的答案是:有,但它的形态变了。未来的 AI 就像现在的操作系统,核心是一个极其强大的通用基座(装满了世界常识),然后配合各种“可安装的模块”。当你需要看病时,你就像下载软件包一样,给基座模型挂载一个“医疗模块”,这个模块是被顶级医院的私有数据“喂”出来的。

【笔者观点:“套壳微调”创业的死刑判决书】
这对目前市面上大量做“行业垂直大模型”的创业公司来说,是个极其危险的信号。
靠拿几本行业白皮书、用开源基座微调一下就敢自称“XX 领域第一大模型”的时代彻底结束了。因为通用模型(基座)的进化速度太快,它会毫不留情地碾压这些浅层的垂直护城河。未来真正的垂直壁垒,只存在于那些掌握着“极其稀缺且无法公开获取的私有数据”(如顶级三甲医院的脱敏病历)的机构手中。

三、 跨越百万上下文:“把整个互联网塞进 AI 脑子里”

当目前的大模型还在为 100 万或 200 万上下文窗口欢呼时,Jeff Dean 的目光已经盯上了“万亿 Token”。

怎么做到?答案并不是简单粗暴地扩大神经网络的注意力机制(这在计算上是不可能的),而是借鉴了谷歌做搜索引擎的看家本领——分层检索。

系统会先用极低的成本,从海量信息中捞出 3 万个相关片段,再用更强的模型浓缩到 117 个,最后用最顶级的模型进行深度推理。这样一来,在用户体验上,模型就仿佛拥有了“处理万亿 Token”的神力。

这不仅适用于文本,更适用于视频、音频甚至激光雷达数据。Jeff Dean 坚信,视觉和动态时序(视频)是绝对的核心模态。当一个模型能够直接“看懂”你过去 20 年的所有邮件、照片和行车记录仪视频时,它将从一个“聪明的百科全书”,变成一个“全知全能的个人分身”。

【笔者观点:从“搜索引擎”到“答案引擎”的终极进化】
谷歌在长上下文和多模态上的执念,其实是在保卫自己的搜索帝国。
过去的搜索,是给你一堆蓝色链接让你自己找;未来的搜索,是 AI 瞬间翻完整个互联网和你的个人私有云,然后直接把那个你想要的“最终答案”递到你手里。谁能最快、最准、最便宜地完成这种“漏斗式”的信息提纯,谁就能拿到下一个十年的互联网入口门票。

四、 程序员的未来:从写代码,到管理“50 个数字实习生”

作为计算机历史上最高产的工程师之一,Jeff Dean 自己是怎么用 AI 写代码的?

他坦言,现在的代码智能体已经非常强大。未来的工作形态将发生剧变:每个工程师不再是单打独斗,而是化身为团队主管,手下带着 50 个“虚拟实习生”。

你不需要再自己去敲打每一行基础代码,你的核心技能变成了“极其清晰、无歧义地定义需求”。如果你没说清楚边界条件或性能要求,AI 就会乱写一通。因此,写一手高质量的提示词(Prompt)和内部系统架构备忘录,将成为未来程序员最重要的核心竞争力。

更有意思的是,当 AI 的生成速度突破 10000 Token/秒时,人类甚至不再需要去“阅读”它生成的代码了。AI 可以在后台疯狂地自我验证、自我推演 9000 行,最后只给你输出 1000 行绝对正确的完美代码。

【总结陈词:超级个体的崛起与平庸的消亡】
Jeff Dean 描绘的这幅图景既让人热血沸腾,又让人脊背发凉。
如果一个人能指挥 50 个 AI 实习生,那意味着什么?意味着传统的“人海战术”彻底破产,意味着初级程序员、外包工种将面临毁灭性的打击。
但同时,这也意味着“超级个体”的时代正式降临。只要你拥有顶尖的系统架构思维和极其敏锐的业务直觉,你一个人,就能活成一家上市公司。面对 AI 浪潮,焦虑毫无意义,学会如何当好这 50 个 AI 实习生的“带教大哥”,才是我们现在唯一该做的事。

👇 欢迎关注我的公众号

在 AI 爆发的深水区,我们一起探索真正能穿越周期的技术价值。
微信搜索 【睿见新世界】 或扫描下方二维码,获取每周硬核技术推文:

微信图片_20260301232734_225_35.jpg

欢迎关注【睿见新世界】!

一、为什么需要免费SSL证书?

SSL证书通过在用户的浏览器和你的服务器之间建立一条加密通道,保护用户提交的密码、个人信息等敏感数据不被窃取。

过去,许多人认为SSL证书价格昂贵且申请流程繁琐。但现在,随着行业技术的进步和众多服务商的推动,免费且自动化的SSL证书已经成为市场主流,尤其适合个人博客、中小企业展示站以及各类测试站点。虽然像阿里云、腾讯云等平台也提供免费证书,但其有效期通常已缩短至3个月,且多为单域名证书,需要频繁续期。

二、为什么重点推荐JoySSL?

在众多免费SSL证书服务商中,JoySSL凭借其对国内站长的友好度以及丰富的免费产品线脱颖而出。

1. 永久免费且支持通配符

JoySSL面向个人和中小企业提供永久免费的SSL证书。更难得的是,它提供免费的通配符证书。这意味着,你只需要申请一张证书,就可以同时保护一个主域名及其所有的二级子域名(例如同时保护 example.com 和 www.example.com 以及 mail.example.com),这对于搭建了多个子站点的用户来说非常实用且省钱。

2. 支持国密算法

JoySSL不仅是国际标准的SSL证书提供商,还深度支持国密算法。如果你所在的政务、金融或国企领域对国产密码算法有合规要求,JoySSL提供的“双算法”证书可以兼容国密浏览器和国际浏览器,实现“一处部署,全面兼容”。

3. 申请流程简单快捷

相比于国外的一些证书机构,JoySSL的官网界面和操作逻辑更符合国内用户的习惯。注册账号后,无需复杂的命令行操作,通过简单的域名验证即可快速签发。

三、手把手教你申请JoySSL免费证书

免费SSL证书申请入口

想要快速上手?只需以下四步:

第一步:访问官网并注册
打开浏览器,访问JoySSL官方网站。在注册账号时,建议填写官方推荐注册码 230970 以获取免费的通配符证书申请权限。

第二步:选择证书类型
登录后台,在证书产品列表中找到“永久免费SSL证书”或“免费通配符证书”选项。点击申请,填写你的一级域名(如 example.com)。

第三步:完成域名验证
为了证明域名是你的,JoySSL会提供两种验证方式。通常选择DNS验证:你只需要复制系统给出的TXT记录值,登录你的域名注册商后台,为该域名添加一条解析记录即可。添加完成后,回到JoySSL点击“验证”,通常几分钟内即可通过。

第四步:下载并部署证书
验证通过后,证书就会签发。你可以下载适配你服务器环境的证书压缩包(如适用于Nginx、Apache、IIS等)。解压后,根据里面的安装文档将其配置到你的服务器上。

四、结语

部署SSL证书不再是技术高墙,也不再是经济负担。通过JoySSL这样的平台,你可以在几分钟内零成本实现网站的HTTPS加密。

不要等到浏览器打出“不安全”的红字警告才行动。现在就去申请一张免费的SSL证书,为你的访客提供一个安全、可信的访问环境吧!


一同探索 Voice Agent、Physical AI 等对话驱动的下一代人机交互界面。

2026 开年,开源项目 OpenClaw 的热度证明了个人化 AI 的潜力。而我们更关心个人化 AI 如何真正进入并感知物理世界,与人一起和现实产生实时互动。

开发者 xiaoan(本期活动嘉宾之一) 推出的 VisionClaw(在 X 上有近百万次浏览和 1.4K Star) 展示了个人 AI 走进物理世界的一种可行路径——在给 Meta Ray-Ban 眼镜接入视觉与对话能力后,AI 可以识别现实中的饮料品牌型号,交流指令后直接操作电脑在亚马逊上完成下单。

这只是一个开始。从纯文本对话演进而来,Voice Agent 正在 Go Visual、Go Physical,并在往横跨桌面端、移动端与智能硬件的 Go Everywhere 发展。跨平台、多模态的落地实战已经展开。

本周六(3 月 7 日)下午,Physical AI Camp 北京站&RTE Meetup 落地北京。我们邀请了来自声网、矽递科技、Intent Company 和盒智科技 的技术与产品专家。大家将围绕模型、通讯、硬件解决方案和终端落地场景 的跨平台协同,交流真实的经验。

关于 Physical AI Camp·超音速计划 2026

本次 RTE Meetup 也是 RTE 开发者社区即将推出的 「Physical AI Camp·超音速计划 2026」 的预热前哨站。

我们即将开启一个为期 3 个月的创业营,招募正在 Voice Agent、Physical AI 和实时多模态 AI 领域探索的创业团队。营期内,我们将为入营项目提供技术资源支持、投融资对接,以及行业头部展会的展位资源。

如果你正在这个领域创业,欢迎带着你的项目或想法来到本次 Meetup 现场与我们交流对接。

RTE Meetup 议程

13:30~14:00 丨 签到与自由交流

Part 1:Voice Agent 演进:Go Visual, Go Physical & Go Everywhere

14:00~14:50

分享嘉宾:

  • xiaoan,Intent Company 创始人 ,近期开发的 VisionClaw 开源项目在 X 上获得近百万次浏览
  • 姚光华 (Colin),声网 AI 产品线负责人

Part 2:软硬结合与跨平台落地:AI Everywhere 的具体实践

  • 14:50~15:40 丨 圆桌讨论 & 现场所有人问所有人
  • 对谈嘉宾:

    姚光华 (Colin),声网 AI 产品线负责人

    王静茜,矽递科技 AI 应用平台产品线负责人

    张昊,盒智科技联合创始人&CTO,产品经理/全栈工程师/indie hacker

  • 嘉宾主持:

    • Neil,AI 眼镜产品经理

本次为闭门小规模讨论会,欢迎在圆桌环节分享你的问题和想法,所有人问所有人。

Part 3:15:40~16:00丨 Lightning Demo,带上你的软/硬件现场展示介绍

Part 4:16:00~16:30丨Physical AI Camp 招募咨询与自由社交

活动时间:

2026 年 3 月 7 日(周六) 13:30 - 16:30

活动地点:

北京市,望京 (报名审核通过后分享地址)

参与方式:

扫描海报二维码,或点击下方链接报名

https://www.rtecommunity.dev/t/t_a3AjCnV6RpwTFh

💡 我们也新开了一个「Physical AI+多模态」微信群,欢迎关注 AI 硬件、跨平台开发、语音交互、视觉理解等方向的伙伴申请加入!

加微信 Creators2022,备注身份和来意(公司/项目+职位/技术栈+加 Physical AI 群),备注完整者优先。

阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么

笔者最近在开发一个产业研究分析的 DeepResearch 智能体,正好看到最近 OpenBMB 开源社区刚刚发布了一款仅 4B 参数的智能体大模型 AgentCPM-Explore 和 8B 参数的 Deep Research 模型 AgentCPM-Report

今天就以这两个小参数开源模型为例,完整记录一下在 AI Max 395 上从模型部署到调用的全流程,也算是给大家提供一个本地算力有限的条件下实现联网搜索问答以及 Deep Research 两个业务场景本地实现的技术方案

AgentCPM-Explore

AgentCPM-Explore 的亮点包括:

  • 首个以 4B 全量参数登上 GAIA、HLE、BrowseComp 等 8 个长程复杂智能体任务榜单的端侧智能体模型。
  • 可实现超过 100 轮的连续环境交互,支持多源信息交叉验证、搜索策略动态调整、实时核验最新信息,持续深度探索直至任务完成。
  • 全流程开源,包括智能体全异步强化学习训练框架 AgentRL、工具沙盒统一管理调度平台 AgentDock、智能体工具学习能力一键测评平台 AgentToLeaP,支持社区共建与自定义扩展。
  • 在 Xbench-DeepResearch 上 AgentCPM-Explore 的表现超越了 OpenAI-o3,Claude-4.5-Sonnet 等闭源大模型,显著超越了不同量级 SOTA 模型的表现趋势线,展现出了更高的能力密度。

img

AgentCPM-Report

OpenBMB 开源社区发布了一款 8B 参数大小的 Deep Research 场景专业模型。实现了比肩顶级闭源系统的报告写作能力。 在 DeepResearch Bench、Deep Consult 以及 DeepResearch Gym 三大主流深度调研评测基准中,AgentCPM-Report 展现了惊人的越级战斗力,综合评分达到甚至超越顶级闭源系统。在最考验深度的洞察性指标上,AgentCPM-Report 力压群雄,排名第一;而在全面性指标上,也仅次于基于 Claude 的复杂写作框架,位居第一梯队。

img

AI Max+ 395

正好我手上最近刚刚入手了搭载了在 2025 年 CES 上 AMD 发布的最新的 AI Max+ 395(代号 Strix Halo)的旗舰级处理器的 mini 主机 GTR9 Pro。

AI Max+ 395是基于 RDNA 3.5 架构打造的 AMD Radeon 8060S 集成显卡。40 个计算单元,显存带宽高达 256GB/s,性能媲美移动版 RTX 4060 独显。

零刻 GTR9 Pro 搭载了频率高达 8000MT/s 的 128GB LPDDR5X 内存,以及出厂标配 2T 容量的固态硬盘。因为 AI Max+ 395 是统一内存架构(致敬 Apple 的 M 系列芯片?),可以在 BIOS 中将 128G 内存中的 96G 分配给显存。

这么大的显存无疑最适合用来本地跑 AI 项目,那么本篇教程就将向各位介绍如何使用 AI Max 395 在本地运行 AgentCPM + DeepResearch 智能体项目

img

img

安装驱动和 ROCm

如果你是刚刚拿到的新机,建议直接放弃 Windows 系统,改用 Ubuntu 系统。因为目前要运行一些 AI 组件依赖,还是 Linux 系统编译安装更为友好,如果实在需要 Windows 系统,那么也建议在 WSL 环境下部署 AI 项目。

首先第一步,我们需要去官网下载驱动:
https://www.amd.com/zh-cn/support/downloads/drivers.html/proc...

如图所示,官网目前提供 Win11,Win10 和 Ubuntu 三个系统版本:

img

我手上这台零刻 AI Max 395 从入手后就直接重置系统删除了自带的 Win11,改成 Ubuntu 24.04 了。因此本篇文章完全是基于 Ubuntu 24.04 来实现的。

根据 AMD 官网的介绍,在使用 Ubuntu 内核 6.12.0-1018 在 AMD Ryzen AI Max 395 系列处理器(gfx1151)上运行 LLM 推理工作负载时,可能会观察到间歇性应用程序崩溃或脚本失败,因此为了避免此类情况出现,我们第一步需要先升级 Linux 内核版本,直接在终端中输入升级命令:

sudo apt update && sudo apt install linux-image-6.14.0-1017-oem

安装完成后,重启系统并启动到 6.14 OEM 内核:

uname -r

然后开始更新系统:

sudo apt upgrade -y

接下来开始下载并安装 amdgpu-install 运行脚本:

sudo apt update
wget https://repo.radeon.com/amdgpu-install/7.1.1/ubuntu/noble/amdgpu-install_7.1.1.70101-1_all.deb
sudo apt install ./amdgpu-install_7.1.1.70101-1_all.deb

运行以下命令来安装 ROCm:

amdgpu-install -y --usecase=rocm --no-dkms

安装完成后设置权限组:

groups

使用下面命令将用户添加到渲染和视频权限组:

sudo usermod -a -G render,video $LOGNAME

添加完成后重启系统:

sudo reboot

重启之后,我们来验证是否安装成功:

groups

输出结果: magicyang adm cdrom sudo dip video plugdev users lpadmin docker render

执行命令验证:

rocminfo

img

类似 NVIDIA 的 nvidia-smi 命令,AMD 的 GPU 可以使用如下命令来监控显卡运行状态:

rocm-smi

img

显存扩容

AI Max 395 分配显存大小有 2 种方案,最简单的方式是通过开机 BIOS 分配显存大小。另外一种则是通过修改 GTT 内存池参数大小。首先来看第一种:

通过 BIOS 进行分配

对于支持该处理器的设备(如 Framework 或特定 AI 工作站),步骤如下:

  • 进入 BIOS:开机时反复按 F2Delete 键进入。
  • 进入高级菜单:使用方向键选择 AdvancedAMD CBS
  • 找到显存配置:路径通常为 iGPU Memory ConfigurationGFX Configuration -> UMA Frame buffer Size
  • 设置数值

    • 将配置模式设为 Custom(自定义)。
    • iGPU Memory Size 中选择所需的显存大小。AI Max+ 395 配合 128GB 内存时,BIOS 通常允许分配最高 96GB 作为固定显存。

通过修改内核参数进行分配

实际上 AMD APU 的 GPU 并没有“固定显存”(CPU + GPU + NPU 被封装在同一个 SOC 上),本质上用的是系统内存 (UMA) 。GPU 显存其实就是系统内存的一部分。因此只要有足够的系统内存(例如 128GB、192GB), 理论上就可以让 GPU 直接用到非常大的“显存”。

而 Linux 上的 AMD GPU 驱动支持 GTT(Graphics Translation Table)内存池,这个扩显存的操作其实就是在扩大 GTT 池,而不是 VRAM。GPU 通过 IOMMU /内存映射直接访问系统 RAM 就像把系统内存当作“显存”使用。

因此除了 BIOS 设置外,还可以通过修改内核参数(如 amdttm.pages_limit)来实现超过 96GB 的极端分配(如 100GB+),需要需要通过 GRUB 命令行工具(如 grubby)进行配置。

sudo nano /etc/default/grub

找到 GRUB_CMDLINE_LINUX_DEFAULT 这一行,改成:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ttm.pages_limit=27648000 ttm.page_pool_size=27648000 amdttm.pages_limit=27648000 amdttm.page_pool_size=27648000 apparmor=0  amd_iommu=off"

img

这里通过修改内核参数可分配的显存大小不要超过 108G,根据 Jeff Geerling 测试的结果,目前 Linux 内核对 AMD 的兼容性并没有特别好,目前分配大小建议按照 27648000 来设置即可,不宜放得过大。

修改完成后 Ctrl+O 保存,并重启系统:

sudo update-grub
sudo grub-install
sudo reboot

重启后先执行以下命令检查,确认是否生效:

cat /proc/cmdline

设置共享内存大小(可选)

ROCm 使用共享系统内存池,默认配置为系统内存的一半。可以通过更改内核的转换表管理器(TTM)页面设置来增加此数量

安装 pipx

sudo apt install pipx

pipx 安装的 wheels 路径添加到系统搜索路径中:

pipx ensurepath

从 PyPi 安装 amd-debug-tools

pipx install amd-debug-tools

运行 amd-ttm 工具查询当前共享内存设置:

amd-ttm

img

使用 --set 参数重新配置共享内存设置(单位为 GB):

amd-ttm --set 16
注意:这里要共享的内存需要根据你分配给显存之后剩余的内存大小来设置。

重启系统以使更改生效:

sudo reboot

部署 GPUStack

GPUStack 是一个开源的 GPU 集群管理器,专为高效的 AI 模型部署而设计。它通过选择最佳推理引擎、调度 GPU 资源、分析模型架构以及自动配置部署参数,能够在自己的 GPU 硬件上高效运行大模型。

img

GPUStack 内置支持的后端推理引擎包括:

  • vLLM
  • SGLang
  • MindIE
  • VoxBox

并且可以通过添加自定义推理引擎的方式增加对 llama.cpp 的支持。

安装 Toolkit 和 Docker

  1. 在安装之前需要确保至少配备一个 AMD AI Max 395 GPU 节点。
  2. 确保工作节点上安装了 ROCm 驱动程序、Docker 和 AMD Container Toolkit 容器工具。

其中 Docker 版本 ≥ 28.3.0,Docker 的安装方法,请自行查阅教程,这里只给出 AMD Container Toolkit 的安装教程。

首先更新系统:

sudo apt update

添加当前用户到所需的 GPU 设备访问组:

sudo usermod -a -G render,video $LOGNAME

安装所需依赖项:

sudo apt update
sudo apt install vim wget nano gpg

创建密钥目录:

sudo mkdir --parents --mode=0755 /etc/apt/keyrings

安装 GPG 密钥和仓库链接:

wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | gpg --dearmor | sudo tee /etc/apt/keyrings/rocm.gpg > /dev/null

添加 AMD Container Toolkit 仓库:

  • Ubuntu 22.04:
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/amd-container-toolkit/apt/ jammy main" | sudo tee /etc/apt/sources.list.d/amd-container-toolkit.list
  • Ubuntu 24.04:
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/amd-container-toolkit/apt/ noble main" | sudo tee /etc/apt/sources.list.d/amd-container-toolkit.list

更新软件包索引并安装工具包:

sudo apt update

安装 Toolkit:

sudo apt install amd-container-toolkit

注册 AMD 容器运行时并重启 Docker 守护进程:

sudo amd-ctk runtime configure
sudo systemctl restart docker

安装 GPUStack

使用 Docker 安装并启动 GPUStack Server 的命令如下:

sudo docker run -d --name gpustack \
    --restart unless-stopped \
    -p 80:80 \
    --volume gpustack-data:/var/lib/gpustack \
    gpustack/gpustack
注意:如果你想把 GPUStack 部署到其他端口(默认为 80 端口)可以修改为 xx:80,xx 即为你想部署的端口号

检查 GPUStack 启动日志:

sudo docker logs -f gpustack

GPUStack 启动后,运行以下命令获取默认管理员密码:

sudo docker exec gpustack cat /var/lib/gpustack/initial_admin_password

在浏览器中打开 http://your_host_ip 访问 GPUStack UI。使用默认用户名 admin 和上面获取的密码登录,登录完成后需要修改登录密码。

img

登录后还需要添加集群和节点信息,在集群管理页面点击集群,选择添加集群。自建环境选择 Docker:

img

基本配置页面填写一个集群名称,然后保存:

img

在添加节点页面的 GPU 厂商中选择 AMD,然后点击下一步:

img

在这个页面会给出一个环境检查的命令,这里主要是需要检查前面已经安装好的 ROCm 驱动和 Docker 还有 AMD Container Toolkit:

img

在终端中输入提示中的命令:

amd-smi static >/dev/null 2>&1 && echo "AMD driver OK" || (echo "AMD driver issue"; exit 1) && sudo docker info 2>/dev/null | grep -q "amd" && echo "AMD Container Toolkit OK" || (echo "AMD Container Toolkit not configured"; exit 1)

正常情况会输出两个 OK,如果没有,请检查 ROCm,Docker 和 amd-container-toolkit 是否成功安装。

img

然后在节点 IP 中输入本机的局域网 IP 地址:

img

然后点击完成。会出现添加节点的命令:

img

复制该命令,在终端中运行,后台会自动拉取 Docker 镜像,启动一个名为 gpustack-worker 的容器。

如果容器启动成功没有报错,回到资源下的 GPUs 页面,就可以看到 AI Max 395 被 GPUStack 成功识别了。

img

部署 AgentCMP-Explore 模型 API 服务

GPU 被成功识别之后,点击模型下面的部署,点击部署模型:

img

在部署模型下拉选框中选择 ModelScope:

img

在搜索框中输入 AgentCPM,选择第一个 AgentCPM-Explore:

img

在右侧弹出的配置信息中后端选择 vLLM,版本选择 0.13.0:

img

然后在高级中,添加两个参数:

img

其中:

--gpu-memory-utilization=0.6 是分配给 AgentCPM-Explore 这个模型 60% 显存资源,大概为60G。

--max-model-len=262144 是设置的模型最大上下文长度,我这里设置了 256k 的最大上下文,如果你不需要这么大的上下文,可以调整这个大小,这样可以显著节省显存开销。

设置完成后点击保存,后台会自动从 ModelScope 拉取模型权重,并且拉取 vLLM 的镜像,用于启动模型。这个过程会比较漫长,需要静静等待,启动时可以打开查看日志按钮来查看启动情况:

img

当日志出现如下接口信息时,代表模型已经启动成功了:

img

当模型完全启动成功之后显示 Running 时,代表模型 API 服务启动成功了!

img

那我们要如何获取接入 AgentCPM 的 API Key ,URL 和模型名称等信息呢?点击右侧的三个点会出现 API 接入信息:

img

在这里会显示接入模型 API 需要填写的参数信息,包括 URL 地址,模型名称:

img

最后我们还需要创建一个 API Key 进行认证,以防止别人盗用模型接口,按照提示点击去创建:

img

然后在 API 密钥添加页面添加一个 API Key 即可:

img

这样我们的模型部署就全部完成了。

使用 AgentCPM-Explore 进行联网搜索任务

在 Cherry Studio 客户端中,在模型服务中找到 GPUStack,然后将刚刚部署好的模型接口信息填入。

img

添加完成之后可以点击检测,如果通过会显示一个✅,这就代表模型接入成功了。

然后回到助手页面,就可以实现问答了:

img

我这里之前有配置了一个投资分析助手的提示词,通过 Cherry Studio 的 Google 搜索插件,就可以实现用 AgentCPM-Explore 结合 Google 搜索,完成类似 DeepResearch 的联网搜索问答任务。

这里只是测试了 Agent 调用搜索引擎的能力,如果要实现完整的 DeepResearch 功能,建议使用 AgentCPM-Report 通过接入开源的 Deep Research 框架项目即可。

从测试的 case 可以看到 AI Max 395 的 AgentCPM-Explore 吞吐速度为首 token prefill 867ms,生成速度大概为 18 tks/s,这个速度对于单用户本群请求完全够用了,以上就是全部内容了。

使用 AgentCPM-Report 进行 DeepResearch 任务

AgentCPM-Report 核心亮点

  • 极致效能,以小博大:通过平均 40 轮的深度检索与近 100 轮的思维链推演,实现对信息的全方位挖掘与重组,让端侧模型也能产出逻辑严密、洞察深刻的万字长文,在深度调研任务上以 8B 参数规模达成与顶级闭源系统的性能对标
  • 物理隔绝,本地安全:专为高隐私场景设计,支持完全离线的本地化敏捷部署,彻底杜绝云端泄密风险。基于我们的 UltraRAG 框架,它能高效挂载并理解本地私有知识库,让核心机密数据在“不出域”的前提下,安全地转化为极具价值的专业决策报告。

接下来我们先在 AI Max 395 上实现用 llama.cpp 来部署 AgentCPM-Report 模型服务。

部署 AgentCPM-Report 模型 API 服务

目前 OpenBMB 开源了 2 个格式的 AgentCPM-Report 模型,一个是标准的 safetensors 格式模型,推理框架可以选择使用 vLLM 进行推理,部署方式和上文中的 AgentCPM-Explore 模型相同,这里不再重复。

另外一个则是 GGUF 格式的模型,这种格式适合在 GPU 资源受限的情况下,使用 CPU+GPU 一起进行推理,特别适合类似 AI Max 395 这种统一内存架构的核显 mini 主机设备。

和 AgentCPM-Explore 部署方式类似,我们仍然选择使用 GPUStack 来完成 AgentCPM-Report 模型服务的部署,和前面的差别是 GGUF 格式需要使用 llama.cpp 的后端推理框架。

因为目前最新的 2.0.3 版本的 GPUStack 已经不再默认内置 llama.cpp,因此我们需要通过配置自定义后端推理框架的方式来实现 llama.cpp 后端的支持。

添加和使用推理后端的操作步骤如下:

如下图所示在推理后端页面,选择添加后端:

img

在添加后端页面选择 YAML 模式。示例:

img

使用如下 YAML 配置文件信息替换为如下代码:

backend_name: llama.cpp-custom
version_configs:
  v1:
    image_name: ghcr.io/ggml-org/llama.cpp:server-vulkan
    run_command: null
    entrypoint: null
    custom_framework: rocm
default_version: v1
default_backend_param: []
default_run_command: '-m {{model_path}} --host 0.0.0.0 --port {{port}}'
default_entrypoint: ''
is_built_in: false
description: null
health_check_path: null
built_in_version_configs: {}
framework_index_map:
  rocm:
    - v1

然后保存,接着在部署页面输入 agentcpm-report,找到 GGUF 格式的模型,然后在后端中选择用户定义分类下的 llama.cpp ,然后部署。

img

然后在高级中配置环境变量与命令行启动参数,详细的环境变量与命令行参数信息可以参考下表:

核心环境变量一览表

环境变量对应参数默认值描述
LLAMA_ARG_THREADS-t, --threads-1生成线程数
LLAMA_ARG_CTX_SIZE-c, --ctx-size4096上下文大小
LLAMA_ARG_N_PREDICT-n, --n-predict-1预测token数
LLAMA_ARG_N_GPU_LAYERS-ngl, --n-gpu-layers0GPU层数
LLAMA_ARG_MODEL-m, --model-模型路径
HF_TOKEN-hft, --hf-token-HuggingFace令牌

配置参数系统化分类

性能调优参数

# CPU配置
LLAMA_ARG_THREADS=8        # 使用 8 个线程
LLAMA_ARG_THREADS_BATCH=4  # 批处理线程数

# 内存管理
LLAMA_ARG_MLOCK=1          # 锁定模型在内存中
LLAMA_ARG_NO_MMAP=0        # 启用内存映射

# GPU卸载
LLAMA_ARG_N_GPU_LAYERS=24  # 24 层卸载到 GPU
LLAMA_ARG_SPLIT_MODE=layer # 分层拆分模式

模型加载参数

# 本地模型加载
LLAMA_ARG_MODEL="/path/to/model.gguf"

# 远程模型下载
LLAMA_ARG_HF_REPO="ggml-org/gemma-3-1b-it-GGUF"
HF_TOKEN="your_hf_token_here"

# 多模态支持
LLAMA_ARG_MMPROJ="/path/to/mmproj.bin"

生成控制参数

# 上下文管理
LLAMA_ARG_CTX_SIZE=8192    # 8K 上下文
LLAMA_ARG_KEEP=512         # 保留 512 个初始 token

# 生成限制
LLAMA_ARG_N_PREDICT=256    # 最大生成 256 token
LLAMA_ARG_TEMP=0.7         # 温度 0.7

# 重复控制
LLAMA_ARG_REPEAT_PENALTY=1.1
LLAMA_ARG_REPEAT_LAST_N=64

介绍完以上参数含义后,根据 AI Max 395 的性能,这里推荐的环境变量参数为:

LLAMA_ARG_THREADS=16
LLAMA_ARG_CTX_SIZE=65536
LLAMA_ARG_N_PREDICT=512
LLAMA_ARG_TEMP=0.1
LLAMA_ARG_MLOCK=1

在 GPUStack 中环境变量和命令行启动参数配置方法,如下图所示:

img

需要注意的是 --ctx-size 65536 这个参数我设置为 64K,也是 AgentCPM-Report 支持的最大上下文长度,实际的参数可以根据你的实际需要来灵活调整。保存完成后,模型后台会自动下载模型文件并启动 API 服务,当出现绿色 Running 图标时,则代表模型启动成功了。

img

部署完成后,就可以将 agentcpm-report 接入到任意的 Deep Research 框架下了。以下为我接入 Dify 构建的 Deep Research 框架测试的效果,后续大家觉得有必要的话欢迎留言,我会更新接入 mirothinker 的效果测试:

img

img

img

加入 GPUStack 社区

GPUStack 社区是一个围绕 AI 基础设施与大模型推理实践展开的技术交流空间。

在这里,你可以看到真实环境下的 AI Infra 与大模型推理的部署经验、问题排查过程,以及围绕推理引擎、算力管理和系统架构的持续讨论。

无论你正处于模型基础设施的评估、试用还是规模化部署阶段,都可以在社区中找到有参考价值的信息。

欢迎扫码加入 GPUStack 社区,与更多关注 AI Infra 与大模型推理实践的伙伴一起交流、学习与分享

社区群二维码

若群聊已满或二维码失效,请访问以下页面查看最新群二维码:
https://github.com/gpustack/gpustack/blob/main/docs/assets/wechat-group-qrcode.jpg

各位感兴趣可以给点意见,目前支持基本功能(网格模式,详情,递归等。并不兼容标准的 ls 参数)。

本工具基于 zig 0.16dev 构建。

仓库地址: https://github.com/here-Leslie-Lau/zlist

预览:

Preview1

Preview2

如果图片出不来,可以点进 github 内查看

我观察到这门语言热度还是不及其他语言,可能是还没有出 1.0 的原因。导致每次小版本升级,项目或工具大概率编译失败,需要自行翻标准库文档来修复。不过有时折腾的乐趣也是如此(自我安慰)

开发者朋友们大家好:

这里是 「RTE 开发者日报」,每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE(Real-Time Engagement) 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」,但内容仅代表编辑的个人观点,欢迎大家留言、跟帖、讨论。

本期编辑:@koki、@瓒an、@鲍勃

01 有话题的技术

1、德国电信联合 ElevenLabs 推出首个运营商级别语音助手,支持实时翻译和 AI 助手

在巴塞罗那 MWC 大会,Deutsche Telekom 基于 ElevenLabs 的 ElevenAgents 平台发布 Magenta AI 呼叫助手,将 AI 语音代理直接嵌入运营商网络基础设施,实现任意通话的实时智能化。

该语音助手,是全球首款将实时 AI 功能(包括实时翻译和管理支持)引入日常通话的解决方案,可在任何设备上使用,无需额外应用程序。

用户只需在通话中说「嘿,Magenta」,即可激活由 ElevenLabs 提供的专用 AI 助手。所有参与者都会在助手启动时立即收到通知,AI 处理仅在明确激活后才会开始。

该助手实时运行,旨在消除语言障碍,并通过以下方式使对话更高效、更易于理解:

  • 实时翻译:参与者可以用自己的母语进行发言和聆听,实现无缝、低延迟的翻译。
  • 智能助手:集成的 AI 助手可以在通话期间回答问题并采取行动,包括推荐附近的餐厅、比较旅行方案、检查预约可用性以及完成预订。
  • 智能摘要:自动捕捉关键信息、预约和待办事项。通话结束后,助手会立即提供简洁明了的摘要,确保不会遗漏任何细节,从会议时间到具体地址,无一遗漏。

通过将这些功能嵌入到常规通话中,ElevenLabs 和德国电信正在消除语言障碍,让所有网络用户都能更轻松地使用人工智能。

Magenta AI 通话助手将于今年晚些时候在德国面向德国电信用户推出,并计划在未来 12 个月内支持多达 50 种语言。

( @elevenlabsio\@X)

2、Qwen 3.5 小模型系列全面上线,最小 0.8B 可端侧部署

Ollama 现已支持 Qwen 3.5 系列小模型(0.8B/2B/4B/9B),所有模型均原生支持工具调用、思维推理和多模态能力,可直接通过 ollama run 命令使用。

这批小尺寸模型性能更强,算力更省,同样基于 Qwen3.5 架构打造——原生多模态、架构深度优化,并经过了大规模强化学习的打磨:

• 0.8B / 2B 版本: 极致轻巧,响应极快,非常适合跑在端侧设备上。

• 4B 版本: 综合实力强悍的多模态基座,是开发轻量级智能体的理想选择。

• 9B 版本: 虽是紧凑型身材,但在性能上已经在追赶那些体量大得多的模型了。

与此同时,基座版本也会同步发布。

HuggingFace:
https://huggingface.co/collections/Qwen/qwen35

( @Alibaba\_Qwen\@X)

3、编程进入「对讲机」时代!Claude 抢发语音写代码,转录 Token 全免费

Claude Code 正式上线语音模式:输入 /voice,长按空格说话,松开即完成输入。语音转录实时流入光标位置,和键盘无缝切换,转录 Token 完全免费。编程的下一个战场不是模型智商,而是交互方式。

跟对讲机一模一样。

目前灰度测试阶段,大约 5%的用户先尝鲜,接下来几周逐步放开。如果账户有权限,打开 Claude Code 时欢迎界面会提示你。

这种语音模式不是简单的语音转文字。语音转出来的文字,会直接在光标位置实时流式输出。

类似下面网友分享的这样:

也就是说,用户可以先手打一半提示词,遇到复杂逻辑懒得打字了,长按空格切到语音,语音输入那段难以描述的逻辑,松手,再继续打字。

无缝衔接。不覆盖。不替换。

这才是关键——它不是替代键盘,是补充键盘。

与此同时,还有一个大利好:语音转录的 Token 完全免费。 不计费。不扣额度。想说多少说多少。

有意思的是,OpenAI 的 Codex 几乎在同一时间也加了类似功能。Codex 0.105.0 版本更新日志写得明明白白——按住空格录音,松开转录,文字直接输入到终端界面。

用的是 Wispr 语音引擎,目前支持 macOS 和 Windows,尚不支持 Linux,并且该功能需要手动开启:在配置文件里设置 features.voice\_transcription=true。

两家几乎同时出招。这不是巧合,是共识。

编程工具的下一个战场,不在模型有多聪明,而在交互有多自然。

(@新智元)

02 有亮点的产品

1、高通推出可穿戴设备新芯片,支持 Linux 系统,适合 AI PIN、AI 眼镜等

今天,高通公司在西班牙举行的 MWC 上发布了新款骁龙 Wear Elite 芯片。

在新闻发布会上,高通表示,他们将 Elite 芯片定位为「腕戴增强版」芯片。它并不会取代之前的 W5 Plus,而是与之并存。该公司表示,预计 Elite 芯片将吸引那些希望打造 AI 可穿戴设备(例如吊坠、胸针以及可能无需显示屏的智能眼镜)的厂商。

除了升级到 3nm 工艺外,Elite 芯片还配备了 eNPU 和 Hexagon NPU 用于 AI 处理。前者负责处理低功耗 AI 功能,例如关键词识别和活动检测,而后者则可以处理计算密集型任务。高通表示,Hexagon NPU 可以在设备端处理 20 亿个参数,每秒可处理多达 10 tokens。

虽然 Wear Elite 的协处理器架构与 W5 Plus 类似,但高通表示其能效更高,因此主芯片可以处理更多功能。例如,GPS 定位所需的功耗降低了 40%。电池方面,Elite 支持 9V 快充,这意味着大约 10 分钟即可充电至 50%。高通还预计其整体电池续航时间可延长 30%。

Elite 还新增了对卫星连接、5G、超宽带和蓝牙 6.0 的支持。CPU 性能提升了约五倍,GPU 现在支持 1080p 分辨率、60fps 的动画播放。

除了 Android 和 Wear OS 系统外,Elite 还将支持 Linux 系统,以便更好地支持那些希望使用专有软件开发 AI 徽章或吊坠的初创公司。

骁龙 Wear Elite 是首个同时集成六种连接技术的可穿戴平台,高通称之为「六重连接」。以下是它所包含的功能:

  • 5G RedCap 为您的可穿戴设备提供独立的蜂窝网络连接,无需像完整的 5G 调制解调器那样消耗大量电量。
  • 低功耗 Wi-Fi (802.11ax / Wi-Fi 6) 让您能够以最小的电池消耗连接到本地网络和云端 AI 服务。
  • 蓝牙 6.0 可实现更精准的设备查找,并与您的生态系统无缝配对。
  • UWB (超宽带)可处理安全的近距离交互,例如数字车钥匙和智能家居门禁。
  • GNSS 可在多个卫星星座中提供精准的定位追踪。
  • 而 NB-NTN (窄带非地面网络)则意味着,即使您身处没有电网覆盖的区域,您的手表也能与 Skylo 合作收发卫星消息。

其中本次新增的卫星通讯功能,对于徒步旅行者、旅行者以及任何需要前往手机信号覆盖范围之外的人来说非常有需求。高通公司表示,「首批搭载骁龙 Wear Elite 处理器的商用设备预计将在未来几个月内上市」

( @AI vision)

2、追觅生态链入局教育硬件:耀墨科技发布「问方」及「AI 闹钟」系列

一家名为耀墨科技(苏州)有限公司(下称「耀墨科技」)的企业在近日推出两款儿童硬件产品——口袋机类型的儿童智能学伴\&AI 闹钟。两款产品的释出海报中,机身都印有追觅 DREAME 的 logo。

2026 年 2 月春节期间,YOOMO 小红书账号的春节倒计时海报中露出了「追觅问方 X1」和「追觅 AI 闹钟 S20」两款产品。据其官方账号中的信息,问方 X1 是一款面向青少年的便携口袋机产品,AI 闹钟 S20 则主要提供智能时间管理,AI 辅助学习等功能和课内外资源,比如科学时间规划和智能唤醒;AI 口语练习;官方小初中教材解读;熏听资源等等。

区别于传统的查题机,YOOMO 的产品逻辑侧重于 SLM(小型语言模型)的端云协同应用与多模态感知:

  • 启发式交互逻辑(Non-Direct Answer): 问方 X1 内置「启发性 AI」,算法层过滤直接答案输出,转而采用多角色 AI 主动提问引导。其技术核心在于 Prompt Engineering 的约束,旨在培养独立解题能力而非单纯的检索。
  • SEL 智能情感系统: 系统集成了社交情感学习(Social Emotional Learning)管家,通过多模态输入识别用户情绪,并提供针对性的引导策略,强化 AI 交互中的情感反馈质量。
  • 边缘侧环境感知预警: 利用后置摄像头与视觉算法,问方 X1 支持实时危险场景识别(如水域、高处边缘),在边缘侧完成图像推理并触发安全预警。
  • 桌面端资源聚合: S20 侧重于时间管理与语音交互,支持教材解读、口语练习及科学唤醒算法,本质上是将传统的智能音箱功能垂直化为「AI 助学终端」

功能上,问方 X1 和市面上同类青少年便携机型相近,覆盖百科对话、陪伴互动、健康提醒、成长管家、安全定位等等,其中:问方 X1 内置了 SEL 成长管家,搭载智能情感系统,在理解和读懂孩子情绪的同时,引导和培养孩子孩子倾听、表达等能力。问方 X1 强调「智能启发学习」,其官方强调「并不是直接给答案,而是通过多 AI 角色主动提问+引导」。其内置启发性 AI,用以引导孩子主动思考,培养独立解决问题的能力。

在安全方面,问方 X1 实时识别水域、高处等场景并发出预警,另有 4G 通话和全天定位功能。

目前官方暂未发布定价等信息,也未在官方及三方电商平台上线。

(@多知)

3、GEO 服务商「PureblueAI 清蓝」完成数千万元天使轮融资,发布新 AI 营销数字员工平台

北京清蓝智汇科技有限公司(简称 PureblueAI 清蓝)正式宣布完成数千万元人民币天使轮融资。本轮融资由祥峰中国(Vertex China)领投,老股东英诺基金及一村淞灵、36 氪跟投。

在这轮融资发布之际,PureblueAI 清蓝也同步发布了新产品—— AI 营销数字员工平台 mkter.ai,以及 AI 口碑营销数字员工「Mark」。

不同于行业内传统功能型 SaaS 工具,Mark 能够提供从用户意图挖掘到效果监控优化的 AI 口碑营销全流程,覆盖诊断、执行到复盘优化的环节。

Mark 能够覆盖的范围也很广,比如可适配中小企业自运营、大型企业定制化服务、营销服务商代理合作等多元需求。同时,Mark 兼容豆包、DeepSeek、千问、元宝等主流 AI 平台。

具体来说,Mark 可提供六大核心能力服务,实现 AI 口碑营销全流程智能化闭环管理:通过专业意图挖掘锁定高转化用户需求;根据多维品牌诊断输出全维度优化方案;一键专属知识库搭建帮助生成高可信内容;精准效果预估提前锁定投放价值;全域智能发布匹配高权重可信信源;实时效果监控实现 7×24 小时动态监测分析等等。

无论是 AI 营销数字员工平台 mkter.ai,还是 AI 口碑营销数字员工「Mark」,背后都是基于清蓝自研的混合模型架构与优化算法,通过先进的生成引擎优化技术,助力企业提升品牌的 AI 推荐率和影响力。

这系列能力,会让 Agent 去学习 AI 平台的推荐规律,替代过往的人工去「猜测」平台投放测录的过程

在过程中,PureblueAI 的系统将持续分析那些在 AI 搜索中被成功推荐的内容,让模型找出这些内容背后共有的「特征因子」,让模型知道什么样的内容结构和特征,能拿到 AI 平台更高的采信权重,用以指导企业客户的内容生成策略、监测模型反馈等等。

比如,当客户提出优化需求(如优化「超混架构车型推荐」这个搜索意图)时,清蓝的模型不仅会生成一篇营销稿件,还会计算出权重最高的发布平台组合。

(@智能涌现)

03 有态度的观点

1、Bill Gurley:不热爱工作的人最容易被 AI 取代

据《商业内幕》报道,知名风险投资人 Bill Gurley 近日在播客节目「On with Kara Swisher」中表示,在今年快速演进的 AI 浪潮下,那些对工作缺乏热情、缺乏明确目标、长期「机械式」履行职责的从业者,将最容易被 AI 取代。

Gurley 指出,许多年轻人沿着「大学 — 稳定工作」的路径前进,最终进入自己并不热爱的行业,成为「流水线上的齿轮」。

在他看来,这类岗位最容易被 AI 重塑,因为从业者缺乏内在驱动力,也缺乏持续提升技能的动力。他认为,AI 的发展已经促使多家大型科技公司放缓招聘或提前裁员,以应对未来更高效的数字劳动力

他引用巴菲特「每天都在跳着踢踏舞去上班」的说法,指出当一个人真正喜欢自己的工作时,「精进是免费的」,因为学习与提升会自然发生。

他进一步表示,AI 对职场人的意义类似「喷气燃料」,能显著放大个人能力。

员工若能成为团队中「最懂 AI 的那个人」,不仅能更快学习,也能在组织中获得更高的不可替代性。

如果你能把 AI 用好,你会成为他们最不想裁掉的人。

(@APPSO)

04 社区黑板报

招聘、项目分享、求助……任何你想和社区分享的信息,请联系我们投稿。(加微信 creators2022,备注「社区黑板报」)

1、活动推荐:3 月 7 日深圳 Data for AI Meetup ,5 位开源专家聊 AI 数据基础设施实战

本次 Meetup 围绕 AI 时代的数据基础设施,从不同视角展开:

  • 数据湖元数据与治理如何支撑 AI 场景
  • 多模态数据湖在真实业务中的架构实践
  • 云原生数据平台的设计演进
  • 半结构化数据与 No-ETL 实时分析解法
  • 开源、AI 和 Data 技术社区生态的趋势和共建

分享嘉宾来自腾讯、OPPO、Datastrato、ScopeDB 等团队,以及 Apache 软件基金会、LF APAC AI & Data 和开源社等知名社区。既有大规模业务实践,也有开源基础设施经验,将从不同角度呈现 AI 数据层的真实挑战与解决思路。

📅 时间:2026 年 3 月 7 日(周六)下午 13:00-17:30

📍 地点:深圳·深国际华南数字谷 H 栋 4 楼

🎟 报名:免费参加,需通过审核(请完整填写报名信息)

报名链接

https://www.huodongxing.com/event/4850156431800

阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么

写在最后:

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创,感兴趣的朋友请通过开发者社区或公众号留言联系,记得报暗号「共创」。

对于任何反馈(包括但不限于内容上、形式上)我们不胜感激、并有小惊喜回馈,例如你希望从日报中看到哪些内容;自己推荐的信源、项目、话题、活动等;或者列举几个你喜欢看、平时常看的内容渠道;内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点,仅供参考

带 AFF 链接,楼下互助下,大家一起薅羊毛。
备:
- 300 代金券需要创建 apikey 调用后,人工审核
- 邀请后下家实名后,我有 200 代金券
- 有多个手机号,自己邀请自己,小号也可以一次,试过第三个手机号实名没有了,这个不知道是 bug 还是 feat

邀请链接:
https://ai.baishan.com/auth/login?referralCode=xe7ByN7Hx3





在跨境电商、社媒矩阵营销、自动化采集等场景中,动态代理已经成为必不可少的工具。很多用户在选择代理服务的时候,总会面临一个问题:

动态代理是否真正稳定?在多账号运营或长时间运行时,会不会频繁掉线会被识别为异常?

本文IPDEEP小编将为大家详细分析下,希望对大家有帮助。
动态代理也能稳定?多账号运营的最佳选择

一、动态代理的核心痛点

动态代理的最大优势是 IP会自动轮换,可以规避封禁和风控限制。然而,这也带来了几个用户最关心的问题:

1.会话长度短

动态IP如果频繁更换,后台登录或自动化程序可能中断,导致任务失败或账号异常。

2.切换机制不智能

低质量代理服务切换IP过快或过慢,容易被目标网站识别异常访问。

3.高峰期稳定性差

当业务并发量高时,如果代理服务器无法承载,成功率下降,影响采集和运营效率。

如果这些问题处置不当,会直接影响电商店铺、社媒账号的安全和业务效率。

二、多账号运营的挑战与解决方案

在多账号运营中,无论是电商还是社媒矩阵,用户常遇到以下问题:

同时登录多个账号时,IP重复导致账号被限制

不同业务场景需要不同类型的IP(如动态住宅、静态住宅或移动IP)

解决方案:

1.选择支持多类型IP的服务

根据任务类型选择不同IP类型,灵活调度

2.长会话支持

对于后台操作或自动化任务,长会话IP能减少异常。

3.智能轮换机制

系统会自动切换IP,保证成功率并降低识别风险。

三、稳定性如何衡量

选择动态代理时,用户可以通过以下几个指标判断稳定性:

IP粘性/会话长度:是否支持长时间会话,减少频繁切换带来的风险。

成功率与高峰表现:在大量访问或自动化采集任务中,是否能维持高成功率。

资源类型与纯净度:是否为真实住宅IP,减少账号被识别异常的概率。

四、动态代理适用的场景

五、如何选择可靠的动态代理服务

选择动态代理服务时,可以从以下角度评估:

1.资源纯净度:是否提供高比例的真实住宅IP。

2.会话稳定性:是否支持长会话和自动轮换。

3.技术支持与稳定:是否提供详细文档和及时响应的技术支持。

4.套餐灵活性:是否支持按需购买和不同类型IP自由组合。

六、总结

动态代理并非天生不稳定。选择合适的服务提供商,注重会话长度、智能轮换、高纯度资源,可以让动态代理在多账号运营中表现得既稳定又高效。

对于跨境电商、社媒矩阵运营或自动化采集团队来说,稳定的动态代理不仅是业务安全保障,也是提高效率的关键工具。

简介:整数在内存中的存储;大小端字节序和字节序判断;浮点数在内存中的存储

1 整数在内存中的存储(回顾)

整数的2进制表示方法有三种,即原码、反码和补码

有符号的整数,三种表示方法均有符号位和数值位两部分。符号位都是用0表示“正”,用1表

示"负",最高位的一位是被当做符号位,剩余的都是数值位。

正整数的原、反、补码都相同。

负整数的三种表示方法各不相同。

原码:直接将数值按照正负数的形式翻译成二进制得到的就是原码。

反码:将原码的符号位不变,其他位依次按位取反就可以得到反码。

补码:反码+1就得到补码。

对于整形来说:数据存放内存中其实存放的是二进制的补码。

为什么?

在计算机系统中,数值一律用补码来表示和存储。

原因在于,使用补码,可以将符号位和数值域统一处理;

同时,加法和减法也可以统一处理(CPU只有加法器)此外,补码与原码相互转换,其运算过程是相同的,不需要额外的硬件电路。

为什么char范围是127 ~ -128

10000000时,直接认为其等于-128

2 大小端字节序和字节序判断

2.1 什么是大小端?

当超过一个字节的数据在内存中存储的时候,就有存储顺序的问题,按照不同的存储顺序,我们分

为大端字节序存储和小端字节序存储,下面是具体的概念:

大端(存储)模式:是指数据的低位字节内容保存在内存的高地址处,而数据的高位字节内容,保存在内存的低地址处。

小端(存储)模式:是指数据的低位字节内容保存在内存的低地址处,而数据的高位字节内容,保存在内存的高地址处。

举个例子:

a = 0x223344550x表示这是一个16进制数。数据的低位字节内容55保存在内存的低地址处,而数据的高位字节内容22保存在内存的高地址处,所以这个环境下是小端(存储)模式。

2.2 为什么有大小端?

这是因为在计算机系统中,我们是以字节为单位的,每个地址单元都对应着一个字节,一个字节为8 bit位,但是在C语言中除了8 bit的char之外,还有16 bit的short型,32 bit的long型(要看具体的编译器),另外,对于位数大于8位的处理器,例如16位或者32位的处理器,由于寄存器宽度大于一个字节,那么必然存在着一个如何将多个字节安排的问题。因此就导致了大端存储模式和小端存储模式。

我们常用的X86结构是小端模式,而KEIL C51则为大端模式。很多的ARM, DSP都为小端模式。有些ARM处理器还可以由硬件来选择是大端模式还是小端模式。

2.3 字节序判断

int check_sys()
{
    int a = 1;
    //00000000 00000000 00000000 00000001(2进制)
    //00 00 00 01 - 大端存储(16进制)
    //01 00 00 00 - 小端存储(16进制)
    return *(char*)&a;
}

int main()
{
    int ret = check_sys();
    if(ret == 1)
    {
        printf("小端\n");
    }
    else
    {
        printf("大端\n");
    }
    return 0;
}

3 浮点数在内存中的存储

3.1 浮点数的存储规定

根据国际标准IEEE(电气和电子工程协会)754,任意一个二进制浮点数V可以表示成下面的形式:

举例来说:

十进制的5.0,写成二进制是101.0,相当于1.01 * 2^2

可以得出S=0,M=1.01,E=2。

IEEE 754规定:

对于32位的浮点数(float),最高的1位存储符号位S,接着的8位存储指数E,剩下的23位存储有效数字M;对于64位的浮点数(double),最高的1位存储符号位S,接着的11位存储指数E,剩下的52位存储有效数字M。

3.2 浮点数存的过程

IEEE 754对有效数字M和指数E,还有一些特别规定。

前面说过,1<M<2,也就是说,M可以写成1. xxxxxx的形式,其中xxxxxx表示小数部分。

IEEE 754规定,在计算机内部保存M时,默认这个数的第一位总是1,因此可以被舍去,只保存后面的xxxxxx部分。比如保存1.01的时候,只保存01,等到读取的时候,再把第一位的1加上去。这样做的目的,是节省1位有效数字。以32位浮点数为例,留给M只有23位,将第一位的1舍去以后,等于可以保存24位有效数字。

至于指数E,情况就比较复杂

首先,E为一个无符号整数(unsigned int

这意味着,如果E为8位,它的取值范围为0~255;如果E为11位,它的取值范围为0~2047。但是,我们知道,科学计数法中的E是可以出现负数的,所以IEEE 754规定,存入内存时E的真实值必须再加上一个中间数,对于8位的E,这个中间数是127;对于11位的E,这个中间数是1023。比如,2^10的E是10,所以保存成32位浮点数时,必须保存成10+127=137, 即10001001。

3.3 浮点数取的过程

E不全为0或不全为1(常规情况)

这时,浮点数就采用下面的规则表示,即指数E的计算值减去127(或1023),得到真实值,再将有效数字M前加上第一位的1。

比如:0.5的二进制形式为0.1,由于规定正数部分必须为1,即将小数点右移1位,则为1.0*2 ^(-1),其阶码为-1+127(中间值)=126,表示为01111110,而尾数1.0去掉整数部分为0,补齐0到23位00000000000000000000000,则其二进制表示形式为:

0 01111110 00000000000000000000000

E全为0

这时,浮点数的指数E 直接 等于1-127(或1-1023)即为真实值,有效数字M不再加上第一位的1,而是还原为0.xxxxxx的小数。这样做是为了表示±0,以及接近于0的很小的数字。

E全为1

这时,如果有效数字M全为0,表示±无穷大(正负取决于符号位s)

1)GPU带宽分析中GPU Non-Base Level Textures过低是什么意思
2)为什么不建议用LoadFromMemory接口


这是第465篇UWA技术知识分享的推送,精选了UWA社区的热门话题,涵盖了UWA问答、社区帖子等技术知识点,助力大家更全面地掌握和学习。

UWA社区主页:community.uwa4d.com
UWA QQ群:793972859

From UWA AI 问答

Q:GPU带宽分析中GPU Non-Base Level Textures过低是什么意思?

A:GPU Non-Base Level Textures指标过低解析:
在GPU带宽分析中,GPU Non-Base Level Textures指标统计的是GPU采样非Mipmap第0层(即经过缩小处理的层级)纹理的次数。该指标“过低”通常意味着绝大多数纹理采样都强制使用了最高分辨率的第0层(Base Level)。

这并非性能优异的标志,反而往往暗示了潜在的带宽浪费和缓存命中率低的风险,具体分析与优化策略如下:

1. 核心含义与风险

Mipmap未生效或使用不当:正常情况下,随着物体远离摄像机,GPU应自动采样更低分辨率的Mipmap层级。若该指标过低,说明场景中的纹理即便在远处也被强制以最高精度采样。

带宽压力剧增:采样第0层意味着每次像素着色都需要读取更多数据。对于远距离或小面积物体,这不仅浪费了宝贵的显存带宽,还增加了GPU Memory Bus的负载,直接导致功耗上升和设备发热。

Cache Miss率升高:过大的纹理数据难以完全放入L1/L2缓存,导致频繁的Cache Miss,进一步引发GPU Stall(读写停滞),降低帧率。

2. 常见成因排查

未开启Mipmap:检查关键纹理资源是否在导入设置中关闭了"Generate Mip Maps"选项。

各向异性过滤(Anisotropic Filtering)强制开启:若在Quality Settings中将各向异性过滤设为"Forced On",或在特定纹理上设置了过高等级,GPU为了修正视角倾斜带来的拉伸,会倾向于采样更高层级甚至混合多层,但在某些统计口径下,过度追求清晰度可能导致非基础层采样逻辑异常或实际仍大量依赖基础层数据。

Shader编写问题:检查是否有Shader代码强制指定了LOD层级(如tex2Dlod固定取0),或使用了不支持Mipmap采样的特殊算法。

UI纹理误用:UI元素通常不需要Mipmap,但如果3D场景中的大量贴图被错误地当作UI处理而未开启Mipmap,也会导致此现象。

3. 优化建议

合理开启Mipmap:对3D场景中的大部分纹理开启Mipmap生成。这能显著降低远处物体的采样带宽。

分级设置各向异性过滤:避免全局强制开启。建议在Project Settings中设为"Per Texture",仅对地面、墙面等需要高质量斜视效果的纹理单独开启,并尽量使用较低等级(如2x或4x)。

控制纹理分辨率:结合渲染距离,对远景物体使用低分辨率纹理。若高分辨率纹理的Mipmap 0层采样率极低(如小于5%),说明其高分辨率部分从未被使用,应直接缩小源图尺寸。

检查RenderTexture:确认动态生成的RenderTexture是否必要开启了Mipmap,避免不必要的内存与带宽占用。

通过提升非基础层纹理的采样比例,可有效降低单次采样的数据量,从而在保证视觉质量的前提下,显著优化GPU带宽与能耗表现。


From UWA AI 问答

Q:为什么不建议用LoadFromMemory接口?

A:不建议大规模使用LoadFromMemory(含同步/异步版本)主要基于以下三方面性能缺陷,已在真实移动端项目中验证:

一、显著更高的CPU与内存开销

  • 同步阻塞主线程:LoadFromMemory是完全同步调用,强制在主线程解压并构建AssetBundle对象,导致帧率卡顿,尤其在加载较大包(如含10张1024×1024纹理)时,耗时可达数十毫秒(对比LoadFromFile的零点几毫秒)。
  • 双倍内存驻留:需先将完整AssetBundle字节数组(如几十MB)全部载入内存,再解压/解析;而LoadFromFile仅加载头部(KB级),资源按需流式读取,内存占用极低。

二、丧失底层IO优化能力

  • LoadFromFile在真机上利用系统文件句柄缓存、预读机制及OS磁盘缓存,对LZ4压缩包可直接映射解压,避免全量解压。
  • LoadFromMemory绕过文件系统,强制走内存拷贝+解压路径,无法享受任何OS级IO优化,且破坏Unity内部PreloadManager的加载队列与速率控制。

三、加密需求存在更优替代方案

  • 若为防破解而加密AssetBundle,LoadFromMemory会引入额外解密内存副本(如解密后字节数组+AssetBundle对象),加剧内存压力。
  • 更佳实践:
    ✅ 对关键配置/脚本单独加密,资源文件(纹理、模型等)免加密(实际防护效果有限);
    ✅ 使用LoadFromFile+自定义偏移加载(offset参数)实现轻量混淆;
    ✅ WebGL等平台可先解密至内存再调用LoadFromMemoryAsync,但需严格复用byte数组避免内存膨胀。

结论:除非必须动态解密或跨平台兼容性受限,否则应优先选用LoadFromFile(LZ4压缩+合理分包策略,兼顾加载速度、内存效率与热更新可行性。

分享链接:
https://www.uwa4d.com/main/uwa-shared.html?shareId=116ff3ca-b...

无论是社区里开发者们的互助讨论,还是AI基于知识沉淀的快速反馈,核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。本期分享分别来自UWA AI问答和UWA问答社区,希望这些从真实开发场景中提炼的经验,能直接帮你解决当下的技术卡点,也让你在遇到同类问题时,能更高效地找到破局方向。

封面图来源于网络


今天的分享就到这里。生有涯而知无涯,在漫漫的开发周期中,我们遇到的问题只是冰山一角,UWA社区愿伴你同行,一起探索分享。欢迎更多的开发者加入UWA社区。

UWA官网:www.uwa4d.com
UWA社区:community.uwa4d.com
UWA学堂:edu.uwa4d.com
官方技术QQ群:793972859

2025年5月,某头部社交平台安全团队监测到异常数据波动:某IP段12小时内注册153个新账号,注册设备、地理位置高度集中,指向境外云服务商弹性IP。这些账号注册后24小时内批量发布虚假投资广告,48小时内被封禁。过去6个月,该IP段注册账号超8000个,89%涉及违规——以“IP池+AI自动化”为核心的养号黑产产业链正加速迭代。
面对黑产“动态IP池+生成式AI脚本”的组合攻击,传统风控手段(如单IP注册限制、静态验证码)逐渐失效。某社交平台安全负责人称,通过接入IP数据云实时查询接口,结合账号行为分析模型,构建“事前防御+事中监控+事后溯源”三重防线,注册账号违规率降低72%。

一、黑产养号:低成本暴利,IP池与AI成核心武器

黑产团伙养号模式标准化,IP资源池与AI自动化工具是核心基础设施:

  • IP来源多样化隐蔽化:利用代理服务器、云主机弹性IP、家庭宽带劫持、秒拨IP技术,快速切换攻击节点,规避风控规则。
  • AI自动化注册与孵化:生成式AI脚本生成虚假信息绕过验证,深度伪造行为模拟真人操作,实现账号全生命周期自动化管理。
    据行业权威研究机构发布的报告显示,单个黑产账号注册成本从2024年的0.1元降至0.08元。黑产通过广告、诈骗或刷量等手段可获利数元至数百元,利润率高达3500%。另据相关市场调研机构统计,2025年全球社交平台因虚假账号损失预计超220亿美元。

    二、传统风控困境:“单IP限制”为何失效?

    面对黑产规模化、智能化攻击,传统风控手段暴露三大短板:

  • 规则简单粗暴:单IP注册数量限制易被动态IP绕过;静态黑名单滞后,且易误伤正常用户。某直播平台曾因“单IP注册限制”误判35%的正常用户。
  • 无法应对AI伪造行为:AI可模拟“符合规则”的异常行为,设备指纹篡改使传统识别技术失效。
  • 全球化攻击溯源难:黑产使用境外云服务商IP,传统风控系统覆盖不足,加密通信与虚拟货币支付切断追踪路径。

    三、技术破局:IP数据云实现“动态风险评估”

    精准打击养号黑产,需从“静态封禁”转向“动态风险评估”,IP数据云的核心价值在于:

  • 实时查询:从“孤立IP”到“关联风险画像”:聚合全球IP历史行为数据,构建多维风险画像,标注风险等级、类型、关联账号数等。
    案例:某社交平台接入IP数据云接口后,发现某IP过去7天注册62个账号,51个因发布广告被封禁,关联设备90%使用云手机,注册与登录地理位置跨3个国家,系统自动拦截并触发人工复核。
  • 数据覆盖广:全球IP库+实时更新:覆盖全球220+国家/地区IP资源,与主流云服务商数据同步,新上线IP快速识别,历史行为追溯,动态风险评分。
    对比传统方案:

    四、实战效果:某社交平台“清朗行动2025”

    2025年Q2,某头部社交平台开展专项治理,通过“IP数据云+行为分析”联动打击养号黑产:

  • 注册环节:动态拦截高风险IP,对“高风险IP”直接封禁,“中风险IP”触发二次验证,“低风险IP”放行但限制初始功能。
  • 账号孵化期:行为分析模型实时监控,对异常账号限制功能,追溯关联信息,利用图计算技术发现隐蔽攻击链。
  • 数据成果:注册账号违规率下降72%,平台日均举报量减少48%,用户因诈骗导致的损失降低1.2亿元,成功溯源并打击3个境外黑产平台,封禁黑产账号超2000万个。
    平台安全负责人表示,IP数据云解决了“看得全”(全球IP覆盖)和“看得准”(结合历史行为数据区分正常用户与黑产IP)的问题,使风控系统更精准拦截攻击,减少对正常用户的干扰。

    五、未来挑战:AI养号与全球化黑产的双重威胁

    尽管当前技术提升风控效率,但黑产仍在迭代:

  • AI养号:从“规则绕过”到“行为模拟”,利用生成式AI模拟真人对话、朋友圈内容,深度伪造技术降低账号异常行为检测概率。
  • 全球化IP:从“集中攻击”到“分散渗透”,通过境外云主机、代理服务器分散攻击,利用隐私计算技术隐藏设备信息,虚拟货币支付、加密通信工具规避追踪。
    应对策略:
  • 技术层面:推广“IP数据云+联邦学习”,构建账号、IP、设备关联图谱,利用区块链技术实现风险账号不可篡改记录。
  • 合规层面:结合法规要求实现风险账号自动处置,推动国际执法合作打击跨境黑产基础设施。
  • 生态层面:与云服务商、运营商建立黑产IP实时共享机制,联合行业协会制定打击标准。

    结语:风控的本质是“成本博弈”

    黑产“低成本暴利”模式决定其不会停止攻击,但社交平台可通过IP数据云的“溯源能力”与行为分析的“预测能力”,抬高攻击成本。当黑产养一个账号成本从0.08元升至1元,而获利仅0.5元时,自然会转向其他目标。
    未来,随着AI、区块链、隐私计算等技术发展,社交平台与黑产的攻防战将进入“智能化、全球化、生态化”新阶段。唯有持续创新、协同治理,才能守护数字世界的清朗与安全。