2026会议实时转写工具横评:从WER到纪要可用性的深度实测

去年年底我们团队开始物色新的会议实时转写工具,到了2026年这一波技术升级,市面上热门的几款产品已经明显分成两个阵营:一类是办公套件顺手加进来的“赠品级”转写,另一类是专注把转写这件事做到极致的“专业队”。我把当前最火的四款工具放在同一间会议室里实测了三周,用同一套录音和同一个麦克风轮番测了好几轮,结论是——真香款和同行的差距,不是一点半点。

先说清楚我这次测的是什么。会议实时转写工具,说人话就是开会的时候把大家说的话实时转成字幕、会后自动生成纪要的AI工具。以前这玩意儿只能解决“懒得打字”的问题,2026年再测,已经开始拼谁能在会议结束三分钟内给你一份带决策、带待办、带风险项的会议记录。适合谁看?经常开会到脑壳疼的管理者、被周报压垮的项目助理、以及想偷懒但又被领导逼着交纪要的普通打工人,这篇都适用。

1. 为什么2026年这个节点值得重新测一轮会议实时转写工具

1.1 会议记录的老问题:不是“记不下来”,是“用不起来”

我前两年用过的几款工具,本质上就是一个语音转文字机——给一段音频,还你一段通篇没有标点的文字稿。你要想从里面扒出“谁说了什么”“下一步谁负责什么”,还得自己从头捋一遍,体感跟人工整理纪要差不了太多。

这轮实测之前,我还特意翻了一下2026年各家的功能更新日志,变化确实大。倒不是“识别准确率从95%涨到97%”这种参数游戏,而是整个产品逻辑从“转写”转向了“理解”:识别说话人、按话题切分片段、自动提取待办事项、甚至能在会议中途给出讨论提醒。也就是说,工具不再满足于当一支录音笔,而是想当半个会议助理。

但这恰恰是问题所在。功能宣传是一回事,真正开会的时候能不能接得住“技术人员口中的专业术语”“客户带着口音的普通话”“三个人同时插嘴的混乱场面”,完全是另一回事。这也是为什么我愿意花三周时间做横向实测的原因——功能清单谁都能列,真实场景下好不好用,必须拿真会议去“照妖镜”。

1.2 本次对比的目标和范围

这次我锁定了四款市面上讨论热度最高的产品,都用代称:

  • 记刻:某办公套件自带的会议转写模块,背靠大树,用户基数最大。
  • 听灵:专注会议转写垂直场景的专业工具,主打高准确率和结构化纪要。
  • 秒转:轻量级低价工具,以“快”出名,适合个人随手记录。
  • 会译:主打跨语言同传转写,中英混夹场景是它的卖点。

测试环境我尽量保持一致:同一间会议室,同一个全向麦克风,同一批测试音频,四款设备同时打开录音,再交给同一批评分员去核对。我没有用官方提供的测试音频,那种素材基本都是“干净得不像人类说话”的录音棚质量,拿那种素材测试没有任何参考意义。

2. 评测方法和标准:数据是怎么测出来的,哪些坑要先避

2.1 转写准确率必须用WER,不能用“大概准”

官方宣传页上的准确率,我劝大家看看就行。正规点的厂商会标注“在标准普通话、安静环境下”,但会议室哪有这么理想?所以这次评测我采用的是行业里通用的词错率WER(Word Error Rate)指标,计算公式是:

WER = (替换词数 + 删除词数 + 插入词数) / 参考文本总词数

举例来说,原话是“这个需求下周五之前完成”,工具转成了“这个需求下周五之后完成”,这里就产生了一个替换词,总词数是8,WER就是1/8=12.5%。如果它还漏掉一个词,删除词数增加,WER还会变差。

我在实际计算的时候写了个简单的Python脚本,用编辑距离去对齐参考稿和转写稿,省了不少人工统计的功夫:

