基于Simulink的三机九节点风电调频仿真:下垂与虚拟惯性控制实现
做风电并网调频仿真的朋友多半都经历过这个阶段拿到一个风机模型在下垂控制里改个系数跑完看着频率曲线心里想着“这回总该成了”结果被人问了一句“你的惯性响应呢”当场愣住。我这次在Simulink里搭三机九节点系统做风电调频起步时也以为只是给有功参考叠加一个频率偏差真正把MPPT运行、下垂控制、虚拟惯性控制串起来跑通之后才发现这里面的核心难点根本不是参数整定而是控制架构怎么设计。这篇文章把整个过程里最关键的逻辑和实现细节整理出来覆盖三个层面一是为什么选三机九节点这个平台来研究风电调频二是MPPT运行下风机为什么“天生”调不了频、下垂和虚拟惯性分别解决什么问题三是这两条控制支路如何在Simulink里落地并协同工作。项目以20%风电渗透率为研究场景用经典三机九节点测试系统替换出一台同步机组、并入聚合风电场在Matlab/Simulink里完整实现了MPPT基准层与调频叠加层的融合控制。想用Simulink做风电调频仿真、或者在多机系统里研究风机参与频率支撑的朋友这篇文章可以直接作为建模和调参的参考。1. 为什么调频研究要选三机九节点从单机无穷大到多机互联的仿真选型1.1 三机九节点系统的拓扑与风电并网接线方案三机九节点系统在电力系统暂态分析里属于“入门级但五脏俱全”的多机测试平台9条母线、3台同步发电机、3个负荷节点系统基准容量100MVA额定频率50Hz总负荷大约315MW。和单机无穷大系统相比它最大的价值在于能真实呈现多台机组之间的频率动态与功率分配过程——一台机扰动其他机组都会在各自的调差特性作用下重新分配出力。我这次做的风电接入方案是把其中一台容量较小、离负荷中心较近的同步机组从母线上解列在原母线位置并入一个聚合风电场模型其余网络拓扑、线路参数、负荷分布全部保持不变。这样做的好处非常直接仿真对比时唯一的变量是“风机替换了同步机”以及“风机叠加了调频控制”而不是因为接线方式变了导致结果没法归因。风电场在模型里以单机等值参数体现按整个风电场63MW额定容量折算转子惯量、变流器容量和功率外环参数省掉了多机并联带来的计算负担同时保留了对电网侧频率动态足够精确的响应特性。1.2 渗透率20%在模型里是如何定义的风电渗透率这个数很多第一次做仿真的人会算错。它并不是“风机容量占系统总装机容量的比例”而是指风电场额定容量占系统最大负荷或统计口径下的总负荷的比例。在我这个模型里系统最大负荷约315MW风电场额定容量设为63MW63/315正好是20%这就是标题里“风电渗透率20%”的由来。这里还有一个建模细节值得提醒风电场的额定功率不是直接把63MW塞进一个理想电源模型就行。要做到“渗透率变化对系统惯量影响真实”需要同步调整系统侧原本由被替换同步机承担的惯量和一次调频能力否则仿真出来的频率曲线会失真。我用的做法是在解列同步机的同时把它的惯量时间常数H、调速器调差系数R从系统等效惯量中扣除这样20%渗透率的场景才真正反映了“少了传统旋转备用能力、多了电力电子接口电源”这一现实变化。1.3 从单机系统换到多机系统的三个关键差异频率不是“刚”的了。单机无穷大系统里无穷大母线把频率钳制得很死风机调频控制产生的那点功率增量对系统频率几乎没有可见影响仿真曲线看起来像没接控制。三机九节点里系统松耦合频率真实跌、真实恢复控制效果才能看得清。故障激励要放在网络侧而不是风机侧。在三机九节点里做负荷阶跃或线路开断扰动会通过潮流和电气距离传播到风电并网点风机感受到的频率变化更接近真实并网场景。单机系统里你只能在风机端口硬拉频率说服力差很多。数据采样和同步问题开始出现。多机系统里风电场并网点电压的相位、幅值在扰动瞬间会有明显波动这直接影响PLL锁相环测频的可靠性——这点我在第4、5部分会展开讲它几乎是所有风电调频Simulink模型翻车的重灾区。2. MPPT模式下的风机为什么“调不了频”转子动能与电网频率脱钩的本质2.1 最优功率跟踪把转速“锁”在了最佳叶尖速比上风机在额定风速以下运行的MPPT逻辑本质上是让转速实时追踪风速使叶尖速比λ维持在最优点λ_opt附近从而捕获最大风能。控制实现非常经典根据当前转速ω直接查最佳功率曲线得到有功参考P_ref K_opt × ω³再通过变流器功率外环去跟踪这个指令。这套控制的问题恰恰也在这里转速参考不是跟随系统需求变化而是跟随风速变化。电网频率跌了要求风机多出功率、释放转子动能但MPPT逻辑只看转速和风速的关系完全不管频率。换句话说风机转子被“锁”在最佳叶尖速比对应的转速上有功输出由风速决定而非由电网频率决定。很多初学者以为风机只要调速器参数配得好就能响应频率实际上MPPT模式下风机对系统频率是“失明”的。2.2 同步发电机与双馈风机的惯量响应本质差异同步发电机的频率响应是物理性的、天然的。转子运动方程2H × dω/dt Pm − Pe决定了频率一旦跌落电网侧电磁功率大于原动机机械功率转子转速自然下降转子动能自动转化为有功功率注入电网。这个响应不需要任何控制器参与从第一个周波就开始作用这也是同步机“惯性”的直接来源。双馈风机在MPPT模式下则完全不同转子通过电力电子变流器与电网解耦电气侧频率变化影响的是网侧变流器的PLL而不是机械转子。变流器控制的有功指令完全由MPPT给定即使电网频率骤降有功参考不变风机机械功率也不变转子转速依然按风速轨迹运行。它跟同步机之间隔着“两堵墙”一是功率外环只认MPPT曲线二是变流器响应时间尺度远快于机械动态。2.3 频率跌落时风机功率路径在Simulink里发生了什么我在模型里设置了一个30MW负荷阶跃观察风机在无调频控制时的表现。扰动发生瞬间并网点频率开始下降PLL输出的频率信号跟着变化但风机有功功率曲线几乎是一条平线——只有在直流母线电压波动的瞬间有一个极小的功率凹陷随后又被电压外环拉了回来。这个过程很直观地说明MPPT模式下风机不是没有“看到”频率而是看到了也不响应。所以风电调频研究的本质就是要在这条“电网频率 → 风机有功”的路径上主动补一条通道把频率偏差和频率变化率翻译成有功增量叠加到MPPT参考值之上。这就是下垂控制和虚拟惯性控制的共同目标区别只是它们翻译的物理量不同、作用的动态阶段不同。3. 下垂控制把频率偏差“翻译”成有功增量的完整实现3.1 风电下垂控制与同步发电机一次调频的异同同步发电机的一次调频基于调速器的静态调差特性频率下降调速器开大导叶/汽门原动机机械功率增加最终在略低于额定频率的点上达到新的功率平衡。这个响应是持续的——只要频率偏差存在功率增量就一直存在。风机的下垂控制可以完全对标这个逻辑将实测频率与额定频率做差乘以下垂系数叠加到MPPT有功参考上。公式写成标幺值非常直观 ΔP_droop标幺 K_droop × (f_ref − f_meas) K_droop就是风机的“调差系数倒数”工程上习惯参考同步机的5%调差率来整定。区别在于同步机调频由原动机侧燃料/蒸汽支撑可以持续输出风机调频靠的是转子动能撑不了太久所以下垂控制必须配套转速恢复逻辑这点后面会专门讲。3.2 Simulink中的下垂控制链测频、PLL滤波、死区、限幅下垂控制在Simulink里的实现链路我拆成五个环节频率测量从风电场并网点母线取三相电压送入Three-Phase PLL输出电网频率f。PLL的响应速度和滤波效果直接决定下游控制质量建议在PLL输出后加一阶低通滤波器时间常数设在0.05s左右过滤换相纹波。频率偏差计算f与额定频率50Hz相减。注意仿真的扰动场景里频率是动态变化的必须用Bus Selector取连续信号不能用手动常数。死区环节频率偏差在±0.03Hz以内不动作。这个死区很重要不是偷懒而是避免系统正常运行时的微小频率波动让风机功率指令频繁抖动影响变流器寿命。Simulink自带Dead Zone模块直接可用。比例环节死区输出的偏差乘以K_droop得到有功增量。功率增量建议做限幅典型范围±0.1 p.u.。限幅不只是保护变流器更是为了防止风机在极端频率偏差下被要求输出超出能力范围的功率。叠加与平滑有功增量加到MPPT有功参考上经一个一阶惯性环节时间常数10~50ms再送入风机功率外环。惯性环节用来模拟变流器有限带宽让功率指令变化是“斜坡式”而不是“阶跃式”避免电流内环被打出尖峰。3.3 下垂系数取值从5%调差率到0.1p.u./Hz的折算下垂系数标幺化最容易让人绕晕这里给一个可以照抄的折算方法。以参考同步机5%调差率为例调差率R 0.05对应的下垂系数K_droop_pu 1/R 20标幺即20 p.u./p.u.。换算到有名值时 K_droopMW/Hz K_droop_pu × S_base / f_ref 20 × 63 / 50 ≈ 25.2 MW/Hz。也就是说频率每下降1Hz风机最大能多出25MW有功。这个数值在三机九节点315MW的系统里属于比较强的调频能力实际仿真中需要根据风机转速状态和电网强度微调。我最后采用的整定值是K_droop_pu在15~20之间并在后端限幅±0.1 p.u.。如果你是自己搭模型建议从8~10开始、逐次增大观察频率最低点和风机转速变化找到“调频效果增益不再明显、转子转速却不健康下跌”的拐点那个拐点附近就是合适值。4. 虚拟惯性控制让功率电子接口“装”出惯量4.1 惯量响应的核心量是频率变化率不是频差惯量响应的物理意义是阻止频率快速变化体现的是对频率变化过程的反抗而不是对频率偏离结果的纠正。所以它的输入量是df/dt不是频率偏差。数学模型写成 ΔP_inertia −K_i × df/dt 频率下跌时df/dt为负ΔP为正风机释放动能支撑频率频率恢复过程中df/dt为正ΔP为负风机反吸功率完成转速恢复。K_i的整定可以从“虚拟惯量时间常数”反推。如果想让风机表现出H_w 3s的惯量按额定容量折算 K_i_absMW/(Hz/s) 2 × H_w × S_base / f_ref 2 × 3 × 63 / 50 ≈ 7.56 MW/(Hz/s)。 在频率变化率0.1Hz/s的扰动中这条支路能额外输出约0.76MW——单看不大的量但对RoCoF频率变化率的抑制效果非常显著。这也是虚拟惯量和下垂最大的差异下垂管稳态频差虚拟惯量管暂态跌落速度。4.2 微分的噪声问题低通滤波、带通近似与PLL处理虚拟惯性控制落地时最头疼的就是微分。PLL测出的频率信号含有开关纹波和测量噪声直接对频率做微分噪声会被放大一两个数量级仿真结果里功率指令满屏毛刺根本没法用。我踩过这个坑试了几种做法后在工程上推荐以下两种第一种先低通滤波再微分。低通滤波器时间常数取0.1~0.2s把开关换相产生的尖刺抹掉再做微分。好处是直观坏处是低通本身会引入相位滞后虚拟惯量响应打折扣所以滤波时间常数不能取得太大。第二种我最终采用用高通滤波器近似微分。传递函数写成 H(s) s/(sa)a取0.5~2。它在有效频带内近似微分作用同时在高频段自然滚降兼备“差分”和“低通”的特性。Simulink里直接用Transfer Fcn模块实现调一个参数a就能兼顾响应速度和噪声抑制比“滤波纯微分”少了一个环节相位特性也更平缓。4.3 虚拟惯量与下垂的动态分工一个管“谷底”一个管“稳态”两条控制支路叠加到同一个有功参考上很多人会担心“会不会互相打架”。实际在时间尺度上它们配合得很好扰动发生的前1~2秒频率变化率最大虚拟惯量支路输出顶峰负责托住频率最低点频率nadir和限制RoCoF1~2秒之后频率变化率减小虚拟惯量支路自然衰减而频率偏差还在下垂支路接力输出负责把稳态频率拉回允许范围。这个“先惯量后下垂”的时序在仿真结果里看得非常清楚。没有虚拟惯量时频率nadir会深跌0.2~0.3Hz加入虚拟惯量后nadir明显抬高但稳态偏差改善有限再叠加下垂稳态偏差也被收窄。三者各管一段协同逻辑清晰这也解释了为什么现代风机调频控制几乎都是“下垂虚拟惯量”组合方案。5. 两种控制策略协同控制架构、转速恢复与仿真结果5.1 MPPT基础层调频叠加层的整体控制架构整个控制系统的结构可以分成两层理解这个分层对模型调试非常重要。底层是风机原有的MPPT控制链转速测量 → 最佳功率曲线查表 → 有功参考P_ref_MPPT → 功率外环 → 电流内环 → PWM驱动。这一层在风电调频研究里不需要改动它保证了风机在正常工况下最大限度捕获风能。上层是调频叠加层输入只有两个信号——并网点频率f和频率变化率df/dt输出一个有功增量ΔP_total做限幅后加到P_ref_MPPT上。这种分层设计的最大好处是控制逻辑解耦底层控制不关心上层做了什么上层控制也不干预风机的正常运行。调试时可以先单独验证MPPT跟踪行为再分别让下垂和虚拟惯量旁路/投入问题定位非常快。在Simulink里把这条叠加链路画出来并不复杂核心是把握住每个模块的输入输出信号类型。我建议单独封装一个“Frequency Support”子系统输入f、df/dt、风机转速ω输出限幅后的ΔP_total再把ΔP_total与MPPT输出相加。这样整个模型看起来清爽后续想对比不同调频策略只在子系统内部改逻辑就行。5.2 转速恢复逻辑释放动能之后怎么“补回来”下垂和虚拟惯量共同作用时风机持续输出超过MPPT的功率转子动能不断被消耗转速明显下降。如果不做转速恢复风机会陷入两个结局中的一个要么转速一路掉到切入转速以下机组脱网要么转速太低再次遭遇频率跌落时没有动能可释放调频能力归零。我采用的转速恢复策略分两级转速监测与触发设定转速下限阈值比如0.70 p.u.当转速降至阈值时触发恢复流程。触发条件里建议加一个持续时间判断避免瞬时噪声引起误触发。功率斜坡回撤不是把调频功率增量直接清零而是以线性斜坡方式逐步减少ΔP_total斜坡时间取2~3秒。这样做是让风机“边支撑边恢复”避免功率指令突变引起系统二次扰动。恢复完成后风机重新回到MPPT工作点转速慢慢回到最佳运行区。斜坡回撤的参数在模型里的影响很敏感。斜坡太快频率会再跌一浪斜坡太慢转速长时间停留在低值区对变流器和齿轮箱都不友好。我的经验是先取2s斜坡观察频率最低点的变化和转速回升轨迹再逐步调整。5.3 仿真场景设计与关键指标对比仿真场景设计的是12s时系统负荷阶跃增加30MW约10%持续到仿真结束这个场景对应现实中的大负荷投切或联络线跳闸后的功率缺额。我跑了四种对照配置不加调频控制、仅下垂控制、仅虚拟惯性控制、下垂虚拟惯性联合控制。关键指标取四个频率最低点nadir、最大RoCoF、稳态频率偏差、风机最低转速。典型结果如下表控制策略频率最低点(Hz)最大RoCoF(Hz/s)稳态频率偏差(Hz)风机最低转速(p.u.)无调频控制49.210.420.650.88仅下垂控制49.280.410.180.82仅虚拟惯性控制49.450.260.620.76下垂虚拟惯性49.520.250.160.74不同参数下数值会有浮动但趋势非常一致虚拟惯性主要改善的是第二列和第三列RoCoF和最低点下垂主要改善第四列稳态偏差两者联合使用的互补性很明显。风机最低转速表格里掉到0.74 p.u.说明释放动能的同时也在吃转速储备所以转速恢复逻辑不是“可选项”而是调频控制的必备模块。6. 实测仿真心得三个容易翻车的地方和规避方法6.1 测频延时让调频动作慢了半拍第一次把两条调频支路接进去我跑完发现响应波形总是比理想情况慢了200ms左右频率最低点的改善幅度不到预期的一半。排查后发现是频率测量链路里PLL的环路带宽设得太低。PLL为了滤除谐波带宽调低了测频输出确实平滑但频率变化的“快照”也跟着滞后。测频延时意味着风机等到频率已经跌到底才开始输出功率虚拟惯量基本废了一半。6.2 转速恢复与下垂控制“打架”导致功率振荡转速恢复逻辑的初版设计是“二值切换”转速低于阈值立刻把调频功率增量清零。仿真结果出现了让人头皮发麻的现象——功率突然掉回MPPT值频率跟着再跌一波下垂控制检测到新频差又重新加大功率风机再释放动能转速又跌破阈值再次清零形成持续好几个周期的功率振荡。后来改成斜坡回撤并让调频支路在恢复过程中保持“部分生效”这个振荡才消失。结论是恢复逻辑必须平滑不能把支撑功率一刀切。6.3 渗透率越高等效惯量评估越不能只看装机容量把渗透率从20%调到30%、40%重跑同一组参数时发现频率跌落深度和RoCoF非线性地恶化。原因在于系统等效惯量随同步机退出而线性下降但风机提供的虚拟惯量并没有同步提升。换句话说渗透率越高同样的下垂/惯量参数对系统频率的支撑能力越显得“不够看”。如果要把同一个模型扩展到更高渗透率场景K_droop和K_i都需要按风电场额定容量与系统等效惯量的比例重新校核不能沿用20%渗透率下的整定值。最后补一个我自己实际操作中的体会Simulink里把控制逻辑跑通只是第一步真正花时间的往往是那些文档里不会写的东西——PLL的环路带宽和虚拟惯量的微分噪声是一对需要手工找平衡的矛盾转速恢复的斜坡和下垂系数是一组需要反复对调的参数测频延时和频率最低点的改善幅度则是一对直接互相拆台的冤家。这套模型和调参思路我后来又复用到不同渗透率和不同扰动场景里每次重跑都会有新的细节要调但也正因为如此风电调频仿真才远不只是“搭个模型看个曲线”那么表面的工作。

