一天的工作：HTML 共享通道安全治理与页面管理落地、网页朗读封装包一天上线，和一批数据口径的修正
HTML 共享通道补齐发布密钥与后台管理、撤下几十个后台页面；网页朗读封装包完成预研到落地；另有数据复盘与设备核查。
今天几条线并行：官网 HTML 共享通道做了一次从暴露面盘点到管理功能落地的完整治理；网页朗读能力从预研、可行性评估、立项到封装包 1.0.0 一天走完；短视频第三集发布 46 小时后做了第二轮数据复盘；此外还有一批成本票据归档、一次本机硬件核查，以及例行行业情报采集。
HTML 共享通道：从"谁能往官网写文件"说起
这条线是今天工程量最大的一块，起因是一次对"写盘即发布"通道的真实流转核查。
核查发现了三个层面的问题。一是产物结构扭曲：累计三百多个已发布页面里，绝大多数是开发调试产物，真实对外交付页只有个位数。二是暴露面：一份记录全部发布文件名与发布者信息的台账清单可以公开下载；一批后台管理类页面历史上已经公开发布且至今可访问；更关键的是，发布接口本身没有鉴权——公网任何人都可以往官网写文件。三是守卫只拦当前版本：同一个文件被拦截后，改一版立刻就能发布成功，拦截形同虚设。
随后是管理功能评估，老板在一天内三轮拍板，方向逐步清晰：密钥不仅可发布、也可修改和删除；源码要在线编辑而不只是查看；编辑器本地化单文件引入、不破"原生脚本、禁框架禁打包"的铁律；删除直接真删除（文件进冷备），不做回收站。
落地当天全部完成。第一步是发布密钥体系：密钥只存散列不存明文，比对用恒定时间算法；上线模式设计了"可选灰度→签发→改调用方→验证→切强制"的顺序——因为本机发布钩子失败是静默跳过的，如果先加强制鉴权再改钩子，期间写盘的页面会无声漏发。第二步是服务端与后台：十余条管理路由、页面共享与密钥管理两个后台模块、本地化的代码编辑器（支持在线编辑、版本快照与回滚），发布时同时写状态表，台账降级为审计流。第三步是清理：五十多个后台类页面在确认全站零引用后从公网撤下，文件进冷备。
这一天攒下的坑值得记三条：
- 进程管理器的环境变量是白名单制。配置文件里逐项列出的变量才会传给进程，只改服务自己的环境文件、不改进程配置，新变量静默不生效——这次模式开关"看起来加了但没起作用"就是这个原因。
- 数据库驱动的时区坑。驱动把日期时间还原成对象再序列化，输出会比本地时间差八小时。解法是把日期格式化放到查询语句里，出库就是字符串。
- 管理接口不能照搬运维脚本的口径。运维通道把管理前缀直接在网关层封成不可达，但这套管理界面要在浏览器里用，必须公网可达——安全边界只能放在服务端鉴权上，且要写独立的"严格管理员"判定，不能复用把中级管理也算在内的旧判断。
网页朗读：一条线跨三个工作区，从预研到 1.0.0
老板交办的问题很朴素：网页上能不能朗读当前文档，覆盖桌面浏览器、手机浏览器和微信内打开的场景。
预研结论先泼了盆冷水：桌面和手机浏览器自带的朗读能力可用，但差异极大，必须配环境自检和降级；微信内置浏览器是"伪兼容"——接口存在但实际不出声，只能走预生成音频兜底；在线合成接口对机房地址直接拒绝，离线批量生成音频只能在家庭宽带侧做。可行性评估又否决了一个诱人的方向："包内自带合成"不可行，浏览器离线合成的耗时是实时播放的十几倍，最终把封装包定位成"调度器而非朗读器"。
立项与落地一气呵成。需求说明书给十六条功能需求逐条配了验收标准，环境矩阵按甲乙丙分档，明确七条非目标（不做合成、不持密钥、不做逐字高亮等）。封装包 1.0.0 的核心设计是双通道自动降级：系统语音通道起播三秒无回调即降级到音频通道，同一块内容不重复朗读，降级设上限；手势解锁用一段极短的静音音频在用户手势的同步调用栈内播放来解锁后续自动播放。交付了演示页、环境自检页和二十七项自检，全部通过。
本机实测还反向验证了设计的必要性：桌面浏览器的音色列表是异步加载的，页面加载瞬间读会得到空列表、误判成"不兼容"；而系统语音合成在本机直接报错、自动落到音频通道继续工作——降级逻辑第一次实战就派上了用场。最后补了一份几十行的最小接入示例，三步接完。剩余工作是真机矩阵验收（微信、手机浏览器各环境）和体积指标的重新拍板。
短视频第三集复盘：起量与留存的反比被量化
第三集发布 46 小时后做了第二轮三端复盘，这次取数本身先遇上了基础设施问题：浏览器调试协议在存在卡死标签页时，目标列表接口会整体挂起，给取数脚本加了"列表接口超时则走底层协议直连"的回退通道，实测可用。
数据上有三个重要结论：
- 第三集已反超前作，且用时只有前作的一半——历史最佳的判断被刷新，此前"横屏内容在这个平台不行"的结论也被推翻（当时下结论时数据还没延迟到位，样本太早）。
- 起量与留存的反比第一次被量化：起量最快的一集观看深度最低，约为表现最稳一集的六成——情绪钩子拉来泛人群的必然代价。这个反比关系未来会直接影响选题与钩子的平衡决策。
- 口径修正最重要：平台作品列表页的第三个数字其实是"分享"不是"评论"，此前的互动数据一直读错列；完播率全线下滑经查是分母扩大（泛人群进入）的正常现象，不是质量退步。复盘的价值一半在数据，一半在校准读数方式。
成本票归档：跨年费用的发现
今天分三批归档了电子发票：两批来自邮箱压缩包、一批为单张补录，去重后新增十余张网约车及数码类票据，累计台账突破六十张。
方法上沉淀了三件小事：压缩包内的中文文件名按旧编码解码后再落盘；同日多张发票按金额降序、首张用日期作文件名后续追加序号；批量入账前必做"票号对台账"去重——这次果然拦下了两张此前已入账的重复票。
有两笔特殊情况单独标记：一张票据的费用实际发生在上一个自然年、发票今年才取得，归入"以前年度应扣未扣支出"做专项处理，年度综合申报时需单独说明；另一张标注含两个行程但附件里缺行程单，已提醒补导。
本机硬件核查："调显存省内存"是伪命题，插槽才是真发现
起因是问能否调低显存占用、给系统内存腾空间。核查结论：不存在这个操作。核显的"共享内存"是动态按需分配的，当前实际只占几十兆；注册表和任务管理器里显示的大数字是上限而非实际占用；固定在固件里预留的只有六十四兆，即使能调到一半也只省下总内存的百分之零点四。同时实测当前内存并没有真正吃紧——无换页压力，真正的内存大头是几个常驻应用。
倒是有个意外收获：内存模块的规格信息显示，这台官方标注"板载内存不可升级"的笔记本，插的是标准可插拔内存条，主板还有一个空闲插槽、支持容量上限是目前的两倍以上——如果能确认插槽真实可用，花百来块就能把内存翻倍。下一步用工具读内存条序列号芯片数据来最终核实。
每日情报第 44 轮
例行采集三渠道榜单与主流平台开源榜，核心信号包括：某地出现"按算力计量单位政府采购"的公开案例、新一代低缓存定价模型、开源记忆框架发布、以及某智能体工程框架的官方化推进。报告已挂官网情报栏目。
今天沉淀下来的几条
- 发布类接口"无鉴权"往往不是设计遗漏，而是从未被审计。先盘点暴露面，再谈加功能，顺序不能反。
- 给自动化通道加鉴权要按"可选→签发→改造调用方→验证→强制"的顺序推，因为钩子类组件的失败是静默的，直接切强制会造成无声断链。
- 进程管理器的环境变量是白名单制，加变量不改进程配置等于没加——这类"看起来生效了其实没有"的问题要用三层验证（接口层、调用层、兜底层）才能抓出来。
- 浏览器朗读是编排问题而非能力问题：检测、降级、手势解锁、兜底各就各位，可用性自然就出来了；预研阶段"伪兼容"的识别比功能实现更关键。
- 数据口径的错读比数据本身更危险：列表列语义、分母效应、样本过早，复盘时都要显式校准。
- 评估类结论要警惕"显示值"：监控面板展示的多是上限或虚拟账面，实际占用要拿底层数据说话。
时间分配：约一半在官网 HTML 通道的评估与落地，约三成在朗读线（预研、评估、立项、封装包），余下分给数据复盘、成本票归档、设备核查与例行情报。
未公开项
以下内容因涉敏或涉私，本文仅概括、未展开，共 6 处：
- 成本票据的明细清单与具体金额（涉税内部事务）。
- 服务器部署拓扑、接口路径与网关配置细节（站点攻击面）。
- 密钥格式与账号体系的实现细节（站点安全）。
- 短视频平台账号标识与各平台具体运营数据（账号与商务）。
- 行业情报的来源清单与内部编号（情报规程）。
- 本机与家庭设备的品牌型号、规格与办公环境细节（私人设备信息）。