徹言 (@iamcheyan)

蹬了一个月20刀的 Ollama Pro 和5刀（次月10刀） OpenCode Go 这两个穷鬼套餐，说说我的体验。 如果你的主要需求是 GLM 5.2 这种重型模型，推荐 Ollama Pro。 如果平时主要跑 DeepThink V4 Flash 这种快速模型，推荐 OpenCode Go。 因为在 OpenCode Go 下面跑 GLM 5.2，周额度掉得非常快。基本每执行一次，都能明显看到额度进度条往上涨。我自己的使用频率，大概一周的额度只能支撑 5 次左右比较重的任务。 并且，OpenCode Go 的月额度大约相当于两个周额度。我上次把一整周的额度打满之后，月额度就已经只剩下一半了。所以如果高强度使用 GLM 5.2，很快就会把整个月的额度全部耗尽。 Ollama Pro 相对就慷慨很多。它同样按周计算额度，但没有月额度这一层限制，所以整体用起来更从容。如果连续高强度跑 GLM 5.2，我体感大概能连续跑三天左右，才会把这一周的额度耗完。 不过，情况到了 DeepThink V4 Flash 就完全反过来了。 OpenCode Go 对 Flash 的缓存命中率非常高，很多请求几乎不会消耗额度。连续用一整天，进度条可能也只涨一点点。按这个速度，我甚至觉得一个月的额度都很难跑完。 反而 Ollama Pro 不一样。即使跑的是 Flash，每执行一次任务，都能明显看到额度往上涨一点，消耗会稳定得多。 结论： 重度 GLM 5.2 用户：选 Ollama Pro。 日常以 Flash 模型为主：选 OpenCode Go，更划算。

我的工作叫服务器保守，对应国内应该就是运维。 面试的时候岗位要求写 Linux、Shell、AWS，我想着日语虽然差点，但哥们技术没问题啊。 结果工作后才发现，这活跟技术就没关系。 国内很多互联网服务都是云原生、24 小时在线服务，而日本很多传统企业，尤其是金融行业，核心系统至今仍然依赖夜间批处理（夜間バッチ処理）。 白天业务运行，傍晚数据冻结，服务器里的JP1、A-AUTO 调度器开始启动，上千个 BAT、KSH、Shell、COBOL 等脚本按照依赖关系一个接一个执行。 有的负责传文件，有的负责清洗数据，有的负责计算，有的负责生成报表，再把结果传给下一台服务器。就是这些只有几 KB 的小脚本，几十年来支撑着整个系统每天运转。 很多人抱怨日本有些网站一下班就维护、暂停服务，就是因为后台开始跑批处理了。 这些祖传脚本很多已经运行了四五十年了，从来没有重构过。没人敢改，也没人敢删，甚至很多脚本的作者可能早就退休了。 反正小车不倒只管跑，能用就行。 那按理说，这么重要的系统应该有设计文档吧。 但脚本的大部分知识都写在 Excel 里。 输入什么文件、输出到哪里、参数是什么、依赖哪个脚本、日志在哪，全靠一个个表格来维护。 而这些表格写得极其复杂，能有几十个列，维护起来特别麻烦。 经常出现的问题是，状态不同步： 代码改了，Excel 没改；路径变了，Excel 没改；文件名改了，Excel 还是旧的……直接照着 Excel 去配置反而会出错，因为记录的信息本身就是错的。 我甚至怀疑这东西像样的版本管理都没有。 最近我们在做服务器迁移。 先根据 Excel 找文件（输入的输出的日志的），复制到新环境，运行脚本，看哪里报错；再顺着代码和日志去找真正需要的输入文件；跑通以后，再把正确的信息反过来补回 Excel。 就靠这样蚂蚁搬家的方法，去一个一个测试那数千个脚本。 代码肯定是不能改的，毕竟祖传代码，改个注释都得开会讨论好几天，能做的就是把它跑起来。 跑起来之后，把成功运行的截图，产生的文件散落，在各个地方的日志复制出来，能存到表格里的就存在表格里，不能存到表格里的，就放在一个共享磁盘里面存档。 等待下一次服务器迁移时，另外一个人一边抱怨着写的什么玩意儿，一边继续在表格里屎上雕花。

去年年底Google不是搞活动么，AI pro家庭组拼车，我记得当时宣传的是各账号额度不共享，然后我就和朋友一起开了个团。 最近朋友说觉得Antigravity经常限额，没怎么用就满了。 研究半天没明白是为啥。 刚刚下载了一个Google的账号切换工具，把他的账号添加进去一看，才发现了秘密： 原来，现在政策变了，只要一个账号进行了消耗，则另外一个账号的额度会跟着减少。Google AI pro家庭组的Antigravity额度由不共享，变成了全组成员共享。 查了一下，有许多人反馈这个问题了。 好像是从6月份开始的。 嗯，Google你玩不起啊。