UFCS融合快充迎里程碑:33款芯片过检,快充生态走向统一

最近看到一份快充芯片通过UFCS融合快充认证的名单,33款芯片同时过检,我的第一反应是意外,又觉得是水到渠成的事情。意外的是,融合快充喊了几年,从标准到协议栈再到终端产品,动作一直不算快;水到渠成的是,只要上游芯片开始批量跟进,终端产品的普及只是时间问题。UFCS的全称是Universal Fast Charging Specification,中文通常叫融合快充,核心目标是用一套通用协议,把不同品牌、不同形态的快充设备串起来。

如果你做过消费电子电源、手机配件或者充电类产品,应该对"充电头一大堆、互相不认"的场景不陌生。这个内容真正解决的问题,是快充生态的碎片化。它适合硬件工程师、产品经理、采购和关注充电效率的玩家参考;你可以不关心协议细节,但至少要懂得"33款芯片通过认证"这件事对产品选型和市场格局意味着什么。

1. 快充为什么一度"各自为政",UFCS到底解决什么

1.1 私有协议的产物:快充的"方言时代"

快充这件事,早期并不复杂。USB标准接口往外输出5V/2A,大家都能用,只是充得慢。后来为了做到"更快",厂商开始在同一个Type-C口上做文章,各自定义私有协议。你可以把私有协议理解成一个个方言:接口长得一样,但内部说话方式完全不同。A家的充电器说A家的话,B家设备听不懂,就只能退回普通5V慢慢充。

这种局面不是没有好处。私有协议可以让自家的设备做到更大功率、更细腻的调压策略、更激进的安全策略,也是产品差异化的一部分。但问题同样明显:消费者手里同时有手机、平板、耳机、充电宝,往往需要准备好几个充电头;公共充电桩要兼容不同品牌,只能在协议列表里越堆越复杂;对中小硬件团队来说,想做一个"什么都能快充"的充电器,甚至还要逐个谈私有协议授权。

我做过的项目里,最头疼的不是电源拓扑,反而是兼容性测试桌上一排排不同设备,有的能握手成功,有的干脆识别不到。这个阶段积累的很多问题,并不是硬件不行,而是协议层面没有统一语言。UFCS融合快充想做的,就是结束这种方言割据,提供一套大家都能用的"普通话"。

1.2 UFCS像"普通话":协议层到底统了什么

UFCS沿用Type-C物理接口和CC通道做通信,但在协议消息层定义了一套完整的协商机制。手机、充电器、充电宝、车载充电器,只要都实现了这套协议,就可以互相理解对方的能力,并协商出合适的输出电压和电流。

简单说,握手之后设备会广播"我能接受哪些电压电流组合",电源端会广播"我能提供哪些档位",最终双方挑选一个都不越界的点,再逐步升压到目标值。整个过程类似于两个人确认好"你说普通话,我也说普通话,那我们聊正事"。

更关键的是,UFCS本质上不是要消灭所有私有协议,而是要做一个多方共识的公共基础。它可以和PD、厂商私有协议在同一个端口上共存,由设备或充电器根据当前连接对象,选择最合适的协议去协商。这种"共存优先"的思路,让它在商业落地时阻力小很多:不是让厂商放弃差异化,而是让最基础的快充场景先统一起来。

1.3 认证的价值:33款芯片为什么值得关注

标准写得再好,如果没人执行,也只是一堆文档。UFCS认证存在的意义,就是把"声明支持"变成"实测可互操作"。厂商把芯片送到第三方检测机构,跑协议一致性、互操作、电气性能、保护机制等一系列用例,通过后才能拿到认证。

这次33款快充芯片通过UFCS融合快充认证,我关注的重点不是数字本身,而是它出现在芯片层。芯片是充电器和手机主板的最小公共单元,芯片过了认证,意味着下游产品开发时可以直接在物料选型阶段就规避掉大量兼容性风险。以前我们做一个支持融合快充的充电器,得自己花时间调协议栈、做交叉测试;现在如果直接选一颗过认证的协议芯片,至少在大方向上不会走偏。

2. 33款芯片过检,UFCS认证到底卡在哪里

2.1 芯片级实现难点

很多人以为快充芯片就是一个简单的握手开关,实际做起来完全不是这样。一颗要通过UFCS认证的协议芯片,至少要同时搞定以下几块:

