智能VIP乘梯IC卡电梯管理系统:四层架构与调度联动
做楼宇智能化这些年我经手过不少梯控项目说实话大部分项目做得都比较“浅”——轿厢内装个读卡器刷卡以后才能按楼层这就叫“梯控”了。但真正面对高端商务楼宇的运营需求这套东西远远不够。标题里明确的几个功能点——VIP权限管理、机器人乘梯、智能调度每一个都意味着系统架构要比“读卡放行”复杂得多尤其当电梯内召和电梯外呼也就是厅门梯控都要接进同一套系统的时候设备配置和现场联调的颗粒度完全不同。这篇文章是给正在做同类项目的集成商、物业智能化负责人和弱电工程师看的。我会从需求拆解、四层架构配置、内召外呼联动逻辑、特色功能落地、扩展性设计五个方面把一套能真正跑起来的智能VIP乘梯IC卡电梯管理系统讲清楚。很多细节是现场调试换来的教训建议收藏之后边做边对照。1. 高端楼宇为什么需要“身份即权限”的乘梯系统1.1 大堂门禁到电梯之间的“权限断层”是最大安全隐患高端商务楼宇通常在大堂设有门禁或访客登记但很多项目到了电梯环节就“裸奔”了只要进了大堂任何人都可以按任意楼层。这个断层的风险比想象中大——临时施工人员直达设备层、陌生访客进入办公层、员工随意带人上楼出一次安全事故物业方和甲方都很难交代。梯控系统要解决的就是把“能进楼”和“能上楼”两件事绑定在同一套身份体系里。IC卡在这里承担的不只是开门凭证而是乘梯授权凭证谁的卡能去哪几层、什么时段能去、节假日是否放行全部由管理平台统一下发。这才叫“身份即权限”。一个完整的权限闭环至少要覆盖发卡管理、黑名单挂失、时段控制、楼层授权这几个基础模块缺一个都会在运营中暴露出漏洞。1.2 VIP权限不是“多给几层”而是“少操作一步”我遇到过不少甲方一开始提VIP需求就是“给领导多授权几层”等真正演示的时候需求变成专属楼层直达、特殊时段可用、高峰不用等梯、甚至从车库进电梯全程不需要掏卡。这些场景背后其实是一件事——降低VIP用户的操作成本。举个例子VIP刷卡瞬间系统自动分配最近一部电梯并提前呼梯轿厢内再刷一次卡确认身份后直接点亮目标楼层。普通用户则需要在轿厢内手动选择自己被授权的楼层。同样的硬件策略不同体验完全不同这就是VIP模块要独立配置的原因。别小看这一步的差异高端楼宇的核心竞争力之一就是“无感通行”领导也好、重要访客也好体验上的顺畅程度直接影响楼宇的租金和口碑。1.3 机器人乘梯和智能调度决定了这套系统不是“门禁外挂”如果只是把电梯读卡器接入门禁系统那叫外挂谈不上“智能乘梯管理系统”。真正的分水岭在机器人乘梯和智能调度机器人没有物理IC卡它的身份是数字化的必须通过API或私有协议跟梯控平台通信智能调度则需要梯控平台参与派梯决策跟电梯群控系统做联动而不是简单触发某台电梯的外呼。这两个能力意味着系统必须有独立的控制层和标准接口。这也是标题把“管理层、控制层、终端层、供电层”单独拎出来的原因——架构上不分层后续加任何新终端都要伤筋动骨分层清楚功能扩展就是加模块的事。后面我会把每一层到底怎么配、怎么选型、怎么接线讲透。2. 四层架构怎么理解每一层的设备职责与配置要点我刚接触这类项目时也困惑过为什么要分四层直接控制器接读卡器不就行了吗后来在现场调试吃过亏才明白分层不是形式主义是为了“可维护”和“可扩展”。管理层出问题不能影响现场刷卡控制层死机不能导致电梯无法选层终端层坏了不能牵连整栋楼供电断了还要保证关键设备能撑住应急时段。四层各管各的故障面才可控。层级核心设备主要职责配置要点管理层管理PC、数据库、发卡器、管理平台权限下发、日志审计、策略定义离线权限存储、分级账户控制层主控制器、楼层扩展板、继电器输出板权限校验、按钮信号输出、联动判断干接点并联、电气隔离、动作时序终端层内召读头、外呼读头、发卡器、人脸/二维码设备身份采集、人机交互防护等级、型号统一、接口预留供电层开关电源、UPS、电源分配箱稳定供电、应急续航、故障隔离容量余量、强弱电分离、独立熔断2.1 管理层权限策略和身份数据的“大脑”管理层主体由管理PC、数据库、发卡器和可选的管理平台本地或云组成。所有VIP等级、机器人身份、常开楼层、时段策略、黑名单和操作日志都在这里定义并下发。实际配置时我建议把管理平台做“三层权限”超级管理员可以改全局策略楼宇管理员只管本楼用户客服人员只能做临时发卡。很多项目为了省事只建一个管理员账户后期物业更换人员时交接成本和风险都很大。另一个容易忽略的点是离线权限存储——断网时控制器必须能独立完成权限校验否则网络抖动一次大门口就堵一排人。我见过一个项目因为管理平台数据库服务偶尔卡顿导致电梯读头响应变慢最后查出来是控制器在线校验权限的设计不合理后来改成离线权限缓存加异步同步才彻底解决。2.2 控制层真正干活的核心干接点并联电梯按钮回路控制层是系统的心脏常见架构是主控制器加楼层扩展板。主控负责逻辑判断和通讯楼层扩展板负责把权限结果变成真实的按钮信号。这里最关键的机制是干接点并联控制器内部用继电器把电梯的楼层按钮回路并联进来权限通过后继电器吸合相当于模拟人手按下了按钮电梯主板收到信号正常选层。听起来简单实际坑很多电梯按钮工作电压有DC12V、DC24V甚至DC110V等不同规格继电器触点必须能承载对应电压电流为了保护电梯主板还建议加中间继电器做电气隔离防止梯控侧故障倒灌到电梯系统。我经手的一个项目就是没做隔离某层继电器粘连后直接烧了电梯按钮板物业连夜找人换板子场面相当狼狈。控制层配置时还要提前规划好继电器通道表和楼层接线点位表写清楚哪个通道对应哪一层否则装修收尾阶段查线比装系统还费时间。2.3 终端层内召读头、外呼读头和发卡器的部署差异终端层就是用户直接接触的设备轿厢内召读头、厅门外呼读头、发卡器/手持管理终端以及可选的人脸识别、二维码等前端识别设备。内召读头装在操纵箱上方面板上要适应轿厢的振动、照明和强电干扰环境外壳和安装紧固都不能省外呼读头装在厅门呼梯盒旁除了防破坏还要考虑地库等潮湿环境的防护等级。发卡器则留在管理室。配置时有条经验同一栋楼尽量统一读头型号减少备用库存种类也降低后期维护的学习成本。如果前端要兼容人脸或二维码控制层要预留对应的韦根或RS485接口后期加设备不需要动主干。终端层的安装位置还要考虑人体工学读头高度一般建议在1.3米到1.5米之间兼顾轮椅用户和普通站立者别为了美观装在腰线以下实际使用起来很别扭。2.4 供电层最容易在验收时翻车的一个环节供电层看起来最不起眼却是项目带病交付的重灾区。配置原则是三句话分区供电、强弱电分离、断电有备。电梯井道和厅门位置走线环境复杂继电器信号线和220V电源线如果同管走线轻则通讯干扰重则烧端子开关电源的容量要按终端负载的1.3到1.5倍配给后续扩展留余量。UPS建议按整个梯控网络的负载计算续航时间。我在某项目里按“读卡器约5W、控制器约10W、网络设备约15W”的规模测算总负载在50W左右配了一台100W的UPS支持两小时以上足够应对大楼应急发电机启动过程。供电层的另一个细节是每个点位都要有独立熔断保护否则一个读头短路整片区域停电排查起来非常痛苦。记住供电不是通电就行而是要“通得稳、断得清、排得快”。3. 内召与外呼的联动配置从接线到联调的顺序清单标题里的“电梯内召即梯控、外呼即电梯门禁”翻译成人话就是轿厢内的选层操作要受权限控制电梯厅外的呼梯操作也要受权限控制。两者在设备上重叠度不高但逻辑上必须联动否则会出现“人到了厅外刷不了卡、进了轿厢又选不了层”这种半吊子体验。3.1 内召梯控权限放行与按钮信号的时序问题内召梯控的流程是读头读到卡主控校验权限通过后点亮对应楼层继电器把选层信号送给电梯。这里有一个现场调试中很容易忽略的时序问题——继电器吸合时间不能太短。我遇到过不少电梯按钮信号低于150毫秒时电梯主板根本采样不到表现为“刷卡成功但电梯没反应”排查一圈发现不是权限问题而是继电器动作时间太短。一般建议吸合时间设在300到500毫秒既保证电梯可靠采样又不至于误触相邻按钮。内召配置时务必保留检修模式梯控系统出故障或电梯检修时应该有开关把梯控旁路掉让轿厢按钮恢复直通。这是安全底线也是不少甲方验收时必查的项目。有些厂家会问“检修模式会不会被滥用”实际上检修模式开关一般装在操纵箱内部或者检修盒里普通乘客接触不到不存在被滥用的风险。3.2 外呼门禁无权限人员呼不了电梯但紧急逃生不能被锁住外呼门禁的逻辑相反厅外读卡器刷卡通过后系统才给指定电梯发出外呼信号或者直接授权该电梯的外呼按钮可操作。这样做的好处是无权限人员在大堂和电梯厅之间就被拦住没法随便按梯呼叫。但隐患也在这里如果外呼被权限锁死火灾等紧急情况下人员疏散怎么办所以外呼配置必须接入消防联动信号——消防信号一来所有梯控立即旁路电梯回归本机运行状态呼梯按钮恢复物理直通。我这几年验收过的项目消防联动这一条是每个都要复测的而且不只是看信号有没有接到还要实测消防信号触发后梯控是否真的释放。把外呼读卡器装在厅门侧面时还要注意跟消防手报按钮、门禁读卡器的距离避免多个读头叠在一起导致用户不知道刷哪个。3.3 联调顺序先单点、再跨层、最后压力与异常整个系统的联调我习惯按五步走单点测试随便挑一层卡刷通、选层亮、电梯响应。跨层测试验证不同楼层的授权组合包括VIP直达和无权楼层不可选。内外联动从厅外刷卡呼梯、进轿厢刷卡选层跑通完整链路。压力测试模拟早高峰多张卡同时刷、多台电梯同时被呼叫的场景观察控制器和电源的波动。异常测试分别模拟断网、断电、消防信号触发确认系统状态可预期。这五步走完项目才敢进验收。很多项目出问题都是因为联调只测了“单点能用”就交差等到高峰真实客流涌进来才暴露总线拥堵或供电不足。联调阶段多花一天后期运维能少熬几个夜。4. VIP权限、机器人乘梯与智能调度三个模块的落地关键这三块是这套系统区别于普通门禁梯控的核心卖点也是最容易“纸面上说得好、现场跑不通”的部分。下面这些配置思路既有原理也有现场修正过的经验。4.1 VIP权限管理等级、时段与派梯策略的组合VIP权限管理不能只做成“一个VIP标志”。建议按使用场景建三个等级一级VIP对应高管任意楼层全天可达并自动呼梯二级VIP对应部门负责人可直达专属楼层和公共办公层非工作时间需要复核三级VIP对应临时重要访客有固定时间窗口和楼层白名单。这里有个容易过度设计的地方——把策略做得太复杂权限组合几十种最后物业培训员工都记不住反而降低使用效率。我一般在项目里跟甲方确认一个底线VIP模块至少支持“时段生效楼层直达派梯优先”三项能力其他个性化需求通过管理平台二次配置不要一开始就把权限矩阵做满。VIP权限的撤销流程也要提前约定好比如高管离任、访客离开权限要能快速回收否则“VIP永久有效”会成为新的安全隐患。4.2 机器人乘梯没有IC卡怎么过梯控机器人乘梯是很多集成商的“知识盲区”。机器人没有物理IC卡所以梯控平台必须对外开放API接口让机器人系统能申请乘梯、查询电梯状态、取消呼梯。典型流程是机器人到达电梯厅调用平台API申请乘梯平台校验机器人身份后在指定电梯上开出一个“虚拟卡通行窗口”机器人通过有线或无线方式向控制器下发乘梯指令电梯到位、机器人进轿厢控制器根据虚拟卡授权点亮目标楼层。这里两个细节特别重要一是通行窗口必须带时效通常在10到15秒防止指令重放或误触发二是电梯到位信号和机器人请求之间要留余量否则早晚高峰电梯调度不过来机器人会一直卡在厅门口反复“空等”。这个模块验收的时候最好写一个模拟脚本用假机器人连续发起几十次乘梯请求看平台的排队和超时处理是否稳定而不是只演示一次好看的。4.3 智能调度梯控平台如何参与派梯决策智能调度听起来高大上但落地时要清醒梯控平台不是取代电梯原厂群控而是通过接口向群控系统提交“派梯建议”。比如VIP刷卡后平台算出当前哪台电梯离目标楼层最近、等候人数最少然后建议群控优先安排那台电梯早高峰时段普通用户按外呼平台可以把低区客流引导到低区电梯减少高区电梯被无效停靠占用。分区调度是高端楼宇最实用的配置高区电梯、低区电梯、VIP专梯各自独立策略互不干扰。我见过一个反面案例某项目把智能调度做成了“人为干预群控”频繁下发指令结果电梯群控系统误判故障直接停止派梯物业差点罢工。稳妥的做法是先让群控系统默认运行梯控平台只在VIP呼梯和高峰分流两个场景做有限介入上线稳定后再逐步增加调度策略。5. 扩展性设计与验收清单决定系统能不能用五年高端楼宇很少有“装完不动”的停车场联动、访客二维码、人脸识别、智慧物业平台这些需求大概率会在系统生命周期内陆续提出来。标题里强调“扩展性强”不是口号而是在架构决策阶段就要留好的接口。5.1 通讯架构选型主干与末端的取舍通讯架构是扩展性的地基。图省事的人会把所有设备都挂在一根RS485总线上稳定性和速率都很受限高端商务楼宇动辄二三十层终端几十上百个我建议主干用TCP/IP网线或光纤楼层扩展段用CAN或RS485末端的识别设备读卡器、人脸终端走韦根或RS485。这样后期加一个人脸识别模块只需要在楼层扩展板上加一个转换模块不用重走主干。如果现场没有网络条件CAN总线的抗干扰能力和实时性也不错但要注意总线长度和节点数量上限。做过一个三十层项目之后我对通讯架构的体会就是不要为了省两根线把扩展性锁死接口预留的成本远低于后期改造的代价。5.2 第三方联动预留停车场、访客系统、消防信号扩展性还体现在对外接口。高端楼宇常见的联动包括地库停车场联动车停好后刷卡直接从地库电梯厅呼梯。访客系统联动前台登记后生成一张二维码或临时卡限定楼层和时间访客直接在电梯读头使用。物业平台联动移动端审批临时权限。这些联动建议在管理平台层面预留标准API并留出至少两路干接点输入给消防和其他紧急信号。我通常会建议甲方在招标技术规范里写明“系统须提供Open API用于第三方平台对接”后期谈需求时主动权就在甲方手里。接口文档要写得清楚别把联调责任全推给第三方现场多花半天聊协议能省一个月的扯皮。5.3 供电冗余与防干扰的实操细节很多扩展需求加不进去不是接口不够而是电源不够。增加人脸终端、二维码读头都是要额外供电的前期如果按照总负载的1.3到1.5倍配置开关电源后期扩展就能直接挂。UPS容量也要按“未来比现状多20%负载”来算。防干扰方面我踩过的最典型的坑是继电器输出线与通讯线走同一根管结果每次电梯启动主控都收到乱码。解决方法是强弱电分离走线通讯线用屏蔽双绞线屏蔽层单端接地。井道内的线缆还要选阻燃型号并做好机械防护这个位置的故障排查成本是所有点位里最高的。现场穿线的时候一定要求施工队把每条线两端都贴好标签井道内线缆一旦乱了检修想死的心都有。5.4 竣工验收时建议按这张清单逐项测试验收不是走过场我把常用测试清单整理了一下覆盖功能、安全和可靠性三个维度测试项测试内容通过标准内召权限多楼层刷卡选层授权楼层可选非授权楼层不可选VIP直达VIP刷卡自动呼梯选层目标楼层自动点亮并直达外呼联动厅外刷卡呼梯无权限人员无法呼梯机器人乘梯模拟API呼叫连续50次请求无掉线、无错层消防旁路触发消防信号梯控全部释放按钮恢复直通断电续航切断市电UPS支撑不少于约定时间日志一致性核对刷卡记录平台记录与现场行为一致这张表看起来不复杂但每条都要留验收记录。很多项目交付后扯皮都是因为前期少了这些白纸黑字的测试凭证。做了这么多轮梯控项目我最大的体会是这类系统的成败三分在设备七分在现场实施和策略设计。VIP权限、机器人乘梯、智能调度这些听起来很“高级”的功能只要架构层面对了实现起来反而顺理成章反过来如果只盯着读卡器和继电器四个层级没理顺后面每加一个功能都像往旧房子上补砖。最后再分享一个实用技巧交付时务必给甲方的物业团队做一次半小时的操作培训特别是VIP策略和消防旁路的日常检查方法。很多系统不是一开始就坏而是被错误操作慢慢用坏的这一点比任何配置细节都更值得重视。

