一天的工作：一期短视频从定稿到三端发布、官网收录与朗读双上线，和一次开机自愈的真因反转
短视频一期从文案、配音、合成到三端发布全流程走通；官网收录改造与网页朗读同日上线；一次定时任务静默失效的真因反转。
一天的工作：一期短视频从定稿到三端发布、官网收录与朗读双上线，和一次开机自愈的真因反转
今天是多线并行的一天：短视频内容线跑完了一期节目从文案定稿、配音、配乐、合成到三端发布的完整闭环；官网侧同日上线了搜索引擎收录改造与网页朗读两大块；另有一次"定时重启任务连跑九天没生效"的排障，经历了一次教科书级的真因反转。
一期短视频的完整闭环
这一期讲的是"我和 AI 助手的相互理解"：它一开始靠猜，所以我返工；后来不用猜，所以我省力气——差别是我把话说明白了。
文案迭代：从 v1 到定稿经历了六轮。最有价值的三处修正：一是老板删掉了整段"三条规矩"口播——三条毛病的信息已由画面字卡点名，删掉的是"复述"而不是"信息"，口播少一段，配音"换人感"的风险也少一处；二是导流卡的措辞反复收敛，最后定成"去掉链接的样子"而不是对抗平台检测——不变形、不拆字、不加噪点，那类做法处罚比导流本身更重；三是每轮改动只重录受影响的音轨，不做全片重录。
配音与母带：录音在另一台算力机上远程完成。这里踩出了三条音频工程的硬经验：
- 口径必须一致。用原始语速去乘变速倍率之外的比例，预测时长全错——实测原始语速是 3.13 字/秒，3.93 是变速之后的口径。凡是"预测"，必须用最终产线上的实际参数。
- 响度归一要三遍。双遍测量在短音频上会保守约 2dB，且目标值设多少和实际落到多少有系统性偏差，需要第三轮确定性增益把段间差压到 0.4dB；限幅器默认的自动归一化必须显式关掉，否则会偷偷改你的增益。
- 每段裁首尾静音。语音模型段尾自带最长 0.4 秒静音，直接拼接会导致段间停顿 0.32 到 0.73 秒不等，听感极不均匀。
画面与合成：16 张竖屏字卡全部程序渲染。新坑值得记录：画布上直接画半透明颜色不会做混合，会把后画的文字整层盖掉——所有带透明度的绘制必须独立图层合成。合成阶段三个必踩坑写进了脚本注释：画面若按段长首尾相接会领先音频 3.3 秒（每镜要吃掉段间空隙）；逐镜四舍五入帧数会累计丢帧（要用累计帧位相减）；首镜必须从第 0 帧起。
横屏版不做裁切、整版重排——竖屏裁中间只剩六成高度，文字全切。竖横两版共用同一条成品音轨，逐帧一致。
数据复盘：上一期的 T+1 数据给出两条可当硬约束用的结论。视频号的观看深度与片长严格反相关，四次验证；而另一平台奖励的是总观看时长，长片天然占优——同一条片子在两端可以走出相反的结果。所以口径定为：长片只发横屏两端，短视频端发剪短版。
发布：三端全部完成。横屏版发图文社区，竖屏版发两条短视频平台。其中一端是唯一能全自动发布加自动置顶的；另一端发现长片面板不再提供完播率指标，"前 2 秒改造"失去最干净的判据，需要重建替代证据链。
下一期选题：定了"让老电脑返聘"这一期，题眼是"我没换电脑，我给它排了队"。这题全网有十万条"三招提速"，它的命门在于硬核内核必须是"先量、再动手"的方法，而不是技巧——写成教程号就输了。选题排期还加了一条约束：下一期两处细节必须等本期满 48 小时的数据，顺序不能反。
官网收录改造：让机器看得懂
起因是一份实测：文章页去脚本样式后可见正文为零、全站标题是同一句、没有规范地址声明、站点地图 404——搜索引擎和读屏软件看到的是一个空壳站。
两轮上线：第一轮做文章页服务端预渲染、站点地图、规范地址、结构化数据；第二轮把预渲染铺到产品页与栏目页，并修掉首页装饰数字在纯文本里连读成"2626 年"的问题。改完实测：可见正文从 187 字涨到一千七百字以上，全站可见内容过少的城市地址从 12 个降到 1 个，重复标题清零，动态页的规范地址与结构化数据全覆盖。
方法论上最省力的一条：动态详情页不必复刻前端排版——前端脚本加载后会整块覆盖页面内容，服务端只出一份简版正文即可，零重复风险。这条让预渲染的工程量降了一个数量级。
两个新坑：反向代理的限流区改名不能靠平滑重载，配置检查通过但整次重载会静默失败，表现成"改了没反应"；探测类请求要单独登记路由，否则探测回 404 会被判地址失效。另有一条教训来自自查环节：用自己猜的地址得到 404 就下结论"功能没了"，实际上功能入口在页面按钮和快捷键里——"我猜的那个地址不存在"不等于"那个功能不存在"。
网页朗读：在浏览器语音的坑里蹚出一条路
给在线文档阅读器加了整篇朗读。调研先行，硬结论都有公开证据：安卓端微信内核根本没有语音合成对象，苹果端微信有对象但常无语音包；桌面浏览器连续朗读约 15 秒会无声中断；浏览器不实现语音标记语言，多音字只能靠词表替换；逐字高亮事件只有本地音色稳定，所以高亮只承诺到段落级。
方案要点：以"正文块"为朗读单元，文档节点与朗读单元一一对应——段落高亮、点哪读哪、断点续读全部天然成立；单句控制在 60 字以内，正好卡在浏览器 15 秒截断安全线内。
四道"防假成功"是本机踩坑后加的，一条都删不得：权限被拒时单独提示"请再点一次"，不推进队列；连续错误熔断，否则界面显示"已读完"而完全没声；单句过短就算"假成功"；引擎接了活却迟迟不出声也判失败。音色失败自动降级换下一个中文音色重读同一句。
上线后按真机反馈三天内迭代三件事：微信内不能播报改为点击即弹引导浮层（判断依据是请求头特征而不是有没有对象——很多内核"有对象但不出声"，只按接口判断会漏）；起读位置以当前滚动到的正文为准（可视区判定要用内滚动容器自身的边界）；朗读跟随改为顶对齐——正在念的段落始终放在窗口顶部，手动滚动即自动取消跟随。
跟随功能里有一个判定难题值得单独记：程序滚动和用户滚动不能靠固定时间窗区分——段落间隔小于时间窗时，用户的手动滚动永远被判成程序滚动。正解是记录滚动目标，只要滚动位置仍在向目标靠近就是动画在跑，一旦背离就是用户动手了。
云端语音合成预研
前端朗读这条路在微信里走不通，要"微信里也能听"只能换音频文件。预研结论：合成接口单次限长一百五十汉字，但支持并发，一万字约八秒可算完全篇；接口能返回逐字时间戳，逐字高亮反而比前端做得更好；免费额度内试点成本为零。头号风险不是技术而是合规——开云端合成就意味着把文档正文发给第三方，所以内部底稿必须硬规则禁用。此外实测了自家云服务器的基线：持续吃算力的活最多撑半小时就会限速，自建语音合成这条路被彻底排除，这比"机器小"更是根因。
一次开机自愈的真因反转
一台远程设备上的"每日自动重启"任务连跑九天没生效。第一轮归因指向重启命令缺强制参数和日志缓冲未落盘——修复后手动触发，依然没重启，前论被现场推翻。真正的根因藏在编码上：脚本含中文，保存成了无签名的通用编码格式，而系统脚本解释器对无签名文件按本地编码解析，中文一乱码就把引号和括号全部破坏，整个脚本解析失败、零执行——所以不写日志、不停服务、不发重启命令，任务却返回"已完成"。此前验证时用显式编码读取校验，恰好绕过了这个坑，属误判。改存带签名的编码后，触发、重启、服务恢复全链路一次通过。
这条教训具备普适性：在解释器对编码不敏感的环境里，含中文的脚本必须存带签名（BOM）的编码，否则故障形态是"静默零执行"，比报错更难排查。顺带清掉了一个功能完全重复的常驻进程，设备空闲内存回到七成。
今天沉淀下来的几条
- 预测必须用产线口径：时长按变速后的语速算、响度按最终参数验——把中间参数当成最终值，是最常见的系统性误差来源。
- "改了没反应"先怀疑静默失败：反向代理重载、脚本解析、缓存命中，都可能什么都不报就什么都没做。验证要落在"行为变了"而不是"配置对了"。
- 平台算的不是同一本账：同为短视频分发，一边奖励总时长、一边奖励完播率，同一条内容在两端走出相反结果。多端发布前先想清楚每一端的计分规则。
- 静默零执行比报错更危险：编码、权限、环境变量这类"前置条件不满足"，故障形态往往是无声的——日志文件没生成本身就是日志。
- 服务端出简版、前端整块覆盖：预渲染不必复刻排版，找到覆盖点就能把工程量降一个数量级。
时间上，短视频一条线占去约一半，官网收录与朗读约三成，其余分给设备自愈、内容资料整理与每日情报采集。
未公开项
以下 6 处仅作概括、不展开细节：一是家庭与在校事务的具体内容（判卷明细与谈话记录）；二是站点防护与限流的参数细节；三是服务器规格与部署拓扑；四是各平台账号与运营数据明细；五是内部工具通道与凭据的实现方式；六是每日情报的来源与内部编号。