from jiwer import wer reference = "这个需求下周五之前完成" hypothesis = "这个需求下周五之后完成" error_rate = wer(reference, hypothesis) print(f"WER: {error_rate:.2%}")

如果你要复现,建议对每段标准音频单独算WER,最后加权平均。直接拿一整场40分钟的会议算,容易因为音频太长导致误差被平均掉,看不出真实水平。

2.2 延迟、说话人分离、术语识别,怎么量化

除了WER,我额外测了三个维度,每个都有自己的一套测法:

  • 端到端延迟:播放一段有明确断句的秒表音源,然后用屏幕录制软件逐帧去查音频发声和字幕出现之间的间隔,测五次取中位数。
  • 说话人分离准确率:准备一段4人圆桌讨论音频,预先人工标注每一句话的说话人身份,再把工具输出的分段结果和人工标注做对比,算正确率。
  • 术语识别正确率:我准备了一份跟日常开发相关的20个专业词表,包括“灰度发布、数据埋点、接口幂等、消息队列、容器化、联调、断点、回归测试”这类团队黑话,看工具能不能在普通语句里准确还原。

这三个维度没有统一的行业标准,但都是我们真正开会时最痛的三个点。延迟太高,实时字幕就成了“字幕追着嘴跑”,干扰注意力;说话人分不清,纪要里就是一大团黑压压的文字,根本不知道谁表了态;术语翻车,干货会议记录直接变段子大会。

2.3 纪要可用性:主观评分也要有标准

转写工具最后好不好用,绝对不是看字转得准不准,而是看它给的纪要能不能直接用。这部分我用主观评分,但评的不是“喜不喜欢”,而是四个硬维度:

  • 结论覆盖度:会议里明确拍板的事有没有进纪要。
  • 决策上下文:谁提出的、因为什么定的、有没有背景信息。
  • 待办清晰程度:责任人、截止时间、交付物有没有被单独抽出来。
  • 风险与依赖:有没有主动标出那些“可能会延期”“依赖某人推进”的隐性风险。

评分员有四个人,每人独立打分,然后我去掉一个最高分和一个最低分取平均。主观题也要尽量做得像客观题,不然你根本说不出“这款比那款好在哪”。

3. 实测结果:四款产品的硬数据对比

3.1 常规周会模拟:普通话、5人轮流发言

第一场测试用的是我同事之前开周会录的音频——不是专业录音棚,就是普通会议室拿手机和全向麦录的。场景很典型:五个人轮流聊版本排期、bug修复进度、需求优先级,全程普通话,偶有几句口头禅,没人抢话。

四款产品用同一台音箱回放音频,同一个麦克风收音,测出来的数据如下:

产品平均WER端到端延迟说话人分离准确率纪要可用性评分
记刻12.6%2.3秒89%7.0
听灵4.2%0.8秒96.5%9.2
秒转18.7%1.5秒不支持4.5
会译15.1%2.8秒91%6.0

听灵在这个环节的优势就已经很明显了。它能准确分清五个人谁是谁,而且能识别出“某同学”和“某同事”这种脱离上下文很难判断的称呼;记刻的分离准确率其实不低,但问题是当两个人几乎同时开口的时候,它会默认把后面的内容甩给前一个人,导致“责任认领”错误。秒转连说话人分离都没有,出来就是一篇纯流水账,基本没法用。

3.2 需求评审:术语扎堆、中英混夹

第二场测试比较头疼——技术评审会。全程各种黑话狂飙,“网关”“接口幂等”“SDK”“QPS”“降级”“熔断”满天飞。这种会议最考验转写工具的领域适配能力,单纯普通话标准已经不够用了。

结果如下:

产品术语正确率典型错误示例
记刻77%“灰度发布” → “辉度发布”,“幂等” → “名单”
听灵98%全部识别正确,且能自动加粗术语
秒转62%“K8s” → “K八成”,“OKR” → “OK人”
会译85%“埋点” → “卖点”,“联调” → “链条”

