以前我在 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。怎么说呢，这次谷歌真正改的，不只是模型大小，而是连“你该怎么理解这批模型”都一起改了。
刚开始用 Codex 的时候，我对 medium 这个默认档位有点误会。
它看起来像一个很稳的中间值：不至于太慢，也不至于太省。网上又经常有人说 GPT-5.4 编码很强，于是很容易顺手把两件事合在一起理解：既然模型强，那默认 medium 应该就够了。
用了一段时间以后，我的结论变了。小修小补可以继续 medium，但只要任务开始跨文件、需求有歧义、需要先读代码再判断，我更愿意直接开 high。xhigh 不当日常默认，留给 high 已经证明啃不动的任务。
翻了一圈现在仓库里的配置，我反而更确定一件事：这套东西最后拼的不是单个模型有多强，而是每一层到底该让谁来承担成本。
最明显的一个信号就是，当前生效的 published.runtime.json 还是 2026 年 4 月 2 日生成的 minimax-m2，但 2026 年 4 月 3 日 16:38 的 5f17088 已经把 blog-style-suite 的默认 provider 切到了本地 LM Studio 里的 gemma-4-26b-a4b。这看起来像前后不一致，其实不是，它恰好说明了这条流水线开始有了分工。
如果 token 足够，最省脑子的办法其实很粗暴：把历史文章直接塞给模型，让它自己学。
问题在于，这种办法只适合偶尔来一篇，不适合反复写。你要是真把博客写作当成长期工作流来做，生吃历史文章这条路，很快就会从“简单直接”变成“又贵又乱”。