【鸿蒙基础入门】概念理解和学习方法论说明

一、鸿蒙是什么？

鸿蒙是分布式操作系统，支持万物互联的概念。分为开源鸿蒙与鸿蒙之分。

而安卓和 iOS 是为移动设备（手机or平板）设计的单设备系统，侧重单机体验；而鸿蒙是面向万物互联的分布式系统，能让手机、平板、电脑、家电、车机等多设备无缝协同、硬件共享，一套系统适配全场景，而非只服务手机平板。

刚接触鸿蒙的同学，很容易把HarmonyOS商业鸿蒙和开源鸿蒙弄混。

首先我们聊一下这两者的关系，然后再说技术上的区别。

众所周知，鸿蒙是华为开发的一款分布式智慧操作系统。因为开发系统，最重要的是集思广益，大家共同维护。为了在IOS和Android之间生存，鸿蒙的茁壮成长一定是需要开源，各方助力才能实现。

在这种思想上，华为的鸿蒙将HarmonyOS的基础功能提取出来，创建了OpenHarmony版本开源，交付给开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目。所以OpenHarmony是HarmonyOS的能力基座，两者的系统架构基座是一致的，为下图所示：

一般而言，这两者关系是相辅相成的，但是HarmonyOS作为亲儿子，能力上还是比OpenHarmony强太多。

华为贡献了 HarmonyOS 的一部分源代码给 OpenHarmony 项目，所以在底层代码等方面有一定的共通性。

因为OpenHarmony 是开源，所以厂商可基于其进行二次开发打造自己的操作系统和品牌。HarmonyOS 是华为品牌下的操作系统，主要应用于华为及其子品牌设备，使用需获得华为授权。

而HarmonyOS特性的功能集合Kit，在OpenHarmony中是没有的。HarmonyOS 在 OpenHarmony 开源底座之上，额外包含 HMS Core、超级终端（Super Device）、方舟编译器 / 运行时增强、星盾安全、盘古大模型端侧 Kit、应用市场 / 支付 / 推送、多屏协同、流畅引擎、设备专属驱动与性能优化、地图 / 定位 / 扫码 / AI 视觉、车机 / PC / 穿戴定制服务 等闭源功能 Kit，这些在 OpenHarmony 中均不存在。【核心是华为面向 C 端消费级与商业生态的专有能力层】

二、OpenHarmony与HarmonyOS技术上的区别

经过这五年鸿蒙的系统迭代，从之前最早HarmonyOS商业鸿蒙还在用Java开发。到OpenHarmonyJS和ArkTS试水，最后两者路线统一。

我们可以观察到鸿蒙在以极快的速度成长。目前仓颉和PC鸿蒙都在快速孵化中，未来可期。但是两者之前还是有所区别，如体现以下三个方面的差别：

系统定制的差别：
OpenHarmony作为开源项目，具有高度的定制性，各厂商可以根据自身需求对系统进行深度定制和裁剪，以适配不同类型的设备和应用场景。比如，智能手表厂商可以根据手表的硬件特点，对 OpenHarmony 进行定制，去除不必要的功能，优化资源占用，使系统更适合手表的运行。

而HarmonyOS是华为的商用系统，定制性相对较弱，主要围绕华为的 “1+8+N” 全场景战略进行优化和适配，以确保华为设备之间的协同体验达到最佳效果。
应用兼容性

生态包容性的差别：
OpenHarmony致力于为各种硬件设备提供通用的操作系统平台，支持从物联网设备到智能终端等多种类型的硬件。不同厂商可以根据自身硬件特点，在 OpenHarmony 基础上进行适配和优化，因此在硬件适配的广度上具有优势。

而HarmonyOS主要针对华为及部分合作厂商的硬件设备进行深度优化和适配，在华为设备上能够充分发挥硬件的性能优势，实现硬件与软件的高度协同。例如，HarmonyOS 与华为手机的芯片、摄像头等硬件深度结合，实现了拍照效果的优化、系统性能的提升等。

应用生态兼容的差别：
OpenHarmony由于其开源性质，应用生态相对较为分散，目前应用数量和种类相对有限，对安卓应用的兼容性也因不同厂商的定制而有所差异。

而HarmonyOS早期版本通过兼容安卓应用，快速丰富了自身的应用生态，用户可以在 HarmonyOS 设备上使用大量的安卓应用。但 HarmonyOS NEXT 不再兼容安卓应用，而是专注于发展自己的原生应用生态。纯血鸿蒙在2025年会正式全面上架。

三、鸿蒙 HarmonyOS 版本年代记

四、鸿蒙相关概念专有名词的解释：

鸿蒙
特指HarmonyOS与OpenHarmony，前者是商业鸿蒙，是华为公司使用和维护的系统。后者是HW开源给开放原子基金协会的系统，任何人遵守开源协议，都可以使用和改造的系统。

HarmonyOS虽然基座是OpenHarmony，但是上层功能和使用差异也还是有的。两者虽然近似，但是并非一个东西。

鸿蒙相关公司
目前使用和维护开源鸿蒙OpenHarmony成长的公司有很多，例如深开鸿，润开鸿，鸿湖万联，开鸿智谷，九联开鸿等。开源鸿蒙的现在使用方向很多，例如电网，工业，物联，矿产等等。
商业鸿蒙，是华为公司自己进行迭代和维护与使用。

鸿蒙北向和南向
特指，北向应用开发 ，南向设备开发。设备开发多是基于开源鸿蒙。北向分OpenHarmony应用开发和HarmonyOS应用开发。

鸿蒙双框架和单框架
在 HarmonyOS NEXT 发布之前，华为手机运行的是 “双框架” 系统。其架构逻辑是鸿蒙和安卓框架共同存在，但底层基础服务仍以鸿蒙为核心，也被称为 “杂交系统”。单框架：以 HarmonyOS NEXT 为代表，是纯血鸿蒙系统，底座全线自研，去掉了传统的安卓开放源代码项目（AOSP）代码，只支持鸿蒙内核及鸿蒙系统的应用

鸿蒙HDE
华为开发者专家（HUAWEI DEVELOPER EXPERTS），经过华为官方认证。他们是华为开放能力的实践领袖，肩负着技术布道、知识赋能等责任，会在各大技术社区解答用户有关华为开发能力的相关问题，定期在社交媒体上进行线上分享，也常在线下以讲师身份分享关于华为最新技术趋势讲解。

鸿蒙HDD
UAWEI Developer Day华为开发者日，定期在国内多个城市举办开发者深度交流的活动。

仓颉
仓颉是华为鸿蒙系统中的编程语言，目前也可用于鸿蒙开发，还在起步中。

鸿蒙开发概念
主流使用ArkTS声明式开发语言，ArkUI响应式开发框架。

以下是鸿蒙应用开发的类的概念说明：

import { promptAction } from '@kit.ArkUI' // 导入系统API
import { IconView } from './IconView' // 导入自定义组件

@Entry // 装饰器，代表入口和界面的意思。
@Component // 装饰器，代表组件
struct Index {
  
  // 重写build接口进行界面或者组件布局的编写，与传统命令式编程不同，这里和Flutter类似，鱼鳞排版的布局搭建
  build() {
    // 堆叠容器控件
    Stack({
      alignContent: Alignment.BottomEnd // 小括号内为Stack的属性设置
    }) { // 花括号内是包裹的子容器
      Text("边距点击问题测试demo")
        .fontSize(50)
        .fontWeight(FontWeight.Bold)

      IconView().zIndex(1)

      Row() {
      }
      .height('100%')
      .width('100%')
      .backgroundColor(Color.Blue)
      // 点击事件
      .onClick(() => {
        // 点击事件回调
        
        // 气泡
        promptAction.showToast({
          message: "点击！"
        })
      })
    }
    // 控件的属性，多是通过点的形式进行设置
    .height('100%')
    .width('100%')
  }
}

ArkUI-X
ArkUI - X 是华为推出的跨平台 UI 框架，旨在将 ArkUI 开发框架扩展到多个操作系统平台。目前还在起步中。

五、鸿蒙自学步骤：

不管是前端，移动端转鸿蒙。还是初学者学习鸿蒙。都可参考根据以下学习路线进行鸿蒙的学习。

首先需要确定你的开发方向，是OpenHarmoy or HarmonyOS。是应用开发，还是设备开发，亦或者是系统开发？

HarmonyOS
（1）知其然才能知其所以然，先进行鸿蒙整体概念的入门和学习
鸿蒙官方开发者学堂，针对鸿蒙相关知识点，进行视频类的讲解，对应还有习题与相关认证。
https://developer.huawei.com/consumer/cn/training/result?cour...
像鸿蒙初级和高级认证，应聘鸿蒙开发多会要求。

（2）通读鸿蒙学习文档
官方文档
有详细的功能调用接口说明：
https://developer.huawei.com/consumer/cn/doc/harmonyos-guides...

六、根据自身定位进行定向学习

目前学习鸿蒙的开发者们，多是从前端，移动端开发转向鸿蒙。当然也有初学者。

（1）针对前端方向
首先鸿蒙的声明式开发与响应式布局，和前端Vue，React等开发语言和框架类似。所以开发思路上的门槛并不大，除了鸿蒙知识的学习，更需要补充移动端开发的思想。

这是前端开发者的弱势。因为目前市面上的鸿蒙开发工作，多是从既有的移动端进行鸿蒙化迁移，需要能看懂Android或者IOS端的代码。并且移动端开发比前端开发，对性能，内存使用，代码效率的要求可能会更高一些，这也需要一定的学习成本。

Android代码语法的学习可从Android官网或者菜鸟笔记，哔哩哔哩等网站上免费进行学习。

