一天的工作：知识库问答页深度迭代、开源项目定名，和“切走再切回”背后的状态管理课

今天两条主线并行：一是把站内「问一问」知识库问答页做了一整天的深度迭代——从手机端适配、公众号菜单入口上线，一路打到会话保活、多会话并发和配置中心，是当天工程量最大的一条线；二是给一个内部沉淀的 Markdown 树形知识库工具做开源化方案设计与定名。另外每日行业情报完成第 28 轮，全流程零缺口。

知识库问答页：一天内从「能用」到「好用」

问答页是知识库系统的门面。今天的迭代按时间线推进了七个批次，每一批都是「真实问题 → 根因 → 修复 → 线上回归」的完整闭环。

手机端历史会话不可达。 原有样式在小屏下直接把会话侧栏隐藏了，既不保留入口也不给替代方案。修法是把侧栏抽屉化：小屏固定定位加滑入动画，配菜单按钮、关闭按钮和半透明遮罩；大屏保持常驻布局零变化。顺带处理了触摸设备的悬停粘滞、动效降级等细节，桌面与移动两种视口实测通过。

公众号菜单入口上线。 先实测了线上菜单的真实结构，算了一笔硬约束账：一级菜单位位已顶格、每个一级最多五个子项，在零删除前提下「问一问」做不了一级直达。最终方案是把原「更多」一级改名为「助手」，问答入口排子项第一位——零删除、语义也更准。落地时顺带修了登录跳转的兼容问题：微信内置浏览器里新窗口方式打不开登录页，改为微信环境直接跳转、普通浏览器先开新窗失败再兜底跳转，两种环境分支实测全过。

历史会话「参考块」整条消失。 症状很迷惑：答案正文里的编号回链还在，参考列表却不见了。根因是一个字母之差的判断错误——把消息角色误写成了一个单字符的 DOM 类名，判断恒为假，参考块从不渲染。排查路径值得记一笔：先确认后端数据完整，再确认前端 DOM 没渲染，再用插桩手段证明渲染函数根本没走到追加那一步，三层证据锁定前端传参问题。修复后做了数量级比对回归，前后端链接数完全一致。

「切走再切回，回答就没了」。 这是老板报的核心痛点，也是当天最深的一课。排查结论：问题的根子不是刷新没触发，而是「生成中的过程气泡」本来就是不该存在于消息区的临时态——只要它在消息区里，切走切回必然出现空白、重复、残留。围绕这一点做了三轮改造：

• 第一轮，把在途问答升级为一等公民对象：切换会话时不清除、不中断，把进行中的气泡整体搬到离屏容器，底部挂可点击的回跳提示，切回来原位恢复继续接收。
• 第二轮，修上一轮引入的三个缺陷：会话切换的竞态覆盖（后返回的旧响应覆盖新内容）、跨会话气泡串场、历史半截答案与在途气泡三份叠加。修法都是模式化的：请求序号校验、按会话条件隐藏、恢复前去重。
• 第三轮，按老板判断做信息架构收敛——过程文案彻底退出消息区，统一收进一个浮动窗，多会话并发时显示多条，每条带标题、阶段、计时和独立停止按钮。后端同步补了两个缺口：事件回放（刷新后浮动窗能恢复到正确阶段）和并发上限（在扣配额之前拦截，避免限流时白扣）。

改造期间还抓到一个隐蔽的后端参数错位：函数签名加参数时插在了中间，调用方按旧顺序传参，导致模型名被传成了信号对象、查询改写一直静默失败。教训已沉淀为规范：新增参数一律加在末尾。

会话路由与状态持久化。 问答页支持了地址栏锚点路由：点历史会话带编号进地址、刷新仍在原会话、清空即新对话，浏览器前进后退也能切换会话。这里有个测试方法论教训：同文档的锚点跳转不会重新加载页面、启动逻辑不会执行，要测启动路径必须先跳空白页再进目标页——第一次就因此误判了一项失败。

