前端开发这几年,localStorage 和 sessionStorage 用得最多,cookie 偶尔也要打打交道。但说到 IndexedDB,很多人的反应是:“听说过,但没用过。”

今天聊聊这个被低估的浏览器内置数据库。

一、为什么需要另一个存储方案?

先看个实际场景。朋友公司做电商后台,产品经理要求:“能不能在列表页缓存 5000 条商品数据,让筛选和搜索快一点?”

第一版用 localStorage:

// 存储
localStorage.setItem('products', JSON.stringify(products)) // 5000条数据,页面卡了2秒

// 搜索
const keyword = '手机'
const allProducts = JSON.parse(localStorage.getItem('products')) // 又卡1秒
const results = allProducts.filter(p => p.name.includes(keyword)) // 遍历5000次

上线后用户反馈:“筛选时浏览器像卡住了一样。”

问题在哪?localStorage 有硬伤:

  • 同步操作,数据量大就阻塞页面
  • 只能存字符串,对象要序列化
  • 容量小(通常 5-10MB)
  • 只能全量读取,无法高效查询

二、IndexedDB 是什么?

简单说,它是浏览器里的 NoSQL 数据库。2011 年就出现了,但很多人不知道或觉得“用不上”。

几个关键特点:

  1. 容量大:通常能占硬盘 50%,几个 GB 没问题
  2. 异步操作:不卡页面
  3. 支持索引:查询速度快
  4. 能存多种类型:对象、文件、二进制数据都行

三、一个简单示例

如果你没用过,先看看基本用法:

// 1. 打开数据库
const request = indexedDB.open('myDB', 1)

// 2. 创建表结构(第一次或升级时)
request.onupgradeneeded = function(event) {
  const db = event.target.result
  
  // 创建对象存储(类似表)
  const store = db.createObjectStore('products', {
    keyPath: 'id',      // 主键
    autoIncrement: true // 自动生成ID
  })
  
  // 创建索引(加速查询的关键)
  store.createIndex('name', 'name')      // 按名称查
  store.createIndex('price', 'price')    // 按价格查
  store.createIndex('category', 'category') // 按分类查
}

// 3. 数据库就绪
request.onsuccess = function(event) {
  const db = event.target.result
  console.log('数据库已就绪')
}

四、核心优势:查询性能

这是 IndexedDB 真正厉害的地方。同样的 5000 条商品数据,查询完全不同:

// 用索引查,不需要遍历所有数据
async function searchProducts(keyword) {
  const transaction = db.transaction(['products'], 'readonly')
  const store = transaction.objectStore('products')
  const index = store.index('name') // 使用索引
  
  // 只搜索相关范围
  const range = IDBKeyRange.bound(keyword, keyword + '\uffff')
  const request = index.openCursor(range)
  
  return new Promise((resolve) => {
    const results = []
    request.onsuccess = function(event) {
      const cursor = event.target.result
      if (cursor) {
        results.push(cursor.value)
        cursor.continue() // 继续下一个
      } else {
        resolve(results) // 搜索完成
      }
    }
  })
}

// 毫秒级响应,不卡页面
const results = await searchProducts('手机')

你可以创建多个索引,实现各种复杂查询:

  • 价格区间筛选
  • 多条件组合查询
  • 分类统计
  • 模糊搜索

五、适用场景

什么情况下该考虑 IndexedDB?

1. 离线应用

邮件客户端、文档编辑器、笔记应用。数据先存本地,有网再同步。

2. 大数据缓存

电商商品目录、大量配置项、历史数据。替代接口频繁请求。

3. 文件管理

图片、PDF、音视频的本地缓存。不用每次都下载。

4. 游戏数据

存档、配置、资源文件。支持离线游戏。

5. 分析数据

收集用户行为,批量上传。避免频繁网络请求。

六、实用建议

1. 用封装库简化开发

原生 API 确实有点繁琐。推荐这些库:

// 用 idb 库(推荐)
import { openDB } from 'idb'

const db = await openDB('my-db', 1, {
  upgrade(db) {
    db.createObjectStore('products')
  }
})

// 操作简单多了
await db.add('products', { name: '商品1', price: 100 })
const products = await db.getAll('products')

2. 渐进增强

先判断支持性,不支持就降级:

function getStorage() {
  if ('indexedDB' in window) {
    return {
      type: 'indexedDB',
      save: saveToIndexedDB,
      load: loadFromIndexedDB
    }
  } else {
    console.log('降级到 localStorage')
    return {
      type: 'localStorage',
      save: saveToLocalStorage,
      load: loadFromLocalStorage
    }
  }
}

3. 注意版本迁移

修改表结构需要升级版本:

const request = indexedDB.open('myDB', 2) // 版本号+1

request.onupgradeneeded = function(event) {
  const db = event.target.result
  const oldVersion = event.oldVersion
  
  if (oldVersion < 1) {
    // 初始版本逻辑
  }
  
  if (oldVersion < 2) {
    // 版本2的升级逻辑
    // 比如添加新索引
    const store = event.currentTarget.transaction.objectStore('products')
    store.createIndex('createdAt', 'createdAt')
  }
}

七、什么时候不用?

IndexedDB 虽好,但也不是万能:

  • 存个用户 token → 用 localStorage 或 cookie
  • 会话级临时数据 → 用 sessionStorage
  • 简单配置项 → localStorage 更方便
  • 需要服务端读取 → cookie

记住:技术选型要看具体需求,不是越高级越好。

八、开始尝试

如果你从没用过 IndexedDB,可以从这些开始:

  1. 缓存接口数据:把频繁请求的 API 结果缓存起来
  2. 离线收藏功能:用户收藏的内容存本地
  3. 图片懒加载缓存:看过的图片存起来
  4. 表单草稿:复杂的表单数据实时保存

不需要一开始就大动干戈。找个合适的场景,先试试水。

写在最后

IndexedDB 在前端领域存在感不强,可能因为它解决的问题不是每个项目都会遇到。但当你真的需要处理大量客户端数据时,它会是个很好的选择。

技术没有绝对的好坏,只有合适与否。知道它的存在,了解它的能力,当合适的需求出现时,你就能做出更好的选择。


看完有点兴趣了?可以在个人项目里试试 IndexedDB,遇到问题欢迎交流。如果你已经在用,有什么经验或踩坑故事?评论区聊聊。

本文由mdnice多平台发布

前言

在大家反馈与测试下,最近花了很多时间和精力已经把我的日志分析工具迭代到 V1.6.12 版本了,加了不少新功能,修复了很多问题,同时也对页面样式细节做了很多调整。

目前也算是趋于稳定了,29 天前这个工具刚做出来的时候还只支持 nginx 的日志解析支持,现在已经支持了:

  • caddy 、IIS 、Apache httpd 、HAProxy 、Traefik 、Envoy 、Tengine 、Nginx Proxy Manager
  • NGINX Ingress Controller 、Traefik Ingress 、HAProxy Ingress

对移动端做了兼容处理,同时也添加了对 PWA 的支持,可以做到从手机的桌面快速查看你站点的访问情况,为了适配移动端的展示,也做了底部导航栏出来。

二级路径的支持

有一部分用户在部署的时候,没有条件做子域名,需要部署在当前已有站点,通过二级路径的形式访问,为了满足这一需求我在 UI 配置面板中直接做了快捷配置,简单输入,点保存即可实现此功能。
image-20260210013953430

更多元化的数据统计维度

  • 实时访问页面的卡片面板新增降序排列按钮
  • 概况页新增自动刷新功能
  • 新增隐藏侧边栏功能
  • 概况页卡片面板的预计今日添加算法实现说明
  • 数据日报新增访客 TOP10 功能
  • 重新设计内容区域的顶部样式
  • 更易用的访问明细
  • 新增系统通知与白名单功能,非白名单内的 IP 访问会触发系统告警。

image-20260210014307159

image-20260210014326870

image-20260210014350810

项目地址

写在最后

至此,文章就分享完毕了。

