徹言 (@iamcheyan)

因为在日本，软件不是一个独立的行业。 而是依附于大型机、计算机、工业设备、消费电子、游戏机以及大型企业系统而存在的。 大致有两条路线。 一条是企业系统：银行、保险、电力、制造业需要系统，但没有开发能力，就交给富士通、日立、NEC这样的厂商。 客户提出需求，厂商定制开发，部署以后继续维护十年、二十年。 这套模式重要的是「长期客户关系和稳定交付」。 简单来讲就是：别出错，别给大家惹麻烦。 另一条是软硬一体。 索尼、任天堂等企业自己有硬件，所以需要操作系统、驱动、游戏、嵌入式软件和各种配套软件。 你想玩我的游戏（使用我的服务），你就需要买我的设备。 日本过去这两条路线都非常强。 相对缺少的是第三种： 在互联网时代，软件本身就是产品。 不依附某个客户，也不依附自己生产的硬件，直接做一套标准化的软件或服务，卖给所有人。 Microsoft、Oracle，后来 Google、Salesforce、AWS，走的都是这条路： 软脱离具体硬件和具体客户，标准化以后复制给全世界，而软件公司本身成为产业中心。 但为什么日本没有呢？ 因为日本在前两条路线的基础之上，形成了一个特色现象： 业务知识在甲方，软件知识在乙方。 最懂银行的人不会写软件。 写软件的人又不知道发金融系统为什么要这样运转。 中间再隔着层层分包。 最后真正写代码的人甚至见不到真正用系统的人。 而在这种产业结构下，企业真正需要的也未必是特别喜欢计算机的人。 需要的是懂客户、懂业务、会写设计书、会协调、能按照仕様把项目交付的人。 对技术钻研的反而不重要。 所以日本 IT 里存在着相当一批很有意思的人： 学历很高，脑子也很好，工作认真负责，甚至已经在这个行业干了十几年，但入行之前可能几乎没有接触过计算机，对计算机本身也谈不上有什么兴趣。 之前学的是文学、法学、经济、环境，甚至音乐。 找工作的时候，没找到满意的工作，就去干IT。 企业也愿意从零开始培养。 用什么就教什么，这个不会就去干那个，那个不会就去干这个，反正总有能干的事儿。 于是一个程序员完全可能写了很多年代码，却从来却从来没用过 Git； 版本管理，就是复制出一排文件夹 bak20260903_1、bak20260903_2、bak20260903_2_fix。 而这个人（甚至整个团队）都不觉得有什么奇怪。 但这换一个行业就会显得非常荒诞。 一个东京大学法学部的高材生，学历很高、脑子很好、工作也很认真。 但他能不能培训几个月以后就去本田设计发动机？ 大概率不行。 因为机械、电气这些传统工程领域，专业能力边界非常清楚，你不会就是不会。 否则硬件轻了出事故，重了要出人命的。 软件不一样啊。 今天写下的一段烂代码，能跑、测试能过、项目能验收。 毕竟验收的人又不懂（可能写代码的人也是不知道从哪复制粘贴的）。 但时间一长就会变成一坨屎山。 而维护他的人又完全不在乎。 这就能解释很多日本 IT 里看起来互不相关的现象。 几十年前的祖传 COBOL 继续修修补补。 系统之间继续全传 CSV。 关键业务最后长成一个巨大的、谁都不敢动的 xlsm 文件。 各种结算系统一到到某个时间段，就停止服务，开始批量运行夜間バッチ。 乐天商家后台还要靠写 HTML 标签去维护内容。 各种票务网站，同时几个人一起打开，就会提示限制访问。 所以日本缺的可能从来都不是会写代码的人。 毕竟往后写代码也越来越不值钱了。 它缺的是一个真正把技术能力本身当作价值、让工程师对软件本身负责的产业结构。 因为如果软件永远只是业务的附属品，那么技术永远只需要做到「够用不出错」就行了。 而互联网（乃至未来的AI时代）真正改变的，恰恰是这一点： 软件不再只是用来支撑其它业务的东西。 软件本身就可以是赚钱的业务。

我们是不允许用 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你玩不起啊。