五个项目并线后的目录端口数据库现状盘点（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 博客 —— 就是这个站 ...
知乎自动发布账号被判 AI 限制七天，403 权限异常（2026-06-03）
自动化跑到一半，被平台自己的那道门拦住了
知乎热点自动发布这条链，我已经跑了一段时间了。选热点、生成封面、发布，三步走，一直挺顺。直到这天早上，第三步不走了。
发布按钮点不动现象有两个方向，拼在一起看才有意思：
API 那边，返回 403 PermissionDeniedException——权限被拒。浏览器那边，点"发布"按钮，没有任何反应。
不是超时，不是网络问题，就是点下去没反应。按钮还在那儿，但它的作用已经没了。
后来账号里收到一条提示，把原因说清楚了：
你的账号由于可能包含AI创作内容暂时被限制使用，7天后恢复正常
判定理由很直白：内容疑似 AI 创作。预计恢复时间是 2026-06-10。
这件事的荒诞之处我得承认，看到这条提示的时候，第一反应是有点想笑。
这条链子里，热点是真的（来自公开的热榜接口），封面是真的（用即梦 AI 生成的图），内容也是我盯着改过的。但平台不去看内容本身，它看的是"这篇东西长得像不像 AI 写的"——而自动化发的稿子，天然长得就像。
这是个结构性的矛盾：自动化最大的优势是稳定和批量，而"稳定 ...
Hermes 0.14.0 终端命令闪黑窗，上游 0.15.0 已修复该问题（2026-06-01）
如果你发现自己在打补丁，先退一步：上游修了吗
那天要解决的毛病很小——小到可以忍，但每次都在提醒你它的存在。
那个一闪而过的黑窗口现象是：每执行一次终端命令，屏幕上就闪一下黑色的 cmd 窗口。
它不影响结果，命令照跑，输出也正常。但一天下来闪几百次，人会烦。更要命的是它给人一种"这东西没做干净"的感觉。
查下来是本地装的 Hermes 0.14.0（v2026.5.16，2026-05-18 发布）的一个已知 bug：Windows 上每次调用终端都会弹一个控制台窗口。
先查上游，再动手改第一反应当然是"把弹窗的地方关掉"——找到 Popen 的调用点，加个 Windows 专用的隐藏标志就行。
但我先多做了一步：去看看上游有没有修。
结果很干脆：这个 bug 在 0.15.0（v2026.5.28）里已经修了，做法是加了一个 windows_hide_flags() 的辅助函数。而当时 PyPI 上最新是 0.15.2（v2026.5.29.2）——本地落后了整整两个补丁版本。
那正确的修法就只有一条：
1pip install --upg ...
290 行 Streamlit 效率分析系统的代码体检与架构复盘（2026-05-28）
自己写的东西，自己最不容易看出问题
那天没写新功能，做了两件更基础的事：给一套自己写的 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 ...
内网 UI 报表部署卡在 CDN 与 localhost 两个老问题上（2026-05-25）
内网部署的坑，一半出在CDN，一半出在localhost。
今天从早到晚都在和工厂的UI报表较劲。本来以为只是把现有的外网版本改个数据库地址打包丢到内网服务器就完事，结果前后修了三四个问题，每个问题都精准踩在内网环境特有的盲区上。
一、需求：把UI打包进内网，配置全部指向10.103.x.x早上接到的活儿很明确：UI报表要放到内网，整体打包成一个文件夹，数据库从原先的地址切到内网MySQL，服务器发布到10.103.54.6的8765端口，视频流地址也换成了内网FLV源。
数据库信息当时直接给了一串：10.103.50.147:3306，库名m3_ai_data，表work_load_0521，表结构不变。账号密码我直接写进了factory_api_server.py，这里就不贴明文了，反正后端连库用的配置全部改好。视频流地址是http://10.103.65.30:8080/live?port=1935&app=live&stream=M3_5643，后面要集成到前端播放器里。
第一版打包很快出炉，factory_dashboard_deploy文件夹一共7个文件：
...
产线工时表切换到10秒快照，利用率累计口径重算（2026-05-21）
数据频率一换，累计算法不换，报表就是 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 秒一 ...
在岗人数全显示1，SQL漏判时段导致worker_num为0也不更新（2026-05-20）
在岗人数不是“最后一条记录的 worker_num”，而是“当前时刻还没有结束的那条记录”。
今天这台看板连续出两个问题：先是在岗人数全部显示成 1，查了半天发现 SQL 少了对时段的判断；修完没过多久，服务自己又退掉了。一天基本就在改查询和重启服务之间来回。
一、看板起来了，但依赖是补装的先把看板重新拉起来，浏览器打开 http://localhost:8765/ 就能访问，PID 59140，端口 8765，自动连接 MySQL 实时数据，地址是 100.64.0.2:3306，30 秒自动刷新一次。
这里有个小插曲：新会话的 venv 被重置了，Python 依赖全丢。所以先把 flask、flask-cors、pymysql 补装完，服务才正常起来。当时没太在意，后面这个“会话重置”又出来刷了一次存在感。
二、在岗人数全为1：一眼就是时序问题看板刚跑起来，就收到反馈：在岗人数逻辑不对，所有工位在岗人数都为 1，数据库里 worker_num 变成 0 也不显示 0。
我去翻查询，问题出在第 71-78 行：
1WHERE (AREA, START_TIME) IN (SELEC ...
车间实时看板调试卡在 Flask 不重启，页面数据不更新（2026-05-19）
这天最关键的判断：改了后端代码不重启 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 ...
图表空白主题不切换，工厂仪表板两个JS语法错误（2026-05-16）
先按规范把深色工业风落地，再让太阳月亮切换真正跑起来——今天最关键的判断是：样式可以灵活，但脚本必须先通过语法这关。
今天这一天基本就是在和工厂仪表板的 UI 死磕。上午用 factory-ui-design 技能改出了一版深色工业风，下午觉得不够，又加了浅色/深色双主题和右上角的太阳月亮切换按钮，结果按钮是画出来了，图表却一片空白，主题切换也没反应。最后定位到两个 JS Bug，都是手滑级别的低级错误，但足够让整个脚本挂掉。
一、需求：从单主题到深色工业风起手的需求很明确：用 @skill:factory-ui-design 修改 UI，重点是把颜色改成深色工业风，其余按原则灵活调整。我第一版就直接按技能规范走了深色工业风，落盘到 D:\factory_dashboard_dark.html，同时工作区留了一份同名文件，原来的莫兰迪版本不动。
这一版的核心配色我记下来了：页面底 #0E1116，卡片 #161B22，悬停 #252A33；文字层级从主文本 #EAEDF0 到次要 #B0B8C1 再到辅助 #6E7681；数据用了深色底上高亮度的六色——蓝、绿、橙、紫、琥珀、 ...
工厂数字大屏改版当天，莫兰迪配色落地后甘特图被砍掉重做（2026-05-15）
看板改版最怕的不是改颜色，是改完图别人看不懂。
今天一整天都耗在工厂数字大屏上。上午刚把整套 dashboard 从中车蓝换成了莫兰迪配色，下午用户一句话就把时间轴里的工位作业甘特图判了死刑，只能当天返工重做。
一、上午：莫兰迪配色版先落地上午的活儿比较顺，主要就是把工厂 dashboard 的整体视觉从中车蓝换成莫兰迪色系。助手把每一处颜色都列了对照表：Header 从原来的 #0066CC 深蓝渐变，换成了 #6B7D8F → #B8A9C9 的蓝灰到紫灰渐变；背景从冷白 #F5F7FA 换成暖灰米色 #F0EDEB；主色调从饱和蓝换成低饱和蓝灰 #8B9DAF。图表颜色也改成了蓝灰、绿灰、暖橙、紫灰、玫瑰这种多色系，状态标签换成雾绿 #8FAE8B 和暗玫瑰 #C4908F，热力图渐变从蓝白改成暖灰白到莫兰迪绿再到深蓝灰。
功能上没动任何东西，四个标签页、6 路摄像头 Canvas 预览、24h 热力图、桌面与移动端切换，全部保留。文件最后落到了 D:\factory_dashboard_morandi.html，也就是 cpolar 服务目录，附件也投递过去了。
二、下午：用户 ...
公告
如果你还能看到这个Blog！
就是我永恒小世界的胜利！