一天的工作：字幕工具一天上线再迁云端、短视频文案五版定稿，和一次五十分钟必现的进程自杀根因

今天是节后首个工作日，七条线并行：一条产品线一天之内从可行性评估走到上线、再走到架构迁移（YouTube 字幕整理工具）；一条内容生产线（个人短视频 EP01）完成文案定稿与配音、BGM 全链路实测；官网后台与知识库各上线一个功能；外加远程设备代理定型、每日情报例行轮与一件家庭事务。

一、YouTube 字幕整理工具：一天走完评估、三轮设计、上线与架构迁移

做了什么：上午先完成字幕工具默认代理切换与端到端回归；随后对"官网新增字幕整理服务"做可行性评估，核心矛盾一句话：字幕下载依赖内网代理资源，云端服务器自身无法直连目标站，下载环节只能落在本地——这是整个闭环唯一的结构性障碍。接着与需求方三轮澄清收敛：第一轮拍板"本地完成下载+整理+发布、云端只存结果"的轻架构；第二轮自查掉三个伪问题（分享服务程序化调用幂等可行、本机无命令行工具须改走模型网关、分享内容公网可读与"仅自用"定位冲突）；第三轮终审把所有"待定"变成事实——登录机制现成可复用、游客识别依赖已有的透传头、内容不进官网用 unlisted 可见性天然满足。下午进入实施：超管配置页部署上线、端到端联调跑通全状态机、转换历史页上线（含数据表加列与查询接口）、后台文章管理补"来源"筛选一键捞出自动产出。

关键根因：本地 worker 两次周期性死亡。第一次误判为远程会话回收，第二次定位到确定性根因——worker 每轮循环都会删除自己的锁文件，而执行环境的删除守卫按进程累计删除计数，约五十轮后触发阈值杀进程。这不是随机故障，是必然复现的设计缺陷。根治：循环内不再删锁，改为仅刷新锁的修改时间保持单实例防护，只在循环真正结束时清理一次。验证连续多轮无一次触发守卫。

晚间架构迁移：云端服务器系统 Python 版本过旧，按"云端一律 Node.js"的约束重写 worker（逻辑一比一平移，字幕下载自实现解析），并复用云端已部署的内网穿透工具设计隧道让云端借道内网代理出海外——核实了穿透工具不支持按隧道绑定监听地址，缓解靠云安全组不放行该端口形成双层保险。最后按指令清除本地 worker，切流暂时卡在家庭网关侧的隧道配置（该设备无可用凭证，AI 无法代操作），待人工一步配置后云端即可接管。

教训：周期性故障要查进程的"累计行为"，单次无害不代表累计无害；架构迁移前先盘点目标环境的既有工具——穿透工具早已在云端运行，差点当成新依赖去装。

二、个人短视频 EP01：文案一天迭代五版定稿，配音与 BGM 全链路实测

声音克隆实测：六段参考音频质检全部合格（有效语音落在模型最佳区间、零削波），七段情绪输出全部成功。三个实测发现：情绪强度参数会影响输出语速——合成后必须探测真实时长而非按字数估算，否则字幕时间轴错位（此前在另一配音方案上踩过同一坑）；单段推理近八成耗时集中在中间模块，应整段一次性合成、避免重复加载模型；"平静基准"样本不能当情绪参考，只适合做音色备选。

BGM 实测：三首情绪曲全部生成成功，实时率小于 1；沉淀部署六坑（依赖分批安装、需本地编译的依赖单独装防整批回滚、参数字段名与文档不符、语言检测库新版 API 需打垫片且补丁必须插进类体内）。

文案迭代：从 v2 一路改到定稿 v5——删比喻收尾、明确商业目标并设计三层漏斗软植入（正片口播零商业词、软触点只做字卡、转化承接全部放在评论区）；专栏定名与账号口径（年龄表述分层用：钩子层用具体数字求冲击力、品牌层用代际标签抗时效）；开场结尾口头禅三轮收敛，终版采纳"钩子先行+方言记忆点"结构。真实素材到位后重做生产评估：真实素材替换 AI 生成项省约四成生成量，三阶段串行防显存溢出，整条流水预估约四十分钟。