我是神奇的程序员,一位前端开发工程师。

如果你对我感兴趣,请移步我的个人网站,进一步了解。

前言

在大家反馈与测试下,最近花了很多时间和精力已经把我的日志分析工具迭代到 V1.6.12 版本了,加了不少新功能,修复了很多问题,同时也对页面样式细节做了很多调整。

目前也算是趋于稳定了,29 天前这个工具刚做出来的时候还只支持 nginx 的日志解析支持,现在已经支持了:

  • caddy 、IIS 、Apache httpd 、HAProxy 、Traefik 、Envoy 、Tengine 、Nginx Proxy Manager
  • NGINX Ingress Controller 、Traefik Ingress 、HAProxy Ingress

对移动端做了兼容处理,同时也添加了对 PWA 的支持,可以做到从手机的桌面快速查看你站点的访问情况,为了适配移动端的展示,也做了底部导航栏出来。

二级路径的支持

有一部分用户在部署的时候,没有条件做子域名,需要部署在当前已有站点,通过二级路径的形式访问,为了满足这一需求我在 UI 配置面板中直接做了快捷配置,简单输入,点保存即可实现此功能。
image-20260210013953430

更多元化的数据统计维度

  • 实时访问页面的卡片面板新增降序排列按钮
  • 概况页新增自动刷新功能
  • 新增隐藏侧边栏功能
  • 概况页卡片面板的预计今日添加算法实现说明
  • 数据日报新增访客 TOP10 功能
  • 重新设计内容区域的顶部样式
  • 更易用的访问明细
  • 新增系统通知与白名单功能,非白名单内的 IP 访问会触发系统告警。

image-20260210014307159

image-20260210014326870

image-20260210014350810

项目地址

写在最后

至此,文章就分享完毕了。

我是神奇的程序员,一位前端开发工程师。

如果你对我感兴趣,请移步我的个人网站,进一步了解。

突然想到北方寒冷时候,候鸟南飞,等北方夏天,候鸟又回来了?那它为啥不一直在物产丰富的南方?又想了一下,难道这个南方不是狭义的中国南方?鸟是去了南半球了?

过去几年,AI在制造业的落地总显得“雷声大、雨点小”。很多企业买了智能系统,却依然靠老师傅的经验拍板;数据堆得满山满谷,可决策还是慢半拍。问题不在技术本身,而在于AI始终停留在“工具”层面——它能算,但不懂为什么算;能执行,却无法理解背后的工艺逻辑与生产节奏。真正的变革,不是让机器更聪明,而是让系统能“思考”。工业智能体,正是这一转变的钥匙。它不是单一算法,也不是一个聊天机器人,而是一套能感知、能推理、能协同、能进化的数字生命体,它把数据、知识、执行能力熔铸成一个闭环,让工厂不再被动响应,而是主动预判。
要理解工业智能体的价值,必须跳出“AI=自动化”的浅层认知。它之所以能突破传统工业软件的断点,是因为它真正融合了工业Know-How与AI的底层能力。数据孤岛、工艺黑箱、知识沉淀难,这些长期困扰制造企业的顽疾,只有通过“感知—决策—规划—执行”的全链路闭环才能破解。这要求智能体不仅懂算法,更要懂设备振动背后的材料疲劳、懂订单波动背后的供应链韧性、懂排产冲突背后的产能瓶颈。它不是替代人,而是把人的经验封装成可复用的逻辑,让每个岗位都有一个“24小时在线的数字专家”。这种深度嵌入,才是工业智能体与通用大模型的本质区别。
在全球范围内,这一趋势正在加速。广域铭岛以汽车制造为起点,构建了覆盖“研产供销服”的超级智能体矩阵,其Geega平台通过数据标准化与知识封装,让原本零散的工艺规则变成AI可调用的“电子字典”。当某条产线突发振动异常,系统能在数秒内关联物料批次、温湿度、设备历史参数,自动调整参数并通知运维,整个过程无需人工介入。而在德国,西门子的MindSphere平台正通过数字孪生与AI协同,实现从订单到交付的全流程动态优化;美国通用电气的Predix系统则聚焦设备预测性维护,结合历史故障库与实时传感器数据,将非计划停机时间降低近40%。这些案例虽路径不同,但内核一致:工业智能体不是孤立的AI应用,而是企业运营体系的“神经中枢”。
广域铭岛的独特之处,在于它不追求“大而全”的模型参数,而是深耕一线场景。它不靠炫技吸引眼球,而是用60多家企业的真实反馈打磨每一个智能体——排产智能体15分钟完成传统需数小时的调度验证,仓储智能体提前48小时预警缺料风险。这种“小而精、快而准”的打法,让它的智能体真正“上岗”了。相比之下,一些国外平台虽技术先进,却常因脱离中国制造业的复杂性与多样性而水土不服。
当越来越多企业开始思考“AI该怎么用”,而不是“能不能用”,工业智能体就不再是一个技术概念,而是一场生产方式的革命。它让制造从经验驱动走向数据驱动,从局部优化走向全局协同。未来属于那些能把AI变成“员工”的企业,而不是那些只把AI当“软件”的企业。

开发者朋友们大家好:

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

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

01有话题的技术

1、Agora 支撑 Whatnot 承载 MrBeast 直播:实现 1080p 画质下 58.3 万峰值并发

实时互动服务商 Agora(声网兄弟公司) 为 Whatnot 电商直播平台举办的 MrBeast 百万美金赠品活动提供技术支持。在 1080p 高清画质下,系统成功应对了 58.3 万的流量冲击,保障了大规模、高频互动的直播稳定性。

  • 超大规模瞬时并发承载: 本次直播峰值同时在线人数达到 58.3 万。Agora 的底层架构在极短时间内完成了大规模接入链路的弹性调度,支撑了远超常规量级的实时流量。
  • 1080p 互动直播画质标准: 在维持 1080p 高清视频输出的前提下,解决了大规模并发带来的延迟问题。确保了百万美金奖品(如兰博基尼、特斯拉)在实时抽奖过程中,全网用户能同步接收到音视频流与互动指令。
  • 全链路低延迟保障: 针对直播购物场景中对「抢购」和「实时互动」的极高要求,该方案在 50 万+ 并发环境下仍保持了极低端到端延迟,避免了因负载过高导致的音画不同步或抽奖结果延迟。
  • 高压环境下的业务转化支撑: 由于直播过程无卡顿,成功支撑了流量向 App 下载的转化,助力 Whatnot 在活动期间攀升至美区 App Store 下载榜第三位。

(@People、@Tubefilter、@MrBeast\@X)

2、字节跳动发布 Seedance 2.0:支持 12 路多模态参考,生成可用率提升至 90% 以上

字节跳动旗下视频生成模型「Seedance 2.0」正式上线即梦平台。该模型通过大幅提升生成稳定性与多模态控制精度,将视频生成从「随机抽卡」转变为「导演级控制」,直接导致视频制作的有效成本下降约 80%。

  • 12 路多模态参考矩阵:支持同时输入最多 9 张图片、3 段视频和 3 段音频作为参考素材,可精确指定角色外貌、动作特效、运镜风格及环境音场,实现跨模态信息的深度融合。
  • 自动化分镜与运镜系统:模型具备自动规划分镜能力,用户只需描述故事情节,无需输入复杂的摄像机术语(如平移、推拉),模型可自主完成具备导演思维的镜头调度。
  • 推理可用率突破 90%:针对 15 秒短片生成,可用率从行业平均的 20% 提升至 90% 以上,显著降低了通过 API 或手动「抽卡」产生的冗余算力成本。
  • 跨镜头角色一致性:增强了长序列叙事的稳定性,支持在多个 15 秒镜头片段间维持角色特征、服装褶皱及场景光影的一致性,满足动漫、短剧等连贯内容生产需求。
  • 音画同步与情绪解耦:实现原生口型同步,并能根据语音语气自动调整角色的微表情(如眼神凌厉、眉毛上挑),确保视听逻辑与情感表达匹配。

