MES报表WORKER_NUM口径反了,工位利用率被除成零(2026-09-14)
不要急着改前端,先拿 SQL 把 572 万行逐行比对钉死——老表的 WORKER_NUM 就是真实人数,上一版却按 ×10 把它除成了 0。
2026-09-14 这天挺满。上午刚把 Hyperliquid testnet 的 drift 3341.32% 告警挂出去,下午就被叫去修一个 MES 报表:工位利用率、出勤时间、有效工时,显示得全不对。表面看是前端渲染有问题,实际一查,口径从根上就反了。
一、问题现象:所有指标都长得不对劲接下活的时候,用户给的是 100.64.0.2:3306 上 m3_ai_data 库的 work_load_0521 表,里面有示例数据。前端报表展出来的工位利用率、出勤时间、有效工时,没一个看着合理。当时我没急着动逻辑,先让脚本把表的概况拉出来。
这一拉就发现问题不小:
AREA 一共 14 个,前端只认 5 个;
MAIN_AREA 分布是 TST1 约 450 万行、TST2 约 77 万行、TST3/TST4 各约 22 万行;
WORKER_NUM 的值是 '0'~'7',看着像真实人数,但我们上一 ...
smart-money 零成交根因是自家 SDK 方法名写错,开源五模块搬进 live(2026-07-29)
自己上一轮为修幽灵持仓写的补丁,才可能是最新的坑;而所谓的“成熟开源项目”,不一定要替换你,把数学和沙箱拆下来就能用。
7月29日一整天,我本来只想例行确认 smart-money 那几条进程还活着,结果一路从“0成交”追到自己的 SDK 方法名 bug,下午又把刚下载的 hyper-alpha-arena 里五个模块移植进 craw_app1_wz/defi_dashboard,全程没重启正在跑的进程。
一、先查“活着”不等于“能用”:17小时0成交的真凶是我我先把全部信号系统和数据库的实际运行状态验了一遍,不是只看进程在不在。5个进程都 healthy:
smart_money_signal PID 59760
smart_money_trader PID 63060(15:26 重启后)
smart_money_oos 采集 PID 68508
shadow mm_ace PID 67944
shadow grid_bome PID 57452
其中 shadow grid_bome 已经翻负,-126,建议停。真正刺激的是,smart_money_signals_lates ...
过夜数据反转,KAITO做市从幸存者变毒性流,网格加注(2026-07-27)
这一天最关键的判断是:过夜数据把昨天的“唯一幸存者”KAITO 做市判了死刑——它不是利润来源,而是毒性流陷阱;真正该加注的是被当成对照的网格。
早上先处理一个关于“全改 maker 挂单、用主网数据近态回测小资金”的想法,我当时影子进程已经跑了一天多,手上第一次有“过夜”的真实主网数据。就用这份数据把盘面重新捋了一遍。
一、资源盘点:6 个进程,8 个库,方向性策略全灭先确认家底。主网只读行情管道(l2Book/recentTrades/funding,零私钥)、修正后的记账引擎、v4 回测框架、9 道闸门审计技能、view19 页面,这些基础设施都能继续用。跑着的影子有 6 个,5 个做市加 1 个网格,落在 8 个 SQLite 库里。
之前已经证伪的方向比较惨:combo、趋势、择时、ETH-BTC 配对、跨所(不可执行)——方向性策略一个没剩,只剩 maker 侧。顺手写了个 shadow_report.py,以后一条命令就能出全库对账报告,不用每次手动拉数。
二、过夜数据反转:KAITO 做市从幸存者变毒性流陷阱拿到过夜数据后,把昨天还在盘面上活着的策略 ...
Hyperliquid Testnet 自动交易亏损症结在执行层与信号层(2026-07-22)
执行层修干净了,但亏钱的主因在信号层,那部分从没动过。
这一天起因很简单:有人问 C:\Users\Administrator\Documents\craw_app1_wz 项目第18页 Hyperliquid Testnet 自动交易,开多和开空是不是都会开仓。我顺着这个问题一路读代码,最后发现这个项目的问题不在开仓方向上,而在执行层和信号层,而且执行层的坑一个个都踩得很实。
一、先确认“开多开空都会开仓”用户问的第18页对应 views/18_hl_testnet.py,核心交易逻辑在 strategy_engine/hl_trader.py。我全项目搜了 Hyperliquid、Testnet、开多、开空,然后读开仓逻辑和信号生成。
证据链逐步收拢:_score_symbol(388–395 行)里 score >= COMBO_THRESHOLD(=1) 产出 BUY(开多),score <= -1 产出 SELL_SHORT(开空)。信号列表 scored 在 984–989 行遍历所有币种,把 SELL_SHORT 也一并收进去,没有过滤。主循环 1067 行 ...
五个项目并线后的目录端口数据库现状盘点(2026-06-04)
手上的东西一多,就需要有人替你说清"你现在在忙什么"
那天做了一次盘点。原因不复杂:项目加到了五个,彼此的目录、端口、数据库、口径都不一样,脑子里那本账开始记不牢了。
五个项目① 工厂仪表盘(Flask)
跑在内网,看板在 10.103.54.6:8765,数据来自 10.103.50.147 上的 MySQL,另外还接了一路视频流(10.103.65.30:8080)。核心表是 work_load_0521,10 秒采样一次。
② 工时报表系统(Streamlit)
这个更贴近"发工资"这件事。一共 16 张表:表 1 到表 15 是工时子表,字段统一 18 列(班组、姓名、员工编号、各类工时、薪酬发放工时的口径都在里面);表 16 是人员打卡记录汇总,读的是 MySQL 的 peo_working_time。
本地库是 localhost:3306,root 无密码只读。
③ yiso.fun 爬虫 —— 用 DrissionPage 写的那套。
④ 知乎热点自动化 —— 前面刚被平台拦了一次的那条链。
⑤ Hexo 博客 —— 就是这个站 ...
python输入实物码记录网卡IP及MAC地址
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960import psutilimport pymysqlimport datetimeimport sysdef insent_db(adapter, mac, ipv4, swcode, sent_time): try: db = pymysql.connect(host="10.103.50.147", port=3306, user="crrcuser", password="abc.123456", database="gsdata", charset="utf8") cursor= db.cursor() db.ping(reconnect=True) ...
python基于cv2图像超分辨率重建
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566def img_chuli_plt2(): import cv2 import random # import imutils import numpy as np # 彩色图像每个像素值是[x,y,z], 灰度图像每个像素值便是一个np.uint8 path = './img/0.jpg' # 路径图片 image = cv2.imread(path) gray_img = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) # 图像大小调整 ori_h, ori_w = image.shape[:2] height, width = gray_img.shape[:2] image = cv2.resize(image, ...
微软 OneDrive 商用版挂载个人电脑,替代百度网盘限速
就是大名鼎鼎微软的OneDrive话说国内的网盘市场已经被百度网盘垄断了百度网盘不付费的话,下载速度没得说,慢的一比唯一的好处就是资源多大家都在百度上分享链接例如,云盘狗百度大而不倒
OneDriveOneDrive好处就是有Office365,办公同步真方便然后空间巨大,不限速一定要taobao买一个商用版的,个人版的被墙了找一个销量好的,5T空间也就20块我买了一个25T的然后用了RaiDrive_1.8.0挂载到个人电脑上注意了一定要RaiDrive_1.8.0,不然没有写权限
OneDrive可以做私人网盘搜索私人网盘搭建,网络上一堆堆攻略。按照之前的经验来看,需要云服务器,开个新账户阿里腾讯云,买三年很便宜,博主都已经玩过一遍了。推荐:Cloudreve
Web3存储前几年Web3大爆发的时候,Web3存储横空出世,File这个cx币,刚出来的时候起飞上天,被称为以太之后的币⚪第三次创新革命。从叙事上来说,Web3存储有些亮点,AR(arweave)通过简化数字世界 一次付款, 永远存储 ,数据可以维持200年,比只能维持20年的web2,超出一个数量级。到底是画饼,还 ...
xLog+Crossbell区块链
起因
技术人员的方法
从IPFS直接访问
更好的永久存储
感想
xLog,Crossbell区块链最近偶然看到了一个很有意思的东西,叫xLog,大概试了试,这是在一条叫Crossbell的区块链上使用智能合约操作和存储元数据,并把实际数据存到IPFS上的项目。看了一眼还挺有意思,就在上面搭了一个自己的另一个博客,另外他们还使用这套方案写了一个类似Twitter的社交系统,也叫Crossbell,非常的人性化,可以说是把Web3真正的带给了普通用户。至于怎么搭他们的项目成员写了篇教程,5分钟就能搭好在Web3的博客。不过使用xLog那就不是技术人员的事了,而是让一个不怎么懂电脑的人来做的事情了。另外他们宣称数据是“Permanently stored on the blockchain”这一点我不太认同,要是说存到了Web3成为了其他人无法修改的数据,这倒是没什么问题,但是存到IPFS上只要没有被Pin,就有可能在节点GC的过程中永远消失。另外我其实对区块链接触不多,不清楚能不能完整的同步他们的链,如果不能那就是私链了,那样元数据也不能永久保留了……所以我只能说这个平台是Web3,可 ...
ForeverBlog
一想起永久,我就想起王菲的歌有时候有时候 我会相信一切有尽头 相聚离开都有时候 没有什么会永垂不朽
我不能避免死亡,我害怕死后什么都没有留下来。
作为默默无闻的一人,没有什么闪耀,慢慢的也过了创造奇迹的年纪,我的世界一片黑暗。
想来想去,只能用老本行,科技改变命运!
曾经看过一个老美电影,就是一个极客得了绝症,为了家人,然后把自己的意识上传网络,让自己完全活在了网络中,家人还可以和网络中的极客对话。有一段时间有新闻说,可以使用AI重建去世亲人,我觉得都是同一类事情。
现阶段我只懂一些鸡肋IT,就做一个简简单单的Forever Blog吧,后面再慢慢完善下去!
现在我一个人更新Blog,以后可能会告诉家人,可以合力把Blog更起来。既然是Forever Blog,能子子孙孙的更新下去,也是奇迹呢。
作为永生博客,我简单的想法就是百年之后,博客仍然可以运行,哈哈😝,这样就可以让世人知道,曾经世上还有这人这事存在过!