(2) 针对移动端开发方向
如果是Android Compose ，IOS swiftUI转到鸿蒙，都是声明式开发，学习鸿蒙的门槛会很小。只是对鸿蒙平台的系统API和思想进行学习。

若不是这两种，还是传统命令式编程方向转过来，那需要先对声明式开发与响应式布局的概念进行学习。转变开发思路。

深入了解鸿蒙系统的独特架构与设计理念，对比与移动端系统的差异。这样才能如指臂使。熟悉 HarmonyOS 的开发语言如 Java、Kotlin 或 JavaScript 等，掌握 ArkUI 等开发框架的使用。参考官方丰富的文档、教程和示例代码，动手实践经典案例与小型项目。逐步积累鸿蒙开发经验，实现技术转型。

（3）针对初学者方向
初学者应先了解鸿蒙系统的架构与特性，学习相关编程语言，通过官方文档、教程及实践项目掌握 ArkUI 等开发框架，多参与社区交流以不断提升开发能力。
重点是编程语言语法的基础，开发概念的熟悉，多参与应用开发积累项目经验。

开头

阿里Qwen团队刚刚丢出了一枚重磅炸弹——Qwen3.6-35B-A3B。
这不仅仅是一个新版本的发布，更是一次对“算力堆砌论”的降维打击。它用350亿的总参数量（仅激活30亿），在智能体编程等关键场景下，硬刚了参数大得多的稠密模型。
开源地址：https://modelscope.cn/collections/Qwen/Qwen36

核心分析

1. 稀疏性（Sparsity）的胜利：MoE架构的工程化落地
Qwen3.6-35B-A3B 的核心标签是 MoE（混合专家模型）。

• 为什么重要： 传统的稠密模型（Dense Model）训练和推理时，所有参数都要参与计算，极其昂贵。而MoE架构像一个“智囊团”，每次只激活最擅长的“少数专家”（即30亿激活参数）。
• 对开发者的价值： 这意味着开发者可以用极低的硬件门槛（消费级显卡即可运行）获得接近千亿级模型的推理能力。它解决了“想要大模型效果，但买不起A100集群”的痛点。

2. 智能体（Agent）编程能力的跃升：从“写代码”到“做架构”
官方数据显示，它在智能体编程方面大幅超越了前代 Qwen3.5-35B-A3B，甚至能与 Qwen3.5-27B 和 Gemma4-31B 等更大参数的稠密模型一较高下。

• 场景变化： 这不仅仅是写个函数，而是意味着它能更好地理解复杂的项目结构、API调用和逻辑编排。
• 工程落地： 对于初创公司或独立开发者，这意味着你可以用它来辅助构建真正的全栈应用，而不仅仅是写个Hello World。它是AI程序员的“副驾驶”，能显著降低从0到1的试错成本。

3. 多模态思考与非思考模式的并存
模型依然支持多模态思考与非思考模式。

• 解读： “思考模式”意味着模型在回答前会进行推理（Chain of Thought），适合复杂决策；“非思考模式”则追求极速响应，适合简单问答。
• 产品化意义： 这种灵活性让开发者可以针对不同的业务场景（如：客服对话 vs. 代码生成）动态切换模型状态，优化用户体验与算力成本的平衡。

苍狮技术团队观点

• 关于“高估”与“低估”： 目前市场可能低估了 3B激活参数 在端侧（Edge）落地的可能性。虽然大家都在卷千亿大模型，但Qwen3.6这种“小身材大能量”的模型，才是未来AI应用爆发的基石。
• 投入建议： 如果你是应用层开发者，现在是最佳入场时机。不要去死磕训练大模型，而是利用Qwen3.6这种高性能的开源底座，去构建垂直领域的Agent应用。它的开源属性（ModelScope）意味着你可以完全掌控数据隐私和模型迭代。
  

总结

Qwen3.6-35B-A3B 的出现，标志着大模型竞争从“比谁参数大”进入了“比谁更聪明、更省钱”的新阶段。它不是简单的参数堆砌，而是一次高效的资源调度革命。

OpenClaw（俗称“养龙虾”）的热度正在经历断崖式下跌。从3月的全网刷屏、GitHub霸榜，到4月的“退坑潮”与“卸载热”，这场关于AI智能体的狂欢仅仅维持了不到一个月。

这并非简单的“喜新厌旧”，而是工程实践对过度炒作的必然修正。当“数字员工”的幻想撞上昂贵的Token账单与高危的安全漏洞，OpenClaw正在经历一场残酷的价值回归。

成本黑洞：从“订阅套利”到“按量付费”的硬着陆

OpenClaw退潮的最直接推手，是算力成本的失控。

早期用户之所以能体验“AI替我打工”的爽感，很大程度上依赖于对大模型厂商订阅制的“套利”。用户利用Claude等模型的包月订阅（如每月200美元），通过OpenClaw进行高频自动化调用，这在初期被厂商默许。然而，这种模式对算力厂商而言是巨大的亏损——有分析指出，重度用户的Token消耗价值可能是订阅费的5倍以上。

随着Anthropic等厂商在4月初切断第三方Agent的订阅访问权限，强制转向按量付费的API模式，OpenClaw的“性价比”瞬间崩塌。

• 隐形消耗惊人：OpenClaw采用“规划—执行—观察”的循环模式，单次任务可能触发数十次模型调用。
• 心跳机制空耗：为了保持上下文连贯，默认每30分钟发送一次请求。即便不干活，挂机一天也会产生几十次API调用。
• 账单失控：从“月薪两万养不起一只虾”的段子变成现实，中度使用者月账单轻松破千，且缺乏有效的上下文缓存优化，导致Token利用率极低。

对于开发者而言，这揭示了一个工程现实：未经优化的Agent原型，其资源消耗是正常应用的十倍级。

安全裸奔：企业级落地的“死穴”

如果说成本是劝退个人玩家的理由，那么安全问题则是OpenClaw在企业侧的“死刑判决”。

OpenClaw为了执行复杂任务，往往需要极高的系统权限。然而，其默认安全配置极为薄弱。工信部与国家互联网应急中心已接连发布风险提示，指出其存在严重的漏洞。

• 权限过大：一旦被黑客通过“提示词注入”攻击，攻击者可直接获取系统完全控制权。
• 数据泄露：已有案例显示，OpenClaw在交互中泄露了用户的IP地址、用户名甚至SSH密钥。
• 恶意插件：官方市场中混入了大量恶意技能包，伪装成办公助手实则窃取数据。

目前，许多国企和科技公司已明令禁止在内网部署OpenClaw。对于工程团队来说，一个无法审计、权限不可控的“黑盒”Agent，是无法通过企业安全合规审查的。

场景伪需求：普通人的“数字员工”幻觉

剥去营销的外衣，OpenClaw面临着“场景匮乏”的尴尬。

绝大多数跟风“养虾”的普通人，并没有复杂的自动化业务流需要处理。对于简单的文档整理、资料查询，现有的ChatGPT、豆包等对话式AI已足够好用且免费。OpenClaw的核心价值在于“自主执行”，但这需要用户具备明确的业务逻辑（SOP）和一定的编程调试能力。

• 技术门槛：配置Python环境、API密钥、调试工作流，劝退了90%的非技术用户。
• 效果落差：没有固定业务流的支撑，OpenClaw最终往往沦为昂贵的聊天机器人。

真正的机会在于“一人公司”或初创团队，他们有明确的痛点（如自动测试、数据清洗），且愿意投入时间打磨工作流。但对于大众市场，这目前只是一个伪需求。

苍狮技术团队观点

OpenClaw的退潮是AI智能体发展史上的必经之路，它戳破了“通用Agent”的泡沫，让行业回归理性。

• 短期判断：OpenClaw类开源项目将进入“去伪存真”的洗牌期。单纯依赖“套壳”和“订阅套利”的工具将被淘汰，具备上下文缓存优化、本地化部署能力的工程化方案将成为主流。
• 长期价值：AI从“对话”走向“行动”是大势所趋，但路径会比想象中更长。未来的机会不在于让AI“全自动”接管一切，而在于构建“人机协同”的可靠工作流。
• 行动建议：开发者应停止盲目跟风，转而关注如何降低Token消耗的架构优化（如引入本地小模型过滤请求）；普通用户则应保持观望，等待更成熟、更安全、开箱即用的商业化产品出现。

总结

OpenClaw的遇冷并非技术的失败，而是工程化与商业化落地的阵痛。它证明了在当前的算力成本与安全架构下，通用的“全自动AI员工”尚不成熟。真正的智能体时代，需要的不是盲目的“养虾”，而是更精细的工程治理与更务实的场景落地。

摘要：Gentest生物样本作为ADME-Tox研究领域含人肝微粒体、重组酶及转运体细胞的重要工具，应用于临床前药物代谢与毒理研究。

一、什么是生物样本？了解ADME研究体系的组成

生物样本多指人源临床样本，如血清、血浆、组织、细胞、微粒体等，是临床前药物代谢与毒理（ADME-Tox）研究领域的重要工具。

近年来，DLS通过整合资源，进一步完善了Gentest体系从生物样本到功能研究的技术链条（点击了解生物样本详情）。在临床前研究阶段，相关产品被应用于代谢研究、药物相互作用评估等场景。

二、人肝微粒体/重组酶/转运体细胞对ADME研究的应用价值

Gentest生物样本主要围绕药物代谢与转运研究需求设计，覆盖ADMET研究多个关键环节，适用于：

• 药物代谢稳定性研究
• 药物-药物相互作用（DDI）分析
• 酶表型分析
• 转运体功能研究
• IND申报前体外实验支持

