2026外呼系统选型指南:AI机器人、人机协同与部署模式全解析
做企业通信和客户触达这块年头不算短了几乎每隔一段时间就会被问到同一个问题外呼系统到底怎么选尤其是到了2026年这个节点AI机器人越来越成熟呼叫中心也从“纯人力”变成了“人机混合”再加上本地部署、云端部署、混合部署这些选项很多团队在选型时不是嫌功能不够而是被选项本身搞晕了。这篇文章我不打算做那种罗列产品参数的“说明书式测评”而是从一次完整的选型视角出发把AI机器人、人工呼叫中心、不同部署模式的底层逻辑和实操要点一次讲清楚。不管你是自己创业的小团队还是在公司里负责通信系统选型的人这篇文章都会比你看一天厂商演示更有价值。1. 先把外呼系统的底子摸清核心构成与选型逻辑很多人在选外呼系统时第一反应是看厂商的功能清单。这个方向没错但有个问题外呼系统的功能清单动辄几十项看起来都差不多真正拉开差距的往往藏在底层架构和策略细节里。1.1 一套外呼系统拆开看只有这四块不管产品叫什么名字、界面多花哨一套能跑起来的外呼系统本质上就是四层结构拼在一起。第一层是线路接入层。这是外呼系统的“血管”决定了你能不能把电话打出去、打出去的音质怎么样。常见的线路形态包括SIP中继、固话线路、行业短号线路等不同线路在并发能力、外显号码、接通率上有明显差异。选型时别只看报价要重点问清楚线路的归属是谁、有没有冗余备份、出故障时多久能恢复。第二层是通信平台层也就是软交换、ACD自动话务分配、IVR交互式语音应答、录音和质检模块。这一层的好坏直接决定通话稳定性。我见过很多团队在选型时只关注AI功能结果上线后发现通话频繁断线、录音文件丢失再调就非常被动。第三层是智能化层。现在主流外呼系统都会带AI能力包括ASR语音识别、TTS语音合成、意图识别、对话管理、情绪识别等模块。严格来说这一层不是外呼系统的必需项但它决定了系统的“上限”——同样是外呼纯人工是一条路AI辅助人是一条路AI全自动又是一条路。第四层是业务应用层包括CRM客户关系管理集成、任务导入、自动外呼策略、号码状态管理、数据报表、坐席工作台等。这一层是使用体验的核心也是交付时最容易产生扯皮的地方。四层结构捋下来你会发现外呼系统的选型不是“挑一个软件”而是“搭一套体系”。体系里任何一块短板都会在实际业务中变成成本。1.2 你的业务场景决定选型边界搞清楚底层结构之后下一步是用业务场景来给选型划边界。这不是空话直接决定你该把钱花在哪个环节。场景一以新客开发为主的电销团队。这类场景的核心痛点是号码量巨大、有效线索比例低需要系统具备高频外呼能力和高效的号码筛选机制。AI机器人在这类场景的价值最大可以先用AI完成初步筛选把有效意向客户再转给人工坐席深聊。场景二以存量客户运营为主的服务型团队比如回访、满意度调查、续费提醒。这类场景对通话质量的稳定性要求高对投诉率非常敏感AI机器人适合做简单通知类任务但涉及客户情绪安抚和复杂问题解释时还是要人工介入。场景三线下门店或本地生活类企业的预约确认。这类场景单次通话时间短、话术固定AI机器人外呼完全可以扛住关键是系统能否和门店的日程系统做对接。场景四呼叫中心外包或客服团队业务量随季节波动大。这类团队需要的是强大的坐席管理能力和动态扩容能力部署模式上云端方案明显更有优势。四个场景走下来你会发现选型的真正起点不是“哪家产品好”而是“你的业务更依赖效率还是更依赖质量”。效率优先AI和自动化的比重就要加大质量优先坐席能力、CRM集成和合规能力就要优先保障。2. 三种外呼形态深度测评AI机器人、人工呼叫中心、人机协同2026年的外呼市场上几乎没有“纯人工”或“纯AI”的单选答案更多的是三种形态的组合。为了方便对比我把它们拆开了说但在实际选型中建议把它们放在一起看。2.1 AI机器人外呼效率高但不是万能AI机器人外呼的核心价值就一个字快。一台AI并发外呼的吞吐量大概相当于几十个坐席同时拨号。而且它可以24小时不间断运行不受情绪、疲劳影响。如果你业务的核心诉求是“用最低成本把海量号码洗一遍”AI外呼几乎是目前的最优解。但这里我必须泼一盆冷水AI外呼在2026年依然有明显的边界。第一个边界是识别能力。虽然现在的ASR在普通话场景下识别准确率已经很高了但遇到方言、口音、背景噪音复杂的电话识别率会明显下降。你不能拿厂商演示时的“标准普通话测试”来评估真实场景。第二个边界是对话“兜底”能力。AI机器人在对话中一旦遇到预期外的回答比如客户反问、抱怨、情绪激动很多系统的应对都很生硬。这背后是意图识别和对话管理的能力差距你在测试时要专门拿各种“刁钻问题”去试。第三个边界是合规风险。AI外呼因为拨打量巨大一旦号码来源不规范、投诉处理不及时就容易带来严重的合规问题。这一点后面单独展开但你在选型时必须记住AI的数量优势必须建立在严格的外呼策略之上。2.2 人工坐席呼叫中心质量稳但成本天花板明显人工坐席呼叫中心已经是一个非常成熟的领域了核心功能无非是坐席工作台、自动外呼分配、监控管理、录音质检等。它的优势在于对话质量高、应变能力强、客户体验好特别适合高客单价产品或复杂售前售后场景。但人工呼叫中心的问题也很现实成本天花板。一个坐席的工资、场地、设备、培训、管理成本加在一起乘以坐席数量这是一笔不小的开销。而且人员的流动率在外呼行业里普遍偏高对管理的考验也相当大。另外一个容易被低估的问题是“拨号等待时间”的浪费。人工外呼时坐席每天要花费大量时间在拨号、等待接通、听忙音上。真正有效的通话时长可能只占工作时间的30%-50%。所以现在主流系统都加入了预测式外呼或自动拨号外呼机制让坐席只接已接通或振铃有效的话务把等待时间压下来。如果你打算上人工呼叫中心建议重点看三个能力坐席工作台是否够顺手、质检与培训工具是否完善、后台报表是否真实可靠。2.3 人机协同我眼中最值得关注的组合方式如果你关注外呼行业趋势会发现2026年的关键词已经不是“谁能代替谁”而是“如何协同”。AI负责干脏活累活人工负责干精细活。这套打法最常见的形态是“AI筛客人工承接”AI先完成第一轮外呼把无效号码、拒接、未接通全部过滤掉把有意向的客户直接转接给人工坐席。坐席接到的每一个电话都已经带着AI记录的标签和对话摘要可以直奔主题效率非常可观。另一种形态是“AI辅助人工”人工坐席与客户通话时AI实时识别对话内容并给出话术建议、客户意向评分、订单信息匹配通话结束后自动生成小结并同步CRM。做选型测评时我强烈建议你把“人机协同”作为默认对标方案而不是单测某一项功能。判断标准很简单AI能精准到什么程度转给人人工能借助AI把效率提升多少。3. 部署模式怎么选本地、公有云、混合部署的对比与建议部署模式这部分是很多企业选型时忽略的重头戏。因为表面上功能都一样但部署模式决定了后期的运维成本、扩展弹性、数据安全性、故障响应速度。3.1 三种部署模式到底差在哪本地部署也就是把整套系统装在自己公司机房或服务器上。它的优势是数据完全由自己掌控内网通信时延低与外部的CRM等系统集成调度起来灵活。但它的问题在于前期投入大——服务器、语音网关、中继线路、专业运维人员一个都不能少扩容也麻烦业务量翻倍时你得加设备高峰期过去设备又闲置了。公有云SaaS部署就是厂商把系统放在云端你按坐席数或按通话量付费。它最大的优势是轻资产开通账号就能用扩容缩容都很方便非常适合业务量波动大、IT人力稀缺的团队。劣势是数据不在自己手上虽然主流厂商都承诺数据加密与隔离但依然有不少大企业对合规审计比较敏感。混合部署比如外呼控制与坐席系统云端部署录音与数据落本地或者业务应用在本地线路和AI能力走云端。这种方案听起来复杂但对于规模型企业来说往往是最务实的选择。既能享受云端的AI能力和弹性又能把核心数据留在本地。三种部署模式放在一起对比会更直观对比维度本地部署公有云SaaS混合部署前期投入高低中高扩容便利性差好较好数据掌控力高低中高运维复杂度高低中AI能力获取较慢需要自建快速快速且可控适合场景大型企业、数据敏感型中小团队、弹性业务中型以上的稳定业务3.2 不同规模企业的选型建议我接触过一个做本地生活服务的创业团队当时他们人数不到20人选型时差点花了不少钱去自建一套呼叫中心。聊完之后我劝住了理由很简单他们最大的需求是预约提醒和售前咨询业务量波动又大公有云按量付费的方式对他们来说压力最小。果然后来他们的业务量翻了两倍系统加坐席数分钟就能解决完全不操心扩容的事。反过来我也接触过一个规模不小的金融类机构。他们的数据安全要求极高很多客户数据不允许离开本地网络核心系统里又有大量定制化需求这种情况下公有云SaaS就明显不适用了。让他们接受本地部署加定制开发虽然前期慢一点但后面长期稳定。还有一类比较典型的混合部署案例来自一个规模不小的连锁服务品牌。他们把呼叫中心坐席平台放在云端但录音和客户台账数据走本地存储AI外呼能力则调用云端的算力来跑。这样既避免了重复搭建AI基础设施又保住了客户数据的本地化诉求。这套组合用下来运营团队省了心IT团队也放心。说到底部署模式的选择可以和功能需求无关但一定和企业的数据态度、IT能力、预算体量强相关。4. 功能清单与关键指标测评别被演示效果带偏了这一部分聊点最实操的。选型测评的时候厂商的演示往往只展示光鲜一面但对你真正有价值的是把关键功能和指标逐个压测一遍。4.1 必测的核心功能清单不管厂商吹得再天花乱坠有几项基础能力建议单独拆出来测试。外呼频率与并发策略是否可控系统能不能按小时、按坐席、按线路设置拨打上限能不能根据号码状态自动调整频率。这项能力直接关系到线路稳定性和投诉风险不能只看“支持定时外呼”这种模糊描述。自动外呼分配策略是否灵活包括预测式外呼的算法、坐席空闲判断的准确度、客户优先级的排队逻辑。这一项需要现场用模拟话务去压测不能只听介绍。通话录音与质检是否闭环录音能不能按时生成、能不能自动转写、质检规则是否可配置甚至能不能做到全程无人工介入的自动质检对你的管理成本影响很大。CRM集成能力是否够深这里的“够深”不是指能不能导入Excel而是能不能和你的现有系统做接口级对接比如客户资料弹屏、通话记录回写、工单自动创建等。号码状态管理是否精细包括空号检测、停机状态识别、拒接状态标记、投诉号码锁定以及黑白名单机制。这些颗粒度细节往往决定你后面会不会莫名其妙被人骂骚扰电话。4.2 接通率、投诉率、转人工率怎么科学解读选型测评时我会特别看重三类指标接通率、投诉率、转人工率。但每一类指标都要会科学看不能只看绝对值。接通率是最容易被误解的。同一批号码不同线路、不同外显号码、不同拨打时段结果可能差很多。更合理的做法是让厂商做一个“同号码池、同时段、不同线路”的A/B测试才能比较公平地看线路质量。另外要注意接通率是“呼叫接通数/外呼总数”还是“有效接通数/应答总数”统计口径不同数字相差会很大。投诉率则是观察红线指标。评测投诉率时要重点问清楚投诉的定义和统计周期是官方渠道受理的投诉还是用户标记接听为骚扰电话也算投诉后的处理流程是什么号码多久会被冻结这个指标无法完全归零但一个具备“早发现、早处置、可申诉”能力的系统能把风险控制在非常低的水位。转人工率是人机协同方案里最核心的指标之一。判断一个AI外呼系统是否“聪明”不是看它自动对话能撑多久而是看它该转人的时候能不能精准判断。评测时别只看平均转接率要分场景看——高意向客户转接成功了多少、低意向客户有没有误转。真正能把“想买的人和不想买的人”分清楚AI才算合格。当然还有一类容易被忽略的后台指标数据报表的准确性。很多厂商前台功能演示得很漂亮但后台数据导出来一对比通话时长、状态标签、坐席工单全对不上。选型时务必抽一段真实业务数据进行完整性核对。4.3 合规能力如何做真实性测评外呼合规在2026年已经不是一个可选项而是必答题。合规能力的测评建议把它当成一个“问题清单”来提问而不是看厂商宣传页上的承诺。比如系统是否内置了多维度号码状态检测比如对高频拨打量、投诉倾向号码的自动预警系统是否能对被标记或投诉的号码实行阻断策略系统的外呼话术是否符合可回溯、可审计的要求有没有完整的通话记录和操作日志系统是否支持用户退订/拒收选项的自动登记并在后续外呼中自动过滤掉这类用户以上这些不一定都需要最贵的系统才能实现但你必须让厂商逐条签字确认。否则后续出了问题吃亏的几乎一定是企业自己。另外多提一下质检策略的配置能力。我之前见过某团队上线外呼系统后质检规则绑定了整条话术的“绝对合规”只要坐席对话里和标准话术稍微不一致就会被判定命中结果一个月下来质检合格率不到60%管理团队非常被动。后来把规则改成关键词与意图双维度检测才把情况理顺。这个案例说明合规能力不是越严格越好而是要能灵活适配真实业务场景。5. 实操踩坑实录选型过程中的问题与排查技巧前面把原理和方法论讲得差不多了这个部分专门说说我在实际选型、上线过程中遇到的坑和对应的处理方式。这些东西平时基本不会写在选型需求书里但对结果影响非常大。5.1 我整理的一套标准选型流程如果你正面临一次外呼系统选型我建议你按照下面这套流程来跑可以少走很多弯路。第一步明确自身需求边界。用一张表把自己最看重的3个核心场景列出来并标出场景是效率敏感还是质量敏感这决定了后续评估的权重。第二步圈定3家左右的意向厂商。不要一上来就海选先看功能是否匹配、部署模式是否适配、大概的预算水位在哪里。然后再让厂商分别做深度演示。第三步做同场景的POC对比测试。这是最重要的一步。给每家厂商相同的号码池和话术脚本让他们在真实环境中跑出指标来。不要只拿厂商给的“样板数据”做判断。第四步专项核查合规与线路能力。这一步需要单独安排时间厂商的销售不一定了解位最好把他们的技术工程师拉进来逐条澄清合规机制、线路容灾方案、投诉处理流程。第五步合同阶段确认SLA服务等级协议。包括接通率、可用性、响应时间、故障恢复时间等最好都写进合同和附件里并明确赔偿条款边界。整个流程跑下来通常要两三周但换来的稳妥比那些急着上线、后期天天救火的团队要值太多。5.2 常见问题与排查速查表在实际选型、压测、上线的过程中我遇到过不少典型问题这里整理成一张速查表方便你对照排查常见问题可能原因排查与解决建议接通率突然下降外显号码被标记、拨打时段不佳、线路质量波动更换备用线路调整外显号码分时段统计拐点外呼号码被大量标记为骚扰拨打频次过高、号码来源不清、缺乏投诉处理机制降低单号码拨打上限补充号码清洗环节加强退订策略AI机器人答非所问意图识别规则过窄、测试语料不贴合真实场景换用真实录音转写文本训练适当放宽意图匹配阈值坐席外呼时大量无效等待预测式外呼算法不精准、坐席状态同步延迟定期校准算法参数检查客户端网络延迟录音文件偶发缺失存储空间不足、并发录音导致的文件写入竞争拆分录音存储目录配置自动转存与完整性校验数据报表与通话记录不一致后台统计口径不同、数据同步任务失败核对任务日志统一统计口径另作抽检比对这张表看起来零散但每一条背后都是真实业务里反复出现过的场景。选型时把这些做成“压测问题”能帮你筛掉很多水分较大的产品。5.3 三个容易被忽略的细节最后再分享三个细节。它们不像核心功能那样显眼但在实际使用中影响很大。第一个是外呼号码的归属地与业务匹配。很多系统支持多归属地号码轮播但号码归属地和业务区域不匹配时客户接听意愿会明显下降。上线前一定要梳理你业务覆盖的地域范围把号码归属地的匹配规则提前定好避免全国一个号码打到哪都行。第二个是异常话务的实时监控。外呼系统上线后至少要保留一个“实时看板”视角能够一眼看到当前有多少号码在拨打、正在通话中、处于拒接状态。很多系统都有这个功能但使用率不高。我在实操中发现实时看板的价值不只是监控更是快速发现线路故障与话术问题的哨兵别等客户投诉了才发现异常。第三个是厂商的售后响应机制。选型时你可以故意在一个非工作时间段提交一个技术问题看看对方多久能响应、回答是否专业。这一点虽然不写在合同里但往往比任何演示都更能反映真实的服务水平。我踩过不少售后响应慢的坑后来把这个测试当成固定动作节省了大量时间。最后再聊几句实在话做了这么多年通信方案我最直观的感受是外呼系统选型不像买手机不是参数越高越好而是越匹配越好。你得先想清楚自己是要扫量还是养客再决定AI的比重、人工的配置以及数据放在云端还是本地。没有一套系统能解决所有问题但一套想清楚再选的系统可以帮你省掉后面两年的大部分烦恼。2026年的外呼市场AI能力已经不再是稀缺资源真正稀缺的是把AI、人工、线路、数据、合规这几块拼图拼得严丝合缝的组合能力。选型时多花点时间做真实对比测试比看任何评测文章和演示都管用。希望这篇从实操里整理出来的指南能帮你少踩一些坑把预算花在真正有价值的地方。

