InTouch组态实战：点位表、脚本联锁与故障注入验收-北京尧图网络

简介面向工业自动化工程师与HMI初学者这份InTouch应用技术实例包围绕Wonderware过程可视化组态软件展开可用于熟悉界面设计、OPC数据通信、报警管理、脚本逻辑、历史数据记录与报表生成等典型环节并借助随包范例理解模拟产线监控、设备故障诊断等实际组态思路。压缩包共2203个文件、约3.05MB以ini配置、cic与dit工程数据、cfg参数、dbf/ndx数据表及索引、win窗口、bmp图形、tag与symbol变量符号库、csv/xls报表等为主覆盖工程配置、变量字典、历史数据、界面元素和脚本逻辑目录层次较完整。已有356人学习。读者可从中获得可参照的工程文件组织方式、变量与符号定义样例、界面与报警配置素材以及脚本和历史数据相关文件便于对照复现与二次练习适合需要从实例入手掌握InTouch组态流程的初中级用户。1. 从一台泵的启停说起这套 InTouch 组态实例要解决什么某中试车间的班组长有个习惯开机前先去配电室按一下现场按钮再回中控室看屏幕上那台泵的状态亮不亮。动作本身没问题问题是这两个动作之间没有任何关系——屏幕是屏幕按钮是按钮中间靠人的眼睛和记忆连起来。这套 InTouch 组态应用实例要解决的正是这件事让画面上的一个按钮真正对应现场一台设备让一次点击背后有权限校验、有联锁判断、有操作留痕、有事后的趋势可查。它适合三类人正在做组态课程设计、需要交一套完整画面的学生自动化方向做毕设、要把 PLC 和上位机打通的人还有刚接手一套老 HMI、被要求重做或补功能的现场工程师。下面按需求梳理、画面架构、功能实现、踩坑排查、验收答辩的顺序展开每一步都给出可以直接照着改的做法。2. 需求与选型从工艺流程图倒推点位表、刷新周期与变量类型组态项目最常见的返工不是画面画得丑而是点位表一开始就没理清。画面做到一半发现某个设备少了一个就地/远程信号或者模拟量没定义量程回头补的时候变量名已经铺满了整个工程改一个要牵动十几个画面。所以这一章先把三件事定死有多少点、多久刷新一次、每个点归哪一类变量。2.1 从工艺流程图倒推点位表正确的顺序是先在纸上画一遍工艺流程图把每一台设备、每一个检测点、每一条管线上的阀门都标出来再从图上往下摘点位。图上没有的东西画面上也不该出现图上有的东西漏摘了后面画面一定缺一块。这个顺序听起来笨但它能保证画面和现场是一一对应的而不是想到哪画到哪。摘点的时候按设备归类一台典型的离心泵通常需要这么几个信号运行反馈、故障反馈、启动输出、停止输出、就地/远程状态有条件再加电流和运行时长。一个模拟量检测点需要位号、描述、数据类型、读写方向、量程上下限、工程单位、报警上下限、所属画面。这些字段在点位表里一个都不能省尤其是量程和单位——现场见过太多把 0 到 1.6MPa 的压力按 0 到 100 显示的画面操作工看一眼就不信这套系统了。一张可以直接用的点位表长这样位号描述类型读写量程单位报警限画面归属Pump1_Run1# 进料泵运行反馈离散读---单元画面Pump1_Fault1# 进料泵故障离散读--高单元画面Pump1_Cmd1# 进料泵启停输出离散写---设备面板Tank1_Level1# 罐液位实型读0~100%高 85 / 低低 15总貌画面Line1_Flow进料流量实型读0~50m³/h高 45单元画面表格里画面归属这一列很多人会省掉省掉之后画面上就会出现同一台泵在三个画面里都有按钮、状态却不同步的情况。归属定清楚一个设备只在一个层级上操作其他层级只读。2.2 刷新周期与通讯负载的确定把所有点都设成 100 毫秒刷新是新手最容易翻车的地方。刷新周期不是越短越好它直接决定通讯链路的负载点位数乘以每点字节数再乘以每秒刷新次数就是链路要承受的流量。一条几百点的工程全部按 100ms 刷链路占用会翻好几倍表现就是画面上的数值一顿一顿地跳或者干脆整片变灰。实际项目里我一般按数据的变化速度分档开关量状态和按钮输出 500ms 到 1s压力、流量这类模拟量 1s液位、温度这种惯性大的量 2s 到 5s累计量和电量统计 5s 以上。这样分完之后真正需要高频的点通常只占总数的两成链路压力立刻降下来。模拟量还要配死区Deadband。死区的作用是让数值变化小于某个阈值时不触发刷新和报警判断避免一个稳定在 50.0% 附近的液位在 49.98 和 50.02 之间来回刷屏也避免报警反复动作。液位这种量我一般给量程的 0.5% 到 1%压力给 0.2% 左右。死区给大了会掩盖真实变化给小了等于没给这个值只能在现场调。2.3 三类变量的分工I/O 型、内存型和间接型InTouch 的变量分三类用错了后面到处是坑。I/O 型变量直接绑定现场设备的访问名和项名它的值受通讯状态影响通讯断了值就不可信内存型变量活在组态软件内部用来存中间运算结果、画面状态、配方缓存间接型变量本身不存值它的内容是另一个变量的名字运行时指哪打哪。I/O 型负责和现场打交道命名建议带上设备前缀和信号含义比如Pump1_Run一眼能看出是哪台设备的什么信号。内存型建议统一加前缀区分比如M_或者HMI_避免和 I/O 变量混在一起后期查变量的时候能省很多时间。间接型是整套方案里最值钱的一个技巧。它让一套设备面板可以复用到八台泵上而不用画八遍。做法是定义一个间接离散变量Pump_State它的内容在运行时被改成具体的标签名{ 窗口脚本 On Show根据设备索引切换间接变量的指向 } { EquipIndex 是内存整型取值 1~8对应八台泵 } { 传入 1 时 Pump_State 指向 Pump_1_Run传入 2 时指向 Pump_2_Run } Pump_State Pump_ StringFromIntg(EquipIndex, 10) _Run; Pump_Fault Pump_ StringFromIntg(EquipIndex, 10) _Fault; Pump_Cmd Pump_ StringFromIntg(EquipIndex, 10) _Cmd; Pump_Current Pump_ StringFromIntg(EquipIndex, 10) _Current;这段脚本在设备面板窗口打开时执行一次把四个间接变量的内容改成当前设备对应的真实标签名。StringFromIntg(值, 进制)把整型转成字符串第二个参数写 10 表示十进制。要改设备数量只需要改EquipIndex的取值范围面板本身不动。提示间接变量指向的目标必须真实存在。如果Pump_9_Run没有定义面板上的状态灯不会报错它只会一直不亮排查起来很费时间。上线前把索引范围遍历一遍逐个确认目标标签存在。变量类型定完等于把整个工程的地基打完了。后面所有的画面、脚本、报警、趋势都建立在这张点位表和这套命名规则上这里省下的时间后面要几倍还回去。3. 画面架构设计四层画面树与一套可复用的设备面板画面做得乱通常不是因为不会画而是因为没有一个固定的层级。所有人各画各的最后总貌画面上有按钮、单元画面上也有按钮、设备面板上还有按钮三个地方的按钮绑的还不是同一个变量。这一章把画面拆成四层再把设备面板做成一套模板最后把脚本按职责分层让逻辑从画面里独立出来。3.1 四层画面树与导航路径第一层是总貌层一屏看完整条线只有设备状态色块、关键工艺参数和报警汇总不放任何操作按钮。第二层是单元层按工艺段划分比如进料单元、反应单元、出料单元每张画面上是这一段的流程图和可操作的设备。第三层是设备面板层一台设备一张面板包含启停、复位、参数设定、当前状态和故障原因。第四层是趋势与参数层历史曲线、报警记录、配方管理都挂在这一层。层与层之间的导航要固定。总貌点单元进单元画面单元点设备进设备面板设备面板上永远有一个返回上一层的按钮位置固定在同一角落。报警弹窗单独一套路径点报警直接跳到出问题的设备面板处理完再返回原画面不要打断操作员当前的操作。画面数量要控制。一个中等规模的工程总貌一到两张、单元五到八张、设备面板按设备类型做三到五套模板、趋势和参数各一到两张加起来十几张就够用了。画面一多维护成本是指数级上升的改一个配色要开十几张图。3.2 用间接变量把一套面板复用到八台泵设备面板的结构是固定的顶部是设备位号和状态灯中间是工艺参数和电流底部是启停按钮、复位按钮和故障原因显示。这一套结构做成一个窗口八台泵都用它靠的就是上一节说的间接变量。面板上所有绑定的变量都用间接变量包括状态灯、故障指示灯、电流数值、按钮的写入目标。窗口打开时由EquipIndex决定指向哪台泵关掉再打开另一台同一套画面复用。这里有个细节容易忽略故障复位按钮的权限。复位是一个有风险的动作不能谁都能点。面板上的按钮本身要做可见性控制同时在按钮的动作脚本里再校验一次权限两道关都要有。只做可见性的话换个分辨率或者用键盘操作就可能绕过去。面板做好之后剩下的工作只是把每台设备的EquipIndex传进去。传参的方式有两种一种是用窗口替代功能在打开窗口时把设备索引作为参数带入另一种是用一个全局内存变量存当前选中的设备号。前者干净后者简单工程不大的话后者够用。3.3 脚本分层把联锁从画面里赶出去组态项目里最危险的一种写法是把设备联锁写在画面的显示动画或者按钮的可见性表达式里。画面一关脚本就不执行了操作员切到别的画面联锁就失效了。这种问题在现场很难复现因为只有在特定操作顺序下才会出现。正确的做法是按执行时机把脚本分三层。设备联锁层放在应用脚本和条件脚本里只要工程在运行就一直在跑和画面开不开没关系画面交互层放在窗口脚本和按钮的动作脚本里负责打开窗口时初始化、点击按钮时校验记录层放在数据变化脚本里某个值变了就写一条日志不参与控制。条件脚本的典型用法是设备联锁{ 条件脚本1# 进料泵联锁执行周期设为 500ms } { 触发条件Pump1_Fault 或 Tank1_Level 满足判断 } { 作用无论当前打开哪张画面联锁始终生效 } IF Pump1_Fault 1 THEN Pump1_Cmd 0; { 故障时强制断开输出 } Pump1_TripReason 1; { 记录跳闸原因1 设备故障 } ENDIF; IF Tank1_Level Tank1_LL THEN Pump1_Cmd 0; { 液位低低时停泵防止干转 } Pump1_TripReason 2; { 记录跳闸原因2 液位低低 } ENDIF; IF Pump1_Cmd 0 AND Pump1_Run 1 THEN Pump1_StopDelay Pump1_StopDelay 1; { 输出断开但反馈仍为运行累计超时 } ENDIF;这段脚本放在应用级别的条件脚本里执行周期设成 500ms。Pump1_Fault、Tank1_Level、Tank1_LL都是前面点位表里定义好的标签Pump1_TripReason是一个内存整型用来在面板上显示为什么停的——这一点很关键操作工看到泵停了但不知道为什么停第一反应就是再按一次启动容易出事。最后一段的Pump1_StopDelay是一个简单的反馈校验输出已经断开但运行反馈还回来说明接触器粘连或者反馈信号有问题累计到一定次数就该报警了。这类判断放在画面脚本里必丢放在条件脚本里才可靠。脚本分层之后画面只负责显示和交互逻辑全在底层跑。带来的直接好处是改联锁不用动画面改画面不用担心碰坏联锁。4. 关键功能实现报警分级、历史趋势、配方下发与操作留痕画面能看只是及格线一套 HMI 真正被现场接受靠的是报警别乱叫、趋势查得到、参数改得对、出了事能追溯。这四件事对应四个功能模块每一个都有具体的配置参数和实现要点。4.1 报警分级优先级、死区与抑制窗口报警最常见的失败是狼来了——一天几百条报警操作工直接把声音关掉真正重要的那条也就淹在里面了。解决靠三件事分级、死区和抑制。分级按后果分不按信号类型分。我一般分四档等级优先级范围典型信号颜色声音是否记录是否推送值班紧急900~999液位低低、联锁跳闸、通讯中断红闪连续音是是重要700~899压力高、温度高、设备故障红间断音是是一般400~699液位高、流量偏差黄单次音是否提示1~399设备切手动、配方下发完成蓝无是否优先级数字本身没有含义重要的是同一档内部保持一致别出现两个同样严重的信号一个 950 一个 500。死区解决抖动报警。一个压力稳定在报警限附近时数值在限值上下小幅波动会让报警反复产生和消失日志里刷出一大片。给这个点设一个死区比如量程的 0.5%报警产生后要等数值回落到限值以下一个死区才消失中间不重复报。死区的值写在点位表里和报警限一起维护。抑制解决检修期误报。设备检修时拆掉传感器信号必然异常这时候报警没有意义。做法是给每个报警组配一个抑制开关检修前操作员在画面上把这一组抑制掉抑制期间报警不产生声音和推送但仍然记录检修结束后手动恢复。抑制开关本身要有权限控制并且要记录是谁在什么时候抑制了哪一组。4.2 历史趋势先决定存什么再决定存多久不是所有点都值得存历史。全存的话数据库膨胀很快查询变慢最后没人愿意打开趋势画面。判断标准很简单这个点在事后复盘时会不会被问到。设备的运行反馈、故障信号、关键工艺参数、设定值变更这些要存画面状态、按钮中间量、报警确认标志这些不存。存储周期分三档开关量和关键模拟量 1s一般模拟量 5s累计量和统计量 1min。存储时长按工艺周期定批次生产一般存三到六个月连续生产存一年。容量估算的方法是点位数乘以每秒样本数乘以存储秒数再乘以每条的字节数算下来通常比想象的小真正的压力在查询而不是存储。历史数据落在关系库里之后趋势画面之外的很多报表可以直接用 SQL 出。比如查某台泵最近八小时的运行时长和启停次数-- 查询两台泵最近 8 小时的运行样本数与启动次数 -- History 是历史库里的明细表字段名按自己的库替换 SELECT TagName, COUNT(*) AS SampleCount, SUM(CASE WHEN Value 1 THEN 1 ELSE 0 END) AS RunSamples, SUM(CASE WHEN Value 1 AND PrevValue 0 THEN 1 ELSE 0 END) AS StartTimes FROM ( SELECT TagName, Value, LAG(Value) OVER (PARTITION BY TagName ORDER BY SampleTime) AS PrevValue FROM History WHERE TagName IN (Pump1_Run, Pump2_Run) AND SampleTime DATEADD(HOUR, -8, GETDATE()) ) t GROUP BY TagName;LAG取同一标签的上一条记录用来判断 0 到 1 的跳变跳变次数就是启动次数。SampleTime的区间条件一定要写不写会全表扫。表名和字段名在不同历史库配置下不一样替换成自己的视图名就行。这条 SQL 出来的数字可以直接贴进交接班记录比让操作工自己数要可信。4.3 配方下发写入前校验写入后回读配方功能的价值在于把一组参数一次性下发减少手工逐个输入的出错概率。但它同时也是最容易出事的地方参数下发了但设备没收到画面显示的是新值实际运行的还是旧值。下发的流程固定四步校验前置条件、写入、回读、确认。前置条件包括权限、设备是否在自动模式、是否有未确认的报警。写入之后不能直接认为成功要延时回读一次把现场实际值读回来和设定值比对一致才提示成功。{ 按钮动作脚本配方下发 } { 前置校验权限、模式、报警状态三项都过才允许写入 } IF $AccessLevel 5000 THEN LogMessage(配方下发被拒绝权限不足当前级别 StringFromIntg($AccessLevel, 10)); ELSE IF Unit1_AutoMode 1 THEN LogMessage(配方下发被拒绝设备处于自动模式请先切手动); ELSE IF Unit1_AlarmActive 1 THEN LogMessage(配方下发被拒绝存在未确认报警); ELSE Recipe_Temp_SP Recipe_Table_Temp; { 写入温度设定值 } Recipe_Time_SP Recipe_Table_Time; { 写入保温时间设定值 } Recipe_WriteFlag 1; { 置位由条件脚本延时回读 } ENDIF; ENDIF; ENDIF;$AccessLevel是内置变量当前登录用户的访问级别数值越小权限越低。LogMessage()把文本写进日志文件出问题的时候这条记录就是证据。Recipe_WriteFlag置位之后由一个条件脚本在两秒后把设定值和反馈值做比较不一致就把标志清掉并弹提示一致才把界面上的下发成功点亮。三层IF嵌套看着啰嗦但每一层拦住的问题都不一样而且被拦下来的时候日志里都有明确原因排查看日志就行不用去猜。4.4 操作留痕谁在什么时候把哪个值从多少改成了多少操作记录不是给审计看的是给自己看的。现场出现这个设定值怎么变成这样了的疑问时能查到人、时间、原值、新值事情五分钟就能说清查不到就要开会。实现方式是用数据变化脚本监听每个需要留痕的设定值值一变就写一条日志。写入的目标可以是日志文件也可以是数据库表。日志内容至少四要素操作员、时间、变量名、原值到新值。{ 数据变化脚本液位设定值修改留痕 } { 触发时机Operator_Level_SP 的值发生变化 } IF Operator_Level_SP Operator_Level_SP_Old THEN LogMessage(液位设定值修改 | 操作员 $OperatorName | 时间 $DateString $TimeString | StringFromReal(Operator_Level_SP_Old, 1) - StringFromReal(Operator_Level_SP, 1)); Operator_Level_SP_Old Operator_Level_SP; { 更新旧值避免重复记录 } ENDIF;StringFromReal(值, 小数位)控制小数位数$OperatorName、$DateString、$TimeString都是内置变量。Operator_Level_SP_Old是一个内存实型专门存上一次的值这一句不能漏漏了日志会重复刷。留痕的范围要克制。把所有变量都监听一遍日志文件会大到打不开。只监听设定值、配方参数、报警确认、模式切换、抑制开关这几类够用且清爽。5. 避坑与排查联锁误动、通讯闪断与脚本不触发的现场处理组态项目上线前跑得好好的上线后开始出各种偶发问题这些偶发问题九成集中在这几类。下面每一条都是现场真实出现过的按现象、原因、解决三段写。5.1 逻辑与脚本类问题现象一操作员切到别的画面后泵的联锁不动作了切回来又正常。原因基本可以锁定为联锁逻辑写在画面脚本里。窗口关闭时窗口脚本停止执行联锁自然失效重新打开画面脚本恢复联锁又看起来正常了。这种问题在调试时很难发现因为调试的人通常一直盯着同一个画面。解决是把所有和设备安全相关的判断从窗口脚本挪到应用脚本或条件脚本里和画面生命周期彻底解耦。挪完之后做一次验证打开任意画面、关闭全部画面、锁定画面三种状态下分别触发一次故障信号看输出是否都被正确断开。现象二泵在自动模式下频繁启停日志里一分钟出现十几次启停记录。原因通常是数据变化脚本里直接写了输出而输入信号本身在阈值附近抖动。比如液位在低低限附近波动每次跌破就触发一次停泵回升后又被别的逻辑启动来回振荡。解决分两步输入侧加死区和延时确认信号要连续满足条件若干个扫描周期才认为是真输出侧加最小运行时间和最小停止时间启动后至少运行若干秒才允许停停了至少若干秒才允许再启。这两个时间参数要写进点位表的备注里别散落在脚本里。现象三权限设置好了但某些操作员还是能点到不该点的按钮。原因往往只做了界面可见性控制没做脚本内校验。可见性控制解决的是看不见解决不了点得到——分辨率变化、键盘操作、画面叠加都可能让按钮露出来。解决是双保险按钮可见性按$AccessLevel控制按钮的动作脚本第一句再判断一次$AccessLevel不满足直接LogMessage记录并返回。两次判断的成本很低漏一次的成本很高。5.2 通讯与数据类问题现象四模拟量在 0 和满量程之间来回跳或者一直卡在一个不动的值上。前者一般是通讯闪断时 I/O 变量被清零后者是通讯断了但变量保留了断线前的旧值。两种表现不一样根子是一个画面没有判断数据到底是不是有效的。解决是加一个通讯状态判断。让现场设备每 500ms 翻转一个心跳位画面上用条件脚本盯着这个位超过若干个周期没翻转就判定通讯异常把所有相关数值置灰并显示通讯中断而不是继续显示一个可能是假的数字{ 条件脚本通讯状态监视执行周期 500ms } { PLC_Heartbeat 由现场设备每 500ms 翻转一次 } IF PLC_Heartbeat PLC_Heartbeat_Last THEN CommFailTimer CommFailTimer 1; { 心跳没变计数加一 } ELSE CommFailTimer 0; { 心跳变化计数清零 } PLC_Heartbeat_Last PLC_Heartbeat; ENDIF; IF CommFailTimer 6 THEN CommOK 0; { 连续 3 秒无心跳判定断开 } ELSE CommOK 1; ENDIF;CommFailTimer 6对应 3 秒这个阈值按现场网络质量调太灵敏会误判太迟钝会滞后。CommOK这个内存离散变量要挂到画面上的数值显示动画上为 0 时整个数值区置灰。现象五历史趋势里出现一段直线或者一段空白。直线通常是历史采集服务重启后继续用旧值填充空白是采集中断。原因多半是历史采集周期和 I/O 刷新周期不匹配比如 I/O 每 5 秒刷新一次历史每 1 秒采一次中间四次采到的都是同一个值画出来就是台阶状。解决是对齐周期历史采集周期不小于 I/O 刷新周期并且给历史记录加时间戳校验相邻两条记录时间戳相同就丢弃。趋势画面上同时显示数据点密度操作工看到一条完全平滑的直线时能立刻意识到这可能是假数据。注意以上五条里有四条的共同点是调试时看不出来。所以联调阶段一定要做故障注入主动制造断线、断电、信号超限而不是等它自己发生。6. 验收与答辩用点表、三轮联调和故障注入证明这套画面真能用画面画完、脚本写完不等于可以交付。验收要拿证据说话最省事的方式是做三轮联调每一轮都有明确的通过标准最后再补一轮故障注入。第一轮是单点调试逐点核对。对照点位表一个人在现场改信号一个人在中控看画面逐个确认数值对不对、单位对不对、量程对不对、报警限到没到、动作方向反没反。这一轮最常见的问题是量程和单位填错还有开关量的 0/1 含义搞反。通过标准是点位表上每一行都打勾。第二轮是联动调试按工艺顺序走一遍完整流程。从进料、升温、保温到出料每一步确认设备动作顺序正确、联锁条件生效、面板状态跟随。这一轮要记录每个动作的响应时间从点击按钮到现场设备动作超过两秒就要查原因。通过标准是流程走通且没有卡顿。第三轮是故障注入主动制造异常。断网线、断设备电源、把模拟量信号拉到超量程、把液位降到低低限看画面是否在预期时间内给出正确反应通讯中断提示是否出现、联锁是否断开、报警是否分级正确、是否记录了跳闸原因。这一轮是验收里最有说服力的部分也是答辩时最容易被问到的部分。一份可以直接用的验收记录表长这样验收项方法通过判据点位准确性逐点核对点位表全部点位数值、单位、量程一致报警分级逐个触发各等级报警颜色、声音、记录、推送与分级表一致联锁有效性打开/关闭/锁定画面各触发一次三种状态下输出均被正确断开通讯中断拔掉通讯线等待 5 秒3 秒内出现中断提示数值置灰权限控制用低权限账号点击受限按钮按钮不可见且脚本日志记录拒绝原因操作留痕修改一个设定值后查日志人、时间、原值、新值四项齐全趋势完整性回放最近 8 小时曲线无直线段、无空白段、无重复时间戳答辩的时候与其把画面从头到尾点一遍不如直接演示故障注入。把通讯线拔掉让评委看画面在几秒内变灰并弹出提示把液位信号拉低让评委看泵自动停下并在面板上显示跳闸原因液位低低。这两下比讲十分钟架构有用得多因为它证明的不是我会画图而是我知道这套东西在异常时会怎么表现。这套实例的画面备份、点表模板和脚本清单我整理成了一个工程包拿到之后建议先干一件事把点表里那二十几个位号替换成你现场的实际位号再打开画面看哪些链接断了。断掉的地方就是你需要重新绑定的变量比从零画一遍快得多也比照着别人的截图临摹靠谱。从那以后我每次做完一套组态交付前都强制走一遍故障注入哪怕工期再紧也不跳过。因为画面好看是给检查的人看的异常时的表现才是给现场操作工用的。希望帮到你。本文还有配套的精品资源点击获取

InTouch组态实战：点位表、脚本联锁与故障注入验收

相关推荐

GLM-5.3安全策略适配指南：用prefill与chat-template解锁专业场景

技术博文创作规范：如何基于真实可信信源构建专业内容

Stanley算法与CarSim-Simulink联合仿真实现车辆横向控制

更多资讯

PCB设计规范深度解析：从网络表到布局布线的工程机制与电磁学原理

数码摄影中深度信息丢失的原因与还原技术

Java工程师AI应用开发指南：LangChain4j从入门到生产实践

操作系统内存管理第十七章答案精讲：地址转换、多级页表与TLB计算题解析

工业机器人标定技术：从基础原理到前沿应用

手机GUI Agent双通道感知：无障碍树与投屏像素融合方案

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？