秒转在这个环节基本属于“人类迷惑行为大赏”,把“灰度发布”转成“灰豆发布”的那一刻,连旁边做测试的同事都笑出了声。记刻和会译属于“勉强能猜它在说什么”的水平,但如果你直接拿转写稿去做会议纪要,还得手动改小半页术语。听灵可以自定义术语库,我提前把团队常用技术词导了进去,现场识别几乎零失误。

3.3 客户访谈:口音、语速、室内混响

最后一场测试没做内部会议,我模拟了一个客户访谈的录音:受访者有轻微方言口音,语速偏快,中途还习惯性吞音,背景有空调风声和偶尔的键盘声。

这场测试可以说是“翻车重灾区”。记刻的实时字幕明显开始跳词,一句话完整率大概只有七成;会译因为默认开启了多语言识别,反而容易把中文词鬼畜地映射成英文单词——“版本”被识别成“version”再转回中文,搞得整个文本中英混杂,看得很累。秒转更夸张,碰上带口音的长句直接静默,给出一段无意义的空字幕。

听灵虽然也做不到100%还原,但整体句子完整度保持住了,还是一句话可以读得通的水准。它还会智能把“嗯嗯啊啊”的口头禅滤掉,但又不会误删正常说话内容,这个度拿捏得刚刚好。

4. “真香款”深度体验:为什么听灵能甩开同行一条街

4.1 实时字幕:0.8秒延迟带来的舒适感

先说最直观的体验:延迟。听灵的实时字幕延迟我测出来是0.8秒左右,基本就是人可以近似无感的范畴。开会的时候眼睛扫一眼字幕,脑子能同步跟上说话人的节奏,不会出现“字幕都跑到下一句了,我还在反应上一句”的割裂感。

对比记刻的2.3秒和会译的2.8秒,差距不是数字大小的问题,而是心理感受的问题。延迟超过2秒以后,你的大脑会不断在两个时间轴之间来回切换:一边是真实的声音,一边是延迟的画面。开十分钟会你就会觉得累,自动想放弃看字幕。这种体验层面的差距,宣传页上的参数根本体现不出来。

4.2 动态说话人分离和会议画像

听灵让我最意外的还是动态说话人分离。它不只会在说话人切换的时候换一个头像标签,还能做到“当事人插嘴回应”时的准确归属。比如前面A在讲方案,B插了一句“这个思路我觉得可行”,听灵会把这句话正确划到B的名下,而不是糊涂地算到A身上。

这一点在实际会议里太重要了。需求评审会上经常是几个人你一句我一句互相补充,如果工具分不清每句话是谁说的,纪要里的“某人说”就是随机点名,责任归属直接混乱。听灵还会根据全场的说话时长和插话频次生成一个“会议参与画像”,谁是主讲、谁一直在沉默、谁频繁打断,一目了然。说句实话,这个功能我第一次见的时候以为是整活,用了几次才发现它对我的帮助是:散会之后我甚至不用回想,就知道该跟谁对一对确认意见。

4.3 纪要生成:从“会议记录”到“决策清单”

最能拉开体验差距的是会议结束后的自动纪要。听灵生成的纪要不是简单把说话人分段列出来,而是会自动整理成一份像人写的会议摘要:

  • 会议主题和背景:一上来就把会议目的写明白。
  • 关键讨论过程:用要点形式记录核心观点,并标注谁提出、谁补充。
  • 明确决策与结论:把“拍板”的内容单独摘出来,避免淹没在长篇对话里。
  • 待办事项清单:按优先级列出责任人、事项和截止时间。
  • 风险与依赖:自动识别对话里“如果……会延期”“依赖……才能推进”这类风险句式。

记刻其实也有类似的摘要模块,但生成出来的东西非常“模板化”,就是“本次会议讨论了……”“各方达成了一致意见……”这种正确的废话。听灵的纪要给我的感觉是写纪要的人真的坐在会议室里从头听到尾,知道讨论的重点在哪,也知道哪个细节不该漏掉。

