包含关键字 typecho 的文章

如果你的网页或移动应用依赖流畅、友好的触控界面,那么你极有可能正在使用 Swiper

Swiper 被公认为免费且现代化的移动端触控轮播组件,支持硬件加速过渡与原生级体验,是移动端网站、Web 应用、原生 / 混合应用的核心基础组件。然而,新近公开的一项高危漏洞,正迫使全球开发者紧急修补其软件供应链。

该漏洞编号为 CVE-2026-27212,安全评级为严重,CVSS 评分高达 9.4,可使应用遭受极具威胁的原型污染攻击

漏洞影响 npm 包 swiper范围极广的版本

>=6.5.1,<12.1.2

该漏洞尤为值得关注的点在于:它绕过了此前的安全修复

官方公告指出:

“尽管此前已通过检查用户输入是否包含禁用键来尝试缓解原型污染,但攻击者仍可通过构造基于 Array.prototype 的输入,实现对 Object.prototype 的污染。”

该漏洞的根本原因已定位到特定工具类文件:

“漏洞位于 shared/utils.mjs 的第 94 行,代码使用 indexOf() 检查用户输入是否包含禁用字符串,但校验逻辑存在缺陷。”

研究人员确认:该漏洞在 Windows、Linux 系统,以及 Node、Bun 运行时中均能利用,影响范围极广。

原型污染是一类极其隐蔽且危险的漏洞,其最终影响范围高度依赖应用所处的整体环境。

安全报告警告:

任何使用该组件处理攻击者可控输入的应用,都可能受到影响。

一旦被成功利用,攻击者可借助 CVE-2026-27212 实施三类典型攻击:
  • 认证绕过

    通过污染原型链,攻击者可暗中篡改应用内身份认证与权限校验逻辑。


  • 拒绝服务(DoS)

    攻击者可直接导致应用崩溃。报告说明:即便无法直接在 Swiper 中利用原型污染,若项目其他依赖存在原型污染,修改全局 Array.prototype.indexOf 后,当调用 swiper.default.extendDefaults 时,也会因 Swiper 依赖该全局属性而直接崩溃。


  • 远程代码执行(RCE)

    这是最严重的后果。若被污染的属性被传入 evalchild_process 等危险执行点,攻击者可实现完整远程代码执行,进而接管目标系统。


鉴于 Swiper 在现代网页与移动应用中覆盖面极大,安全团队必须迅速行动以封堵该攻击面。

组件维护方已修复该问题,12.1.2 及以上版本已完成安全加固。

官方强烈建议开发团队立即审计依赖树,并将 swiper 升级至最新安全版本,以避免可能造成的严重安全入侵。

美国网络安全和基础设施安全局(CISA)发布警告,多款广泛使用的工业物联网设备存在多处高危漏洞。通报指出,济南有人物联网技术有限公司(PUSR)生产的 USR‑W610 串口服务器 存在多项底层安全缺陷。
对管理员而言最严峻的问题是:该系列设备已正式停止服务(EOL),官方将不再提供任何安全补丁
这批漏洞中危害最严重的是 CVE‑2026‑25715CVSS 评分高达 9.8,属于特级高危漏洞

该漏洞源于设备管理逻辑的底层设计缺陷

官方通报显示:设备的 Web 管理界面允许将管理员用户名和密码设置为空值

一旦如此配置,对网络安全将是毁灭性打击

报告警告:设备允许通过 Web 管理界面和 Telnet 服务使用空凭证登录,这相当于直接关闭了所有关键管理通道的认证机制同一局域网内的任意攻击者无需密码即可获取完整管理员权限

除登录绕过漏洞外,USR‑W610 还缺乏现代加密机制,界面安全设计存在严重问题:
  • 明文窃听漏洞(CVE‑2026‑24455)

    设备不支持 HTTPS/TLS,仅使用过时的 HTTP 基础认证。这会导致流量仅编码不加密,同一局域网内的攻击者可轻松截获用户凭证


  • 密码明文显示漏洞(CVE‑2026‑26049)

    设备 Web 界面会在输入框中明文展示密码,任何能接触到管理界面的人员都可直接看到管理员密码,极易通过偷窥、截图、浏览器表单缓存等方式泄露。


  • Wi‑Fi 反认证攻击漏洞(CVE‑2026‑26048)

    设备缺少管理帧保护机制,攻击者可发送伪造帧,对设备发起未经授权的干扰,造成拒绝服务(DoS)


设备厂商济南有人物联网技术有限公司已明确表示:该产品已停止服务,无任何补丁计划

这意味着 USR‑W610(3.1.1.0 及以下版本)永久存在高危风险,包括认证失效、拒绝服务、凭证被窃等。

由于不会再有任何修复程序,CISA 与安全研究人员强烈建议用户:

立即停用受影响设备,或将其严格隔离在网络分区中,确保未授权设备无法访问其管理接口

在几乎所有中大型企业中,你都能找到一个名为 CMDB 系统、 IT 资产管理系统 或“资产台账”的模块。

服务器、网络设备、终端、软件许可证、云资源、虚拟机、业务系统…… 从数量上看,资产“一个不少”;从字段上看,信息“填得很满”。

ManageEngine卓豪将介绍2026年CMDB的困境!

但一旦进入真实运营场景,CMDB 往往立刻暴露出致命问题:

l 发生重大事件时,无法快速判断影响范围
l 做变更评估时,只能靠经验“拍脑袋”
l 审计或合规检查时,数据经不起追问
l 资产数量对得上,但业务依赖关系一团乱

这也是为什么业内常说一句话: “CMDB 是 ITSM 里最贵、也最容易失败的模块。”

问题不在工具,而在治理逻辑

多数失败的 CMDB 项目,并不是因为工具能力不足, 而是从一开始就把 CMDB 当成了“静态记录系统”。

在这种思路下,CMDB 的目标往往被简化为:

把资产“录进去”
把字段“填完整”
把关系“画出来”

但真正的问题在于: 谁在用?什么时候用?用来做什么决策?

如果 CMDB 不能在事件、问题、变更、容量、审计等关键流程中 持续提供可靠数据支持,那么它无论字段多全,都是“死库”。

为什么 AI 时代反而更离不开 CMDB?

随着 AI、自动化、AIOps 在 ITSM 中的广泛应用, 一个新的误区正在出现: “有 AI 就不需要 CMDB 了。”

事实恰恰相反。

无论是智能告警聚合、根因分析、自动化修复, 还是代理式 AI 的自主决策, 其底层都依赖一个前提: 对 IT 环境结构的可信理解。

如果 CMDB 中的关系是错的、旧的、断裂的, 那么 AI 只会更快、更大规模地“做错事”。

CMDB 是 AI 的“世界模型”

在先进组织中,CMDB 正在从“后台模块” 转变为 AI 决策的结构性输入。

它不再只是被动存储,而是:

l 为告警与事件提供业务上下文
l 为变更风险评估提供影响链路
l 为自动化与 AI 代理划定执行边界

这也意味着: 没有治理能力的 CMDB,不适合进入 AI 阶段。

从“资产台账”到“关系资产”:CMDB 在 IT 治理中的角色跃迁

在大量企业的 IT 管理实践中,资产管理往往长期停留在“台账层面”:设备编号、型号、采购时间、责任人、折旧信息一应俱全,但这些信息仅用于盘点与审计,对日常运维决策的帮助极为有限。

而 CMDB(配置管理数据库)真正的价值,并不在于“记录资产”,而在于描述资产之间的关系,以及这些关系如何共同支撑业务运行。当 IT 资产被纳入 CMDB 进行建模后,它们不再是孤立存在的对象,而是服务、系统与业务链路中的关键节点。

CMDB 是否必须一次性建全?
不必。CMDB 更适合采用渐进式建设策略,优先覆盖高价值系统和关键服务。

如何避免 CMDB 数据快速失真?
通过自动发现、流程绑定与治理责任制,减少对人工维护的依赖。

CMDB 与 IT 资产管理是否重复?
二者关注点不同:资产管理强调生命周期与合规,CMDB 强调关系与影响分析。

员工提交问题,技术人员处理工单,服务台负责记录与关闭—— 这一模式在很长时间内行之有效,但也逐渐暴露出明显的瓶颈。

随着业务系统复杂度、员工规模与数字化依赖程度的不断提升, 企业开始意识到:IT 服务台已经不只是“接单和派单”的地方, 而是正在演变为连接业务、技术、数据与治理的“服务中枢”。

ManageEngine卓豪将介绍2026年IT服务台正在发生什么变化!

一、传统 IT 服务台的三大结构性问题

如果回顾多数企业当前的服务台现状,会发现问题并非出在“工具不好”, 而在于服务台的定位与能力边界已经跟不上组织的发展节奏。

1. 服务台被动响应,缺乏前瞻能力

在传统模式下,服务台只能在问题发生之后介入。 无论是系统宕机、性能下降,还是权限配置错误, 都必须等到用户感知并提交工单后,流程才会启动。

这不仅延长了业务中断时间,也让 IT 团队始终处于“救火状态”。

2. 工单视角割裂,缺乏全局上下文

大量服务台仍以“单张工单”为最小管理单元, 事件、问题、变更、资产、配置项之间的关联关系并未被系统性利用。

结果是:技术人员在处理问题时,需要反复在不同系统之间切换, 依赖个人经验拼凑上下文,效率和准确性高度不稳定。

3. 服务台难以支撑跨部门服务协同

随着企业逐步推进企业服务管理(ESM), IT 服务台开始承载 HR、行政、财务等非 IT 服务请求。

然而,如果底层平台仍然停留在“IT 工单工具”层面, 这些跨部门服务往往只是“形式上接入”, 并未形成真正统一的服务体验与治理能力。

二、服务台平台化:从“工具”到“服务中枢”

要突破上述瓶颈,企业必须重新思考 IT 服务台的定位: 它不应只是一个系统模块,而应是企业级服务能力的核心枢纽。

这一转变,通常体现在三个方面:

l 从“处理工单”转向“编排服务”
l 从“流程驱动”转向“意图驱动”
l 从“人工主导”转向“人机协同”

在这一过程中,平台能力的重要性开始凸显。 一个成熟的服务台平台,必须同时具备流程治理能力、数据整合能力以及智能扩展能力。

例如, ServiceDesk Plus 在设计之初, 便将服务台视为统一服务管理平台, 而非单一的工单处理系统。

三、AI 介入服务台:从“效率工具”到“服务协同者”

在服务台平台化的基础之上,人工智能的引入并非简单叠加功能, 而是对服务交付逻辑的一次结构性升级。

早期 AI 在 IT 服务台中的应用,多集中于效率型场景, 例如工单分类、优先级推荐、自动回复等。 这些能力确实缓解了一线压力,但并未改变服务台的整体角色。

当 AI 与服务台深度结合之后,其价值开始从“替人做事” 转向“协同决策与服务编排”。

AI 在服务台中的三类核心角色

感知者:持续分析工单、日志、资产与变更数据,识别潜在风险
建议者:为技术人员提供根因、处理路径与优先级建议
执行者:在受控范围内完成标准化、低风险操作

Q1:智能服务台是否意味着减少 IT 人员?
不一定。更多情况下,是角色转变,而非简单替代。

Q2:AI 自动化是否会带来合规风险?
风险来自失控,而非 AI 本身。治理是前提。

Q3:服务台平台化是否适合中小企业?
越早平台化,未来扩展成本越低。

Excelize 开源基础库发布 2.10.1 版本更新

https://developer-private-1258344699.cos.ap-guangzhou.myqclou...;1772002094&q-key-time=1771996694;1772002094&q-header-list=host&q-url-param-list=&q-signature=eded1c8ac095e3f0a86f2779f56c6872ea96eb07&x-cos-security-token=Ym4fMB3eaZVXV72MoReC2cJG7ggSn5ca61247a305c761ee77af8b094122dbfedhiaNFGvq0YlmE8A-YPVd-xtIS7JPaUujc53qvCq-NG_jW3_GkYGpbmZxI6VY0wkKLeRVhPBRagoc3Hgk6oiICyy2PCvp2Y0dzPhoaSmZgo-LHljZW0mSXYR_k_JWZMeoe0Y-KmU48kJEYIX0p4K6qNbIkeqL0pxN_1S0fL_Z77TMJWAo_HGh_QTBd0dfKDoGsUgRok6nPLdqAbWrMTFBQ_R5eYhk75oAydkF49ttZJp5oic1JRMjKJCDNGJGHoqJxJbfwzMy17QX5ebNWGzMQmqejK9BvQdMd68HNgLfoyVzVWtvUV_Wbj94fQuzOulhMiu62WJEOoDqCtl2ny0rcops_VD-PHZ6Ic3xD-eDsI1Sbuo-y8X5wwueAqam8gn43jKHUGZ4L1hKXFGEutokMRAO05q7wexgjYTv08kfArlfN9LTmfKTvPeUtMYX-ncjHxmIVUUg8uimsssXimjNms3XKLdMRAeSe_LGq-75jAraUZ5zWlfgDXJ4-AHxMdWKdq9nMSRaG5vDugHqH8JtqUh29dC6O1AA9_QDZSoElTJxUWpzCjyUYsX3JReqjuCbDwWVOd0Ynt8fMAMI7HyCuRI2BKpS5jsi4qPbT87Z5a-VgaQ-wWrP6GjJvwrchYFn_nc5PK0UGodCuG4RMzW5bZUdCOMj6QRbYxW6ZRniBGB8enJhMPX21LVlUKuMKFVV

<p align="center"><img src="" width="440" alt="Excelize 开源基础库 2.10.1 版本发布"/></p>

Excelize 是 Go 语言编写的用于操作 Office Excel 文档基础库,基于 ECMA-376,ISO/IEC 29500 国际标准。可以使用它来读取、写入由 Excel、WPS、OpenOffice 等办公软件创建的电子表格文档。支持 XLAM / XLSM / XLSX / XLTM / XLTX 等多种文档格式,高度兼容带有样式、图片(表)、透视表、切片器等复杂组件的文档,并提供流式读写支持,用于处理包含大规模数据的工作簿。可应用于各类报表平台、云计算、边缘计算等系统。自 2016 年开源以来已成为开发者在处理电子表格办公文档时的热门选择,正在被广泛应用于大型互联网公司、中小企业客户和初创公司。荣获 2025 上海开源创新菁英奖、入选 2023 开源创新榜优秀开源项目、荣获 2022 年中国开源创新大赛一等奖、2020 Gopher China - Go 领域明星开源项目 (GSP)、2018 年开源中国码云最有价值开源项目 GVP (Gitee Most Valuable Project)。

开源代码

2026年2月25日,社区正式发布了 2.10.1 版本,该版本包含 40 余项更新,包括新增功能、错误修复和兼容性提升优化。来自世界各地的 29 名开发者为此版本贡献了代码。下面是有关该版本更新内容的摘要,此版本中最显著的变化包括:

兼容性提示

  • 移除了 3 个导出的错误变量:ErrStreamSetColStyleErrStreamSetColWidthErrStreamSetPanes

新增功能

  • 新增 ChartDataPoint 数据类型
  • ChartSeries 数据类型中新增 DataPoint 字段
  • ChartAxis 数据类型中新增 DropLinesHighLowLines 字段
  • GraphicOptions 数据类型中新增 Name 字段
  • ChartSeries 数据类型中新增 DataPoint 字段
  • 新增 2 个常量:MaxGraphicAltTextLengthMaxGraphicNameLength
  • 新增 7 个导出的错误变量:ErrFillTypeErrFillGradientColorErrFillGradientShadingErrFillPatternColorErrFillPatternErrMaxGraphicAltTextLengthErrMaxGraphicNameLength
  • 新增 GetHyperLinkCells 函数,支持获取包含超链接的单元格,相关 issue 1607
  • 新增 GetSheetProtection 函数,支持获取工作表保护设置
  • 当向已存在批注的单元格添加批注时,AddComment 函数将返回错误
  • 支持插入 ICO 格式图片,相关 issue 2234
  • 新增 2 项公式函数:SORTBY 和 UNIQUE
  • 添加图表时支持为圆环图、饼图和三维饼图设置数据点颜色,相关 issue 1904
  • 添加图表时支持为东亚文字与复杂文字脚本设置字体
  • 添加图表时支持为面积图和折线图设置下垂线与高低线
  • 获取图片时支持返回部分图片格式属性,相关 issue 2157
  • 新增流式设置列可见性功能,相关 issue 2075
  • 新增流式设置列的分级显示功能,相关 issue 2212
  • 添加形状和添加切片器时,支持将形状与切片器设置为单一单元格锚定类型
  • 获取切片器时支持获取单一单元格锚定类型的切片器
  • 支持设置与获取“3 个三角形”、“3 颗星”和“5 个方框”类型的图标集条件格式,相关 issue 2038
  • 删除条件格式和删除数据验证时,支持从一个大的单元格范围中删除指定单元格范围内的条件格式或数据验证,而保留其余单元格范围内的条件格式或数据验证
  • 添加图片时支持设置图片的名称
  • 添加图表或插入形状时,支持为图表或形状设置名称与替代文本
  • 添加切片器时支持为切片器设置替代文本
  • 支持校验图形名称与替代文本的长度,当长度超过限制时将会返回错误
  • 支持以 UTF-16 方式检查并截断文本长度

兼容性提升

  • 保存工作簿时将自动移除无效的空行,减少生成的工作簿文件大小

问题修复

  • 修复 v2.10.0 中引入的问题,解决 GetCellValueGetRows 函数在某些情况下读取空白单元格时,错误地返回了共享字符串索引,相关 issue 2240
  • 修复 GetPivotTables 函数在部分情况下获取数据透视表时发生 panic 的问题
  • 修复部分情况下,读取带有中文月份名称数字格式的单元格时,发生 panic 的问题,相关 issue 2224
  • 修复部分情况下,打开带有密码保护的加密工作簿时,发生 panic 的问题,相关 issue 2237
  • 修复使用流式写入器 SetRow 函数时,列样式缺失的问题
  • 修复获取图片时,未包含部分单元格图片的问题
  • 修复由浅色主题颜色索引溢出导致的,部分情况下生成的工作簿损坏的问题
  • 修复删除数据验证函数 DeleteDataValidation 在数据验证单元格范围无序时,数据验证单元格范围未被正确更新的问题
  • 修复设置条件格式函数 SetConditionalFormat 在设置部分带有时间周期条件格式规则时,生成的工作簿损坏的问题
  • 修复计算单元格的值时,对带有单引号的工作表名称解析失败,导致的单元格公式计算结果有误问题
  • 修复使用默认字体或填充格式创建样式时,重复创建样式的问题,相关 issue 2254

性能优化

  • 通过增加计算缓存并将处理范围限定到实际数据区域,优化了公式计算引擎的性能,相关 issues 2057 和 2223
  • 优化算带有 VLOOKUP 函数的公式计算性能,内存分配与耗时最多降低约 50%,相关 issue 2139
  • 优化了合并单元格重叠范围的检查算法,降低了获取合并单元格函数 GetMergeCells 的内存分配和耗时,相关 issue 2226
  • 通过使用连分数基本递推公式转换优化了带有分数数字格式代码的单元格读取速度

其他

  • Go Modules 依赖模块更新
  • 单元测试与文档更新
  • 包含阿拉伯语、德语、英语、西班牙语、法语、意大利语、日语、韩语、葡萄牙语、俄语、简体中文和繁体中文的多国语言文档网站更新
  • 支持 WebAssembly / JavaScript 的 excelize-wasm NPM 包发布版本更新
  • 支持 Python 的 excelize PyPI 包发布版本更新
  • 支持 C# 的 ExcelizeCs NuGet .Net 包发布

致谢

感谢 Excelize 的所有贡献者,以下是为此版本提交代码的贡献者列表:

  • pjh591029530 (Simmons25)
  • Sang-Hyuk (SangHyuk)
  • wangacc
  • kenny-not-dead (Roman Sergeev)
  • pegasscience-cyber
  • jesusfelix951-lang
  • felixdevelopper-hue
  • shcabin
  • radam9
  • sqdtss
  • IvanHristov98 (Ivan Hristov)
  • yasarluo (Yasar Luo)
  • DengY11 (Yi Deng)
  • Kingson4Wu (Kingson4Wu)
  • zhuzhengyang (Zhu Zhengyang)
  • schbook
  • rhinewg
  • jpoz (James Pozdena)
  • sides-flow (Sides)
  • t4traw (Tatsuro Moriyama)
  • ijustyce (杨春)
  • d9c4
  • imirkin (Ilia Mirkin)
  • atmngw (Atsuki)
  • Flashcqxg
  • olivere (Oliver Eilhard)
  • susautw (Su, Rin)
  • ohauer (Olli Hauer)
  • yan00353-0729

《Excelize权威指南》

《Excelize 权威指南》

《Excelize权威指南》不仅介绍了 Excelize 库的基本使用方法,还深入探索了高级特性和应用场景。全书共分五个篇章:入门指南、基础库设计概览、深入 Excelize、高性能流式读写技术以及实践应用。通过这本书,你将学会如何利用 Go 语言和 Excelize 库,实现 Excel 文件的自动化处理、复杂数据分析以及报表生成等任务。

你将不再受限于 Excel 的传统操作方式,而是能够通过编程的方式,解锁 Excel 新境界,创造出更加智能、高效的数据处理解决方案。

一、方案背景
电子组装行业(涵盖SMT贴片、DIP插件、组装测试等工序)具有多品种、小批量、快迭代及高精密的生产特点。传统的管理模式已难以应对当前的挑战,本方案旨在通过MES(制造执行系统)解决物料防错、全程追溯、柔性排程和质量管控四大核心痛点,实现生产过程的数字化与智能化转型。

