前两天发了一篇 Rewriting Bun in Rust 原文的翻译，内容有点多，这次我自己整理了一份精简版。 背景 一开始是因为在 X 上刷到 Bun 官方博客一篇《Rewriting Bun in Rust》，作者是 Jarred Sumner。看完挺震撼的——1 个工程师，用 CC（Claude Code）+ Claude Fable 5（重写那会儿还是预发布，现在订阅用户已经能正常用了

背景已经高强度的使用 claude code 大半年的时间了，积累了不少好用的 SKILLS 和工具，今天来整理一下分享给大家。 我安装了大约 70 几个 SKILLS，但常用的其实也不太多，下面介绍一些我个人觉得效果不错的。推荐使用我开发的 skilldeck 来管理本地的 SKILLS： 12brew tap crossoverJie/skilldeck && brew i

背景以前学 linux 命令行，常见路线是记住一堆 grep、find、sed、awk，然后自己在代码库里定位问题、筛选文件、拼接命令。 但进入 Coding Agent 时代后，我觉得人和终端的分工变了。 代码搜索、读取配置、分析调用链、运行测试，这些工作本来就是 Agent 擅长的。面对一个仓库，Claude Code、Codex 之类的 Agent 会自己判断该用 rg、git diff、j

背景最近将终端从 Warp 切换到了 cmux，用了一段时间后，现在已经基本上满足我的所有需求，所以才有这篇安利的文章。 开始之前先回顾下自己的终端使用历史。刚开始工作那时候使用的是 Windows，用得最多的终端就是 xshell，后面切换到 macOS 之后自然就切换到了 mac 上用的最多的 iTerm2。

背景最近在搞 StarRocks 的跨版本升级（3.3 → 3.5），中间踩了不少坑。我之前也写过一篇 StarRocks 升级注意事项记录了手动升级的流程，但那只是针对小版本（3.3.3 → 3.3.9）的升级。 跨大版本升级完全是另一回事——3.3 到 3.5 中间有 6000+ 个 commit，里面藏着各种不兼容变更：配置默认值变了、Session Variable 改了、Protocol

背景相信现在 AI Coding 已经占据工作中大部分代码了，甚至很多人就直接交给 AI 来写，自己只做 review。 再有甚者 review 都不做了，直接全面交给 AI，自己只做产品经理提需求、验证功能逻辑是否正确——也就是现在很流行的 Vibe Coding。 前段时间我自己用 Vibe Coding 写了一个 macOS 原生的 APP，以此来判断 Vibe Coding 是否能让我在一

背景最近我一直在折腾项目文档生成的事情。之前写过两篇关于 deepwiki 的文章：deepwiki-rag-principle 讲了 RAG 原理，deepwiki-optimize-line-number 聊了给代码加行号的优化。 经过几轮迭代，搞了两个优化： 代码加上行号前缀 基于 Proto 文件生成确定性目录 这两个优化背后其实是同一个思路：把确定的东西明确告诉 AI，不确定的才让

背景最近我们在做一件非常危险的大事——把用了好几年的腾讯云企业版 Istio 服务网格迁移到社区开源版。 事情的起因是腾讯云突然宣布不再维护 Istio 服务网格了，后续也不会推出新版本。这就导致我们的网格一直停留在旧版本，进而连带着 k8s 这些基础组件也很难升级。可以说是血的教训：用托管服务一时爽，一旦厂商放弃维护，迁移成本还是得自己扛。

背景 上周末参加了一个我们重庆本地的一个 AI 分享会，分享了一些企业大模型与 Vibe Coding 的实战经验，现在把它整理成一篇 blog。

背景最近在用 deepwiki-open 给内部的 Java 项目生成 wiki，发现一个很明显的问题：生成的 wiki 页面里引用的代码行号经常不准确，看起来是 LLM 根据上下文自己推算的。 比如一个函数明明在第 503 行，生成出来的 wiki 里可能标注成第 510 行甚至更离谱的数字。 之前我在 DeepWiki 一个常用 RAG 应用的开发流程 里分析过它的整体流程，本文主要聊聊我们在