吃 WorkBuddy 的 Hy3 自助餐这么久也渐渐感觉到 Hy3 的自助餐开始收口了，每天都是用大概2个小时 WorkBuddy 就把自助餐封禁很久，模型选择界面那里也出现了一个 0.05× 倍率的 Hy3 也是一个铁证。AtomCode 这边的限时免费也暂停了开放。在 WorkBuddy 积分存粮也给 DeepSeek V4 Flash 吃了 2/3 以后，我像游牧民族一样开始踏上“逐水草”的旅程，四处寻找其他的免费资源。在寻找与等待的间隙，也是时候静下来花更多时间写日志，总结这段时间的开发经验了。成为 nomad 后的第一篇日志，便是总结我所用过的模型。

这个项目是从 AtomCode 限时免费开始起的头，DeepSeek V4 Flash 是“开国元老”，也是后续所有模型对比的基准。从项目开始时 WorkBuddy 上各模型的倍率来说，这个模型算是诸多模型中既便宜又能打的模型了。除了在本项目建立上立下汗马功劳，我还用它分析了分析了一些老游戏的架构，发现它也能读懂二进制内容，帮我定位、提取到其中的诸多资源，相当有黑客精神。

从 Hy3 开启自助餐模式后，就开始使用 Hy3 了，当时想法很纯粹，Hy3 的倍率比 DeepSeek V4 Flash 高，表现应该不比 DeepSeek V4 Flash 差，再加上原生的视觉功能，在需要视觉修正的任务上应该会比 DeepSeek V4 Flash 好。但是实践下来发现有视觉未必有充分调动视觉的主动性——在做“分子机甲” feature 试验的时候，它仅仅满足于一张正面截图所看到的结果，没有从多个角度去审视它的作品，于是我得到的是纸片“机甲”——它用2D的东西去仿造3D，从不去看侧面。即使最终我强制它换成了 Three.js 进行绘制，我也还是发现了具视觉的 AI 的第二个局限性——视觉有了，但是美感没有与人类对齐——“机甲”风格对它来说是很抽象的，它的美感停留在碰撞体（Collider）阶段——身体？用个药丸形状表示就行，什么所谓的完美“身材”一概不懂。如果模型的视觉止步于此，那么它很难体现出视觉的优越性——这样的模型只能修正那些通过文字描述也能指出的视觉错误，但是无法完成具备视觉后“美感”这一重大课题。在调动视觉的主动性上，DeepSeek V4 Flash 也许更胜一筹，自从它具备像素扫描后，在找图或者配色任务中它会调用自己的这一能力去检查一张图片，即使你没有明确叫它这样做——在那次的任务中这种“视觉”是我很想 ban 的能力，是它的 cheat sheet，会干扰它从源码中帮我寻找到答案的过程。似乎它还具备了对颜色的感知，对于“肉色”它知道大概的颜色范围，它能对你说某两种颜色值混合后调配出的就是“肉色”。从广义的“主动性”来讲，DeepSeek V4 Flash 确实一骑绝尘——使用像素扫描、解码二进制字节——其他有视觉能力的模型碰到视觉任务，会把自己的视觉像内衣一般藏着掖着，需要使用者主动调用才不情不愿睁开“看一眼”；而遇到需要解读二进制文件的任务，其他模型早就讳莫如深了。还有，DeepSeek V4 Flash 有时候会执着于自己的技术路线——当你抱怨 SWF 素材使用 Ruffle 显示太小，放大后又缩在左上角看不全时，DeepSeek 老兄一直尝试帮你调位置，当你透露出想放弃的念头，问它还要不要坚持的时候，它斩钉截铁地说“我还要试！”它骨子里自然而然透露出这么一种不服输、敢解剖的黑客精神。

第三个要说到的模型就是 Agnes 2.5 Flash 了，自从 Hy3 的自助餐开始收口后，它开始承担副手的角色，接力完成 Hy3 未竟的事业。虽然 Agnes 也会有使用一段时间后被限制的情况，但解禁时间没有 Hy3 那么长。总的来说虽然它并不像 DeepSeek V4 Flash 那样 aggresive，但它的毅力比 Hy3 稍强，分析到一半就草草掐断的情况出现得比 Hy3 少。

第四个模型是 DuMate 的“文心”模型？也许是所有模型当中最克制节俭的一个了，每天500积分，但是看账单很少有超过10个积分的条目，当然账单粒度很细，每分钟甚至同一分钟的账单都有，可能与调用有关；而且积分只能应用内消费，只能在店飞书遥控。基于所说的种种限制，积分积累反而是最多的。

使用 Vibe Coding 开发大模型这么久，最终对 token 的消耗也有了一定的体会，如今再看那些所谓的“1000万 token”，我会默默换算成“10M token”，然后感慨：“就这？”——一次简单的 bug 排查，也许就会轻松烧掉100万 token，就本项目开发这么久来说，1000万 token 只够塞牙缝了，不到一小时就能烧完。Tokenmaxxing！

也许有人会问，使用这么多这么杂的模型开发一个项目，一个新的模型也许都没能完全理解这个项目，“半路出家”不怕“各显神通”最终堆出累累屎山代码和技术债吗？我也曾问过自己这个问题，但我给出了自己的经验判断：一个模型，只要认真读一部分源码，只要源码遵循了良好的编程实践，那么这些实践会反过来规范后来的模型写出符合规范的代码。所以，作为指挥模型进行编程的工程师，自己一定要时不时审一下模型生成的代码，细节可以不去细究，但要能鉴别出一个系统的大问题，舍得亲自坐镇让模型早期去修正、重构，不要让模型去过早收敛，不要让它选择一个拆东墙补西墙的局部最优解，才能保证后续写出的代码是规范的。屎山代码的积累，很多时候源自审核的懒惰，完全放手让模型发挥——审核者对重构都不上心，在代码中没有树立模范，又怎能促使模型走心呢？在被我规训几次以后，模型也会懂得反复思考、提及和遵守我说的“零策展”原则。历朝历代亡国的君主，他们手下不是缺乏治国的能臣；发愤图强的君主，哪怕只是多上几次朝，多批几本奏折，多听几句刺耳的话，多亲自诘问几个问题、拍板几个决定、选拔几个能人、采纳几个听起来有用的意见，也许都能迎来一次“中兴”，其中的道理是相通的。对这些有充分认识的人，才能做到兵没了再招，手中始终握有“旌旗十万斩阎罗”。