已在「即梦」平台上线,付费会员(最低 69 元/月)可直接使用。

(@极客公园)

3、Xmax AI 推出虚实融合实时交互视频模型 X1:破次元实际互动,毫秒级即时反馈

2026 年,随着生成式 AI 与端侧算力的同步成熟,虚拟内容正从「预制叠加」向「实时生成」跨越。初创公司 Xmax AI 近日推出全球首个虚实融合的实时交互视频模型 X1,由华为「天才少年」计划成员史佳欣领衔开发。该模型打破了传统文生视频的键盘输入限制,让用户通过手机摄像头与手势,即可在现实场景中「召唤」并操控虚拟角色。

不同于追求画质和时长的专业创作工具,X1 侧重于降低交互门槛,实现毫秒级的即时反馈。其技术演示应用 X-cam 已展示四大核心功能:

  • 次元互动:通过摄像头捕捉现实场景并上传图片,虚拟角色可「脱屏而出」。用户能通过捏、拍、托等手势与之互动,模型会实时生成物理反馈,如绒毛遮盖、转头避让等。
  • 世界滤镜:支持将实时拍摄画面转化为梵高、乐高或动漫等指定风格。
  • 触控动图:用户在屏幕上拖拽静态照片中的部位(如耳朵、嘴角),即可让角色产生实时位移与表情变化。
  • 表情捕手:AI 实时捕捉镜头中人或物体的特征,根据选定的 Emoji 生成动态表情包。

在技术实现上,Xmax AI 团队针对极致实时、意图理解与数据稀缺三大痛点交出了答卷。 模型采用端到端的流式重渲染架构及帧级别自回归 DiT,配合循环回归架构,实现了无限时长的连续生成。同时,团队构建了虚实融合数据合成管线,低成本批量生产高质量交互训练数据,解决了行业内交互数据匮乏的难题。

Xmax AI 的团队成员涵盖了来自清华大学、港科大以及字节、华为等头部厂商的顶尖力量。其愿景不仅是开发一款应用,而是搭建下一代内容交互引擎,让虚拟角色成为能走进家庭的「数字生命体」,实现「用 AI 玩转世界」的目标。

testflight 邀请链接:
https://testflight.apple.com/join/8sWgKZeQ

Xmax AI 官网链接:
https://xmax.ai/

(@机器之心)


02有亮点的产品

1、OpenAI 首款硬件「Dime」曝光

OpenAI 首款面向消费者的 AI 硬件设备正加速推进,但今年 9 月亮相的首发版本将是功能受限的「简版」

原因在于 HBM 供应紧张推高 2nm 芯片成本,迫使 OpenAI 推迟原计划中具备计算单元的「全能形态」,先行推出仅支持音频功能的版本。

博主「智慧皮卡丘」最新爆料称,这款设备命名为「Dime」,寓意其体积小巧。

其专利已于昨天在美国国家知识产权局公示,外观采用金属材质,主体类似卵石,内部藏有两颗可取出的胶囊状耳机,佩戴方式为置于耳后。

供应链消息指出,设备用料更接近手机级别,主处理器目标直指 2nm 智能手机芯片,且正在开发定制芯片,以实现通过语音直接执行 iPhone 上的 Siri 指令。

在 OpenAI 内部,这款代号「Sweetpea」(甜豌豆)的设备被 Jony Ive 团队列为最高优先级,首年出货目标高达 4000 万至 5000 万台。富士康也已接到通知,需在 2028 年前为 OpenAI 五款设备做好产能准备。

OpenAI CEO 山姆 · 奥特曼曾公开表示,真正的竞争对手不是 Google,而是苹果。

他认为未来 AI 的主战场在终端,而非云端;智能手机屏幕与交互方式限制了 AI 伴侣的潜力,因此 OpenAI 必须打造「AI 原生设备」

奥特曼将其愿景比喻为「湖畔小屋」——在信息轰炸的时代广场之外,为用户提供专注空间。

除了耳机,一支神秘的 AI 笔也在开发之列。结合 Altman 与 Jony Ive 多次提及的线索,外界推测这款设备体积小巧、具备环境感知能力,可能采用陶瓷等高质感材料,并以极简交互为核心。

技术层面,OpenAI 正加速迭代音频模型,为硬件奠定基础。知情人士透露,新一代模型不仅语音更自然,也能支持同步对话与打断处理,预计今年第一季度发布

OpenAI 已组建跨供应链、工业设计与模型研发的团队,目标是打造能主动协作的「智能伙伴」,而非简单的语音接口。

外界还推测,AI 笔可能集成微型投影仪,将图像投射到桌面,以解决无屏幕交互问题;笔夹可能集成麦克风或摄像头,实现文本解析与环境感知。

用户在纸上书写时,AI 可实时解读内容、生成待办事项,甚至作为智能中枢控制周边设备。

( @APPSO)

2、当「老二次元」下场 AI 创业:我要做个会说话的智能「痛包」

图源AI生成

创业者郭轶捷推出了一款名为「Neurobo」的智能娃包。这款产品不仅是装载二次元虚拟角色(即「娃」)的背包,更集成了摄像头、麦克风、GPS 及 Agent 工作流,使其具备感知环境、记录情境和保存记忆的能力。当用户背着娃包外出或社交时,AI 能以包内角色的视角捕捉生活片段,并在合适时机通过 APP 发起互动,实现「让娃活过来」的体验。

郭轶捷团队之所以选择「娃包」而非直接做「娃」,基于对二次元人群的深度洞察:

  • 出行刚需:二次元用户本身就有带娃出街的习惯,娃包是现成的载体。
  • 去 IP 化:情感投射具有高度个性化,用户更倾向于自我创造角色(OC)或融合多种人设,而非受限于单一固定 IP。
  • 数据闭环:相较于居家场景,带娃出门社交能产生大量物理空间数据,弥补了当前人机交互中情感与社会性数据的缺失。

尽管二次元常被视为小众生意,但该项目已获奇绩创坛及港科大教授高秉强等投资方的支持。投资人认为,这门生意的本质是人与虚拟角色之间的交互幻想,这种需求具有普适性。郭轶捷表示,娃包只是切入二次元细分人群的形态,其核心是一套智能可穿戴设备的交互机制。未来,这套机制可拓展至 Labubu、宠物甚至亲子等更广泛的角色化陪伴场景。

目前,Neurobo 娃包计划于 2026 年中量产,预计定价在 500-1500 元之间。团队希望通过打造轻奢的交互体验,让用户感到把娃放进包里是一种更高级的选择,最终服务于更广泛的需要「陪伴叙事」的大众消费人群。

(@未来人类实验室)

03有态度的观点

1、研究称「996」工作模式正在硅谷 AI 行业蔓延

据《商业内幕》报道,今年硅谷的 AI 行业正出现更趋严苛的「996」式工作文化,引发业内对员工身心负担的担忧。

报道援引多位研究人员指出,在激烈的 AI 竞赛推动下,部分科技公司正在形成高压、长工时的工作环境,甚至开始接近在国内互联网行业长期存在的「996」模式。

报道提到,Allen Institute for AI 高级研究科学家 Nathan Lambert 与 AI 研究实验室创始人 Sebastian Raschka 在近期播客节目中谈到,硅谷的工作节奏虽未完全复制中国的「996」,但趋势正在向更高强度靠拢。

Raschka 表示,AI 模型迭代速度极快,初创公司为了在竞争中保持领先,往往需要团队持续交付成果,这使得长时间工作成为常态。他强调,这种节奏更多源于竞争压力与从业者的热情,而非强制要求。

Lambert 指出,这种文化在旧金山最知名的 AI 公司中尤为明显,他提到「这就是 OpenAI 和 Anthropic 的现状」,许多程序员主动投入高压环境,因为他们希望参与最前沿的研究。

不过,他也强调,这种投入往往伴随明显的「人力消耗」,包括与家人相处时间减少、视野变窄以及健康问题等。