相关新闻

手把手教你用C语言自己实现popen/pclose:原理、代码与踩坑

手把手教你用C语言自己实现popen/pclose:原理、代码与踩坑

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

2026/10/17 3:09:45 阅读更多 →
CSRF攻击完全指南:原理、复现与防御方案详解

CSRF攻击完全指南:原理、复现与防御方案详解

先还原一个具体场景。某天下午,A同学登录了一个购物网站,浏览完商品后随手关掉了页面,没有退出登录。接着他去逛论坛,点开了一个帖子里附带的图片,图片转圈很久也没加载出来,他也没当回事。第二天再登录购物…

2026/10/17 3:09:45 阅读更多 →
手算U-Net:用PyTorch从零实现编码器、解码器与跳跃连接

手算U-Net:用PyTorch从零实现编码器、解码器与跳跃连接

这几年和不少同学、同行聊U-Net,大家普遍都经历过同一个阶段:代码从 GitHub 上拷下来能跑,验证集的 Dice 分数还挺好看,但不会被提问“编码器里为什么每层都套两个卷积”“跳跃连接真的拿掉会怎样”“一张 512512 的图过完最底层分…

2026/10/17 3:08:45 阅读更多 →

最新新闻

生成式AI知识折旧快?用“过时指南”视角沉淀不变的技术骨架

