多维防御架构应对Quishing:关键基础设施二维码钓鱼攻击剖析

最近在针对某水务集团、某电力研究院的一轮混合红队演练里,我手里最“土”的工具——一张打印出来的二维码贴纸——居然比十几个CVE利用都好使。这让我重新审视了一个越来越危险的攻击面:Quishing,也就是QR二维码钓鱼攻击。它不打破任何软件漏洞,不需要高超的免杀技巧,只需要让目标人把手机摄像头对准一张图片,然后指尖一点。对于关键基础设施(电力、水务、燃气、轨道交通)来说,Quishing正在成为绕过重重边界防护的“物理-数字”混合突破口。这篇文章,我就把自己从攻击者视角和防守者视角分别踩过的坑、验证过的对抗手段,以及一套可落地的多维防御架构整理出来。内容适合负责工控安全、企业安全运营的工程师,以及被要求“做好二维码风险管控”但不知从何下手的同行参考。

1. 攻击向量分析:Quishing为什么总在关键设施里得手

1.1 恶意二维码的生成与投递方式

人人都能靠在线工具生成二维码,但它作为攻击载荷的可怕之处在于:二维码承载的不是明文网址,而是一个编码后的数据块。大多数手机相机的默认行为是“识别出URL后弹出预览”,用户会在未经任何安全校验的情况下,看到一个看起来正常的域名,然后点击。攻击者可以轻易做到:

  • 将钓鱼URL编码进二维码,并通过短链接或URL重定向隐藏真实地址。
  • 在二维码中嵌入带用户标识的恶意链接,实现动态令牌或按目标定制。
  • 生成QR码图片,以PDF附件、桌面壁纸、打印贴纸、甚至电子屏幕滚动播放的形式投递。

实际投递方式可以分为四类,这也是我们做防御拆解时最关心的分类维度:

投递方式场景威胁特点
物理张贴替换停车场扫码缴费、访客登记台、设备巡检标签、食堂餐牌替换真实二维码,目标群体明确,隐蔽性高
邮件附件伪造IT服务台的“设备二维码绑定”、伪造HR工资单查询二维码绕过了基于内容的邮件过滤,因为图片很难做语义判断
即时通讯/协同软件群聊里发“会议签到二维码”“场所码更新”借助内部信任链传播,传播路径短平快
移动网页/社交工程配合热点事件诱导扫码(如“员工福利登记”)制造紧迫感,降低警惕性

我记得在某电力企业的现场测试中,我们打印了50张伪装成“访客无线上网登记”的二维码,贴在门禁旁的公告栏。一个上午,就有37次成功扫描。这个成功率是邮件钓鱼的三倍,因为它完全绕开了“审查链接”这一步——手机相机的扫码动作本身就被用户默认为“安全”。

1.2 关键基础设施场景下的典型入侵路径

关键基础设施与普通企业最大的差异,是IT网络与OT网络之间的强隔离。大量攻击者卡在IT边界进不去,但Quishing提供了另一条路:通过操作员或维护人员的移动设备进入内部。一次典型的攻击路径如下:

  1. 攻击者制作二维码,指向一个仿冒的“内部设备报修系统”登录页。
  2. 目标员工扫码后看到高仿登录界面,输入域账号和密码。
  3. 攻击者拿到凭据,通过远程桌面、虚拟专用网络网关或Web门户进入办公网。
  4. 横向移动到支持OT系统的跳板机,再通过受控的工程工作站访问只能从特定位置触达的PLC维护接口。

这个过程中的关键点在于:二维码钓鱼从来不直接攻破工业协议,它只是“递钥匙”的人。钥匙就是凭据。很多关键基础设施单位把安全预算都花在工业防火墙和主机加固上,却忽略了大量第三方运维人员、外包保洁、承包商都需要通过手机扫码进出关键区域。一台个人手机一旦被植入恶意配置或诱导安装App,它就可能变成穿透物理隔离的“移动跳板”。

