徹言 (@iamcheyan)

我们是不允许用 agent的，只能在 Office 365 企业版的网页里跟 AI 聊天。其它工具全被 ban 了，连 VS Code 侧栏里的 Copilot 都没反应。 我以为大家都是这样。 但有一天发现领导的 VS Code 居然能连 Copilot，只是特别不稳定。 我就问他哪来的，他说其实给少数人订了企业版，但这个只能读代码，不能编辑，而且经常没响应。 我发现他的 VS Code 版本特别老，插件也一直没更新，估计 API 都变了。 我就说要不更新一下试试？ 他说だめ啊，禁止安装软件。 我说这也不算安装吧，就是 update 啊，那win11不天天强制更新吗。 他说没说可以就是不可以。 好吧。 结果过了几天，他真去问了，说可以更新，于是就把 VS Code 和插件更新了。 ……然后他的 Copilot 彻底不能用了。 我靠。 之前至少还能在IDE里给看看代码，更新完直接无服务。 我都懵了。 研究半天才发现，原来 GitHub Copilot 企业版里是可以看到自己有哪些模型能用的，而他能用的新模型全被禁了，只剩一个 GPT-4。 偏偏新版插件已经没法用这个老模型了。 我说那让把新模型权限开一下不就行了吗？ 企业版订阅的钱每个月照样花，结果东西用不了，这钱不是白花了吗？ 然后他就真去申请了。 到现在还没信。 我问他为什么这么慢，他说可能觉得新东西不安全吧。 所以搞AI卖给谁啊？ 究竟谁在用。

用了一晚上，体感不太好。 可能是散热问题，也可能是工程机的缘故。也可能单纯是被 ARM 的 MacBook 惯坏了。 回到 x86 之后，随便开几个任务，就能听见风扇开始起飞，一股热风从右边出风口往外喷，马上要把手烤成猪蹄。 MacBook 就完全没有这种感觉。那台本子很少听过风扇响，有时甚至怀疑它到底有没有风扇。

最近比较闲，一边学日语，一边重新研究以前感兴趣的开源项目。 但现在已经很难静下心从头读代码了，毕竟 AI 读得比我快。 于是换了个方法：让 AI 读一个历史悠久项目的 GitHub 提交记录，再结合 release、issue、论坛讨论、RSS、新闻和当时的时间背景，整理成一部项目编年史。让它像写小说一样地，讲这个项目如何从 0 到 1 被实现出来的，没事就打开看看，老有意思了。

蹬了一个月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你玩不起啊。