工厂数字化

页面再顺、大屏再快，策略该不该上线还是得看那 0/12 已平交易——结论是：还不能。 今天这一天的活很杂，上午接着搞 factor_ic 的 A/B 看板，下午被工厂大屏的前端问题打断，晚上又拉了一轮策略数据，结论反而比白天改的代码更重要。 一、先把 factor_ic 的回测结论摁在桌上上午有人问 factor_ic 的回测结果怎么样、当前运行情况怎么样。我第一反应就是当前运行必须实拉，不能凭记忆，尤其要确认 SHORT-only A/B 切了 17 小时后有没有 LONG 漏进来。回测结果是历史事实，可以看落盘记录，但运行状态必须实时。 实拉核验后，回测结果本身是清楚的：12 币全池、5000 根 1h K 线约 208 天，无前视。全样本 338 笔，**总收益 -16.5%，单笔均值 -0.053%，胜率 49.4%**。拆开看：LONG 腿 169 笔 **-38.1%**，SHORT 腿 169 笔 **+34.9%**。这个对比已经很说明问题了。 但更让人警觉的是别人给过来的判断——方向对、核心 caveat 对，却有 5 处实质错误，其中 ...

"管道不是没接，是接了但死了8天没人发现"——这句话比任务描述里写的严重得多，也决定了这天所有动作的优先级。 翻开 factor_ic.db 一看，心里就咯噔一下。任务描述说管道没接，可实际查下来根本不是没接，是接了但早死了。后面还冒出一个 Streamlit 报错，根因居然是本地的 watchdog.py 把第三方包给遮蔽了——两件事串在同一天，都是典型到不能再典型的坑。 一、factor_engine：硬编码死代理断粮8天先看数据库。factor_ic.db 最后成功写入停在 07-31，08-01 到 08-06 的日志全是 502 和连接重置。翻代码找病灶，死因是 127.0.0.1:7890 这个硬编码死代理——和 08-07 那批 ProxyError 是同一个病根。更要命的是，没有任何调度器在跑它，所以断了 8 天完全没人发现。 factor_ic 表里 MIN run_iso=2026-07-30，MAX 之前卡在 07-31，这次补齐到 1596 行。断粮这 8 天，IC 管道等于完全没供数，而下游因子实验还在傻等。 二、修三件事，逐条实拉才点头第 ...

自己写的东西，自己最不容易看出问题 那天没写新功能，做了两件更基础的事：给一套自己写的 Streamlit 做代码体检，再把另一个小项目的架构摊开看一遍。都是"回头看"的活，比往前冲更难受，但也更有用。 第一件：给效率分析系统做个体检被体检的是一个 290 行的 Streamlit 应用——效率分析管理系统。结构其实挺清楚，一共七个区块： 页面配置（7-13 行） 样式注入（15-35 行）—— 自定义 CSS，用 unsafe_allow_html 常量定义（37-52 行）—— 硬编码了 D:\work 路径和三个 Excel 文件路径，三组列名 Session State 初始化（54-69 行）—— 把三个表读进 session_state 工具函数（71-98 行）—— DataFrame 转 Excel bytes、校验列名后导入 主界面三个 Tab（106-282 行）—— 每个 Tab 都是"导入/导出/在线编辑" 页脚（284-289 行） 功能上没毛病：三表管理、Excel 导入带列名校验、导出、da ...

数据频率一换，累计算法不换，报表就是 100% 假象。 今天这一天基本都耗在 factory_api_server.py 和前端报表上。数据库从旧表 work_load 切到新表 work_load_0521，本来以为只是换个连接串，结果时间字段从时段变成每 10 秒一条快照，利用率算法也跟着塌了，改到第三轮才把口径理顺。 一、新表 work_load_0521：TIME 是单点快照，不是 START/END拿到的新库配置很直接：100.64.0.2:3306，表名 work_load_0521，每 10 秒记录一次人员及工时。字段里 TIME 代表记录时间，worker_num 是人数，workload 是总工时，area 和 main_area 保持原意。 跟旧表 work_load 放一起，差异一眼就能看出来： 维度 旧表 work_load 新表 work_load_0521 时间 START_TIME / END_TIME TIME（快照单点） 工时 WORKTIME（秒） 无此字段，WORKLOAD 为累计值 频率 不定时 10 秒一 ...