1.3 为什么传统网络防御抓不到Quishing

传统邮件网关会检查邮件正文里的URL,沙箱会打开附件里的文档,但二维码图片在URL扫描型安全产品看来就是一张普通图片。只要不调用OCR和解码模块,它就是个无害的BMP/JPEG/PNG。更麻烦的是,即使解码出了URL,绝大多数安全产品只做静态信誉查询,而攻击者会让QR码指向正常域名下的一个子路径,再利用开放重定向跳到钓鱼页,信誉列表永远不会命中。

还有一个容易被忽略的原因:扫码动作发生在个人手机或未受管的BYOD设备上。关键基础设施单位的管理员通常只保护企业配发的Windows电脑,但手机不在管控范围。当手机访问钓鱼站点时,只有手机厂商自带的浏览器安全功能在起作用,而企业内部零散的EDR、防火墙根本看不到这段流量。等到用户把凭据输入进去,所有防护才后知后觉。

2. 多维防御架构设计:从单点拦截到纵深协同

既然Quishing跨越物理、终端、网络、身份、行为多个域,那么防御就不能只依赖某一款“二维码安全网关”。我给客户设计的是一套五层协同的架构:终端侧、网络侧、身份侧、邮件协同侧、物理管理侧。五层通过威胁情报和告警联动串起来,形成一张网。

2.1 终端侧防护:移动设备与QR扫描入口

第一步不是装App,而是把扫码入口管起来。企业应该强制规定:员工在办公区域扫码时必须使用企业统一管控的扫码工具,而不是直接打开相机。这个工具需要具备以下几种能力:

  • URL安全预览:扫码后不直接跳转,先解析出链接并展示给用户,同时与云端安全数据库比对信誉。
  • 域名相似度分析:识别形如“wèb”或“rni11”这类视觉混淆域名。
  • 禁止自动下载文件:防止二维码触发下载恶意APK或带有宏的文档。
  • 沙箱化打开:对于必须打开的链接,在远端的浏览器隔离服务中渲染,而不是在本地WebView里渲染。

如果没有预算建设专用App,可以退而求其次:在移动设备管理(MDM)策略里,把默认浏览器的自动跳转改为“询问”,同时部署DNS安全插播,对所有查询做信誉过滤。我在某水司实际部署过,先用MDM禁止相机直接识别二维码(只保留企业扫码器),再配合本地DNS拦截,成功拦截了一次针对生成车间的QR码钓鱼演练。

2.2 网络侧防护:URL分析与DNS拦截

二维码最终通向URL,所以网络侧必须能看清“扫码之后的流量”。对于办公网络和单独划分的移动设备接入网络,要在出口DNS和HTTP代理上做双路检测:

  • DNS层:对所有域名解析请求做动态恶意域名判定,重点解析短链服务(bit.ly、t.cn等)的原始链接,并把短链接跳转后的最终域名也纳入信誉判定。
  • HTTP层:使用安全代理或其他中间箱对页面内容做实时分析,重点识别“仿冒登录框”。不需要什么AI大模型,简单的DOM特征提取就足够:页面标题包含“登录”“认证”,但域名不是企业已备案的域名,且表单提交地址不在白名单内,就告警。
  • 证书透明日志:定期检查企业相关域名的证书是否被仿冒,利用证书透明度(CT)日志扫描新签发的相似域名。

在这里要特别强调一点:必须把OT网络边界处的对外访问也纳入检测。很多工业网络安全工程师认为OT区必须单向隔离,但实际上,现在不少PLC、HMI都需要升级固件、同步时间或上传工艺数据,运维人员会用U盘或临时笔记本接上外网。Quishing这类攻击的落点,恰恰是这种“允许但未记录”的边界松动处。建议在DMZ区和OT维护区的出站流量上部署独立DNS解析器,所有出站DNS请求都强制走该解析器,并记录完整日志。