三、核心产品体系解析

3.1 人肝微粒体及组织组分

人肝微粒体（HLM）是体外代谢研究的基础工具之一。

其中，UltraPool HLM 150通过多供体混合方式，覆盖更广泛的人群代谢差异，有助于提高 实验 数据的稳定性与可重复性。

应用方向包括：

• 代谢稳定性评价
• 代谢物鉴定
• CYP酶反应表型研究
• DDI风险评估

3.2 Supersomes重组酶体系

Supersomes为常用的重组酶研究工具，涵盖多种代谢酶 类 型，如：

• CYP酶
• UGT酶
• FMO酶

该类产品常用于：

• 单酶代谢路径分析
• 药物相互作用筛选
• 代谢机制研究

3.3 转运体研究工具（TransportoCells）

转运体在药物吸收、分布和排泄过程中发挥关键作用。

相关产品包括：

• SLC摄取转运体细胞（如OATP、OCT、OAT等）
• ABC外排转运体囊泡（如P-gp、BCRP等）

其特点在于：

• 冻存即用
• 无需构建稳定细胞株
• 适用于高通量筛选

四、产品体系特点总结

从实际应用角度来看，该类ADMET研究工具通常具备以下特点：

• 多供体来源，降低个体差异影响
• 批次稳定，有利于长期研究
• 冻存即用，提高实验效率
• 覆盖代谢与转运多个关键环节
• 适用于规范化临床前研究流程

五、FAQ：ADMET实验常见问题

Q1. 这些产品可以用于临床或诊断吗？

不可以，仅限科研用途。

Q2. 多供体微粒体的优势是什么？

可以更好地模拟人群差异，提高实验结果的代表性和稳定性。

Q3. Supersomes主要应用在哪些研究中？

适用于代谢酶表型分析、DDI研究及代谢路径解析。

Q4. 转运体细胞是否需要自行培养？

通常为冻存即用型，解冻后即可开展实验。

Q5. 产品如何保存？

一般建议在-80℃条件下储存，并避免反复冻融。

六、本文补充说明

在临床前药物研发过程中，ADMET研究是连接候选药物筛选与IND申报的重要环节。选择稳定、标准化的体外研究工具，有助于提高数据可靠性并降低研发风险。

如需进一步了解相关人肝微粒体、重组酶、转运体细胞等技术资料，欢迎点击此处了解曼博生物提供的Gentest生物样本信息。

本文基于Discovery Life Sciences公司公开资料，由DLS中国官方供应商上海曼博生物整理，仅用于科研信息分享。

什么是MFA轰炸攻击？

多因素认证（MFA）的设计初衷，是大幅降低基于密码的攻击风险，成为企业网络安全的重要防线。但即便MFA已被广泛部署，我们仍看到Lapsus$等高级威胁攻击者，通过一种看似简单却极具破坏力的攻击方式——MFA轰炸攻击（又称MFA垃圾邮件攻击、MFA疲劳攻击），成功入侵多家大型企业。

这种攻击无需高超的黑客技术，也不需要昂贵的工具，核心是利用任何安全系统中最不可预测的元素：人类行为。据微软研究数据显示，仅一年内就检测到超过38.2万起MFA疲劳攻击，其中1%的用户会盲目通过第一个意外的推送通知——这一数据充分说明，企业仅部署MFA远远不够，更需要一套全面的防护策略。

MFA轰炸攻击（又称MFA疲劳攻击、MFA提示轰炸、推送轰炸），本质是一种社会工程学攻击：攻击者向目标设备持续发送大量MFA验证请求，通过反复骚扰，迫使目标用户因烦躁、困惑或肌肉记忆，最终通过其中一次恶意认证请求。

与其他密码攻击不同，MFA轰炸攻击的致命之处在于，它将日常使用的技术变成了攻击用户的武器。当攻击者控制了MFA验证请求的频率和时机时，每一条合法的推送通知，都可能被利用成为攻击载体。

MFA轰炸攻击的攻击流程

第一阶段：获取用户凭证

这一阶段通常在实际轰炸攻击前数周甚至数月就已开始。攻击者会投入大量时间，通过多种渠道收集有效的登录凭证。如今，暗网上的泄露凭证交易市场规模庞大且价格低廉，攻击者有时只需花费10至50美元，就能购买到大型企业的已验证凭证集。

第二阶段：触发认证提示

获取有效凭证后，攻击者进入触发认证提示阶段，这一步需要精心的时机规划和策略。高级攻击者不会立即发起猛烈的轰炸攻击，而是先进行侦察：他们会尝试几次登录，了解目标的MFA配置、所使用的具体认证应用或服务，以及用户的典型在线活动模式。

部分攻击者会采取“低调渗透”策略，在数周内每天只发送几次MFA请求；另一些则会采取激进的MFA垃圾邮件攻击，每分钟发送数十条通知。前者的目的是让目标用户习惯这类认证请求，降低对每条通知的警惕性，不再仔细核对。

第三阶段：强化社会工程学操控

社会工程学强化阶段，是区分普通攻击者与专业网络犯罪组织的关键。高级威胁攻击者明白，仅靠技术很难成功，对人类心理的操控才是核心。

在高级MFA轰炸攻击中，受害者还可能接到自称是技术支持、安全团队成员甚至公司高管的电话。这些来电者通常准备充分，会利用从社交媒体、公司网站和前期侦察中获取的信息，熟知目标的公司情况、同事信息和当前项目。他们会编造虚假的安全事件或系统维护需求，制造紧迫感，谎称需要立即通过认证验证。

第四阶段：利用获取的访问权限

一旦受害者通过了虚假的认证请求，访问权限利用阶段就正式开始。专业攻击者清楚，在入侵被发现前，他们的操作窗口非常有限。

获得访问权限后的几分钟内，他们会执行一系列预设操作：修改密码，锁定合法用户，为自己争取更多时间；将自己的设备添加到账户中，确保即使原始入侵方式被发现，仍能持续访问；安装远程访问工具或后门木马，建立进入网络的备用入口；从密码管理器、浏览器保存的密码或邮箱中收集更多凭证，实现企业内部的横向渗透。

这一阶段的执行速度，往往决定了攻击最终是引发轻微安全事件，还是导致大规模数据泄露。

MFA轰炸攻击背后的心理学逻辑

安全专家在设计系统时，通常假设用户会对每一次认证请求做出理性、谨慎的判断。但数十年的行为研究表明，在压力、重复和时间限制下，人类的决策会越来越容易出现偏差——而这正是MFA轰炸攻击刻意营造的环境。

通知疲劳的影响

人类的大脑并不擅长对重复、看似合法的请求保持持续警惕。当用户在正常工作中收到多条MFA提示时，多种心理因素会削弱他们的安全意识。

自动化偏见会让人们在熟悉的界面上形成无意识的操作习惯。经过数月在正常工作中合法通过MFA请求后，这种操作会变得高度自动化，用户甚至无需有意识地判断上下文和时机，就能通过通知。当攻击者将轰炸时间选在用户通常进行认证的时段（如周一早上上班时），这种肌肉记忆效应会变得格外危险。

消耗心理资源

信任偏见会造成另一种心理漏洞，被攻击者利用。MFA提示来自用户日常工作中频繁接触的可信系统，与语法错误、发件人陌生的钓鱼邮件不同，认证通知看起来完全合法——因为它们确实是由真实的安全系统生成的。

用户被训练成信任这些通知，并迅速响应以维持工作效率和系统访问权限。当攻击者能够通过非法方式触发这些可信通知时，这种习得的信任就变成了攻击武器。

“只想让它停止”的心理

“只想让它停止”的心理，或许是对MFA轰炸攻击最危险的心理反应。安全专家往往低估了这类攻击对日常工作流程和个人设备使用的实际干扰。

行为安全研究表明，高压场景——比如远程员工正在准备会议，却被大量MFA提示轰炸——会促使用户为了恢复正常状态，而直接通过通知。此时，用户会将这些通知视为需要解决的技术问题，而非需要评估的潜在安全威胁。

如何防范MFA轰炸攻击？

防范MFA轰炸攻击，需要采取“技术+人力”的双重策略，覆盖这类攻击成功的两个核心因素。企业不能只部署MFA就万事大吉，而需要更全面的防护方案。

部署自适应认证策略

实施上下文感知认证系统，实时分析地理位置一致性、设备指纹、基于时间的访问模式和网络来源。这类系统会标记来自异常位置、陌生设备或可疑时间的认证请求；当检测到异常时，系统会自动提升安全要求，比如要求额外的验证方式，或针对高风险场景需要IT人员手动审批。

配置速率限制和流量控制

企业可以配置系统，限制用户在特定时间段内的认证尝试次数（如5分钟内最多3次）。实施指数退避机制，在每次失败请求后增加尝试间隔——例如，从30秒开始，对于持续的可疑活动，间隔延长至数小时。同时，启用账户隔离功能，在提醒安全团队的同时自动禁用可疑账户，并提供清晰的恢复流程。

制定MFA轰炸相关的事件响应计划

制定专门的指南，帮助安全团队区分合法的认证问题和轰炸攻击。指南中需包含检测标准，如多次快速请求、异常地理模式以及用户报告的可疑电话。建立安全的沟通渠道和标准化的用户联系脚本，以及即时补救措施，如临时禁用账户、安全重置密码和加强监控。

监控认证模式

实施实时监控系统，跟踪认证频率、地理异常和用户行为模式。为用户和部门建立基准模式，自动标记明显的偏差。建立分层警报系统，根据威胁严重程度升级，并与安全信息和事件管理（SIEM）系统集成，将认证异常与企业内其他安全事件关联分析。