协议引擎要处理完整的握手、能力广播、电压电流请求、档位切换和异常重试。这不只是解析几条消息,还要管理状态机,应对各种提前拔线、设备重启、消息超时的边界情况。功率管理部分不能只输出固定的几个电压,而是需要在合理范围内实现连续或准连续调压,并且保证电压精度和动态响应。安全保护更是高压大电流场景下的底线:过压保护、过流保护、过温保护、短路保护必须快速可靠,不能只靠外部电路补救。

多协议共存也是大难点。一颗芯片既要跟自家私有协议沟通,又要听PD的请求,还要响应UFCS的握手。三套逻辑在同一颗芯片里跑,不能互相抢总线、抢中断、抢定时器,这对固件架构和芯片资源的规划要求不低。

2.2 "支持UFCS"和"通过UFCS认证"是两回事

市面上不少芯片标称"兼容融合快充",但实际行为差异很大。有的只能跟特定某一家的设备握手成功,换一个品牌的手机就退回5V慢充;有的能握手但调压过程不稳定,负载一变化电压就晃;有的在理想环境下正常,但遇到劣质线缆或者左右快速插拔就死机。

认证过检则要严格得多。认证测试会模拟大量正常和异常场景,比如半路断掉通信、多次快速插拔、输出电压切换瞬间拉载、高温环境下连续运行等。只有这些场景都表现稳定,才有资格进入最终通过认证的名单。所以在我看,选型时问一句话就够了:这颗芯片是有UFCS认证报告,还只是宣传页写了UFCS三个字母。两者差的是一个完整的验证闭环。

对比维度宣称支持通过认证
协议消息覆盖常用路径覆盖全状态机与异常路径
互操作验证只拿自家或少数设备测与多品牌参考设备交叉验证
电气边界常规电压电流正常边界电压、极限负载、动态切换
安全保护基本功能存在异常触发条件与恢复机制受检
项目风险需大量自测兜底已具备更高可信度

2.3 认证测试通常关注哪些维度

UFCS认证不是一个单一测试项,而是一组面向真实使用场景的验证矩阵。我在和检测机构打交道时,至少会关注以下几个维度:

协议一致性解决的是"你说话有没有按规矩来",包括消息格式、字段含义、时序关系、状态跳转是否都符合规范。互操作性测试则是把被测对象放到真实环境里,和一批标准参考设备互相通信,看能不能正常协商、正常调压。电气性能测试关注输出电压精度、输出纹波、动态响应,以及从一档切换到另一档时有没有明显跌落或过冲。安全保护测试会故意制造过压、过流、过温、短路等条件,确认芯片能及时响应并进入保护状态。电磁兼容方面则要看整个应用方案在工作时会不会对外界产生过多干扰,同时自身能不能抵抗外部干扰。看上去每项都有标准答案,实际跑起来能一次全过的方案并不多。

常见挂点包括:握手时序偏快或偏慢,导致对端设备晚一步响应;能力广播里写了过高的功率档位,但电源端实际带不动;调压过程中输出电压过冲超过限值;保护恢复后没有正确回到待机状态。这些细节到了实验室里,都会被量化为具体波形和测试数据。

2.4 通过认证芯片对选型的参考意义

对终端产品开发者来说,选择一颗已经过UFCS认证的芯片,相当于把项目里最难啃的协议验证环节往前移了一步。过去我们做一款双口充电器,最担心的就是"为什么这个口能快充、那个口不能快充"之类的互操作问题。现在选用认证芯片,至少可以确认协议层主路径是通的。

但选型时不能只看有没有证书,还要看认证覆盖的功率范围是不是涵盖你的目标产品。比如一颗芯片认证到65W,你非要它去做90W产品,那超出认证范围的部分风险仍然需要自己扛。我建议直接把芯片的认证报告要到手,核对测试样机型号、固件版本、功率档位和认证日期,再决定要不要用它。

3. 从认证芯片到成品:UFCS充电产品的开发落地

3.1 先想清楚产品形态和功率目标

UFCS不是某个特定芯片的专属功能,而是一套协议能力。它可以出现在墙插充电器上,也可以出现在充电宝、车载充电器、排插甚至手机主板上。产品形态不同,开发重心差异很大。充电器要重点解决AC-DC功率转换和协议芯片的联动;充电宝要关注电池侧升降压和端口协议切换;手机端则要处理充电IC与电池保护系统的配合。

开发前先把功率目标定义清楚,这个事不能后面再改。比如目标是65W的单C口充电器,那功率级至少要留足冗余,协议芯片选型也要覆盖65W对应的电压电流组合。如果定义是双C口,那么还得考虑两口同时输出时的功率分配策略,UFCS协议和PD协议在双口模式下怎么共存,比单口复杂得多。