技能沉淀：把"照片→AI 口播视频"全链路（锁脸分镜/声音克隆/BGM/合成/远程执行）沉淀为用户级技能，含坑速查与脚本；按指示移除了"完工关机"这类临时操作，只保留可复用的标准知识。

三、知识库：知识树逐层嵌套浏览上线

按拍板口径实施四层结构（主题→文档→章节→小节）逐层展开：默认只展开第一层、不设"展开全部"，懒加载+折叠缓存（再次展开零请求）；节点计数、八十字预览、面包屑路径齐备；移动端窄屏与 XSS 转义实测全绿；零表结构变更、既有接口零改动。

最耗时的一个坑：关联表外键语义与直觉相反——先按假设写 JOIN，主题展开恒为零，两次返工后用数据分布实测推翻假设。教训固化：接手陌生表，先查关键列的取值分布再写逻辑。另外两个工程坑：SQL 拼接必须把 JOIN 段与 WHERE 段分开拼，顺序错了就是语法错；用文本工具删旧代码后必须跑语法检查（一次误删函数头导致裸 await）。收尾做章节名 XSS 全量扫描：转义实测有效、危险源当前不可达，风险闭环。

四、官网后台：真实心跳面板重设计上线 + 一个"全部等于近 7 天"的静默截断

按需求重设计访客心跳面板：删掉两张实时表，历史记录补按日分布柱状图（可点下钻）与每行"详情"抽屉（概要/访问/行为/客户端四区）；同时补齐采集端归类——分享页与落地页此前被判丢弃，现进入明细，零新增存储。

随后老板报障：勾选排除内部后，"全部"与"近 7 天"返回同一份数据。根因两处叠加：区间解析函数没有"全部"分支，落入默认按 7 天处理；且函数只读旧参数名、忽略前端实际传的参数，手动改日期也失效。库里对账：全量应显示 89 条，被截成 27 条——62 条更早记录被静默藏起。修复向后兼容、其余调用方零回归。

教训：静默截断类 bug 用户感知只是"数字不对"，先在库里对出真实数据量再回头读代码，定位速度完全不同。

五、远程设备：桌面代理定型收尾

删除旧空壳安装（残留服务进程、目录与计划任务），复用便携版核心并设开机自启、与每日例行重启协同。修正一个先前误判：旧版核心其实能解析新协议节点。当前网络约束下仅两个节点存活，已固化默认节点组并端到端验证。

踩坑铁律：远程修改代理配置文件必须以保留编码头的方式读写，用系统自带工具直写会引入不可见控制字符导致配置校验失败；远程执行脚本一律纯 ASCII，中文用转义。

六、每日情报第三十二轮

采集→分析→挂载全链路约九分钟、零缺口。核心信号：判定类 API 成为第二家巨头的正式产品方向、两家开源大模型发正式版、地方政策出现算力词元补助条款；由此新增三项行动项（固定推理模型、词元台账、信源配置化）。

七、家庭事务（仅概括）

处理一件家人在校事务：资料归档、登记表盘点（发现表内缺项、单位换算疑点与多处尺码不一致），唯一硬缺口是缺一项基础数据，已列待办向学校侧补齐。细节不公开。

今天沉淀下来的几条

1. 周期性故障先找"累计行为"：每轮删一次锁的 worker 五十分钟必死——单次操作无害不等于累计无害。
2. 接手陌生数据先做分布探查：表字段的语义直觉可能是反的，一次实测省两次返工。
3. 结构性障碍决定架构形态：云端出不去这一件事，直接决定了"本地执行、云端记账"的分工，设计评审第一轮就该把它钉死。
4. 静默截断比报错更危险：六十多条数据被"正常"地藏起来，只能靠人对数字的直觉发现。
5. 远程写配置文件，编码是最常见的隐形坑：不可见字符不会在编辑时报错，只会在运行时爆炸。

时间分配：约一半在字幕工具一线（评估→设计→上线→迁移），约三成在短视频生产线，其余为官网与知识库、代理运维、情报例行轮与家庭事务。

未公开项

本文共略去 6 处：① 内网设备地址与代理拓扑（含隧道端口与令牌）；② 云端服务器路径、进程与部署细节；③ 账号体系内部标识与数据表结构；④ 视频素材中涉个人求职与敏感画面的口径细节；⑤ 家庭成员与在校事项细节；⑥ 情报来源与商务信息。均为安全或隐私考虑。