相关新闻

分布式电源接入下配电网三相不平衡潮流计算与工程实现

分布式电源接入下配电网三相不平衡潮流计算与工程实现

1. 从单相模型到三相模型:分布式电源接入后到底哪里出了问题1.1 单相潮流为什么在配电网里"够用"在纯交流输电网里,设计阶段几乎默认三相线路是换位的,长距离线路经过整循环换位,三相阻抗基本一致;大型负荷也…

2026/10/12 6:35:49 阅读更多 →
SpringBoot+Vue全栈实战:游戏零售平台从设计到部署完整指南

SpringBoot+Vue全栈实战:游戏零售平台从设计到部署完整指南

做游戏零售平台这个项目,前后折腾了大概两个月。SpringBoot Vue的组合是目前个人开发者和毕业设计里最常见的选型,这套组合的好处在于:SpringBoot把后端服务端的复杂度降得很低,Vue则让前端交互页面的开发效率大幅提升&#xff0…

2026/10/12 6:34:49 阅读更多 →
Python requests库实战:429限流重试与优雅请求策略

Python requests库实战:429限流重试与优雅请求策略

说实话,我一开始也没把那串红色报错当回事。直到某个深夜,我盯着控制台里满屏的“exceeded retry limit, last status: 429 too many requests”,才意识到自己对Python的requests模块其实只是“会用”,离“用明白”还差了十万八千…

