这篇文章记录了作者在Kubernetes集群上排查Istio Ambient Mesh网络问题的全过程。问题出现在PR预览环境的请求始终被路由到baseline pod而非目标pod。经过9小时的系统排查排除了众多可能性后，AI助手Claude Code建议标记为已知限制。但作者启用独立调查subagent后发现，真正的根源在于Cilium的socket-level负载均衡配置更新后未触发Daem

这篇文章记录了作者在Kubernetes集群上排查Istio Ambient Mesh网络问题的全过程。问题出现在PR预览环境的请求始终被路由到baseline pod而非目标pod。经过9小时的系统排查排除了众多可能性后，AI助手Claude Code建议标记为已知限制。但作者启用独立调查subagent后发现，真正的根源在于Cilium的socket-level负载均衡配置更新后未触发Daem

摘要：本文复盘了一起由VS Code插件内存泄漏引发的服务器故障。故障始于8月14日Claude会话卡顿导致进程堆积，经过20小时缓慢积累，最终在次日因内存压力引发IO风暴，导致四核服务器负载峰值达38.7。作者通过分析进程树、压力指标和内核日志，发现59个VS Code进程占用7.3GB内存的根源是旧版本客户端未正确关闭会话。解决方案包括：1) 精确清理僵尸进程树；2) 添加4GB swap作为

摘要：本文复盘了一起由VS Code插件内存泄漏引发的服务器故障。故障始于8月14日Claude会话卡顿导致进程堆积，经过20小时缓慢积累，最终在次日因内存压力引发IO风暴，导致四核服务器负载峰值达38.7。作者通过分析进程树、压力指标和内核日志，发现59个VS Code进程占用7.3GB内存的根源是旧版本客户端未正确关闭会话。解决方案包括：1) 精确清理僵尸进程树；2) 添加4GB swap作为

摘要：作者发现Claude Code插件在处理第三方API的长响应时出现严重延迟。通过分析发现，问题根源在于插件逐token处理事件导致渲染队列积压，阻塞了控制消息。虽然会话逻辑已结束，但通知系统和界面显示存在时间差。最终通过中间件合并事件流解决了性能瓶颈。文章揭示了流式处理中颗粒度与性能的平衡问题。（149字）

那个任务已经在我的远程主机上跑了一阵子——那种我启动之后就转身离开的、长时间多步骤的活。我人在别处，手机忽然震了一下。是我自己写的一个小提醒工具发来的 Telegram 消息，它会在 Claude Code 的一轮任务需要我输入、跑完，或者挂掉的时候通知我——这样我就不用一直守着。这次是第一种：Claude 走到了一个它自己做不了主的决定，停下来问我。我没能及时看到那条提醒。

这篇文章讲述作者在开发claude-code-notify工具时遇到的两个关键bug：一个是工具未能识别Claude Code的用量限制错误，另一个是工具错误地将credits不足误判为用量限制。问题根源在于作者最初忽视了官方文档中关于异步写入会话记录的警告，以及错误地依赖了一个多义字段。通过添加调试日志、实施重试机制、优先使用结构化载荷数据，并引入更精确的错误码判断，最终解决了这些问题。文章强调

文章摘要： 本文通过作者开发两个AI辅助编程项目的对比，揭示了纯聊天式编程工作流的局限性。在第一个项目blockly-platform中，作者仅通过Telegram与Claude Code交互，导致同一类安全配置错误反复出现四次却未被及时发现，因为缺乏代码可见性和连续性跟踪。第二个项目programming-learning-platform进行了三项关键改进：1）使用IDE远程开发模式获得代码可

这篇文章探讨了在多项目并行开发时，使用 Claude Code 遇到的"任务状态不透明"问题及解决方案。作者最初通过简单的 Stop 钩子发送通知，但发现后台任务和子代理会导致误报。通过分析会话记录中的 tool_use_id 匹配任务状态，最终开发出可靠的 claude-code-notify 工具，能在三种关键场景（任务完成、需要输入、出错终止）时通过 Telegram 准确通知。该方案特别解