开展压力测试培训

在条件允许的情况下，企业可以开展培训项目，模拟高压业务场景——即攻击者利用情绪状态和时间压力的场景。这类培训应教会用户保持安全意识，提供在压力下仍能有效决策的框架，并建立清晰的上报流程。

分析师对MFA轰炸攻击的看法

行业安全专家和研究机构一直在警告MFA轰炸攻击的风险不断上升。他们的研究结果揭示了一个令人担忧的现状：这类看似简单的攻击，正在入侵即使是防护完善的企业。

微软安全研究洞察

几年前，微软安全研究团队向行业发出了极具警示意义的提醒——他们揭露了野外MFA轰炸攻击的庞大规模。其全面监控数据显示，仅12个月内就检测到超过38.2万起MFA疲劳攻击。

更令人担忧的是，微软的行为分析发现，约1%的用户会盲目通过收到的第一个意外MFA提示，不进行任何验证或上下文核对。虽然1%的比例看似不高，但对于企业规模的用户群体而言，这意味着数千个潜在的入侵入口。

研究还表明，攻击者的时机把握和攻击方式已变得非常成熟。他们不再进行随机的MFA轰炸，而是仔细研究目标的工作模式，找到用户最可能不加审视就通过请求的最佳攻击窗口（例如，繁忙的周一早晨、重要会议前，或已知的系统维护期间）。

2025年及以后的专家预测

根据主要网络安全行业报告，2025年将成为认证安全威胁的关键转折点。

谷歌云《2025年网络安全预测》明确警告：“威胁攻击者将越来越多地利用人工智能开展复杂的钓鱼、语音钓鱼和社会工程学攻击”，并特别强调了旨在绕过MFA的技术。

趋势科技《2025年安全趋势报告》预测：“恶意攻击者将全力挖掘人工智能的潜力，让网络犯罪变得更简单、更快、更具破坏性。”其研究表明，人工智能驱动的社会工程学攻击，将使传统的MFA轰炸攻击变得更具迷惑性，更难被检测。

行业分析师尤其关注智能体人工智能（agentic AI）的出现——这类自主人工智能系统能够独立规划和执行任务，在网络攻击中，它们可以自动完成入侵、侦察和利用流程，提高攻击速度和精度，同时实时调整以绕过传统防御。飞塔（Fortinet）《2025年网络威胁预测》警告，这类人工智能代理将大幅提升攻击效率，给企业防护带来巨大挑战。

行业专家的共识非常明确：MFA轰炸攻击代表着攻击方法的根本性转变，这要求企业在认证安全和用户培训方面做出同样根本性的改变。正如多家领先网络安全公司所记录的那样，人工智能增强与人类心理利用相结合，将使这类攻击仅靠传统安全措施越来越难以防御。

借助ADSelfService Plus，保护企业免受MFA轰炸攻击

MFA轰炸攻击通常利用推送通知的漏洞，而ManageEngine ADSelfService Plus提供了多种防御机制来应对这类威胁。该解决方案除传统的推送通知外，还提供多种认证方式——包括FIDO2安全密钥、生物识别认证和TOTP令牌，帮助企业减少对MFA轰炸攻击目标（推送通知）的依赖。

其自适应MFA功能通过评估登录尝试过程中的风险因素，增强认证安全性。ADSelfService Plus还包含账户锁定策略，可在配置的失败认证次数后自动锁定用户，有效阻止依赖反复发送提示的MFA轰炸攻击。

此外，ADSelfService Plus支持无密码认证方式，从根源上消除了攻击者发起MFA轰炸攻击所需的初始凭证泄露问题。企业还可以利用该解决方案的全面认证日志，实时掌握认证模式，并在发生潜在安全事件时进行调查。

在实时分析领域，Apache Doris 已经成为一款被广泛采用的开源 OLAP 数据库。凭借高性能查询引擎与一体化架构，Doris 在实时数仓、日志分析等场景中持续发挥重要作用，并在近几个版本中不断向 AI 与搜索能力演进。

在此基础上，SelectDB Enterprise 作为官方企业版发行形态，面向生产环境对 Doris 进行系统性增强，重点补齐安全、治理、生态兼容以及可控交付能力，帮助企业更加稳定、合规地落地 Apache Doris。

近日，飞轮科技正式发布 SelectDB Enterprise 4.0.5 版本，该版本基于 Apache Doris 4.0.5 构建，在完整继承内核能力的同时，重点强化安全性、治理能力与生态接入能力，为企业打造一套面向生产环境的实时分析与 AI 数据底座。产品介绍

延续内核能力，企业级可靠可控

SelectDB Enterprise 4.0.5 是一个融合 AI、面向规模化落地的重要版本。该版本的意义不在于问题修复的数量，而在于其完成了一次非常关键的衔接：

• 一方面，它完整承接 Doris 4.0 系列 “AI 驱动、搜索增强” 的技术方向，支持向量搜索、全文检索、混合检索以及 AI Functions 等核心能力
• 另一方面，它进一步补齐企业在数据安全、链路加密、漏洞治理和国产数据库接入上的基础能力，使平台在规模化生产落地时更加可靠、可控。

这一版本更适合对稳定性、合规性和运维可控性有更高要求的企业用户。

具体有哪些升级

整体来看，SelectDB Enterprise 4.0.5 的更新可以归纳为：

加速 AI 应用落地

首先，在能力层面，版本完整继承了 Doris 4.0.5 的全部能力，并延续其 AI + 搜索的整体方向，包括：

• 基于 ANN 的高维向量搜索
• 结构化过滤与向量相似度结合的一体化查询
• 基于 BM25 的文本相关性排序
• 通过 SQL 直接调用大模型，实现分类、抽取、摘要、翻译与语义匹配

这意味着，过去需要多套系统协作完成的流程（如检索 + 排序 + AI 推理），现在可以在同一个系统中统一完成。

构建企业级安全体系

数据层安全：透明数据加密（TDE）

• 支持对持久化数据进行透明加密
• 支持 AWS KMS 作为 Root Key 提供方
• 支持 AES256、SM4 等加密算法
• 支持主密钥轮转，满足审计与合规要求

文档

传输层安全：TLS 链路加密

• 支持统一 TLS 链路加密，覆盖 FE、BE 及节点间通信
• 支持 HTTP、MySQL、Thrift、BRPC、Arrow Flight 等协议
• 支持单向/双向 TLS、证书热更新与基于 SAN 的鉴权

文档

运行时安全：漏洞治理（CVE）

• 系统性修复已知漏洞
• 优化依赖组件安全基线
• 降低系统暴露面与安全运维压力

推进国产数据库适配

在生态能力方面，4.0.5 新增对达梦、GBase、Kingbase 等国产数据库的支持：

• 支持通过 JDBC Catalog 进行统一接入
• 支持联邦查询与跨源分析
• 支持数据迁移与湖仓一体架构

帮助企业在推进国产化替代过程中，实现对异构数据源的统一管理与平滑过渡。

带来的核心价值

这一版本带来的提升主要体现在以下几个方面：

更完善的安全与合规能力 通过 TDE 与 TLS 的组合，覆盖数据静态存储与传输链路两个核心安全面，满足企业在数据保护与审计合规方面的基础要求，适用于金融、政企、制造、互联网等行业。

更低的系统复杂度 在同一平台上统一承载结构化分析、全文检索、向量搜索与 AI 调用，减少多系统拼装带来的架构复杂度与运维成本。一个平台即可支持实时数仓、日志分析、经营报表以及多源联邦查询等场景，同时也适用于语义搜索、混合搜索、RAG 检索增强、智能推荐等 AI 应用落地。

更强的生产稳定性 通过漏洞修复、链路加密与企业级治理能力增强，显著提升系统在生产环境中的稳定性、安全性与长期可维护性。

更广的数据接入能力 通过 JDBC Catalog 扩展国产数据库支持，使企业能够更加顺畅地连接异构数据源，降低数据迁移与系统集成门槛，适用于推进国产数据库适配与存量系统整合的架构团队。

摘要：
2026年，外贸企业的真实困境是：传统获客方式（展会、B2B平台、邮件）集体失效，获客渠道割裂、无法形成合力，线索很难转化为实际订单，公域CRM暗藏风险……单一工具只能解决局部问题。真正的破局之道在于一站式获客——以私域独立站为流量阵地，通过谷歌、社媒、数据、EDM等全渠道精准触达，再借助私域CRM系统高效转化，形成从“找到客户”到“拿到订单”的完整闭环。本文以富通天下云平台为例，拆解这一闭环如何落地，并结合实战案例说明其可复用的方法论。

一、深层困境：外贸获客为何越来越难？