2026/10/12 6:34:49 阅读更多 →

最新新闻

OpenAI DevDay 2026:dots、Spaces与GPT-6.1 Sol的工程化落地指南

OpenAI DevDay 2026:dots、Spaces与GPT-6.1 Sol的工程化落地指南

1. 这不是发布会速记,而是一份开发者视角的“技术落地可行性评估报告”OpenAI DevDay 2026 这个标题本身已经释放出强烈的信号:它不再是一场面向大众的炫技秀,而是一次明确指向工程实践边界的深度技术校准。我全程参与了线上直播与会后48小时…

2026/10/12 8:43:30 阅读更多 →
公众号都在安利 OpenShip:中文社区为什么突然集体拥抱自托管

公众号都在安利 OpenShip:中文社区为什么突然集体拥抱自托管

公众号都在安利 OpenShip:中文社区为什么突然集体拥抱自托管 【免费下载链接】openship Self-hosted deployment platform 项目地址: https://gitcode.com/GitHub_Trending/ope/openship 如果你关注过 2026 年夏天的 GitHub Trending,大概率见过这…

2026/10/12 8:43:29 阅读更多 →
二叉树右视图全解:BFS层序取末位与DFS先右后左

二叉树右视图全解:BFS层序取末位与DFS先右后左

说个实在话,二叉树的右视图这道题,是我在刷 LeetCode 时反复做了三遍才真正吃透的一道题。题面特别简单:给你一棵二叉树,让你想象自己站在树的右侧,返回从上到下看到的节点值。很多人第一反应是“那我一直往右走不就行…

