当半导体一级市场回归理性,资本不再为单纯的“算力堆叠”买单,而是开始寻找真正能“落地”的技术。1 月 15 日,硅谷通用神经网络处理器(GPNPU)IP 厂商 Quadric 正式宣布完成 3000 万美元(约合人民币 2.17 亿元) 的 C 轮融资。本轮融资由 BEENEXT 管理的 ACCELERATE 基金领投,老股东 Uncork Capital、Pear VC 持续加注,新投资方阵容则颇具产业背景,包括 万向美国(Wanxiang America)、NSITEXE(丰田 / 电装生态圈)、MegaChips(日本大型无厂半导体公司)以及 Gentree 和 Volta 等。

在端侧大模型(Edge LLM) 加速渗透的今天,Quadric 试图用一套“软件优先”的 GPNPU 架构,打破传统 NPU“不仅难用,还没法改”的僵局。

1. 营收翻倍,不仅是“讲故事”

芯片圈现在的融资环境大家有目共睹,光靠 PPT 已经很难从 VC 口袋里掏出钱了。Quadric 这轮融资之所以能成,核心在于其商业化进程的 “实锤”。根据官方通稿披露的数据,Quadric 在过去一年交出了一份相当硬核的成绩单:2025 年的 IP 许可与特许权使用费(Royalty)营收较 2024 年实现了三倍增长。截至目前,其累计融资总额已超过 7200 万美元。Quadric CEO Veerbhan Kheterpal 在谈及此次融资时底气十足地表示:“在这个充满挑战的融资环境中,能够超额认购完成 C 轮,直接证明了市场对我们‘代码优先’(Code-First)推理架构的认可。”

2. 拿下关键 Design Wins:Tier IV 与亚洲大厂

除了营收数据,Quadric 此次还披露了两个极具含金量的 Design Wins(设计中标),直接验证了其技术在高端市场的落地能力:日本自动驾驶软件巨头 Tier IV作为开源自动驾驶软件 Autoware 的维护者,Tier IV 将在其下一代 AD / ADAS 计算平台中集成 Quadric 的 Chimera GPNPU 核心。这对实时性要求极高的车规级市场来说,是一个重要的风向标。一家亚洲顶级芯片供应商(Top-Tier Asian Silicon Vendor)虽然官方未点名,但这大概率指向了本轮的战略投资方之一(如 MegaChips 等)。该厂商将在其边缘 SoC 中集成 Quadric IP,专门用于运行端侧大语言模型(Edge LLMs)。这标志着 Quadric 已经杀入了最火热的 AI PC / AI Phone 或边缘服务器赛道。

3. 为什么要“革 NPU 的命”?

目前市面上的边缘 SoC 设计,普遍还在用“CPU + DSP + NPU”的异构堆叠模式。看着分工明确,实则痛点不少:数据要在不同核心的内存间搬来搬去,功耗白白浪费;而且 NPU 往往是“黑盒”,开发门槛高,一旦算法变了(比如从 CNN 切到 Transformer),硬件可能就废了。

Quadric 搞的这个 Chimera™ GPNPU,核心逻辑就是做 减法与融合。软件定义的硬件:Quadric 强调 “C++ driven”,开发者不需要学习晦涩的专用语言,直接用 C++ 就能控制硬件。混合流水线:它在一个处理器里同时处理矩阵计算(AI 推理)和控制逻辑(C++ 代码)。这意味着,你不需要把数据在 CPU 和 NPU 之间来回倒腾,直接在 GPNPU 内部“一条龙”处理完。抗老化能力:对于汽车这种生命周期长达 10 年的产品,算法年年变。GPNPU 的可编程性,意味着车厂可以通过软件更新来支持未来的新模型,而不用更换硬件。

4. 行业观察:资本向“应用侧”转移

边缘计算社区观察到,本轮投资方的构成非常耐人寻味。除了财务投资人,NSITEXE(电装关联企业)、MegaChips 和万向美国 的入局,清晰地表明了产业链上下游的态度:汽车电子和工业自动化领域,急需一种更灵活、更高效的计算架构。随着 Transformer 架构日新月异,端侧大模型层出不穷,专用加速器(ASIC)“上市即落伍”的风险越来越大。Quadric 这种“通用性 + 高性能”的中间路线,或许正是解决当前边缘 AI 碎片化难题的一剂良药。据悉,这笔 3000 万美元 将重点用于扩大全球工程团队,并进一步打磨其软件开发工具链(SDK),毕竟对于 IP 厂商来说,生态好不好用,直接决定了客户愿不愿意用。

参考材料
Quadric Press Release: Quadric Raises $30M Series C Funding to Accelerate On-Device AIhttps://quadric.ai/press-release/quadric-raises-30m-series-c-...

Pulse 2.0: Quadric: $30 Million Series C Closed As Design Wins Acceleratehttps://pulse2.com/quadric-30-million-series-c/

Design & Reuse: Quadric Raises $30M Series C Financing for GPNPU Architecturehttps://www.design-reuse.com/news/56829/quadric-series-c-fina...

基于 YOLOv8 的桥梁病害(八类缺陷、病害高精度)自动检测 [目标检测完整源码]

一、背景与问题:桥梁检测为什么需要 AI?

桥梁作为城市与交通网络中的关键基础设施,其服役周期长、受力复杂、环境影响显著。随着时间推移,桥梁结构不可避免地会出现裂缝扩展、混凝土退化、钢筋腐蚀、潮湿渗水等病害问题。若不能及时发现并处理,轻则影响通行安全,重则引发结构性风险。

传统桥梁检测主要依赖人工目测或人工+仪器结合的方式,普遍存在以下痛点:

  • 检测效率低,难以覆盖大规模桥梁资产
  • 对检测人员经验依赖强,结果主观性高
  • 数据难以结构化,不利于长期健康评估

在此背景下,基于计算机视觉的自动化桥梁病害检测逐渐成为智能运维的重要发展方向。
在这里插入图片描述

源码下载与效果演示

哔哩哔哩视频下方观看:

https://www.bilibili.com/video/BV1m8g8z6Ejp/