2.3 身份侧防护:FIDO2与持续验证

Quishing攻击的最终目的是拿身份。所以无论二维码后面是什么,只要身份验证环节足够硬,钓鱼就失去意义。我强烈建议关键基础设施单位对所有可远程访问的员工账号强制启用FIDO2硬件密钥或基于设备绑定的无密码认证,而不是短信验证码或邮箱OTP——因为二维码钓鱼可以同时诱导用户输入邮箱验证码,甚至伪造一次性密码。

对于无法立即升级到FIDO2的系统,至少要做到以下两点:

  • 登录行为上下文检测:记录登录的IP地理位置、设备指纹、接入网络(是否从员工手机热点接入)、时间规律。发现账号在A城市办公网登录后十分钟内又从B城市登录,立刻触发强制二次验证。
  • 分级账户策略:区分“只有IT系统访问权”和“能访问OT组态软件”的高权限账户。高权限账户禁止通过Web门户登录,只能从独立的运维堡垒机执行命令。这样即使二维码钓鱼拿到的是普通域账号,也无法触达PLC操作界面。

2.4 邮件与协同办公侧防护:图片解码与OCR识别

邮件网关目前还很难对二维码图片做深度判读,但我们可以通过外挂的方式补足:部署一个QR感知模块,在邮件进入用户收件箱之前,执行一次“图片解码-URL提取-信誉查询”流程。具体做法是:用开源解析库把邮件和附件里的所有JPEG/PNG/GIF识别出来,检查是否存在高密度定位图形(QR码的三个回字角),有则解码并提取URL。然后将这个URL送入已有的邮件URL信誉系统。遇到短链就自动展开。

这一步最大的问题是计算资源消耗。一个200人的单位,每天邮件附件图片可能几千张,全部解码会导致邮件网关延迟。我的经验是使用两级过滤:先通过灰度图形特征快速筛掉绝大多数不含二维码的图片,只对疑似图进行解码。实测下来,单台8核服务器每天处理5万封邮件完全没问题。

协同办公软件(如企业微信、钉钉、Teams等)也要做同样的策略,因为这些内部即时通讯工具里的二维码,用户几乎不会质疑来源。配置规则:所有出现在群聊、单聊中的图片附件,都调用与邮件网关相同的QR检测服务,检测出URL后统一替换成“安全链接”样式,并且点击前必须经过网页隔离检查。

2.5 物理安全与二维码生成管理

这个维度最容易被人忽视,但对关键基础设施尤其重要。废纸篓里回收的一张二维码门禁卡,公告栏上一张被换掉的缴费码,都可能是突破口。物理层面的防御手段其实很朴素:

  • 统一二维码生成与登记系统:所有面向员工和访客的二维码,无论是访客登记、会议室预约、设备巡检,统一由某一平台生成,并记录生成时间、申请人、绑定URL。对二维码的URL实行短生命周期:默认有效期只有24小时,过期自动失效。
  • 防替换巡检:对在公共区域长期展示的二维码,安排安保人员以拍照方式定期比对,用图像哈希检测贴纸是否被更换。
  • 打印物销毁流程:含有二维码的临时工牌、访客凭条、废旧海报,在丢弃前必须粉碎或涂黑二维码区域。这个习惯成本极低,但能断了最笨却有效的“换码骗局”。

3. 实施细节与关键技术:让防御真正落地

3.1 QR码预览与解析技术选型

很多团队觉得二维码解析是大难题,其实不然。我梳理过一轮,目前主流方案是ZBar、ZXing、OpenCV配合草拟的定位解码。在实际项目中,我更倾向于使用ZXing的Java/C++实现,因为它的容错能力强,对破损二维码(打了码、贴了半张)也能解出数据。