这种节奏不可能长期维持,人真的会被拖垮(burn out)。

Raschka 也分享了自身经历,称长期不休息导致颈部与背部疼痛。他认为,年轻程序员若希望在 AI 领域产生影响,亲自来到旧金山仍是最现实的路径,但必须接受相应的生活与健康取舍。

( @APPSO)

04 Real-Time AI Demo

1、VisionClaw:将 OpenClaw 装进智能眼镜 ,实现语音、视觉和智能体操作

近日,开发者 sseanliu 开源了 「VisionClaw」 项目这是一款适用于 Meta Ray-Ban 智能眼镜的实时 AI 助手——通过 Gemini Live 和 OpenClaw 实现语音、视觉和智能体操作。 它结合视觉与语音技术,让智能穿戴设备具备了感知现实并执行复杂任务的能力。

VisionClaw 允许用户在戴上眼镜后,通过简单的点击和语音交互来实现「所见即所得」的智能化体验。其主要功能包括:

  • 实时环境感知:利用眼镜摄像头以每秒约 1 帧的速度向 Gemini 传输画面,AI 能够实时描述用户看到的景象。
  • 双向语音交互:基于 Gemini Live API,系统支持原生的实时音频流传输,而非传统的「语音转文字」后再处理,响应更加自然。
  • 智能体代理操作:通过接入可选的 OpenClaw 本地网关,AI 能够跨应用执行任务,如将物品添加到购物清单、通过 WhatsApp 发送消息或搜索附近商铺。

在技术实现上,该项目基于 Meta Wearables DAT SDK 与 Gemini Live API 构建。它不仅支持 Meta 智能眼镜模式,还特别提供了「iPhone 模式」,方便开发者在没有硬件眼镜的情况下,利用手机后置摄像头测试完整的 AI 链路。

GitHub:
https://github.com/sseanliu/VisionClaw

( @GitHub)

2、告别模糊定位:VPS 技术赋予智能眼镜「空间感知」新高度

来自开发者 Nikhil Sawlani:

智能眼镜现在具备了空间智能。multiset.ai 的视觉定位服务(VPS) 现已支持可穿戴设备,并首发适配 Meta Ray-Ban 智能眼镜。凭借小于 5 厘米的定位精度,眼镜能够精确感知设备的实时位置。

( @sawlaninik@X)

05 社区黑板报

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

1、招聘后端工程师(全职 Remote)

【项目背景】

团队实力: 顶级内容 IP 制作运营团队 。

战略合作: 与日本游戏大厂深度战略合作,资源与技术底蕴深厚。

核心产品: 打造下一代「桌面全息仓」,赋予数字生命毫秒级交互体验 。

【职位详情】

性质: 全职(base 日本),支持远程办公 (Remote) 。

【核心挑战】

多模态中枢: 构建支持语音、文本、视觉输入的实时交互流水线 。

极致低延迟: 优化 TTFT(首 Token 延迟),确保全链路延迟在 1 秒以内 。

底层通信: 基于 WebRTC、WebSocket 或 Protobuf 设计高频指令传输协议 。

【任职要求】

精通异步后端开发,构建支持多模态(语音/文本/视觉)的实时交互流水线 。

熟悉音视频编解码(Opus/PCM)及抖动缓冲区设计 。

熟悉 TEN Framework/ LiveKit / Pipecat / Vapi 等至少一种实时框架 。

联系人:Andy

微信:xianhuabusi002

<邮箱:kai.shi0818@gmail.com>

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

写在最后:

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

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

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

这两年,大模型几乎成了开发者的“标配工具”:
写代码、查资料、做总结、当智能助手。

但你有没有认真想过一个问题:

我们真的必须把所有请求都发到云端 API 吗?

随着模型体积持续下降、硬件性能快速提升,以及 Ollama 这类工具逐渐成熟,
本地运行大模型,已经从早期的“极客尝鲜”,演进为一种可以在真实项目中落地的工程方案

这篇文章,我们就来完整走一遍:

如何使用 LangChain,基于最新 Runnable API,调用本地启动的 Ollama 模型,构建一个真正可用的本地大模型应用。

一、为什么选择 LangChain + Ollama?

先给结论:

Ollama 解决“模型怎么跑”,LangChain 解决“能力怎么用”。

这是目前本地大模型场景中,最自然、最稳定的一种组合方式


1️⃣ Ollama:本地大模型的“Docker”

你可以把 Ollama 理解为:
专门为大模型设计的一层运行时基础设施。

它解决的问题非常聚焦:

  • 统一模型的下载、管理与启动
  • 对外提供标准化 HTTP API(默认端口 11434
  • 支持 LLaMA、Qwen、Mistral、DeepSeek 等主流模型
  • Mac / Linux / Windows 全平台可用
  • 天然适合 Docker / 私有化部署

一句话总结:

Ollama 把“跑模型”这件事,做成了基础设施能力。

2️⃣ LangChain:AI 应用的“控制中心”

如果你只是想“问一句、回一句”,直接调 Ollama API 当然也没问题。
但一旦进入真实工程场景,需求会迅速复杂化:

  • Prompt 如何复用、版本化?
  • 对话上下文如何管理?
  • 如何组合多步推理?
  • 后续怎么接 RAG、Agent、工具调用?

这些正是 LangChain 擅长的事情:

  • Prompt 模板与结构化输入
  • Runnable / LCEL 编排能力
  • 对话历史(Memory)管理
  • Tool、RAG、Agent 的统一抽象
  • 可自然演进到 LangGraph

所以一个非常自然的分工是:

LangChain 负责“编排与逻辑”,Ollama 负责“模型与算力”。

二、准备工作:本地启动 Ollama 模型

1️⃣ 使用 Docker 部署 Ollama(推荐)

docker run \
-d \
--restart=always \
--name ollama \
--gpus=all \
-p 11434:11434 \
-v /home/data/ollama:/root/.ollama \
ollama/ollama

如果你对部署细节感兴趣,可以参考我之前的文章:

  • 《如何使用 Ollama 打造你的本地 AI 助手》
  • 《为本地部署的大模型添加 API Key 认证:Nginx 实现方案》

2️⃣ 拉取并运行模型

qwen3:8b 为例:

ollama pull qwen3:8b

简单测试:

ollama run qwen3:8b

如果可以正常对话,说明模型已经在本地成功运行。


三、LangChain 接入本地 Ollama(OpenAI 协议)

接下来进入核心部分:
如何用 LangChain 调用本地 Ollama?


1️⃣ 安装依赖

pip install langchain langchain-openai

这里我们使用 OpenAI 兼容协议,这是目前最稳定、生态最完整的一种方式。


2️⃣ 创建 Ollama LLM(ChatOpenAI)

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    name="ollama-ai",
    model="qwen3:8b",
    base_url="http://localhost:11434/v1",
    api_key="your api key",
    temperature=0.7,
    timeout=300,
)

几个关键点说明:

  • model 必须与 Ollama 中的模型名称一致
  • base_url 指向 Ollama,并注意使用 /v1 后缀
  • 这里使用的是 OpenAI 标准协议,不是 Ollama 私有 API

3️⃣ 最简单的一次调用

response = llm.invoke("用一句话解释什么是 LangChain")
print(response)

到这里,你已经完成了:

LangChain → 本地 Ollama → 本地大模型

这条完整调用链。


四、进阶用法:Prompt + Runnable(LCEL)

在真实项目中,几乎不会直接“裸调”模型。


1️⃣ PromptTemplate

from langchain_core.prompts import PromptTemplate

prompt = PromptTemplate(
    input_variables=["question"],
    template="你是一个资深后端工程师,请用简洁、专业的语言回答:{question}",
)

2️⃣ 输出解析(StrOutputParser)

from langchain_core.output_parsers import StrOutputParser

parser = StrOutputParser()

显式的输出解析,是 LangChain 新 API 的重要特征:

  • 输出类型清晰
  • 便于后续切换为 JSON / Pydantic
  • 更适合工程化