在这里插入图片描述
包含:

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址(含标注脚本

二、整体解决方案概述

本文介绍的一套桥梁病害检测系统,采用 YOLOv8 目标检测模型 作为核心算法,并结合 PyQt5 桌面端可视化工具,构建了一条从模型训练到工程应用的完整技术链路。

系统核心能力概览

  • 支持 8 类典型桥梁缺陷与病害识别
  • 覆盖 图片、批量图片、视频、摄像头 等多种输入形式
  • 提供 图形化操作界面,降低使用门槛
  • 支持模型再训练与工程级部署

该系统既可作为科研与教学案例,也可直接用于工程检测与巡检辅助。


在这里插入图片描述
在这里插入图片描述

三、检测目标设计:让模型“看懂”桥梁问题

在桥梁结构表面,病害往往呈现出尺度小、纹理细、形态多样的特点。针对工程实践需求,系统定义了以下八类检测目标:

  1. 裂缝
  2. 收缩裂缝
  3. 底层收缩裂缝
  4. 混凝土退化
  5. 混凝土空洞
  6. 腐蚀
  7. 潮湿
  8. 路面劣化

这些类别基本覆盖了常见桥梁表观病害类型,为后续健康评估与维修决策提供了结构化输入。


在这里插入图片描述

四、为什么选择 YOLOv8?

YOLOv8 是 Ultralytics 推出的新一代实时目标检测模型,在工程实践中表现出明显优势:

  • Anchor-Free 架构
    对细长裂缝、小尺度缺陷更友好,减少人为先验约束。
  • 推理速度快
    能够满足视频流与实时检测场景需求。
  • 训练与部署流程成熟
    模型配置灵活,支持快速复现与迁移学习。
  • 多任务扩展能力强
    为后续引入分割、姿态或多模态任务奠定基础。

在桥梁病害这类“复杂背景 + 小目标”的场景中,YOLOv8 在精度与速度之间取得了良好平衡。


在这里插入图片描述

五、数据集构建与训练流程

1. 数据组织方式

系统采用标准 YOLO 数据格式,清晰划分训练集与验证集,便于模型迭代:

dataset/
├── images/
│   ├── train/
│   └── val/
├── labels/
│   ├── train/
│   └── val/

每张图像均配有对应标注文件,记录目标类别及归一化边界框信息。

2. 训练与评估策略

模型训练过程中,重点关注以下指标:

  • box_loss:定位精度
  • cls_loss:类别区分能力
  • mAP@0.5:整体检测性能

当模型在验证集上达到稳定收敛并取得较高 mAP 后,即可进入部署与应用阶段。


在这里插入图片描述

六、推理与可视化系统实现

1. 模型推理逻辑

系统基于 PyTorch 推理接口加载训练完成的 YOLOv8 模型,对输入图像或视频逐帧执行检测,输出包括:

  • 缺陷类别
  • 置信度
  • 边界框坐标

这些信息可进一步用于统计分析或风险评估。

2. PyQt5 图形化界面优势

通过 PyQt5 封装推理流程,系统实现了:

  • 图像/视频/摄像头一键加载
  • 检测结果实时展示
  • 自动保存检测图片与日志
  • 无需命令行操作的工程化体验

这使得系统不仅面向算法工程师,也适用于检测人员与工程管理人员使用。


在这里插入图片描述

七、典型应用场景

该系统在多个实际场景中具备应用潜力:

  • 桥梁日常巡检与快速筛查
  • 历史病害数据对比与趋势分析
  • 科研机构桥梁健康监测研究
  • 高校土木与智能建造课程教学

通过持续积累检测结果,还可进一步构建桥梁全生命周期健康管理体系。


八、未来扩展方向

在当前系统基础上,可进一步拓展以下能力:

  • 引入 图像分割模型,实现裂缝精细化测量
  • 融合 红外或多光谱数据,增强隐蔽病害识别
  • 部署至 边缘计算设备或无人机平台
  • 结合时序数据,分析病害演化趋势

在这里插入图片描述

结语

本文介绍了一套面向实际工程应用的 桥梁病害智能检测系统,通过 YOLOv8 高性能目标检测模型与 PyQt5 可视化工具的结合,实现了从数据、模型到应用的完整闭环。

该方案在提升检测效率、降低人工成本、增强结果一致性方面具有显著优势,为桥梁智能巡检与结构健康监测提供了一条可落地、可扩展的技术路径,也为工业视觉在基础设施领域的应用提供了有价值的实践参考。

本文从实际工程应用角度出发,系统梳理了一套基于深度学习目标检测模型的智能识别解决方案,完整覆盖了数据准备、模型训练、推理验证以及应用系统集成等关键环节。通过将算法能力与可视化应用相结合,实现了从模型效果验证到业务可用系统落地的转化,体现了人工智能技术在真实场景中的工程价值。整体方案结构清晰、技术路线成熟,既具备较强的复用性与扩展性,也为相关领域的智能化升级提供了可参考、可落地的实现范式。

基于 YOLOv8 的多车型交通车辆实时检测识别项目 [目标检测完整源码]

一、背景与问题引入

在智慧交通体系中,“看得清、分得准、跑得快”始终是视觉感知系统的核心诉求。传统基于规则或特征工程的方法,在复杂道路环境、密集车流、多车型混行的场景下,往往存在鲁棒性不足、维护成本高的问题。

随着深度学习目标检测模型的成熟,YOLO 系列逐渐成为交通视觉领域的主流方案。其中,YOLOv8 以其 Anchor-Free 架构、更优的速度–精度平衡以及完善的工程生态,非常适合用于实时车辆检测与系统级落地。

本文将从工程实践角度,完整介绍一个 支持 12 类常见交通车辆、具备图形化界面、可直接部署运行 的实时检测系统设计与实现思路。
在这里插入图片描述

源码下载与效果演示

哔哩哔哩视频下方观看:

https://www.bilibili.com/video/BV1dwg5zCEkL/

在这里插入图片描述

包含:

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址(含标注脚本

二、系统整体架构设计

该系统并非仅停留在“模型推理”层面,而是以完整应用系统为目标进行设计,整体架构可划分为四个核心模块:

┌────────────┐
│  数据输入层 │  ← 图片 / 视频 / 摄像头 / 文件夹
└─────┬──────┘
      │
┌─────▼──────┐
│  检测引擎层 │  ← YOLOv8 Detection Model
└─────┬──────┘
      │
┌─────▼──────┐
│  结果处理层 │  ← NMS / 置信度过滤 / 可视化
└─────┬──────┘
      │
┌─────▼──────┐
│  UI 交互层  │  ← PyQt5 图形界面
└────────────┘

这种分层结构具备以下优势:

  • 算法与界面解耦,便于模型升级
  • 输入方式可扩展(无人机、RTSP流等)
  • 易于二次开发与功能叠加

在这里插入图片描述
在这里插入图片描述

三、核心功能能力解析

3.1 多源输入的统一检测流程

系统支持多种数据源接入,并统一走同一套检测逻辑:

  • 单张图片检测:适合离线分析与测试
  • 文件夹批量检测:用于数据清洗与标注校验
  • 视频文件检测:适配道路监控录像
  • 实时摄像头检测:满足在线监控需求

在底层实现上,通过对输入源进行抽象封装,确保模型推理逻辑保持一致,避免重复代码。


3.2 多车型精细化识别

本项目针对真实交通场景,定义了 12 类常见车辆类型,涵盖:

  • 轿车、SUV、面包车
  • 公交车、卡车、工程车辆
  • 特殊用途车辆等

YOLOv8 的 Anchor-Free 机制在多尺度目标(远距离小车 / 近景大车)检测中表现稳定,有效降低漏检与误检率。


3.3 PyQt5 图形化交互系统

为了降低系统使用门槛,引入 PyQt5 构建桌面级应用界面,核心设计原则是:

  • 无需编程经验即可使用
  • 操作路径清晰
  • 结果可视、可保存

主要功能包括:

  • 输入源选择与切换
  • 检测启动 / 停止控制
  • 实时画面显示(带检测框)
  • 检测结果自动保存

这使得模型能力真正转化为“可使用的软件”,而不仅是脚本级 Demo。


在这里插入图片描述

四、YOLOv8 模型训练与评估实践

4.1 数据集组织规范

项目采用标准 YOLO 数据格式,便于复用与迁移:

dataset/
├── images/
│   ├── train
│   └── val
└── labels/
    ├── train
    └── val

标签文件采用归一化坐标,兼容 Ultralytics 官方训练接口。


4.2 模型训练策略

训练阶段基于 YOLOv8 预训练权重进行微调,核心关注点包括:

  • box_loss:定位精度
  • cls_loss:车辆类别区分能力
  • dfl_loss:边框质量优化

在实际项目中,当 mAP@0.5 稳定超过 90%,即可满足工程部署需求。


4.3 推理与部署方式

模型推理通过 Ultralytics 官方 API 完成,具备如下特点:

  • 接口简洁,代码量少
  • 支持 CPU / GPU 自适应
  • 可导出 ONNX / TensorRT

结合 UI 层,可直接形成“即点即检”的完整工作流。


在这里插入图片描述

五、工程化落地与可扩展性

与单纯算法实验不同,该项目在工程层面具备以下实用特性:

  • 完整源码与权重打包
  • 一行命令启动系统
  • 训练 / 推理 / UI 全流程覆盖

在此基础上,可进一步拓展:

  • 车辆轨迹跟踪(DeepSORT / ByteTrack)
  • 车流量统计与时间序列分析
  • 多路摄像头并行检测
  • 智慧交通平台对接

在这里插入图片描述
在这里插入图片描述

六、总结与展望

本文从系统视角出发,完整介绍了一套 基于 YOLOv8 的多车型交通车辆实时检测平台 的设计与实现思路。通过将高性能目标检测模型与 PyQt5 图形界面深度融合,实现了从算法能力到实际可用系统的有效转化。

该项目不仅适用于智慧交通与城市监控场景,也非常适合作为:

  • 计算机视觉工程实战案例
  • AI 教学与科研实验平台
  • 工业级视觉系统原型

随着模型与算力的持续演进,交通视觉系统将不再只是“看见车辆”,而是逐步走向 理解交通、预测交通、优化交通。这一项目,正是迈向该目标的一个扎实起点。

在这里插入图片描述

本文从工程化与系统化的角度,介绍了一套基于 YOLOv8 的多车型交通车辆实时检测系统,完整覆盖了数据输入、模型训练、推理部署以及 PyQt5 图形化交互等关键环节。通过将高精度目标检测模型与易用的桌面端界面相结合,系统实现了对多种交通场景下车辆目标的稳定识别与实时展示,显著降低了深度学习技术在智慧交通领域的使用门槛。整体方案结构清晰、可扩展性强,不仅具备直接落地应用的工程价值,也为后续在车流统计、行为分析和交通智能决策等方向上的功能扩展提供了良好的技术基础。

作者:张红霞,青岛雨诺网络信息股份有限公司新零售产品部总监

综述

当前,医药零售企业已不再满足于“卖药”,而是致力于成为“健康管理伙伴”。通过构建以 CRM 会员系统为核心、线上与线下深度融合的全渠道服务架构,企业实现了服务时间与空间的无限延展、会员数据的集中管理与智能应用、营销活动的精准触达与高效转化。

作为医药零售的头部企业,重庆医药(集团)股份有限公司(简称“重药集团”)前身是成立于1950年的中国医药公司西南区公司,服务于医药全产业链,同时从事医药研发(MAH)、医疗器械生产,并投资参与医药工业。重药集团拥有全级次分、子公司200余家,正在从传统的配送商业企业向“互联网+医药”融合型现代医药企业转型。

随着CRM会员系统的使用时间拉长,其底层的传统数据库逐渐难以满足复杂数据的高效处理需求。面对海量交易和多维度行为数据的汇聚,重药集团CRM会员系统亟需采用具备高可用、强一致、可扩展特性的数据库。经过对比三款国产分布式数据库,重药集团选择OceanBase,最终实现系统稳定运行、复杂场景实时分析、查询效率提升25倍、存储空间节约60%。

此次重药集团CRM系统的数据库升级不仅提升了用户体验与品牌忠诚度,也为后续集团构建高性能、高可用的“集团级数字化运营中枢”提供了明确的业务需求与数据基础,构建可扩展、可复制、可监管的集团化运营体系。

医药零售商业模式变革,CRM系统实现全渠道协同

随着消费者行为的数字化转型和健康需求的持续升级,医药零售行业正经历深刻的商业模式变革。传统药店“有啥卖啥”的经营逻辑,逐步向“顾客需要什么”的逻辑转变,除了提供到店服务外,还支持线上服务,比如通过企业微信、公众号等渠道建立长期沟通机制。微商城代客下单、在线解答疑问等。

为构建以专业化服务为基础的顾客信任体系,医药企业建立了完整的会员服务体系——CRM 会员系统,以实现绑定多重会员信息、建立精准的会员标签画像,为会员提供更多的服务和营销。通过数据驱动决策的专业化服务能力提升来提高企业在行业内的竞争力,实现增收。

如图1 所示,CRM 会员系统可以实现线上、线下全渠道协同,支持会员档案统一、标签体系完善、自动触发机制、店员触达赋能、社群营销等关键功能。完成顾客到店/线上购药 → 完成交易 → 数据沉淀至 CRM → 触发服务与营销 → 二次消费 → 再次触达,实现“交易—服务—再交易”的正向循环。

图1 CRM会员系统实现线上、线下全渠道协同

为实现一体化管理需求,构建CRM会员系统

重药集团CRM会员系统的搭建背景,源自于其各子公司会员管理分散,系统缺乏统一规划,导致数据难沉淀、服务差异大、运营难复制,且缺乏实时监控,难以支撑决策。

为实现一体化管理,重药集团CRM会员系统分阶段建设。第一阶段完成会员营销平台的底座建设,打造集团化、标准化、数据化运营基础,核心目标如下。

  • 搭建集团化会员运营平台。现集团—子公司—门店的一体化管理,打通组织架构与业务链路,确保会员在不同层级和渠道中都能获得一致的服务体验。
  • 统一的会员运营服务体系。构建覆盖会员管理、营销活动、服务交付的标准化流程,减少分散运作带来的效率损耗,提升整体运营协同能力。
  • 可快速复制标准化服务能力。形成可落地的服务模板和运营机制,帮助新业务和子公司快速复制成熟经验,缩短建设周期,提升推广效率。
  • 实现经营数据统一分析。沉淀完整的数据资产,打破信息孤岛,实现对会员、门店、区域的多维度统一分析,为企业战略决策与合规审计提供有力支撑。

在上述目标指导下,我们做了三个核心举措:

  • 联合集团会员中心,推进一体化进程。覆盖集团全品牌及线上会员,实现线上和线下会员统一运营和全域价值管理(见图2)。
  • 构建多层级组织架构视角报表。支持集团、品牌、门店的权限管理,权限灵活配置,便于集团总部进行跨品牌的数据报表分析。
  • 集团统一下达任务。集团可向各品牌下发销售任务、患者教育活动任务及拉新任务,实现集团任务统一管理与执行监督。

图2 集团会员同意运营架构

我们计划以集团内个别区域公司为试点,试行以上举措,若成功,则进行全面推广。推广成功后,重药集团会员运营平台将实现从“单一业务系统”向“集团级数字化运营中枢”演进。依托统一的技术底座与标准化流程,平台不仅实现对多家子公司、多个品牌的全面接入,更构建起可扩展、可复制、可监管的集团化运营体系。

此外,为实现全渠道会员统一运营,平台通过整合分散在各系统中的数据,构建统一、动态、多维度的会员标签画像体系(见图3),支撑精细化运营决策。

图3 多维度会员标签画像体系

通过会员系统精准化的服务来反哺我们的线上和线下的会员营销和服务,实现线上精准营销、个性化推荐、好物推送、会员关怀,线下关联用药建议、慢病管理提醒、店员主动触达等,提升营销转化率,增强客户粘性,实现“数据驱动服务”的闭环。

精细化会员服务,带来海量数据的查询、存储难题

然而,随着集团化会员运营平台的推进,精细化服务模式持续深化,导致用户数据规模呈指数级增长,显著提升了系统的查询与存储复杂性。

  • 会员量:突破千万级,覆盖多个品牌及区域公司。
  • 交易数据量:达到亿级,涵盖线上线下购药、用券、复购等行为。
  • 用户行为类数据:包括商品浏览、搜索、加购等,总量亦达千万级以上。

这些数据来源于线上商城、私域平台、公众号等多个渠道,经标签体系整合后,用于构建立体化的会员画像,支撑精准营销与双向引流。

但数据体量大、类型多样、实时性要求高,对数据库的高并发读写能力、存储扩展性与查询性能提出严峻考验。面对千万级会员、亿级交易和多维度行为数据的汇聚,传统数据库难以满足高效处理需求,亟需采用具备高可用、强一致、可扩展特性的分布式数据库系统进行支撑。

CRM会员系统数据库升级,应对千万级数据处理难题

传统数据库的技术瓶颈制约业务发展

重药集团会员服务平台的规模化发展,使系统数据总量迅速增长至千万级、数十 TB 存储规模,传统关系型数据库在支撑精细化会员运营场景时,暴露出四大核心挑战。

  • 性能:百万大表 InnoDB 在高并发读写及复杂查询场景下,性能显著下降,无法满足业务需求,且有事务访问,无法通过拆分提升性能。同时,业务强依赖事务一致性,无法通过拆分提升性能。
  • 效率:核心归档由于业务需求,需要保留大量数据(数十 TB),会造成 DDL 周期长,延迟业务上线时间。
  • 成本:随着企业数量增多、历年数据累积,存储成本将越来越高。
  • 及时性:在各种场景下,对应数据处理的及时性需求越来越强。

上述技术挑战不乏真实业务案例。

例 1:某大型连锁店,以满足信创要求为前提进行性能保障

如今国家对信息技术应用创新(简称“信创”)的要求日益严格,特别是在国有企业中,系统必须符合相关标准才能上线。为了响应这一趋势,我们严格按照信创目录选择数据库产品,并对其进行了全面的业务场景适配与性能验证。

  • 数据准备:会员卡 9950万+、订单 1 亿 9980万+。
  • 验证数据库:OceanBase 数据库、某数据库1、某数据库2。
  • 验证功能:报表 14 项内容、高级筛选 8 项内容。
  • 参考标准:报表查询小于 20s、静态化数据小于 60s、高级筛选小于 15s。

测试结果如图4所示。OceanBase 在所有测试项中均显著优于其他两个国产数据库,在报表查询、高级筛选、静态化数据三个场景的性能表现都远超预期:

  • 报表查询小于 7s,平均提速 78 倍以上。
  • 高级筛选响应高级筛选小于 1s,速度提升 200–700 倍。
  • 静态化数据静态化数据小于 46s,效率提升 6.7 倍以上。

图4 OceanBase 数据库、某数据库1、某数据库2的测试结果

在严格遵循国家信创要求的前提下,OceanBase 不仅完全满足合规性准入条件,更在百亿级数据规模下的复杂查询与批量处理场景中展现出卓越性能,远超同类国产数据库产品。基于此,我们总结了三个数据库的性能数据,向客户提交了一份详细的分析报告。

例 2:连锁会员、订单交易数据量增长迅速,实时性查询瓶颈

除了信创需求外,客户对业务的实时性、及时性要求也越来越高。过去,企业主要依赖 BI 工具进行周期性报表生成,可容忍数小时甚至数天的数据延迟。然而,随着营销策略向精准触达和即时响应演进,业务人员需要在高价值客户识别、复购提醒触发、定向营销投放、健康知识推荐等场景中获取近实时数据支持。为实现精准服务,运营人员经常需要基于会员信息、会员属性、历史消费、会员标签、商品集合等多个维度进行多维组合筛选,由于关联维度过多,可能会出现查询失败、查询时间过长、范围跨度受限、复杂查询无法支持等问题,显然,这些问题是我们服务的客户无法接受的。

例 3:海量业务数据,系统可用性与存储成本难平衡

连锁医药企业会员体系的不断扩展和数字化运营的深入,必然会带来业务数据量的指数级增长,海量数据带来的高存储成本成为制约系统可持续发展的关键瓶颈之一。

  • 用户数据:累计会员数量突破千万级(>1000万)。
  • 交易流水:日均订单量达百万级,历史累计超过亿级(>1亿条)。
  • 用户行为数据:包括浏览、搜索、加购、收藏等行为记录,总量亦达千万级以上。

单个业务数据库实例空间占用已达到 N 个 TB 级别,且随时间推移呈线性增长。随着客户数量增加和业务持续扩张,业务数据库实例的空间占用迅速攀升至数十TB甚至上百TB级别,这些数据不仅用于支撑日常业务运行,还需长期保留以满足合规审计、精准营销、客户画像构建等需求。企业面临保障性能与可用性的前提下降低存储成本的难题。

因此,引入具备高效数据压缩、自动冷热分层、弹性扩展能力的新一代分布式数据库,是实现“数据价值最大化、存储成本最小化”的必然选择。

数据库技术引入,支撑海量交易数据的高效处理

综合业务需求与传统数据库的技术瓶颈考虑,我们需要替换传统数据库,升级为高性能、稳定性强、成本低、 HTAP 一体化的分布式数据库。

自 2023 年起,我们开始系统性地评估并引入 OceanBase,历经技术认知、多轮测试、工具链验证、SaaS 级试点上线等关键阶段(见图5),最终成功应用于重药集团会员管理平台。

图5 上线OceanBase的关键阶段

1.技术引入与评估阶段(2023年)

测试重点包括三部分。

其一,日常抖动测试。在对 OceanBase 初期测试时,我们首先进行了业务压力测试。低峰期业务配合100%模拟线上流量直接发压,高达4轮的压力测试,每次持续 3 小时以上。

其二,扩容/缩容测试。在业务流量低时进行相关操作验证。为了验证是否存在小概率事件,进行了为期一周的脚本自动扩、缩容操作以观察其稳定性。

其三,Add Index 测试。与扩容、缩容相仿,基于业务流量对1T大表进行多达几十次的add index操作,观察延迟情况。

2.SaaS 产品试点上线(2023 年 12 月)

在完成全面技术验证后,我司将 OceanBase 应用于内部 SaaS 类产品中,作为首个生产级试点场景。该阶段实现了:

  • 数据库稳定运行于真实业务环境中。
  • 验证了迁移、运维、监控等全生命周期管理能力。
  • 积累了宝贵的实战经验,为后续客户项目打下坚实基础。

3.重药集团项目正式上线(2025 年 4 月)

基于前期充分验证与试点成果,我们于 2025 年 4 月正式启动重药集团会员管理平台项目,OceanBase 正式投入生产使用,支撑海量交易数据的高效处理。

会员服务平台“新面貌”:稳定、高性能、低成本

构建标准化数据链路,稳定、高效处理海量数据

目前,OceanBase 主要支撑重药集团会员服务平台的分析型业务场景,支撑高并发、多维度的会员数据查询、标签计算、报表生成及精准营销决策。其核心价值体现在:高效处理海量历史数据、支持复杂实时分析、保障查询性能与系统稳定性。

整个数据链路遵循“源系统 → CRM 中转清洗 → OceanBase 分析库”的三层架构,如图6所示。

图6 会员服务平台的数据分析链路

数据来源(源系统)包括POS 订单数据、各渠道会员信息、组织人员数据、会员标签数据、档案测量数据、全部商品主数据。

  • 中转与清洗层(CRM 系统):所有原始数据通过定时抽取或实时接入方式进入 CRM 系统,进行统一的数据清洗、去重、合并与标准化处理。关键处理策略包括历史数据清洗、订单数据合并、积分逻辑处理、会员标签动态更新、消费行为计算、活跃度模型计算。
  • 目标存储与分析层(OceanBase 分析库):清洗后的数据通过同步机制实时或定时写入 OceanBase 分析库;并分为原始数据表、静态化处理表、日表/月表、报表中间表。

通过构建“源数据 → CRM 清洗 → OceanBase 分析库”的标准化数据链路,实现了多源异构数据的统一整合、复杂分析场景的高性能响应、业务数据的长期留存与高效利用。

会员精准筛选复杂场景,查询效率提升 25.7 倍

在重药集团会员服务平台的实际运营中,多维度组合筛选(见图7)是支撑精细化营销与客户管理的核心功能。对于数据库而言,该功能是典型的复杂查询场景,用户需同时基于多个维度进行精确匹配,查询通常涉及多表关联、大量过滤条件和聚合计算,非常考验数据库的执行效率。我们通过开启 OceanBase 的列存模式(Columnar Storage),将原本传统数据库MySQL 的响应时间从 18 秒缩短至 0.7 秒,性能提升达 25.7 倍,满足业务对“实时圈选、即时触达”的严苛需求,显著提升了系统整体吞吐量与用户体验。

图7 会员服务平台多维度组合筛选

数据存储空间省 60%,有效降低存储成本压力

OceanBase 将全量数据划分为两个部分进行管理:一是增量数据(Memtable),即实时写入内存中的热数据,支持快速读写;二是基线数据(静态数据),即经过合并与持久化后的冷数据,存储于磁盘。

对于静态数据,OceanBase 采用高效的压缩算法,对列式存储的数据进行深度压缩,显著减少磁盘 I/O 和存储开销。例如,当原始数据总量为 4TB 时,MySQL 需要完整保留所有数据,存储空间占用为 4TB;而 OceanBase 通过对静态数据进行高压缩处理,仅需 1.5TB 即可承载相同规模的数据。

在重药集团会员服务平台的实际部署中,OceanBase 通过其先进的列式存储引擎与高效压缩算法,显著降低了数据存储空间占用,在同等业务数据规模下实现了 60% 以上的存储空间节约,有效缓解了海量数据带来的存储成本压力。

面向未来,持续推进 OceanBase 的深度集成与价值释放

随着 OceanBase 在重药集团会员服务平台的成功落地,我们对其在更广泛业务领域和客户群体中的应用充满信心。面向 2026 年及未来,我们将围绕场景拓展、客户推广、技术融合与产品适配四大方向,持续推进 OceanBase 的深度集成与价值释放。

应用于更多业务场景与产品

当前,OceanBase 已稳定支撑重药集团会员管理平台的复杂分析型业务(如精准筛选、标签计算、报表生成)。订单处理中心和运营诊断产品也在生产环境开始使用OceanBase,下一步,我们将推动其全面融入日常运营服务场景,包括:实时会员服务、营销活动执行、AI 智能推荐等业务场景。

另外,我们将逐步将 OceanBase 适配至更多内部产品,包括商品主数据管理、患者健康管理平台、智能补货与供应链协同系统,构建以 OceanBase 为核心的统一、弹性、智能的企业级数据基础设施。

向业内客户推荐

在国家信创政策与企业降本增效双重驱动下,我们已将 OceanBase 作为高并发、大数据量、强一致性要求场景下的首选数据库,并向行业客户积极推广。截至目前,已在以下大型医药企业成功落地:扬子江药业集团、鹭燕医学、重药集团、上海医药、国大药房。未来,我们将继续优先推荐 OceanBase 作为会员服务、订单中心等关键系统的数据库底座,助力更多企业完成安全、高效、低成本的国产化替代。

交流开发,沉淀运维经验

为持续提升团队与客户的 OceanBase 应用能力,我们计划定期组织专题培训、参与社区技术沙龙、共建问题解决机制、定期组织数据库培训及实战分享会议,探讨并解决遇到的问题,争取打造一支“懂业务、精技术、能落地”的复合型数据库应用团队。

未来,我们将携手更多合作伙伴,共同探索“数据库 + AI + 行业场景”的创新路径,为医药健康行业的高质量发展注入新动能。


使用 springboot 集成 micrometer 实现自定义 prometheus 指标。
假如在多实例的商城系统中存在一个用于统计商品查看次数的指标,名为 item_view_count ,label:item_idinstance_id
当服务重启时,按照 micrometer 的默认行为,这个指标会被置为 0 。

对于这个行为我想到了两种方案。

  1. 将这个值持久化,并且在第一次创建指标时加载。
  2. 服务重启后使用新的 instance_id ,这样在做 sum 统计时不会被重置影响

各位都是如何处理这个问题呢?

最近做了个小项目:Pocket Shell ,一个移动端友好的 Web 终端。
说实话,它和手机上的 SSH 客户端功能上差不多,并没有什么“颠覆性”。

而且体验比起 Termius 还是差很多

可能适合的人:

  • 不想装客户端、临时在手机浏览器里连一下服务器
  • 想要一个“轻量、可自部署”的网页版终端

主要特性:

  • 移动端优化 UI,输入等
  • 虚拟键盘( Ctrl/Alt/Tab/方向键)
  • 长按方向键手势输入
  • 单二进制部署(前端内嵌)
  • 会话状态恢复

Pocket Shell

项目地址:
https://github.com/zzjcool/pocket-shell

议题分享: When ASUS IoT Devices Play Hide-and-Seek with Security

CVE-2025-36463 Sudo_chroot Elevation of Privilege 漏洞分析

CVE-2025-32023 Redis 漏洞分析

智能体对话正在告别“纯文本时代”!近日,腾讯云智能体开发平台(ADP)重磅上线国内首个“AI 原生 Widget”,面向企业客户提供“富交互任务交付”能力,只需自然语言描述,就能实时生成表单、按钮等交互组件。该能力还同步在腾讯元器(一站式 AI 智能体创作与分发平台)生态侧落地,支持创作者一键生成交互卡片。

 

值得一提的是,这一功能还兼容 OpenAI 生态的 Widget 接入规范,外部 Widget 可依据标准协议直接导入复用,进一步拓展智能体能力边界与生态扩展空间。

 

“AI 原生 Widget”是一种面向智能体任务交付的“富交互组件形态”,模型输出结构化描述(JSON Schema),平台自动渲染为可操作的表单、按钮,并将用户交互结果回传智能体,实现任务闭环执行。

自然语言秒级生成智能体交互组件

在传统的大模型对话中,文本输出是主要形式。海量的文字堆砌,不仅抬高理解成本,而且完成单一任务需要多轮来回沟通,效率低且体验不佳。Widget 作为可嵌入式的自定义展示组件,能在智能体对话流中,灵活融入图表、表单、按钮等“富交互”模块,将对话界面升级为沉浸式任务平台,引导用户按步骤操作,大幅提升信息传递与任务执行效率。

 

当前国内的智能体平台构建 Widget 时,普遍采用传统“拖拉拽式低代码+手动配置字段/数据源映射关系”的方式,流程繁琐、耗时久、稳定性一般,难以适配高效开发的需求。针对这一痛点,腾讯云 ADP 推出的 AI 原生 Widget,提供了模版创建、代码创建、自然语言生成等多种方式,降低开发门槛。即使非专业前端开发者,只需用语言描述需求,或调用现成 Widget 模板,一分钟内就能够生成对应组件,真正实现“所想即所得”。

支持多种 Widget 开发模式

比如用户想要搭建一个“健身小助理”智能体,通过 AI 原生 Widget,输入提示词后,一键就能生成对应卡片。当用户询问“我要跑步”时,系统会弹出预设卡片,引导用户点选运动频率、强度等习惯信息,再根据用户的选择,快速生成“跑步训练周计划”卡片,包含每周运动安排、单次运动内容、时长和强度建议等核心信息。

从纯文本对话到富交互任务执行

虽然我并不认同“IDE 会在 2026 年消亡”这种绝对说法,但 Steve Yegge 和 Gene Kim 在分享中抛出的判断,依然值得认真对待:在他们的推演里,从 2026 年 1 月 1 日起,继续依赖传统 IDE 的工程师,会被更快拉开差距。

他们认为这不是“工具升级”,而是“生产方式换代”:工程师的竞争力,越来越取决于你能否用好新一代 AI 开发方式,以及你愿不愿意为它付出真实成本——例如把每天的 token 开销重新定价到“接近日薪”的量级。

更刺耳的是,他们转述了 OpenAI 的 Andrew Glover 的一项观察:是否使用 Codex,可能会让同级别工程师之间的生产力差距被拉到 10 倍,这让管理层“非常惊慌”,“因为他们甚至可能不得不裁掉 50% 的工程师”。

其核心观点如下:

  • 现在的模型本质上是派一个潜水员下去,让它在代码库里四处探索,即使给它更大的氧气瓶,比如一百万 token,它仍会耗尽。正确做法应该是派多个角色,而不是寄希望于一个超大的单一潜水员。

  • 如果你在 2026 年 1 月 1 日后还在使用 IDE,那你就是一个“不好的工程师”。

  • 作为工程师,我每天花在 Token 上的费用应该与我的日薪相当,也就是每天 500 到 1000 美元。

  • Claude Code 走错了方向,他们造出一只巨大、耗能、高成本的“肌肉蚂蚁”。

 

Steve Yegge:今天的时间会过得很快,我将讨论明年(2026 年)开发工具的样貌。

 

现在所有人都迷恋 Claude Code,市面上大概有四十个竞争者,但 Claude Code 并不是答案,代码补全也不是。

 

虽然我每天使用它十四个小时,但开发者并未真正采纳。核心问题是这些工具使用难度过高,认知负担重,而且常常“撒谎、作弊、偷懒”。因此大多数开发者并不喜欢这样的工具。

 

我逐渐认识到,Claude Code 很像电钻或电锯。对于没有受过训练的人,它既能帮上忙,也能造成巨大损伤。未受训练的工程师使用 Claude Code,与一个新手拿着电锯差不多:既可能“切到脚”,也可能在熟练后完成极其精细的工作。然而软件世界无限广阔,而我们的野心也同样无限。

 

因此我想用一个类比说明:明年将是从“手持电锯、电钻”转向“数控机床(CNC)”的一年。CNC 在给定坐标后能自动执行极其精确的操作,这项技术我们已经使用了数百年,也不会在今年停止。

 

有人说“模型已经触顶了”,你的工程师们可能也这么说。即使如此,我们仍然等同于刚发现蒸汽和电力,还需要时间去驾驭它。现在的问题已经主要是工程问题。一年到一年半内,所有代码都将由大型自动化“磨床”式系统生成,工程师不再直接查看代码。这将是一个全新的世界,而我们正走向那里。

 

Gene 和我曾与 OpenAI 的 Andrew Glover 交流过,他说公司内部出现了明显的分化:部分工程师使用 Codex,而更多人没有用(拒绝使用工具的人主要是资深与 Staff 级工程师),产能差距巨大,导致绩效评估出现警报。两个同级别的工程师,其生产力可能相差十倍,这让管理层非常惊慌,因为他们甚至可能不得不裁掉 50% 的工程师。

 

这种情况类似瑞士机械表产业的衰落:经历数百年的辉煌,却被石英表在短短几年内颠覆,当时的工匠与今天坚持传统方式的资深工程师反应如出一辙。

 

未来需要的是一种全新的 UI,不是传统 IDE,而是新的 IDE。事实上,Replit 已经走得最前,他们的方向非常值得称赞。我们不该再继续追着旧形态、构建各种命令行界面。

 

更重要的是,Claude Code 及其竞争者都走错了方向——它们像在打造“世界上最大的蚂蚁”。

 

我的朋友、澳大利亚联邦银行的 Brendan Hopper 说得很好:自然界靠蚁群协作,而 Claude Code 却造出一只巨大、耗能、高成本的“肌肉蚂蚁”。无论是要分析整个代码库,还是只是问“我的 git ignore 还在吗”,它都调用最昂贵的模型。

于是我想到了“潜水员隐喻”:上下文窗口就像氧气瓶。现在的模型本质上是派一个潜水员下去,让它在代码库里四处探索,即使给它更大的氧气瓶,比如一百万 token,它仍会耗尽。正确做法应该是派多个角色:产品经理潜水员、开发潜水员、代码审查潜水员、测试潜水员、合并潜水员等,而不是寄希望于一个超大的单一潜水员。可没人这么做,大家都在造“大潜水员”。

 

未来的构建方式将是工程师熟悉的:任务分解、逐步细化、组件化、黑盒化,并依赖大量协作的智能体,而不是单一智能体。

但在此之前,我的建议还是:学习 Claude Code 来适应新方式,并放弃你的 IDE。如果你在明年 1 月 1 日后还在使用 IDE,那你就是一个“不好的工程师”。

Gene Kim:我研究高绩效技术组织已有 26 年,这段旅程始于我作为 Tripwire 的技术创始人。我们致力于研究那些表现卓越的技术组织——它们在项目交付、运维稳定性、安全合规方面都处于领先。我们想理解这些组织如何实现“从优秀到卓越”的转变,以及其他组织如何复制这些成果。

 

在这 26 年中我经历了许多意外,其中最大的意外之一,是这项研究最终将我带到了 DevOps 运动的中心。DevOps 改变了测试、运维、信息安全等角色的协作方式。我曾以为这会是我职业生涯中最激动人心的经历,直到我在今年 6 月首次与 Steve Yegge 见面。

 

我和 Steve 有许多共同点,其中之一就是对人工智能的热爱,以及都认为 AI 将从底层重塑软件开发的方式。我们相信,AI 对技术组织的影响,可能比十年前敏捷、云计算、CI/CD 和移动化所带来的变革大上百倍。而这些技术突破不仅会改变组织,也会重塑整个经济,让经济结构围绕更先进的生产方式重新排列。

 

过去一年半,我们观察了许多案例,让我们提前看到未来技术组织的雏形。有人可能熟悉 Adrian Cockcroft,他曾是 Netflix 的云架构师,主导了 2009 年将 Netflix 整个基础设施从自建机房迁移到云端。他在几个月前写道,2011 年有人提出“无运维(NoOps)”时,引发了基础设施和运维团队的强烈反对,但现在类似的事情再次发生,只不过这次可能叫“无开发(NoDev)”。如今看来,这似乎不再好笑。

 

我们从 Zapier 的分享中看到,支持团队能发版,设计师能发版,UX 设计也能直接发版。过去被开发者告知“排队、等一个季度、等一年、甚至永远等不到”的人,现在突然能够自己把功能“对话式地”写进生产环境。这不仅改变技术组织,也可能改变整个经济。

 

Steve 和我很幸运能看到部署方式的改变带来什么影响。十年前,我写了《The Phoenix Project(凤凰项目)》,讲述灾难性的部署流程。当时许多组织一年只发布一次版本,难以想象。后来我参与了 DevOps 状况研究,这项跨行业研究在 2013–2019 年间覆盖了 36,000 名受访者。我们发现,高绩效团队每天能多次部署,并能在一小时内完成一次发布。

 

在 2009 年,多次每日部署被视为鲁莽、不负责任甚至“不道德”,但如今却是常态。若想保持高可靠性、缩短平均修复时间,就必须更频繁地进行更小规模的部署。现在我们看到的案例表明,不再手写代码,而是运用新的方式进行开发,可能是一种价值更优的路径。

 

我们在《Vibe coding》一书中提出的定义是:只要不是靠双手在 IDE 里敲代码的方式,都可以称作“Vibe coding”。有些人还像在暗房里冲洗照片一样,依旧习惯在昏暗环境里手动输入代码。但 Anthropic 联合创始人兼 CEO Dario Amodei 给了我们更好的定义:Vibe coding 是由反复对话推动的、由 AI 生成代码的过程。他说这个词很美,能表达一种全新的开发方式,但也略带戏谑。不过对他们而言,这已经是“唯一的方式”。

 

这是编程语言领域的重要人物 Erik Meijer 博士,他参与过 Visual Basic、C#、Haskell,也在 Meta 推出了 Hack 编程语言,在一年内迁移了数百万行 PHP 代码,引入静态类型检查。他说,我们可能是最后一代手写代码的开发者,所以应该享受这一段最后的旅程。

 

还有一件事是这样的:去年 11 月开始,我一直在观察 Steve,他每天在编码代理上花掉几百美元。这在当时看起来非常奇怪。他不仅把各种月度订阅都用到了上限,实际上还远远超出了这些额度。

但现在我们听到的一种说法是:作为一名工程师,我的工作本身就应该要求我每天在 token 上的花费,和我的日薪大致相当。也就是说,大概每天 500 到 1000 美元。因为这些工具带来的,是一种机械优势和认知优势。作为工程师,我会挑战自己,去榨取这种投入所能带来的最大价值,把成果交付给真正重要的人。

在书中,我们把人们为何愿意这样做总结成一个缩写:FAAFO。

第一个 F 是 Faster(更快),但这是最表层的理由。

 

更重要的是 A-Ambitious(雄心),AI 让我们得以完成过去无法实现的雄心项目,把不可能的事情变得可能。在另一端,琐碎麻烦的小任务也几乎变成了零成本。我非常喜欢 Claude Code 团队中的一段采访,Katherine 说,以前客户问题会被放进 Jira 的待办项,在梳理会议中争论,一拖数周;而现在我们直接在当下修复,并在 30 分钟内发布。记录依然会做,但协调成本几乎完全消失了。也就是说,不可能的事情变得可能,麻烦的小事变得免费。

 

第二个 A 是 Able(能力),代表“更独立”,更能单独完成工作。这里有两类协调成本正被 AI 消除。第一类协调成本来自“等待”。如果你需要开发者或一个团队帮你做事,你必须沟通、协调、同步、排优先级、游说、升级……总之必须让他们“和你一样在乎这个问题”。而现在,依靠这些近乎奇迹般的新工具,你可以自己完成许多工作。第二类协调成本来自“理解”。即使别人愿意像你一样重视某件事,他们也无法读你的心。但我们发现,LLM 是惊人的“协作中介”。仅通过一个 LLM,你就能以 Markdown 文档的形式与不同职能顺畅协同。这当然不是最终形态,但它让高带宽的理解成为可能。因为要想实现共同的成果,就必须先有共同的目标与共同的理解。

 

第二个 F,是 Fun(好玩)。正如 Steve 所说,Vibe coding 具有成瘾性。我们见过两个人原本以为“写代码的黄金时代已经过去了”,结果却意外发现现实恰恰相反。我现在常常玩得太投入,不逼自己去睡就会写到凌晨两三点。它不是只有好的一面,但肯定比无聊、枯燥甚至痛苦要好得多。

 

O 是 Optionality(可选项)。我们非常重视“创造期权价值”。模块化之所以强大,也因为它能创造更高的期权价值。Vibe coding 能让你同时进行更多实验、更多尝试,因此它是极具经济价值的工具。Steve Yegge 说,对于已经经历“顿悟时刻”的人来说,本能反应往往是:如何让团队中所有人都获得与你现在同等的生产力?

 

下面我分享一些让我们看到未来形态的案例。

 

例如,Travelopia 的产品与技术负责人 Sree Balakrishna 的分享。Travelopia 是一家年营收 15 亿美元的旅行企业。他们曾用一个小团队,在 6 周内替换一套传统系统。按过去的方式,需要 8 人(6 个开发、1 个 UX、1 个产品负责人);而现在,也许只需要一个开发与一个领域专家,正如 Kent Beck 所说,“一个有问题的人加一个能解决问题的人”。这种团队规模的变化会深刻影响组织未来的运作方式。

 

我最兴奋的案例来自 Dr. Tapabrata Pal。他在 Capital One 推动过 DevOps,如今在 Fidelity 负责一个关键应用,用来查询公司 2.5 万个应用中哪些受 Log4j 影响。过去他的团队总说重新做这个工具需要 5 个月,并需招聘前端工程师。

 

最终他自己花 5 天 Vibe coding 出了一个版本,并上线生产。他只是想证明:事情完全能做,而且可以更快完成。后续更戏剧的是:他为应用找维护者,资深工程师们都不愿接手,最后是团队中最年轻的工程师成为维护者,并正在快速成长。

 

与此同时,这个应用的内部用户数量增长了 10 倍,他也因此获得更多人手。这些变化是任何人都没预料到的。

 

再分享一个例子,我重返 Google Cloud 团队做的 Dora 研究,其中一项未进入正式报告的发现是关于“AI 信任度”。我们采用的信任定义是:你能多大程度预测对方(AI)的行为?越信任,就能给更大请求,用更少词语,减少反馈需求。结果显示:使用 AI 的时间越长,信任越高。那些说“我试了一下,它写代码很差”的人,多半只用了 1 小时。显然,AI 的掌握是可训练的技能,需要实践,而不是一次性体验。

 

因此,我们的责任之一,是帮助他人获得“顿悟时刻”,并协助他们不断练习,从而真正掌握这些强大的工具。

 

六周前,Steve 和我为领导者们做了一次 Vibe coding 工作坊。三小时内,完成率 100%,每个人都做出了成果。还有一位,他说自己 15 年没写代码了,却在短时间内做出一个自动帮自己抢 Southwest 登机位的工具(直到被反机器人系统封掉),你从他脸上的表情就能看到那种久违的创造力被重新点燃。

所以,当支持团队、领导者能编码并上线时,技术组织必然会重塑。

 

一个技术领导者说,当他告诉团队他写了一个应用,其中 6 万行代码都是 AI 写的,而他自己一行没看时,团队看他的眼神仿佛“希望他不存在”。

 

另一个例子,一些存在十年的遗留系统问题,团队集合资深工程师,用 AI 生成修复方案并提交 Pull Request。这次被接受了,而不像过去那样被污名为“AI 生成的低质量内容(AI slop)”。还有团队说,他们现在的代码提交速度如此之快,以至于每个代码仓库只能容纳一个工程师,否则合并冲突会让协作成本爆炸。

 

参考链接:

https://www.youtube.com/watch?v=cMSprbJ95jg&t=4206s

 

“今年上半年我在山东临沂见了一位满头白发的 90 后老板,他们公司的年销售额超过 3 亿元,但利润却不到 1000 万。”1688商家发展中心总经理王强在日前接受媒体采访时讲道,“白天睡觉、晚上陪客户,这是他们为此生意的主要方式。”

事实上,这不是个例,而是中国数百万中小工厂主的真实缩影——规模在增长,利润在萎缩;订单在增加,确定性在流失。

这种悖论背后,是一场深刻的结构性撕裂,是当前 B2B 产业面临的系统性挑战:合规成本持续攀升,环保、税务、用工等要求日益刚性;与此同时,供给极端碎片化、需求高度非标化,交易决策链冗长,产业经验变得难以沉淀和复用。这使得过去依靠压价和人情关系维系的生意模式,在今天已经难以为继。

换言之,中国产业带的底层逻辑正在被彻底重构,“K 型复苏”成为新常态,头部企业加速扩张,尾部企业加速出清,一个尖锐的问题摆在所有中小工厂面前——出路究竟在哪?

1688 在刚刚发布的《2025 中国产业带发展趋势报告》(以下简称“报告”)中给出了他们的答案:2025 年,中国产业带开始迈向 AI 原生时代。这不是又一次简单的工具升级,而是一场历史性跨越:从“数字化”向“智能化”的范式转变。在这场变革中,AI 不再是可有可无的“外挂”,而是决定生死存亡的“操作系统”。

该报告基于 1688 平台 26 年产业带深耕经验,整合覆盖全国 70%一级产业带、超百万家源头厂商的真实交易大数据,系统分析了 AI 在产业带的演进路径。

从“卷成本”到“拼确定性”,中国产业带的游戏规则正在被重写

如果说过去二十年产业带的竞争关键词是“规模”与“成本”,那么今天,“确定性”正迅速取代“低价”,成为新的护城河。所谓确定性,不只是按时交货,更包括产品品质稳定、服务响应及时、需求预测精准、合规风险可控。并且,这些变化的覆盖范围不仅限于国内市场,更是全球性的。

报告指出,产业带“江湖规矩”和“权力地图”正被彻底重写,“外转内”与“内转外”并行,产能外迁与产业内移共振,工厂正从“代工者”蜕变为“品牌主”。

而 AI,成了构建确定性的核心引擎,基于 AI 原生的下一代供应链呼之欲出。

据王强分享,深圳一家 3C 配件厂商深圳众鑫通泰曾深陷“低价、欠款、无客”的死循环,但他们通过 AI 分析亚马逊上的用户差评发现,一款手机支架的核心痛点是“粘不牢、价格高”,并据此开发出了采用真空磁吸技术的新品,同时,借助 AI 生成的油管爆款视频进行推广,这家工厂最终实现了跨境业务占比突破 70%,毛利率远超同行。

另一家位于安徽芜湖的一个 6 人鞋企也在 2024 年借助 AI 工具实现了惊人跃升:上新效率提升 4 倍,支付转化率提升 41%,全年销售额达 1.5 亿元。他们没有设计师,就用 AI 完成换色、场景图和视频生成;没有客服团队,就部署 7×24 小时自动响应系统;甚至通过 AI 分析 TikTok 热门搜索词,捕捉全球潮流趋势。“AI 已经是趋势了,等别人都试完再上,你就被淘汰了。”芜湖苏禾鞋业张云这样说。

类似的故事正在更多产业带上演。报告显示,和这些工厂一样,越来越多的中小企业正通过 AI 将内贸积累的柔性快反、品控能力“翻译”为跨境竞争力。AI 不再只是巨头的游戏,它同样成为了小微商家对抗规模劣势的“杠杆”。

具体而言,AI 已深度融入商家端的三大核心场景:选品方面,通过全球电商平台评论与社媒热词,反向定义产品;小单快返方面,基于柔性供应链使得响应周期大幅缩短;智能质检方面,用图像识别替代人工目检,使得效率大幅提升。

1688 公共事务部总经理范敏强调,这些变化背后指向了这样一种进化逻辑——AI 正在驱动三大“位移”:

第一,决策机制位移,从依赖“老师傅经验”转向依赖“AI 产业大脑”;第二,组织形态位移:从“人盯人”管理转向“AI 调度+人机协同”;第三,核心竞争力位移,从“模具和产能”转向“数据驱动的快速迭代能力”。

正如报告所示,2026 年起,增长将向能稳定交付、直连用户、自主开款的源头工厂集中。未来的赢家,不是规模最大、也不是成本最低的,而是将 AI 融入血液,构建起“效率×合规×确定性”新护城河的企业” 。在这个新规则下,“确定性”本身就成了最稀缺的资源,能否用好 AI,则成了企业穿越周期的关键。

超越“生意搭子”,AI 从来不只是一个工具

当然,这场跃迁并非坦途。数据孤岛、模型泛化能力不足、复合型人才短缺仍是大多数企业在 AI 应用落地过程中遇到的主要瓶颈。尤其在传统产业带,许多工厂连基础的 ERP 系统都没能打通,导致 AI 系统缺乏高质量、结构化的数据输入。

面对这些现实约束,企业可以选择从最小可行场景切入,以业务价值反推技术建设。以深圳众鑫通泰为例,他们并不是从一开始就试图构建“全厂智能大脑”,而是聚焦一个具体痛点——“用户为什么差评我们的手机支架?” 通过抓取公开电商平台评论这一无需内部系统打通的外部数据源,快速验证了 AI 选品的价值,再逐步将成功经验延伸至生产排程与质检环节。这种“由外而内、由点及面”的路径,有效绕开了初期数据孤岛的制约。

针对模型泛化难题,目前市场上已经有平台开始探索基于跨商家、跨品类的聚合数据,提炼具有行业共性的智能能力。比如 1688 依托其覆盖全国 70%一级产业带的交易网络,正尝试把成功案例中从选品洞察、质检规则到履约优化的 AI 应用逻辑,抽象为可借鉴的方法论甚至工具原型,以降低单个工厂的试错成本。

而破解人才困局的关键,在于构建“人机协同”的新工作流,而非追求全能型个体。拿芜湖苏禾鞋业这个 6 人企业来说,他们并没有 AI 工程师,也没有技术背景,仅仅通过应用 AI 工具,就实现了设计、营销与客户服务的全面提效。

王强表示:“未来的 AI 的卷应该是,你是不是让 AI 把你做成一套的体系或系统?而不仅仅是一个工具。” 换言之,AI 的价值不在于炫技,而在于能否系统性解决已知问题。

报告中对中国产业带进化进行了三阶段划分,随着 AI 应用深度的变化,企业将从“AI 外挂”进入“AI 共生”乃至“AI 原生”。而这也恰恰是企业应对以上一系列挑战的底层逻辑,企业不应该把 AI 当作一个孤立的技术项目,而是将其视为重构业务流程、组织协作与客户价值的契机。

对于身处这一变革浪潮中的企业,报告还给出了三条行动建议:

第一,要信仰 AI,用 AI 做生意,把工厂变成真正的“硅基工厂”——让每一条产线都听得懂需求、看得见订单、控得住质量;第二,要做足确定性,品控要硬、履约要稳、服务要好;第三,要布局双循环,AI 正在模糊内需与跨境的边界,因此企业需要一套 AI 系统,通做全球生意。

当 AI 不再是“生意搭子”,而成为产业运行的“智能中枢”,中国制造业的下一轮红利,才真正拉开序幕。这场变革不会一夜完成,但方向已然清晰:谁能把不确定性转化为确定性,谁就能在新秩序中占据主动。而 AI,正是那把最关键的钥匙。

现在,大模型可以独立写完整整一个浏览器了?

 

Cursor CEO Michael Truell 最近分享了一项颇为吸睛的实验:他们用 GPT-5.2 让系统连续不间断运行一周,从零构建出一个“可用”的 Web 浏览器。按他的描述,产出规模达到:超过 300 万行代码、横跨数千个文件,全部通过这套 AI 驱动的编程平台生成。

 

数百个 Agent “从零”写了一个浏览器?

 

按照他的说法,这个项目并没有依赖现成的渲染引擎,而是用 Rust 从零实现了一整套渲染引擎,其中包括 HTML 解析、CSS 级联规则、布局计算、文本排版(text shaping)、绘制(paint)流程,甚至还实现了一个自定义的 JavaScript 虚拟机。

 

Truell 也坦言,这个浏览器目前只是“勉强能用”,距离 WebKit 或 Chromium 等成熟引擎还有很大差距;但团队依然“感到震惊”,因为简单网站在它上面渲染得很快,而且整体效果在很大程度上是正确的。

 

与此同时,Cursor 还发布了一篇博客文章,题为《Scaling long-running autonomous coding》(扩展长时间运行的自主编程)。文章回顾了一系列实验:让“编程 agent 连续自主运行数周”,目标是“理解在那些通常需要人类团队耗费数月完成的项目中,agentic coding 的能力边界究竟可以被推进到什么程度”。

 

在这篇文章里,他们重点讲的是多 Agent 如何协同:如何在单个项目上同时运行数百个并发 Agent、如何协调它们的工作,并观察它们写出超过一百万行代码和数万亿个 token 的过程与经验。

 

Cursor 先承认了单个 Agent 的局限:任务规模一大、依赖一复杂,推进速度就会明显变慢。并行化看似顺理成章,但他们很快发现,难点不在并发,而在协同。

 

“学习如何协同:我们最初的方法是让所有 agent 具有同等地位,并通过一个共享文件自行协同。每个 agent 会检查其他 agent 在做什么、认领一个任务并更新自己的状态。为防止两个 agent 抢占同一项任务,我们使用了锁机制。

 

这一方案在一些有趣的方面失败了:

 

agent 会持有锁太久,或者干脆忘记释放锁。即使锁机制正常工作,它也会成为瓶颈。二十个 agent 的速度会下降到相当于两三个 agent 的有效吞吐量,大部分时间都花在等待上。

 

系统非常脆弱:agent 可能在持有锁的情况下失败、尝试获取自己已经持有的锁,或者在完全没有获取锁的情况下更新协调文件。

 

我们尝试用乐观并发控制来替代锁。agent 可以自由读取状态,但如果自上次读取后状态已经发生变化,则写入会失败。这种方式更简单、也更健壮,但更深层的问题依然存在。

 

在没有层级结构的情况下,agent 变得非常规避风险。它们会回避困难任务,转而做一些小而安全的修改。没有任何一个 agent 承担起解决难题或端到端实现的责任。结果就是工作长时间在空转,却没有实质性进展。”

 

为了解决这一问题,Cursor 最终引入了更明确的角色分工,搭建一条职责清晰的流水线:将 Agent 分为规划者和执行者。

 

“规划者(Planners) 持续探索代码库并创建任务。他们可以针对特定区域派生子规划者,使规划过程本身也可以并行且递归地展开。

 

执行者(Workers) 领取任务并专注于把任务完成到底。他们不会与其他执行者协调,也不关心整体大局,只是全力处理自己被分配的任务,完成后再提交变更。

 

在每个周期结束时,会有一个评审 Agent 判断是否继续,然后下一轮迭代会从干净的初始状态重新开始。这样基本解决了我们的协同问题,并且让我们可以扩展到非常大的项目,而不会让任何单个 Agent 陷入视野过于狭窄的状态。”

 

在此基础上,Cursor 把这套系统指向一个更具挑战性的目标:从零构建一个浏览器。他们表示,Agent 持续运行了将近一周,在 1,000 个文件中写出了超过 100 万行代码(原文如此,跟 Michael Truell 说的 300 万行不同),并将源码发布在 GitHub 上供外界浏览。

 

Cursor 进一步宣称:即便代码库规模已经很大,新启动的 agent 仍然能够理解它并取得实质性进展;同时,成百上千个 worker 并发运行,向同一个分支推送代码,而且几乎没有冲突

 

一场“全民打假”的开始?

 

这次实验之所以引发强烈反应,很大程度上是因为:Web 浏览器本身就是软件工程里公认的“地狱级”项目。

 

它难的不只是“写代码”,而是工作量的量级、模块之间的高耦合,以及兼容性这条几乎看不到尽头的长尾。

 

在 Hacker News 上,有人顺手抛了一个问题:“开发一个浏览器最难的地方是什么?”很快就有人给出一个类比:“说句真心话,这个问题几乎等同于:开发一个操作系统最难的地方是什么?”

 

因为现代浏览器是千万级代码量的系统,能够运行非常复杂的应用。它包含网络栈、多种解析器、frame 构建与回流(reflow)模块、合成(composite)、渲染(render)与绘制(paint)组件、前端 UI 组件、可扩展框架等等。这里面每一个模块,都必须同时做到:既支持 30 年前的旧内容,也支持复杂得离谱的当代 Web 应用。同时,它还得在高性能、高安全前提下尽可能少占用系统资源,并且往往要跨 Mac、Windows、Linux、Android、iOS 等多个平台运行。

 

还有人提到,最难的是那张超长的任务清单。浏览器里包含多个高复杂度模块,每一个单拎出来都可能要做很久;更麻烦的是,它们之间还要通过一套相当“啰嗦”的 API 连接起来——很多接口你必须实现,至少也得先把壳子(stub)搭出来,否则系统就会崩。

 

对这个浏览器项目,Cursor 在博客中写道:“虽然这看起来像是一张简单的屏幕截图,但从头开始构建一个浏览器是非常困难的。”

然而如果外界自己去尝试编译这个项目,会很快意识到:它离“功能齐全的浏览器”还差得很远,甚至看起来在公开代码状态下,连最基本的构建都很难稳定通过。

 

从仓库公开信息来看,近期 main 分支的多次 GitHub Actions 运行结果显示失败(其中还包括工作流文件本身的错误);不少开发者的独立构建尝试也报告了数十个编译错误。与此同时,最近的一些 PR 虽然被合并,但 CI 仍处于失败状态。

 

更有开发者表示自己回溯 Git 历史,往前翻了约 100 个提交后表示,依然没能找到一个可以“干净编译通过”的版本。

 

这也引出了一个问题:这些被 Cursor 描述为在代码库中长期并发运行的“agent”,在工程链路上到底做到哪一步?至少从当前公开状态看,它们似乎并没有把“能编译、能检查”当成最基础的收敛目标——因为无论是 cargo build 还是 cargo check,都会立刻暴露出成片的编译错误和大量警告。

 

而 Cursor 的博客文章除了提供代码仓库链接外,既没有提供可复现的演示,也没有提供任何已知的有效版本(标签/发布/提交)来验证截图。无论如何,这文章本身给人一种原型功能完备的错觉,却忽略了此类声明应有的基本可复现性特征。

 

有人在 Michael Truell 的 LinkedIn 上直接把结果抛了回去:“构建直接失败,报了 32 个错误,代码本身就是坏的;没有任何 release、没有 tag,CI 也在持续失败,我们甚至连这个所谓‘可用的浏览器’都没法编译、没法试跑。这更像是一场营销活动,而不是一次真正的 agentic 实验。”Michael Truell 至今没有回复。

 

目前唯一一个在社交平台上明确分享“复现成功”的人,是前浏览器开发者 Oliver Medhurst。他表示自己花了大约两个小时修复编译错误和漏洞,才把项目跑起来。至于性能,他的评价也很直接:有些页面加载要整整一分钟,“不算好”。

 

还有一个更敏感的追问也随之出现:“所以这真的是从零开始写的吗?”他给出的回应更像一句反转预告:“剧透:不是。”

 

更多网友通过翻看仓库依赖发现,这个项目直接引入了 Servo (一个最初由 Mozilla 开发的基于 Rust 的浏览器)项目的 HTML 与 CSS 解析器(html parser、css parser),以及 QuickJS 的 Rust 绑定(rquickjs),并非所有关键组件都是自行实现。

 

再加上 selectors、resvg、wgpu、tiny-skia 等一系列成熟库,这个“浏览器实验”更像是直接调用了人类编写的代码,而不是“从零开始”的一整套渲染与执行引擎。

 

更搞笑的是,Cursor 这里用的还是一个发布于 2023 年 6 月的 wgpu 0.17 这种非常旧的老版本,而当前最新版本已经是 28(发布于 2025 年 12 月)。大概因为大模型写代码时往往会直接改版本管理文件(如 package.json、Cargo.toml),而不是通过 npm add、cargo add 这类构建工具来引入依赖。

 

这也不怪网友骂他们:

 

“这简直是胡扯。应用根本跑不起来,功能也缺得厉害。LLM 更像是在把它训练过的现成代码拼起来做个浏览器——毕竟 Chromium 本来就是开源的。最后堆出了 300 万行‘看起来很多’但没有价值的代码,结果还不能用,更谈不上什么新产品。折腾到最后,你还是得让开发者花大量时间去调试、排查安全漏洞,才能把它打磨得像一个早就存在的成熟产品。”

 

“两周时间、数百个 agent,V8 和 Blink 又都是开源的。说到底,这就是在浪费 GPU 和电力。”

 

最后值得一提的是,这个实验还暴露出一个不容忽视的问题:成本。

 

有人翻回 Cursor 的原帖指出,他们还在跑类似实验,比如一个 Excel 克隆项目(https://github.com/wilson-anysphere/formula)。GitHub Actions 的概览数据很夸张:累计触发了 16 万多次 workflow 运行,但成功的只有 247 次——失败的主要原因不是代码本身,而是超出了支出上限。

 

当然,Agent 并不在乎预算;但在真实的软件工程里,可复现的构建、可持续的成本、可验证的产出,才决定一个系统最终能不能被信任、被维护、被继续推进。

 

参考链接:

https://cursor.com/cn/blog/scaling-agents

https://news.ycombinator.com/item?id=46646777

https://www.reddit.com/r/singularity/comments/1qd541a/ceo_of_cursor_said_they_coordinated_hundreds_of/

https://www.linkedin.com/posts/activity-7417328860045959169-PFuT/

https://xcancel.com/CanadaHonk

是的,PHP 拥有光明的未来。各位看官可能会觉得这是玩笑,但您别急,且听我扯几句。这不是标题党,也不是哗众取宠。这是楼主近几天实实在在的有感而发。

这一切源于最近我家小朋友有了编程的兴趣;在尝试学第一门编程语言。让我意想不到的是,他选择了 PHP 。我很惊讶,PHP 不是没落了吗?大家讨论的都是 JS ,Go ,Rust ,Python 等等热门语言,按理说小孩网上怎么搜也不会蹦出 PHP 这三个字母吧。令我更意想不到的是,他学得津津有味。而且已经有了一些成果。观察几天后,我才发现,这一切并非偶然。

最重要一点因素,是 PHP 有最友好的社区,没有之一。不管是内外网,PHP 社区有极高的包容度。PHP 的讨论区很少有无谓的争吵,虚荣的推销。相反,PHP 社区有很多在其他圈子少见的谦逊与耐心 — 这也是我小孩喜欢网上讨论 PHP 的关键因素:当其他社区因为一个语法糖,一个框架,一个包争得面红耳赤时,经验丰富的 PHP 程序员却愿意放下姿态去回答几岁小孩的入门问题。进入 Zig ,Rust 等等社区,你会看到如邪教一般的传道与重写,我一个大人都有点承受不住。为了小孩的身心健康,我打心底更愿意小孩在 PHP 社区成长。

另外,不管喜不喜欢这门语言,少有人会否认 PHP 一直是一门及其实用且稳定的语言。尤其在 web 1.0 时代,PHP 绝对是指哪打哪的大杀器。哪怕是今天,快速迭代一个中小型全栈项目,很多人都会拿起 Laravel/ThinkPHP 。而现代化的 PHP 8 更是吸收了各家所长,OOP ,函数式,协程,可以说要什么有什么。更难能可贵的是在快速迭代的同时依然保持了高度的兼容性。对比乱成一锅粥的 Node/JS ,小孩写的 PHP 代码,不管是老语法,还是旧框架,往往都能运行,正向反馈频繁。我相信现在这些代码 5 年后依然能正常运行。

看到这里,您可能就明白我为什么说 PHP 有光明的未来了。后浪推前浪,世界终归是我们下一代的。当孩子们选择了 PHP ,他们怎么不会再一次为 PHP 带来阳光呢。

— 于 PHP 8.5 发布日

temporal 官网示例

python:

@workflow.defn
class SleepForDaysWorkflow:
    # Send an email every 30 days, for the year
    @workflow.run
    async def run(self) -> None:
        for i in range(12):
            # Activities have built-in support for timeouts and retries!
            await workflow.execute_activity(
                send_email,
                start_to_close_timeout=timedelta(seconds=10),
            )

            # Sleep for 30 days (yes, really)!
            await workflow.sleep(timedelta(days=30))

ruby:


# Send an email every 30 days, for the year
class SleepForDaysWorkflow < Temporalio::Workflow::Definition
  def execute
    12.times do
      # Activities have built-in support for timeouts and retries!
      Temporalio::Workflow.execute_activity(
        SendEmailActivity,
        start_to_close_timeout: 10
      )

      # Sleep for 30 days (yes, really)!
      Temporalio::Workflow.sleep(30 * 24 * 60 * 60)
    end
  end
end

C#:

[Workflow]
public class SleepForDaysWorkflow
{
    // Send an email every 30 days, for the year
    [WorkflowRun]
    public async Task RunAsync()
    {
        for (int i = 0; i < 12; i++)
        {
            // Activities have built-in support for timeouts and retries!
            await Workflow.ExecuteActivityAsync(
                (Activities act) => act.SendEmail(),
                new() { StartToCloseTimeout = TimeSpan.FromSeconds(10) });

            // Sleep for 30 days (yes, really)!
            await Workflow.DelayAsync(TimeSpan.FromDays(30));
        }
    }
}

PHP:

class SleepForDaysWorkflow implements SleepForDaysWorkflowInterface
{
  // Send an email every 30 days.
  public function sleepForDays(): void
  {
      for ($i = 0; $i < 12; $i++) {
          // Activities have timeouts, and will be retried by default!
          $this->sendEmailActivity->sendEmail();

          // Sleep for 30 days (yes, really)!
          Workflow::sleep(30 * 24 * 60 * 60)
      }
  }
}

感觉对于 java 程序员 php 的心智负担好小啊

「一键部署你的专属服务器」——WNMP 一键包,让 Web 环境搭建回归简单

还在为 Nginx + PHP + 数据库 的复杂安装而头疼吗?
WNMP 一键包,让这一切变成——一行命令搞定。

apt install -y curl && curl -fL https://wnmp.org/zh/wnmp.sh -o wnmp.sh && chmod +x wnmp.sh && bash wnmp.sh

一分钟安装完整 Web 环境:

  • Nginx 1.28.0 (支持 HTTP/2 、WebDAV 、Stream )
  • PHP 8.2–8.5
  • MariaDB 10.6 / 10.11 (内置 Mroonga 全文搜索引擎)
  • 自动 SSL 证书( acme.sh
  • WebDAV 云盘支持(拒绝明文 FTP )

系统自动优化:

  • 启用 BBR/FQ 网络加速
  • 关闭 THP ,优化内核参数
  • 全面适配 Debian 12/13 、Ubuntu 22–25 、WSL2
  • 自动生成安全配置,默认防止常见漏洞

安全为先 · 默认即最优:

  • 内置 SSH 密钥登录
  • PHP 默认关闭危险函数
  • phpMyAdmin 启用 BasicAuth 双重防护
  • SSL 证书全自动签发与续期

面向开发者与站长的真正“零阻力”方案:
无论你是独立开发者、云服务商、还是边缘节点运维者,WNMP 让服务器环境部署变得和安装浏览器一样简单。
轻量、稳定、可复制 —— 一次配置,永久受益。

官方网站: https://wnmp.org
社区支持:QQ 群 1075305476 | Telegram @wnmps
Github:[url]https://github.com/lowphpcom/wnmp[/url]
开源协议:GPLv3

WNMP 不仅仅是一个脚本,它是下一代 PHP 运行环境生态的起点 ——
基于 LOWPHP 的常驻内存架构,未来将带来原生级的高性能 PHP 体验。

使用的测试文件 info.php,调用 php.info();
现在网站需要放在其他路径底下,修改了 nginx 中的 root 之后就提示 No input file specified.
但是 index.html 静态文件显示正常

在网上查的和 gpt 问,试过以下几种方式还是不行,求大佬帮忙看下

1 ,php74/etc/php-fpm.d/www.conf 文件中 chroot 和 chdir 参数都是默认注释的,
在 info.php 中,参数显示如下
USER www-data
HOME /var/www

2 ,nginx 中的 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
$document_root 或者修改成绝对路径也不行

3 ,修改 cgi.fix_pathinfo=0

4 ,;cgi.force_redirect=1 取消注释

上述的 4 种方式最多就是某 2 个一起试过。
关于文件权限问题,/var/www 使用的是 777 ,html 和我想放的文件夹 site 的权限也是 777 ,site 和网站文件的属组和属主都是 www-data
php74/etc/php-fpm.d/www.conf 文件中


user = www-data

group = www-data

listen = /run/php74-fpm.sock

listen.owner = www-data

listen.group = www-data

listen.mode = 0660


/run/php74-fpm.sock 的属组和属主是 www-data

求大佬帮忙看下还有什么办法嘛,想放到/var/www/site 文件夹下

PHP 用了十年了,也停滞在某个版本很多年了。

最近项目重构,用新的库,一开始用 laravel ,九牛二虎搞起来,感觉好复杂,还慢,就搞了 flightphp ,快十倍,也简单。但是,现在又发现 go ,flightphp 是猎豹,go 就是火箭啊。作为 web api ,也就基本 crud 工作,go 应该能很好的完成。数据库,ai 时代,完全可以用原生 SQL 了。

这次如果重构完成,那就要和 PHP 拜拜了,因为 WEBAPI 如果用 GO ,就没有地方用他了,测试用 PYTHON 大数据用 PYTHON EXCEL 用 PYTHON ,前端用 SVELTEKIT ,其他用 GO

这样子看,PHP 是不是快死了?微服务+ AI 时代,他没有擅长的技能,各个模块都被其他语言代替?

GitHub 仓库地址:https://github.com/fawdlstty/faml

什么是 FAML ?

FAML 是一种扩展自 TOML 的动态配置语言,专为需要运行时配置计算和更新的场景设计。它保留了 TOML 的简洁语法,同时增加了动态表达式、条件配置和运行时可变性等高级特性。

核心特性对比

特性 TOML KCL PKL FAML
语法风格 TOML 风格 JSON 风格 结构体风格 TOML 风格
动态表达式
条件配置
运行时修改
特殊数据类型

快速示例

基本语法

[server]
port = 8080
host = "localhost"

动态表达式

[database]
host = "localhost"
port = 5432
connection_string = $"postgresql://{host}:{port}/mydb"

条件配置

[app]
env = "production"

@if env == "development"
log_level = "debug"

@if env == "production"
log_level = "error"

特殊数据类型

[cache]
ttl = 5 minutes
max_size = 100 MB

[network]
timeout = 30 seconds
buffer_size = 4 KB

复杂表达式

[user]
age = 25
is_adult = age >= 18
welcome_message = is_adult ? $"Welcome, adult user!" : $"Welcome, young user!"

运行时动态修改

let mut config = FamlExpr::from_str(config_str)?;
config["server"]["port"].set_int(9000);  // 动态修改端口
let connection_string = config["database"]["connection_string"].evaluate()?.as_str();  // 自动更新连接字符串

文末广告 :)

2025

2024

I have much less spare time this year because I have a baby :p. And I'm looking for a sustainable way to contribute.

I joined the Rust compiler team (in 2024! :3).

LLVM: A performance regression in LLVM that affected Ajla and Python

This regression has been discussed elsewhere; see lobste.rs/s/9paxz2/performance_python_3_14_tail_call.

I introduced the regression due to a limit for compile time in llvm#78582.
Finally, I learned a resolve from GCC, and then I fixed the regression in llvm#114990 and llvm#132536.

Rust: Transforming “Clone” to “Copy”

To me, the most interesting issue is rust#128081.

The "Clone" method can be transformed to "Copy" in GVN. I have several PRs for this and am working on more.

The first key PR (rust#128299) exposed variant miscompilations. Camille Gillot identified the root cause in rust#147844:

We can reason with the value behind a reference because it is UB to directly assign to the underlying local while the reference is live. We allow creating new derefs, this means extending the liveness of references, so we are creating UB.

Rust: Debuginfo in MIR Basic Blocks

rust#129931 turns out that handling Debuginfo in MIR Basic Blocks is required. I implemented this in rust#142771.

This left some stuff:

Rust: 4 P-critical

I caused 4 P-critical issues. :(

The rust#124150 and rust#132353 are miscompilations in MIR opt. I'm investigating some translation validation tools, such as Miri, Alive2, and model checker, but I haven't made any progress. So far, I have only read Program Z3, and I have forgotten many things. Furthermore, I'm thinking about picking it up next year. :p

Other

While reviewing PRs can be exhausting, it's also a great learning opportunity. For instance, working through PRs like rust#142707, rust#143784, rust#136840, and rust#133832 taught me a great deal.

I realize that the knowledge of the LLVM backend is essential to me, since more and more issues happened in the LLVM backend. I'm not sure how to tackle these issues, but I have begun studying LLVM Code Generation: A deep dive into compiler backend development.

MIR optimizations are still important to me. I'd like to thank Camille Gillot for their help on MIR.

I'm trying to immerse myself in English, and I have stopped using LLM for Chinese-to-English translation anymore. :p

I'm also learning Japanese for fun. If you are interested in anime and manga, I recommend you read learnjapanese.moe.


家里没地方了 :(,卖掉我的 7950X 主机:

  • CPU:AMD 7950X
  • 主板:华硕 TUF GAMING B650M-PLUS
  • 内存 2 条:金士顿 FURY 32G D5 6000
  • 水冷:华硕 ROG STRIX 飞龙二代 360
  • 硬盘:ZHITAI TiPlus7100 2TB
  • 硬盘:Samsung SSD 980 PRO 2TB
  • 显卡:AMD 撼讯 RX6600
  • 电源:先马 XP850W 白金
  • 机箱:乔思伯 松果 D31

价格 11000 。

我使用 Koa 很多年了,一直很喜欢它简洁的设计哲学。近几年在 Cloudflare Worker 上开发较多,接触到了 Hono 。Hono 也是一个不错的框架,但在深入使用后,我对它的一些设计理念并不是很认同,于是萌生了自己造个轮子的想法。

我为新框架设定了三条核心原则:

  1. 微内核架构:与 Koa 类似,保留了洋葱模型的中间件设计,同时还补充了插件系统
  2. 符合直觉的 API 设计:摒弃 Koa 的 delegates 思路,API 严格区分 ctx/ctx.req/ctx.res ,更加符合语义
  3. 环境无关性:可在 Node.js 、Bun 、Deno 以及 Cloudflare Worker 、Vercel 等边缘环境运行

于是 Hoa 诞生了。目前我跟另一个维护者已经为 Hoa 补充了近 30 个常用中间件,我也已经将手头大部分项目从 Koa 迁移至 Hoa 。今天分享出来,希望更多人去使用,也期待收到更多反馈,共同把 Hoa 框架打磨得更好。

特点

  • ⚡ Minimal - Only ~4.4KB (gzipped).
  • 🚫 Zero Dependencies - Built on modern Web Standards with no external dependencies.
  • 🛠️ Highly Extensible - Features a flexible extension and middleware system.
  • 😊 Standards-Based - Designed entirely around modern Web Standard APIs.
  • 🌐 Multi-Runtime - The same code runs on Cloudflare Workers, Deno, Bun, Node.js, and more.
  • ✅ 100% Tested – Backed by a full-coverage automated test suite.

安装

npm i hoa --save

快速开始

import { Hoa } from 'hoa'
const app = new Hoa()

app.use(async (ctx, next) => {
  ctx.res.body = 'Hello, Hoa!'
})

export default app

License

MIT