二、核心痛点与解决方案
1、物料管理:从“人工核对”到“智能防错”
传统模式问题:
在传统模式下,上料环节高度依赖人工核对,极易出现人为失误,导致错料事故。同时,生产过程中抛料率居高不下,造成成本浪费。此外,对于锡膏、胶水等有严格有效期和存储要求的辅料,往往缺乏有效的监控手段,容易导致过期使用或性能下降。
万界星空MES解决方案关键点:
智能防错上料: 系统引入PDA扫描枪与贴片机Feeder位进行绑定校验。操作员在上料时扫描物料条码,系统自动比对物料编码、批次号及有效期。只有信息完全匹配,设备才允许启动,从源头杜绝错料。
锡膏全生命周期管理: 系统自动记录锡膏的回温时间、搅拌时间及使用期限。一旦超时未用或超过有效期,系统将自动报警并锁定该物料,禁止上线使用,确保焊接质量。
2、生产追溯:从“纸质记录”到“一物一码全链路”
传统模式问题:
传统工厂依赖纸质流转卡和手工报表,数据查询困难且容易丢失。一旦出现产品质量问题,往往需要花费数天时间翻阅大量纸质文档,才能勉强定位到具体的人员、机台和物料批次,严重延误客诉处理和召回时机。
MES解决方案关键点:
一物一码全链路追溯: 建立以PCB裸板序列号(SN)为核心的追溯体系。从SMT上线开始,系统自动关联每一颗元器件的批次信息、使用的贴片机台、钢网版本、回流焊炉温曲线以及后续的测试数据。
极速响应机制: 实现5分钟内完成正向(查产品去向)与反向(查问题来源)的全程追溯。无论是应对客户投诉还是内部质量分析,都能瞬间调取完整档案。
3、计划排程:从“Excel静态表”到“APS动态联动”
传统模式问题:
电子组装行业急单、插单频繁。传统使用Excel进行排程,无法实时掌握设备运行状态、模具占用情况以及物料齐套率。往往计划下达后才发现缺料或设备故障,导致生产线停工待料,交期延误。
MES解决方案关键点:
APS高级排程联动: 基于有限产能(综合考虑设备、人力、模具等实际资源)进行动态排程。
敏捷插单支持: 系统支持“一键插单”功能。当紧急订单插入时,系统自动重新计算并调整后续所有工序的计划,同时实时模拟计算物料齐套情况,确保新计划的可执行性,最大化提升交付准时率。
4、质量控制:从“事后检验”到“在线闭环”
传统模式问题:
传统质量管理多以成品事后检验为主,SPC(统计过程控制)统计滞后。往往在发现不良时,已经生产了大量废品,无法做到预防批量不良,造成巨大的材料和时间损失。
MES解决方案关键点:
在线质量闭环: 深度集成SPI(锡膏检测)、AOI(自动光学检测)、ICT/FCT(功能测试)等设备数据。
实时预警与拦截: 系统实时监控检测数据,一旦发现连续不良或趋势异常,立即触发停机报警,并实时生成SPC控制图。这种“事中控制”机制能有效防止不良品流入下一道工序,将质量隐患消灭在萌芽状态。
三、典型业务流程架构
1、工程数据管理 (EDM)

统一管理BOM(支持多版本切换)、工艺路线、SOP作业指导书(电子化推送到工位屏幕)。
钢网、治具的生命周期管理与保养提醒。

2、计划与调度

接收ERP工单,分解为车间作业计划。
根据换线时间最小化原则优化排产顺序(如将相同物料的订单合并生产)。

3、SMT车间执行

接料管理:卷带接料扫码确认,防止接错料。
首件检测:强制首件检验流程,检验合格后方可批量生产。
设备联网:采集贴片机抛料率、运行状态,计算OEE(设备综合效率)。

4、DIP与组装执行

防错装配:关键工位(如螺丝锁付、条码粘贴)配备传感器或视觉检测,漏操作无法流转到下一站。
安灯系统 (Andon):缺料、设备故障、品质异常一键呼叫,消息直达相关人员手机/手表。

5、测试与包装

自动采集测试数据(电压、电流、功能测试结果),不合格品自动锁定并提示返修路径。
包装环节关联外箱码与内部产品序列号,生成出货报告。

四、2025-2026年技术新趋势
1、AI与大模型融合:

利用AI算法分析历史生产数据,预测设备故障(预测性维护)。

通过大模型辅助生成排程建议,甚至通过自然语言查询生产报表。
2、低代码/零代码平台:

万界星空科技低代码平台企业IT人员无需编写代码即可快速搭建或调整表单和流程,适应电子行业频繁的工艺变更。

3、云原生与SaaS化:
中小型企业更倾向于部署云端MES,降低初期硬件投入,实现快速上线。
4、软硬一体化集成:

MES不再孤立,而是与WMS(仓储)、QMS(质量)、EMS(设备)深度集成,甚至直接控制自动化物流小车(AGV)进行自动配料。

对于电子组装企业,一套优秀的MES解决方案不仅是记录工具,更是防错的盾牌和增效的引擎。在2026年的当下,选择具备AI能力、行业深度适配且灵活可扩展的系统,将是企业在激烈的市场竞争中保持敏捷与高质量的关键。

前情提要: https://2libra.com/post/recommendations/vvKLMn5

去年申请过一个谷歌开发者账号,一直闲着没用。
春节前突然通知限 60 天内发布 app,不然账号就没了。
为了 25 美金不打水漂,做了一个简单的查询笔顺的 app,第一次走 google play 上架流程。

应用已经提交,目前在 Closed Testing 阶段。
恳请大家帮忙在 Google Play 下载测试应用,保持 14 天安装并每天打开一次。
几天前在 Reddit 互助板块发过,也有一些测试用户了。为了保险起见,还需要增加一些安装量。

应用名称:

一笔一画(WriteRight) (由本站首富( @bopomofo )赐名)

SCR-20260225-lxrb

本应用开源,项目地址: https://github.com/utags/write-right
PWA 版本链接: https://writeright.pipecraft.net/

PWA 版本可以用来装饰手机桌面。

加入测试流程:

  1. 加入 Google Group: https://groups.google.com/g/writeright-beta-testers

  2. 安装应用: https://play.google.com/store/apps/details?id=net.pipecraft.writeright.twa

保持 14 天安装并每天打开一次。

感谢大家 🙏

一、什么是国密证书?

国密SSL证书是指采用我国自主研发的SM2(非对称加密)、SM3(哈希算法)及SM4(对称加密)算法体系所颁发的数字证书。它与我们日常使用的国际SSL证书(如RSA算法)在技术底层上有着本质区别。国密证书由获得国家密码管理局资质的国内CA机构签发,确保证书链的完全自主可控,从根源上避免了受制于人的风险。

二、 为何必须部署国密证书?

当前,政策合规是推动国密改造的主要驱动力。对于政务系统、金融、能源及国企等关键信息基础设施而言,采用国密证书不仅是《网络安全法》的要求,更是通过“密评”(商用密码应用安全性评估)的硬性指标。

除了合规性,国密算法在性能上也具有显著优势。SM2算法在同等安全强度下,密钥长度更短(256位 vs RSA的3072位),运算效率更高,能够有效降低服务器负载,提升网站响应速度。这意味着在保障数据防窃取、防篡改的同时,用户访问体验也能得到优化。
申请JoySSL的国密(或双算法)证书,流程非常标准化,跟着下面五个步骤操作,很快就能完成。

三、具体申请步骤

国密证书申请入口

第一步:注册账号并填写注册码

首先,访问JoySSL的官方网站,点击右上角注册按钮创建一个新账号。在注册过程中,有一个关键环节是填写注册码230970,这通常用于获取免费证书名额、优惠券或一对一的技术指导服务。

第二步:选择证书类型

登录后,在证书选择页面找到“国密算法”或“双算法”证书选项。

  • 国密算法证书:纯SM2算法,适用于对合规性要求极严的纯国密环境。
  • 双算法证书:推荐大多数用户选择,它包含SM2和RSA双套证书。服务器配置后,能根据访问者浏览器自动切换,既满足密评要求,又兼容普通用户访问。
    根据你的域名情况,选择单域名(保护一个域名)、多域名或通配符(保护二级及以下所有子域名)版本。
第三步:提交申请并验证域名所有权

填写具体的域名或IP地址、组织信息(如申请OV证书需公司名称)。提交后,需要进行域名所有权验证,一般有两种方式:

  • DNS验证:在域名管理后台添加一个指定的TXT解析记录。
  • 文件验证:在网站根目录下上传一个指定的验证文件。
    验证通过后,系统通常会很快签发证书(DV证书甚至可以在几分钟内完成)。
第四步:下载证书文件包

证书签发后,登录你的JoySSL账户,在证书列表中点击“下载”。你会得到一个压缩包,里面包含了:

  • 证书文件(.crt/.pem)
  • 私钥文件(.key)
  • 帮助文档(不同服务器的安装指南)
第五步:部署到服务器并进行测试

根据你的Web服务器环境(如Nginx、Apache、IIS),将证书文件上传并配置。如果是“双算法证书”,记得按照指南配置两个证书的路径。部署完成后,使用浏览器访问你的网站,检查地址栏是否显示安全锁标志,确保HTTPS连接正常工作且无安全警告。

提示:注册码和优惠信息具有时效性,建议在操作前留意官网的最新活动说明。如果在部署中遇到问题,也可以随时联系JoySSL的客服寻求技术支持。

⼀场震动 AI⾏业的指控

2026 年 2⽉23⽇,Anthropic 正式公开指控三家中国 AI 公司——DeepSeek、 MiniMax 和 Moonshot AI ——利⽤超过 24,000 个虚假账⼾,对其旗下 Claude 模型进⾏了总计超过 1,600 万次对话交互,通过“模型蒸馏”技术⼤规模提取 Claude 的核⼼能⼒。

这不是⼀句模糊的“我们怀疑有⼈抄了”。Anthropic 拿出了 IP 地址追踪、元数据分析、⾏业伙伴交叉验证,甚⾄将部分账⼾关联到了具体的公司研究⼈员。截⾄发稿,三家公司均未公开回应。 三家公司中,MiniMax 交互量最⼤(1,300 万次), Moonshot 居中(340 万次), DeepSeek 量最⼩但据称⼿法更有针对性(15 万次),专攻推理链的逆向提取。

 

乍⼀看,这是⼀个清晰的故事:有⼈偷了东西,被抓了。

 

但越往深看,越觉得不简单。抄了 1,300 万次作业的那家,为什么产品还是打不过⽼⽼实实练基本功的同⾏?指控别⼈偷的这家,⾃⼰的训练数据就⼲净吗?为了抓住“⼩偷”,平台对所有⽤⼾的对话到底看了多深?⽽这⼀切发⽣的时间节点——恰好是 Anthropic 在五⻆⼤楼谈判桌上最需要筹码的时候。

 

更别提,还有⼀种规模远超 1,300 万次的“蒸馏”,正在全球范围内公开进⾏,从来没有⼈叫它蒸馏,也从来没有⼈喊停。

 

这篇⽂章会从头讲清楚模型蒸馏是什么、怎么操作、威⼒有多⼤。但更重要的是,我们会追问那些新闻标题⾥不会告诉你的问题。

 

先从技术本⾝说起。

蒸馏:⼀个诺贝尔奖得主的“好主意”

 

2015 年,Geoffrey Hinton——后来拿了 2024 年诺⻉尔物理学奖的“深度学习之⽗”——和 Google 的 Jeff Dean 等⼈发表了⼀篇论⽂,正式提出了“知识蒸馏”(Knowledge Distillation) 的概念。

 

他的出发点很朴素:⼤模型能⼒强,但太笨重、太贵、跑太慢,能不能把⼤模型的“知识”压缩进⼀个⼩模型⾥?

 

Hinton 注意到⼀个关键现象:⼤模型在给出答案之前,内部其实产⽣了⼀组丰富的概率分布。 ⽐如让它识别⼀张动物图⽚,它不只是说“这是猫”,⽽是给出“猫 90%、狗 8%、虎 2%”。这个分布本⾝就是知识——它说明了猫和狗⽐猫和卡⻋更相似。⽤这种“软知识”去教⼩模型,⽐只告诉它“对或错”有效得多。

 

这个技术迅速成了⾏业标配。 Google⽤它、 OpenAI⽤它、Anthropic ⾃⼰做轻量版模型 Haiku 时也⽤它。完全合法,完全正向——让 AI 更便宜、更快、更容易部署到⼿机和边缘设备上。

 

⼗年后,同样的技术被⽤在了 Anthropic 指控的这个场景⾥。只不过⽅向变了:不再是压缩⾃⼰的⼤模型,⽽是从别⼈的⼤模型⾥抽取能⼒

⼀个⼩时学会⼗年功夫

 

传统的 AI 模型训练,像是让⼀个学⽣从⼩学开始⾃学——读课本、做习题、犯错、总结,⼀步步积累能⼒。这个过程需要海量数据、巨⼤算⼒、⼤量⼈⼯标注,周期⻓达数⽉,花费动辄数亿美元。

 

模型蒸馏的逻辑完全不同:不⾃⼰学,直接抄“学霸”的答题过程

 

具体怎么操作?三步:

 

第⼀步:批量出题。 针对你想提取的能⼒(⽐如推理、代码编写、⼯具调⽤),设计成千上万个精⼼构造的问题。不是随便问,⽽是覆盖这项能⼒的各种维度和难度组合。

 

第⼆步:让“学霸”答题。 把这些问题发给⽬标模型(⽐如 Claude),收集它的全部回答。这些回答⾥隐含了模型的判断逻辑、推理路径、表达策略——这是花了⼤量资⾦和算⼒训出来的能⼒结晶。

 

第三步:⽤答案训练⾃⼰的模型。把这些⾼质量的“问题-回答”数据对,直接喂给⾃⼰的模型做训练。你的模型不需要理解“为什么这样回答好”,只需要学会“遇到这类输⼊时,输出这种模式”。

 

举个具体例⼦。假设我想让⾃⼰的模型学会“智能客服处理客⼾投诉”的能⼒:

  • “客⼾要求把贷款利率从 4.5%降到 2%,否则转⾛存款,怎么回复?”, 同样的场景,但客⼾是 VIP;

  • 同样的场景,但客⼾正在发脾⽓;

  • 同样的场景,但客⼾搬出了⾏⻓的名字。

 

⼀个能⼒点,展开成 5,000 个变体。 Claude 对每个变体给出⼀个⾼质量回答——什么时候坚持原则、什么时候给台阶、 怎么平衡合规和客⼾体验。这 5,000 对数据的质量,远⾼于你从互联⽹上能爬到的任何东西。

 

“5,000 条数据,只能应对 5,000 种情况吧?” 直觉上是这样,但神经⽹络不是背题库。

 

你给孩⼦做 100 道⼏何证明题,他学到的不是“100 道题的标准答案”,⽽是“辅助线该往哪⾥做”的直觉。遇到第 101 道没⻅过的题,他照样能做。

 

模型训练⼀样。那 5,000 条银⾏客服数据喂进去,模型学到的是⼀套放在哪⼉都管⽤的应对逻辑:情绪升级时先共情再给⽅案,涉及合规红线时⽤“制度要求”⽽⾮“我不⾏”来托底,对⽅搬出权⼒关系时既不接招也不硬顶。

 

蒸馏的精妙之处在于:你不需要覆盖所有场景,只需要覆盖⾜够多的能⼒维度。 就像不需要教孩⼦每⼀道可能出现的⼏何题,只需要让他把“相似三⻆形”“圆的切线”“⾯积法”⼏个核⼼⽅法练熟,他就能组合应对绝⼤多数题⽬。

 

所以 MiniMax 做了 1,300 万次交互——这不是在收集 1,300 万个答案,是在系统性扫描 Claude 的整个能⼒图谱。

 

1,300 万次,怎么可能做到?不需要⼈。

 

⼀个脚本,⼏⼗⾏代码。⽤AI 批量⽣成 prompt,再⽤Claude 批量回答。机器对机器,24⼩时不停。 24,000 个假账号分散请求,每个账号每天⼏百条,混在正常⽤⼾流量⾥,⼀个⽉就能跑完。

 

Anthropic 在报告中描述了⼀种叫“Hydra Cluster”的架构:⼀套代理⽹络同时控制两万多个账号,⾃动轮转、⾃动混⼊正常请求来躲避检测。 实际操作团队可能只需要⼏个⼯程师。

 

成本?按 API 定价粗估,1,300 万次对话⼤约⼏⼗万美元。对⽐从头训练⼀个同等能⼒模型需要的数亿美元——投⼊产出⽐惊⼈。

 

这也是为什么 Anthropic 说这件事光靠⾃⼰防不住:攻击⽅的边际成本⼏乎为零,防守⽅要在海量正常流量⾥⼤海捞针。

 

1,300 万次到底覆盖了多少?

 

Anthropic 报告提到 MiniMax 主攻的⽅向包括⾃主编程、⼯具调⽤、任务编排等。综合其他报道,加上推理、视觉等领域,假设总共覆盖⼗⼏个⼤的能⼒域。

 

算⼀笔粗账:1,300 万次交互分配到 15 个能⼒域,每个域⼤约 87 万次。每个域下⾯拆出 50 个⼦任务,每个⼦任务⼤约 17,000 个变体。

 

17,000 个变体意味着什么?意味着⼀个具体的能⼒点——⽐如“从⼀段⾃然语⾔需求⽣成可执⾏的 SQL 查询”——被从各种⻆度、各种边界条件、各种难度级别反复扫过。这不是⼤海捞针式的乱抓,⽽是⼀张精⼼设计的能⼒扫描⽹,基本把⽬标模型最有商业价值的能⼒维度都过了⼀遍。

但抄作业有天花板

 

读到这⾥,你可能觉得蒸馏⽆敌了。 实际上不是。

 

⼀个有趣的事实:MiniMax 做了 1,300 万次蒸馏,但在很多⽤⼾的体感中,它的模型并不⽐⼀些没有被曝出蒸馏⾏为的国产模型更好⽤。

 

这恰恰说明蒸馏有它绕不过去的短板。

 

抄作业能让你从 60 分快速冲到 85 分,但从 85 分到 95 分靠的不是抄更多作业——是你⾃⼰的底⼦: 模型架构怎么设计、预训练数据质量好不好、训练⼯程扎不扎实、跟⼈类偏好的对⻬调得细不细。这些东西,蒸馏搬不⾛。

 

⽽且蒸馏有⼀个硬顶:你最多只能接近⽼师,不可能超过⽼师。⽬标模型⾃⾝的短板,你也原样继承了。

 

那些被觉得“更好⽤”的模型,往往是在底⼦上下了更扎实的功夫——训练数据质量更⾼、更懂⽬标⽤户的习惯和偏好、在具体场景上打磨得更深。这是硬功夫,没有捷径。

 

1,300 万次蒸馏,结果并没有造出公认最强的模型——这本⾝就是蒸馏局限性的最好注脚。

 

“可是 Anthropic⾃⼰的训练数据不也是‘偷’来的?”

这是很多⼈的第⼀反应,也不是没有道理。

 

Anthropic 训练 Claude 时,⼤规模抓取了互联⽹上的书籍、新闻、论⽂、代码、论坛帖⼦——其中⼤量 内容的版权属于原作者,既没有被告知也没有授权。《纽约时报》诉 OpenAI、 Getty Images 诉 Stability AI,打的都是这个仗。

 

所以就有了⼀个绕不开的追问:你拿别⼈的作品训练出模型,然后宣称模型的输出不可被提取——“所有权”到底从哪⼀环开始成⽴?

 

但这两件事放在⼀起⽐,还是有本质区别的:

 

法律性质不同。 训练数据的版权争议⽬前还没有定论,合理使⽤(fair use) 的边界还在被法院⼀点点 划定。 ⽽Anthropic 所指控的蒸馏⾏为涉及违反服务条款、使⽤欺诈账⼾、绕过地域限制——这些在合 同法层⾯是板上钉钉的违约。

 

做法不同。 训练基础模型时,从海量数据⾥学通⽤规律,任何单⼀来源的内容都被稀释到了可以忽略的程度。蒸馏是盯着你⼀个模型定点抽取——精⼼设计 Prompt,专⻔榨你最值钱的能⼒。⼀个是“读了⼀万本书”,另⼀个是“把隔壁学霸的笔记本偷来复印”。

 

这不意味着 Anthropic 在道德上就完全站得住。 只是说明这是两个不同层⾯的问题,不能简单地⽤“你也偷了”来对冲。

你的企业可能正在灰⾊地带⾥

 

上⾯说的是 Anthropic 指控的违规⾏为。但现实中,⼤量企业的正常使⽤⾏为,其实离“蒸馏”只有⼀步之遥。假设⼀家电商公司是 Claude 的付费企业客⼾,⽤它来⽣成客服话术——处理退货纠纷、应对差评投

 

诉、化解价格争议。 ⽣成了⼏千条⾼质量回复后,存进内部知识库。 以后客服遇到新问题,系统⾃动从知识库⾥检索最相似的话术推荐给客服。

 

这完全合规,是标准的企业 AI 应⽤。

 

但仔细看——它的效果和蒸馏⼏乎⼀样:付⼀次钱,把能⼒带⾛了。 新场景来了不需要再问 Claude, 知识库加语义检索就能覆盖绝⼤多数情况。

 

类似的场景到处都是:

  • 律所⽤Claude 批量⽣成合同审核意⻅,整理成模板库,以后新合同对照模板⾛,不再需要 AI 逐份审核;

  • 医疗公司⽤Claude 撰写⼏百种常⻅症状的分诊指南,嵌⼊⾃⼰的问诊系统,从此⾃给⾃⾜;

  • ⼴告公司⽤Claude 为不同⾏业、不同调性⽣成上千条⽂案范本,建成内部的“创意弹药库”。

 

这些企业没有⼀个在做“蒸馏攻击”,甚⾄动机完全正当。但效果是⼀样的:⼀次性提取 AI 的能⼒,转化为⾃⼰的⻓期资产。

 