这天最关键的判断：改了后端代码不重启 Flask，页面永远还是旧数据。 上午接到的需求是把一张静态的 factory_dashboard_dark.html 塞进真实数据库里的产线工时数据，还要动态实时刷新。最后折腾到傍晚，主要精力没花在写 SQL 上，全花在“我以为改了就应该生效”上了。 一、从一张静态 HTML 到一个 Flask API 服务原始素材很明确：数据库在 100.64.0.2:3306，账号 ***（空密码，内网测试库），库名 m3_ai_data，表 work_load，字段有开始时间、结束时间、worker_num 人数、worktime 工时、workload 总工时。area 字段里五个工位代码分别是 SCBX（上层布线）、SCZZ（上次组装，素材里是打字笔误，我直接按原文记录）、DCZZBX（底层组装布线）、GJQ（工具区）、ZCZZ（中层组装），总区域 main_area 的 TST1 代表 M3 手工流水线。 浏览器本身不能直连 MySQL，所以当天定下的架构就是两文件方案： factory_api_server.py：Flask 本地服务，端口 87 ...

看板改版最怕的不是改颜色，是改完图别人看不懂。 今天一整天都耗在工厂数字大屏上。上午刚把整套 dashboard 从中车蓝换成了莫兰迪配色，下午用户一句话就把时间轴里的工位作业甘特图判了死刑，只能当天返工重做。 一、上午：莫兰迪配色版先落地上午的活儿比较顺，主要就是把工厂 dashboard 的整体视觉从中车蓝换成莫兰迪色系。助手把每一处颜色都列了对照表：Header 从原来的 #0066CC 深蓝渐变，换成了 #6B7D8F → #B8A9C9 的蓝灰到紫灰渐变；背景从冷白 #F5F7FA 换成暖灰米色 #F0EDEB；主色调从饱和蓝换成低饱和蓝灰 #8B9DAF。图表颜色也改成了蓝灰、绿灰、暖橙、紫灰、玫瑰这种多色系，状态标签换成雾绿 #8FAE8B 和暗玫瑰 #C4908F，热力图渐变从蓝白改成暖灰白到莫兰迪绿再到深蓝灰。 功能上没动任何东西，四个标签页、6 路摄像头 Canvas 预览、24h 热力图、桌面与移动端切换，全部保留。文件最后落到了 D:\factory_dashboard_morandi.html，也就是 cpolar 服务目录，附件也投递过去了。 二、下午：用户 ...

需求很简单：让工时自己说话，别再靠人抄 车间里的工时数据是有的——机器一直在采，落在 MySQL 里。问题是没人看。数据躺在表里，要问产量就得有人去查、去汇总、去做表。信息在，但不在需要它的人眼前。 这块看板就是为了把这句话反过来：数据在哪儿产生，就在哪儿显示。 先看数据长什么样第一步永远是看表结构，而不是先想界面。 表是 work_load，在一台早期的 MySQL 上（100.64.0.2:3306，库叫 m3_ai_data）。字段不复杂： 字段 含义 START_TIME / END_TIME 一段工作的起止 WORKER_NUM 工位编号 WORKTIME 工时，单位秒 WORKLOAD 工作量，单位人·秒 AREA / MAIN_AREA 区域 / 主区域 两个细节后来证明很关键：工时是秒不是分钟，**工作量是"人·秒"**。也就是说，同是一小时，两个人干出来的是一个人的两倍——这一条决定了后面所有图表的口径。 还有一点，这几个字段都是 varchar。数值存成字符串，意味着不能在 SQL ...