但重点不是解码,而是“预览”。我们做的二维码安全工具,在弹出预览页时,不只展示URL,还要展示以下信息:

  • 完整域名(包括一级域名和注册域名,用视觉上高亮的方式标出)。
  • 证书信息中的公司名称(如果页面是HTTPS,可以预先抓取证书中的CN字段)。
  • URL扫描结果的简短判定(“该域名未在企业白名单”)。
  • 一个“复制链接到安全浏览器分析”的按钮,而不是“立即打开”。

这个预览带给了用户一个“思考间隙”,实验表明,只要用户看到域名显示为陌生后缀,拦截成功率会提升40%以上。

3.2 可信二维码标记与溯源

关键基础设施单位可以考虑发布自己的“可信二维码”——也就是带有企业签名的二维码。具体实现方式是在二维码的数据内容里嵌入一个JSON结构:

{ "type": "employee_badge", "tenant": "water-uas-01", "nonce": "6f1d3c91a1", "expires": 1719000000, "target_url": "https://sso.internal.example.com/qr/register", "signature": "base64(ed25519_sign(hash(...)))" }

扫码工具在解码后先验证签名是否来自企业证书链,再检查目标URL是否在企业的“内部系统域名白名单”里,两个条件都满足才允许自动跳转。这个方案的难度不在技术,而在管理:所有打印出来的可信二维码都需要电子审批记录,而且URL必须使用系统内域名,不能使用公共短链。只要伪造二维码的签名不合法,即使二维码图片做得再像,扫码工具也会直接报警。

我在一个电网项目里试点过,把关键设备巡检的二维码全部换成带签名的可信二维码。同时把所有旧的普通二维码作废。两周内,就有三位场站员工报告“扫码工具提示未知二维码”,排查发现其中一张是微信群里的不明来源图片,还有一张是贴在厕所隔板上的恶作剧码。这两起事件因为工具的预警被及时拦在了发生危害之前。

3.3 与现有SOC/SIEM的集成

多维防御的最后一环,是让所有“Quishing事件”在安全运营中心(SOC)汇聚成可关联告警。为此,我把每一维度的检测事件都统一成以下字段:

维度主要检测事件告警信号
终端扫码工具发现的恶意URL恶意二维码拦截
网络DNS解析恶意域名、HTTP访问仿冒登录页QuishingURL命中
身份异常登录位置、异常设备QR钓鱼后凭据滥用迹象
物理二维码替换巡检失败二维码被篡改

在SIEM里,我用三个关联规则驱动响应:

  • 同一用户设备在24小时内被“主动扫码告警”命中,且该设备访问过一次非白名单登录页,则提升风险等级。
  • 同一员工账号在扫码拦截后30分钟内出现新设备登录,则触发阻断。
  • 同一个QR码图片哈希关联到多名用户(比如同一个伪造贴纸被多个人扫),则触发事件升级并通知应急响应组。

这种关联能帮你把“孤立的扫码误触”和“一次真正的Quishing攻击”区分开。实际运营中,99%的扫码告警只会到达员工个人的手机端,不会打扰SOC。只有同时满足两个以上条件时,才告警给值班人员。

3.4 零信任架构下的最小授权

零信任和Quishing天然契合。为什么?因为Quishing偷到的是“用户输入的那一刻的信任”。如果系统默认不信任任何来源,即使有合法凭据,也要持续验证,那么钓鱼获得的凭据价值就会大幅下降。

落地时我不建议一开始就全盘上零信任大平台,而是做两个最小集:

  • 网络微隔离:把工控资产按工艺段划分,每个区域只允许特定工程站访问。即使用户账号被钓鱼,他也只能看到自己工作区域的资产,而不是整个OT网段。
  • 应用代理前置:将所有进入OT区的Web操作(组态软件配置、报表查询、设备状态页面)都经过一个反代网关,在网关层做统一登录、短暂会话(比如2分钟无操作即退出)、提交内容只允许白名单指令。这样,被钓鱼的账号即便拿到了URL,也会被网关的二次人机校验和短会话拦住。