1.传统获客方式正在失效
展会：投入几万十几万，仍要面对客户一对多比价，且展会质量参差不齐，拿回一堆名片，跟进时大多石沉大海。
B2B平台：本质是公域流量池，客户一对多比价，价格内卷严重。僧多粥少，年费、广告费越来越贵。
邮件群发：缺乏精准数据支撑，打开率低、退信率高，还可能被标记为垃圾邮件。
社媒盲撞：每天加好友发消息，要么被封号，要么被拉黑，劳心费力却收效甚微。
2.渠道割裂，无法形成合力
即使你同时使用上述多种方式，数据也是割裂的：展会的名片存在Excel，社媒的私信躺在手机里，海关数据查到的公司名不知道联系人是谁，独立站有流量却不知道谁看了。每个渠道都在单打独斗，无法形成完整客户画像，难以持续培育客户。
3.有线索无订单，中间缺了转化链
很多企业并不缺线索，但为什么成交寥寥？因为从线索到订单，缺乏系统化的跟进和培育：业务员跟进靠记忆、客户信息散落在各处、不知道谁处于什么阶段、沉睡客户无人问津、潜在客户没有得到重点服务。
4.公域CRM暗藏风险
更隐蔽的陷阱在于客户管理工具本身，不少企业使用的是公域CRM。
公域CRM就是CRM厂商，实际上是B2B平台的子公司或投资入股的关联公司，公域CRM系统与B2B平台深度绑定和数据打通。外贸企业的客户数据会进入B2B平台的“公域客户池”。这意味着，外贸企业辛苦开发的客户，可能在不知不觉中被B2B平台推荐给竞争对手，导致同质化竞争加剧、老客户流失、利润率下降。市场上知名的公域CRM厂商主要是小满和孚盟，其中小满是阿里国际站全资收购的！孚盟是中国制造网投资入股的！
这四个困境叠加的结果就是：获客成本越来越高，订单转化率越来越低，客户资产还随时面临被稀释的风险。而一站式获客方案的价值，正是打通从“建站→引流→触达→培育→转化”的每一个环节，让获客从“碰运气”变成“系统工程”，同时将客户牢牢掌握在自己手中。

二、富通天下云平台：围绕获客闭环的一站式解决方案

富通天下云平台的设计逻辑，就是围绕上述困境，构建一套完整的私域获客作战体系。以下按获客流程拆解其核心功能：

第一步：私域独立站——自主搭建外贸营销获客主阵地

展会、B2B平台都是公域流量，私域独立站才能真正沉淀自己的客户。云平台提供实现零门槛建站，拖拽式操作、响应式模板、30分钟即可上线专业B2B官网；内置SEO运营系统，在网站结构、内容、关键词选取、布局、检测、评分等环节，做到了专业化、流程化、智能化，有效提升Google排名。
更重要的是，富通天下将私域独立站放在完整的营销体系中，无缝对接营销和管理系统，让流量得到最大化应用。

第二步：引流——全渠道数字化私域营销获客

除了自然流量，云平台还通过布谷鸟GoogleSEM营销、WhatsApp等社交营销、海关数据等数据营销、EDM营销，AiReach等数字化私域营销方式，为独立站源源不断地引来流量。
这些营销方式不是各自为战，所有触达记录、客户反馈自动汇入云平台数据库，形成完整的获客画像，让每一次营销都有的放矢。

第三步：转化沉淀——将流量转化为实际订单

获得线索后，客户管理是转化的关键环节。
传统Excel管理，信息分散、跟进混乱、人员流动易流失客户。公域CRM与B2B平台深度打通，企业的客户数据会进入平台的“公域客户池”，导致内卷加剧、利润下滑。
富通天下私域CRM不与任何B2B平台打通，客户数据100%归企业所有。覆盖邮件、审批、团队、客户、统计报表等高效管理功能，提升新客户转化率和老客户复购率。
最后，通过富通天下ERP，高效管理订单的生产采购、出运结汇，把控业务的每个环节与节点，形成完整闭环。

三、案例分析：九州羽翔使用富通天下云平台，月询盘高达160＋

九州羽翔使用富通天下云平台后，效果十分显著：
对比去年，页面收入从3.6万增长至8.6万，近乎翻倍；自然搜索关键词覆盖达到4000多个，外链数量突破2万条，各项数据增长迅速。这些数据增长直接带来了大量精准询盘，单月正式询盘加上留言、在线咨询等，合计就有160多个，且询盘精准度高，极大方便了业务员跟进转化。
这主要得益于云平台本身就是一套完整的数字化生态系统。前端有面向客户的私域独立站，后端配套SEO运营、大数据营销，再加上长期使用的CRM系统与私域营销手段，方方面面综合发力，才实现了良好的运营效果。
同时，九州羽翔公司自身也非常重视私域独立站运营，配备了专职运营人员，在富通专业的培训与引导下，持续开展网站优化和运营工作，双方共同努力达成了理想效果。

四、总结：一站式获客是2026年外贸增长的必选项

外贸获客早已过了“一招鲜”的时代。单一工具，无论是海关数据、社媒工具还是邮件群发软件，都只能解决获客链条上的一个环节，而真正的订单来自整个系统的协同：独立站吸引流量，多渠道精准触达，私域CRM持续培育、高效转化，专业ERP确保订单交付。
以富通天下云平台为例，其“私域独立站+数字化私域营销+外贸私域CRM+专业ERP”的四位一体架构，已经被6万家企业验证有效。无论你是想盘活存量客户、降低获客成本，还是突破流量瓶颈、提升转化率，这套闭环体系都能帮你系统化地赢取更多订单。

小T导读：中原油田作为中国石化的重要油气生产基地，其生产过程控制系统（PCS）是保障油田安全生产、优化运行的核心枢纽。为解决高并发写入性能瓶颈、高昂的存储成本、复杂的实时分析需求以及多业务数据孤岛等问题，项目组于 2023 年正式引入 TDengine TSDB 作为新一代数据底座。在本案例中，TDengine TSDB 作为 PCS 核心业务模块的时序数据库，并通过 taosX 工具，实现了从分公司到总部的数据实时同步。落地实践表明，升级改造后的系统已经成为一个高效、稳定、易扩展的统一数据平台，为中原油田的智能化建设奠定了坚实的数据基石。

业务痛点

随着物联网技术的普及和数字化转型的深入，PCS 系统接入的设备数量与数据种类呈指数级增长，海量的时序数据对原有基于 Oracle 构建的数据架构提出了严峻挑战。中原油田 PCS 项目涵盖采油、注水、储气库管理、管线监控等多个关键业务模块。全油田范围内布设有数以万计的传感器与智能设备，每秒产生数十多万条时序数据记录。

在原有技术架构下，我们的系统面临的核心痛点如下：

• 写入性能瓶颈：Oracle 数据库并非为高频时序数据写入设计，在面对大量并发插入请求时，I/O 压力巨大，经常出现写入延迟，甚至影响前端控制指令的下发。
• 存储成本高昂：关系型数据库对时序数据的压缩效率较低，导致存储空间占用巨大。为保存一定周期内的历史数据，需要不断扩容高端存储设备，硬件与维护成本居高不下。
• 实时分析能力不足：基于 Oracle 进行时间窗口聚合、设备间关联分析等操作，需要编写复杂的 SQL，执行效率低下，响应时间常在分钟级以上。
• 系统架构僵化：各业务模块（如 PCS 与储气库）数据独立存储，形成数据孤岛，难以进行跨业务的统一分析与价值挖掘。

这些痛点严重制约了油田数字化和智能化的进程，因此，选择一个专为时序数据设计的高性能数据库成为项目组的必然选择。

选择 TDengine TSDB

在项目选型初期，我们团队制定了明确的目标：新数据库必须具备极高的写入和查询性能、优异的数据压缩能力、对 SQL 标准的良好支持、高可用性与易于维护的集群架构，并能与现有物联网生态无缝集成。

经过严格的 POC 测试，TDengine TSDB 在以下方面展现出决定性优势：

• 性能碾压：在同等硬件条件下，TDengine TSDB 的写入吞吐量、查询速度更是有数量级的提升。
• 极致压缩：凭借其专为时序数据设计的存储结构，TDengine TSDB 的压缩比轻松达到 1:10 ，远超测试中的其他竞品。

• SQL 兼容性：团队原有的 SQL 技能可以轻松迁移，大大降低了开发和学习成本。同时，这也方便了像 ThingsBoard 这样的第三方工具直接通过标准 JDBC 连接进行数据查询。

• All in One 设计：TDengine TSDB 内置了消息队列、缓存和数据订阅等功能，无需再部署 Kafka/Redis 等额外组件，简化了系统架构，降低了运维复杂度。
• 企业级特性：企业版提供的多级存储功能，可以将冷数据自动迁移至更廉价的对象存储，进一步优化成本，这与项目长期数据保存的需求完美契合。

业务落地实践

系统架构

新架构中，我们采用了云边协同架构，TDengine TSDB 作为核心数据持久层与计算引擎贯穿始终。

业务模块与收益

数据写入与实时处理模块

针对不同业务我们采用“双轨制”写入策略。对于结构灵活多变的储气库等业务数据，我们利用 TDengine TSDB 的 Schemaless 接口，数据库自动建表，极大简化了数据接入流程。对于结构稳定、逻辑复杂的核心 PCS 业务数据，则采用传统拼装 SQL 的方式写入，确保精确控制与高性能。

在数据接入层，油田现场的各类设备通过 MQTT 或 HTTP 协议，将数据上报至 ThingsBoard 物联网平台。对于数据结构多变、灵活的储气库业务，采用 TDengine TSDB 的 Schemaless 写入接口，ThingsBoard 可直接写入数据，TDengine TSDB 自动建表，极大提升了开发效率。

核心收益——

• 写入性能飞跃：TDengine TSDB 专为时序数据优化的写入引擎彻底解决了 Oracle 面临的 I/O 瓶颈。系统轻松应对每秒数十万条数据的并发写入，延迟从秒级降至毫秒级，保障了生产监控数据的实时性与控制指令的及时性。

• 开发效率提升：Schemaless 写入模式在应对业务字段变更和新型设备接入时，无需频繁修改数据库表结构，后端代码也无需调整，实现了“数据即接即用”，开发效率提升超过 60%。ThingsBoard 通过内置的 JDBC 连接器，将解析后的数据持久化到 3 节点 TDengine TSDB 高可用集群中。同时，核心的 PCS 业务模块，因其数据结构稳定且业务逻辑复杂，仍采用拼装标准 SQL 的方式直接向 TDengine TSDB 写入数据。这种“Schemaless + SQL”的双轨写入模式，兼顾了灵活性与复杂性。

  

