AI+制造场景落地:五类高价值场景的选择与避坑指南

做智能制造落地这几年,我被问得最多的一个问题就是:“AI+制造,到底先做哪个场景?”大多数企业其实不是缺技术,是缺一张分清了“能做”和“值得做”的优先级清单。最近我翻到一份区域级的“AI+制造”场景建设指南(第一期),它把典型场景按建设条件、数据需求和预期收益排了个序,读下来的感觉是:这份清单不是技术排行榜,而是告诉你先从哪里切入最容易跑通、最不容易烂尾。这篇文章我结合自己做产线智能化项目的经验,把场景选择背后的逻辑、五类高价值场景的落地路线、数据盘点方法和试点避坑思路重新梳理一遍,适合正在做产线智能化规划的制造企业负责人、方案架构师,也适合刚准备入行的实施团队直接当作工作底稿来用。

1. 这份场景清单背后的选择逻辑

绝大多数制造企业搞AI转型,失败的第一原因不是模型精度不够,而是场景选错了。一个场景如果收益说不清楚、数据要现补、产线又不愿意配合,那不管技术多牛都推不下去。我认真看了这份第一期指南,它列的每一个场景基本都满足四个条件:有明确的可量化收益口径、数据基础能在6个月内补齐、场景可以在同行业内复制到多条产线、市面上有成熟供应商而不是纯实验室项目。

这四个条件背后其实是一套很务实的筛选逻辑。收益可量化决定了这个项目能不能立项、能不能验收;数据基础决定了你上不上得了手;可复制性决定了投入一次能不能多次变现;供应商成熟度则决定了你是在做工程还是在做科研。我把这个逻辑转成了下面这张判断表,做场景筛选时刻直接对照。

判断维度要回答的核心问题落地红线
可量化收益这个场景能直接换算出多少钱?没有基线指标的项目不做
数据基础现有数据能不能支撑建模?需要超过6个月改造数据的慎重启动
可复制性跑通后能挪到多少条同类产线?只有单点价值的场景暂缓
供应商成熟度市场上有没有成熟方案可参考?需要完全定制算法的项目降级为预研

1.1 为什么把“可量化收益”放在第一位

我见过太多AI项目汇报时只说“效率有提升”,但问“提升了多少、怎么算的、省了多少成本”,一个都答不上来。这种项目就算上线了,第二年预算也一定被砍。所以指南把可量化收益放在第一位是很有道理的——它逼着你在做技术之前,先把财务账算清楚。

实际操作里,每个场景的计量口径要先定死。缺陷检测要看漏检率、过杀率,以及因为过杀导致的返工成本;预测性维护要看非计划停机时长的下降比例;排产优化要看换型时间、交期达成率;能源管理直接看单位产出的电费和水费变化。这些口径必须在项目启动前跟财务、生产、设备三个部门一起确认,并且留出为期两周左右的数据基线采集期。我遇到过一家企业,上AI质检时验收只测“能检出缺陷”,没测过杀率,结果上线后过杀严重,操作工每天都在投诉,项目最后被叫停——问题就出在验收指标不完整。

1.2 场景与产品成熟度的匹配判断

第二件要看清楚的事是:不是指南里收录的场景就代表人人都能落地,不同场景的技术成熟度差别非常大。按我观察到的现状,表面缺陷检测是最成熟的,工业相机加算法已经可以用;设备预测性维护属于中等成熟,数据条件好的工厂能见效,数据条件差的容易做成“告警盒子”;生产排产优化难度更高,问题定义比算法本身还难;工艺参数寻优则取决于你积累了多少带标签的工艺记录。

我建议企业根据自身现状选择入场场景:如果你的产线已经有完善的传感器和PLC数据采集,优先做预测性维护;如果你有大量历史缺陷图片和明确的质检标准,优先做缺陷检测;如果你刚刚开始数字化建设、数据还靠人工录入,那就先把能源管理和设备OEE(设备综合效率)这类数据要求低的场景做起来,不要一上来就碰排产优化。

2. 五个高价值场景的落地路线与门槛分析

指南第一期列的场景可以归纳成几大类。我结合自己实际参与过的项目,挑五个最常见、也最能直接见效的场景,把落地路线和门槛摊开讲清楚。下面这个总览表可以帮你在做方案前快速定位自己要投入的方向。