4.4 部署与隐私:私有化、权限、审计一个不少

到了2026年,企业选会议工具已经不能只看功能好不好用了,数据安全是绕不开的硬门槛。听灵支持私有化部署,可以选择把音频和转写数据全部留在内网,音频文件加密策略、账号权限、导出审计日志也都可配置。我们做测试的时候专门试了一下,管理员可以强制开启水印,谁导出了纪要、导出过几次,后台都能查到。

记刻和会译虽然是背靠大厂的产品,但默认还是要走云端处理,这意味着会议音频会经过第三方服务器。如果你所在团队对会议内容比较敏感,光这一条就能劝退很多人。秒转倒是也有本地部署包,但功能直接被砍到只剩下“音字转写”,连说话人分离都没有,想要它承担正式会议记录的重任基本不可能。

4.5 价格模型:算一笔账看“真香”是不是真的香

最后说一下价格。四款产品的收费模式各不相同,我按团队常用规模折算了一下:

产品收费模式人均月度成本(约)是否支持私有化部署
记刻按坐席年费60元/人/月需额外定制
听灵按坐席年费98元/人/月支持
秒转按次数套餐15元/人/月(低频)部分版本
会译按分钟计费50元/人/月(高频)需商务沟通

如果你单看单价,听灵确实是最贵的那一个。但换个角度算一笔账:过去我们团队开完一次需求评审会,整理纪要至少要花一到两个小时,一个月下来光是会议纪要的人力成本就够把听灵的年度费用覆盖掉。更别说它还能自动生成待办清单和风险提醒,省掉的不只是打字时间,还有反反复复的确认沟通成本。所以我个人觉得,它这个“贵”其实还挺划算。

5. 实测中踩过的坑:会议室里的转写工具远没有想象中省心

5.1 麦克风位置能比算法更影响结果

转写工具再强,收音不行一切都白搭。我第一轮测试的时候把全向麦克风放在会议桌的一角,结果所有产品的WER都大幅飙升,听灵也没有幸免。同一个设备,同一个会议室,只是把麦克风从桌角挪到桌子正中央,听灵的WER直接从5.1%降到了4.2%。

后来我还专门做了一组对照实验:

麦克风位置听灵WER记刻WER
桌子角落5.1%13.4%
桌子正中央4.2%12.6%
靠近空调出风口6.8%16.2%

结论就一句话:如果收音条件差,先别急着怪工具识别能力不行,把麦克风放到会议桌正中央、远离空调和风扇,是最便宜也最有效的提升手段。

5.2 联动场景差:从手机录音、离线导出、接口生态

测试过程中我还发现一个很现实的痛点:开会不总在会议室里。临时在茶水间站着开个小会,或者坐地铁的时候拉一个电话会,你根本不可能带着全向麦克风。这时候手机端的录音质量就决定了工具的发挥空间。

听灵的手机端会自动把录音降噪和语音增强做一遍预处理,转录结果相对稳定;记刻的手机端则基本是“裸奔”,你把手机放在桌上,序里写,别指望转写工具能读懂人心。正式会议建议用专业级设备,临时讨论用手机也尽量让设备正对说话人的嘴部。

5.3 免费版 vs 付费版,差的不只是次数

四款产品里,秒转和记刻都有免费档,但免费档的体验我只能说“能转字,不能用”。秒转免费版没有说话人分离,也拿不到结构化纪要,一个月还有60分钟的时长限制。记刻免费版延迟更长,识别率也没有明显优势,最要命的是它会把关键词识别“阉割”——你明明在聊“灰度发布”,它非要转成“辉度发布”,而且你还没有权限修改术语库。