• 架构简化：TDengine TSDB 内置的类消息队列能力，替代了部分原先需要 Kafka 等中间件实现的缓冲与削峰填谷场景，减少了系统组件依赖，降低了架构复杂度和运维成本。

数据同步与分发模块

为了满足总部对全局数据的分析需求，项目使用 TDengine TSDB 企业版提供的 taosX 数据同步工具，将油田生产区的指定数据表/超级表，实时、可靠地同步到总部数据平台的 TDengine TSDB 集群中，实现了数据的跨地域统一。在数据库管理 web 后台页面图形化界面即可配置数据实时同步任务。

核心收益——

• 实现数据汇聚与统一：轻松构建了“边缘-中心”两级数据体系，解决了总部全局数据分析需求与分公司数据本地化处理需求之间的矛盾。
• 同步过程可靠高效：taosX 工具保障了数据同步的可靠性和一致性，且对源集群性能影响极小。总部可实时获取全域数据视图，为高层战略分析和跨区域对标提供了数据基础。

数据查询与分析模块

业务应用、实时大屏和数据分析系统可直接通过标准 SQL（或 REST API/JDBC）访问 TDengine TSDB。这样一来，我们可以充分利用原生函数，进行高效聚合、插值、降采样等操作。利用“超级表”模型，轻松实现跨设备、跨区域的统一查询分析。

在数据应用层，业务应用、实时大屏、告警分析引擎均直接连接油田侧的 TDengine TSDB 集群，利用其强大的即时计算能力，进行数据查询与分析。

核心收益——

• 查询性能指数级提升：典型查询场景性能对比显著。例如，“查询某注水站过去一小时每分钟的平均压力”这类时间窗口聚合查询。
• 打破数据孤岛：基于“超级表”概念，将不同采油厂、不同业务线（如采油、注水）的同类型设备（如泵机）数据模型统一，实现了跨业务、跨区域的全局数据关联分析，为生产协同优化提供了可能。
• 实时分析能力增强：毫秒级的查询响应使得基于实时数据的监控大屏、即时决策和交互式分析成为现实，显著提升了生产调度和应急指挥的时效性。

数据存储与压缩模块

TDengine TSDB 针对时序数据特性，采用列式存储与专用压缩算法，实现海量测点数据的高效写入与存储，在显著降低空间占用的同时也提升了查询性能。

核心收益——

• 存储成本大幅降低：在实际业务中，我们发现数据压缩效果显著，压缩比普遍超过 1:10。原需约 50TB 原始空间的数据，在单副本存储下仅占用约 4.2TB；结合多级存储策略，长期数据保存的整体存储成本下降超过 85%。
• 存储管理自动化：多级存储策略实现了数据生命周期的自动化管理，无需人工干预数据归档，在保证历史数据可查询的同时，释放了昂贵的高性能主存储空间。

未来规划

TDengine TSDB 在中原油田 PCS 项目的成功，是油田数字化转型的一个开端。接下来我们计划针对以下几点进行进一步研究与合作：

1. 深度分析：探索利用 TDengine TSDB 与机器学习框架的结合，对海量历史时序数据进行深度挖掘，实现设备预测性维护、工艺参数优化等高级应用。
2. 边缘计算融合：研究 TDengine TSDB 在边缘侧的部署，在数据产生源头进行初步的过滤和聚合
3. 持续关注：团队将持续关注 TDengine TSDB 的发展，积极测试新版本、新功能，如流计算引擎的进一步增强，以期在现有平台上创造更大的业务价值。

关于中原油田

中原油田是中国石油化工集团有限公司的重要上游企业，世界 500 强中石化旗下第二大油气田。其拥有总矿权面积 15405.164 平方千米，石油资源量 20.88 亿吨、天然气资源量 18451.02 亿立方米，探明石油地质储量 6.258 亿吨、天然气地质储量 4833.36 亿立方米；取得省部级以上科技进步奖 380 项、国家级科技进步奖 36 项、国家专利 765 件，其中“特大型超深高含硫气田安全高效开发技术及工业化应用”项目荣获 2012 年度国家科技进步特等奖；获得全国“五一”劳动奖状、中央企业先进基层党组织、中国石化绿色企业等多项荣誉，连续六届被评为全国文明单位。

作者

王欣怡

PDF 线性化（也称为 “Fast Web View”，快速网页查看）是一种对 PDF 文件进行优化的方式。通常情况下，在浏览器从服务器下载完整个多页 PDF 文件之前，用户无法在线查看其内容。而当 PDF 被线性化处理后，即使文件尚未完全下载，浏览器也可以优先快速显示第一页，从而提升加载和浏览体验。

本文将介绍如何使用C#代码将普通 PDF 转换为线性化 PDF。

环境准备

在开始操作之前，需要先完成开发环境的基础配置，确保项目能够正常使用 PDF 相关功能。

你可以通过以下方式引入所需的库：

• 通过 NuGet 安装（推荐）：在 Visual Studio 中打开 NuGet 包管理器，搜索并安装对应的 PDF 处理库，即可自动完成依赖配置。
• 手动添加引用：下载相关组件包后，将其中的 DLL 文件添加到项目引用中。

完成以上配置后，即可在项目中调用相关 API 进行 PDF 线性化处理。这里我们以Spire.PDF for .NET为例：

PM> Install-Package Spire.PDF

将 PDF 转换为线性化格式

下面是将普通 PDF 文件转换为线性化 PDF 的基本步骤：

1. 使用 PdfToLinearizedPdfConverter 类加载需要处理的 PDF 文件。
2. 调用 ToLinearizedPdf() 方法，将文件转换为线性化格式。

参考示例代码如下：

using Spire.Pdf.Conversion;

namespace ConvertPdfToLinearized
{
    class Program
    {
        static void Main(string[] args)
        {
            // 加载 PDF 文件
            PdfToLinearizedPdfConverter converter = new PdfToLinearizedPdfConverter("Sample.pdf");
            // 将文件转换为线性化 PDF
            converter.ToLinearizedPdf("Linearized.pdf");
        }
    }
}

转换完成后，可以在 Adobe Acrobat 中打开生成的结果文件，并查看文档属性，可以看到 “Fast Web View（快速网页查看）” 的值为 Yes，这表示该文件已经完成线性化处理。

结语

通过以上内容，你可以轻松实现将普通 PDF 转换为线性化格式，从而显著提升文档在网页端的加载速度和用户浏览体验。对于需要在线预览或分发 PDF 文件的应用场景来说，这一优化尤其重要。

在实际项目中，只需完成基础环境配置并调用相应方法，即可快速集成该功能。你可以根据业务需求，将其应用到文档管理、在线阅读或文件传输等场景中，进一步提升整体性能和用户体验。

在开发跨境金融、汇率看板、多币种结算系统时，统一、实时、稳定的汇率数据源是整个系统的核心。
传统多接口轮询方案存在格式混乱、延迟高、维护成本高等问题，本文提供的 WebSocket 接口，分享一套可直接落地的多币种汇率订阅方案，简洁、可靠、适合生产环境。

一、传统汇率获取方式的痛点

在实际开发中，常规方案会遇到明显瓶颈：

• 单接口仅支持单币种，多币种需多次请求，效率低
• 不同接口返回结构不统一，数据整合成本高
• REST 轮询延迟大、资源占用高，无法满足实时性要求
• 无重连机制，网络波动易造成数据中断
• 难以支撑 7×24 小时稳定运行
  这些问题直接影响系统稳定性与数据准确性。

二、技术方案：WebSocket 实时推送

相比轮询，WebSocket 长连接更适合实时汇率场景：

1. 数据变动主动推送，延迟极低
2. 一次鉴权、一次订阅，长期维持连接
3. 支持批量币种订阅，返回格式统一
4. 便于实现断线重连，提升可用性
   提供标准化多币种实时汇率接口，接入简单、稳定性强，是后端与金融场景的高效选择。

三、核心功能与优势

多币种批量订阅
一次订阅即可同时获取 USDCNY、EURCNY、JPYUSD、GBPUSD 等主流汇率。
统一数据结构
所有币种返回格式一致，无需额外适配。
实时低延迟
汇率变动秒级推送，远优于定时拉取。
高可用
支持断线重连与自动重订阅，保证数据不间断。

四、精简可运行代码（一段即用）

import json
import websocket

WS_URL = "wss://api.alltick.co/realtime"

def on_message(ws, msg):
    data = json.loads(msg)

def on_open(ws):
    ws.send(json.dumps({
        "action": "subscribe",
        "symbols": ["USDCNY", "EURCNY", "JPYUSD", "GBPUSD"]
    }))

if __name__ == "__main__":
    ws = websocket.WebSocketApp(WS_URL, on_open=on_open, on_message=on_message)
    ws.run_forever()

五、工程化最佳实践

1. 将最新汇率存入内存字典或 Redis，支持全局快速读取
2. 增加断线自动重连机制，确保链路高可用
3. 只订阅业务需要的币种，减少无效数据与带宽消耗
4. 增加日志记录，便于追踪连接状态与异常
5. 使用 systemd 或进程托管工具，实现服务自启动

六、总结

多币种实时汇率接入，关键在于统一数据源 + 长连接推送。
可实现一次订阅、多币种同步、低延迟、高稳定，大幅降低开发与维护成本。
这套方案可直接用于汇率工具、跨境系统、行情看板、量化策略等场景，是后端工程化落地的实用方案。