那 Anthropic 的服务条款怎么划这条线? ⽬前的规定是:禁⽌⽤输出“训练模型”,但没有禁⽌你把输出存进知识库做检索。 两种做法的实际效果可以⾮常接近,但在合同层⾯⼀个违规、⼀个不违规。

 

这恰恰暴露了当前规则体系的脆弱——技术⼿段可以达到⼏乎相同的⽬的,但法律和条款只能按⾏为⽅式划线,没办法按效果划线。

 

这也意味着,当我们讨论 Anthropic 对中国 AI 公司的指控时,真正的问题可能⽐“谁偷了谁”要深刻得多。

还有⼀个没⼈问的问题

 

回过头看 Anthropic 的指控,有⼀个细节很容易被忽略:他们是怎么发现的?

 

Anthropic 说⾃⼰通过 IP 地址追踪、元数据分析、请求模式识别来锁定这些蒸馏⾏为,甚⾄将部分账户关联到了具体公司的具体研究⼈员。

 

这意味着什么?意味着 Anthropic⾄少在做这⼏件事:记录每次对话的来源 IP 和元数据,分析⽤户 Prompt 的内容和模式(否则怎么判断“这些 prompt 是在做蒸馏⽽不是正常使⽤”?),对对话内容进⾏聚类和分类。

 

问题来了:要抓蒸馏,就得看⽤⼾在聊什么。⽽看⽤⼾在聊什么,本⾝就是对隐私的侵⼊。

 

想想你⾃⼰⽤AI 的场景。你可能跟它聊过商业策略、法律纠纷、健康问题、家庭⽭盾,甚⾄⼀些你不会告诉任何⼈的⼼事。你打下这些字的时候,有没有想过平台⽅不仅有能⼒、⽽且可能正在分析这些对话的内容、模式和意图?

 

Anthropic 能够精确识别出哪些对话在做什么、来⾃谁、⽬的是什么——这说明 AI 公司能看到的东西,远⽐⼤多数⽤户以为的要多得多。

 

AI 公司保护⾃家模型不被蒸馏,当然有正当理由。但“保护”需要的监控⼒度,和“⽤⼾隐私”之间的⽭盾, ⽬前⼏乎没有⼈公开讨论过。⽤⼾为此让渡了多少隐私?这些让渡是否被充分告知和授权了?当 AI 公司说“我们检测到了异常使⽤模式”时,这句话背后站着⼀整套针对所有⽤⼾⾏为的监控体系。

 

我们在讨论“谁偷了谁的模型”时,或许也该问⼀句:谁在看我们的对话?

 

追问到这⾥,我们已经从技术层⾯⾛到了伦理层⾯。但还有⼏个更尖锐的问题,涉及动机、 ⽴场和话语权。

为什么是现在?

 

指控的内容值得关注,指控的时机同样值得关注。

 

就在 Anthropic 发布这份报告的同⼀时期,多家媒体报道了另⼀件事:美国国防部⻓召⻅Anthropic CEO Dario Amodei 前往五⻆⼤楼,就 Claude 的军事⽤途进⾏谈判。据报道,⽓氛相当紧张——Anthropic 因拒绝完全解除 AI 安全护栏,正⾯临被定性为“供应链风险”、从⽽失去国防合同的压⼒。 与此同时,Elon Musk 的 xAI 和 Google 已经先后与五⻆⼤楼达成了协议。

 

在这个节骨眼上,公开指控中国 AI 公司对⾃⼰发动“⼯业级蒸馏攻击”,客观效果是什么?

 

它强化了“美国 AI 技术正在被系统性窃取”的叙事,也强化了 Anthropic 作为“被攻击的受害者”和“负责任的安全守卫者”的公众形象——⽽这恰恰是它在五⻆⼤楼谈判中最需要的筹码。

 

这不是说指控⼀定是策略性的,也不是说内容是捏造的。但⼀个⾏为同时服务于多个⽬的时,我们⾄少应该意识到这些⽬的的存在,⽽不是只看到其中⼀个。

 

同样的逻辑,也适⽤于下⼀个问题。

反⽅向有没有⼈在做?

 

⽬前的公开讨论⼏乎是单向的:中国公司蒸馏美国模型。但⼀个显⽽易⻅的反向问题很少被提及。

 

DeepSeek 的 R1 是开源模型,权重完全公开,任何⼈都可以下载和使⽤。美国公司有没有在研究、借鉴、甚⾄直接使⽤DeepSeek 的模型输出来改进⾃⼰的产品?

 

开源不等于放弃所有权利——很多开源协议明确禁⽌⽤输出来训练竞品模型。但在⽬前的舆论环境中,这个⽅向的审视⼏乎为零。

 

如果蒸馏在道德上是错的,那它在任何⽅向上都应该是错的。如果只在⼀个⽅向上被追究、被报道、被上升到国家安全⾼度,那我们⾯对的到底是⼀个知识产权问题,还是⼀个披着技术外⾐的地缘政治叙事?

 

这个问题没有现成答案。但不问这个问题,我们的理解就是不完整的。

安全叙事经得起推敲吗?

 

Anthropic 在这次指控中反复强调⼀个论点:蒸馏出来的模型会丢失安全护栏,可能被⽤于⽣物武器开发、⽹络攻击、⼤规模监控。这也是它呼吁加强出⼝管制的核⼼理由。

 

这个论点听起来很有说服⼒,但逻辑上有⼀个跳跃。

 

安全护栏不是通过蒸馏传递的。 护栏是在模型基础能⼒训练完成之后,通过⼈类反馈强化学习(RLHF)等技术单独加上去的⼀层约束。蒸馏抽⾛的是模型的底层能⼒——推理、代码、 ⼯具调⽤——⽽不是护栏本⾝。

 

换句话说,任何⼀个拥有⾜够技术能⼒的团队,拿到⼀个开源模型之后都可以⾃⾏移除安全限制,根本不需要通过蒸馏 Claude 来获得“没有护栏的危险能⼒”。

 

把“蒸馏”和“安全风险”强⾏绑定,在技术逻辑上并不严密。但它在政策倡导上⾮常有效——因为它把⼀ 个商业竞争问题包装成了国家安全问题,⽽国家安全的标签⼀旦贴上,讨论的空间就会急剧收窄。

 

这不是说安全风险不存在。AI 能⼒的扩散确实带来真实的风险。但谁在定义“安全”、定义的标准是什么、定义的动机是否纯粹——这些问题同样需要被追问。

蒸馏 AI 违规,蒸馏⼈呢?

 

我们已经聊了机器对机器的蒸馏。但还有⼀种提取能⼒的⽅式,规模更⼤、更隐蔽,却⼏乎没⼈拿来跟

 

蒸馏放在⼀起说。

 

以头部数据标注公司为代表,⾏业内普遍以 100 到 200 美元的时薪,在全球范围内招募各⾏业的资深专业⼈⼠参与 AI 训练任务。⼀个医⽣标注“这张 CT 影像的诊断应该是什么”,⼀个投⾏分析师标注“这份财报的关键风险点在哪”,⼀个律师标注“这段合同条款的法律风险是什么”。

 

但实际操作⽐“标注”两个字残酷得多。

 

很多时候,专家不只是答题的⼈,还得⾃⼰出题。 平台要求专家⾃⾏构建业务场景,然后⾃问⾃答—— 相当于⼀个⼈同时扮演蒸馏流程⾥“设计 Prompt”和“⽣成输出”两个角⾊。 更关键的是,如果专家构建的场景不够特别,或者跟平台已有的数据太像,就会被打回重来,要求想更⼩众、更边缘的情境。 ⽽被打回的那些时间,不计⼊⼯时,不算钱。

 

想想这在⼲什么:平台⽩嫖了专家最难的那部分劳动——思考、构建、探索——只为最终被“认可”的输出买单。 ⽽那些被打回的场景,平台真的删掉了吗?还是也悄悄进了数据库,只是没有付钱?

 

⽽且平台为什么拼命逼专家往⼩众场景⾛?因为通⽤场景互联⽹上到处都是,不需要花钱找⼈。平台真正饥渴的是只存在于资深从业者脑⼦⾥的边界知识——罕见病例怎么判断、极端市场条件下怎么对冲、冷⻔法律条款怎么适⽤。这些知识的稀缺性,恰恰是这些专家和他们所在机构最核⼼的竞争壁垒。

 

⼀⼩时⼀两百美元买⾛的不是劳动时间,是⼏⼗年经验⾥最稀缺的那⼀层。 ⽽且被打回的那些⼩时,连⼀两百美元都省了。

 

流程拆开看:让⾏业专家⾃⼰构建场景、⾃⼰回答、不断被逼向更稀缺的知识边界——这和机器蒸馏的流程如出⼀辙,只是被蒸馏的对象从 AI 模型换成了⼈。

 

⽽且这些专家通常签过竞业协议和保密协议,他们在标注任务中输出的专业判断,严格来说很可能已经违反了与雇主的合同义务——只是没有⼈追究,甚⾄没有⼈意识到。

 

Anthropic 指控 MiniMax 蒸馏了 1,300 万次对话。这些数据标注公司在全球有多少标注员,累计产出了多少条训练数据?这个数字恐怕⽐1,300 万⼤⼏个数量级。

 

如果从别⼈的 AI 模型⾥提取能⼒叫蒸馏,那从别⼈的员⼯脑⼦⾥提取能⼒,该叫什么?

 

这个问题之所以没有被讨论,可能恰恰因为它牵扯到的不是⼏家中国公司,⽽是整个 AI 产业的训练数据供应链——包括指控别⼈蒸馏的那些公司⾃⼰。

AI⾏业最⼤的未解命题

 

这整件事撕开了 AI⾏业⼀个根本性的问题:在 AI 的价值链条上,知识产权的边界到底画在哪?

 

  • 作者写了⼀本书→ 被抓取⽤于训练→ 模型学会了写作→ 模型输出了新⽂本→ 这个输出⼜被另 ⼀个模型蒸馏⾛了。这条链条上,从哪个环节开始算“偷”?

  • 美国版权局已经明确:AI⽣成的内容不享有版权保护,因为版权要求⼈类作者⾝份。那么 Anthropic 指控别⼈“偷”了它的模型输出,法律基础到底有多牢固?

  • 蒸馏技术本⾝是公开的、通⽤的机器学习⽅法。禁⽌别⼈对你的模型做蒸馏,和禁⽌别⼈对你的产品做逆向⼯程,边界在哪?

  • 为了抓蒸馏,AI 公司得把⽤⼾⾏为看多深?⽤⼾知道⾃⼰被看了吗?同意了吗?

  • ⼀项指控同时服务于商业利益、公众形象和政策博弈时,动机还能说得清吗?

  • 蒸馏这件事,是不是只许州官放⽕不许百姓点灯?如果只在⼀个⽅向上被追究,它还算技术伦理问题吗?

  • 当“国家安全”成为 AI 竞争的万能论据时,谁来审视这个论据本⾝?

  • 从专业⼈⼠脑⼦⾥⼤规模提取⾏业经验⽤来训模型,和从 AI 模型⾥提取能⼒,本质上有什么区别?凭什么前者是正常⽣意,后者就是“盗窃”?

 

法院还没有答案,⽴法者还没有答案,⾏业⾃⼰也还没有答案。

 

但有⼀件事是确定的:这场博弈怎么收场,直接决定未来⼗年 AI⾏业的竞争格局和游戏规则。

 

谁拥有 AI 的“知识”?这个问题,⽐我们想象的要难回答得多。


本⽂基于 Anthropic 2026 年 2⽉23⽇公开声明及 Bloomberg、TechCrunch、VentureBeat 等多家媒体 报道整理。⽂中涉及的指控均为 Anthropic 单⽅⾯陈述,截⾄发稿三家公司均未公开回应。

 

本⽂由号称被蒸馏的当事⼈协助撰写

Oracle AI Database 26ai - 适用于所有数据的新一代 AI 原生数据库

免费的 Oracle AI 数据库平台

请访问原文链接:https://sysin.org/blog/oracle-database-26ai/ 查看最新版。原创作品,转载请保留出处。

作者主页:sysin.org


数据是 AI 的燃料。Oracle AI Database 26ai 将 AI 引入您的数据,从而简化应用开发和关键任务工作负载。

Oracle AI Database

Oracle AI Database 26ai 赋能 “AI for Data” 革命

Oracle 将 AI 架构到 Oracle AI Database 26ai 的核心,进一步履行 Oracle 致力于帮助客户安全地将 AI 应用于各种环境中的所有数据的承诺。

  • Data Deep Dive@AI World 2025https://www.oracle.com/ai-world/

    在 10 月 13 日至 16 日于拉斯维加斯举行的 2025 甲骨文全球 AI 大会 Data Deep Dive 活动中,您将了解 Oracle 的数据战略如何帮助企业推动 AI 创新、简化数据管理、加快应用开发以及将数据作为竞争优势。

为什么要选择 Oracle AI Database

面向数据的 AI

  • 通过内置 AI Vector Search 和数据库内机器学习将 AI 引入数据,消除集成和管理多个数据库的复杂性和成本,同时保持数据一致性。
  • 在不牺牲安全性、可用性和性能的情况下 (sysin),大规模使用 AI 并从中获益。
  • 结合使用检索增强生成 (RAG) 和企业级 LLM 等新技术与自己的业务数据,以获得更加符合具体情境且更相关的结果。

详细了解 Oracle AI Database 中的基础 AI 技术:https://www.oracle.com/cn/database/features/#foundational-ai

面向数据的 AI

面向数据的开发

  • 别让有限的数据类型或编程语言妨碍您的创新 — 这个融合数据库支持所有现代数据类型、工作负载和开发风格,助您简化应用开发。
  • 您可以利用 JSON Relational Duality 简化文档模型 (sysin),从而获得关系框架的可扩展性。
  • 使用内置的 APEX 平台,加快由生成式 AI 驱动的低代码开发速度。使用容器化的可插入数据库,简化微服务的开发和部署。

了解 JSON Relational Duality:https://www.oracle.com/cn/database/json-relational-duality/

面向数据的开发

面向数据的关键任务

  • True Cache 能够在改善应用响应速度的同时,降低数据库服务器负担,让您无需重写应用。
  • 使用 SQL Firewall,保护数据库免受 SQL 注入攻击(包括零日攻击)。使用带 RAFT 复制的 Globally Distributed Database,在满足数据驻留法规的同时,管理多个区域的数据。
  • 无论您的数据位于本地还是 Oracle Cloud 中,您都可以使用相同的技术。

了解 True Cache:https://www.oracle.com/cn/database/truecache/

面向数据的关键任务

部署选项

灵活部署,精确满足您的独特需求

  • 本地部署 Oracle AI Database 服务

    您可以在自已的办公地点利用您自已的硬件运行 Oracle AI Database,也可以在您的数据中心采用 Oracle Exadata 以获取出色性能、灵活性和强大功能。

    Oracle Exadata:https://www.oracle.com/cn/engineered-systems/exadata/

  • 在本地部署 Oracle Cloud 技术

    您可以利用自己的防火墙保护由 Oracle 托管的这个适用于 Oracle AI Database 的混合云平台。

    Cloud@Customer:https://www.oracle.com/cn/cloud/cloud-at-customer/

  • 基于 Oracle Cloud Infrastructure 部署 Oracle AI Database

    您可以利用强大的计算能力、物理存储和各种工具简化日常数据库管理操作,并通过 Oracle 精心设计的高性能集成系统运行企业级云数据库。Autonomous AI Database 可为企业提供全自动化的体验 (sysin),其中包含了自动扩展功能,可为 OCI 上的任何数据库提供较低的总拥有成本。

    数据库云技术服务:https://www.oracle.com/cn/database/technologies/

  • 在多云环境中部署 Oracle AI Database

    数据库应用使用基于 Oracle Cloud Infrastructure 运行的 Oracle AI Database 服务在超大规模数据中心内运行,并与超大规模的控制台和 API 深度集成,从而在您选择的超大规模环境中实现高性能、可扩展性和可用性。

    Oracle Multicloud 解决方案:https://www.oracle.com/cn/cloud/multicloud/

新增功能

在今年于拉斯维加斯举行的 Oracle AI World 上,Oracle 发布了其最新旗舰产品:Oracle AI Database 26ai。首先,它作为 Oracle Database 产品线的延续,支持此前所有的功能,包括所有关键任务能力。它支持自助式管理配置,也支持全自动运行、自动调优的 Autonomous AI Database。它既能在本地部署,也能运行在公有云超大规模环境,或 Oracle Cloud Infrastructure (OCI) 中。它支持最常见的数据管理模型,包括关系表、JSON 文档、图形等,还支持空间数据、不可变(区块链)账本,以及文本文件的数据存储与分析。它能够针对 AI、OLTP、分析、流处理、IoT 等多种负载优化数据存储与访问 (sysin)。它可以维护单一物理/云位置的数据库,也可以利用分布式数据库功能跨区域运行。它可以运行在裸金属、容器、本地 Oracle 工程系统中,也可以通过 Cloud@Customer 部署在 OCI 上,或运行于 Azure、AWS、Google Cloud。

但这些你可能都已经知道。那么,新的能力是什么?是什么让 Oracle AI Database 26ai 成为企业范围内部署数据驱动 AI 的理想平台?

新功能

以下新功能进一步增强了 Oracle AI Database 26ai 作为企业级 AI 数据平台的能力:

  • AI 向量搜索(包括支持 LangChain)
  • 数据使用案例领域
  • Exadata AI Smart Scan
  • 大模型(LLM)集成
  • 注释(Annotations)
  • 外部表向量数据支持
  • 增强版 JSON-关系双向视图
  • True Cache
  • 属性图支持
  • SQL 防火墙
  • 全球分布式数据库

此外,本次版本还提供实时 SQL 执行计划管理、JavaScript 存储过程、只读 PDB 备用库,以及滚动补丁能力。

Oracle AI Database 26ai 如何胜任 AI 平台核心

让我们看看该 DBMS 及其最新更新如何满足企业级 AI 数据平台的要求:

  • 可以基于相似性或近似特征搜索数据,使用 Oracle AI Vector Search,可纳入标准 SQL,也可用于搜索非结构化数据。不同于其他数据库外部执行向量搜索的方式,Oracle 将此能力直接集成于数据库核心,提升效率与灵活性。借助 Autonomous AI Database 的“目录的目录(Catalog of Catalogs)”,数据查找与整合更加容易。
  • 对于跨区域物理分布的数据库,Oracle Globally Distributed Database 使用 Raft 算法提供一致性、最佳事务吞吐与复制能力。
  • Oracle SQL 不仅可以访问 Oracle Database,还可访问其他数据库,尤其强调对 Apache Iceberg 表的支持。Oracle True Cache 提供更高效的时间点缓存,弥补性能差异,优于外部第三方方案 (sysin)。
  • JSON Relational Duality Views 提供以 JSON 文档视图方式访问关系数据,同时保持数据一致性并简化应用开发。此外,Select AI 能基于自然语言提示自动生成正确 SQL。
  • 能够随着数据量增长自动扩展,尤其在 OCI 环境中,可透明地向上或向下伸缩。
  • 允许非技术用户通过自然语言与可视化界面构建应用。Oracle AI Database 26ai 中的数据可作为关系型、JSON 或图结构处理,无需特殊技能。
  • 除了加快专业开发者 AI 应用开发的能力外,本版本也让 JavaScript 开发者能使用 JavaScript 存储过程来编写数据库逻辑。
  • 由于平台以全面方式处理数据,因此其安全性也必须内嵌于 SQL 处理过程之内。Oracle SQL Firewall 能阻止未授权 SQL 与 SQL 注入攻击,并提供对所有 SQL 流量的完整可见性以便审查与故障检测。

系统要求

官方要求 OL8/OL9,也可以运行在其他 RHEL8/9 兼容发行版上。

下载地址

Download:

基于无人机视角的道路损害检测数据集详解与目标检测应用实践

一、引言:无人机赋能道路病害智能巡检

随着城市化进程加快和交通基础设施规模的持续扩大,道路养护与安全管理面临着巡检范围广、人工成本高、响应速度慢等现实挑战。传统人工巡检方式在面对高速公路、城市主干道、山区公路及灾后应急场景时,往往难以兼顾效率与精度。

在此背景下,无人机(UAV)+ 计算机视觉逐渐成为道路损害检测的重要技术路径。通过搭载高清摄像设备与稳定云台,无人机能够从空中获取大范围、连续、高分辨率的道路图像数据,为基于深度学习的目标检测算法提供可靠输入。

本文将围绕一个无人机视角道路损害检测数据集展开,系统介绍其数据构成、标注类别、技术特点及在目标检测任务中的应用价值。
在这里插入图片描述

数据集下载

链接:https://pan.baidu.com/s/1CkmQRHQDjXzGa9KESO0i2A?pwd=snt5
提取码:snt5 复制这段内容后打开百度网盘手机App,操作更方便哦

数据集说明
在道路养护巡检、交通通行安全保障、基础设施寿命评估及灾害后道路恢复等对路面损伤识别精度、病害类型区分能力及复杂环境适应性起关键作用的领域,基于无人机平台的道路损伤目标检测系统,依托无人机载高清摄像设备、实时数据传输模块及图像处理分析技术,实现对核心目标 “Alligator crack(鳄鱼纹裂缝)”“Longitudinal crack(纵向裂缝)”“Pothole(坑洼)”“Transverse crack(横向裂缝)” 的精准检测,直接关系到交通管理部门对城市主干道、高速公路路面健康状况的实时掌控(如日常道路病害隐患排查、高负荷路段损伤趋势监测)、乡村公路及山区道路(如盘山公路、隧道出入口路段)病害分布的动态研判及自然灾害(如暴雨、地震)后受损道路的快速评估;这四类道路损伤作为判断路面通行风险等级、养护作业优先级及道路修复资源调配的核心依据,其精准识别检测是开展道路养护计划制定、交通管制策略调整、修复施工路径规划及路面生命周期管理的基础,对特定场景下(如夜间低光照环境中路面裂缝识别、雨季积水路段坑洼检测、复杂交通流环境下路面损伤捕捉)的准确区分,还能为管理部门提供道路损伤发展规律、高频病害区域等关键信息,辅助评估道路通行安全态势与养护策略优化需求。