场景类型适用的产线特征核心输入数据主要技术栈关键验收指标
表面缺陷检测产品外观要求高、人工质检强度大产品图像、缺陷标注、产线节拍目标检测、图像分类漏检率、过杀率、单张推理耗时
设备预测性维护关键设备故障影响大、停机成本高振动、温度、电流、历史维修记录时序异常检测、老化曲线误报率、提前预警时长
生产排产优化多品种小批量、订单切换频繁工单、BOM、设备产能、物料库存约束规划、启发式搜索换型次数、交期达成率
工艺参数寻优工艺窗口复杂、依赖老师傅经验历史工艺参数、对应质量结果回归代理模型、贝叶斯优化工艺窗口命中率、良率提升
能源精细化管理能耗占比高、用能曲线波动明显电表、水表、气表、产线产量负荷预测、规则优化单位产出能耗下降比例

2.1 表面缺陷检测:最成熟也最容易踩坑的场景

缺陷检测是AI在制造领域落地最广的场景。因为它的逻辑最直观:用相机替代人眼,用模型替代经验。但它的坑也最容易被低估。

第一坑是成像方案。我见过不少项目,算法团队一进来就急着跑模型,结果发现白天和晚上的检测结果差异很大,原因是光源方案没做稳定,环境光干扰太严重。光源和相机选型必须基于被测物的表面材质来定:反光强的材料要用低角度光,透明件要考虑背光,高速产线上还需要考虑频闪同步。这些在项目前期就要找有视觉集成经验的人一起定,不能让算法工程师临时补课。

第二坑是缺陷定义。同一个“划痕”,质检老手和新手标注出来的范围可能差很多。建议在标注启动前做一份缺陷判定作业规范,把每种缺陷拍成样例图,明确边界情况,并做一轮标注一致性测试,让不同标注员的IoU(交并比)一致性达到比较高的水平再开始正式标注。

第三坑是节拍约束。离线测试时模型跑得再准,一旦要嵌入产线,单次推理时间必须小于产线节拍留给检测工序的时间窗口。比如产线节拍是2秒一件,你的模型在GPU上跑一次要800毫秒,再加上图像采集和运动控制的时序消耗,可能就压线了。所以在方案阶段就要先算清楚推理时间预算,再决定模型轻量化策略。

2.2 设备预测性维护:从数据采集到故障阈值

预测性维护的收益逻辑很清楚:减少非计划停机,降低维修成本和备件损失。但执行起来,大多数工厂卡在数据准备上。很多设备虽然能联网,但PLC里的数据时间戳对不齐,采样周期不稳定,历史维修记录和故障时间点又没有结构化,结果报警模型根本没法训练。

我的建议是分三步走。第一步先梳理关键设备清单,按“停机影响程度”排序,选出一两台核心设备做试点,不要铺开。第二步做数据质量审查,重点确认三项:传感器数据是否连续存储、时间戳是否对齐、维修工单是否记录了准确的故障起止时间。如果这三项都不满足,先做数据采集改造。第三步再从健康度打分做起,不直接追求“提前两天预测故障”。比较稳妥的做法是用振动、温度、电流等多维时序数据训练异常检测模型,当设备运行状态偏离历史正常模式时给出告警,再结合维修人员的经验设定阈值。

这个场景我特别提醒一点:不要只看模型准确率,要把误报率当作第一指标。误报一次两次大家能忍,误报十次就没人信这个系统了,最后设备真的出问题也没人理。所以在告警策略上,宁可漏报少报,也要保证报出来的都是高置信度事件。

2.3 生产排产优化:约束条件比算法更重要

生产排产是看起来最“AI”的场景,但也是最容易翻车的。难点不在算法,而在把排产规则转换成算法能理解的约束条件。工人排产的时候脑子里装的东西远超你想象:工单优先级、设备切换成本、模具和治具的可用状态、物料齐套时间、人员班次、维修日历、甚至不同工位的熟练工差异。这些如果不一起扔进模型里,算出来的排程计划员根本不敢用。

我在实际项目里强烈建议先做“约束梳理工作坊”,把生产计划员、车间主任、维修负责人拉在一起,把规则一条条列出来,标出哪些是硬约束、哪些是软约束、哪些是历史习惯但可以打破。然后先用规则引擎或者仿真工具验证版本,跑两周看计划员接不接受,再决定要不要上优化求解器。技术选型上,中小规模排产用约束规划或遗传算法就够了,不用一上来就上强化学习,后者调试成本会吃掉你所有收益。