​项目介绍：​这是一个面向投标/评标场景的结构化抽取工具。支持上传 PDF、Word 或 Excel 格式的招标文件，自动提取项目基础信息、投标资格、技术与商务要求、评标办法等关键条款，并还原目录层级与跨页表格。输出结构化 JSON/Excel，适用于招标文件智能生成、AI 辅助评标及招投标知识库建设。

​GitHub 项目地址：​https://github.com/intsig-textin/xparse-sample-projects

接下来我们主要讨论一件事：如果目标是从一份很长的招标文件里稳定产出结构化结果，系统应该怎么搭。重点不是场景背景，而是中间层怎么定义、任务怎么拆、Prompt 为什么这样写。

一、先把目标定义清楚

如果只是让大模型“总结一份招标文件”，实现并不难；难的是把一份上百页的长文档稳定拆成可展示、可复用、可继续治理的结构化结果。

这类工具真正要完成的是下面这条链路：

• 上传 PDF 招标文件
• 调用 TextIn 把原始文件转成 markdown + pages
• 按标题把长文档切成多个语义片段
• 把片段路由到基础信息、资格要求、评审办法、投标递交、无效标风险、附件格式 6 个模块
• 每个模块单独调用大模型，输出固定 JSON
• 前端直接按模块渲染，后续也可以继续导出或复用

所以这里的核心不是“抽字段”三个字，而是先把长文档抽取问题拆成多个边界明确的小任务。

二、架构应该怎么拆

如果目标是长文档结构化，推荐把链路拆成四层：

这四层分别解决不同问题：

• 解析层：把 PDF 变成后续可计算的中间结构
• 编排层：把长文档拆成多个上下文更小的任务
• 抽取层：让每个模块只输出自己负责的 schema
• 展示层：按模块 JSON 渲染，而不是再做一次自由解析

三、先把解析层的输入输出定义对

这里最容易写错。真正调用的不是 form-data 接口，而是 TextIn 的二进制流解析接口：

POST https://api.textin.com/ai/service/v1/pdf_to_markdown

请求头和请求体在代码里是这样组织的：

headers = {
    "x-ti-app-id": TEXTIN_APP_ID,
    "x-ti-secret-code": TEXTIN_SECRET_CODE,
    "Content-Type": "application/octet-stream",
}

params = {
    "parse_mode": "auto",
    "page_count": 200,
    "dpi": 144,
    "table_flavor": "html",
    "apply_document_tree": 1,
    "markdown_details": 1,
    "page_details": 1,
    "apply_merge": 1,
    "paratext_mode": "none",
}

resp = await client.post(
    "https://api.textin.com/ai/service/v1/pdf_to_markdown",
    headers=headers,
    params=params,
    content=file_bytes,
)

这里的关键点只有两个：

• 返回值里最重要的是 result.markdown

可以把它理解成下面这个输入输出契约：

输入：

Headers:
- x-ti-app-id
- x-ti-secret-code
- Content-Type: application/octet-stream

Query:
- parse_mode=auto
- page_count=200
- dpi=144
- table_flavor=html
- apply_document_tree=1
- markdown_details=1
- page_details=1
- apply_merge=1
- paratext_mode=none

Body:
- PDF 文件的原始字节流

输出：

{
  "code": 200,
  "result": {
    "markdown": "# 第一章 招标公告\n...",
    "pages": []
  }
}

如果你做的是 Web 工具，通常会在本地后端再包一层 /api/parse 方便浏览器上传和鉴权隔离；但那只是工程封装，不是上游解析接口本身的协议。

四、为什么中间层必须是\`markdown+pages\`

这一步决定了后面能不能把长文档拆稳。

markdown 的价值在于：

• 保留标题层级
• 保留段落结构
• 表格可以以 HTML 或 Markdown 形式继续消费
• 便于按标题、按章节做切块

pages 的价值在于：

• 保留分页语义
• 为页面预览、页码回跳、证据定位留接口
• 后续如果要做高亮溯源，不需要重新回到 PDF 二进制层

也就是说，解析完成之后，整个系统处理的对象就不再是 PDF，而是 markdown+pages 这个统一中间层。

五、长文档不要全文直抽，先按标题切块

招标文件最难的地方不是字段多，而是篇幅长、章节多、不同章节关心的问题完全不同。如果直接把全文塞给一个总 Prompt，结果很难稳。

更合理的做法是先按标题切块。代码里的切块入口就是：

function parseMarkdownToChunks(md: string): Chunk[] {
  const lines = md.split('\n');
  const headerMatch = line.match(/^#{1,2}\s+(.*)/);
}

这一步做的不是“抽取”，而是把文档转成一批更短、更聚焦的 chunk。

切完之后，再按关键词做模块路由，例如：

const MODULE_KEYWORDS = {
  basic: ['招标公告', '项目概况', '联系方式'],
  qualification: ['资格', '资质', '财务', '联合体'],
  evaluation: ['评标', '评审', '评分', '分值'],
  submission: ['投标文件', '递交', '开标', '保证金'],
  invalid_risk: ['无效标', '否决', '废标条款'],
  annex: ['附件', '格式', '表单', '清单'],
};

这样设计有三个直接收益：

• 每次发给模型的上下文更短，稳定性更高
• 每个模块只关注自己的问题，不互相干扰
• 后续新增模块时，只需要新增路由和 Prompt，不需要推翻整套架构

六、Prompt 不是“让模型抽字段”，而是定义模块契约

这里最值得学的不是“用了大模型”，而是 Prompt 把输入输出边界写得很死。

以 basic_prompt.txt 为例，开头先把约束写清楚：

你是一个“招投标文件基础信息（basic）抽取器”。
你的任务：仅抽取【基础信息 basic】模块，并输出严格合法的 JSON。

【核心硬性原则：禁止捏造】
1) 你只能从输入的 Markdown 原文中抽取信息。
2) 如果原文没有明确出现某字段：该字段 value 必须为 "" 或 null。
6) 【溯源原子性原则——最高优先级】
- 每个 value 必须来自原文中一处连续段落/句子的逐字摘录。

接着把输出骨架固定下来：

{
  "module_key": "basic",
  "module_name": "基础信息",
  "sections": {
    "bidder_agency": { "title": "招标人/代理信息", "blocks": [] },
    "project_info": { "title": "项目信息", "blocks": [] },
    "key_time_content": { "title": "关键时间/内容", "blocks": [] },
    "bid_bond_related": { "title": "保证金相关", "blocks": [] },
    "other_info": { "title": "其他信息", "blocks": [] },
    "procurement_requirements": { "title": "采购要求", "blocks": [] }
  },
  "missing_fields": [],
  "warnings": []
}

为什么要这么写，而不是只写一句“请抽取基础信息”？

原因很实际：

• module_key 固定，前端才能知道这是哪个模块
• sections 固定，页面才能直接按 section 渲染
• missing_fields 固定，后续才能做缺失项提示
• warnings 固定，后续才能挂冲突说明或风险提醒

Prompt 里还进一步把 block 限定为 table / kv / list / text 四种。这个设计很关键，因为招标文件天然是半结构化文档，不同信息的最佳表达形式并不一样。

例如：

• 联系方式更像 table
• 项目编号、预算金额更像 kv
• 公告媒介、平台地址更像 list
• 开标说明、答疑说明更像 text

这比把所有字段强行压成同一种平铺结构更稳。

七、输入、Prompt、输出必须一一对应

要让这套架构可维护，至少要把三件事先对齐：

1. 模块输入是什么

输入不是全文，而是某个模块命中的 Markdown 片段。前端会把命中的 chunk 重新拼成模块输入：

moduleData[key].markdown += `\n\n### ${c.title_path}\n` + c.content;

所以传给 qualification 模块的，并不是整份标书，而是“资格要求相关片段”。

2. Prompt 定义什么结构

以资格要求模块为例，Prompt 直接固定了三个 section：

{
  "module_key": "qualification",
  "sections": {
    "applicant_requirements": { "title": "申请人资格要求", "blocks": [] },
    "eligibility_review": { "title": "资格性审查", "blocks": [] },
    "compliance_review": { "title": "符合性审查", "blocks": [] }
  }
}

这意味着这个模块的职责只有三件事，不会在一次抽取里又去掺杂评标办法或附件格式。

3. 前端按什么结构展示

前端模块配置也会定义同样的 section key。这样一来，页面渲染不需要再猜字段，只要按约定好的 key 读取结果即可。

也就是说，这里不是“先让模型自由返回，再想办法接结果”，而是先把输入范围、Prompt schema、页面结构统一好，再让模型往固定壳子里填内容。

八、和传统做法相比，差别在哪里

如果目标是做工程化工具，而不是做一次性演示，这套方案和传统方式有两个本质区别。

1. 不是 OCR 文本加正则硬提

纯文本加正则在字段非常固定时还可以用，但招标文件章节名称、段落顺序、表格表达方式都经常变化，规则一旦堆多，维护成本会非常高。

2. 不是全文加一个总 Prompt

全文单 Prompt 很适合快速做一个效果展示，但它很难同时解决下面几个问题：

• 模块边界不清
• 输出结构不稳定
• 某个模块要扩字段时会牵一发动全身
• 很难做稳定展示和后续治理

更稳定的方式是：

• 先解析成结构化中间层
• 再切块
• 再按模块分别抽取
• 最后按模块 JSON 聚合