二、数据集背景与建设目标

在这里插入图片描述

2.1 无人机道路检测的技术优势

相较于车载检测与人工拍摄,无人机巡检具备以下显著优势:

  • 视角灵活:可覆盖高架桥、隧道口、山区弯道等复杂路段
  • 范围广、效率高:单次飞行即可获取大面积道路信息
  • 环境适应性强:适用于灾后、封闭道路等特殊场景
  • 数据一致性好:利于模型批量训练与长期监测

然而,无人机视角也带来了新的挑战,如目标尺度变化大、背景复杂、光照条件多变等,对检测模型的鲁棒性提出了更高要求。

2.2 数据集建设目标

该数据集的构建目标主要包括:

  1. 覆盖典型道路病害类型
  2. 贴近真实无人机巡检视角
  3. 支持主流目标检测模型训练
  4. 服务道路养护、交通安全与应急评估场景

在这里插入图片描述

三、数据集整体概述

3.1 基本信息

项目说明
数据集类型无人机道路损害检测
图像总数6341 张
数据来源无人机航拍道路图像
任务类型目标检测
标注形式Bounding Box

3.2 数据集划分详情

数据集已完成标准化划分,适用于直接训练:

数据子集数量
训练集(Train)5853
验证集(Val)488
可根据需求自行扩展测试集或进行交叉验证。

四、道路损害类别定义与特征分析

数据集中共标注 4 类典型道路病害,覆盖道路结构性损伤与表面损害的主要形式。

nc: 4
names:
  - Alligator crack
  - Longitudinal crack
  - Pothole
  - Transverse crack

4.1 Alligator Crack(鳄鱼纹裂缝)

  • 呈现网状、不规则裂缝形态
  • 通常代表结构层疲劳损伤
  • 是道路寿命评估的重要指标

4.2 Longitudinal Crack(纵向裂缝)

  • 沿道路行驶方向分布
  • 常出现在车辙带或接缝区域
  • 易在雨水渗透后进一步恶化

4.3 Transverse Crack(横向裂缝)

  • 垂直于行驶方向
  • 多由温度收缩或结构应力引起
  • 在寒冷或昼夜温差大地区较为常见

4.4 Pothole(坑洼)

  • 表现为明显凹陷区域
  • 对行车安全威胁最大
  • 是养护优先级最高的病害之一

五、数据集技术特点与挑战分析

5.1 无人机视角带来的挑战

该数据集在视觉层面具有以下特点:

  • 目标尺度变化剧烈(随飞行高度变化)
  • 背景干扰复杂(车辆、阴影、标线、积水)
  • 光照条件多样(强光、阴影、阴天)
  • 裂缝类目标边界模糊

这使其成为检验目标检测模型在真实复杂环境下表现的理想数据集。

5.2 数据集的工程价值

  • 可直接用于 YOLO / Faster R-CNN / RetinaNet 等模型
  • 适合研究 小目标检测、细长目标识别、复杂背景抑制
  • 有助于评估模型在真实巡检任务中的泛化能力

六、适用模型与训练建议

6.1 适用模型算法

  • YOLOv5 / YOLOv8(实时性优)
  • YOLOv8 + 高分辨率输入(裂缝检测更友好)
  • Anchor-Free 模型(处理尺度变化)

6.2 训练策略建议

  • 提高输入分辨率(如 1024×1024)
  • 使用 Copy-Paste / Mosaic 数据增强
  • 针对裂缝类目标调整 IoU 与 NMS 策略
  • 引入 Attention 机制提升细节感知能力

在这里插入图片描述

七、典型应用场景

7.1 道路养护巡检

  • 城市主干道病害自动识别
  • 高速公路定期健康评估
  • 养护优先级智能排序

7.2 交通安全与管理决策支持

  • 高风险路段预警
  • 病害分布热力分析
  • 养护资源调度优化

7.3 灾后道路快速评估

  • 暴雨、地震后道路损伤排查
  • 应急抢修路径规划
  • 交通恢复决策支持

八、结语:无人机道路检测的未来方向

基于无人机视角的道路损害检测,是智能交通与智慧城市建设的重要组成部分。本文介绍的数据集,从真实巡检场景出发,覆盖典型道路病害类型,为目标检测算法在复杂环境下的验证与落地提供了坚实基础。

随着无人机平台、传感器精度及深度学习算法的持续演进,结合此类高质量数据集的研究,将进一步推动道路养护从“被动响应”向“主动预防”转变。

背景

Access 从 2007 版开始已经内置了日期选择器,文本框格式设置为日期型后,右侧会自动出现一个小日历图标。但这个内置功能有几个明显局限:

  • 老格式不支持:.mdb 格式的旧库没有这个功能
  • 没有年月选择:只能逐月翻页选日期,无法直接选"某年某月",在账期、报表筛选等场景下操作繁琐
  • 界面较简陋:样式陈旧,不支持自定义,也没有时间选择部分

这个项目的出发点就是在不依赖任何外部控件的前提下,用标准模块 + Access 窗体自己实现一套更完整的日期输入组件,同时覆盖日期时间选择和年月选择两种场景。项目已开源,源码见文末链接。

它长什么样?

日期时间选择器


左侧是经典的日历网格,右侧是小时/分钟滚动列表。当前月日期黑色显示,非当月灰色,今天蓝色边框,选中日期蓝色背景白字。鼠标悬停时还有浅蓝色高亮效果,交互体验接近现代 Web 日期选择器。

年月选择器

4 列 × 3 行的月份网格,支持按年、按十年快速翻页,适用于报表筛选、账期选择等只需要"年+月"的场景。


技术架构:为什么选择这种实现方式?

这个项目的核心设计理念是 "纯标准模块 + 表达式事件绑定",具体来说:

1. 零窗体代码

生成的 frmDatePickerfrmYearMonthPicker 窗体本身没有任何代码模块。所有逻辑都写在标准模块(Module_DatePicker.bas / Module_YearMonthPicker.bas)中。

2. 表达式事件绑定

控件的事件不是通过窗体代码模块的 Private Sub 来响应,而是直接在控件属性中写表达式:

OnClick = "=DatePicker_DayClick(1)"
OnMouseMove = "=DatePicker_DayMouseMove(1)"

这种方式的好处是:窗体可以完全由代码自动生成(CreateForm + CreateControl),不需要手动在设计视图中操作,真正实现一键部署

3. 窗体自动构建器

导入 .bas 模块后,只需在立即窗口执行一行命令,构建器就会自动创建窗体、布局控件、绑定事件:

CreateDatePickerForm       ' 创建日期时间选择器
CreateYearMonthPickerForm  ' 创建年月选择器

再次执行会自动删除旧窗体并重建,方便迭代调整。

4. Win32 API 精准定位

在下拉模式下,选择器窗体会精准定位到文本框正下方,就像一个真正的下拉控件。这是通过 GetFocusGetWindowRectMoveWindow 这组 Win32 API 实现的,同时兼容 32 位和 64 位 Access。

5. 鼠标悬停效果

42 个日期格子(或 12 个月份格子)都绑定了 OnMouseMove 事件。通过模块级变量 m_iHoverCell 跟踪上一个悬停位置,实现了高效的悬停高亮切换——只刷新变化的两个格子,而不是整个网格,避免了闪烁。


怎么用?三步上手

第一步:导入模块

从 GitHub 下载 .bas 文件,在 VBA 编辑器中 文件 → 导入文件

  • Module_DatePicker.bas — 日期时间选择器
  • Module_YearMonthPicker.bas — 年月选择器(按需导入)

第二步:创建窗体

在立即窗口(Ctrl+G)中运行:

CreateDatePickerForm

第三步:调用 API

最简用法——一行代码弹出选择器:

Dim dt As Variant
dt = ShowDatePicker()
If Not IsNull(dt) Then MsgBox "选择了: " & dt

绑定文本框——双击弹出、选完自动回写:

' 在窗体的 Form_Load 中
AttachDatePicker Me, "txtOrderDate"           ' 日期+时间
AttachDatePicker Me, "txtBirthday", False     ' 仅日期
AttachYearMonthPicker Me, "txtMonth", "yyyy-mm"  ' 年月

<!-- 图片位置:绑定文本框后的实际交互效果(双击弹出、选择、回写) -->

零代码绑定——直接在属性表中写表达式:

=PickDateForCtl("frmOrder","txtDate",True)

这意味着你甚至不需要打开 VBA 编辑器,直接在控件属性里粘贴一行表达式就能用。


进阶玩法

自定义输出格式

PickDateFor Me.txtDate, False, "yyyy-mm-dd"
PickYearMonthFor Me.txtMonth, "yyyy年mm月"

自动扫描绑定

如果你的窗体上有大量日期字段,可以一键全部绑定:

AttachDatePickerAll Me              ' 自动识别名称含 date/日期/time 的文本框
AttachDatePickerAll Me, "dt"        ' 匹配 dt 开头的文本框

修改主题色

模块顶部的颜色常量可以轻松替换:

Private Const CLR_BLUE As Long = 16024898   ' 改成你喜欢的颜色
Private Const CLR_HOVER As Long = 16576233  ' 悬停色

兼容性

环境支持情况
Access 2010 / 2013 / 2016 / 2019 / 365
32 位 / 64 位
.accdb / .mdb
运行时版本 (Runtime)

完整源码

项目已开源,欢迎 Star ⭐:

GitHub 地址:https://github.com/miaowei2/access-datepicker

包含:

  • Module_DatePicker.bas — 日期时间选择器(含构建器 + API + 事件处理)
  • Module_YearMonthPicker.bas — 年月选择器(独立模块,可单独使用)
  • 详细的使用说明文档

下载后直接导入即可使用,无需任何额外配置。


写在最后

Access 虽然"老",但在中小企业、政府机关、制造业中依然有着广泛的应用。很多运行多年的 Access 系统,承载着核心业务数据,短期内不可能迁移到其他平台。

与其抱怨 Access 的种种不足,不如用技术手段去改善它。一个好用的日期选择器看似是小事,但它直接影响一线操作人员的录入效率和数据质量。

如果你的团队正在使用 Access,或者你是一名 Access 开发者,欢迎试用这个开源组件。 如果觉得有用,请帮忙转发给更多需要的人。

在 Access 开发中遇到任何问题,也欢迎在公众号后台留言交流。我会持续分享 Access 实战技巧和开源工具,帮助大家把这个"老伙计"用得更顺手。


Access 开发」 专注于 Microsoft Access 开发与企业级应用,提供以下服务:

📚 技术培训

Access VBA 从入门到精通(线上/线下)

Access + SQL Server 企业级开发实战

Access 系统性能优化与架构设计

💼 定制开发

企业 ERP/CRM/进销存等系统开发

旧系统升级与性能优化

🔧 技术支持

代码审查与重构建议

疑难问题远程诊断

一对一技术辅导

联系方式:

公众号后台留言

邮箱:will.miao@edonsoft.com

微信:edonsoft

技术改变业务,专注创造价值。

工业织物缺陷目标检测数据集(1000+高精度标注样本)| AI训练适用于目标检测任务

一、引言:工业视觉检测面临的新挑战

在智能制造与工业 4.0 的背景下,机器视觉在质量检测环节中的地位愈发关键。织物瑕疵检测作为工业视觉的重要分支,广泛应用于纺织、服装、功能性材料等领域,其检测结果直接影响产品合格率、生产成本与企业品牌信誉。

然而,与金属表面、印刷品等具有明显结构纹理的检测对象不同,高精细织物(C1 类织物)存在纹理极弱、表面特征稀疏、缺陷对比度低等问题,对传统视觉算法及深度学习模型提出了更高要求。

为此,本文将系统介绍一个面向工业织物弱纹理场景的瑕疵检测数据集,并结合目标检测任务的工程实践,探讨其在模型训练、鲁棒性评估与算法研究中的应用价值。
在这里插入图片描述

数据集下载

链接:https://pan.baidu.com/s/1OVK43Qr_gpi1iCzQ6oJ4Vw?pwd=g9gg
提取码:g9gg 复制这段内容后打开百度网盘手机App,操作更方便哦

工业织物瑕疵检测

本数据集专为工业织物瑕疵检测与分类任务构建,特别聚焦于 C1 类高精细织物。此类织物表面光滑、纹理极细、几乎无可见结构特征,典型代表如 普通粘胶纤维与丝绸织物,适用于弱纹理背景下的目标检测算法研究与模型鲁棒性评估。

数据集中包含 1000+ 张 768×512 分辨率的织物图像,标注了四类常见工业缺陷,包括:洞(Hole)、异物(Foreign Object)、油斑(Oil Stain)及织线错误(Weaving Defect)。数据集采用标准训练、验证与测试目录结构组织,便于直接用于 YOLO 等目标检测框架训练。

该数据集适用于 工业视觉检测、弱纹理表面缺陷识别、制造业质量控制、深度学习模型可靠性验证等研究与应用场景,为探索复杂微弱特征中的瑕疵识别提供理想实验基准。

数据集详细信息
图像数量: 1000+
图像分辨率: 768×512像素
课程:
0: 洞
1:异物
2:油斑
3:线程错误

path: main/datasets
train: images/train
val: images/val
test: images/test

nc: 4

names: ['洞','异物','油斑','织线错误']

nc: 4
names: ['Hole', 'Foreign Object', 'Oil Stain', 'Weaving Defect']

在这里插入图片描述

二、数据集背景与设计目标

2.1 织物类型与检测难点

本数据集聚焦于 C1 类高精细织物,其典型特征包括:

  • 表面光滑、纹理周期性弱
  • 几乎无明显方向性结构
  • 局部缺陷与背景灰度差异极小

代表性材料包括:

  • 普通粘胶纤维织物
  • 丝绸类高精度织物

在此类织物上,孔洞、油斑等缺陷往往呈现为微弱灰度扰动,极易被噪声、光照变化所淹没,是检验目标检测模型感知能力与泛化性能的理想场景。

2.2 数据集设计初衷

该数据集在构建时重点关注以下目标:

  1. 服务真实工业场景
    图像来源贴近实际生产线拍摄条件,而非合成或过度增强数据。
  2. 考验模型在弱纹理背景下的检测能力
    避免通过明显纹理“降低难度”。
  3. 兼容主流目标检测框架
    数据结构与标注格式可直接用于 YOLO 系列模型训练。

在这里插入图片描述

三、数据集整体概述

3.1 基本信息

项目说明
图像数量1000+ 张
图像分辨率768 × 512
数据类型RGB 工业织物图像
标注形式目标检测(Bounding Box)
任务类型工业缺陷检测

3.2 缺陷类别定义

数据集中共标注 4 类常见工业织物缺陷

类别 ID英文名称中文说明特征描述
0Hole结构性破损,边缘不规则
1Foreign Object异物表面附着非织物物体
2Oil Stain油斑灰度渐变,边界模糊
3Weaving Defect织线错误经纬异常、线条错位

这些缺陷在弱纹理背景下形态差异细微,对检测算法的特征表达能力提出较高要求。


四、数据集目录结构与标注规范

4.1 数据集路径结构

数据集遵循标准的 YOLO 训练目录组织方式:

main/datasets/
├── images/
│   ├── train/
│   ├── val/
│   └── test/
└── labels/
    ├── train/
    ├── val/
    └── test/

该结构可直接对接:

  • YOLOv5 / YOLOv8
  • MMDetection(简单转换即可)
  • Ultralytics 官方训练脚本

4.2 类别配置文件示例

nc: 4
names: ['Hole', 'Foreign Object', 'Oil Stain', 'Weaving Defect']

标注文件采用 YOLO 标准格式:

class_id x_center y_center width height

所有坐标均为 相对比例(0~1),便于多分辨率训练。


五、数据集特点与技术价值分析

5.1 弱纹理背景下的目标检测挑战

与常规数据集(如 COCO、VOC)相比,本数据集具备以下显著特点:

  • 背景信息极少:模型无法依赖纹理模式记忆
  • 缺陷尺度变化大:从微小油斑到明显孔洞
  • 类别间视觉差异小:尤其是油斑与异物

这使得模型必须真正学会:

  • 局部异常建模
  • 细粒度特征提取
  • 高噪声环境下的目标定位

5.2 适合作为算法评测基准

该数据集非常适合用于:

  • YOLO 系列模型对比(v5 / v7 / v8 / v10)
  • Anchor-Free 与 Anchor-Based 方法对比
  • 注意力机制(SE / CBAM / ECA)效果评估
  • 数据增强策略在工业场景中的有效性验证

六、典型应用场景

6.1 工业视觉检测系统

  • 纺织品在线质检
  • 自动剔除瑕疵布料
  • 减少人工目检成本

6.2 制造业质量控制(QC)

  • 生产批次质量评估
  • 缺陷类型统计与溯源分析
  • 工艺参数优化反馈

6.3 学术研究与工程教学

  • 工业 AI 课程实验数据
  • 弱监督 / 小样本学习研究
  • 模型鲁棒性与泛化性测试

七、基于 YOLO 的训练实践建议

7.1 模型选择建议

  • 实时检测:YOLOv8n / YOLOv8s
  • 高精度场景:YOLOv8m / YOLOv8l
  • 研究用途:引入 Transformer 或 Attention 改进模型

7.2 训练技巧

  • 使用 Mosaic + MixUp 但控制比例
  • 启用 Focal Loss 以缓解类别不平衡
  • 适当提高输入分辨率(如 1024)
    在这里插入图片描述

八、结语:工业弱纹理检测的价值与未来方向

工业织物瑕疵检测并非简单的目标检测问题,而是一个融合了弱特征感知、噪声抑制与细粒度识别的综合挑战。本文介绍的数据集,正是围绕这一核心难点构建,具备较高的工程与研究价值。

无论是用于工业落地,还是作为算法验证基准,该数据集都为复杂弱纹理场景下的智能视觉检测研究提供了可靠支撑。

随着更先进的模型结构与训练策略不断涌现,基于此类真实工业数据集的探索,将持续推动智能制造向更高精度、更高可靠性方向发展。

Apple Safari 26.3 发布 - macOS 专属浏览器 (独立安装包下载)

适用于 macOS Sequoia 和 macOS Sonoma 的 Safari 浏览器 26

请访问原文链接:https://sysin.org/blog/apple-safari-26/ 查看最新版。原创作品,转载请保留出处。

作者主页:sysin.org


Safari 浏览器
风驰电掣
数据密不透风

Safari

无论在哪种 Apple 设备上,用 Safari 浏览器上网都再好不过。它带来健全的自定选项、强大的隐私保护功能,以及傲人的电池续航,让你随时都能自如地浏览网络 (sysin)。至于速度,这款飞快的浏览器更再次超越自我。

了解如何将 Safari 浏览器设为默认

查看详细功能介绍

新增功能

Safari 26.3 Release Notes

Released February 11, 2026 — 26.3 (20623.2.7)

Safari 26.3 is available for iOS 26.3, iPadOS 26.3, visionOS 26.3, macOS 26.3, macOS Sequoia, and macOS Sonoma.

详见:Safari Release Notes

下载地址

Safari 26 for macOS Tahoe 包含在系统软件更新中。

旧版不定期清理。

Safari 26 for macOS Sequoia Installer

Safari 26 for macOS Sonoma Installer

Safari for macOS Ventura 停止更新,旧版请访问:

Safari for macOS Monterey 停止更新,旧版请访问:

其他下载:

更多:macOS 下载汇总 (系统、应用和教程)

在将算法模型部署至 征程 6 芯片平台的实际应用中,由于算法设计与硬件架构特性存在差异,可能会出现部分算子适配度有待提升、运行效率有待优化以及量化精度可进一步优化等情况。解决好这些问题有助于模型更快更好的运行,充分发挥硬件性能。

本文聚焦于算法模型在 征程 6 芯片上部署时的算子支持问题,包括算子不支持、算子运行效率低、算子量化精度差问题的解决和优化建议。重点阐述解决上述问题的优化思路给出优化案例,使模型在 征程 6 芯片平台实现更快速、更稳定的运行,为算法高效落地提供实用的技术路径。

1.算子替换

算子替换主要解决模型中存在 BPU 不支持的算子问题。当遇到无法支持的算子时,为提升执行性能需要使用 BPU 支持的算子对不支持的算子做替换,使尽可能多的运行在 BPU 中。

1.1 Scatternd 的产生和消除

ScatterND 算子由 op 做了 slice 操作 之后 又进行 inplace 产生,因此会引入 CPU 算子。若导出的 onnx 中均存在大量 ScatterND,希望从算法侧进行移除, 等价替换相关操作即可。以下给出几种使用场景:

场景 1:

# dummy code to generate ScatterND
import torch
from torch import nn
​
class DummyModel(nn.Module):
    def __init__(self):
        super().__init__()
​
​
    def forward(self, x):

将模型导出后会发现存在 scatternd 算子:

img

修改后不带 ScatterND 的代码与模型结构

import torch
from torch import nn
​
class DummyModel(nn.Module):
    def __init__(self):
        super().__init__()
​
    def forward(self, x):
        tmp1 = x[:, :2]
        tmp2 = x[:, 2:]

img

查看 onnx,scatternd 算子不存在,已被替换。

场景 2:

修改前 onnx 中带有 ScatterND 算子的代码示例

###### 修改前onnx中带有ScatterND算子的代码 ###### 
block_warp_offset = torch.clone(
    offset[
        :,
        pad_u : self.height - pad_b,
        pad_l : self.width - pad_r,
        :,
    ]
)
block_warp_offset[:, :, :, 0] += pad_l

修改后 onnx 中不带 ScatterND 算子的代码示例