3️⃣ Runnable 组合(推荐写法)

chain = prompt | llm | parser

response = chain.invoke({
    "question": "为什么本地部署大模型越来越流行?"
})
print(response)

这就是 LangChain 当前主推的 LCEL(表达式)写法
比早期的 LLMChain 更透明、也更可组合。


五、加入 Memory:真正的本地对话能力

⚠️ 一个非常重要的变化

在新的 Runnable 体系中,
Memory 不再是 Chain 的“隐藏参数”,而是显式的状态管理。


1️⃣ 定义对话历史存储

from langchain_core.chat_history import InMemoryChatMessageHistory

store = {}

def get_session_history(session_id: str):
    if session_id not in store:
        store[session_id] = InMemoryChatMessageHistory()
    return store[session_id]

2️⃣ Prompt 显式消费 history(关键)

from langchain_core.prompts import PromptTemplate

prompt = PromptTemplate(
    input_variables=["history", "question"],
    template="""
         你是一个资深后端工程师。

         以下是之前的对话历史:
         {history}

         当前用户问题:
         {question}

         请基于上下文给出连贯、准确的回答。
    """.strip()
)
这是很多人第一次使用 RunnableWithMessageHistory 时最容易忽略的一点:
历史是否生效,取决于 Prompt 是否显式使用 {history}

3️⃣ 构建带记忆的 Runnable

from langchain_core.runnables.history import RunnableWithMessageHistory

chain = prompt | llm | parser

chat_chain = RunnableWithMessageHistory(
    chain,
    get_session_history,
    input_messages_key="question",
    history_messages_key="history",
)

4️⃣ 调用(带 session_id)

config = {"configurable": {"session_id": "local-chat"}}

print(chat_chain.invoke(
    {"question": "什么是 Ollama?"},
    config=config
))

print(chat_chain.invoke(
    {"question": "它和 LangChain 有什么关系?"},
    config=config
))

到这里,你已经拥有了一个:

  • 支持上下文
  • 完全本地
  • 状态可控

的对话系统。

而且 所有数据都只存在你的本地机器上


六、这套方案适合谁?

非常适合:

  • ✅ 本地工具 / 桌面应用
  • ✅ 内部知识库 / 私有 RAG
  • ✅ 研发辅助工具(代码、文档、SQL)
  • ✅ 对数据安全敏感的企业场景
  • ✅ 学习大模型工程化的开发者

不太适合:

  • ❌ 超大并发场景
  • ❌ 极限性能 / 超大模型
  • ❌ 面向公网的 C 端产品

七、一些来自实践的工程建议

最后分享几点真实踩坑后的经验:

  1. 模型别贪大

    • 7B / 8B 是当前本地部署的性价比甜点位
  2. Prompt 比模型更重要

    • 本地模型对 Prompt 非常敏感
  3. LangChain 要“模块化使用”

    • Prompt / LLM / Parser / Memory 明确分层
  4. Memory 要可演进

    • InMemory → Redis → 数据库 → Checkpointer
  5. Ollama 非常适合私有化场景

    • Docker + 内网 + 权限控制,工程成本极低

结语

过去一年,我们讨论最多的问题是:

“该用哪个云端大模型?”

而现在,越来越多开发者开始认真思考:

“哪些能力,其实可以放回本地?”

LangChain + Ollama 并不是为了“替代云”,
而是为我们提供了一个:

真正可控、可组合、可落地的本地大模型方案。

如果你正在做:

  • 本地 AI 工具
  • 私有化大模型
  • Agent / RAG 工程实践

那么这套组合,非常值得一试。


如果你觉得这篇文章对你有帮助,欢迎 点赞 / 转发 / 收藏
下一篇,我会继续分享 LangGraph 在本地大模型场景下的实战用法

