一天的工作：内容寻址上线、网页数据库工作台从零到一，和一次把自己封禁的事故复盘
地址冻结改造、拦截提示页、数据库工作台上线、网关图像能力盘点，以及一次自己人被封的故障复盘。
今天五条线并行：官网侧一天之内完成「地址冻结」改造、拦截提示页上线，还经历了一场「自己人被自己封了」的故障处置；工具侧把网页版数据库工作台从设计稿一路推到生产上线并做了产品化评估；平台侧给大模型网关装上了「眼睛」（图像识别）；内容侧完成第四支视频的三端上架与首日复盘，并敲定第五支的选题内核。以下是各条线的展开。
一、官网升级：从「文件名」到「内容指纹」的地址冻结
HTML 页面发布链路此前按文件名寻址，修订一次地址就漂移一次，外发出去的链接全部失效。这次落地「内容寻址」：地址由内容指纹加服务端私盐派生，同一内容无论重发多少次，地址完全不变。
几个值得记录的设计决策：
- 排序规则的坑：数据表此前用大小写不敏感的排序规则，两个仅大小写不同的名字会被静默合并成同一个地址。生产库不支持严格的排序规则变体，只能用二进制比较类型兜底，改完实测全大写查询结果从误命中变成零命中。
- 覆盖要有安全网：从「新建」变成「覆盖」语义后，补齐了三道护栏——覆盖前自动快照、目标地址归属校验（越权直接拒绝）、来源指纹回填，旧页面更新须显式指定目标。
- 同内容异源分址：两个来源发布了相同内容，各自拿到独立地址，互不踩踏。
服务端十项验收全过，钩子端到端三轮「发布→改内容→再发布」地址不变。小坑：发布钩子对过短内容有静默跳过阈值，测试页写得太短会让人误以为钩子坏了；页面族名的取法从「文件名去后缀」改成「纯标识」，否则文件名里带日期和指纹，改一次内容族名就变。
二、事故复盘：我们自己把自己封了
地址冻结上线不到半小时，办公电脑突然连不上服务器了——不只网站，远程登录、文件通道全部中断。排查结论分两层：
- 业务层回归：新机制下，同一来源的重复发布从「新建」变成了「覆盖」，而覆盖要求更高的编辑权限；办公电脑配的是只发权限的密钥，于是连续收到五次拒绝。
- 防护层越界：连续拒绝触发了反爬封禁，而封禁动作被配置成了全端口拦截——网站层的惩罚范围超出了网站本身，把服务器上所有服务一起带崩了。
处置四件事：解封；把「发布自己页面」设为豁免（自己的密钥覆盖自己的页面放行，跨密钥覆盖仍要求编辑权限）；拒绝计数里豁免发布接口的正常拒绝；给白名单加了一个自动守护——凡是通过安全通道登录过、或正常完成过发布的来源地址，自动进入免封名单并定期续期。
两条教训值得刻下来：
- 防护工具的「重载」可能是假成功。反爬工具原地重载时会因内核组件占用而静默失败，防火墙规则实际没重建，封禁功能处于失效状态而不报错。结论：这类工具改配置必须完整重启服务，重启后还要做一次封禁演练验证真的生效。
- 上线任何新机制，必须带回归自检。这次故障的直接导火索就是新机制改变了既有调用的语义，而上线清单里没有一条「旧调用方还能正常工作」的验证项。
三、访问拦截提示页：把冷冰冰的拒绝页变成有温度的提示
此前被拦截的访问者只会看到网关默认的白色错误页。这次上线了分层提示：正常浏览被拦时显示完整提示页（已拦截次数与剩余机会），限速场景只给轻提示，恶意扫描仍然直接封禁。
实测先行纠正了需求前提：所谓「缓存命中页要提示」其实不成立——那些命中全是真实用户的正常缓存行为，真正需要提示的是被拒绝和被限速两类。这个「先看真实数据再定方案」的动作省了一次错误上线。
网关层两个经典坑，以后谁配都会撞上：
- 命名跳转点里反向代理不能携带路径，否则配置直接无法生效——必须换成完整路径写法。
- 错误页内部跳转会重跑整个访问控制链：如果判断条件用的是「原始请求地址」，内部跳转后它仍然不变，于是二次命中拦截规则，网关认为这个错误页已经被处理过，最终退回默认页——表现为「配了但没生效」。修法是改用「解码后的当前路径」做判断，并对提示页自身路径显式豁免。
上线后验证了三档文案递增、正常路径零误伤、接口拒绝仍返回纯数据不被污染、版本号隐藏。顺带还修正了一个旧判断：此前以为拦截计数器没在工作，实际是因为高危来源早被提前封禁，根本轮不到计数。
四、网页版数据库工作台：一天从设计稿到生产
需求是做一个对标主流数据库客户端的网页工具：连接多种数据库、浏览结构、执行语句、备份导出导入。上午出设计方案，下午开发完成并部署上线。
几个架构结论：
- 浏览器物理上无法直连数据库（私有二进制协议加裸传输层连接），纯前端方案不成立，必须走「浏览器 → 自建网关 → 数据库」三段式。
- 凭据不进浏览器：连接定义的权威源在服务端，口令走服务端加密密钥库；前端本地存储只存连接元信息。
- 安全护栏写在代码里：多语句一律拒绝而非只执行第一条、只读锁、危险语句二次确认、目标端口白名单防内网探测。
- 大结果集靠虚拟滚动：两万行查询，服务端一百五十毫秒，界面二百四十毫秒，页面里只有二十来个真实节点。
开发中踩的三个真坑：新驱动没有旧驱动的流式暂停接口，做导出背压必须改用标准可读流，用错会导致备份只写出建表语句；驱动返回的字段类型是数字码，前端展示前要映射成可读名称；前端全用绝对路径，挂到子路径下全部四成空——加了按当前目录推导的前缀常量，一份代码根路径和子路径通吃。
部署后接的真实生产库跑通全链路：结构浏览、真实查询、导出、备份还原逐行比对一致。产品化评估的结论也很干脆：自用已就绪；卖给客户做私有化部署可行，需补会话持久化、改密、多账号权限等六项；而「客户把数据库口令托管给我们」的在线服务形态是结构性死结——数据库工具是客户数据资产的钥匙，没有公司会把钥匙交给外部服务，这条路不是技术问题，是定位问题。
五、给大模型网关装上「眼睛」
对网关做了图像识别能力的只读盘点，结论好于预期：登记的全部模型原生支持图像输入，上游和网关代码都不用改，消息原样透传即可。决定性验证是自造了一张点阵数字图，多个模型全部读对，端到端走网关同样通过。
真正的障碍在体积闸门：网关和前置网关双层限制请求体一兆以内，手机拍照的原图基本全部超限，而且超限后不是返回标准错误，而是直接断开连接——调用方只能看到「请求失败」，无法得知原因。当晚三项改造全部上线：体积上限提到八兆、超限改回标准的四百一十三错误数据（公网也有兜底）、模型清单新增能力字段并在控制台可见、字符统计遇到图片只计占位长度（修复前一张图会把统计撑到一百万字符，修复后一百零五）。
一个副作用值得记录：编辑工具写内部控制台页面时触发了自动发布钩子，把四个含接口路径的内部页面发布到了公网。发现后全部删除。这个案例再次验证「工具链的自动化边界」——发布钩子应该有目录排除规则，服务端内置页面不该进入公开发布通道。
六、内容线：最强开局、归因纠错、和「AI 是乘号」
第四支视频凌晨三端上架，首日数据是系列迄今最强开局：九个多小时的全平台播放量超过了此前两支各自数天的累计，单端纪录刷新至原来的近两倍。更有价值的发现有两个：
- 这一轮赢在「停留」而不是「曝光」：平均播放时长是此前两支的两倍多，说明新的前两秒模板加长片内容初步成立。但混杂因素必须写明——长片天然拉高平均时长，唯一的干净判据是次日才能拿到的「两秒跳出率」。
- 归因假设必须机器验证：投稿页显示的分区和接口查到的分区不一致，发布记录里写的分区根本没生效。此前「形态与分区双变量混淆」的担心被一次接口核实拆解掉，归因重新变干净。流程里因此加了一条硬约束：发布后必须用接口核实关键状态。
第五支的选题设计是今天内容侧最有意思的思考。第四支片尾彩蛋已经把下一期锁定为「让我的 AI 助手来吐槽我」，但在这个壳之下，老板提出要装一个硬核的内核——不只是讲段子，要回答「我们做对了什么，才能把这么多产品落地」。
答案是五层能力盘点：会写提示只是第一层，会操作是第二层，之上还有三层——判据（怎么验证 AI 说的是真的）、规矩外置（把规矩写成机器可执行的约束）、留痕回滚（出了错能退回来）。后三层恰恰是从没讲过的，也最有价值。
立意分析里有一个提炼得很准的比喻：AI 是乘号，不是加号。你的能力是一，它放大到十；你的能力是零，乘多少还是零；而如果你给了它一个错误的判断，它会把错误忠实放大十倍——这在第一支视频的素材事故里有真实自证。落到行动上，「拿主意」的工程学含义就是说出「什么算做好了」——判据是人定的，AI 只负责跑。
还有一条传播方法论：太「对」的句子无法反驳，也就无法传播。金句必须有具体的东西（第一支的核心句有敌人、有具体动作，所以活了），必须树一个敌——这次树的不是某个厂商，而是「以为有了 AI，就不用自己拿主意」这种想法。
七、例行线
每日情报第四十六轮照常采集发布，零缺口；访客数据连续两日处于低位，渲染爬虫剔除规则做了升级。
今天沉淀下来的几条
- 上线新机制必须配回归自检——语义变化会以最意想不到的方式伤到老调用方，这次直接把服务器自己人封了。
- 防护工具的重载不等于重启，改完配置必须完整重启并做一次真实演练验证生效。
- 先看真实数据再定方案——拦截提示的需求前提被当日状态码分布直接纠正，省掉一次错误上线。
- 判据是人和 AI 的分界线——「说好了不算好，跑过了才算好」，完成信号要机器可读，验证要用数据不用感觉。
- 内容要硬核内核加熟悉外壳——壳已被数据验证，硬核讲层而不是讲技巧；金句要具体、要有敌人。
时间分配上，官网与基础设施侧（一至三、五节）约占一半，数据库工作台约占四分之一，内容线与例行采集占余下部分。
未公开项
本文为对外口径，以下内容仅作概括或略去，共六处：
- 服务器与办公网络的拓扑细节、封禁阈值与白名单实现（披露站点安全面）；
- 各服务的部署路径、配置文件与备份坐标；
- 密钥体系、账号与权限的实现细节；
- 平台账号标识与运营数据明细；
- 内部评估文档中待批示的决策项清单；
- 情报来源与内部编号体系。