4. 实战演练与排查经验

4.1 模拟Quishing攻击的红蓝对抗设计

如果你需要验证自己单位的防御水平,强烈建议做一次无预警的QR码钓鱼演练。步骤参考如下:

  1. 先向管理层说明这是受控的红队任务,但不对普通员工提前透露。
  2. 由红队制作一个仿冒内部系统的钓鱼页,域名使用相似域名(比如“example-uauth.com”),并配置HTTPS证书。
  3. 打印30张二维码,分别投放到食堂、电梯、门禁、吸烟区。如果条件允许,再通过内部邮件发送一张二维码图片,主题为“新版员工福利登记入口”。
  4. 在扫码工具的检测模块里,把该恶意域名标记为“需告警但不阻断”的测试模式,以收集真实用户行为数据。
  5. 观察并记录:扫码次数、输入凭据人数、是否有人点击了不受信任链接,以及用户是否向安全部门报告可疑二维码。

我操盘过的一场演练里,48%的员工扫了码,其中19%输入了账号密码,只有1人主动报告。这个结果让管理层立刻认识到Quishing的威力。另外,演量结束后的复盘非常关键:把“报告给安全部门”这一条也纳入KPI,因为员工主动报告才是“人为防火墙”真正起效的信号。

4.2 发现异常扫描行为的指标

即使没有专门的二维码安全工具,你也可以通过现有日志寻找Quishing的蛛丝马迹:

  • DNS请求异常:在某台移动设备上,连续出现多个短链域名解析请求,且这些短链最终指向同一陌生域名,就是典型的“扫码后跳转”行为。
  • 移动设备流量特征:手机访问某登录页时,User-Agent显示为手机浏览器,但你单位根本没有针对手机的Web应用,就值得怀疑。
  • 凭据使用异动:域控日志中,同一账号从多个新设备登录,且登录时间处于非工作时段,同时伴随密码更改行为。
  • OT组态变更:攻击者利用窃取的凭据登录后,往往会在工程站上创建新的下载任务或修改某个控制逻辑。因此,对工程站的组态变更记录做基线比对,对一切非计划变更触发即时阻断。

我处理过一起真实事件:某水厂OA账号在深夜登录了SCADA的工程站,行为是从未见过的IP段。排查后发现是该员工的手机中了恶意二维码,凭据被钓鱼后又被横向移动工程站。幸亏我们在组态变更日志里设置了异常告警,整个处置时间压缩到了15分钟。

4.3 真实处置流程示例

假设你接到一条SOC告警:“员工A的设备扫描了未知二维码,随后账号在异地登录”。完整的处置流程应该是:

  1. 确认设备身份:通过MDM查询员工A的设备是否在公司注册序列内,如果不是,则要求立即强制退出所有登录会话、禁止接入企业网络。
  2. 重置凭据:立即强制该用户修改密码,并注销所有会话令牌(包括浏览器Cookie、移动端令牌)。
  3. 溯源二维码:从扫描工具日志中调取二维码的图片哈希,反向检索该图片是否在其他设备上出现过,确认是点对点发送还是公共区域张贴。
  4. 检查横向扩散:在10分钟内筛查该账号访问过的所有服务器和共享目录,重点检查是否存在弱口令、本地管理员账号复用。
  5. 锁定边界:如确认是物理投递,通知安保部门调取现场监控,筛查可疑人员,同时清除相关区域的所有同款贴纸。
  6. 复盘与更新:将恶意域名计入黑名单、把QR码图片加进威胁情报、更新员工宣传素材,告知员工“常见的诱导话术”。

整个过程不能超过2小时,因为攻击者可能已经试图用窃取的凭据做更深的渗透。拖得越久,损失越大。

5. 常见问题与避坑清单

5.1 三个最常见的误区

误区一:只要封住邮件附件里二维码图片就够了。实际Quishing最常见的投递路径是物理贴纸和即时通讯,邮件网关挡不住所有。防御时务必把物理投递纳入同等权重,而不是只盯着邮件网关。