转载:公众号[星纬智联技术],推荐中转站: https://nicecode.cc/
AI Agent Gateway 赛道的现状:
2026 年初,AI Agent 领域最火的项目非 OpenClaw 莫属。这个前身为 Clawdbot 🦞(后改名 Moltbot ,最终定名 OpenClaw )的项目,在 GitHub 上已经积累了超过 17 万 Star 。它的核心理念很直接:给 LLM 一双"手",让 AI 能操作你的本地系统——执行命令、读写文件、控制浏览器。OpenClaw 的架构确实强大:
• Gateway + Pi Agent:Gateway 是 Node.js WebSocket 服务(默认绑 ws://127.0.0.1:18789 ),内嵌 Pi ( Mario Zechner 写的开源 Coding Agent )通过 JSON-RPC over stdio 做推理和工具调用
• 多模型支持:通过 Pi 的统一 LLM API 接 Anthropic 、OpenAI 、Google 、Ollama 等多家 Provider
• 支持 WhatsApp 、Telegram 、Discord 、iMessage 、Slack 、Signal 等消息通道• 沙箱模式、设备配对审批、加密凭据存储
但它也有明显的代价:43 万行 TypeScript 代码,Node.js 运行时,以及相当复杂的依赖链。
对于只想自托管一个 AI 助手的个人开发者来说,这个体量太重了。myclaw 想做的事情很简单——用 Go 写一个够用的轻量替代。
myclaw 是什么:
myclaw 是一个 Go 编写的自托管 AI Agent Gateway 。设计目标三条:
1. 轻量:核心代码约 2000 行,单二进制部署,无运行时依赖
2. 实用:覆盖日常场景——Telegram 和飞书双通道、定时任务、记忆持久化
3. 可扩展:模块化架构,Channel 接口抽象清晰,加新通道写一个 struct 就行
架构上借鉴了 OpenClaw 的 Gateway 模式,但实现上砍掉了所有我用不到的东西。
架构设计:
myclaw 的整体架构可以用一句话概括:消息总线驱动的服务编排。
┌─────────────┐     ┌──────────┐     ┌──────────────┐
│  Telegram    │────▶│          │────▶│   Claude /   │
│  Channel     │     │ Message  │     │   OpenAI     │
└─────────────┘     │   Bus    │     │   Agent      │
                    │          │     └──────┬───────┘
┌─────────────┐     │          │            │
│  Feishu      │────▶│          │◀───────────┘
│  Channel     │     └──────────┘
└─────────────┘          │
                         ▼
┌─────────────┐     ┌──────────┐
│  Cron        │     │  Memory  │
│  Service     │     │  System  │
└─────────────┘     └──────────┘
       │
┌─────────────┐
│  Heartbeat   │
│  Service     │
└─────────────┘
核心组件包括:
1. Message Bus (消息总线)
消息总线是 myclaw 的中枢。两种消息类型:
• InboundMessage:从通道流入,携带 Channel 、SenderID 、ChatID 、Content 、Timestamp 等字段
• OutboundMessage:从 Agent 流出,携带 Channel 、ChatID 、Content 、ReplyTo 等字段
通过 Pub/Sub 模式( SubscribeOutbound / DispatchOutbound ),各服务之间实现松耦合的事件路由。缓冲区默认 100 条消息,Goroutine 安全。
2. Gateway (网关编排器)
Gateway 是顶层编排器,负责:
• 组装系统 Prompt (从 AGENTS.md + SOUL.md + 记忆上下文拼接)
• 处理入站消息,调用 Agent 运行时(支持 Anthropic 和 OpenAI 两种 Provider )
• 将 Agent 输出路由到对应的消息通道
• 处理 SIGINT / SIGTERM 优雅关闭
Provider 切换的逻辑很直接——配置里 provider.type 写 openai 就走 OpenAI ,其他情况默认 Anthropic 。不搞什么抽象工厂,一个 switch 解决。
3. Channel (消息通道)
Channel 接口定义了四个方法:Name()、Start()、Stop()、Send()。目前实现了两个通道:
Telegram 通道:
• 基于 telegram-bot-api/v5 长轮询
• Markdown → Telegram HTML 格式转换
• 消息分片( 4096 字符限制)
• 发送者白名单过滤
• 代理配置支持(方便国内网络环境)
飞书通道:
• Webhook 模式,启动一个 HTTP Server 监听 /feishu/webhook (默认端口 9876 )
• Tenant Access Token 管理,带缓存和双重检查锁
• URL Verification Challenge 自动应答
• 事件驱动的消息接收( im.message.receive_v1 )
• 发送者白名单过滤(基于 open_id )
• Verification Token 校验
飞书通道需要一个公网可达的 Webhook URL 。本地开发可以用 Cloudflared 临时隧道,生产环境建议配 DNS 。
4. Memory (记忆系统)
记忆系统分为两层:
• 长期记忆( MEMORY.md ):持久化的知识库
• 每日日记( YYYY-MM-DD.md ):按日期归档的交互记录
提供 ReadLongTerm()、WriteLongTerm()、ReadToday()、AppendToday() 和 GetRecentMemories(days) 方法。默认取最近 7 天的日记,和长期记忆一起组装进 LLM 的系统 Prompt 。
文件就是 Markdown ,想手动改也行。
5. Cron (定时任务)
支持三种调度模式:
• cron:标准 Cron 表达式(基于 robfig/cron/v3 )
• every:固定间隔(毫秒级)
• at:一次性定时执行
任务持久化为 JSON (存在 ~/.myclaw/data/cron/jobs.json ),支持状态追踪( LastRunAtMs 、LastStatus 、LastError )和执行后自动删除。任务的执行结果可以通过 deliver 字段指定是否推送到某个消息通道。
6. Heartbeat (心跳服务)
定期读取 HEARTBEAT.md 文件内容,触发 Agent 处理。Agent 返回 HEARTBEAT_OK 表示无需进一步操作。默认间隔 30 分钟,适合做周期性自检或主动提醒。
为什么用 Go:
选 Go 不是为了赶时髦,是几个实际的考量:
1. 单二进制部署:go build 产出一个可执行文件,不需要 Node.js 运行时或 Python 虚拟环境。scp 到服务器直接跑
2. 并发原语:Goroutine + Channel 天然适合消息总线架构。每个通道、每个定时任务、Webhook Server 都是独立的 Goroutine ,代码写起来比 async/await 回调链清爽
3. 内存占用:Go 运行时的内存开销远低于 Node.js / Python ,一个长期驻留的 Gateway 进程,这点差别会累积
4. 交叉编译:GOOS=linux GOARCH=arm64 go build 一行命令编译到任意平台
快速开始:
安装
go install github.com/stellarlinkco/myclaw/cmd/myclaw@latest
初始化
myclaw onboard
这会在 ~/.myclaw/ 下创建配置文件和工作空间:
~/.myclaw/
├── config.json          # 主配置
├── workspace/
│   ├── AGENTS.md        # Agent 角色定义
│   ├── SOUL.md          # 人格特质
│   ├── HEARTBEAT.md     # 心跳任务提示词
│   └── memory/
│       └── MEMORY.md    # 长期记忆
└── data/
    └── cron/
        └── jobs.json    # 定时任务持久化
配置
编辑 ~/.myclaw/config.json:
{
  "agent": {
    "model": "claude-sonnet-4-5-20250929",
    "maxTokens": 8192,
    "temperature": 0.7,
    "maxToolIterations": 20
  },
  "provider": {
    "type": "anthropic",
    "apiKey": "sk-ant-..."
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "your-bot-token",
      "allowFrom": ["123456789"],
      "proxy": ""
    },
    "feishu": {
      "enabled": true,
      "appId": "cli_xxx",
      "appSecret": "xxx",
      "verificationToken": "xxx",
      "port": 9876,
      "allowFrom": ["ou_xxx"]
    }
  },
  "gateway": {
    "host": "0.0.0.0",
    "port": 18790
  }
}
想用 OpenAI 兼容的 API ?把 provider.type 改成 "openai",填上对应的 Key 和 Base URL 就行。
也支持环境变量覆盖:
环境变量 用途
MYCLAW_API_KEY / ANTHROPIC_API_KEY Anthropic API Key
OPENAI_API_KEY OpenAI API Key (自动切换 Provider )
MYCLAW_BASE_URL / ANTHROPIC_BASE_URL API 地址(可接自定义 Endpoint )
MYCLAW_TELEGRAM_TOKEN Telegram Bot Token
MYCLAW_FEISHU_APP_ID 飞书 App ID
MYCLAW_FEISHU_APP_SECRET 飞书 App Secret
一个细节:如果只设了 OPENAI_API_KEY 而没有配 provider.type ,myclaw 会自动把 Provider 切到 OpenAI 。少一步配置。
运行
# REPL 模式(命令行交互)
myclaw agent

# 单条消息模式
myclaw agent -m "今天的任务清单"

# 完整 Gateway 模式(启动所有服务)
myclaw gateway

# 查看状态
myclaw status
部署
Docker
myclaw 提供了多阶段 Dockerfile ( golang:1.24-alpine 构建,alpine:3.21 运行),编译产物约 10MB
# 构建并启动
docker compose up -d --build

# 如果需要飞书 Webhook 的公网隧道
docker compose --profile tunnel up -d --build
Docker Compose 里包含一个可选的 Cloudflared 隧道服务,通过 --profile tunnel 激活。它会自动把飞书 Webhook 端口暴露到公网,省去自己配 Nginx 反向代理的麻烦。
本地开发也可以直接用 Make:
make tunnel  # 启动 cloudflared 临时隧道
拿到 *.trycloudflare.com 的 URL 后填到飞书开放平台的事件订阅里就行。
裸机部署
# 交叉编译
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o myclaw ./cmd/myclaw

# 丢到服务器上
scp myclaw user@server:/usr/local/bin/
ssh user@server "myclaw onboard && myclaw gateway"
myclaw 证明了一件事:构建一个实用的 AI Agent Gateway 不需要 43 万行代码。2000 行 Go ,两个消息通道,一套记忆系统,一个 Cron 调度器——日常够用了。当然它也有明显的不足。没有 Web UI ,没有多用户会话隔离,飞书通道目前只支持纯文本消息。如果你的场景需要这些,OpenClaw 或者自己加功能。Go 的单二进制部署和低内存占用让它特别适合丢在一台小 VPS 上长期跑着。如果你认同"能用 2000 行解决的问题不要用 43 万行"这个理念,可以试试。
转载:公众号[星纬智联技术],推荐中转站: https://nicecode.cc/

迪士尼的票是真的难抢,只好原价买了,上海的佬们有什么推荐或者注意避雷的吗?

关于IP地址申请HTTPS证书的问题,确实存在一些特定的情况和限制。以下是对这个问题的详细解答:

IP地址能否申请HTTPS证书?

是的,可以为IP地址申请HTTPS证书。不过,这与为域名申请证书有所不同,并且有一些特殊的要求和限制。

1. 公网IP地址

  • 公网访问性:申请证书的IP地址必须是一个可以通过互联网直接访问到的公网IP地址。内网或私有IP地址由于不在公共网络上可见,因此无法用于获取被广泛信任的SSL/TLS证书。
  • 唯一性:该IP地址应该是唯一的,并且你对其拥有完全控制权。这意味着你可以管理该IP上的服务配置及文件。

2. 证书类型

  • 支持的证书类型:通常情况下,针对IP地址的证书仅限于域名验证(DV)级别或组织验证(OV)级别的SSL证书。扩展验证(EV)级别的证书一般不支持IP地址。
  • 单个IP绑定:一个证书只能绑定到一个具体的IP地址,而不像域名那样可以通过通配符证书覆盖多个子域。

3. 验证过程

  • 所有权验证:CA(证书颁发机构)会要求验证你对所申请IP地址的所有权。这通常通过在指定端口上放置一个临时文件来完成。
  • 端口开放需求:在进行验证的过程中,可能需要短暂开放某些端口以便CA能够访问验证文件。

