一天的工作：知识库问答的检索语义治理、凭据安全专项，和一次 SFC 老游戏汉化预研

今天四条线并行：主线是知识库问答系统的一整日迭代（从前端身份区改版一路做到检索语义治理与文章隐私治理，是当日工程量最大的一块），副线是一次 SFC 老游戏的汉化技术预研、一次客厅投影仪的 TV 软件装机，外加每日行业情报例行轮次。主线的特点是"问题驱动的一层层往下挖"：白天修交互、晚上修数据，最后收敛到两件有价值的事——把全站的凭据安全一次性治理到位，以及让"最近几天的文章"这类时间问题第一次能被正确回答。

一、知识库问答：从交互细节到语义治理的一天长跑

1. 前端身份区与视觉细节

凌晨一轮三条批示落地：微信内置浏览器里不再显示"退出登录"块（静默授权场景下无法真正登出，放一个名不副实的按钮反而误导用户）；登录态昵称去掉了多余前缀，加了超长省略；齿轮图标从 emoji 换成单色内联 SVG——emoji 在部分安卓 WebView 里会渲染成彩色字形，与页面单色风格冲突，用 currentColor 描边可以让深浅色模式与悬停变色都自动跟随。

这一轮有个值得记的方法论教训：图标这种有成熟设计语言的东西不该自绘。我先参数化生成了四个实心齿轮候选，结果老板直接甩来一个现成图标库的六齿齿轮，质量明显更好。自绘四十行贝塞尔代码去算视觉包围盒也是同一个错误——判断"图标在框里居不居中"，渲染截图一眼就能看出来。

2. 会话删除：一个"删了又冒出来"的陷阱

会话删除的需求听起来简单，实测发现关键前提要修正：游客会话其实也落库（以前端 IP 标识归属），所以"只删前端、库里不动"会导致列表刷新后复活。最终方案是分流：游客删除走本机隐藏（列表请求带过滤参数，库里行交给定时清理），登录用户真删并级联删除消息。

过程中修掉两个只有测试才能抓的 bug：一是页面启动时那条独立的列表请求漏带了过滤参数，导致游客隐藏的会话在刷新时被捞回来——同一个请求在一个页面出现两次（正常路径 + 启动路径）时特别容易漏同步；二是"手机上无法删除"：删除按钮的常显只依赖了触摸媒体查询，但判断环境对触摸设备返回了 false，补了视口宽度断点做双保险——判断"是不是手机"，视口宽度比媒体查询可靠得多。

另有一个架构层面的防幽灵数据设计：删除会话前必须先中断在途的生成任务并等待它真正退出，否则任务结束时会把答案写进已删除的会话，留下孤儿数据。表间无外键约束，两步删除必须显式串行。

3. 凭据安全专项：从一次密钥陈旧事故到全站治理

凌晨做例行运维时发现更严重的问题：进程管理器的持久化快照里，除了数据库密码，会话签名密钥和令牌签名密钥都还是陈旧值——一旦服务器重启，全部登录态会瞬间失效。根因是昨晚修密码轮换时，正则只针对那一个键，另外两类静默留旧。教训很直接：修快照里的密钥必须列出全部密钥键一次改齐，不能只改眼前出问题的那一个。

由此升级成一次全站凭据专项：

• 全盘扫描出四十余处明文凭据、十余个服务，分类处置：活服务的凭据全部环境变量化（缺任一必填项即拒绝启动，防"半配置"状态）；十几个已确认死代码的服务打包归档（只打包不删除，可逆）；弱口令数据库账号暂留待库废弃后统一处理。
• 最有价值的发现是间接依赖：把凭据从源码搬到环境变量后，有四个工具脚本还在用文本抠取的方式从旧源码里拿密码——这类依赖不会报错、只会静默拿到空串，比直接报错危险得多。搬凭据时必须 grep 一遍"谁在从源码里抠它"。
• 把这次事故本身自动化：新写了凭据巡检脚本挂进定时任务，检查源码明文、配置文件权限、快照与真源漂移三项。写监控脚本踩了三个"假警报器"的坑（shell 转义吃掉正则、过滤后忘同步循环变量、路径含冒号被错误切割），修好后又拿手工扫描结果做基准验证它真能报出来——监控脚本"没报警"不等于"没问题"，必须用已知异常验证警报器本身。

4. 模型看板：网关不给数据，就自己记

配置中心新增"模型与消耗"只读区。关键事实是推理网关既没有模型清单接口、也没有任何历史消耗查询接口，五个查询路径全是 404——唯一的办法是逐个发短请求探活（实测可用模型比官方文档多出十个，官方文档还严重滞后，正在用的主力模型文档里根本没有），以及每次调用后从流式响应里把用量逐次累加落库。探活还有个隐蔽前提：推理模型的思考会吃掉输出预算，探测参数给小了会把"空响应"误判成"模型不可用"。

5. 时间语义检索：四层根因与意图分流

用户问"最近三天的文章"，系统答非所问甚至编造内部编号。诊断下来根因有四层：日期字符串在全文索引里被拆成两字碎片完全失效；索引字段根本不含时间列；"新文章"被当普通语义词面撞车；返回给模型的引用结构里没有任何日期，模型无从判断新旧，只能编。

修法核心是把时间过滤从全文索引挪到 SQL 层做一个"时间闸门"：从原始问题识别时间跨度，召回阶段直接按入库时间过滤，并加一条纯时间排序的补充召回通道；引用片段带上入库日期；系统提示词里加了"没有日期就不要说是新的、禁止输出片段里没有的编号和数量"两条硬规则。