3.2 充电器端:电源架构与协议控制

充电器内部的典型架构是AC-DC功率部分加协议控制部分。AC-DC部分负责把市电转成可调的直流电压,常见拓扑有反激、准谐振反激、LLC等;协议控制部分负责与设备通信,告诉设备"我这里能提供哪些电压电流",并根据设备请求去调节电源输出。

在做系统设计时,协议芯片的请求不能直接覆盖电源的物理能力。电源能输出多大功率、工作在什么电压区间,是由变压器、开关管、输出电容和环路补偿共同决定的。协议芯片可以广播五个档位,但如果实际硬件在最大档位下发热严重、输出电压跌落,那这个广播就是在给认证和用户体验埋雷。

3.3 受电端:充电IC与协议交互

如果你做的是手机、平板或笔记本这类受电设备,侧重点又不同。受电端充电IC要理解UFCS协议中"设备请求电压"的逻辑,然后把它转换成适合电池充电的电压和电流。设备不能因为支持UFCS就一味要高压,还要结合电池温度、电量和内阻动态调整充电策略。

很多设备同时支持私有协议、PD和UFCS,交互时的优先级设计很关键。我的做法是先在产品定义阶段写清楚协议优先级,比如"私有协议最优,其次UFCS,再次PD,最后普通5V"。这样既保住了品牌自有产品的体验,也不会在连接第三方充电器时完全失去快充能力。

3.4 一次完整的UFCS握手与调压过程

在实验室里观察一次UFCS充电过程,大体是这样的流程:插上Type-C线缆后,源端和受电端先在默认5V下建立通信连接;设备广播自己的充电能力和期望电压,源端广播自己能提供的功率档位;双方完成匹配后,设备发出调压请求,源端逐步把输出电压调到目标值;电压稳定后,设备开始拉取电流,进入正常快充状态。

整个过程中最值得盯的是调压过渡。快速调压容易造成电压过冲,太慢又会让设备误以为协议异常而退出快充。实际调试时我习惯把电子负载设置成动态拉载,边调压边拉电流,观察输出电压波形上有没有明显台阶或振铃。源端和受电端之间必须来回确认多轮消息,有一轮超时都可能导致握手失败。

3.5 交叉互操作测试一定要做足

认证通过不等于所有终端都能正常快充。真实市场上有大量线缆、不同接口规范、不同芯片方案、不同系统版本,交叉组合之后问题会放大。我给自己定了一个最低要求:每款产品至少要测试三台不同品牌的UFCS受电端、两台第三方充电器、三种不同线缆,再加上老化带载和双口互充场景。

测试时还要注意E-Marker线缆和普通CC线缆的差异。有些快充协议需要线缆具备E-Marker芯片才能承载超过5A电流,普通线缆会在电流限制上卡住。UFCS的协商结果必须考虑线缆能力,否则设备端请求了高电流,线缆却在物理层限制住,容易导致充电中止或发热。把这些场景放进测试计划,后面量产客诉会少很多。

4. 项目落地时最容易踩的坑

4.1 只追UFCS,忘了兼容存量快充

UFCS是公共协议,但消费者的抽屉里还有很多旧充电器采用了厂商私有协议。如果新产品只做UFCS而不兼容私有协议,用户用旧充电器时还是只能慢充,换新的动力就打折扣。

我建议做双协议甚至多协议兼容。协议芯片在端口上检测到设备支持UFCS时走UFCS通道,检测到私有协议时走私有通道,检测到标准PD时走PD通道。这个优先级不是简单排个序,还要处理一些设备同时广播多种协议的情况,这时候芯片需要根据设备的能力和电源侧重选择最合适的路径。多协议一定增加工作量,但没有它,产品的市场接受度会受影响。

4.2 电压切换翻车:输出跌落和过冲

UFCS调压需要源端实时改变输出电压,这比固定5V输出难多了。常见的问题是切换瞬间出现输出过冲,严重时会触发设备保护甚至烧板子;另一种是切换时输出电压掉太多,设备认为协议异常,立刻断开快充。

根因多半在反馈环路和调压策略上。反馈环路响应太慢,负载变化后电压来不及修正;调压跨度太大,又没有中间缓冲,就容易冲过头。解决方向是让调压分步进行,并在切换过程中保持电流很小或空载,每一步稳定后再走下一步。电路设计上预留足够的输出电容,也能显著改善动态响应。