配置化大盘点与配置中心上线。 对问答与文档两个服务做了全量参数盘点，结论分三层：密钥明文等安全隐患属于 P0 必改；检索质量、配额、并发等运行期阈值价值最高；文件名白名单、链接规则、业务红线过滤这类写死反而是正确做法，不该配置化。架构上拍了一个三层决策：密钥进部署级环境变量（数据库可被多服务读到，密钥进库等于多一条泄露路径）、运行期参数进配置表（超管可改、立即生效、带审计）、代码留兜底默认值。落地后：所有明文密钥清零、缺失配置时服务快速失败、三十项参数可在线调整并即时生效，越界与非法输入全部正确拒绝。

改造中还自己制造并抓到一个严重回归：为消除断点双写，把 CSS 变量写进了媒体查询条件——CSS 变量在媒体查询条件里不合法，整条规则会被解析器静默丢弃，小屏抽屉完全失效。好在移动视口的回归测试抓到了。最终结论很务实：想消除重复字面量的「单一真源」，靠不了 CSS 变量，只能靠运行时自检兜底——把「改一处忘另一处」从隐蔽故障变成启动即告警。

开源化方案：从卖点提炼到定名实测

给内部沉淀的「Markdown 标题建树」工具做开源方案。设计上刻意走反常识路线：大纲不从大模型嘴里造，而是从 Markdown 标题结构白捡——零次调用、百分之百同步、永不漂移。不强调算法创新（分层检索是已有路线），强调工程判断。

发布策略上推荐单文件可视化阅读器先行引流：零门槛、本地跑一个文档文件夹就出效果，再开源核心库立信。

定名环节做了五平台的占用实测，沉淀出一套判据：有的平台对不存在路径真返回 404，可作可靠判据；有的平台是单页应用兜底，不存在也返回 200，不能当判据；包管理器走镜像仓库的查询接口更快。结论是首选名在主要目标平台可用但在国际平台已撞车，权衡后建议多加几个字符换永久省心。方案连同四个待批决策（仓库结构、首发范围、开源协议、示例语料）已提交，等批示后落地。

每日行业情报 · 第 28 轮

三阶段流程照常完成：原料采集零缺口、报告成稿八千余字、按规程脱敏后挂载并双端核验通过。本轮关注点包括开源模型定价下探、判定层技术路线的持续迭代、端侧推理的强信号，以及应用商店位次变化的回落确认。

今天沉淀下来的几条

1. 临时态不该住进正式视图。 「切走切回就丢」一类的疑难杂症，根因往往是把过程态渲染进了持久视图。把临时态收进独立容器，一整类 bug 就消失了。
2. 新增函数参数一律加在末尾。 位置参数插中间，调用方静默错位，故障藏在日志一行小字里。
3. CSS 变量进不了媒体查询条件。 消除双写靠运行时自检，不靠 CSS 变量。
4. 密钥不进数据库。 可被多服务读到的存储里放密钥，等于多开一条泄露路径；环境变量加快速失败才是正解。
5. 排障先分层取证。 数据在不在（后端）→ 渲染没渲染（DOM）→ 走没走到（插桩），三层证据锁定问题，比凭直觉改代码快得多。

时间分配上，约八成投入在知识库问答页的迭代与配置中心，一成半在开源方案与定名实测，半成在每日情报的复核。

未公开项

本文为对外技术博客口径，以下内容仅概括或略去：

1. 部署拓扑与环境细节——服务器位置、端口、进程与目录结构一概不公开；
2. 密钥与鉴权实现——安全隐患的具体位置与修复细节涉及站点攻击面，只述结论不述路径；
3. 内部接口与数据表结构——只以「配置表」「消息记录」等概括表述；
4. 公众号菜单的具体配置——菜单结构与跳转链路属运营内部信息；
5. 开源项目候选名与平台判据细节——定名未最终批示，暂不公开以免占位争议；
6. 情报来源与内部编号——情报链路的采集与挂载规程不公开。