排产系统的另一个隐藏需求是“可解释性”。计划员不信任黑盒输出,一张排产表只是结果,他更想知道为什么这么排。所以系统要在输出排产表的同时,给出约束冲突说明和理由摘要。如果做不到这一点,在组织里基本推不动。

2.4 工艺参数寻优:让老师傅经验变成数据模型

很多产线存在一个奇怪现象:工艺参数是老师傅口头传承的“秘方”,一旦老师傅不在,新产品试制就抓瞎。AI在工艺参数寻优场景里能做的,是通过历史数据学习参数和质量指标之间的关系,再在参数空间里搜索更优组合,把“老师傅经验”变成“数据模型加推荐参数”。

具体路线是:先收集历史工艺参数和对应质量检验结果,清洗之后作为训练数据;然后训练一个代理模型,用来模拟“给定一组参数,大概会得到什么质量结果”;最后用贝叶斯优化在这个代理模型上搜索最优参数组合。但要注意,纯数据拟合很容易找到物理上不可行的参数,比如温度超出设备极限、压力超出模具承载。所以必须把设备说明中的安全范围作为硬约束加进优化过程,让搜索结果始终落在可行区间里。

我在注塑和焊接类项目里看到的效果最明显。注塑机的料温、模温、保压时间、注射速度,这些参数组合空间巨大,凭人工试错根本扫不完。用AI寻优之后,通常能把试模次数从十几次压到三五次,良率提升一到两个百分点。这类场景的验收指标也很干净:直接看良率和试模周期。

2.5 能源精细化管理:回本最快的低调场景

能源场景在指南里容易被大家忽略,因为它听起来不像“AI”。但按我接触过的实际改造,能源精细化管理往往是投资回收期最短的一类。原因很简单:电表、水表、气表在绝大多数工厂里都有长期历史数据,数据质量远好于设备振动和工艺记录,而且能源单价是明确的,省一度电就是省一度电的钱,收益算得清清楚楚。

落地思路通常分两条线。一条是负荷预测,用过去一年的用能数据结合产量、天气、班次安排,预测接下来一周的负荷曲线,然后错峰用电,把高耗能工序往阶梯电价低的时段挪。另一条是单设备优化,比如压缩空气系统、中央空调、冷冻机组,这些系统的运行策略通常是人为设定的固定值,AI可以根据实际负荷动态调节运行台数和参数,往往能挖出5%到15%的能耗空间。

这类项目对团队的技术要求其实不高,但需要对工厂用能体系有人懂。你要知道哪块表对应哪条产线,哪个能耗单元占大头,才能选对优化对象。建议做能源场景前,先拉一份车间能耗分布表,找到占比最高的三个用能单元,然后再谈模型。

3. 场景建设前必须完成的数据资产盘点

很多团队把数据盘点理解成“数据库里有什么导出来看看”,这是大错特错。AI落地需要的数据要满足几个硬性条件:有足够的回看周期、有和业务事件对齐的时间戳、有明确的字段含义、可以持续稳定地增量采集。我习惯先做一次数据可用性分级,再决定场景能不能上、需要补什么数据工程。

3.1 数据可用性分级:从立即可用到需要技改

我通常把数据资产分成三个等级。A级数据可以直接拿来建模,特征是已经在数据库中结构化存储超过一年,时间戳完整,字段含义有文档,业务事件(比如缺陷记录、停机记录)能通过ID关联起来。B级数据可采集但需要治理,特征是设备或系统有数据,但要先去部署采集网关、清洗历史数据、对齐时间戳,工程量大。C级数据需要技术改造才能拿到,比如要新增传感器、更换PLC或改造设备通信模块,这类往往要动生产线,周期和预算都不可控。

企业做场景规划时,应先盘一遍自己有哪些A级和B级数据,再决定场景优先级。没有数据就是没有地基,再好的算法也是空中楼阁。我在项目里见过最典型的失败案例,是某公司决定做设备预测性维护,结果发现设备的历史维修记录全在纸质工单上,故障时间点完全没法对齐电子版传感器数据,项目在数据治理阶段就耗掉了大半预算。

3.2 时间维度与标注质量对模型效果的实测影响