生成式AI知识折旧快?用“过时指南”视角沉淀不变的技术骨架

前阵子清理电脑里的旧笔记,翻到一份2023年初写的生成式AI入门文档。当时费了很大力气整理,把当时主流的模型架构、prompt写法、参数调优经验都写得清清楚楚。时隔一年多再看,里面至少三分之二内容已经不能直接用了——有的模型被新版本替代&a…

2026/10/17 3:51:57 阅读更多 →
5V3M加湿器原理图设计:电源保护、3MHz谐振驱动与安规隔离全解析

5V3M加湿器原理图设计:电源保护、3MHz谐振驱动与安规隔离全解析

简介:本资源是一份面向电子设计初学者与硬件开发者的5V3M便携式加湿器完整电路原理图,聚焦雾化控制、人机交互与EMC合规设计等典型嵌入式应用实践。资料以PDF形式呈现全部电路设计细节,共1个文件(132KB),涵…

2026/10/17 3:51:57 阅读更多 →
MySQL索引优化实战:从慢查询到高效索引设计

MySQL索引优化实战:从慢查询到高效索引设计

去年年底帮一个业务团队排查线上数据库抖动,问题不复杂但很典型:某张几千万行的订单表,一个列表查询接口从平均80毫秒慢慢涨到了1.2秒,数据库CPU一度冲到90%。慢SQL捞出来一看,全表扫描,连索引都没走到。这…

