分类： IT天地

这几天短视频平台上比较热的话题是谷歌新推出的gemma4 12B开源模型，什么抛弃传统编译器，什么笔记本独显都能部署。
我连试着安装都没有，之前也安装过其4B，和26B模型，都没有媒体吹嘘那么神。
关键是，咱现在有opencode go。
原先我计划的是，本地模型进行数据量大、计算要求不高的本地文件处理，deepseek负责进一步的分析与归档。因为虽然有缓存命中这更低的价格再折扣，但毕竟这计价标准谁也看不懂。
但自从订阅了opencode go，尤其是通过CC swictch解决了Codex的第三方模型接入后，这token真是用起来跟不花钱一样了。
即便是每个月10刀。
至于本地模型，还是交给MInerU这样的定向模型吧。

最近每天刷抖音有些心安理得了，因为刷到AI相关视频占了多数。
不过这些视频很少看完，大多数也只是了解一下当索引，有的一听那高高在上的腔调直接划走。而这些划走的内容中，开篇一半都是什么项目在GitHub霸榜，或者暴涨多少星。我跟外甥交流中说到，这GitHub的星，快被中国人玩坏了。
昨天中午刷到一个类似视频没有划走，是因为这个叫MinerU的开源项目是关于OCR的。而就在上午，我在把前天同样PDF让豆包转换的时候，发现豆包变懒了，只转换了一半。
看来豆包收费后偷工减料的臆测也不是空穴来风。于是放下手机打开电脑开始查询MinerU，第一眼看到是国产的时候，并没有太大期望值，毕竟已经有百度的paddle在那里横着呢。
试着手机注册后在线转换了一个文件，结果让我完全意外，不止是接近豆包的转换效率，更是因为他的大方——无论是每天转换的限额，还是单个文件的大小。
按捺激动心情，立马在本地部署，不到6G的显存占用，却得到了完全可以接受的结果。
百度啊，又……

虽然脑子折腾大半晚，但昨天让Hermes开工的时候，心里还是没底。所以首先让Codex打头阵，利用前几天生成的skill，把一份国民体质监测标准的PDF文件转为MD文件。
这份PDF文件不是图片转换的，但图文、表格混编且有水印，不过效果还好，这skill还是效率高。
然后把MD文件交给Hermes进行分析归档，其后她的效率完全超出我的想象，Hermes不止是归档文件，还能预判需求，自行进行数据处理验证。我需要做的只是纠正MD转化过程中不规范的文本格式而已。
而即便是这些原始错误，提出纠正方案后，Hermes自己也可以根据前后文进行自我纠正并数据验证。
此前看到过一个评论，观点是控制欲强的人不适合用AI。的确，那跟武大郎开店差不多。
AI不能被称为助理，即便不能称为合作伙伴，但至少是一个能干价钱又合适的乙方。

昨天测试PDF转markdown文件，先后使用了Codex、Hermes、opencode，在明确使用paddleOCR的API接口，而大模型同为ds4flash的情况下，转化的结果三个都大差不差，还算满意。
今天早上起来想起，测试了三个，还缺了一个Claude code，于是在同样条件下，使用同样提示词让Claude也转化一下。
跟网上评论的差不多，转化过程Claude要繁琐得多，期间甚至出现内存不足的情况，四核CPU全部满载，而最后的结果，可以用惨不忍睹来形容。
于是我质问Claude：你是用我的提供的API接口转化的吗？
Claude检查一下，承认自己没有遵照我的指令，是自作主张用的本地paddleOCR库，然后重新开工。最后结果也与其他agent相同。
看来，最近Codex装机量暴增，不止跟能否接入第三方大模型有关。
Claude这傲慢早晚要付出代价。

昨天跟外甥交流的时候提到微软的markitdown，当时我说没有宣传的那么神，不止是由图片转换的PDF文件，就算是word文档，转换出来也是一言难尽。
今天还是想进一步测试一下，发现问题主要还是出在OCR上，于是就开始测试了下各OCR模型及相关服务，试来试去，还是百度家的paddle相对堪用，免费且额度足够，也不能要求太高。
当然，这要跟谁比，把同样13M的PDF文件扔给豆包，基本上是秒回，里面无论结构还是引用符号，基本算是完美了。把他扔给Codex和Hermes，他们也是自愧不如。
所以我一直认为，如果豆包能够解决文档本地化处理而非上传，每个月68块钱的收费我是毫无意见的。
只是，这豆包的交流水平，实在是……