相关新闻

airllm 实战:低显存跑 70B 大模型的分层推理与避坑指南

airllm 实战:低显存跑 70B 大模型的分层推理与避坑指南

airllm 这个项目名字,第一次听到的时候,我以为又是某个蹭大模型热度的玩具。一直到我看清楚它的设定——声称可以在普通消费级显卡上直接跑 70B 参数体量的开源大模型,而且“不修改模型代码、不丢弃权重、计算复杂度和原始模型一致”&#xf…

2026/10/15 6:45:49 阅读更多 →
C++20编译期字符串处理:从fixed_string到静态类型映射的工程实践

C++20编译期字符串处理:从fixed_string到静态类型映射的工程实践

最近在重构一个内部工具库时,我遇到了一个特别拧巴的需求组合:日志系统希望自动带上调用点的完整函数签名,序列化模块想在编译期就校验字段名有没有写错,反射注册表想通过一个字符串反查类型。这三个需求凑到一起,就逼…

2026/10/15 6:45:49 阅读更多 →
矩阵向量求导速查手册:工程师的梯度推导实战指南

矩阵向量求导速查手册:工程师的梯度推导实战指南

1. 这不是数学课,是工程师手边的“求导速查手册”你打开一份机器学习模型的推导文档,第一页就卡在了 $\frac{\partial}{\partial \mathbf{W}} \left( \mathbf{x}^\top \mathbf{W} \mathbf{y} \right)$ —— 符号密密麻麻,下标横飞&#xff0c…