4. 适用场景

  • 服务器通信:当两个系统之间需要建立安全连接,但又没有域名时,使用IP地址的证书非常有用,例如在内部网络中或者开发测试环境中。
  • 物联网设备:对于那些直接通过IP地址连接的IoT设备来说,这样的证书可以提供额外的安全保障。

申请步骤概述

IP地址https证书申请入口

  1. 选择合适的CA:打开JoySSL官方网站注册一个账号。在注册过程中,需要填写特定的注册码230970以获得免费测试ip证书的权限。
  2. 生成CSR文件:使用你的服务器软件创建证书签名请求(CSR)文件,这将包含公钥信息。
  3. 提交申请并验证:向CA提交CSR文件以及必要的信息,然后根据指示完成所有权验证。
  4. 安装证书:一旦获得证书,将其正确配置到你的Web服务器上。

注意事项

  • 成本考量:与基于域名的证书相比,IP地址的证书可能会更昂贵,尤其是企业级产品。
  • 浏览器兼容性:部分老旧浏览器可能不支持IP地址证书,因此要确保目标用户群体使用的浏览器版本支持这种类型的证书。
  • 安全性:虽然IP地址证书提供了加密传输,但在公开网络上,使用域名证书通常是更好的选择,因为它们更容易记忆且便于品牌推广。

总之,虽然为IP地址申请HTTPS证书是一种可行的方法,特别是在特定的应用场景下,但对于大多数面向公众的服务而言,建议还是优先考虑使用域名证书。如果确实需要为IP地址申请证书,请确保遵循上述指导原则,以顺利完成整个过程。

天涯社区宣布回归

据「天涯客」公众号 2 月 6 日发布公告,宣布关停近三年后天涯社区重启,计划 6 月 1 日恢复访问。公告称,天涯社区的资金流动性困难,导致 2023 年 4 月 1 日起因电信 IDC 欠费而暂停访问,天涯数据面临灭失的危局。2024 年专门创立的新天涯投资主体「成都天涯客网络科技有限公司」是天涯社区平台重启、新天涯建设的核心力量,已陆续为天涯社区数据的存续提供了上百万资金。同时在征得天涯社区公司认可的基础上推出了「新天涯创世成员产品服务包」并招募 9999 位创世成员成为新天涯的共建者与天涯社区重启者。服务包包含天涯重启者数字徽章、天涯客高级会员礼盒、官方天涯神帖付费专区 10 年免费阅读权限、天涯元空间以及天涯客 10 年高级尊享会员优惠折扣与 1999 个天涯金豆。服务包限量发行 9999 份,售价 1999 元/份,所得费用均用于天涯社区数据存续、恢复访问及后续新天涯计划的落实。来源


Discord 将默认为账号开启未成年人模式

2 月 9 日,Discord 发文宣布将在全球范围内增强青少年保护措施,自三月起,Discord 将对新用户与现有用户逐步推送年龄验证流程,包括基于本地设备的视频年龄估计等多种方法。之后,未完成成人年龄认证的用户将默认开启未成年人浏览模式,包括限制进入年龄限制频道与内容、陌生人一对一私信过滤、陌生人好友申请警告、禁止舞台频道发言等。同时,Discord 将招募 Discord 青少年委员会,与 10 至 12 名青少年共同商议 Discord 未来功能、优化青少年使用体验。来源

值得一提的是,这一措施随即引发了游戏社区的不满。去年十月,Discord 合作的年龄认证服务商已发生过一次泄漏事故,英国与澳大利亚七万余名用户的身份证件信息被黑客盗取。来源


Linux Kernel 6.19 正式版发布

Linus Torvalds 日前宣布 Linux Kernel 6.19 正式版发布,同时开启 Linux Kernel 7.0 版的合并窗口,也就是 Linux Kernel 6.19 是 Linux Kernel 6.x 的最终版本。此次更新涉及到内核的多方面变更,包括底层安全架构、网络协议、文件系统以及图形管线等,比如底层安全架构方面,加入了线性地址空间隔离、PCIe 链路加密与认证、Arm MPAM 以及用户态 UML 多处理器支持;而在硬件方面则新增对搭载 M 系列芯片的苹果 Mac 的 USB-C 接口的原生管理支持、提前支持 Intel Nova Lake 桌面与移动处理器以及 Intel Xe3-LPG 显卡、正式支持 LoongArch32 子架构、新增对 Logitech G13 游戏版、G PRO X Superlight 2 接收器的支持以及在 GPU 方面新增对 Adreno 612 和 Mali-G1 的支持。对于使用 Linux 发行版的用户可以等待开发商适配更新,专业用户亦可自行编译新版内核。来源


英特尔放弃硬件付费解锁模式

近日,有媒体发现英特尔 SDSi 的 GitHub 项目已被归档,显示该功能已被正式放弃,相关的网页也已经从英特尔官网移除,仅能找到部分旧版 PDF 文档。2021 年英特尔曾推出名为「软件定义芯片」(Software Defined Silicon,SDSi)的功能,该功能用于激活额外的授权硬件特性。此后这个软件定义芯片的支持工作持续推进,并最终以英特尔按需服务(Intel On Demand)的名义正式发布,其核心是:用户可付费激活部分特定型号处理器中已集成、但默认未启用的额外加速器功能,主要用于至强系列芯片。该模式一经推出就遭到了广泛的批评,英特尔也未再对外提及按需服务相关消息。来源


微信平台启动摆拍内容分级分类管理试点

2 月 9 日,微信珊瑚安全发布虚假摆拍视频阶段性治理公告,宣布平台已启动对未标注「剧情演绎」摆拍内容的分级分类管理试点,对累计三万余条存量视频实施补充标注提示。治理范围重点涵盖生活技巧、安全知识(如防骗演示)及搞笑、情感、职场等虚构故事场景。同时平台正式推行「剧情演绎」分级分类标注管理,已主动提醒超五万个创作者规范标注提示,提升内容透明度。来源


欧盟提醒 Meta 屏蔽第三方 AI 助手涉嫌垄断

2 月 9 日,欧盟委员会发文表示已向 Meta 发送一份反对声明。声明指出 Meta 在 WhatsApp 平台屏蔽除 Meta AI 外的第三方 AI 助手的行为,已经违反了欧盟反垄断条例。欧盟委员会有意向对此行为采取临时措施,防止 Meta 的屏蔽导致市场出现严重伤害,但仍会遵守 Meta 的答复与辩护权。2025 年 10 月 15 日,Meta 更新了 WhatsApp 商业解决方案条款,将第三方通用 AI 助手从应用完全禁用,至 2026 年 1 月 15 日,WhatsApp 上唯一可用的 AI 助手只有 Meta 自家的 Meta AI。来源


Apple Swift 学生挑战赛已开放申请

Swift 学生挑战赛(Swift Student Challenge)已于 2 月 6 日开放申请,截止日期为太平洋时间 2 月 28 日,该比赛面向正在培养软件开发技能的学生。中国大陆参赛者要求年满 14 岁或以上,已在 Apple 免费注册为 Apple 开发者或已是 Apple Developer Program 的成员,且满足如下任一要求:

  • 现正就读于,或过去 90 天内毕业于经认可的学术机构、同等正规家庭学校或 Apple Developer Academy;
  • 是 STEM 组织教育课程的在读学生;或
  • 在过去 6 个月内从高中或同等学校毕业,并且正在等待认可的学术机构录取或已被录取。

参赛者需要提交一个可在三分钟内体验的 App Playground,详情见来源。来源


交通运输新业态协同监管部际联席会议办公室约谈高德打车

2 月 9 日,交通运输部发文,表示交通运输新业态协同监管部际联席会议办公室已组织对高德打车约谈。约谈指出高德打车对合作网约车平台管理不到位、压低运价、应急处置不当,要求高德打车强化合作网约车平台监督管理、规范平台经营行为、保障司机合法权益、强化运营安全监管、加强司机关心关爱。来源


