从企业版 Istio 迁移到社区版：一场给高速行驶汽车换轮胎的实践

针对腾讯云企业版Istio停止维护的情况，团队需将服务网格迁移至社区开源版，此过程如同为高速行驶的汽车更换轮胎，风险极高。为确保可靠性，迁移采用了双控制面并行与按namespace灰度切换的策略：在集群内同时运行企业版和社区版控制面，通过istio.io/rev和usergroup标签驱动sidecar注入版本，并利用discoverySelectors实现控制面隔离，仅感知特定标签的namespace，保障并行环境互不干扰。迁移中深入源码验证关键机制，包括MutatingWebhookConfiguration如何根据namespace标签动态匹配注入版本、discoverySelectors的实时过滤与证书自动下发逻辑，以及ALLOW_ANY流量策略确保跨控制面互通。实践遇到了证书不匹配、503错误等问题，通过调整标签和确保discoverySelectors配置解决。AI技术被用于辅助分析Istio源码，快速定位逻辑并验证方案可行性，提升了高风险变更的把控能力。整体迁移依赖详细的检查清单和渐进式操作，最终实现了控制面平滑过渡与流量安全切换。

手搓一个 Agent 驱动的项目 Wiki 生成方案

作者在项目文档生成实践中，发现传统RAG方案如deepwiki在处理确定性结构（如目录、接口列表）与不确定性分析（如架构总结、ER图）时存在局限。其核心思路是：将确定性信息（如行号、Proto文件）明确处理，仅将归纳、推理等任务交由LLM，以实现各取所长。然而，deepwiki的独立页面架构难以满足基于已生成内容进行汇总的需求。 为此，作者转向基于Claude Code的方案。该工具采用工具驱动检索机制，通过Read、grep、LSP等确定性工具链精准定位代码，而非依赖向量化索引。这使生成的Wiki内容更准确可控，并可复用为跨项目Skill。尽管需要多轮调试且自动化程度较低，但其在内容质量、尤其是跨文件关联分析上优势明显。文章最终提出互补策略：项目初期用deepwiki快速搭建框架，成熟阶段则用CC方案精细打磨可控的文档体系。

别再傻等了，给 Claude Code 装个通知铃铛

这篇讲的是作者在使用Claude Code这类AI Agent时发现的一个痛点：任务跑在后台，总忍不住去查看状态，或者错过了需要授权的交互提示，导致效率低下。 他先是试了让LLM在任务完成时播放提示音，但发现这个“软提示”方案极不靠谱——LLM不会100%遵循指令，长对话还会压缩丢掉提示词，什么算“任务完成”也没个准谱。 于是他转向了确定性的“硬触发”方案：利用各平台的Hook机制，开发了`agent-notifier`这个SKILL。它能统一监听Claude Code、Copilot CLI、Cursor等多个平台的事件（如任务空闲、需要授权），然后并发地将通知发送到声音、系统通知、Telegram、邮件等多种渠道。 整个设计很巧妙，纯用Python标准库实现零依赖，拿过来就能用。核心是统一事件模型加并发分发，单个渠道失败也不影响其他。本质上是把通知这个“该确定的事”从不靠谱的LLM手里，交给了确定的Agent脚本去执行，最终实现了可靠的自动提醒。

全程用 Claude Code 搓了一个 macOS 原生应用：SkillDeck

文章作者因在多个AI编程助手（Claude Code、Codex、Gemini CLI、Copilot CLI）间切换时面临Skills管理分散、安装更新繁琐的问题，决定利用Claude Code全程辅助开发一款名为SkillDeck的macOS原生应用。该应用提供了统一的图形化界面，核心功能包括：三栏式仪表盘支持搜索与按Agent过滤；集成Skills市场实现一键安装；通过对比tree hash实现更新检测；提供SKILL.md编辑器；以及通过开关控制Skill在不同Agent间的symlink分配，实现一份Skill多处共享。开发过程体现了AI编程辅助跨语言开发的巨大潜力——作者虽无Swift与macOS开发经验，但通过清晰的需求提出、代码测试与问题反馈，借助AI完成了完整应用的开发。文中总结了多项AI编程实践技巧：每个功能在新对话中进行以避免上下文干扰、将AI生成的复杂分析结果保存为文档以节约token、利用`--resume`恢复会话但不宜长期依赖、以及通过`CLAUDE.md`文件设定开发规范（如Git分支策略、测试要求）来约束AI行为。项目已开源，旨在解决多AI代理下Skills生命周期管理的痛点。

SkillDeck 支持 OpenClaw 了，顺便聊聊小龙虾

SkillDeck 刚更新了 v0.0.14，正式支持了 OpenClaw。这次更新主要有两方面：一是新增了对 Antigravity、Cursor、Kiro、CodeBuddy 和 OpenClaw 本身的 Skills 目录管理，现在总共支持 10 个主流 AI coding agent；二是直接集成了 ClawHub 市场，可以在 SkillDeck 里浏览、搜索并一键安装 Skills，不用再手动操作。 作者借着这次更新，也聊了聊对 OpenClaw 这波热潮的看法。他认为爆火背后是自媒体的焦虑传播、AI 公司卖 token、云厂商卖服务器等多方推动。OpenClaw 的本质更像是一个高级自动化工具，核心是让 AI 通过模拟操作来帮我们执行任务。但当前最主要的问题是权限过大，已经出现了不少安全案例，比如公网暴露导致电脑被远程控制。 理想的解决方案或许是让应用间通过标准化的 AI 可识别接口通信，但这涉及厂商的商业利益，还有很长的路要走。最后作者提醒，工具是用来解决问题的，不必盲目追逐热点，Claude Code 等工具已具备的循环任务功能，其实和 OpenClaw 没有本质区别。