2026/10/15 6:45:49 阅读更多 →

最新新闻

debounce 和 throttle 到底差在哪?200 次连续输入实测触发次数

debounce 和 throttle 到底差在哪?200 次连续输入实测触发次数

一次输入 200 个事件,同一份数据同时喂给 debounce 和 throttle,谁触发几次、差在哪,页面当场报数。 先把结论摆出来。 同一段 200 事件的输入流,debounce 只触发 6 次,throttle 触发 22 次,差了 16 次。 …

2026/10/15 8:01:05 阅读更多 →
AnyPS5技术解析:跨平台串流、输入映射与存档同步的工程实践

AnyPS5技术解析:跨平台串流、输入映射与存档同步的工程实践

1. 从“AnyPS5”这个名字说起:它到底想解决什么问题第一次看到“AnyPS5”这个标题,我脑子里蹦出来的第一个念头是:这大概率是一个围绕“通用化”做文章的项目。名字里的“Any”通常意味着跨平台、跨设备、跨场景的兼容能力,而“PS…

2026/10/15 8:01:05 阅读更多 →
谷歌开源ARTEMIS:让AI像人一样操作手机的移动端自动化框架

谷歌开源ARTEMIS:让AI像人一样操作手机的移动端自动化框架

ARTEMIS 这个项目出来的时候,我在第一时间就把它拉下来试了一遍。说实话,第一眼看到官方演示视频里 AI 自己点开设置、翻通讯录、甚至帮用户清通知的时候,我心里第一个念头是:这不是又多了个自动化工具,这是整个人机交…