4.3 认证准备时忽略的细节

申请UFCS认证之前,不要只顾着写代码和调硬件。认证现场需要提供完整的设计说明、固件版本说明、测试样机和必要的测试夹具。样机数量要留足,因为测试项目里有些破坏性测试会直接损坏样品;固件版本要锁定,认证前不要临时改功能,否则测试结果无法真实复现。

还有一点容易被忽略:认证通过后,量产固件如果和送检固件不一致,认证状态实际上已经变了。这意味着后续每次固件大版本升级,都要评估是否需要重新提交部分测试。量产前最好把固件版本管理起来,做到可以追溯。

4.4 常见问题速查表

现象可能原因排查思路
插上后只有5V,无法触发快充协议握手失败或优先级未匹配先看是否有通信波形,再核对设备广播消息
握手后电压到位,但电流上不去线缆电流能力不足或电源功率限制换E-Marker线缆,确认目标功率在电源能力内
轻载调压正常,重载电压跌落反馈环路补偿不足调整环路参数,增加输出电容或降低拉载斜率
某些品牌设备无法握手协议版本兼容或私有协议优先冲突抓取协议消息,对照特定设备的广播能力
线缆不同导致快充不稳定线缆电阻和CC通道质量影响统一线缆规格,测试时固定测试条件
持续高功率输出后降频保护热设计不足或过温保护阈值过低检查温升,优化散热,调整保护阈值

4.5 避坑心得与量产建议

我踩过最大的坑是拿到一个"看起来支持"UFCS的芯片,但实际只完成了单个场景的验证。项目开发到一半才发现它跟另一种主流受电端握手不稳定,不得不重新选型和改板。这件事之后,我给自己定了一条规矩:新项目选协议芯片,第一优先级永远是看认证报告,第二优先级才是价格和供货。

量产阶段还要预留固件升级能力。UFCS标准还在演进,实际落地过程中会有不少细节被修订和补充。如果产品出厂后固件无法升级,遇到兼容性问题就只能下架返工。哪怕只是一个隐藏升级接口,也比完全没有强。

5. 33款芯片之后,融合快充生态会怎么走

5.1 对产品定义的影响:从选配件变成默认项

以前产品定义快充功能,默认是跟着自家私有协议或者PD走。UFCS芯片大量过检之后,融合快充会慢慢变成默认功能。尤其是一些面向多品牌用户的公共场景,比如共享充电宝、车载充电器、多口桌面充,单独支持一种私有协议根本不够,必须要有公共协议托底。

对产品经理来说,UFCS最直接的价值是把"兼容性"从一个模糊卖点,变成一个可标注、可验证的特性。产品包装上可以直接写支持融合快充,不再需要长篇解释"支持某某协议、某某协议、某某协议"。

5.2 对供应链和成本的影响

从供应链角度看,33款芯片过检意味着已经有足够多的选择,不用再被某一家芯片卡住。多供应商供货会带来更合理的价格竞争,也会让下游方案商的日子好过一些。融合快充本身不会让芯片更贵,反而因为标准统一,芯片厂商可以在一个通用协议栈上做规模优化,长期看成本会被摊薄。

当然,不是所有产品都需要UFCS。一些极低成本的桌面小充、数据线,可能继续停留在普通5V或者单一PD阶段。但这部分产品也在慢慢减少,因为消费者已经开始认得"融合快充"这个标识,同等价格下更愿意选兼容性更好的那一个。

5.3 对消费者的实际改善

消费者最直观的感受应该是"充电头终于可以少买几个了"。以前一个手机一个头,现在一个支持UFCS的充电器可以给不同品牌手机快充,甚至同时给手机、耳机、充电宝补电。公共区域里的充电位也不必再贴一张密密麻麻的兼容列表,用户插上去就知道能充多快。

不过这需要一个过程。市场上还有大量存量设备只支持私有协议,融合快充不可能一夜之间取代它们。比较现实的状态是:未来新产品普遍支持UFCS,同时保留对存量协议的后向兼容,让用户手里的旧设备不会被完全排除在外。

5.4 现实挑战:协议统一不是终点

UFCS融合快充解决了最基础的互操作问题,但快充远不只是握手协议。更高功率带来的热设计、多口功率分配、电池寿命管理、无线充电融合,都是后续要面对的问题。33款芯片过检是一个很好的节点,它证明了标准已经从文本走到芯片供应链,接下来真正的考验是终端产品能不能把这些能力用稳定。