2026/10/17 3:51:57 阅读更多 →
图像质量评价经典算法代码复现:BRISQUE、RankIQA与NIMA实战指南

图像质量评价经典算法代码复现:BRISQUE、RankIQA与NIMA实战指南

简介:这份资源面向图像处理方向的学习者与开发者,系统整理了图像质量评价领域的经典算法代码实现,涵盖BRISQUE、RankIQA、NIMA等代表性方法,可用于监控视频传输质量评估、图像压缩与增强算法效果验证、医疗影像分析等需要量化图像…

2026/10/17 3:51:57 阅读更多 →
Docker部署Elasticsearch:从启动命令到稳定运行的完整指南

Docker部署Elasticsearch:从启动命令到稳定运行的完整指南

你如果只在网上搜docker run -d -p 9200:9200 elasticsearch,照着一帖,大概率能启动,但能不能用就是另一回事了。我见过太多同事卡在“容器起来了但日志疯狂报错”“elastic账号密码是什么”这类问题上,还有更糟的——起来之后一写…

2026/10/17 3:51:57 阅读更多 →
TraceVIC:用因果推理定位漏洞诱导型提交

TraceVIC:用因果推理定位漏洞诱导型提交

1. 这不是又一个“git blame”工具——TraceVIC到底在解决什么真问题?你有没有遇到过这样的场景:线上服务突然爆出一个高危漏洞,安全团队火速拉群,SRE盯着告警面板手心冒汗,开发组长翻着最近三天的提交记录头皮发麻。大…

