以前我在 VS Code 里调 C++，配置基本就停在 launch.json，最多再加一句 GDB。

把 program 填好，把 gdb 填好，把断点打好。然后呢？然后每次调试前，自己去终端里 cmake --build 一下。

更烦的是，自定义的价格、合约、订单类型断下来以后，VS Code 调试窗口经常只能看到一堆内部字段。数据是对的，但是不说人话。

这事离谱的地方在于，我以前看过的一些教程也差不多就写到 launch.json 为止。直到最近让 AI 配一个新项目，它顺手加了 preLaunchTask 和 gdb_printers.py，我才反应过来：VS Code 调 C++，不只是把 GDB 启起来。调试前可以自动触发 CMake 编译，断点停住以后，也可以让 GDB 加载 Python 脚本，把业务类型处理成自己看得懂的样子。

说实话，这不是什么黑科技。

但是它刚好补上了 C++ 日常调试里两块很烦的空白：启动前构建，以及断点后的变量展示。

最近写算法服务，twap、vwap 这类模块一铺开，我又把这个老问题翻出来了。

C++ 里如果还靠类名硬扛语义，名字很快就会失控。TwapOrderManager、VwapOrderManager、AlgoOrderManager 这种东西，写着写着就一股子“我知道自己结构没收住，但我先把前缀补上”的味道。说白了，按文件夹分层，再配一层 namespace，不是代码洁癖，这是在补 C++ 没有 Java 那种原生 package 体系的空位。

这次刷论坛，最让我长记性的不是哪家又发了榜单，而是一句很土的话，显存不够，参数再大也白搭。

以前我总把“模型慢”理解成算力问题。后来越看越明白，很多时候根本不是 GPU 算不动，而是数据没法待在对的地方。只要内存路径一变，token 速度就不是慢一点，是直接掉下去。

如果只看榜单，最容易心动的肯定是 31B。

但真把机器搬出来，还是那台没升级的 RTX 3060 12GB，判断马上就会变。怎么说呢，本地部署这件事，最后拼的不是谁最风光，而是谁最像能长期相处的那个。对我来说，这次真正值得先跑的，不是 31B，而是 26B A4B。

首发当天我本来想干的事很简单，找一个和 Gemma 3 对应得上的升级版，先下下来跑。

结果一圈看下来，人先有点傻眼。以前熟的 4B / 12B / 27B 那套名字没了，冒出来的是 E4B、26B A4B、31B。怎么说呢，这次谷歌真正改的，不只是模型大小，而是连“你该怎么理解这批模型”都一起改了。

平时宅在家里，2026 年清明假期难得出来走走，晃到松江大学城文汇路，第一反应其实不是风景，是店。

好特卖不稀奇，上海这些年已经铺得到处都是。让我愣了下的是，我居然在这里看到了 零食很忙。这个牌子以前在老家见得更多，我一直以为它离上海还有点距离。结果一条文汇路，先把我这点刻板印象打掉了。

我现在的判断挺明确：零食很忙 这类店能开到松江，不是因为上海突然“下沉”了，而是因为松江本来就不是很多人想象里的上海边角料。你把这里当郊区，它偏偏有足够密的人流、足够年轻的客群、足够长的停留时间；你把它当纯睡城，它背后又站着松江府的历史底子、大学城的科创资源，还有上海西南门户的新定位。

用 Codex 这段时间，有个问题一直挺别扭：默认思考档位是 medium，但网上一聊到 GPT-5.4，口气又都很猛。真到自己手里，medium、high、xhigh 到底差多少，官方也没给一张特别直白的表。

我现在的结论挺明确，日常编码我更愿意直接开 high。medium 不是不能用，快活、小修小补、试探方向没问题；但真到多文件修改、需求有歧义、还要边看代码边判断的时候，medium 很容易把算力省错地方。xhigh 我反而不会常开，留给卡壳的大活更合适。

翻了一圈现在仓库里的配置，我反而更确定一件事：这套东西最后拼的不是单个模型有多强，而是每一层到底该让谁来承担成本。

最明显的一个信号就是，当前生效的 published.runtime.json 还是 2026 年 4 月 2 日生成的 minimax-m2，但 2026 年 4 月 3 日 16:38 的 5f17088 已经把 blog-style-suite 的默认 provider 切到了本地 LM Studio 里的 gemma-4-26b-a4b。这看起来像前后不一致，其实不是，它恰好说明了这条流水线开始有了分工。