免费工具适合什么场景呢?我个人觉得适合个人灵感速记,比如电话采访、碎片化想法捕捉,这类场景不需要区分说话人,也不需要结构化纪要,能用就行。但如果是正式项目会议、客户访谈、跨部门对齐会,我还是建议别省这个钱,因为整理一份烂纪要的时间成本,比订阅费贵多了。

6. 常见问题速查表:转写工具的排查与调优

6.1 为什么转写老是漏字、乱码?

如果你发现工具的转写结果频频出问题,按下面这个顺序逐个排查,基本能覆盖九成以上的情况:

  • 网络状况:云端转写对网络质量敏感,如果公司网络不稳定,优先考虑私有化部署版本。
  • 收音环境:麦克风离说话人超过两米、桌面有回音、空调声过大,识别率都会暴跌。
  • 术语库:默认词表里没有你们的黑话,必须先导入自定义术语库。
  • 口音与方言:如果普通话不标准,开启“方言增强”选项或让工具多学几段你们团队的录音。
  • 同音词:人名、地名、产品代号最容易翻车,提前在词库里加拼音纠错。

6.2 怎么让工具听懂你们团队的“黑话”

团队黑话这种东西,通用模型永远不可能百分百听懂,但大部分专业工具都支持自定义词库。以听灵为例,管理员可以直接在后台把常用术语、产品代号、英文缩写、人名批量导入,有些工具还支持上传一段历史录音让模型自动学习。

我的建议是:别光把词库丢进去就完事。还应该给每个词配上拼音或常见同音字纠错。比如你团队常说的某个内部系统代号,如果不告诉它“可以读作某某”,它照样可能转成音近字。词库维护是一个持续的过程,开了一次会后顺手把新出现的黑话加进去,久而久之准确率会稳定在很高的水平。

6.3 转写完成之后,纪要怎么处理才能用

很多团队把工具生成的纪要直接丢进群里,效果基本等于没做。正确的处理流程是“三查一补”:先查人名的甲方乙方调换、再查数字和日期有没有误差、最后查术语是不是被替换过;补则是把工具漏掉的重要讨论补回纪要里。这一步看起来很费事,但每次花五分钟,就能保证发出去的纪要不丢人,也能培养团队对工具的信任感。

我自己的习惯是搭配其他工具做二次处理:听灵导出带待办标记的Markdown,我再在本地用脚本把待办事项自动拆成一条条任务,同步到项目管理系统里。这样从会议结束到任务生成,全过程基本能控制在十分钟内。

7. 写在最后的测试心得

这次做了三周实测之后,我最想说的一句话是:别拿官方宣传当参考。宣传页上那句“准确率98%”,永远是在最干净的录音棚、最标准的普通话、最正常的讨论节奏下跑出来的。你拿自己的会议室、自己的同事、自己的行业术语去测,才是决定买不买的唯一标准。

如果让我直接给结论,我会说:预算允许、团队对会议纪要质量有要求,直接上听灵这种专业级工具;预算紧张或者开会频率很低,先定好麦克风位置、规范会议环境,哪怕用免费工具也比瞎买强。

最后再分享一个实测小技巧:选测试音频的时候,别挑那段最清晰的团队宣传片,一定要用你们日常开会时最能“霍霍人”的那间房、最嘈杂的那段时间录的音频。谁能在这种环境下稳住,才是真的稳。

相关新闻

Spring Boot集成Motan RPC框架实战指南:从入门到排障

Spring Boot集成Motan RPC框架实战指南:从入门到排障

聊一聊Spring Boot和Motan这套组合。Motan是我这几年做微服务拆分时用得相当顺手的一套RPC框架,不像有些框架那样配置繁琐到劝退,也不像轻量到只适合玩具项目。如果你正打算在Spring Boot项目里引入RPC调用,或者在Dubbo、Feign、Motan之间纠结…

2026/10/20 8:15:31 阅读更多 →
智能代理系统安全响应演练实录:从告警到改进的完整复盘