2026/10/15 8:01:05 阅读更多 →
开源音乐播放器推荐:Strawberry与Lollypop深度评测

开源音乐播放器推荐:Strawberry与Lollypop深度评测

1. 为什么我们需要开源音乐播放器?在这个流媒体音乐盛行的时代,大多数人已经习惯了使用商业平台来收听音乐。但你可能没意识到,这些平台往往存在隐私泄露、功能限制、曲库不全等问题。作为一名长期关注数字隐私的音乐爱好者,我发现…

2026/10/15 8:01:05 阅读更多 →
Spark Kryo Buffer Overflow根因与五种压降方案

Spark Kryo Buffer Overflow根因与五种压降方案

1. 这个报错不是Kryo的问题,而是你低估了数据的“体积膨胀”org.apache.spark.SparkException: Kryo serialization failed: Buffer overflow——这个报错在Spark调优中出现频率极高,但绝大多数人第一反应是“Kryo配置不对”,于是疯狂调大spa…

2026/10/15 8:01:04 阅读更多 →
金牛区零售门店店长面试,卡人卡在哪几处

金牛区零售门店店长面试,卡人卡在哪几处

金牛区一家连锁门店的店长面试,第一道题常常不是问履历。面试官更爱先抛一个具体处境,让求职者当场处理。比如早班临时少来一个人,这班怎么排、活怎么分,答完就见分晓。一、金牛区店长面试真正在考什么店长面试整体在考现场处理、…

2026/10/15 8:00:04 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

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

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

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

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

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

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

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

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

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

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 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/15 0:14:36 阅读更多 →
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/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练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/14 7:53:34 阅读更多 →