数据盘点里还有两个特别容易被忽视的因素:时间跨度和标注质量。

时间跨度方面,很多项目赶进度,只用最近一周或者一个月的热数据训练模型,当时效果很好,结果换季、换料、节假日排产调整之后性能大幅下降。正确做法是至少覆盖一个完整的生产周期,包括淡旺季、不同原材料批次、不同产品型号。如果条件紧张,也要保证训练集和验证集来自不同时间段,确保模型不是只记住了某个时段的数据特征。

标注质量方面,缺陷检测这类监督学习场景,标注质量直接决定模型上限。标注没有统一口径,模型训练出来的决策边界就是乱的。建议在开始标注前做标注规则培训,再让不同标注员标同一批图算一致性;标注过程中也要定期抽检,把标注规范的偏差控制在可接受范围内。

4. 试点阶段最容易翻车的三个环节

场景选好、数据盘完,真正开始试点的时候,还会有三个反复出现的翻车点。我把它们单独列出来,不是因为技术多难,而是因为几乎每个项目都要在这里面磨几轮。

4.1 样本不均衡:缺陷数据不够怎么补

以缺陷检测为例,正常品占绝大多数,真实缺陷样本极其稀疏。有些缺陷类型的出现频率是每万件才一次,你采集三个月也攒不出足够的样本。这时候有几个办法可以组合使用:一是跨产线共享缺陷样本,只要产品形态接近,模型可以做迁移学习;二是做数据增强,旋转、缩放、亮度变化、加噪;三是合成缺陷,用图像编辑方法把真实缺陷粘贴到正常样本上。

但我要特别提醒:合成缺陷要克制。合成出来的缺陷如果和真实缺陷形态差异太大,模型学到的是“假缺陷”,上线到真实产线反而会漏检。正确姿势是先用真实缺陷样本训练一个初版模型,在它搞不定的难例上再考虑合成补充,而且合成样本要控制在一定比例以内,避免主导训练分布。

4.2 模型验证方式错误:离线测得好不等于在线能用

团队最容易自我陶醉的环节是离线评测。大家都在历史数据集上比精度、比召回,出一份看起来很漂亮的报告,结果一接产线就露馅。原因主要有几个:产线实际数据分布和采集的历史数据有偏差;在线推理有延迟约束;干预决策后操作工会改变行为,形成一个反馈回路。

我建议试点阶段采用“影子模式”双跑:系统先不直接干预产线,而是和现有作业方式并行运行一两个星期,每天对比模型输出和实际结果。以质检为例,就是模型先跑出结果但不参与放行,人工按原流程做判断,最后对拍差异。这样既能评估真实准确率,又不会因为系统误判打断生产,是当前最稳妥的验证方式。

4.3 IT与OT网络边界:部署时被安全策略卡住

这是最让我抓狂的一类问题,技术都测好了,部署时发现AI服务器访问不到PLC数据。很多工厂的OT网络和IT网络之间是有安全隔离的,机房到车间的通信端口不开放,数据出不来。这个不是算法团队能单独解决的,需要提前和IT、OT、自动化几个部门一起定数据流通方案。

常规方案有这么几种:用工业网闸做单向数据传输,把设备侧数据单向同步到数据区;在车间侧部署边缘网关,让网关主动采集数据后转发到AI平台;或者通过OPC UA协议在授权的通道上做点位映射。不管选哪种,都要在项目启动时就启动网络策略变更流程,这类审批往往比开发周期还长。

5. 团队与算力配置的务实建议

5.1 团队最小配置与角色分工

做AI+制造项目,团队拼的不是人数,是角色完整。我认为最小配置是四个人:一个懂工艺和业务的现场工程师,负责定义问题、组织数据标注、跟产线沟通;一个数据工程师,负责数据采集链路、数据清洗和特征处理;一个算法工程师,负责建模和调参;一个运维或IT工程师,负责部署和系统稳定性。

现实中很多企业只招算法工程师,觉得算法是核心。但项目真正卡住的往往是数据链路和业务问题定义:标注规范谁定?PLC点位谁去理?车间不配合谁去沟通?这些事让算法工程师干,既慢又容易出偏差。我见过一个案例,项目启动半年,算法工程师换了三版模型,但数据接口一直不稳定,每天要手工导一次数据,最后在数据工程师到位之后,两周就把模型跑到可上线状态。