误区二:用“手机不允许拍照”来防Quishing。非常不现实,也极其影响生产。关键现场人员拍照记录设备铭牌、仪表读数是刚需。越禁止越容易引发逆反,员工会偷偷用个人手机绕过管理。正确的做法是管住“扫码后干了什么”,而不是管住“能不能扫”。

误区三:给所有二维码加个“防伪标签”就完事。只有防伪但不在扫码工具里校验,那只是心理安慰。可信二维码方案必须闭环:签发、验证、阻断、告警四步缺一不可。

5.2 中小型设施如何低成本起步

如果你的单位预算有限,无法一次性建设完整的“可信二维码平台”,可以从这套最小组合开始:

  • 用开源ZXing做扫码工具,加一个简单的URL白名单校验文件。
  • 在企业DNS处部署一个恶意域名屏蔽模块。
  • 让所有进行远程访问的账号开启多因素认证(优先使用硬件密钥)。
  • 对高权限运维账号,额外规定只能通过堡垒机登录OT系统,禁止直接SSH/RDP。
  • 在公共二维码张贴区增加巡检打卡点,用NFC(近场通信)标签做位置验证,防止二维码被更换。

这套方案一个月内就能落地,成本几乎为零。但效果立竿见影:拦截了95%以上的脚本化Quishing,剩下的5%也会被多因素认证和堡垒机挡住,最终进不到工业控制网络。

5.3 工具选型参考

能力需求建议方向备注
二维码图片内嵌URL提取使用ZXing或ZBar集成识别速度快,支持批量处理
短链接还原调用安全厂商的短链解析API不要自己去逐层访问,防点“带毒链接”
页面仿冒识别无头浏览器抓取页面标题、表单、域名注意设置无头浏览器识别反爬策略
移动端扫码安全企业应用商店内统一安装扫码器禁用系统相机识别二维码
DNS信誉拦截采用支持动态黑名单的DNS服务器必须同时过滤IPv6查询

我见过不少团队迷信“AI识别钓鱼页面”,结果被带了图片验证码的假登录页骗得七荤八素。其实对大多数Quishing攻击来说,简单的规则引擎远比花哨的机器学习可靠。所以工具选型,先求稳和可解释,再考虑智能升级。

6. 写在最后的一点心里话

过去三年,我做过十几场Quishing相关的攻防测试,最大的感悟是:二维码本身不危险,危险的是我们对“扫码”这个动作习以为常。在关键基础设施里,一条最容易进入的路径,往往不是攻破最先进的防火墙,而是让一位疲惫的值班员扫一张贴在设备柜上的二维码。技术防御固然重要,但我更希望每个参与防御的人,都能在自己的手机里装一个“会怀疑的扫码器”,在手指点击跳转之前多看一眼域名。这个习惯的养成,比任何安全产品都值得投入。如果你准备在单位推动Quishing防御,别急着买设备,先拿一张自制二维码贴在茶水间试试,看看谁会扫,谁会报告——结果一定会说服你的领导。

相关新闻

DirectShow虚拟摄像头VCAM技术拆解:过滤器、帧推送与二次开发

DirectShow虚拟摄像头VCAM技术拆解:过滤器、帧推送与二次开发

简介:面向DirectShow及视频开发者的虚拟摄像头实现资源,基于DirectShow API构建VCAM,可在没有物理摄像头时输出连续视频流,适用于测试、演示或与第三方软件集成。压缩包共154个文件,包含h与cpp源文件、ax组件、sln与vc…

2026/10/20 11:40:37 阅读更多 →
OpenClaw接入飞书全攻略:半小时打造团队AI助手

OpenClaw接入飞书全攻略:半小时打造团队AI助手