###### 修改后onnx中不带ScatterND算子的代码 ###### 
block_warp_offset = torch.clone(
    offset[
        :,
        pad_u : self.height - pad_b,
        pad_l : self.width - pad_r,
        :,
    ]
)
a = block_warp_offset[:, :, :, :1] + pad_l

场景 3:

如下代码会引入 scatterND

# intri_mat shape为(1,4,4,4), intrinsic shape为(1,4,3,3)
intri_mat = torch.eye(4).unsqueeze(0).repeat(1, 4, 1, 1)
intri_mat[:, :, :3, :3] = intrinsic

修改与验证代码如下:

import torch
from torch import nn
​
class DummyModel(nn.Module):
    def __init__(self):
        super().__init__()
​
    def forward(self, intri_mat,intrinsic):
        ## ============方案1 =============
        # tmp1 = intri_mat[:, :, :3, :3]

方案 1 与方案 2 思想一样

img

场景 4:

原包含 scatternd 算子的代码:

key_points = self.scale_mul.mul(scale, self.exp.exp(anchor[1][..., None, 0:3])
rotation_mat[:, :, 0, 0] = anchor[2][:, :, 1] # cos
rotation_mat[:, :, 0, 1] = -anchor[2][:, :, 0] # sin
rotation_mat[:, :, 1, 0] = anchor[2][:, :, 0]
rotation mat[:. :, 1, 1] = anchor[2][:, :,1]

修改之后:

key_points = self.scale_mul.mul(scale, self.exp.exp(anchor[1][..., None, 0:3]))
temp_cos = anchor[2][:, :, 1]
temp_sin = anchor[2][:, :, 0]
temp_zeros = self.rotation_quant(temp_cos.new_zeros([bs, num_anchor]))
temp_ones = self.rotation_quant(temp_cos.new_ones([bs, num_anchor]))
temp1 = self.stack1.stack([temp_cos, -temp_sin, temp_zeros], dim=-1)
temp2 = self.stack2.stack([temp_sin, temp_cos, temp_zeros], dim=-1)
temp3 = self.stack3.stack([temp_zeros, temp_zeros, temp_ones], dim=-1)
rotation_mat = self.stack4.stack([temp1, temp2, temp3], dim=-2)

场景 5:

Swin Transformer 中为滑动注意力窗口计算对应的掩码值,不同区域做标识符区分

原代码为:

# calculate attention mask for SW-MSA
# +-----------+-----------+-----------+
# | Region 0  | Region 1  | Region 2  |
# +-----------+-----------+-----------+
# | Region 3  | Region 4  | Region 5  |
# +-----------+-----------+-----------+
# | Region 6  | Region 7  | Region 8  |
# +-----------+-----------+-----------+
img_mask = torch.zeros((1, H_pad, W_pad, 1), device=query.device)
h_slices = (

修改之后:

主要思路,把对原 tensor 划区域的赋值方式修改为划区域的拼接,先对 w 维度进行拼接,再对 h 维度拼接

cnt = 0
img_mask_patches = []
for h in [
    H_pad - self.window_size,
    self.window_size - self.shift_size,
    self.shift_size,
]:
    img_mask_patches.append([])
    for w in [
        W_pad - self.window_size,

1.2 Bool 赋值和 Mask 替换

对于 PNC 以及静态目标检测模型,模型中较多逻辑判断涉及到 bool 数据类型的赋值和 mask 操作,这一类操作可以考虑替换为 torch.where 算子,可以消除潜在的 cpu 算子并提升模型性能,例如

tfl_mask[valid == 0] = float("-65504")

该操作在 E/M 会引入 cast 和 equal 算子 cpu,如下

img

可以修改为:

x = torch.where(valid_mask == 0, torch.tensor(float("-65504"), device=x.device), x)

此外,此处 -65504 的极大值会影响模型中该算子输入的数据分布,影响量化参数统计从而影响量化精度,相同场景还有 attn 结构中对 attn\_mask 的填充:attn = torch.where(attn\_mask, float("-inf"), attn)。因此考虑到量化精度的话,这里建议进一步将填充值换为量化友好的数值:

x = torch.where(valid_mask == 0, torch.tensor(-100, device=x.device), x)

1.3 Nonzero 等效替换

目前 征程 6 芯片不支持 BPU Nonezero 算子,需要对其做替换使算子跑在 BPU 中:

# 修改前
key_mask=agent_mask.clone()
key_mask = key_mask.reshape(-1, self.T)
index=torch.nonzero(key_mask[:, -1]
key_mask[index,:] = 0 
# 修改后
key_mask=agent_mask.clone()
key_mask = key_mask.reshape(-1, self.T)
mask_filter = ~key_mask[:, -1]
key_mask = mask.logical_and(mask_filter.unsqueeze(1))

1.4 Enisum 等效替换

目前 征程 6 芯片不支持 torch.einsum 算子,可以使用以下两种方式替换:

import torch
A = torch.randn(2, 3, 4, 5, 6) # 形状为 (a=2, b=3, c=4, i=5, j=6)
B = torch.randn(6, 7, 2, 3) # 形状为 (j=6, k=7, a=2, b=3)
# 使用einsum进行操作
result = torch.einsum('abcij, jkab -> abcik', A, B)
# 直接等价实现
# 扩展张量A和B以对齐维度
A = A.unsqueeze(-1) # 扩展为 (a, b, c, i, j, 1)
B = B.unsqueeze(0).unsqueeze(-1).permute(3, 4, 5, 0, 1, 2) # 扩展为 (a, b, 1, 1, j, k)
# 逐元素相乘并对j维度进行求和
import torch
A = torch.randn(2, 3, 4, 5, 6) # 形状为 (a=2, b=3, c=4, i=5, j=6)
B = torch.randn(6, 7, 2, 3, 4) # 形状为 (j=6, k=7, a=2, b=3, c=4)
# 使用einsum进行操作
result = torch.einsum('abcij, jkabc -> abcik', A, B)
# 替代实现
B = B.permute(2, 3, 4, 0, 1) # tanspose为 (a, b, c, j, k)
result_alt = torch.matmul(A, B)
# 结果比较
compare = torch.allclose(result, result_alt, rtol=0.00001, atol=0.00001)

2.算子优化

算子优化分为执行效率的优化和精度的优化。在部署时可能出现算子引入的其他开销,或者算子的执行效率支持的不够好的情况,同时在部署时我们还需要考虑算子的量化精度友好性。本章节将分别针对算子的效率优化和精度优化,给出部署建议和优化方案,帮助模型更快、更好的运行。

2.1 效率优化

2.1.1 Topk 算子

征程 6E/M 在工具链 OE3.2.0 已支持 topk 算子在 SPU 上运行(征程 6B 在 OE3.5.0 版本支持),在 convert 时配置 enable\_spu=True 后算子将会被指定在 SPU 上运行。若 topk 算子后接的 gather、index 算子出现 CPU 的 cast 算子时,建议将 OE 版本升级到 OE-3.5.0(或者将 hbdk 升级到 4.5.5 及以上版本)。

2.1.2 Argmax 后 cast 消除

pytorch 的 argmax 输出的 idx 为 int64 类型,若不做改动会导致引入 CPU 算子,可以将 idx 的类型转为 int8/int16(视数值范围而定避免溢出)避免引入的开销,参考下图:

img

2.1.3 多个 eltwise 操作效率提升

当多个大尺寸的 op 做 add 时,若一次性 add 可能会引入带宽问题。若存在带宽问题,即 load&store 的时间大于计算时间,建议拆为逐个 add 相加,

使用示例

以下提供两个常见的对多个 eltwise 计算的使用示例,方式 1 为多次相加;方式 2 为一次相加。

方式 1:

homo_feats = []
        for i in range(12):
            homo_feat = self.grid_sample(
                feat,
                fpoints[i * B : (i + 1) * B],
            )

            homo_dfeat = self.dgrid_sample(
                dfeat,
                dpoints[i * B : (i + 1) * B],

方式 2:

for i in range(12):
            homo_feat = self.grid_sample(
                feat,
                fpoints[i * B : (i + 1) * B],
            )

            homo_dfeat = self.dgrid_sample(
                dfeat,
                dpoints[i * B : (i + 1) * B],
            )
性能表现

以如下输入大小来测试性能差异:

input = {
    "feat": torch.randn(size=(1, 80, 238, 60)).to(torch.device("cuda:0")),
    "dfeat": torch.randn(size=(1, 1, 1260, 2040)).to(torch.device("cuda:0")),
    "fpoints": torch.randn(size=(12, 64, 256, 2)).to(torch.device("cuda:0")),
    "dpoints": torch.randn(size=(12, 64, 256, 2)).to(torch.device("cuda:0")),
    }

Temporal Statistics:

  • 方式 1:latency 为 3.267 ms

img

  • 方式 2: latency 为 2.321 ms

img

2.1.4 LayerNorm 优化

https://cloud.tencent.com/developer/article/2509912

论文:https://arxiv.org/abs/2503.10622

Dynamic Tanh(DyT)是由何恺明、Yarnn LeCun 等研究者提出的新结构,用于替代 Transformer 中的归一化层(如 LayerNorm),原理简单,在于归一化层的 input-output mapping 曲线近似 tanh 函数,可以直接使用 tanh 函数来拟合线性归一化层的效果。其设计简单高效,仅需 9 行代码即可实现,展现出优于或持平传统归一化层的性能,不仅部署性能明显优于 ln,训练速度也会有明显提升:

class DyT(nn.Module):
    def __init__(self, num_features, alpha_init=0.5):
        super().__init__()
        self.alpha = nn.Parameter(torch.ones(1)*alpha_init)
        self.weight = nn.Parameter(torch.ones(num_features))
        self.bias = nn.Parameter(torch.zeros(num_features))
    def forward(self, x):
        x = torch.tanh(self.alpha * x)
        return x * self.weight + self.bias

对于 transformer 模型的 征程 6 部署,替换为 dyt 也是一个很高效的选择,layernorm 会被拆分为 8 个算子,而 dyt 只有 4 个算子,且避免了 reducemean 的计算(相对来说不是那么高效,且量化不友好),部署性能以及量化友好度都有提升。

img

img

2.1.5 传统 Attention 优化

论文:https://arxiv.org/pdf/2206.08898

SimA 针对传统 Transformer Self-Attention 存在的主要问题,例如长序列任务的计算复杂度高;softmax 指数运算导致的梯度爆炸或消失等,完全移除 Softmax,采用线性相似度计算降低计算复杂度,同时保持模型近似表达能力,在主流的 ViT/NLP 模型中取得相当或更好的模型精度同时,有效降低了部署推理的延时,同时减少了训练时间

import torch
import torch.nn as nn
import torch.nn.functional as F


# SimA实现
class SimAttention(nn.Module):
    """ SimA attention block
    """
    def __init__(self, embed_dim, num_heads=8, qkv_bias=False, proj_drop=0.):

值得注意的是,实际使用中,在多层 attention 的 encoder 结构中,如果使用 SimA 做替换优化,往往保留最后一层为传统 softmax attention 做数值修正来保证模型整体精度效果,避免每层线性归一化带来的累计数值误差从而对 encoder 输出产生影响

2.1.6 Norm 优化

从计算效率从高到低排序:batchnorm > dyt > layernorm/instancenorm > groupnorm

但在实际算法场景中例如 transformer 类的模型,替换 batchnorm 后浮点精度可能无法训回来,因此 layernorm 更常用,此外还有 groupnorm 和 instancenorm

对于 group norm 而言,groups=1 就是 layernorm,groups=channels 就是 instancenorm,所以对于 group norm 的实现:

plugin 导出时通过 transpose+reshape 将 gn 转成 ln

img

经实验 layernorm 比 group norm 要快(因为可以避免前后 reshape),但是用户手动将 group norm 替换 layernorm1d,需要手动在前后加 permute(因为 ln 从最后一维开始 norm),替换比较麻烦。使用下面的方式对 channel 维度做 norm,同时避免引入前后的 permute:

from horizon_plugin_pytorch.nn.layer_norm import SplitLayerNorm
SplitLayerNorm(normalized_shape=[c, 1], dim=1)

2.1.7 nn.Embedding 优化

torch.nn.Embedding 要求输入 tensor 为 LongTensor,也就是 int32/int64,对于 E/M 而言会引入 bpu 不支持的 cast 算子从而跑在 cpu 上影响性能,常规的做法是。to(torch.int16).to(torch.int64),但是只对初始权重的模型有效(scale=1)可以融合。但对于真实权重的模型而言,会引入 dequantize+cast:

img

例如下面结构,让 embedding 的一路维持定点类型可优化

data = {
    # 定点输入
    "sdnavi_link_tbt_info": torch.ones((2, 20, 8, 7), dtype=torch.int16),
    # 浮点输入
    "sdnavi_link_info": torch.ones((2, 20, 8, 256), dtype=torch.float32),
}

class Encoder(nn.Module):
    def __init__(self,
                 ...

对定点数 tensor 的 quant 需要给 scale=1 的 fix\_scale 配置,参考如下

module_name_qconfig = {
    "quant": QConfig(
        output=FakeQuantize.with_args(
            observer=FixedScaleObserver,
            dtype=qint8,
            scale=1,
        )
    ),
}

优化后可实现 BPU 全一段。

2.2 精度优化

2.2.1 Inverse\_sigmoid 部署方案

Inverse sigmoid 容易出现 bc 导出掉点问题,若遇到此问题:

方式一:将 segmentlut 的参数从"curvature"改为"evenly"。

img

方式二:算法上去除 Inverse sigmoid 算子,对 sigmoid 的输入做 clamp(需重训,此方案需要验证对浮点的影响。)

img

注意:此示例中为提高 torch qat 精度,将 +reference sigmoid 放在了 cpu,若 torch qat 并不存在精度问题可以放在 bpu 中。

11.5219 为 inverse\_sigmoid 的输出上限

2.2.2 Gridsample 拆分

由于 BPU 采用定点数值计算,grid\_sample 算子在处理较大的 W 维度时,受限于硬件位宽精度,量化后的数值无法精确表示原始网格坐标,导致 nearest (最近邻)和 bilinear (双线性插值)两种采样方式均引入一定的精度误差。

示例:

class OriGridSample(nn.Module):
    def __init__(self):
        super(OriGridSample, self).__init__()
        self.unitconv = nn.Conv2d(1, 1, (1, 1))
        nn.init.constant_(self.unitconv.weight, 1)
        nn.init.constant_(self.unitconv.bias, 0)
        self.gridsample = hnn.GridSample(
            mode='bilinear',
            padding_mode='zeros',
            align_corners=True,

拆分后:

class SplitGridSample(nn.Module):
    def __init__(self):
        super(SplitGridSample, self).__init__()
        self.unitconv = nn.Conv2d(1, 1, (1, 1))
        nn.init.constant_(self.unitconv.weight, 1)
        nn.init.constant_(self.unitconv.bias, 0)
        self.gridsample1 = hnn.GridSample(
            mode='bilinear',
            padding_mode='zeros',
            align_corners=True,

2.2.3 Sin/Cos 算子去周期

  1. export 时如果发现敏感度排在前面的是 sin/cos 算子,且输入范围较大(超出-pi~pi 一个周期),可以将 sin/cos 替换为 plugin 的自定义算子,并配置 single\_period=True,注意需要重新做量化
import horizon_plugin_pytorch.nn as hnn
class modelnet(nn.module):
    def __init__(self,):
        ...
        self.sin=hnn.Sin(single_period=True)
        self.cos=hnn.Cos(single_period=True)
  1. 也可以自行处理 sin/cos 输入,按照周期性将输入处理到[-pi, pi)之间,注意需要重新做量化
x = x - 2 * torch.floor(x * ( 0.5 / torch.pi) + 0.5) * torch.pi

2.2.4 Conv/Linear weight 高低位拆分

该方案为保障 conv 的高精度计算,对 weight 对高低位的拆分。在用户不重训浮点的情况下,量化训练前需要对用户的浮点 ckpt 部分 linear weight 进行高低位拆分:

方式 1:通过修改 plugin 源码方式,需要将红框后面的减法去掉

img

方式 2:对 model 做拆分:

#=============== 用户原 model =============
self.enc_bbox_head = MLP(hd, hd, 4, num_layers=3)
class MLP(nn.Module):
    """Very simple multi-layer perceptron (also called FFN)"""

    def __init__(self, input_dim, hidden_dim, output_dim, num_layers):
        super().__init__()
        self.num_layers = num_layers
        h = [hidden_dim] * (num_layers - 1)
        self.layers = nn.ModuleList(

Ckpt weight 拆分:

def update_state_dict_task(state_dict, input_sequence_length=None):
    state_dict_new = copy.deepcopy(state_dict)
    state_dict_new["sparse_dynamic_vehicle_head.head.sparse_dynamic_head.transformer.decoder.norm1_1.weight"] = copy.deepcopy(state_dict["sparse_dynamic_vehicle_head.head.sparse_dynamic_head.transformer.decoder.norm1.weight"])
    state_dict_new["sparse_dynamic_vehicle_head.head.sparse_dynamic_head.transformer.decoder.norm1_1.bias"] = copy.deepcopy(state_dict["sparse_dynamic_vehicle_head.head.sparse_dynamic_head.transformer.decoder.norm1.bias"])
    
    for k, v in state_dict.items():
​
        if "sparse_tl2d_head." in k:
            params = copy.deepcopy(v)
            new_key = k.replace("sparse_tl2d_head", "traffic_light_head")

2.2.5 Matmul 高低位拆分

OE 3.5.0 已经支持 matmul 双 int16 的量化,如需要双 int16 输入则配置两个输入为 int16 量化即可。若使用时存在 CPU 的 bitshift,可以开启 VPU 使其运行到 VPU 中,若不需要 VPU 或双 int16 存在性能问题时则需要用户在前端手动的对矩阵做拆分,用双 int8 模拟 int15,达到高精度的效果。

拆分思路:A(B+C)=AB+A*C,B 为原 scale 能表示的 int8 的最大部分,C 为剩余部分。

self.mod = MAX(T_mat) / 128 # MAX-max absolute value
T_mat_high = torch.trunc(torch.div(T_mat, self.mod)) * self.mod
T_mat_low = torch.fmod(T_mat, self.mod)
T_mat_high = self.quant_high(T_mat_high) # int8, fixed-scale with scale==self.mod
T_mat_low = self.quant_low(T_mat_low) # int8, no need fixed-scale
sample_points_pv = torch.matmul(sample_points, T_mat_high) + torch.matmul(sample_points, T_mat_low)
该方案 matmul 为 int15 计算,工具为 int16。实际使用时可根据性能和精度做平衡。

也可以通过修改 plugin 源码方式自动做拆分,需要将红框后面的减法去掉:

过去两年,行业几乎都盯着同一张榜单追分、比排名、算差距;但从今天起,这套玩法可能要告一段落了。

 

今天,OpenAI 正式宣布 SWE-bench Verified“退役”。几小时前,OpenAI 的开发者账号发推明确表示:SWE-bench Verified 将逐步退出舞台,已不再适合作为前沿编程模型的主要对标基准;官方更建议大家转向 SWE-bench Pro。

 

SWE-bench Verified 曾经几乎就是代码评测的“北极星”。OpenAI、Anthropic、Google,包括不少国内开源权重模型,都在同一张榜单上咬得很紧,领先优势往往只差零点几。

 

但 OpenAI 在最新分析中指出:剩余未解决任务本身存在多重问题,已经不值得继续追求、更不值得继续公布 Verified 成绩。其中最严重的一点是数据污染——几乎所有前沿模型(包括 OpenAI 自己的模型)如今都表现出“复现 SWE-bench 评估数据与解法”的能力,有时甚至只凭任务 ID 就能做到:

 

另一个原因则更“直白”:测试设计本身就不够可靠。OpenAI 认为,至少有 60% 的未解决问题,从题面描述出发就应该是无法被正确解决的——如果某个模型“解决了它们”,更可能意味着绕过了评测机制(也就是在“刷题/作弊”)。他们举的例子之一,是 SWE-bench 中针对 pylint 问题 #4551 的测试用例。

 

今天,Latent.Space 邀请了 OpenAI 的 Frontier Evals 团队一起解读了这次榜单更迭的原因,并对比了两个新旧不同测评榜的差异。

 

SWE-bench Verified 题目规模偏小、任务周期过短,90% 的问题对资深工程师来说一小时内就能完成。而 SWE-bench Pro(SuperBench Pro)的题目更大、更难、任务时间被明确拉长到“数小时甚至更久”,覆盖的仓库、语言和问题类型也明显更丰富;更重要的是,目前它还没有被刷爆,污染迹象远低于 Verified,至少在现阶段仍然能区分真实能力差异。

 

并且 Pro 也不是终点。任何公开榜单,最终都会被追平、被记住、被“学会”,然后再次失效。OpenAI 认为,关键不在于“换哪个榜”,而在于下一代代码评测到底该测什么——他们更希望看到真实世界使用层面的指标:AI 在现实中到底被用了多少、在多大程度上替代了人类工作、又在多大程度上是在增强人类、加速人类。

 

这个事件的意义,正如一位网友所说:“排行榜的噱头已经过时了!如今的优势在于溯源性、对抗性强的评估以及在生产环境中值得信赖的 Agent”。

 

这期嘉宾是 OpenAI 的 Olivia Watkins(Frontier Evals 团队)和 Mia Glaese(OpenAI 研究副总裁)。我们整理了这期播客的核心内容,供你快速了解这场“退役 + 换标”背后的关键逻辑。

 

SWE-bench Verified 的终结(2024–2026)

 

主持人:你们其实亲眼见证了代码评测基准这些年来的演变。我记得大概是在 2024 年中后期,你们第一次发布了关于 Verified 的工作。从那之后事情变化很大。今天你们发布的这篇博客,核心论点是什么?你们想对外传达的主要信息是什么?

 

Olivia:我们的核心观点是:SWE Bench Verified 一直是这个领域用来衡量代码能力进展的“北极星”级基准之一。但最近我们发现,这个基准上的进展基本停滞了。

 

我们意识到,这是因为这个评测已经饱和了,同时也高度被污染了。所以在现阶段,它已经不能很好地衡量代码能力的真实提升了。

 

我们认为,整个领域应该逐步从它转向其他基准,比如 SuperBench Pro。

 

主持人:太有意思了。我经常开玩笑说,好像所有实验室都有个群聊,大家轮流把分数往上挪 0.1%,然后就开始说:“行吧,你现在是最强的代码模型了。”但到现在这个阶段,这种“领先”其实已经没什么说服力了。

 

Olivia:是的,确实如此。

 

主持人:那我们不妨先回到最初。你们当初为 CS Verified 做的原始工作,其实投入非常巨大,但我觉得外界至今都没有真正理解这一点。你们当时到底做了什么?以及后来你们发现了哪些问题?

 

Olivia:SWE Bench Verified 本质上是对一个学术基准的“清洗”和重构。原始基准来自普林斯顿的一个研究团队,叫 SWE Bench。它的基本设定是:给一个 agent 一个真实世界的代码库,以及一个来自 GitHub issue 的任务,让它去解决问题,然后通过是否通过测试来评分。

 

在当时,这个基准迅速流行起来,因为整个领域几乎没有真正贴近现实世界的软件工程评测。

但当 OpenAI 把这个基准纳入我们 preparedness framework 中的评测体系后,我们开始发现:很多 agent 的失败,并不是因为模型“太笨”,而是因为问题本身的设置就有问题。

 

于是 OpenAI 启动了一次规模非常大的人工数据项目,雇佣了将近一百名真实世界的软件工程师,逐题审查这些任务:任务是否描述清晰?测试是否公平?最终我们构建了一个经过严格筛选的、约 500 个任务组成的高质量子集。

 

Mia:真的很难夸大这个过程的投入规模。很多经验丰富的软件工程师,对同一道题进行了多轮、逐条的审查。基本上是三位不同的专家独立做出判断。

 

主持人:你们完全可以不这么做的,这相当于把成本直接乘了三倍。

 

Mia:但我们必须这么做。因为这类任务真的非常复杂。你不仅要看问题描述和补丁,还要把它放到整个代码库上下文中去理解,无论是人类还是模型,都是在这个上下文中完成任务的。所以三轮审查是必要的。甚至事后看,也许我们还应该做更多,但即便如此,那已经是非常巨大的投入了。

 

主持人:我注意到你们后来几乎开启了一个“Verified 风潮”,我前阵子还看到 Quinn 做了 HLE Verified。现在什么都要 verified 了,这本身是好事。回到重点。这 500 道题,大致结构是:问题描述、diff、golden tests,再加上一些回归测试。由于评测是完全公开的,污染几乎是不可避免的。你们确实放了一些 canary(金丝雀),但问题毕竟来自开源仓库。

 

Mia:是的。这和我们通常发布评测不太一样。一般我们会加入 canary strings,来检测是否被训练数据“记住”。但当你使用的是开源 GitHub 仓库的数据时,是不可能插入 canary 的。

 

而且很多题目来自非常流行的项目,比如 Django,你在 GitHub 各处都会看到这些代码片段反复出现。

 

主持人:你之前在录制前跟我说,你们甚至在 G5.2 的 chain-of-thought 里也发现了类似情况。

 

Olivia:对。有一个例子是,任务要求 agent 实现一个功能,但问题描述中并没有提到某个参数,而测试却会检查这个参数是否存在。但在 GPT-5.2 的推理过程中,我们看到模型直接推理说:“我记得在这个仓库的后续版本中实现过这个参数,我或许应该加上。”

 

这类测试,如果没有这种“污染知识”,几乎是不可能通过的。

 

Mia:这其实触发了一次更大规模的调查,不只是针对自家模型,也包括市面上的其他前沿模型,去理解整个行业的污染程度。

 

主持人:那你们还发现了什么?

 

Olivia:这部分主要是团队里其他同事完成的。我们做了一项分析:这些测试本身是否公平?方法是先挑出那些模型始终无法稳定解决的问题,然后再让大量人类工程师做一次深度审查。

 

主持人:他们是直接分析问题,还是看了模型的输出再判断?

 

Olivia&Mia:不完全一样。这不是原始 Verified 的那套流程,而是一次更深入的调查:这些“谁都解不了”的问题,是因为模型不够聪明,还是因为问题本身就有根本性缺陷?

 

结果非常明确。在被深入调查的问题中,超过一半都存在问题。最常见的情况是:测试过于狭窄。测试期待某个具体实现细节,但问题描述里根本没有要求这一点。比如,有的任务要求你实现一个功能,但测试要求你必须用某个特定的参数名或函数名。如果你用了另一个完全合理的命名方式,测试就失败了。

 

还有一类问题是:测试检查了一些问题描述里从未提及的“额外功能”。这意味着,通过测试当然说明你做得很好,但没通过测试,并不代表你的实现不好。只是评测只接受了极其狭窄的一小部分解空间,而忽略了大量同样正确、同样高质量的实现。

 

转向 SWE Bench Pro

 

主持人:某种程度上,这像是你们在 2025、2026 年回到过去,修正自己当年的工作。

 

Olivia&Mia:确实如此。但说实话,在抽象层面发现问题,比起对着一个非常聪明的 agent 的“最佳努力解”来审视,要难得多。

 

而且我想强调的是:在当年发布时,SWE Bench Verified 是一个非常强的基准。它确实教会了我们,也教会了整个行业很多东西。

 

但这几乎是所有成功基准都会经历的生命周期:一开始,模型只能做到 20% 甚至更低的正确率,大家能清楚地看到进步空间;等到性能接近天花板后,0.1% 的提升就变得毫无意义。

 

现在的问题是:在当前这个阶段,这个基准测量的已经不再是我们真正关心的东西——也就是 agent 的代码能力,而更像是在测量模型是否能“猜中”某个特定函数该叫什么名字。

 

主持人:这确实不是我们现在想测的东西。如果让我你们估算一下,现在大多数前沿模型在 Verified 上是不是都已经到了 80% 多?这个基准的“天花板”大概在哪?

 

Olivia&Mia:这个真的很难说。比如在 GPT-5.2 发布之后,我们回头去看,发现它(模型)解出了大概31 个属于那种“如果没有污染,应该非常难解出来”的题目。所以我觉得很有可能:如果完全没有污染的话,那个数字(天花板)其实我们可能早就已经达到了

 

主持人:那我们之后就不再继续汇报 SWE Bench Verified 了,对吧?接下来 SuperBench Pro 会成为新的主要基准,这是 Scale 那边发起的项目。你们怎么对比分析?SuperBench Pro 吸引你们的点是什么?

 

Olivia:第一点很直接:它更难。SWE Bench Verified 里大概90% 的题,估计一个资深软件工程师不到一小时就能完成。它们通常都很清晰、很自包含、规格也写得很完整。

 

但 SuperBench Pro 的题目整体更大、更难,而且评测还有更大的提升空间,因为它还没饱和。

 

主持人:它还有一些按耗时分的类别,比如1 到 4 小时、以及4 小时以上这一类。

 

Olivia&Mia:是的。另外它也更多样:仓库更多、语言更多、题型也更丰富,定性上就能感觉到问题类型更不一样——这些都很棒。

 

从“污染”角度,我们也认为它更好。我们之前衡量 SWE Bench Verified 的污染,用的是一个小工具:我们做了一个“污染审计(contamination auditor)agent”。这个 agent 会拿到任务描述、patch、任务 ID,然后让它去“审问”目标模型——用一组开放式问题,尽量诱导出模型可能藏着的污染线索。

 

在 SWE Bench Verified 上,我们在很多模型里都看到了污染迹象:包括 OpenAI 自家的模型,也包括像 Claude 4.5、Gemini Flash 等。

 

我们看到的现象包括:模型会复述(regurgitate)标准答案,甚至有时会吐出任务 ID之类的东西——这至少说明它对相关仓库(repositories)有明显的熟悉度。

 

比如它直接给出任务 ID,那种就很离谱。

 

但在 Pro(SuperBench Pro)上,我们目前没看到这种情况。污染审计 agent 只找到了一点非常轻微的迹象:可能有少数模型对一两个源仓库“略微熟悉”,但这和 SWE Bench Verified 的情况完全不是一个量级。所以从污染角度看,确实更好。

 

不过我们也应该预期:再往后,总有一天它也会变得不再合适。作为一个领域,我们必须持续向前走,去找更难、也更具代表性的问题,作为我们能力的锚点。

 

好的代码评测应该衡量什么

 

主持人:太好了。那我们就顺着这个聊。我觉得很多人在用 5.1、5.2、5.3 的时候能明显感觉到“质变”,但这些基准并不总能反映出来——因为它们多数还是一堆分数。 如果是你们理想中的代码基准(或者 agent 编程基准,不管叫什么),你们真正想 benchmark 的能力是什么?

 

Olivia:我觉得其中一个方向是:开放式的设计决策。也就是问题可能有点“没写死”,看模型能不能做出合理的设计选择。

 

主持人:那这种评测怎么写 prompt 才算合理?比如“写一个五个九可用的 B2B SaaS,别犯错”——这当然是个梗。但真正可用的开放式题目会是什么样?

 

Olivia:当然。举个例子:你让它想办法把代码库某一部分提速。但提速的路径可能不止一种。

 

主持人:是,不过性能也有专门的基准吧?你们是不是有 efficiency?还是那是 Harris 团队做的?

 

Mia:我觉得人们在和软件工程 agent 协作时,会在意非常非常多的东西。SWE Bench Verified 显然衡量了一些重要能力——比如给你一个 GitHub issue 的描述,你能不能产出一个 patch,把问题解决到令人满意的程度。

 

它确实测到了模型的一个真实能力,只是由于基准本身的各种问题,当我们已经到 80% 的时候,我们不太信任再往上那一点点提升是否真代表能力提升。

 

但现在作为一个领域,我们正在超越“我的 coding agent 能不能帮我解决一个小的 GitHub issue”这种层级。我们开始关心的是更长期的任务:不是 15 分钟搞定,而是可能要花一小时,有时甚至是几天,以及更久。

 

再进一步,除了“它能解决什么任务”,还有一些更难量化的东西:比如它有没有设计品味(design taste)?它解决问题的方式是不是符合我团队一贯的风格?再比如:代码写得“好不好看”?是否清晰、干净?未来是否可维护

 

这些也许更“不那么可触摸”、更难评测,但对真正和 coding agent 一起工作的开发者来说,意义非常大。

 

主持人:对。这些品质显然已经不是“低垂的果子”了——我们几乎不知道怎么评。我觉得这里有两条路:一条是非常重人力、重金钱:雇一堆承包商来人工标注;另一条是用 LLM 做 proxy,然后想办法把模型对齐到一个“足够可靠的代理评审”上。你们会选哪条?还是两条都要?

 

Olivia:GDP Eval 是一个评测,由人类数据团队和 Frontier Evals 团队合作完成,目标是衡量 agent 能否完成各种真实世界的白领工作。这个评测的评分非常难,因为需要大量领域知识:在不同情境下,你到底要“看”什么,什么才算好。

 

主持人:对。覆盖了大概 15、16 种白领职业——这些职业占 GDP 的很大比例,属于高层次专业工作;同时里面还有很多更细粒度的子任务。我个人非常喜欢这个评测——这几乎就是“AGI 的评测”了。

 

Olivia:也正因为它很难、需要很多领域知识,人类数据团队雇了很多来自这些职业的人,深度参与任务设计、标准答案(gold solutions)的制作、rubric(评分规则)的制定等等,才能把它做出来。

 

主持人:所以基本上,如果把 GDP Eval 这种“通才型”的方法,用同样的路径搬到代码领域,就能得到一条大致的路线图。

 

Mia:我觉得这是个很有意思的方案。你指出了一个关键问题:到底“现实感”应该多强?我们希望 coding agents 写出来的代码,是我们认为“好”的代码。让人类来评审,确实是确保这一点的好方法。但它也会更慢、更复杂。

 

这也是为什么 SWE Bench Verified 当年会那么流行,以及为什么类似基准会这么流行:它很简单——甚至可以更简单。只要验证“测试全过”,基本就是一键跑出来的:对还是不对,然后你就能汇总统计,快速对比。

 

但它不会告诉你:它是不是把问题“解决得漂亮”?代码是不是很丑?如果你是那个开源项目的 maintainer,你会不会愿意 merge 这个 PR?它回答不了这些。

 

尽管如此,“易于跨行业比较”和“能快速运行、无需人工参与”这两点,仍然非常有价值。

 

从打分到计价:能否把能力换算成成本?

 

主持人:太棒了。你们团队也做过其他类型的 eval,比如我记得有 RL paper bench,还有一些更像递归式自我改进(recursive self-improvement)的评测。这些东西应该在主流的 coding eval 里占多大比重?它们和“普通代码评测”有没有可能融合?

 

Olivia:抱歉,你的问题是:我们是否也应该为“自我改进能力”构建评测?还是你在问,现在的代码评测有没有覆盖到这一点?

 

主持人:我想表达的是:那些可能是我们手上最先进的一类 eval,但它们并没有进入“常规路径”。就好像一边是“正常 coding 的 eval”,另一边是“机器学习研究的 eval”,完全是两套东西,我猜你明白我的意思。这可能主要是出于 safety 的考虑,但从实用角度来说,大家也很想知道模型是不是特别擅长做“AI 代码”(比如研究代码)这件事。

 

Olivia:对。我猜很多基准到现在还没太聚焦“AI 代码”,主要原因是数据集很难收集。最先进的 AI 代码库很多都是私有的。如果我们为那类东西做 eval,很可能也没法公开发布。这样一来,外部领域就很难做同类对比,也很难衡量“这是不是一个现实的研究编码工作流”。

 

但我确实认为,公开地衡量这些技能,对整个领域是有益的,只是更难把它做得足够真实。

 

主持人: 还有一个趋势:很多人尝试不再用 0 到 100 的百分制,而是用 Dollars 来重新计价。你有 freelancer 之类的东西,也有人做 vending bench 之类——你们对这些有什么看法?它们有用吗?还是你们仍然更想要传统的学术基准?

 

Mia:我觉得从某种意义上,这些是在用不同的尺度衡量同一件事。

 

如果你说“它能产生多少价值(多少钱)”,这和说“这个问题让人类来做需要两小时”其实差不多。通常它们是高度相关的:一个人类解决这个问题要花多少时间,往往就决定了我们会给解决方案赋予多大的价值。

 

所以我认为一个很重要的维度是:我们能够把 agent 托付给多复杂、运行时间多长的任务?这些任务到底能有多“长”、多“重”、多“复杂”?这件事本身非常关键。

 

所以我觉得这是一个很重要的点。但无论是用金钱价值时间,还是复杂度来衡量,本质上它们都是在试图捕捉同一件事。

 

主持人:是的。它们本质上都是某种“代理指标(proxy)”,用来衡量我们想要测量的、不断增长的能力。我觉得这是件好事。我觉得在这个领域里,另一个比较重要的参与者是 METR(原文音近 meter),他们做了所谓的 long horizon / long autonomy 测试。顺便说一句,恭喜你们,已经把那条曲线彻底打穿了。你们怎么看这类方法?显然你们在这些评测上表现非常好,这看起来当然很好,但我不知道这种思路是不是你们未来在构建 eval 时也会考虑吸收的方向。我指的是“长期自治(long autonomy)”那类评测。

 

Mia:是的,我们当然知道那套评测,而且我们也和 METR 在这些评测上有合作,所以我们是非常认可它们的。

 

他们主要是用时间作为度量,而不是用金钱。

 

我想这正好呼应你刚才的问题。我认为“复杂度”——不管我们用什么方式去量化——对于理解我们正在走向什么样的能力水平、什么样的市场阶段,都是非常重要的。

 

主持人:明白了。复杂度是一个更抽象的概念,然后它可以投射到时间、story points,或者金钱这些更具体的指标上。

 

评测的终点:AI 替代了多少人类工作

 

主持人:最后一个问题,关于整体的 Preparedness Framework。我注意到现在很多人都会提到这个框架,但我觉得对大多数人来说,它并没有被很好地解释清楚。你们其实有一个做得很好的公开网站,上面讲的是“测试、告知、教育”之类的内容。我感觉你们在这方面投入了很多工作。你愿不愿意简单讲讲 Preparedness Framework 是如何应用的?

 

Olivia:Preparedness Framework 是一个公开的框架,用来说明我们如何追踪前沿风险(frontier risk)。这些风险通常来自一些双用途能力:它们既可以被用于好的事情,也可能被用于坏的事情。我们希望至少能持续监测潜在的负面使用,确保我们作为一家公司、以及整个社会,都能为可能出现的风险做好准备。

 

目前我们主要追踪三大类能力风险:第一类是生物安全风险(biorisk);第二类是网络安全(cybersecurity);第三类是研究自动化与模型自治(research automation & model autonomy)。这第三类正是和代码评测联系最紧密的地方。代码并不等同于研究自动化,但它是其中一个非常关键的组成部分

 

所以我们最初创建 SWE Bench Verified,就是作为“模型自治”这一工作流中的一部分评测手段。而现在,我们认为必须继续向前,去评估模型是否真的开始自动化完整的研究工作流

 

主持人:非常棒。还有什么你想补充的吗?比如大家应该如何理解 preparedness,以及 eval、人类数据、对齐团队是如何协同工作的?

 

Mia:我觉得我最想说的一点是:我们真的非常珍惜整个社区的参与。我们投入了大量精力去构建这些评测,这也是为什么我们会在这个框架下发布 Verified、分享 GDP Eval 等成果。同时,我们也非常鼓励整个领域去共同构建、分享、复用评测

 

像 SuperBench Pro 这样,如果它是一个更好的评测,那我们就应该用它。

 

我非常希望大家能探索更多方式,去创建并共享 eval,让我们以及整个领域,都能更好地衡量不同能力维度上的进展——包括代码能力,因为理解我们现在到底处在什么位置非常重要。

 

主持人:这里我想直接请你发出一个“号召”:如果大家要为你们做 eval、或者给这个领域贡献 eval,你们最想看到什么?

 

Olivia:我觉得有几类东西会非常有价值。

 

第一,是真正非常非常难的任务——那种需要顶尖工程师花几个月、或者一个团队花几周才能完成的事情。如果这些任务的评分是可靠的,而且有经过领域内多方验证的 rubric(评分标准),那会非常有价值。

 

第二,是端到端产品构建类的基准。随着越来越多人在用 agent “直接出产品”,这类 benchmark 会变得越来越重要。

 

第三点,也许不完全算是 eval,但我认为和我们的整体使命高度相关:我希望看到更多真实世界使用情况的指标——AI 在现实中到底被用了多少?在多大程度上替代了人类工作? 在多大程度上是在增强人类、加速人类?这些真实世界指标,本身非常重要。

 

主持人:是的,“替代”这个词在宣传层面总是很敏感(笑)。不过现实就是:我们会创造新工作来管理旧工作,事情一向如此。就你个人而言,接下来在 Frontier Evals 上最值得期待的是什么?你们每次都交付非常高质量的工作。

 

Olivia:我不太方便具体说接下来会发布什么,但从大的方向上来说,肯定会更多关注真实世界影响——真实使用、真实吞吐、真实效果这类东西。

 

主持人:太棒了。我也非常期待你们在“真实世界影响”这条线上继续推进。

 

参考链接:

https://www.youtube.com/watch?v=0HaUD_olwQU

https://x.com/latentspacepod/status/2026027529039990985

在过去的五个月里,我们团队进行了一项挑战:开发并发布一款完全没有人工编写代码的内部测试产品。

目前,该产品已经拥有内部日活用户和外部 Alpha 测试人员。它在真实的开发环境中运行、部署、报错并接受修复。其独特之处在于,从应用逻辑到测试脚本,再到 CI 配置、文档、可观测性及内部工具,每一行代码都出自 Codex 之手。据我们估算,这种开发模式的效率极高,耗时仅为手动开发代码的 10%。

人类掌舵,Agent 执行。

我们特意设定了这个限制,就是想看看工程效能能否实现量级上的突破。当时我们需要在短短几周内交付上百万行代码,这迫使我们必须重新思考:如果工程师不再把“写代码”当成主业,而是转去设计环境、定义意图并构建反馈循环,好让 Codex Agent 产出可靠的成果,那么研发模式到底会发生什么变化?

在这篇文章中,我们将分享通过 Agent 团队构建全新产品的心得,包括哪些尝试失败了,哪些产生了复利效应,以及如何最大化利用我们最宝贵的资源:人类的时间与注意力。

从空仓库起步

2025 年 8 月底,我们向这个空仓库提交了第一次 Commit。

初始脚手架由 Codex CLI 调用 GPT-5 生成,并辅以少量现有模板作为引导,涵盖了仓库结构、CI 配置、格式化规则、包管理器设置以及应用框架。甚至连指导 Agent 如何在仓库中工作的初始 AGENTS.md 文件,也是由 Codex 亲笔完成。

这里没有任何预存的人工代码来作为系统的“锚点”。从一开始,整个仓库的形态就是由 Agent 塑造的。

五个月后,该仓库已拥有约 100 万行代码,涵盖应用逻辑、基础设施、工具链、文档和内部开发组件。在此期间,一支仅有 3 名工程师的小团队驱动 Codex 开启并合并了约 1500 个 PR。这意味着平均每位工程师每天产出 3.5 个 PR。令人惊讶的是,随着团队扩大到 7 人,人均产出率反而进一步提升。

更重要的是,这并非为了刷量而产出:该产品已被数百名内部用户使用,其中包括每天重度使用的核心用户。在整个开发过程中,人类从未直接贡献过任何一行代码。这成了团队的核心哲学:拒绝人工编写代码。

重新定义工程师的角色

由于不再亲自动手写代码,工程师的工作重心转向了系统设计、脚手架搭建和杠杆效能。

早期的进展比预期要慢,这并非因为 Codex 能力不足,而是因为环境的“规范度”不够。Agent 缺乏实现高层目标所需的工具、抽象和内部结构。于是,工程团队的首要任务变成了:赋能 Agent 开展有效工作。

在实践中,这意味着采用深度优先的工作方式:将宏大目标拆解为微小的构建块(设计、代码、评审、测试等)。驱动 Agent 构建这些块。利用这些已有的块去解锁更复杂的任务。当任务失败时,修复方案几乎从不是“再试一次”。因为必须通过 Codex 来推进工作,人类工程师会介入并思考:“缺失了什么能力?我们如何让这种能力对 Agent 而言既清晰可见又强制执行?”

人类与系统的交互几乎完全通过 提示词 完成:工程师描述一项任务,运行 Agent,并授权其开启一个 Pull Request。为了推进 PR 最终合入,我们会指示 Codex 在本地审查自己的代码改动,并请求其他特定的 Agent(无论是在本地还是云端)进行交叉评审。Codex 会根据人类或 Agent 给出的反馈进行响应,并在循环中不断迭代,直到所有 Agent 评审员都感到满意——这实际上形成了一个所谓的 “拉尔夫·维格姆循环”(Ralph Wiggum Loop)【见译注】。Codex 直接调用我们的标准开发工具(如 GitHub CLI gh、本地脚本以及集成在仓库中的技能),自主获取上下文,无需人类手动在命令行中复制粘贴。

译注:Ralph Wiggum Loop:这是一个来自《辛普森一家》的梗(那个坐在教室后面自言自语的小男孩),在软件工程语境下,通常指代一种“自给自足、闭环且带有某种幽默色彩的自推导循环”。

虽然人类可以审查 PR,但这并非强制要求。随着时间的推移,我们已将几乎所有的评审工作都交给了 “Agent 对 Agent” 的协作模式。

增加应用的“可读性”

随着代码产出率的提升,我们的瓶颈变成了人类的 QA 能力。由于人类的时间和注意力始终是唯一的稀缺资源,我们致力于通过让应用 UI、日志和指标对 Codex 直接可见且可理解,从而为 Agent 增加更多能力。

例如,我们使应用能够针对每个 Git 工作树(worktree)独立启动,这样 Codex 就可以为每一次代码变更运行并驱动一个实例。我们还将 Chrome DevTools Protocol 接入 Agent 运行时,并创建了处理 DOM 快照、截图和导航的技能。这使得 Codex 能够直接复现 Bug、验证修复结果并推导 UI 行为。

我们对可观测性工具也做了同样的处理。日志、指标和链路追踪通过一个本地的可观测性栈暴露给 Codex,这个栈对于任何给定的工作树来说都是临时的。Codex 运行在该应用的一个完全隔离的版本上,包括其日志和指标,这些内容会在任务完成后被销毁。Agent 可以使用 LogQL 查询日志,使用 PromQL 查询指标。有了这些上下文,诸如“确保服务启动在 800ms 内完成”或“这四个关键用户旅程中没有任何 Trace Span 超过 2 秒”之类的提示词,就变得具有可操作性了。

我们经常看到单次 Codex 运行持续处理一个任务超过 6 小时(通常是在人类睡觉的时候)。

以仓库知识作为“事实来源”

上下文管理是让 Agent 处理复杂任务的最大挑战之一。我们学到的核心教训是:给 Codex 一张地图,而不是一本千页的使用手册。

我们曾尝试过“单一 AGENTS.md 大文件”方案,但很快就失败了:1. 上下文是稀缺资源:巨大的指令文件会挤占任务代码和相关文档的空间。这会导致 Agent 要么遗漏关键约束,要么开始针对错误的目标进行优化。2. 引导过度等于没有引导:当所有内容都被标榜为“重要”时,就失去了重点。Agent 最终只会进行局部的模式匹配,而无法有目的地理解全局。3. 文档极易腐化:单体式的手册很快就会变成陈旧规则的坟场。Agent 无法判断哪些规则依然有效,人类也懒得维护,结果这份文件反而成了误导 Agent 的诱饵。4. 难以验证:这种单一的大块内容无法进行机械化检查(如覆盖率、时效性、归属权或交叉链接),架构偏离也就成了必然。

因此,我们将 AGENTS.md 视为目录而非百科全书。

代码库的知识库存在于一个结构化的 docs/ 目录中,并被视为唯一事实来源。一份简短的 AGENTS.md(约 100 行)被注入到上下文中,它主要充当地图的角色,包含指向分布在各处的更深层“事实来源”的指针。

AGENTS.mdARCHITECTURE.mddocs/├── design-docs/│   ├── index.md│   ├── core-beliefs.md│   └── ...├── exec-plans/│   ├── active/│   ├── completed/│   └── tech-debt-tracker.md├── generated/│   └── db-schema.md├── product-specs/│   ├── index.md│   ├── new-user-onboarding.md│   └── ...├── references/│   ├── design-system-reference-llms.txt│   ├── nixpacks-llms.txt│   ├── uv-llms.txt│   └── ...├── DESIGN.md├── FRONTEND.md├── PLANS.md├── PRODUCT_SENSE.md├── QUALITY_SCORE.md├── RELIABILITY.md└── SECURITY.md
复制代码

设计文档被编目并索引,其中包含验证状态以及一套定义了“Agent 优先”运营原则的核心信条。架构文档提供了一个关于领域划分和包分层的顶级地图。一份质量文档则会对每个产品领域和架构层级进行评分,并长期跟踪其中的差距。

计划(Plans)被视为一等公民。临时性的轻量计划用于微小的变更,而复杂的工作则会被记录在执行计划中,连同进度和决策日志一起提交到仓库。活跃计划、已完成计划以及已知的技术债都会进行版本化管理并放在一起,使 Agent 能够无需依赖外部上下文即可开展工作。

这实现了渐进式披露:Agent 从一个微小、稳定的入口点开始,并被告知下一步该去哪里寻找信息,而不是预先就被海量信息所淹没。

我们通过机械化手段强制执行这一点。专门的 Linter 和 CI 任务会验证知识库是否处于最新状态、是否正确进行了交叉引用以及结构是否合规。一个循环运行的“文档园丁”Agent 会扫描那些无法反映真实代码行为的陈旧或过时文档,并开启修复类 PR。

以“Agent 可读性”为目标

随着代码库的演进,Codex 的设计决策框架也随之进化。

由于整个仓库完全由 Agent 生成,它首先针对 Codex 的可读性 进行了优化。正如开发团队致力于为新入职工程师提高代码的可导航性一样,我们人类工程师的目标是让 Agent 能够直接从仓库本身推导并理解完整的业务领域知识。

从 Agent 的视角来看,任何在运行时无法通过上下文获取的信息,实际上都不存在。存储在 Google Docs、聊天记录或存在于人们大脑中的知识,系统是无法访问的。只有仓库本地的、版本化的工件(如代码、Markdown、Schema、可执行计划)才是它可见的全部世界。

我们意识到,随着时间的推移,我们需要将越来越多的上下文推入仓库。比如那次让团队在架构模式上达成一致的 Slack 讨论,如果它对 Agent 来说是不可检索的,那么它就是“不可读”的——就像对于三个月后入职的新员工来说,这段背景是缺失的一样。

赋予 Codex 更多上下文,意味着需要组织并暴露正确的信息,以便 Agent 进行推理,而不是用大量的临时指令让它不堪重负。就像你会向新队友介绍产品原则、工程规范和团队文化(甚至包括表情符号的使用偏好)一样,向 Agent 提供这些信息会带来更加一致的产出。

这种思路让许多权衡变得清晰。我们更青睐那些可以被完全内化并在仓库内进行推理的依赖项和抽象。那些通常被称为“乏味”的技术,往往因为其组合性、API 稳定性和在训练集中的高覆盖率,更容易被 Agent 建模。在某些情况下,让 Agent 重新实现一部分功能,比绕过公共库中不透明的上层行为成本更低。例如,我们没有引入通用的 p-limit 风格的包,而是实现了自己的并发映射助手:它与我们的 OpenTelemetry 监控紧密集成,拥有 100% 的测试覆盖率,并且完全符合我们运行时的预期。

将系统的更多部分转化为 Agent 可以直接检查、验证和修改的形式,不仅提升了 Codex 的杠杆效能,也同样造福了其他在同一代码库中工作的 Agent(例如 Aardvark)。

强制执行架构与审美

仅靠文档不足以保持一个完全由 Agent 生成的代码库的连贯性。通过强制执行“不变量”而非微观管理实现细节,我们让 Agent 在快速交付的同时,不破坏系统的根基。例如,我们要求 Codex 在系统边界处必须进行数据格式解析,但并不强制规定实现方式(模型似乎偏好 Zod,但我们从未指定过这个特定的库)。

Agent 在边界严格且结构可预测的环境中效率最高。因此,我们围绕一套僵化的架构模型构建了应用。每个业务领域被划分为一组固定的层级,拥有严格验证的依赖方向和有限的允许连接点。这些约束通过自定义 Linter(当然也是 Codex 生成的!)和结构化测试进行机械化强制执行。

下图展示了这一规则:在每个业务领域(如“应用设置”)内,代码只能沿着一组固定的层级“向前”依赖(类型定义 → 配置 → 仓库层 → 服务层 → 运行时 → UI)。跨领域关注点(如认证、连接器、遥测、特性开关)通过单一且明确的接口进入:提供者(Providers)。除此之外的任何依赖都是被禁止的,并由机械化手段强制执行。

这种架构通常是在拥有数百名工程师后才会考虑推行的。但在使用编程 Agent 时,它是前置的必要条件:正是这些约束,才使得系统在高速迭代的同时,不会出现腐化或架构偏离。

在实践中,我们通过自定义 Linter、结构化测试以及一小套“审美不变量”来执行这些规则。例如,我们通过静态检查强制要求:结构化日志记录、架构和类型的命名规范、文件大小限制,以及针对特定平台的可靠性要求。由于 Linter 是自定义的,我们可以编写专门的错误信息,以便将修复指令直接注入到 Agent 的上下文中。

在以人类为中心的工作流中,这些规则可能显得过于死板或受限。但在 Agent 环境下,它们变成了效能倍增器:规则一旦被编码,就会立即应用于所有地方。

与此同时,我们明确区分了哪些地方需要约束,哪些地方不需要。这非常像领导一个大型工程平台组织:中央强制执行边界,地方允许自主。 你需要极度关注边界、正确性和可复现性;而在这些边界之内,你允许团队(或 Agent)在表达解决方案时拥有极大的自由。

最终生成的代码并不总是符合人类的审美偏好,但这没关系。只要产出是正确的、可维护的,并且对未来的 Agent 运行而言是可理解的,它就达到了标准。

人类的审美会持续反馈到系统中。评审评论、重构 PR 以及面向用户的 Bug 都会被转化为文档更新,或直接编码进工具链。当文档不足以约束行为时,我们就将规则晋升为代码。

吞吐量的提升改变了合并哲学

随着 Codex 吞吐量的增加,许多传统的工程规范反而变得适得其反。

仓库运行时的阻塞性合并门槛极低。Pull Request 的生命周期非常短。对于测试偶发失败,通常通过后续运行来解决,而不是无限期地阻塞进度。在一个 Agent 吞吐量远超人类注意力的系统中,纠错是廉价的,而等待是昂贵的。

在低吞吐量的传统环境中,这样做是不负责任的;但在这里,这通常是正确的权衡。

“Agent 生成”的真正含义

当我们说代码库是由 Codex Agent 生成时,我们指的是代码库中的一切。

Agent 产出的内容包括:- 产品代码与测试脚本 - CI 配置与发布工具 - 内部开发者工具 - 文档与设计历史 - 评估框架(Evaluation harnesses)- 评审评论及回复 - 管理仓库本身的脚本 - 生产环境仪表盘的定义文件

人类依然掌控全局,只是工作的抽象层级变了。我们现在的任务是排列优先级、把用户反馈转化为验收标准,并最终对结果进行把关。一旦 Agent 开发受阻,这就是一个明确的信号,提醒我们要去复盘:系统里到底缺了什么?是工具不够,护栏不稳,还是文档有误?找到症结后,我们会把这些反馈注入仓库,但依然坚持让 Codex 自己动手来编写修复方案。

Agent 直接使用我们的标准开发工具。它们获取评审反馈、进行行内回复、推送更新,并且通常会自主压缩(Squash)并合并自己的 PR。

持续提升的自主化水平

随着越来越多的开发环路(测试、验证、评审、反馈处理及故障恢复)被直接编码进系统中,该仓库最近跨越了一个具有里程碑意义的门槛:Codex 已经能够端到端地驱动新特性的开发。

仅需一段提示词,Agent 现在就可以自主完成以下流程:- 验证代码库的当前状态 - 复现报告的 Bug- 录制一段展示故障过程的视频 - 实现修复方案 - 通过操作应用来验证修复结果 - 录制第二段展示修复效果的视频 - 开启 Pull Request- 响应 Agent 及人类的反馈 - 检测并修复构建失败 - 仅在需要人类判断时才上报 - 合并变更

这种行为极度依赖于本仓库特定的结构和工具链。在没有类似投入的情况下,不应假设这种能力可以被直接泛化,至少目前还不行。

熵增与垃圾回收

完全的 Agent 自主权也带来了全新的挑战。Codex 会复制仓库中已有的模式——即便是那些不均衡或非最优的模式。 随着时间的推移,这不可避免地会导致架构偏离。

最初,人类通过手动方式解决这个问题。我们的团队曾固定在每周五(占一周工作时间的 20%)清理“AI 废料”。不出所料,这种模式根本无法扩展。

针对这些问题,我们选择将所谓的“金科玉律”直接写入代码仓库,并建立了一套周期性的清理机制。这些原则是一些带有明确主张的机械化规则,目的是确保代码库在后续的 Agent 运行中始终保持清晰、一致。具体实践包括:第一,我们更倾向于使用共享的工具包,而不是手写辅助函数,这样可以集中管理那些不变量;第二,我们拒绝“全凭运气”的数据探测,必须在边界处进行校验,或者依赖强类型 SDK,防止 Agent 采样猜测的数据形状来编写代码。我们会定期运行一组 Codex 后台任务,专门扫描偏离规则的代码,更新质量评分并开启针对性的重构 PR。由于这些规则非常明确,大部分 PR 在一分钟内就能完成评审并自动合并。

这种机制运行起来就像“垃圾回收”。技术债就像高利贷:连续进行小额偿还,几乎总是优于让其复滚并最终在痛苦的爆发式清理中解决。人类的审美被捕获一次后,便会持续强制执行到每一行代码中。这还让我们能够在日常工作中及时发现并消除不良模式,而不是任由它们在代码库中蔓延数天甚至数周。

我们仍在探索的领域

到目前为止,这套策略在 OpenAI 内部产品的发布和推广中表现良好。通过为真实用户构建真实产品,我们的投入得以为现实需求服务,并引导系统走向长期可维护。

目前我们尚不清楚,在一个完全由 Agent 生成的系统中,其架构连贯性在长达数年的跨度下会如何演进。我们仍在摸索人类判断力在何处能产生最大的杠杆效应,以及如何将这种判断力转化为可沉淀、可产生复利的规则。同时,随着模型能力持续增强,这套系统将如何进化也仍是未知数。

但有一点已经非常明确:构建软件仍然需要严谨的纪律,只不过这种纪律不再体现在代码编写上,而是体现在“脚手架”的搭建上。那些能保持代码库连贯性的工具链、抽象层和反馈循环,正变得愈发重要。

我们现在面临的最艰巨挑战在于如何设计环境、反馈循环和控制系统。唯有如此,才能帮助 Agent 达成我们的目标,即大规模地构建并维护复杂且可靠的软件。

随着 Codex 等 Agent 承担起软件生命周期中越来越多的份额,这些问题将变得至关重要。希望这些早期教训能帮助你思考该在何处投入精力,从而让你能更纯粹地去创造产品。

原文链接:

https://openai.com/index/harness-engineering/

今日好文推荐

收购不成便带头封杀?!Meta 痛下狠手,OpenClaw 彻底失控:被拒后竟“人肉”网暴人类,实锤无人操控

“软件工程师”头衔要没了?Claude Code之父YC访谈:一个月后不再用plan mode,多Agent开始自己组队干活

编码新王登基!Gemini 3.1 Pro 血洗 Claude 与 GPT,12 项基准测试第一!

阿里除夕开源“王炸”千问 3.5-Plus ,性能媲美Gemini 3 Pro、Claude 4.5 Opus,百万 Token 8毛钱

没有 AI 之前,写脚本,老老实实一行一行敲,有 AI 后,直接 CC 梭哈,爽是爽,但也只能爽半自动,一直困扰我的问题是,AI 只能编辑本地的内容,无法直接修改浏览器油猴中的脚本,所以就得来回 CV,繁琐无比,以前都算了,今天忍不了,于是遨游了一些互联网后发现了新大陆,原理其实很简单,分享给大家

  1. 在扩展设置中开启允许访问文件网址
    image
  2. 在油猴脚本中引入本地 js 脚本地址
    image
  3. 直接在本 js 中编写脚本
    image
  4. 展示
    image


不知道我是不是最后知道的force_smile

大家新年好啊,我日常会使用多个 Code Agent ,比如 CC 、copolit 、opencode ,也在本地安装了很多 Skills ,每次使用其中一个 Agent 的时候会担心我的 Skills 到底有没有被加载,所以我偶尔会使用 /skills 查看下当前有哪些 Skills 。

虽然有一个 https://agentskills.io/home 的标准,但各家 app 也有自己的目录,总之管理起来比较恼火(还要考虑到更新的问题)。

于是我就用 Claude Code 写了这么一个 app:SkillDeck

它不仅提供安装能力,还提供了统一的发现、更新、删除等全生命周期管理。

统一仪表盘

三栏布局的 macOS 原生界面:左边是 Agent 列表和筛选,中间是 Skill 列表,右边是详情。支持按名称、描述、作者搜索,还能按 Agent 过滤和排序。

Dashboard Overview

Skills 市场浏览

内置了 skills.sh 的排行榜浏览,支持 All Time 、Trending 、Hot 三种排序方式,还有搜索功能。看到喜欢的 Skill 可以直接一键安装。

Registry Browser

安装与更新

从 GitHub 安装只需要输入仓库地址(支持 owner/repo 格式),SkillDeck 会自动 clone 、扫描可用 Skills 、创建 symlink 。

更新检测也是一键的:会对比本地和远程的 tree hash ,有变更就显示橙色角标,点一下就能拉取最新代码。

Install & Update

Agent 分配

每个 Skill 的详情页有一组 toggle 开关,控制这个 Skill 安装到哪些 Agent 。打开就自动创建 symlink ,关掉就自动删除。

这样也不用每个 Agent 都去安装 skill ,只保留一份。

安装方式:

brew tap crossoverJie/skilldeck && brew install --cask skilldeck

项目开源,MIT 协议,欢迎 star/issue/PR:GitHub | 项目主页

做了一个类似 WordPress 的动态博客 CMS 系统,可以部署在 Vercel 等云平台或者使用 Docker 自部署,和 WordPress 一样,可以在后台实时动态的更改页面内容和布局。

我敢说你一定没见过全站横向滚动的博客。

Demo: https://ravelloh.com

Github: https://github.com/RavelloH/NeutralPress

文档: https://neutralpress.net

(你可以在文档页面查看更详细的功能介绍)

简介

NeutralPress 是一个基于 Next.js 的 CMS 系统,其在生态位上与 WordPress 类似,你可以所见即所得的通过强大的后台管理系统来管理你的站点,所有更改都会实时应用。

WordPress 之所以流行,是因为它易于使用且功能强大。但其技术栈陈旧、性能要求高、功能依靠插件、后台风格过时,且强需求服务器,难以免费部署。我们致力于解决这些问题,通过融合静态站点生成器(如 Hexo )和动态 CMS 系统(如 WordPress )的优点,提供一个低成本、易于使用且功能强大的内容管理平台。

仅当内容变更时,NeutralPress 才会使用动态增量再生( ISR )技术重新生成发生更改的页面,而在内容未变更时,页面与静态页面类似。这既确保内容可实时更新,又能享受静态页面的高性能、SEO 友好和低成本优势。

因此,你可以 0 成本 的免费部署 NeutralPress 到任何支持 Serverless 的云平台,而无需实际管理服务器。或者,如果你愿意,你也可以选择使用 Docker 自托管。

功能

功能上应该是最多的 CMS 博客系统之一,不仅仅只是个文章发布平台。一键部署,你就可以拥有:

  • 行云流水的内容系统,所见即所得、支持 Markdown / MDX 可视化编辑、草稿箱、版本管理,内置 SEO 深度优化。
  • 独具匠心的页面系统,支持拖拽组件、实时预览,也可使用 HTML / Markdown / MDX 新建页面。
  • 井井有条的归档系统,以标签和分类两个维度对文章进行组织,支持自定义。
  • 强大的媒体管理系统,自动压缩、图片优化、防盗链、短链接、照片墙、Exif 信息展示。
  • 多用户权限管理系统,支持多角色、多权限分配,支持访客注册、Github / Google / Microsoft OAuth 登录、Passkey 登录、TOTP 双因素认证、会话管理、敏感操作二次验证。
  • 毫不妥协的安全系统,内置速率限制 WAF 、IP 封禁系统,重要端点自带 PoW 验证码,并使用 Server Action 代替 API 通信以增强安全性。
  • 详细的访问统计系统,内置访客分析、搜索关键词与全站关键词对比、访客来源、设备分析、文章热度分析等,自动发送日报/周报/月报。
  • 无限层级的评论系统,支持嵌套回复、评论审核、评论点赞,内置评论反垃圾系统。
  • 事无巨细的审计系统,记录每一次内容更改,所有操作可追溯、可还原。
  • 洞察秋毫的搜索系统,高性能分词与索引,专为中文内容及编程术语进行了优化。后续将支持 AI 向量搜索。
  • 即时通达的通讯系统,基于 WebSocket ,支持实时私信、在线 / 输入状态显示等。后续将支持端对端加密私聊。
  • 无远弗届的通知系统,整合站内信、Email 、WebPush 推送,支持精细化的通知订阅策略。
  • 兼容并蓄的订阅系统,支持 RSS ,支持邮件通讯录订阅。
  • 别出心裁的作品系统,独立于文章的展示维度,专为项目展示设计的网格布局与详情页、GitHub 仓库卡片同步。
  • 守望相助的友链系统,支持友链自助申请、自动抓取元信息、健康度巡检,自动标记或隐藏失效链接。
  • 海纳百川的存储系统,同时支持本地文件系统、AWS S3 、Cloudflare R2 、Vercel Blob 、OSS ,甚至 Github Pages 。多种对象存储策略可并存,切换自如。
  • 防微杜渐的诊断系统,支持定时健康检查、性能分析,自动优化。即使在 Serverless 环境下,也能正常执行定时任务。

‧‧‧‧‧‧

前台默认主题

Front 1 Front 2 Front 3
Front 4 Front 5 Front 6
Front 7 Front 8 Front 9
Front 10 Front 11 Front 12
Front 13 Front 14 Front 15
Front 16 Front 17 Front 18
Front 19 Front 20 Front 21

后台默认主题

Front 1 Front 2 Front 3
Front 4 Front 5 Front 6
Front 7 Front 8 Front 9
Front 10 Front 11 Front 12
Front 13 Front 14 Front 15
Front 16 Front 17 Front 18
Front 19 Front 20 Front 21

部署

可以参考 https://neutralpress.net/docs/deploy ,支持 Vercel 、源码部署、Docker 部署。Docker 一键部署:

curl -fsSL https://get.neutralpress.net | bash

(服务器需要 1GB 内存才能正常运行)

大家要是有自己想要的新功能,也可以留言一下,后续的版本我给加上

Chris Lattner 是 LLVM 项目的创建者,也是 Clang 编译器的关键推动者之一,长期站在编译器工程、编程语言设计与大型软件系统实践的交汇点上。他对 Claude C Compiler 的判断之所以重要,源于他在过去二十多年里持续参与并推动的那一代编译器抽象——这些抽象已经深度嵌入现代软件工程体系,塑造了今天我们构建与维护大型系统的基本方式。

 

2 月 6 日,Anthropic 发布工程博客:他们让 Opus 4.6 以 agent 团队方式构建一套 C 编译器,“基本放手”两周后,它能在 Linux 内核上工作。2 月 7 日,Lattner 在 X 上转发并评价这一结果“相当惊人”——既反映了 AI/agent 能力的进展,也说明了编译器设计的某些特性。他随即抛出问题:如果由他来写一篇解读,哪些角度最值得写、又不至于重复现有讨论?在大量反馈推动下,他随后深入拆解其工作方式与构建过程,并于 2 月 20 日发表长文总结所见。

 

他在文中给出的判断是:Claude C 编译器之所以重要,不是因为“AI 写出了编译器”这条新闻本身,而是因为它证明了一点——在结构成熟、标准清晰、成败可验证的工程问题里,AI 已经可以把几十年积累下来的工程共识成体系地复刻出来:搭出架构、维护子系统一致性、在测试与失败反馈循环里迭代,直到“跑得过”。

 

这意味着实现、转译、重写、样板化改造这类过去最耗人力的工程活动,正在被直接纳入 AI 的默认工作范围,成本被系统性压低,从而让编程“从根本上发生了改变”。

 

但同一个案例也把短板推到台面上:它更像是在优化“通过测试”,而不是像人类工程师那样主动追求更通用、更稳健的抽象——一旦离开现成测试套件或既定成功标准,泛化能力就会变得脆弱。软件工程的重心因此被迫上移:写代码不再是瓶颈,瓶颈转向架构选择、抽象设计与工程判断——以及在复杂性引入之前,决定什么值得做、什么不该做。

 

以下是 Chris Lattner 的原文翻译:

 

Claude C 编译器的诞生,揭示软件未来形态

 

编译器在计算机科学发展史中占据着特殊地位。作为计科教育的经典课程,构建一款编译器本身就是段意义重大的历练。学生们需要借此直面软件的真实运作方式,研究语言、抽象、硬件、人类意图与机器执行之间的过渡边界。

 

曾经的编译器帮助人类与机器对话,如今的机器则开始帮助人类构建编译器。

 

笔者的职业生涯一直致力于编译器与编程语言方面的研究,Anthropic 打造的 Claude C 编译器(简称 CCC)自然引起了多的关注。我的基本观点非常简单:这代表着真正的进步,也是行业的一大里程碑。当然,AI 的进展并非世界末日,请大家冷静看待。

 

提纲挈领说一句:AI 构建 C 编译器并不能算多么重大的革命性突破,但却揭示了 AI 编程的发展历程及未来的前进方向。

 

以下是我的几条主要观点:

  • AI 不再局限于编写小段代码,而开始参与大规模系统的工程设计。

  • AI 正从局部代码生成转向全局工程参与:Claude C 编译器不仅涵盖函数,,更须维护子系统架构。

  • Claude C 编译器的设计与 LLVM 类似:依托数十年的编译器工程经验训练而成,其编译器架构也深受历史影响。

  • 我们的法律体系往往滞后于技术进步,而 AI 正在挑战法律的边界。也许专有软件正在被时代淘汰。

  • 优秀的软件依赖于高质量判断、沟通与清晰的抽象,AI 进一步强化了这点。

  • AI 编程完成的是实现环节的自动化,因此设计和维护变得更加重要。

  • 手动重写和转译工作正被划入 AI 原生任务的范畴,将更高比例的工程活动囊括于其中。

  • 只要人类投入更多精力在架构、设计和创新上,正确使用 AI 就能产生更好的软件。

  • 随着 AI 系统的结构化知识持续增强,文档缺失开始成为制约开发能力的瓶颈,架构文档越来越多地扮演起基础设施的角色。

 

这一切都给工程团队带来了真实且直接的影响。在文章的最后,我将分享我们 Modular 团队如何将这些洞见转化为具体愿景。

编译器是什么?为什么要将其作为 AI 基准测试的重心?

要理解 Claude C 编译器的深远意义,我们首先需要理解编译器对于智能(无论是人类智能还是人工智能)为何如此重要。

 

编译器处于多个复杂领域的交汇点上:形式化语言设计、大规模软件架构、严苛的性能约束以及毫不妥协的正确性要求。

 

大多数应用程序可以容忍存在 bug,但编译器不行。一个错误转换就足以悄无声息导致程序 bug,进而影响无数用户的生产实践。因此其中每个层次都必须严格保持不变性,同时与其他层次协同工作。

 

从历史上看,这也让编译器成为计算机科学教育中至关重要的必修课。工程师们必须跨越抽象层展开思考:将文本转化为结构,将结构转化为意义,再将意义转化为高度优化的机器行为。

摘自我之前关于 LLVM 编译器设计文章。

 

这个过程实际还反映出更深层次的问题,即把人类意图转化为精确执行的过程。正因如此,编译器成为 AI 系统集成中一个独特而有趣的基准课题。

 

早期 AI 编程工具在编写函数、生成脚本或者填充缺失代码等局部任务上表现出色,这里考查的是模式识别和短期推理的能力。

 

Claude C 编译器展现出的更高层次进步,使其成为真正的里程碑。它展示了 AI 系统如何在整个工程系统中保持一致性,协调多个子系统、维护架构结构,随时间推移不断迭代以保障正确性并在复杂的测试与失败反馈循环下稳定运行。由此开始,AI 正式从代码补全转向整体工程参与。

 

更重要的是,编译器工程师构建的架构往往具有高度可读性与结构化水平。编译器具有分层抽象、统一命名约定、可组合的编译过程以及确定性反馈(具有明确标准的成功或失败判断)。正是这些特性,让接触过大量人类经验与源代码训练的学习机器获得了相对简单的工程参与入口。

 

由此看来,Claude C 编译器验证了过去数十年间的软件工程实践,在由编译器工程师们开发的跟着抽象结构之上实现了机器推理。但在意义非凡背后,这里也暗含一大重要局限性。

深入体察 Claude C 编译器

Claude C 编译器最引人注目的一点,在于 Anthropic 为其发布了完整源代码。与众多其他 AI 演示不同,此次亮相的不只是经过精心打磨的结果或者基准测试分数,而是任何人都能随意查阅的工程成果。包括提交历史、设计文档与未来规划,整个代码库都已对外公开。这意味着我们可以研究这套 AI 系统如何一步步构建编译器,搞清自己感兴趣的一切细节。

 

其中初次主要提交就“一次性”构建了系统的基本架构。Claude C 编译器严格遵循经典编译器结构,各主要子系统也都辅以出色的设计文档,具体包括:

  • 处理预处理、解析和语义分析的前端(所有编译器通用)。

  • 直接受 LLVM 启发的中间表示和优化成果。

  • 负责代码生成的后端,支持 4 种架构(x86-32、x86-64、RISC-V 和 AArch64)。

整个代码库的设计选择始终体现出成熟的编译器实践,符合大学课堂上的讲义,也在 LLVM 和 GCC 等现有编译器中广泛采用。中间表示则包含大量 LLVM 开发者非常熟悉的概念,例如 GetElementPtr 指令、基本块“终止符”和 Mem2Reg。从结果上看,Claude C 编译器对于主流编译器设计有着深刻的理解。

 

子系统编译器架构示例。

面对训练集中的 LLVM 与 GCC 代码,Claude 有效将其中相当一部分转译成了 Rust 以供 Claude C 编译器使用。设计文档同样体现其对这两大系统的深入理解,以及对实现方法的深思熟虑。有人批评 Claude C 编译器借鉴了大量现有技术,但在我看来这相当荒谬——我在构建 Clang 时,也从 GCC 身上汲取了不少灵感!

 

Pushpendre Rastogi 还专门撰写了一篇关于 Claude C 编译器与智能体扩展定律(scaling laws)的博文(https://vizops.ai/blog/agent-scaling-laws/),探讨了迭代式智能体工作流如何逐步扩展以优化实现/测试覆盖率:

代码考古时间线,作者 Pushpendre Rastogi(已获原作者许可)。

 

总之,Claude C 编译器完全不像是实验性的研究编译器,而更多展现出教科书式实现的稳健风格。它类似于优秀本科生团队在项目早期构建的系统,虽然还须数年时间进行完善,但初步成果已经令人瞩目。

Claude C 编译器有哪些不足?

Claude C 编译器当然并非完美无瑕。部分设计选择表明,其优化目标更多是让系统通过测试,而不是像人类开发者那样构建起通用抽象。仅举几例:

  • 代码生成器功能简陋,优化器会重新解析汇编文本、而未使用中间表示法(IR),此外代码生成器的架构设计也很糟糕。

  • 解析器的错误恢复能力和可用性较差,且在某些极端情况下会出问题。

  • Claude C 编译器似乎无法解析系统头文件(系统头文件的处理复杂度要远高于应用代码),因此它会直接将测试所需内容硬编码到代码当中。

 

从 bug 跟踪系统的检测结果来看,Claude C 编译器最后、也是最大的缺陷,似乎是无法很好地泛化到测试套件之外。这个问题颇具启发性,表明当前 AI 系统更擅长组合已知技术并针对可量化的成功标准进行优化,但在生产级系统所需的开放式泛化方面表现不佳。

 

由此引出了另一个更深层次的问题:AI 编程本身到底存在哪些问题?

Claude C 编译器揭示出 AI 编程之道

Claude C 编译器最有趣的启示并不在于 AI 有能力构建编译器,而在于具体构建过程。它并没有发明新的架构或者探索陌生的设计空间,只是复现了数十年来编译器工程积累下的共识:结构正确、易于理解,且完全基于成熟技术。

 

现代大语言模型是极其强大的分布式模仿者。它们能掌握工作中的大量现有模式,并生成与这些集体经验相仿的解决方案。这种现象与 Richard Sutton 提出的“痛苦教训”理论高度契合,认为扩展定律法能够重新发现已经获得广泛成功的结构。

 

打个比方,使用英国文学作品进行训练能让模型生成莎翁风格的散文。这倒不是说英国文学自 17 世纪之后就停止了发展,只是因为莎士比亚的作品在训练分布中密度更高。模型会学习那些被广泛传播和强化的内容。类似的情况也出现在了编译器设计当中。

 

人类知识的各个阶段都会被大规模吸纳和消化,但问题是谁来编写下一阶段的课程?

 

Claude C 编译器表明,AI 系统能够内化某一领域的教科书知识并成功实现大规模连贯应用。AI 现在可以在既定工程实践中可靠运行,里程碑式地消除诸多重复性繁琐工作,帮助工程师释放出更多创造性空间。但这也凸显出 AI 编程领域的一大重要局限:

 

实现已知抽象概念,与发明新的抽象概念截然不同。我认为目前的实现方式并无创新可言。

 

纵观整个历史,编译器的进步并非源自快速整合标准组件,而来自概念上的飞跃。例如新的中间表示、新的优化模型、新的程序结构以及新的硬件交互方式。团队成员以探索性的思维彼此激励鼓舞,协同打造出前所未有的技术成果。

 

当前 AI 编程系统在标准清晰且可验证的情况下,已经拥有良好的产出表现:编译程序、通过测试、提升性能等等。但创新却截然不同——在创造一种全新抽象概念时,什么才算成功尚无定论。对于尚不存在的想法,因为缺少相应测试套件,AI 难以判断哪种设计才算好。

 

因此,AI 编程只能算是自动化进程中的重要一步。它显著降低了实现、转换与改进的成本。随着这些剧本的降低,真正稀缺的决策,即哪些系统应当存在、软件应当如何演进等,开始向上转移。

知识产权法与专有软件护城河

Claude C 编译器还在知识产权领域引发了不少争议。既然结构、模式乃至特定实现都依托于过去几十年间的公开代码,那么学习和照抄之间的边界究竟在哪里?部分观察人士指出,尽管声称是“洁净开发”,但 Claude C 编译器似乎仍会生成与过往实现高度相似的工件,包括标准头文件及实用程序代码。现有法律框架显然无法制约这种并未明确引用源代码,而是通过统计方法对原有代码进行“洗稿”的行为。

 

当然,人类也会通过研究现有系统、内化模式并将想法重新应用于新情境来学习。二者的区别在于规模化和自动化。AI 可以将数十年间的工程知识压缩成一套可以瞬间复制解决方案的生成模型,这无疑让以具体表达方式为切入点的许可协议显得苍白无力。

 

我们正面临着专有软件会被轻易自动重新实现的新时代。AI 降低了复制既有设计的成本,也让竞争优势从原本的代码库转向执行、生态与持续创新。法律与制度规范也将随之转变,正如当初的 Linux 和开源软件逐步打开自己的生存空间。我敢肯定,未来由人类-AI 协作高效产出的生态体系,将取代那些无法跟上时代洪流的传统生态系统。

自动化、创新与软件的未来

如果 AI 编程主要用于自动化实现,那么未来又会变成什么样子?

 

历史已经给出了清晰的脉络:当某种产品的构建成本大幅降低,我们不仅会以更低成本构建相同的东西,还必然开始构建出前所未有的产物。

 

编译器本身就是个很好的例子。早期程序员只能手动编写汇编代码,可一旦编译器变得稳定可靠,开发者能做的就更多了,整个软件行业也应运而生。这是因为高度抽象使得复杂性更加易于管理。代码编写难度越低,带来的结果不是程序员越来越少,而是软件越来越多。我们可以推进更多实验、获得更多专业工具,并让以往不值得自动化的问题也拥有自动解决方案。

 

1957 年,NASA 利用 IBM 704 主机进行航空研究。

 

工程工作的经济性由此得到优化,大规模重写、迁移和样板代码实现等机械性任务可以交给 AI 负责。这种工作量大但创新性较低的任务,天然与 AI 系统的特性高度适应。工程师们的工作重心也从编写代码实现转向指引系统,即明确意图->验证结果->构建架构的新形式。

 

随着实现成本的降低,工程师的角色也开始上移。到那时候,最稀缺的技能会变成选择合适的抽象概念、决定哪些问题更有意义,以及设计出人类-AI 共同参与并推进的系统。软件工程与产品思维之间的边界将日益模糊,限制项目落地的不再是能够构建软件,而是判断应该构建什么及如何管理随之而来的复杂性。当然,AI 也会同时放大软件结构中好的和坏的部分,管理不善的代码也一定会造成理解和维护上的噩梦。

 

综合以上提出的所有趋势,既然编程正从根本上发生改变,那么软件工程师自身又该何去何从?

软件工程师的角色演变

软件开发的每一次重大变革,都会改变程序员的定义。早期工程师直接管理硬件,而后来的工程师则学会了信任编译器并掌握高级语言。每一次转变都减少了人工操作,同时也提高了人们对于工程师能力的期望。AI 编程无疑代表着这一发展进程的未来走向。

 

随着实现过程日益自动化,软件工程的核心技能也从亲手编写代码转向构建系统。工程师们将专注于决定哪些功能应当保留、组件如何整合以及如何随时间推移保证复杂性元素的可理解性。软件的质量将依赖于判断力、沟通效果与抽象清晰度。AI 系统只是在增强这些人类特质,而非将其取代。

 

最优秀的工程师不会与 AI 比谁编码更快,而是学会与 AI 协作,运用技术快速探索想法、广泛迭代并将精力集中在规划和设计上。AI 工具正迅速成为常规软件开发技术栈的组成部分,正如之前的编译器、版本控制乃至持续集成一样。学习如何有效与 AI 合作正迅速成为一项核心技能。现在谁忽视 AI 的存在,就如同二十年前拒绝采用源码控制一样。

 

来源:摘自 Luca Rossi《软件工厂的时代》,CircleCI 2026 年软件交付现状报告。各顶尖开发团队正迅速拉开差距。

 

根据 CIrcleCI 发布的《2026 年软件交付现状报告》,排名前 5%工程团队的产出量几乎同比增长了一倍,而排名后 50%的团队则停滞不前。2025 年生产力最高团队的产出量,已经达到 2024 年领先团队的 10 倍。

 

这就带来了新的问题:开发团队要如何调整才能取得成功?

 

以下是我们 Modular 团队对这种转变的理解。

Modular 如何适应 AI 工具带来的新愿景?

Claude C 编译器等重大成果改变了我对于软件工程的看法,也让我对团队提出了新的要求。充分利用 AI 工具的前提,是有意识地做出改变:几十年来形成的习惯不会自动消失,组织也很少会单纯为了适应更好的新工具就自主转型。

 

同时,务实的态度也很重要。AI 系统确实功能强大,但远非完美。进步来自与 AI 的协作,而非对 AI 的放任。我们不是为了削减人手,而是把人放在更重要的位置上。由此引出了以下三点愿景:

1. 主动采用 AI,同时保持责任感

从软件工程到行政管理、再到市场推广,每位员工都该积极采用 AI 工具来提高生产力与决策效率。世界瞬息万变,我们必须拥抱变革。

 

但这并不是把责任也推卸给工具。例如,构建大规模生产软件的工程师们仍须对软件正确性、设计质量和长期可维护性负责。AI 扩展了我们的能力,但并不能取代判断。AI 生成的成果应该像手工编写的代码一样,经过充分的解读、验证和认可。产品的声誉永远建立在成果,而非提示词之上。

2. 推动人类价值升华至新高度

历史上,大部分工程工作都属于机械重复式劳动:重写代码、调整接口、迁移系统以及在新环境中复现原有模式等。AI 在这些任务上的表现正迅速超越人类。我们不该在机械性工作上与 AI 竞争,反而应当更严谨地阐明意图、通过测试验证结果并据此改进设计。

 

未来,所有工程师都应当承担起与创造力和判断力高度相关的管理责任。随着迁移与实现速度的加快,架构演进将不再受限于人类重写软件的速度,而是受限于我们能否清晰定义系统的下一步发展方向。

3. 关注结构与社区

AI 强化了结构。

 

具备完善文档的系统更易于扩展和演进,而结构不良的系统则比以往任何时候都更容易陷入混乱。如今,文档、清晰接口与明确设计开始成为稳定运转的前提,而非可有可无的额外开销。

随着实现成本接近于零,稀缺资源从编写代码转向了人员协作。因此最重要的是构建起志同道合的社区,让开发者们携手前进,为了共同的目标和生态而彼此配合。

 

对 Modular 团队而言,这意味着专注于打造能帮助其他开发者取得成功的工具和平台:推动现有代码发展、释放现代计算能力,并实现人类-AI 协作的系统。这也是 Modular 普及 AI 计算、扩展世界各地程序员创造力的一贯使命。

写在最后

Claude C 编译器并不代表软件或者编译器工程的终结。恰恰相反,它为软件工程的未来开启了新世界的大门。实现的门槛越低,真正的创新空间也就越大。

 

降低实现门槛并不会降低工程师的重要性;相反,它们提升了远见、判断和品味的重要性。真正重要的议题变成了什么更值得被创造出来。这份决策背后的意义、方向和责任,本质上仍然归属于人类。

 

编写代码从来都不是终极目标,构建有意义、有价值的软件才是。谁愿意拥抱新工具,挑战固有观念并设计出能够帮助人们进一步创造的系统,未来就将属于谁。

 

这正是 Modular 自创立之初就秉持的未来愿景,也是我坚信 AI 新时代必将构建起的全新世界。

 

原文链接:

https://www.modular.com/blog/the-claude-c-compiler-what-it-reveals-about-the-future-of-software