随后又发现概览型问题被"挑重点"链路压成个位数——"列出最近一周全部文章"和"挑最相关的几篇讲讲"是方向相反的两种意图，同一套精排链路只该服务后者。于是按意图分流：概览问题走独立的清单通道（一行一篇、直接查文章表、不走裁剪），并按天分批渲染。这里还顺带堵掉一个"数字撒谎"：截断后必须如实告知"共 N 篇、列出最新 M 篇"，不能把 80 篇说成全部。中途还修了一个流式渲染的经典坑——服务端兜底生成的内容只落库没有推送给前端，用户看到的就是空白；判定法很实用：库里有字、页面空白，基本就是漏了推送。

6. 文章管理与隐私治理

文章管理的完整系统设计当天拍板当天落地：后端不新建服务，落点选在文章主数据所在的服务上，权限三件套原样复用；前端新增微信侧管理页；已归属的敏感文章全部划归私人可见并同步清出知识库索引（留快照、一条语句可回滚），定时任务兜底新文章的敏感扫描。落地后二十余项验收全绿，包括未登录请求零穿透、越权改判无效、软删恢复往返等。

晚上又修了管理页的"加载失败"：未登录时前端无条件发请求、401 早退吞掉了本该显示的友好空态。验证手法值得复用——不装浏览器，用最小 DOM 替身跑页面内联脚本，断言三种登录态各自的文案分支。

7. 深色主题与"只写不读"

老板反馈"选了深色保存后页面没变化"。根因不在配置页，而在全站缺一层胶水：偏好注册表定义了九项用户偏好、也能入库，但没有任何页面读回来应用——典型"只写不读"。解法是新建全站共享的偏好层：首帧同步打主题标记（避免深色用户闪一帧浅色）、后台对账、跨标签页同步；配色实现改用浏览器原生的 light-dark() 函数加 color-scheme，彻底避开"媒体查询与用户选择谁优先"的打架。验收六场景全过，关键一项正是"系统深色 + 手动选浅色 → 仍是浅色"。

二、SFC《三国志IV》汉化预研：一次干净的可行性验证

副线是对一款 1994 年日文原版主机游戏的汉化预研。文件身份先做了实测纠正（一个 ROM 加两个存档，不是拆好的资源包），然后得出几个关键判据：

• 文本层是明文双字节日文编码，未压缩、非私有码，难度远低于同类游戏；
• 最核心的可行性结论：日文与中文同为双字节编码，原文本按字节对齐终止，等长替换成立——不需要改指针表、不需要搬数据、不需要碰机器码，唯一约束是字数对齐；
• 真正的瓶颈是字库容量（现有约七百字，需求约九百字），需要扩容 ROM，补丁格式要选支持尺寸变化的那个；
• 区分文本与图形数据是核心难点，需要"对齐 + 终止 + 含假名 + 上下文连贯"四重判据，且必须人工复核。

产出预研报告与九轮可复用的探测脚本，三条技术路线（等长替换 / 重建指针表 / 基于社区补丁二次创作）连同周期估算一起待批示。这个项目的价值在于方法论：先用探测脚本把"能不能做"变成"怎么做、多大工作量"，再决定投入。

三、投影仪 TV 装机：通道收敛的取舍

给客厅投影仪装三个 TV 应用。实测发现本机外网环境发生重大变化：主流开源托管平台主站与多家应用市场全部不可达，仅少数镜像与官方分发通道存活。由此收敛出三条通道：开源应用走国内镜像、官方应用走自带分发网、闭源商业应用本机无干净通道改走设备内置应用市场。另外固化了一个上机前包名核验的小工具——从安装包多编码提取包名，防冒牌应用。开源软件找镜像、闭源软件找设备自带市场，是这个场景下最省力的取舍。

四、每日情报例行轮次

行业情报第三十轮照常产出与发布：关键词是判定层巨头化、某云厂商数十亿级智能体决策模型、国内第五个发放算力券的城市，以及自家官网访客行为的一个连续四天的深读信号，据此提出三条官网动作项。

今天沉淀下来的几条

1. 同一条请求在一个页面出现两次时，改参数必须全量同步——启动路径漏掉过滤参数，就是"删除后复活"的全部根因。
2. 搬凭据必须 grep"谁在从源码抠它"——间接依赖静默失败，比直接报错危险一个量级。
3. 监控脚本要用已知异常验证警报器本身——"没报警"可能是警报器坏了。
4. 同一链路服务两类意图时，正确做法是按意图分流，而不是调参数——"挑重点"和"列全量"方向相反，硬调必然顾此失彼。
5. 凡要按日期分组的字段，SQL 层就该输出字符串格式——驱动返回的日期对象经序列化后会让分组静默全空。
6. 图标用现成的，别自绘；居不居中，截图别算包围盒。

时间分配大致是：知识库问答及配套的安全与主题治理约占八成（其中凭据治理与时间语义检索各占大头），SFC 汉化预研约一成，投影仪装机与情报轮次合计约一成。

未公开项

本文为对外技术博客口径，以下内容做了概括或略去，共 6 处：

1. 服务器部署拓扑与进程编排细节（凭据治理部分只讲方法不讲坐标）；
2. 具体凭据清单、弱口令分布与数量级（安全敏感，不宜公开）；
3. 站点自身接口、权限与身份实现细节（避免暴露攻击面）；
4. 情报轮次的内部编号体系与来源渠道（内部规程）；
5. 汉化项目的具体文件特征、地址计算数值与社区补丁来源（涉及他人作品细节）；
6. 家庭设备与内网环境信息（私人事项）。