2026/10/17 3:50:57 阅读更多 →

日新闻

DeepSeek选型与部署:V3/R1、Ollama、API全攻略

DeepSeek选型与部署:V3/R1、Ollama、API全攻略

简介:《DeepSeek使用方法.pdf》是一份面向DeepSeek入门及进阶用户的完整使用指南,重点围绕V3与R1两款模型的能力差异与适用场景展开,帮助读者根据任务类型与成本选择合适的模型。资源共1个PDF文件,压缩包大小约311KB,篇…

2026/10/17 0:00:25 阅读更多 →
200+Deepseek润色指令拆解:从底层原理到场景落地的完整指南

200+Deepseek润色指令拆解:从底层原理到场景落地的完整指南

简介:这是一份聚焦DeepSeek提示词优化的《200Deepseek润色指令》PDF文档,共收录两百余条可直接套用的润色指令,涵盖语法修正、风格统一、逻辑梳理、表达精炼等维度,并针对商务写作、学术论文、广告文案等场景给出差异化建议。文档…

2026/10/17 0:00:25 阅读更多 →
OpenCV轮廓法物体计数系统:轻量、可控、可落地的工业级实现

OpenCV轮廓法物体计数系统:轻量、可控、可落地的工业级实现

简介:本资源是一份基于OpenCV的本科课程设计完整报告,面向计算机视觉初学者、图像处理学习者及高校通信/信息类专业学生,解决物体智能计数与检测结果结构化记录的实际问题。项目覆盖图像预处理、轮廓检测、边界框绘制、轨迹栏交互式参数调节、…

2026/10/17 0:00:25 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/16 21:35:51 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/17 1:44:59 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/16 15:04:24 阅读更多 →

月新闻

我发现了一个新思路:用 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/16 21:54:38 阅读更多 →
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/16 3:49:43 阅读更多 →
黑夜航拍船只数据集训练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/16 14:23:36 阅读更多 →