2026/10/12 8:43:29 阅读更多 →
Spring Boot热部署实战:DevTools、自动重启与热加载方案全解析

Spring Boot热部署实战:DevTools、自动重启与热加载方案全解析

1. 为什么说 Spring Boot 热部署是"开发体验的分水岭"先聊一个很多 Java 开发者都经历过的场景:你在一个 Controller 里改了个接口的返回值,然后按下 CtrlF10 或者重启应用,等待漫长的启动日志刷屏。如果项目稍微大一点&#xff0c…

2026/10/12 8:43:29 阅读更多 →
稀疏、密集、二进制向量选型与Milvus实战全解

稀疏、密集、二进制向量选型与Milvus实战全解

做向量检索这几年,我接到最多的一个问题不是"Milvus 怎么用",而是"我到底该用稀疏向量、密集向量还是二进制向量"。很多人默认三种向量只是精度和存储的取舍,实际完全不是一回事——稀疏、密集、二进制对应的是三种不同的…

2026/10/12 8:43:29 阅读更多 →
cli-continues会话管理5大命令:list、scan、inspect、dump、rebuild使用清单

cli-continues会话管理5大命令:list、scan、inspect、dump、rebuild使用清单

【免费下载链接】cli-continues resume any AI coding session in another tool — Claude Code, Copilot, Gemini, Codex, Cursor 项目地址: https://gitcode.com/gh_mirrors/cl/cli-continues 点击查看 免费下载 cli-continues(npm 包名 continues&am…