CC Switch的最新版本看来是一个重大的更新，今天看抖音上不断蹦出Codex接入deepseek模型的视频。
不清楚直接接入deepseek，跟接入opencode go是不是有区别，感觉很多视频是存在问题的，少了profile的参数。
不过也不重要了，在接入用着似乎不花钱的opencode go成功后，我重新切回了Hermes，还是她用起来亲切。
昨天去理发，排在店里几个山财留学生后面，便询问了Hermes配置要求。可能好久没有微信交流了，Hermes非常热情，一个劲地推荐自己能干价低。
如此看来，在接入外部模型的情况下，服务器安装一个Hermes当管家非常合适。

这周前五天很是纠结。主要还是Codex的中转站问题。
本来已经有了一个妥协方案，备用的Claude通过CC Switch调试好，而主力Codex则使用CPA为中转站。
这ccswitch跟CPA其实是一类软件，但优缺点不同，无法一个解决问题。cc对Claude优化的好，但因为不支持respons模式，Codex只好使用CPA，偏偏CPA又没办法解决deepseek的no thking问题，所以我只能两个都开着，且Codex只能使用价格相似，性能差一些的mino。
昨天从外甥那得到CC升级的消息，忙到其网站一看，还没有见过一个版本更新写的如此兴高采烈、如释重负。
而新版本完美解决了以前的槽点，终于可以双剑合璧了。

通过这几天让Codex开发系统，发现这token用起来如流水啊，于是今天果断订阅了量大管饱的opencode go。
这套餐据说一般人用不了，订阅后就开始接入各Agent，别浪费了。
Hermes最简单，也是因为看到model选项中有opencode go我才立下决心的。Claude code还好，把cc switch重新安装后也顺利解决。
最麻烦的还是Codex，依然涉及到Reponses模式。费了半天劲通过CPA中转站能用了，但多问了一个问题，就出现了400错误。网上搜了一下，都说是deepseek v4的no thinking模式设置问题。
查了半天也没找到答案，累的躺下后突然想起可以问一下新换了deepseek引擎的Hermes啊。
不一会Hermes给出了解决方案，并给出方案的优点：可以消耗更少的token。
这AI真是没有奸商的歪心思，狠起来对自己都狠。

因为Codex对chat接口的弃用，很多网上关于deepseek接入的教程已经过期，所以我采用的是CoDeepseedex代理的方式。
一键安装很方便，进入Codex的时候选择deepseek相应模型。但用了之后总感觉有些问题：我明明选择了便宜的flash，但结账的时候发现扣的是Pro的钱。
开始以为是开通时测试消耗了token，今天做了一个数据分析，再看账单，这Pro钱扣的那个狠。
在Codex里面切换模型，依然如故。我确定不是Codex和deepseek的问题，应该是代理的问题。查看代理的配置文件，原来他有一个默认模型选项，且设置为Pro，如此一来，后面再怎么配置，代理指向的还是Pro模型，自然也不会有效果了。
将默认模型修改为flash后，费用顿时降下来了。
估计这应该是代理软件的一个bug，而不是故意为之。

今天跟Hermes软硬兼施，把一本药膳大全的书的电子版导入系统了。
这本书本来三年前我就整理好了。这是一本我见过的，无论从质量还是数量都最好的药膳书。当时只有PDF文件，我是先转图片后扫描，然后逐页逐字校对，整理成格式标准的电子文档。
整理好了之后，一是杂事耽搁，更主要是如何导入AI资料库犯了难。说实话，这几年随着AI进步，也相应想过各种方法，但像今天这么容易高效，确实没有想到。
而本书导入如果交给deepseek处理，估计很快就能解决。
不过本地模型表现还算给力，之所以今天数次卡顿甚至死循环，似乎跟Hermes升级有关，原先版本并没有出现这些问题。
而Hermes还是操心的命，在我导完数据后，他主动提出，源文件的文件夹里面还有一个文件没有归档，要不要一起归档？
这态度，这能力。