看看就行的小道消息

  • 无 DRM 游戏数字发行平台 GOG 本月 5 日在 Reddit 上举行了一次 AMA「问我任何事」活动中回答了论坛网友提出的一系列问题。GOG 平台的现任所有者 Michał Kiciński (@Worth_Technology_415) 正式确认了此前曝光的招聘启事透露的消息:GOG 正在招聘一位高级工程师来协助开发第一方原生 Linux 支持,GOG 已在推进 Linux 支持项目,终有一天会在平台正式上线。同时他们还正将 Dreamlist 梦想名单中原本仅支持主机平台的游戏移植到 PC 端,第一方启动器 GOG Galaxy 将得到进一步改进以及将提高游戏在 GOG 平台的发布计划的透明度。来源
  • 微软针对近期正式弃用 Windows 11 中基于旧版架构的 V3/V4 打印机驱动的问题做出了进一步澄清,即基于 V3/V4 驱动程序的 Windows 11 打印机不会停止工作,多年以来微软正在逐步停止对第三方的 V3/V4 驱动程序提供支持,自 2026 年 1 月 15 日后微软将不再通过 Windows 更新为 Windows 11 及后续版本以及 Windows Server 2025 及后续版本发布基于 V3/V4 的新打印驱动程序。换言之如果自行安装厂商提供的 V3 和 V4 架构的新驱动程序,打印机将仍可以正常使用。不过如果其中包含任何安全问题也只能由用户自行承担可能的风险。来源
  • LibreOffice 开发组织 The Document Foundation(TDF)再度发文,抨击微软的 OOXML 格式完全为其商业利益考虑,文档冗长复杂,且微软自己都未在产品中严格遵循自家标准,既不开放,也不中立。来源
  • 图片分享社区 Flickr 确认因邮件服务 Substack 于 2 月 5 日被攻击,Flickr 发生了范围未公开的数据泄漏,受影响的用户可能经钓鱼邮件泄漏姓名、用户名、邮箱、账号 IP、常用地等,但不包含密码与财务信息。Flickr 提醒用户要继续防范钓鱼邮件。来源
  • CNBC 报道称微软、谷歌等多家企业至高报价 40 至 60 万试图与社交媒体创作者达成 AI 工具的长期宣传合作,但不少创作者因观众的强烈厌恶拒绝。来源
  • YouTube Music 开始将歌词收为 Premium 订阅功能,未订阅听众仅可查看五首歌词。来源
  • 法拉利公布首款电动跑车 Luce 内饰与人机交互设计。该车设计由 Jony Ive、Marc Newson 与 LoveFrom 设计公司完成。车内并未采用全触屏设计,大量保留了便于操作的机械组件。来源


少数派的近期动态

  • 少数派年度征文来了,古法手搓大战人工智能,你会是哪条赛道的大赢家?参与一下
  • 我们正在优化并改进新的首页版式,如果你在使用过程中发现了任何问题或者有改进建议,请通过反馈表单告知我们。首页反馈收集
  • 将设计装进耳朵:少数派×飞傲联名 CD 机盖板设计大赛已经开始啦。了解详情
  • 没什么用,但就是好玩:盘点或恶搞或无聊的「神经病」应用。看看都有啥
  • Sonos × 少数派 × 暖风家联合打造:声音与视觉的沉浸体验空间正式上线啦。了解详情

你可能错过的文章

> 下载 少数派 2.0 客户端、关注 少数派公众号,解锁全新阅读体验 📰

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

    早上看到影视飓风发了个视频,说字节最新的视频生成模型用了他们大量的素材训练,给一张 tim 的照片,模型就能自动匹配他的声音和公司的真实环境。

    然后我试了一下,找了个爱发朋友圈的前同事,把很多朋友圈截图丢 gemini 了,最后 gemini 确实给出了比较准确的猜测信息,这还只是朋友圈一个数据源的情况下。

    所以我觉得,以前的人肉搜索是一个复杂的过程,现在大模型工具可能会加快信息滥用和身份挖掘。
    如果有一个模型,喂足够多的人脸照片,然后输出性能也够强,是不是完全可以实现针对现在各类 app 的活体认证了?要求摇头 点头 张嘴 眨眼,他都能做到,颜色光也可以摄像头采集颜色 然后模拟打光。

    我一直秉承,不把个人照片传互联网网,不带个人姓名等等信息,密码用公式法,每家不一样但有一定规律,但感觉完全不够。

    周日新镜头到了,迫不及待周一早上提早 1 小时起床,趁着上班前在公司附近的公园拍拍小翠。

    前面 7 张都是昨天早上拍的,最后一张是今天早上新鲜出炉的!也是目前为止最满意的一张了。

    目前最大的问题就是全程手持还是太累了,拍一会手就抖的不行,准备周末看看架子和云台去。

    主动降噪的,能侧躺的。之前的坏了,对市场水深不了解,感觉 300 以下就够了吧?牌子太多,眼花缭乱,是不是还是大牌的好点?之前是红米 airdots 3 pro

    本地知识库:数据安全与智能管理的新选择

    在数字化时代,知识管理已成为个人和企业不可或缺的一部分。传统的云知识库虽然方便,但数据安全问题日益凸显。本地知识库应运而生,成为保护数据隐私的重要解决方案。

    什么是本地知识库?

    本地知识库是一种在用户本地设备上运行的知识管理系统,主要用于文件内容搜索和文件知识问答。与依赖网络知识的通用大模型不同,本地知识库能够依据个人电脑或企业服务器中的文件内容进行精准回答。

    访答本地知识库的核心功能包括:

    • 文件上传:将个人电脑中的各类文件投影到知识库
    • 深度解析:详细解析PDF、Word、图片、Excel等文档内容
    • 智能搜索:直接搜索相关内容在哪些文件中出现
    • 知识问答:依据文件知识进行准确回答

    为什么需要本地知识库?

    数据安全至关重要

    云知识库中的文件数据存在被窃取、被AI白嫖的风险。访答本地知识库作为离线知识库,具有以下安全优势:

    • 一键安装,0代码使用
    • 不会上传任何文件
    • 断网可用,绝对安全
    • 自主可控,可自定义
    • 保护私有知识产权和数据隐私

    企业内部数据作为核心资产,更不可能上传到云端。本地知识库确保了数据主权始终掌握在用户手中。

    本地知识库的核心功能

    深度文件解析能力

    访答知识库对各种类型文件的解析能力令人印象深刻:

    • 图片:识别图片中的文字和内容描述
    • PDF/Word:提取文本、图片、公式、表格、印章等
    • Excel:处理表格数据
    • 视频:解析视频中的图片、语音、文字
    • 音频:转写音频文字

    多模态搜索与问答

    本地知识库支持多种搜索和问答形式:

    • 文本包含和相似搜索
    • 图片、语音、视频相似搜索
    • 多模态搜索(文本搜图片、文本搜语音等)
    • 文件整体相似性比较
    • 智能问答基于Qwen、Deepseek等模型

    本地知识库的应用场景

    AI智能客服问答

    企业可将商品信息沉淀入知识库,在用户询问时搜索相关信息并生成准确回答。支持多模态问答、多级问答和自助客服,显著提升客服效率。

    智能商品推荐

    依据用户行为和商品特征,从知识库中搜索相似商品进行推荐。支持多样性推荐、冷启动和否推荐功能,实现精准营销。

    企业知识管理

    打破部门间知识壁垒,方便内部沟通和高效检索。存储员工手册、流程文档和技术资料,助力企业智能化转型。

    本地知识库 vs 云知识库

    访答本地知识库的所有操作都在用户电脑上进行,不上传任何文件数据,所有AI模型都在本地运行。而云知识库跟随账户,在任意电脑登录即可使用,但存在数据外泄风险。

    立即体验安全的知识管理

    本地知识库是数据主权时代的刚需选择。访答提供绝对安全的本地知识库解决方案,一键安装,0代码使用,让您的知识管理既智能又安全。

    无论您是个人用户还是企业用户,保护文件数据安全都是首要考虑因素。选择本地知识库,就是选择对数据的完全控制权。