5.2 算力预算梯度:别一开始就建大集群

算力这块我建议分梯度规划,不要一上来就采购一堆GPU服务器。试点阶段,一张主流消费级显卡的工作站就够跑缺陷检测或预测维护的模型训练;数据量大的话,上一台有双卡的工作站,也能扛住大部分场景。真正到了需要并行训练多个模型、或者要服务多条产线实时推理的时候,再考虑集中式推理集群。

推理端的算力要单独算。边缘推理通常用工业级IPC插一张推理卡就能满足,部分轻量模型用嵌入式盒子也能跑。关键指标是每秒推理帧数和产线节拍匹配,宁可买高一点的算力留余量,也不要卡在性能边界上天天调优。训练集群则按项目并发数来估算:同时跑三个模型实验,单卡资源够用;同时跑十个以上,再考虑上多卡集群或云资源。

6. 第一期场景跑通后的扩展顺序思考

6.1 从单点场景到跨工序协同

企业最容易犯的错误,是跑通一个场景后急着再开三五条新场景线。我的建议是先打横、再打纵。所谓打横,是先把一个成功场景复制到同类型的其他产线或车间,把数据接口、模型部署、运维流程标准化,降低边际成本。所谓打纵,是把不同场景的数据串起来,形成跨工序协同。比如质检数据回流给工艺参数寻优,让模型知道哪个参数组合容易产生缺陷;排产结果联动预测性维护,让维修计划避开高负荷排期。

跨工序协同的价值在于:单个场景解决的是局部效率问题,协同解决的问题是整条价值链的平衡。但从单点到协同,技术复杂度呈指数上升,必须在单场景稳定运行两到三个季度之后再启动,否则容易把战线拉太长。

6.2 指标沉淀与场景复制的节奏

每个场景跑通之后,不要急着做下一个,先沉淀四样东西:数据字典和采集规范,让你换产线时不用重新理解数据;标注规范和缺陷库,让第二个车间的标注不用从零开始;模型评估基准和上线流程,让复制时不再靠个人口口相传;部署文档和运维手册,让IT团队能独立接管。

我一直跟团队强调,场景复制不是重新做一遍,而是把已经验证过的能力往下套。套的时候要评估两个差异:产线设备差异带来的数据分布变化,以及工艺差异带来的模型调整空间。如果这两个差异可控,通常三四周就能复制一个点;如果差异大,那就回到试点流程重新走。复制节奏上,我建议一个季度复制一个场景到两条产线,不要贪多,跑完一个闭环再扩下一个。

最后分享一点个人体会:做AI+制造场景,技术只是其中一环。真正决定项目能不能活下去的,是你在前面选了什么场景、有没有算清楚账、数据链路顺不顺、现场伙伴配不配合。每次拓展新方向之前,我会问自己一个问题:这个场景换一条产线还能不能复用?如果答案是不能,那我就先停下,把基础能力和数据平台补扎实再走下一步。

相关新闻

CLI驱动的Git集成代码审查:LLM作为轻量级审查协作者

CLI驱动的Git集成代码审查:LLM作为轻量级审查协作者

1. 项目概述:这不是又一个“AI写代码”玩具,而是一套嵌入开发流程的轻量级代码审查协作者“open-code-review”这个名字乍一听像某个开源项目仓库名,但拆开来看——open(开放)、code(代码)、rev…

2026/10/19 16:35:07 阅读更多 →
AI客服如何让电商重复性咨询降低78%?KoalaQA接入实战解析

AI客服如何让电商重复性咨询降低78%?KoalaQA接入实战解析

做电商客服的朋友应该都体会过那种感觉:后台弹窗一个接一个,催物流的、问退款的、要发票的,同一句话复制粘贴了几十遍,手都快麻了,工单却越积越多。我自己经手过的几个店铺项目里,售后咨询里真正需要人工介…

2026/10/19 16:35:07 阅读更多 →
养老护理管理系统:前后端分离与微服务架构实践解析

养老护理管理系统:前后端分离与微服务架构实践解析

2. 项目概述2.1 核心需求解析2.2 技术选型背后的思考3. 项目结构与系统架构3.1 前后端分离架构设计3.2 后端微服务模块划分3.3 前端工程化组织架构4. 核心业务模块详解4.1 老人档案管理4.2 护理工作记录4.3 床位分配系统4.4 费用收支管理5. 数据库设计与实现5.1 关键数据表结构…