把 OpenClaw 接进飞书这件事,我第一次跑通的时候,心里最大的感受其实是“原来这么简单”,但回头看,前前后后折腾掉的时间,几乎全浪费在几个特别不起眼的细节上:回调验证地址多写了一个斜杠、app_secret 复制…

2026/10/20 11:40:37 阅读更多 →
OpenClaw接入飞书实战:从消息回调到团队AI助手

OpenClaw接入飞书实战:从消息回调到团队AI助手

写完这篇指南之前,先说说我在实际迭代中踩过的坑。团队协作工具里的 AI 助手,跟网页端聊天机器人完全是两回事:网页端不在乎谁来找你,但飞书里至少得知道这是哪个群、哪个部门、了谁,权限、隔离、超时重试、部署保活这…

2026/10/20 11:40:37 阅读更多 →

最新新闻

Spring Boot社区在线问诊系统实战:从需求到部署的完整技术拆解

Spring Boot社区在线问诊系统实战:从需求到部署的完整技术拆解

最近后台经常有人问社区家庭医生在线问诊系统怎么做,正好我前阵子完整跟过一个类似项目,从需求梳理到部署上线走了不少弯路。我干脆把这套系统的技术拆解和踩坑记录整理成一篇长文,一方面给自己做个复盘,另一方面给正在做毕业设计…

2026/10/20 13:09:01 阅读更多 →
Git克隆Demo代码仓库实战:从地址到跑通全流程

Git克隆Demo代码仓库实战:从地址到跑通全流程

1. 拿到仓库地址后,先别急着敲命令很多同学第一次接触代码仓库时,最容易犯的毛病就是:复制了地址,打开终端,直接输入git clone,回车,然后开始疯狂刷新浏览器看着进度条发呆。如果仓库小&#xf…

2026/10/20 13:09:01 阅读更多 →
OpenHarmony设备上Flutter淡出过渡动画移植实战与性能优化

OpenHarmony设备上Flutter淡出过渡动画移植实战与性能优化

上个月我把一个原本跑在标准Flutter环境里的页面过渡动画方案移植到OpenHarmony设备上,遇到的第一个问题倒不是动画本身,而是animations 这个官方维护的三方动画库直接编译不过。项目里本来打算用它实现页面切换时的淡出过渡效果,想着省一笔自…

2026/10/20 13:09:01 阅读更多 →
轻量级技能管理方案:从零搭建可量化可组合的技能表

轻量级技能管理方案:从零搭建可量化可组合的技能表

1. 从“skills”这个词说起:它到底指什么“skills”这个词看起来简单,但放在不同语境里,指向完全不同。做招聘的人看到它,想到的是岗位能力模型;做在线教育的人看到它,想到的是课程标签体系;做开…

2026/10/20 13:09:01 阅读更多 →
企业级RAG问答系统实战:知识库、检索链路与大模型应用的完整落地指南

企业级RAG问答系统实战:知识库、检索链路与大模型应用的完整落地指南

做了将近半年的基于大模型的智能问答系统,上线之后我最大的感受是:**决定这套系统好不好用的,往往不是大模型本身,而是知识库和检索链路。**模型答得再聪明,检索不到对的资料,它也只能一本正经地编。我们做…

2026/10/20 13:09:01 阅读更多 →
GraphRAG工程实践:知识图谱如何补足向量检索的推理短板

GraphRAG工程实践:知识图谱如何补足向量检索的推理短板

向量检索失效的那一刻,我才决定认真搞GraphRAG年初做过一个企业内部制度问答系统,刚开始用的是经典的向量库RAG方案:文档切块、embedding、top-k召回、拼prompt喂给大模型。原型阶段跑得很顺,演示的时候领导问了一个问题——"…

2026/10/20 13:08:00 阅读更多 →

日新闻

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/20 10:02:13 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出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/20 10:02:08 阅读更多 →
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/20 9:50:17 阅读更多 →
黑夜航拍船只数据集训练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/20 9:50:45 阅读更多 →