2026/10/12 8:42:27 阅读更多 →

日新闻

复古胶片颗粒感噪点合成器:Canvas ImageData 像素高斯杂色注入算法

复古胶片颗粒感噪点合成器:Canvas ImageData 像素高斯杂色注入算法

在数码相机、高清显示屏与现代矢量图形技术高度发达的今天,画面可以做到绝对的锐利、平滑与无瑕。然而,当一张秋日手账插画或拍立得照片过于“平整无瑕”时,往往会散发出一种冰冷生硬的“数码塑料感(Digital Plasticity&#xff0…

2026/10/12 0:00:59 阅读更多 →
活字印刷古籍线装排版:Canvas 竖排文字与栏线自适应算法

活字印刷古籍线装排版:Canvas 竖排文字与栏线自适应算法

在现代网页与移动端设计中,横排(Horizontal Layout)早已经成为了绝对的主流。然而,当我们翻开泛黄的线装古籍、宋版木刻诗集,或是欣赏一张茶道雅集的手写便签时,那种**自上而下纵向书写、自右向左逐列铺展&…

2026/10/12 0:00:59 阅读更多 →
周日晚间的“精神松绑减震器”:无压力情绪倾倒箱与温和轻声陪伴

周日晚间的“精神松绑减震器”:无压力情绪倾倒箱与温和轻声陪伴

每到周日的晚上八点到十点,很多人心里都会悄悄亮起一盏警示灯。 在心理学上,这种现象有一个专门的称谓——“周日夜晚焦虑症(Sunday Scaries)”。明天又是周一,闹钟又要重新在七点响彻卧房;脑海里仿佛有一个…

2026/10/12 0:00:59 阅读更多 →

周新闻

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

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

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

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

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

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

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

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

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

2026/10/12 0:16:43 阅读更多 →

月新闻

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