2026/10/19 16:35:07 阅读更多 →

最新新闻

Java SE蓝牙开发实战:SPP通信全链路实现与跨平台适配

Java SE蓝牙开发实战:SPP通信全链路实现与跨平台适配

简介:本资源是一个面向Java开发者与物联网初学者的蓝牙通信实践项目,聚焦JSR-82规范在桌面端的落地实现,解决Java SE环境下缺乏原生蓝牙支持的开发痛点,适用于智能家居设备控制、低功耗传感器通信等IoT场景。压缩包为RAR格式&…

2026/10/19 17:25:59 阅读更多 →
基于Python的出租房管理系统设计与实现

基于Python的出租房管理系统设计与实现

去年接了个活,帮一位房东朋友做一套能管几十套房子的出租房管理系统。他原来的方式是一本纸质台账加一个Excel表,租客信息散落在微信聊天记录里,哪个房间该收房租了全靠翻日历,水电费对账对到头晕。我问他想要什么功能&#xff0c…

2026/10/19 17:25:59 阅读更多 →
大模型应用开发全流程实战:从Prompt到Agent与微调

大模型应用开发全流程实战:从Prompt到Agent与微调

做了一年多大模型应用开发,带过几个从零起步的项目,也带过不少刚入门的同学。我发现大家遇到的最常见问题,不是“API怎么调不对”,而是“整个应用开发的流程到底怎么串起来”。这篇就把我从入门到搞明白的完整过程整理出来&#x…

2026/10/19 17:25:59 阅读更多 →
大模型应用开发完整流程:从需求拆解到上线优化

大模型应用开发完整流程:从需求拆解到上线优化

这几年做AI应用落地,我反复被问到同一个问题:大模型应用开发的完整流程到底是什么?问的人里有刚转行过来的前端工程师、有做数据分析出身的研究生、也有不少已经在公司里顶着“AI负责人”头衔、但手里只有几个API Key的朋友。大家的困惑其实都…

2026/10/19 17:25:59 阅读更多 →
GCC 编译选项实战指南:从 -Wall 到 -O2 的工程化配置

GCC 编译选项实战指南:从 -Wall 到 -O2 的工程化配置

1. 为什么“会敲 gcc 命令”和“懂 gcc 编译选项”是两回事很多人第一次接触 C/C 开发,都是从一行gcc hello.c -o hello开始的。这行命令能跑通,于是很多人就觉得自己“会用 gcc”了。但真正进入稍具规模的项目,尤其是需要排查诡异 bug、分析…

2026/10/19 17:25:59 阅读更多 →
开源代码审查CLI工具:LLM+Git上下文驱动的智能Review方案

开源代码审查CLI工具:LLM+Git上下文驱动的智能Review方案

1. 项目概述:一个真正能落地的开源代码审查 CLI 工具“open-code-review”这个名字乍一听像某个 GitHub 上刚起步的玩具项目,但如果你最近在团队里被 PR 堆得喘不过气、被“请检查一下这段逻辑”这种模糊反馈折磨过,或者自己写完代码总不敢点…

2026/10/19 17:24:57 阅读更多 →

日新闻

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

简介:本资源为电源技术方向的学术研究文档,聚焦介质阻挡放电型臭氧发生器电源的频率跟踪型PWM控制策略,面向电力电子、高压电源及臭氧应用领域的科研人员与工程技术人员。针对负载呈容性、等效电容随外加电压升高而增大、谐振频率随之漂移的难…

2026/10/19 0:00:47 阅读更多 →
Vibe Coding 遇上 TaoToken:把开发者思维圣殿的灵感流接入统一 Key 通道

Vibe Coding 遇上 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 0:00:47 阅读更多 →
HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

【免费下载链接】HundredCV-Chat 项目地址: https://ai.gitcode.com/hf_mirrors/Jax-dan/HundredCV-Chat 点击查看 免费下载 HundredCV-Chat 是一个由 100 位青年简历数据开发而来的中文多轮对话数据集,共包含 24,750 组日常闲聊对话和 4,871 个话题标签…

2026/10/19 0:00:47 阅读更多 →

周新闻

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

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

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

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

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

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

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

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

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在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 阅读更多 →