智能代理系统安全响应演练实录:从告警到改进的完整复盘

很多团队都有过这样的矛盾:安全预案写了厚厚一叠,告警规则也配了一堆,但真正出问题的时候,大家还是手忙脚乱。文档里写着“发现异常立即上报”,没人告诉你异常长什么样;群里弹了告警,值班的人看…

2026/10/20 8:15:31 阅读更多 →
RAG面试高频考点全解析:从检索到生成的优化链路

RAG面试高频考点全解析:从检索到生成的优化链路

1. 为什么面试官揪着RAG不放:先把这个动机吃透我最近在系统梳理大模型方向的面试题,RAG(Retrieval-Augmented Generation,检索增强生成)几乎是每家必问的模块。尤其是做应用层项目的岗位,RAG的提问密度比微…

2026/10/20 8:14:30 阅读更多 →

最新新闻

CODE V数码相机镜头设计:从规格约束到公差分析全流程

CODE V数码相机镜头设计:从规格约束到公差分析全流程

简介:资源围绕CODE V软件设计数码相机镜头的完整流程展开,面向光学设计入门者及需要了解镜头规格、优化指标的工程师。文档从一台定焦VGA数码相机的设计规格出发,详细讲解了像面尺寸、像素大小、焦距、视场角等关键参数,并说明如何…

2026/10/20 9:02:37 阅读更多 →
M实验室与C公司深度适配:推理框架与算子优化的生态拐点

M实验室与C公司深度适配:推理框架与算子优化的生态拐点

这周几个技术群的讨论热度,几乎都集中在一条生态合作消息上:以开源推理模型出名的M实验室,和做AI处理器、服务器与基础计算平台起家的C公司,官宣在推理框架、算子优化、开发者工具三个层面做了深度适配。圈子里有人直接说&#xf…

2026/10/20 9:02:37 阅读更多 →
C语言switch case用法详解:从if-else嵌套到状态机与跳转表优化

C语言switch case用法详解:从if-else嵌套到状态机与跳转表优化

刚接触C语言的同学,十个里有八个会被if-else连环嵌套折磨到眼晕。特别是当你辛辛苦苦写了七八层判断,回头一看代码缩进都快到屏幕右边缘了,那种心情我太懂了。其实C语言早就给了你一个处理"多选一"场景的利器——switch case语句。…

2026/10/20 9:02:37 阅读更多 →
中小规模ASR私有化部署:从10路到50路的硬件配置与全链路优化

中小规模ASR私有化部署:从10路到50路的硬件配置与全链路优化

1. 这不是买服务器,而是给语音识别系统“搭舞台”——中小规模ASR私有化部署的真实逻辑你搜“10路、30路、50路实时语音识别怎么配服务器”,说明你已经跨过了“要不要上ASR”的决策门槛,正站在工程落地的门口:手上有真实业务场景—…

2026/10/20 9:02:37 阅读更多 →
2026年Agent元年:大模型应用开发从提示词工程到工程化落地

2026年Agent元年:大模型应用开发从提示词工程到工程化落地

说实话,这两年经常被问到同一个问题:2026年才开始学AI大模型开发,会不会太晚了?我的答案通常是反着来的——真正该担心晚的,不是“会不会调接口”,而是“能不能把一个Agent从PPT做到生产环境”。如果你只是…

2026/10/20 9:02:37 阅读更多 →
Protege进阶:推理机、SWRL与SPARQL从入门到避坑

Protege进阶:推理机、SWRL与SPARQL从入门到避坑

简介:面向已经掌握Protege基础操作和推理验证的读者,这份进阶教程以动物园本体构建为贯穿案例,围绕个体编辑、数据属性(datatype property)和对象属性(如Belonging)设定展开,详细演示…

2026/10/20 9:01:37 阅读更多 →

日新闻

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/20 2:50:50 阅读更多 →

月新闻

我发现了一个新思路:用 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 阅读更多 →