如何在本地打包 StarRocks 发行版

本文针对 StarRocks 用户在等待官方版本发布周期时，需要快速应用修复 PR（如物化视图重启导致全量刷新、excluded_refresh_tables 参数跨数据库失效等）的场景，介绍了本地打包发行版的完整流程。核心方法是利用社区提供的统一 Docker 镜像（starrocks/dev-env-ubuntu）简化构建环境，避免复杂的本地环境配置。具体步骤包括：拉取对应版本的 Docker 镜像，克隆 StarRocks 仓库并手动合并修复代码到分支，将宿主机源码目录挂载到容器中运行构建脚本（build.sh）生成前端（FE）和后端（BE）的产物。构建完成后，推荐使用更稳妥的方式替换镜像：以官方 FE 镜像为基础，仅替换新生成的 starrocks-fe.jar 文件来构建修复版本的 Docker 镜像，从而确保运行时的兼容性和最小化镜像修改。整个过程依赖官方文档和 GitHub 资源，适用于需要紧急部署定制修复版本的运维和开发场景。

我的 CodeReview 实战经验

背景

Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。

我个人觉得再忙的团队 Code Review 还是很有必要的（甚至可以事后再 Review），好处很多：

• 跳出个人开发的思维误区，更容易发现问题
• 增进团队交流，提高整体的技术氛围
• 团队水平检测器，不管是审核者还是被审核的，review 几次后大概就知道是什么水平了

通常 Code Review 有两种场景，一种是公司内部，还有就是开源社区。

开源社区

先说开源社区，最近也在做 cim 项目里做 Review，同时也在 Pulsar、OpenTelemetry、StarRocks 这些项目里做过 Reviewer。

以下是一些我参与 Code Review 的一些经验：

先提 issue

在提交 PR 进行 Code Review 之前最好先提交一个 issue 和社区讨论下，你的这个改动社区是否接受。

我见过一些事前没有提前沟通，然后提交了一个很复杂的 PR，会导致维护者很难 Review，同时也会打击参与者的积极性。

所以强烈建议一些复杂的修改一定先要提前和社区沟通，除非这是一些十拿九稳的问题。

个人 CI

一些大型项目往往都有完善的 CI 流程来保证代码质量，通常都有以下的校验：

• 各种测试流程（单元测试、集成测试）
• 代码 Code Style 检测
• 安全、依赖检测等

如果一个 PR 连 CI 都没跑过，其实也没有提前 Review 的必要了，所以在提 PR 之前都建议先在自己的 repo 里将主要的 CI 都跑过再提交 PR。

这个在 Pulsar 的官方贡献流程里也有单独提到。

同时在 PR 模板里也有提到，建议先在自己的 fork 的 repo 里完成 CI 之后再提交到 upstream。

这个其实也很简单，我们只要给自己的 repo 提交一个 PR，然后在 repo 设置中开启 Action，之后就会触发 CI 了。

如果自己的 PR 还需要频繁的提交修改，那建议可以先修改为 draft，这样可以提醒维护者稍后再做 Review。

同时也不建议提交一个过大的 PR，尽量控制在 500 行改动以内，这样才方便 Review。

Review 代码

Github 有提供代码对比页面，但也只是简单的代码高亮，没法像 IDE 这样提供函数跳转等功能。

所以对于 Reviewer 来说，最好是在本地 IDE 中添加 PR 的 repo，这样就可以直接切换到 PR 的分支，然后再本地跟代码，也更好调试。

有相关的修改建议可以直接在 github 页面上进行评论，这样两者结合起来 Review，效率会更高。

Review 代码其实不比写代码轻松，所以对免费帮你做 Review 的要多保持一些瑞思拜。

AI Review

现在 Github 已经支持 copilot 自动 Review 了，它可以帮我们总结变更，同时对一些参加的错误提供修改建议。

使用它还是可以帮我们省不少事情，推荐开启。

企业内部

在企业内部做 Code Review 流程上要简单许多，毕竟沟通成本要低一些，往往都是达成一致之后才会开始开发，所以重点就是 Review 的过程了。

既然是在公司内部，那就要发挥线下沟通的优势了；当然在开始前还是建议在内部的代码工具里比如说 gitlab 中提交一个 MR，先让参会人员都提前看看大概修改了哪些内容，最好是提前在 gitlab 中评论，带着问题开会讨论。

实际 Review 过程应该尽量关注业务逻辑与设计，而不是代码风格、格式等细枝末节的问题。

提出修改意见的时候也要对事不对人，我见过好几次在 Review 现场吵起来的场景，就是代入了一些主观情绪，被 Review 的觉得自己能力被质疑，从而产生了一些冲突。

Code Review 做得好的话整个团队都会一起进步，对个人来说参与一些优质开源项目的 Code Review 也会学到很多东西。

StarRocks 物化视图创建与刷新全流程解析

本文详细解析了StarRocks物化视图从创建到刷新的完整技术流程。在创建阶段，系统首先对SQL语句进行语义分析与校验，随后通过本地元数据服务完成一系列核心操作，包括验证数据库与视图的存在性、初始化列定义与刷新策略（如异步定时刷新）、根据存算一体或分离架构创建对象、处理分区映射逻辑，以及将关键数据序列化至元数据中以支持重启恢复。元数据通过FE集群的checkpoint机制定期快照，确保一致性。创建完成后，刷新流程会立即触发，其核心步骤在于同步物化视图与基础表的分区状态。对于常见的Range分区，系统通过特定分区器计算分区差异，并执行删除旧分区与添加新分区的操作，以确保物化视图的数据范围与基础表保持一致，随后基于此差异计算并执行具体的数据刷新任务。整个流程紧密围绕分区管理和元数据持久化展开，是理解StarRocks物化视图机制的关键。