我个人在实际选型时,会先问自己三个问题:这颗芯片是否真的拿到了UFCS认证报告?认证覆盖的功率档位是否覆盖我的产品定义?量产固件能不能持续升级?这三个问题看着基础,但很多项目恰恰是栽在这些基础环节上。融合快充的大方向没有问题,真正决定产品成败的,还是每一个连接点上的稳定和细节。

相关新闻

STM32 CAN总线实战:从物理层到协议栈的深度解析

STM32 CAN总线实战:从物理层到协议栈的深度解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:07:34 阅读更多 →
RK3528嵌入式直播全栈方案:硬编硬解+AI绿幕+六协议共存

RK3528嵌入式直播全栈方案:硬编硬解+AI绿幕+六协议共存

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:07:34 阅读更多 →
STM32+华为云IoT+Qt:跨平台智能家居控制系统全链路实战

STM32+华为云IoT+Qt:跨平台智能家居控制系统全链路实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:07:34 阅读更多 →

最新新闻

Unity代码热更新实战:ILRuntime集成Addressable的完整方案与避坑指南

Unity代码热更新实战:ILRuntime集成Addressable的完整方案与避坑指南

做Unity客户端这些年,只要是做手游的,基本绕不开热更新这个话题。资源热更还好说,AssetBundle或者Addressable都能解决,真正麻烦的是代码热更。以前用Lua,好是好,但团队要养Lua程序员,C#的代码也…

2026/10/20 2:00:13 阅读更多 →
MapReduce核心原理解析:从分而治之到Shuffle与优化实践

MapReduce核心原理解析:从分而治之到Shuffle与优化实践

1. 为什么先要有MapReduce:单机跑不动的那一刻我最早接触MapReduce是在某培训机构的课程笔记里(也就是标题里这个"学习历程"系列),前几章还在讲HDFS,讲数据怎么分块存储、怎么备份。当时我的感觉是&#xff…

2026/10/20 2:00:13 阅读更多 →
排队论与Anylogic仿真:车站进站拥堵优化实践

排队论与Anylogic仿真:车站进站拥堵优化实践

简介:一份基于排队论与Anylogic仿真研究车站进站排队优化的学术PDF文档,面向铁路运营管理、车站规划设计及客流管理相关从业者与研究人员,也适合交通工程、运筹学方向学生作为案例参考。文档针对实名制售票下旅客进站排队过长、体验不佳的问题…

2026/10/20 2:00:13 阅读更多 →
轻量级数据抓取与清洗:用Python和规则配置打造自动化处理工具

轻量级数据抓取与清洗:用Python和规则配置打造自动化处理工具

1. 为什么会做"rea"这个项目"rea"这个名字从一开始就不是什么复杂的单词缩写,它只是我手上这个小工具的一个代号。当时我维护着一个内容站点,每天需要从几个固定的数据源抓取素材,经过人工筛选、格式整理之后再发布到后台…

2026/10/20 2:00:13 阅读更多 →
ANSYS弹塑性分析实战:从弹性到塑性收敛调试

ANSYS弹塑性分析实战:从弹性到塑性收敛调试

简介:《2021年ANSYS弹性及塑性分析非常经典.docx》是一份面向ANSYS初、中级用户及机械、土木、航天等工程领域从业者的中文教程资料,聚焦弹性与塑性非线性分析的核心原理和软件操作方法,帮助读者理解材料屈服、塑性变形和ANSYS塑性选项的实际…

2026/10/20 2:00:13 阅读更多 →
HyperDbg:Windows Ring0级内核调试代理原理与实践

HyperDbg:Windows Ring0级内核调试代理原理与实践

简介:本资源为开源Ring0级内核调试器Hyperdbg的完整源码工程,面向Windows驱动开发者、系统安全研究员及操作系统学习者,用于深入理解与实践内核层调试技术,解决驱动开发调试、恶意代码行为分析、系统稳定性优化等高阶问题。压缩包…

2026/10/20 1:59:13 阅读更多 →

日新闻

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
ESP32舵机控制指南:原理、多路驱动与避坑实战

ESP32舵机控制指南:原理、多路驱动与避坑实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
位移法实现一阶低通滤波:单片机ADC采样降噪实战

位移法实现一阶低通滤波:单片机ADC采样降噪实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →

周新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/19 10:02:04 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/19 17:32:41 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/19 1:30:52 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/19 2:54:50 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/19 9:10:22 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/18 12:16:16 阅读更多 →