随着 AI 编程代理大量参与开发，代码审查面对的最大问题已经从“如何审查一份代码”变成了“如何在代码数量快速增长时，合理分配有限的人类注意力”。

Claude Code 团队在官方博客中分享了他们的实践：不取消代码审查，而是把大部分机械性检查交给机器，把人类时间留给架构、风险和产品方向等更需要判断力的问题。

本文是对原文的中文整理与总结，并非官方翻译。原文：How the Claude Code team does code review。

前言

MikroTik RouterOS 是一套非常强大的路由操作系统，但在日常使用中，总会遇到一些 RouterOS 原生功能不方便处理的需求：使用标准 Linux 命令排查网络、通过 SSH 执行自动化脚本、使用 curl/tcpdump/dig 诊断网络，或者运行轻量级 Python 和 Shell 工具。

RouterOS 7 提供了 Container 功能，可以在支持的硬件上运行 Linux 容器。我决定在两台 MikroTik RB5009 上分别部署 Debian 12，让路由器兼具 RouterOS 网络能力与 Linux 运维能力。

本文记录部署过程、关键配置、遇到的问题及解决方式。

背景

前面两篇记录了怎么用 iWAN 隧道 + 自建 VPS/L2TP 做跨境出口。那两篇解决的是”整条账号的所有流量走哪个出口”，但实际用下来需求更细：YouTube 这类大流量留在默认出口，Claude/ChatGPT 这类走专门的美国出口，Google 其它服务和默认出口一致——这就不是”按账号分流”能解决的了，得精确到”按域名分流”。

这篇记录这个过程踩的坑，比预想的深得多：从一个看起来人畜无害的 Fake-IP 怪现象，一路挖到 DoH 兼容性、陈年连接跟踪记录，最后还撞上了 IPv6 双栈这个完全没预料到的硬骨头。

背景

手上的 SD-WAN iWAN 客户端(sdwand)官方只给了裸机部署方式：一个二进制+ 一份配置文件，配 systemd 拉起来就行。但我想把它塞进 MikroTik RouterOS的 /container 里跑——路由器本身就是流量的枢纽，隧道建在路由器自己的容器环境里，比额外接一台旁路设备更省事。

这个想法本身没问题，sdwand 装进 Debian 容器里确实能跑起来。真正麻烦的是后面那步：怎么让局域网里其他设备的流量，经过容器里的这条隧道出网。容器有自己独立的网络命名空间，RouterOS 的主路由表根本看不到容器内部那张隧道网卡，这中间要打通的环节比想象中多得多，而且一个坑套着下一个坑，最后那个根因差点让我以为是硬件问题。

背景

手上有一条按月付费的 Panabit iWAN 隧道服务，跨境访问是没问题的，但出口 IP是服务商统一分配的默认出口，没法控制。想要的效果很简单：跨境这段继续走
已经付费的 iWAN 隧道，但最终出网的 IP 换成我自己买的那台 VPS。

看起来是个很直觉的需求，但实际折腾下来，光是搞清楚”该在哪一端加配置”就走了不少弯路，中间也踩了几个挺隐蔽的坑，记录一下。

最近给一台 2019 款 Mac Pro（MacPro7,1）安装 macOS 更新时，连续遇到了同一个严重问题：更新进行到重启阶段后无法正常完成，机身状态指示灯橙色闪烁，最后只能拔掉电源才能重新开机。系统虽然还能回到桌面，但版本没有更新成功。

这不是一次普通的下载失败。系统日志最终证明，真正失败的是 Apple T2 安全芯片内部的 BridgeOS 固件升级。通过另一台 Mac 执行一次不抹除数据的 DFU Revive 后，T2 固件成功更新，随后 macOS 也顺利完成升级。

引言：代码已经不再是瓶颈

AI已经让软件代码的生产速度发生了数量级变化，但围绕代码生产建立起来的组织流程，并没有以相同速度改变。

今天回来,要帮同学远程运维一下之前的服务器(他忘记续费了),忽然发现运维脚本执行后没反应(往常1分钟一台跑完的).

手上有两个云盘：115 网盘存了大量影视资源，123 云盘有不错的带宽和直链能力。日常需求很简单——让 媒体库的文件,可以通过 115 和 123 的通道播放和下载。

极致优化：如何将 128k 上下文的显存占用从 87GB 降至 66GB？

在上一篇博文中，我们展示了双 3090/四 3090 环境下部署 Qwen3-30B 的基础性能。今天，通过引入 OLLAMA_KV_CACHE_TYPE=q8_0，我们将这项测试推向了新的巅峰：在不损失响应速度的前提下，显存占用降低了 **24%**。