Lab4AI大模型实验室是面向AI开发者、科研党与学习者打造的一站式AI实践平台，深度绑定高性能弹性算力，支持模型复现、训练、推理全流程，以按需计费、低价高效破解高端算力紧缺与成本高昂难题；同步Arxiv前沿论文并提供翻译、导读、分析服务，支持各类大模型一键复现与数据集微调，对接孵化资源助力科研成果转化；同时搭载多样化AI在线课程，实现理论学习与代码实操同步推进，全方位覆盖AI研发、科研创新与技能学习全场景需求。

大模型实验室官网链接： https://www.lab4ai.cn/arxiv?utm_source=sf_daily_paper

作者信息

德克萨斯农工大学

研究背景

1. RAG技术现状：检索增强生成（RAG）通过外部检索知识增强大语言模型生成效果，早期以非结构化文本检索为主，后续引入图结构知识表示提升推理与事实一致性。
2. 传统图RAG局限：普通知识图仅能表示二元关系，无法建模多实体高阶交互，易造成信息丢失与推理碎片化。
3. 超图RAG不足：现有超图RAG将超边视为静态事实，检索时不考虑交互顺序与演化过程，属于排列不变性检索，无法适配依赖时序、因果与过程的推理任务。
4. 现实任务需求：热带气旋、港口运营等场景的推理结果，不仅依赖交互内容，更依赖交互发生的顺序，现有方法无法满足该类顺序敏感型任务。

研究目的

1. 打破现有RAG将检索证据视为无序集合的核心假设，解决排列不变性检索与顺序敏感型推理任务不匹配的问题。
2. 提出将顺序作为核心结构属性的超图RAG框架，实现对知识高阶交互与交互时序的统一建模。
3. 将检索从“独立事实选择”重构为“连贯交互轨迹推理”，让大模型能够基于有序证据链完成过程化、因果化推理。
4. 在热带气旋-港口影响评估等领域任务中，验证顺序感知超图检索对生成质量与推理准确性的提升效果。

本文核心贡献

1. 提出顺序感知知识超图表示：将高阶交互与优先顺序结构融合，突破传统超图仅建模静态关系的局限，完整保留知识的时序与逻辑顺序。
2. 重构检索范式：将传统集合式检索改为超边上的轨迹推理，显式建模证据序列的重要性，而非仅关注检索内容相关性。
3. 无显式时序监督的顺序学习：设计可学习的转移模型，从数据中自动学习超边间的优先关系，无需人工标注时序信息。
4. 验证顺序核心价值：通过实验证明，检索证据的排列顺序直接决定推理质量，顺序感知设计是性能提升的关键因素。

研究方法

1. 顺序感知知识超图构建与顺序学习

• 知识超图构建：以实体为节点、超边为高阶交互单元，通过大模型进行N元关系抽取，保留多实体依赖的完整语义。
• 实体类型划分：分为持久对象（港口、气旋）、瞬时状态（气旋等级）、时间锚点（T-48）三类，支撑时序与结构建模。
• 优先顺序学习：采用双线性转移模型Pθ(ej|ei)，通过对比损失自监督学习，利用文档顺序、实体重叠、检索偏好三类信号训练，无需显式时序标注。

2. 顺序感知超图检索

• 检索目标：最大化相关性+顺序连贯性+优先一致性+实体连续性+阶段覆盖度，获取最优有序超边轨迹。
• 推理算法：采用束搜索（Beam Search）生成有序轨迹，小候选集使用维特比动态规划精确优化。
• 多轨迹检索：返回多条多样化轨迹，为生成提供多路径解释与互补证据。

3. 检索增强生成

• 将检索到的有序轨迹以带步骤索引、时间标签、阶段标注的结构化形式输入生成器，避免扁平化拼接丢失顺序信息。
• 支持单提示多轨迹交叉参考与置信度加权聚合两种生成模式，保障生成的事实准确性与推理逻辑性。

4. 实验设计

• 数据集：CyPortQA（热带气旋-港口运营QA基准，2917个场景、117178个问题）。
• 基线方法：Text-RAG、GraphRAG、HyperGraphRAG。
• 评估指标：判断题/选择题精确匹配、简答题容差精度、描述题LLM语义评分。
• 消融实验：打乱顺序、移除顺序相关模块、对比无顺序/启发式顺序/学习顺序。

研究结果

1. 整体性能最优：OKH-RAG在四类问题（TF/MC/SA/TD）及整体准确率上均超过所有基线，整体准确率达0.534，高于HyperGraphRAG的0.511。
2. 顺序是核心增益源：将OKH-RAG检索结果打乱顺序后，整体准确率从0.534降至0.487，降幅最大，证明顺序对推理至关重要。
3. 模块有效性：优先一致性、阶段覆盖、实体连续性、顺序连贯性均对性能有正向贡献，其中优先一致性与阶段覆盖影响最显著。
4. 学习顺序最优：性能排序为学习顺序 > 启发式顺序 > 无顺序，验证可学习转移模型优于固定规则。
5. 任务自适应：跨时间推理任务优先跨阶段轨迹，单阶段事实任务聚焦局部紧凑轨迹，适配不同查询的推理需求。

总结与展望

本研究推翻了RAG领域“检索证据可视为无序集合”的核心假设，提出OKH-RAG框架，将顺序作为核心结构属性融入超图RAG，实现高阶知识交互与时序关系的统一建模。实验证明，在顺序敏感的领域推理任务中，证据的组织顺序与内容本身同等重要，顺序感知轨迹检索可显著提升大模型的推理准确性与事实一致性。

展望

1. 可将该框架拓展至科学发现、临床诊断、工程故障分析等更多顺序依赖型领域。
2. 进一步优化顺序学习与轨迹检索算法，提升大规模知识图谱上的效率与可扩展性。
3. 结合动态知识更新，实现实时时序知识的顺序感知检索与生成。
4. 探索多模态知识（文本、图像、数值）的顺序感知超图建模，适配多模态复杂推理任务。

就在刚才，Anthropic 又一声不响地把 Claude 4.7 给放出来了。

说实话，我当时正在那调优我的 Claude Code 脚本，调得我焦头烂额，结果页面一刷，Opus 4.7 的文档就这么硬生生地怼到了我脸上。

这次更新，很多媒体可能又在炒作什么 100 万上下文，或者什么 3.75MP 的高清视觉。

但在我看来，那些都不是最重要的。

最让我脊背发凉的，是 Claude 终于学会了「省钱」，而且还学会了「自我怀疑」。

我不知道屏幕前的你有没有这种感觉，现在的 AI 越来越像一个职场老油条。

以前的 AI，你给它个任务，它要么秒回，要么就在那傻呆呆地思考三分钟，然后给你出一堆废话。

但这次 Claude 4.7 搞了个新玩意，叫「Adaptive Thinking」，翻译过来就是自适应思考。

这个功能太骚了。

它不再是像以前那种死板的思考模式，而是会根据你任务的难易程度，自己决定到底要思考多久。

如果是简单的活，它咔咔两下就干完了。

如果是那种要改几十个文件的、涉及长链代理的复杂代码任务，它会自己开启一个叫「xhigh」的最高努力模式，在那疯狂推理。

关键点来了。

它还配了一个叫「Task Budget」的任务预算功能。

这玩意目前还在 beta 阶段，但它的逻辑非常牛逼，你可以给 AI 设定一个「Token 预算」。

以前咱们用 Agent，最怕的就是这货在那死循环，一觉醒来，几百美金的额度全被它烧光了。

现在的 Claude 4.7，它干活的时候会自己盯着自己的「钱包」。

如果快超支了，它会停下来问你，或者自己调整策略，看能不能用更省钱的方式把活干完。

真的，看到这我直接愣住了。

这哪里是 AI 啊，这特么分明就是一个懂财务、懂成本控制的高级项目经理。

而且，这次它的「自我纠错」能力简直拉满了。

以前 AI 报错了，你得去修它。

现在是它写完一段代码，自己先跑一遍，发现不对，自己在那默默地改。

这种「老子自己能搞定」的自信，对于我们这些天天跟 Agent 打交道的人来说，真的是救了老命了。

除了这个，这次的视觉能力提升也挺离谱。

分辨率直接翻了 3 倍，而且搞了个「1:1 像素坐标映射」。

听着挺学术对吧，其实换成人话讲，就是它看东西更准了。

以前它看一张复杂的网页截图，可能知道按钮在哪，但点的时候总感觉差了那么几像素，像个老花眼。

现在有了 1:1 映射，它能精准定位到每一个像素点。

这意味着什么，你想想看。

这意味着它以后操控你的电脑，或者作为 GUI Agent 去帮你订票、买东西，基本上不会再有点错位置这种低级错误了。

最骚的是什么？

是这么多升级，价格居然一分钱没涨。

API 已经上线了，大家可以直接开整。

我有时候觉得，我们真的生活在一个巨大的转折点上。

以前我们聊 AI，聊的都是「它能写什么」。

现在我们聊 AI，聊的是「它能替我们在这个物理世界里完成什么」。

这不是什么生产力的微调，这是生产关系的重构。

当 AI 像一个有血有肉的人一样，开始思考效率、思考成本、思考精准度的时候，作为普通人的我们，到底该站在哪里？

反正我觉得，与其担心被取代，不如先去上手试试这个「会算计」的 Claude 4.7。

毕竟，能教一个 AI 帮你省钱，这种感觉还是挺爽的。

哦对了，虽然这次 4.7 很猛。

但我听说，那个代号叫「Mythos」的庞然大物，还在 Anthropic 的实验室后面等着呢。

大时代啊，朋友们。

我们，还是得保持好奇心。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

/ 作者：文浩 / Web：wenhaofree.com

原文链接：https://mp.weixin.qq.com/s/f-MnUqgu1MNUSGxvCGIzMw