远程小电脑通过 NPS 暴露 SSH 入口。现场现象很具体：SSH 连上后，过一段时间开始变卡，随后出现断联；新开一个 SSH 连接时，客户端卡在 banner 阶段，最后报： 1Connection timed out during banner exchange 这类问题容易被归到三个方向：本机 SSH 配置、云端 NPS、设备侧 4G 网络。最后的结论是：本机到云端跳板没有问题；NPS 服

前两篇把 LLM-wiki 的文档模型和治理 CLI 跑起来了：topic 承接长期业务知识，change 承接一次需求或修复过程，code.path 让代码变更可以反向找到文档。今天继续往前推了一步，主要解决一个更细的问题：change.code 到底是不是交付事实源。 结论是：不是。change.code 应该只是索引快照，真正证明一个 change 已经交付的事实源应该是 commit。基于

上一篇文章先把 LLM-wiki 的文档模型收住了：topic 保存长期业务事实，change 保存一次变更过程，代码通过 code.path 反向索引文档。这次没有继续加概念，而是把它落成一个能跑的 Python CLI，然后拿真实提交试了一次。 试跑结果很直接：基础校验能跑，代码影响分析也能跑，但一笔多加料终端、多吊钩秤的提交没有命中任何正式 wiki 文档。工具只返回了一批 uncovere

最近在设计一个给 coding agent 使用的业务文档自管理系统。问题不是“要不要写文档”，而是：代码已经是运行行为的第一事实源，文档如果只是人工补充说明，很快会漂移；但如果完全不写文档，很多业务前提、取舍和禁区又不会自然出现在代码里。 这套系统最后收敛成一个比较小的模型：代码负责表达当前怎么跑；wiki 负责表达代码之外的业务语义和设计取舍；脚本负责稳定发现影响范围；agent 只处理语义判

端侧 Java 服务里有一类配置读写很容易被忽略：系统配置表看起来很小，单次 selectById 也很快，但高频轮询、状态推送、版本上报叠在一起后，会把 SQLite 打成持续背景负载。 这次要处理的不是一次慢 SQL，而是低价值的高频读写。目标也很明确：不改变业务配置语义，减少系统配置读写次数，把优化开关做成可回退能力。 现场数据监控窗口是 30 秒。某台端侧设备上的数据库监控大致是这样： 1

这次主要补的是 Agent 编码之后的下一段路：代码可以自动改了，但构建完成、镜像确认、部署调试机这几步还断在人工操作里。结果就是 Agent 写完代码以后，仍然不知道什么时候可以部署，也不知道应该拿哪一个镜像去跑调试。 最后落下来的方案没有做成一套很重的发布平台，而是先把调试闭环打通：构建脚本上报状态，后台服务记录构建产物，Agent 查询成功镜像，再调用仓库里的受控部署脚本更新调试机。 目标当

这次排查的是边缘端 Java 服务的一次现场 CPU 飙高。 现象很直接：某天 15:30 到 16:00 左右，Java 进程 CPU 很高，日志里持续报 SQLite/JDBC 连接获取失败。现场关闭“测点缓存”功能并重启后，服务恢复。这个功能之前一直开着，只有那天爆了一次，后面也没有再打开。 一开始很容易把问题归到测点缓存上：关了它就好了，那是不是缓存库坏了？但日志和库文件检查对不

一台现场小电脑通过 SSH 登录后不断刷： 12channel 3: open failed: connect failed: Connection refusedchannel 4: open failed: connect failed: Connection refused 现场刚经历过一次升级中断，第一反应很容易落到 Java 服务、SSH 配置、端口转发、Docker 容器状态这些方向

最近做了一个内部文档同步工具，目标很简单：把浏览器里有权限访问的语雀知识库定时同步成本地 Markdown，再给后续 Agent 检索、引用和 RAG 使用。 真正卡住的不是目录解析，也不是 Markdown 入库，而是登录态。Playwright 自带 Chromium、Playwright channel: "chrome"、系统 Chrome 独立 Profile 都试过

项目里有一个 app_manage，前端是 React + Vite，后端是 Python + FastAPI。最开始的问题很直接：service.sh 启动时，能不能把前端也一起拉起来，并且把 Python 服务的默认首页切到这个前端。 这类需求第一次看，很容易顺手想到 service.sh 里再后台起一个 npm run dev。它能跑，但不太像一个稳定的服务发布方案。真正要先分清的是，这个前