- 博客(14)
- 收藏
- 关注
RSS订阅原创 不装 Playwright：130 行 Node 手搓 CDP 客户端驱动 Chrome 的最小实现
【代码】不装 Playwright：130 行 Node 手搓 CDP 客户端驱动 Chrome 的最小实现。
2026-10-03 01:23:38
287
原创 SQLite 会话库打开卡死排查实战：65416 个 part 碎片的合并与 WAL checkpoint 归零
【代码】SQLite 会话库打开卡死排查实战：65416 个 part 碎片的合并与 WAL checkpoint 归零。
2026-10-02 09:55:27
541
原创 流量我自己掌控：从 nginx 原始日志扒出真实下载量，官网到底谁在用
先把结论摆在前面。一是，这个桌面软件官网日均两千到三千的 PV、一百四到三百一十个独立 IP，大头是已安装客户端的更新心跳和扫描器探测，真人浏览比看板上的数字小得多，搜索来的来源近乎为零。二是，"下载量"这件事，我认可的判据是：响应状态码 200 且实际发出字节数不低于 30MB；按请求次数去数，会被断点续传和分段下载虚增好几倍。
2026-10-02 09:54:47
366
原创 进程还在，任务却没跑：自动化看门狗三层守护的工程复盘
定时自动化任务的故障就三种形态：注册了没跑、进程活着但逻辑死了、重启后行为不符合预期。任何单层的守护——只配自启、只加重启、只靠人肉巡检——都盖不全这三种形态。能盖全的架构底线是三层：开机自启管冷启动、进程内异常兜底管自己崩、周期看门狗管一切其它死法，而且每一层都必须幂等。先交代来源：我运维着若干桌面自动化服务——两个本地代理进程（一批长任务经它们出网调用模型）、几路 cron 风格的定时任务（其中一路是心跳看护）。
2026-10-01 15:41:19
707
原创 mysql2事务裸return不回滚：连接池全池卡死复盘
，污染在池里自我繁殖。这一项是排障时的一个乌龙：老版本 mysql 曾有这个参数，mysql2 在 3.x 版本里把它移除了（changelog 里明确写着 remove acquireTimeout invalid option），所以"等连接超时自动失败"这条路在新版里根本不存在——池的排队要么等到天荒地老，要么手动放弃。它持有的行锁没有被释放，任何后来要改这些行的事务，都会排队等待——等待链一长，业务写入全部超时，这就是"偶尔重启前也恢复不了"的原因：只要那条僵尸事务还在，被它锁住的行就一直锁着。
2026-10-01 15:40:46
553
原创 消息去重与幂等：从指纹账本到布隆过滤器的三级防线
三级防线拆开看，没有一级用到新东西：哈希、原子写、TTL、超时释放，全是老手艺。真正决定成败的是一开始那两个判断——键要选在输入侧。这个决定把"同一件事"的判据从"我输出了什么"换成了"我收到了什么"，后者是客观的、稳定的，前者带有随机性。所有基于输出的去重方案最后都会在重试路径上崩掉，因为重试的全部意义就是"再生成一次"。占位要早于处理。判据必须能表达"正在做"这个中间状态，否则系统在"决定要做"到"已经做完"之间是失明的，而这段区间恰好就是网络、模型调用、发送这些最慢的步骤所在的区间。
2026-09-30 09:38:59
280
原创 事故出在模型外面：从 Prompt Engineering 走向 Harness Engineering 的四次线上复盘
过去一年，我们把大模型接进一款跑了多年的某电商接待机器人，前端入口是微信客服会话。接完之后线上出的事故，复盘下来没有一起的根因在模型里：模型本身没有变笨，价格没变，上游也没换过几次。出事的全是包在它外面的那一层——喂给它的教材、下一轮带进去的上下文、往外传输的流式协议、以及放它执行动作之前的那道闸。这一层有个英文名字，Harness，直译是"挽具"：让一匹马愿意拉车的所有马具、缰绳和车辕。
2026-09-29 17:11:13
389
原创 LLMOps：发布原子不是模型，是提示词/语料/模型三元组
回到标题那句话。发布原子不是模型，是提示词、语料、模型版本的组合——这不是一个说法，是一条能直接指导工程动作的结论。它决定了你该把哈希校验放进 CI 还是放进人眼，决定了你该让版本号自动生成还是靠人记得改，决定了你的回滚单位是一份代码还是一个三元组快照。三元组里真正难的不是技术，是它的形态是文本。文本会被复制、会被手改、会被当成文案而不是代码。
2026-09-29 09:04:05
412
原创 应用日志去哪了：journalctl 只见启停不见业务日志
表示持久层最多占 4GB，超限时 journald 会从最老的日志开始自动清理，也就是说 journal 这条路天然有"磁盘占用有界"的保证——这一点和后面那个只增不减的 app.log 形成了刺眼的对比，也是"journal 与文件谁是权威源"这场争论里 journal 方面最实在的论据。有同事主张生产也开着 debug 方便排障，实测的结论是反对：这个工具的消息收发是高频事件，debug 级别全开时日志量是 info 的四十多倍，journald 的速率限制会先一步触发丢日志——
2026-09-28 09:40:01
507
原创 支付回调验签与订单查询的四个坑排查实录
同理，“空值是否参与”"字段名大小写是否敏感"这些边角规则，本质上都是在补齐规范化的定义，缺了任何一条，两边的规范化结果就可能不同，验签就会随机失败。MD5 的抗碰撞性确实早已被打破，但本方案的用法是"密钥拼接后做摘要"，安全目标是防伪造而不是防碰撞，截至目前没有公开的、能在真实网关场景下稳定伪造有效签名的通用攻击。切到生产之后，验签成功率却掉到了一个很低的水平——网关的重试机制会不断补发通知，我们的日志里全是验签失败的记录，而成功的那几笔，看起来毫无规律。"实际上，网关对超期未付订单的记忆是有限的。
2026-09-28 00:56:33
480
原创 Naise AI 核心应用场景与落地实践指南
在日常开发和产品落地过程中，我们常常面临一个核心痛点：如何让人工智能真正融入业务流，而不是仅仅作为一个聊天玩具存在？很多团队引入了大模型，却只停留在“问一个问题得到一个回答”的浅层交互上，实际的生产效率并没有得到本质提升。真正的价值在于将 AI 能力封装进具体的场景，让它自动处理重复性高、规则明确或需要大量创意发散的任务。无论是电商运营需要每天产出上百条商品描述，还是跨国会议后需要快速整理出 actionable 的纪要，亦或是教育场景中针对每个学生的差异化辅导，这些都需要一套可执行、可落地的自动化方案。
2026-09-26 15:01:04
618
原创 AI客服系统架构复盘：LLM应用上线后，决定稳定性的不是模型也不是提示词——一个7×24电商客服机器人的大模型工程化实战
前阵子"从 Prompt Engineering 走向 Harness Engineering"这个话题上了热榜，核心论断一句话：模型不是产品。我认同这个判断，但想把它往前再压一层。——输出清洗、流式协议重建、上下文卫生、发送前闸门、失败兜底、成本意识。模型偶尔犯轴，提示词偶尔失配，但只要这圈支架做得够硬，客户那边就是感知不到的；反过来，支架薄一层，上游每一个不规范的习惯都会原样砸到真实客户脸上。这篇是一台 7×24 在线的电商客服机器人的工程复盘。
2026-09-25 12:06:12
450
原创 电商客服 AI Agent 架构复盘：意图路由分档、转人工兜底与幂等去重——智能体设计模式的最终形态
档判据来源产出典型触发一档·自定义规则商家自己配置的关键词与话术毫秒级 canned 回复商家配过的发货地、尺码建议二档·工单档操作性意图识别生成工单并决定归属“改地址”“催发货”“申请售后”三档·转人工规则服务红线关键词表进入人工链路买家明说"找人工"、投诉升级类词四档·AI 档模型生成清洗后的回复文本长尾咨询、寒暄、复杂表述规则在前、模型在后；红线夹在中间兜着。一条消息每往上走一档被拦下，就少一次模型调用、少一分幻觉风险。
2026-09-25 11:58:34
647
原创 IndexNow 接入实录：key 托管、批量提交与对账
回过头复盘"提交成功但收录不动"的那段时间，它其实暴露了一个比脚本更深的问题：我们把"提交通道"当成了收录问题的全部，而通道两端——本站的 URL 质量、引擎侧的抓取预算——才是决定性的。协议没有强制，但 key 文件是被引擎侧缓存的，频繁更换会造成一段时间内的验证混乱。最后回扣一句：官网的收录问题，最终靠这套十几 KB 的提交脚本加上一道 sitemap 对账工序解决，而它服务的对象——那套需要被搜到的、本地化部署的微信自动回复工具文档——也在收录提速之后，第一次让用户通过搜索引擎直接找到了排障页面。
2026-09-24 14:43:23
1014
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人