🎵 推荐边听边读：Moonlit Sailor – *Dollar Underwater*

Moonlit Sailor 是一支来自瑞典的四人后摇乐队，隶属于 Deep Elm Records 厂牌，与传统后摇的沉闷压抑截然不同–旋律干净利落，画面感很强，风格清新明亮。

*Dollar Underwater* 收录于他们 2014 年的第四张专辑《We Come From Exploding Stars》。这首曲子曾在电影《百元之恋》中被用作背景乐–先安静铺垫，然后在平淡中积蓄力量，最后一下子爆发释放出来。

乐队的成员贝斯手 Rundlöf 也说：「我们的作品总会为听众带来希望和光。」

这两周，我让 OpenClaw 帮我做了三个小项目。全部都是通过飞书发指令，让 OpenClaw 调大模型来搞定的。

一、做了哪三个项目

第一个项目是给 Seedance WebUI 加功能。接了 OSS 云存储，素材和作品可以存到云上统一管理；加了提示词模板库，把常用场景的 prompt 沉淀下来；还有一些交互体验的优化。这个项目是之前 OpenClaw 帮我从零搭起来的，现在算是持续迭代。

第二个项目是日历笔记。今年四月份，我用 OpenClaw 的前身写过一版，当时用 Minimax 和 MiMo 做后端，效果不理想，就一直没真正用起来。上周一晚上重新写了一版，发现改进很大–现在基本上可以直接用了。

第三个项目是火山 Coding Plan 的模型请求次数看板。火山方舟后台只显示使用百分比，不告诉你具体请求了多少次、每次消耗多少。对我来说一直是个黑盒，那就自己动手解决。

做这三个项目就是满足自己的需求，不过做下来确实对大模型和 AI 有了更深的理解。

二、怎么做的

用什么软件框架、什么语言、怎么部署、前后端怎么分工、架构怎么设计、文件怎么命名……这一系列事情，全部交给 AI 来决定。

甚至包括后续的版本规划–做多少个版本、每个版本实现哪些功能–都是 AI 帮我梳理的。

我基本上只需要做两件事：

• 提出需求

• 对每个版本的结果提修改意见

当然，最终代码里有没有 Bug、有没有安全漏洞，现在确实没精力去逐行研究，完全是靠 AI 在做。后续也可以考虑用 Skill 调用安全插件和检测工具，叠加其他大模型来交叉检查。

三、用下来的感受

1. 模型也有”性格”

比如下面这两张图，能猜到我用了哪个模型吗？后面再揭晓。

2. 模型迭代是真的快

两三个月前我用 MiMo 也写了一版，当时效果还不太行。没想到这次用 MiMo 2.5 Pro 就写得很不错。后面尝试换其他模型来继续这个任务–修复 Bug、生成 Windows 安装包等等。有的模型在处理时没搞定，就是上面那张图的模型。切换到 GLM 之后，处理效率就很高，几轮对话就修完了 Bug，打包 Windows 安装包时遇到的报错也找到了具体的解决办法。

同一个任务，同一个 Prompt，不同模型的表现天差地别。这说明在 AI 编程这件事上，选模型比写 Prompt 更重要。

3. 飞书比 TUI 更适合日常任务

一个多月前，我挺喜欢在 TUI 下发送指令。但这一个月，我基本上都是通过飞书来和我的 Agent Jarvis 对话，上面说的三个项目全是这么完成的。

飞书消息的可读性还不错，这点比微信强。而且通过飞书，我几乎随时随地可以查看任务执行情况，特别方便。

TUI 更适合跑一些系统配置类的任务，比如查看知识图谱的构建情况、更改配置文件等等。

4. OpenClaw 不太适合做复杂项目

不管是 IM 还是 TUI，展示深度思考过程之后的可读性不强。OpenClaw 里面的Agent比较适合查看结论性的信息。

比如在配置 Kimi 2.7 Code 这样的模型时，会强制显示思考过程，但这个过程的展示对我修正代码几乎没有帮助。网上有人说用 Kimi 自家的 Kimi Code + Kimi 2.7 比较好用，但结合 OpenClaw 来使用，确实效果不好。

复杂项目需要工程师不断调整，甚至需要手工去改代码，也需要工程师有基本的代码知识，知道该指导大模型往哪个方向调整。而 IM 上一问一答式的修正和交互，效率会变得很差。

当然，目前阶段它还是比较适合我来写一些小的工具。这也符合 OpenClaw 的定位–它不是一个 IDE，而是一个 Agent 总控台。

5. 国内大模型排名

最近执行这几个任务，几乎把国内所有大模型都用了一遍。按照我的使用体验（综合性价比来看），从强到弱排序：

GLM 5.2

MiMo 2.5 Pro

DeepSeek V4 Flash

Kimi 2.6

Seed-Code

Kimi 2.7-Code

Minimax 2.7

Seed-Lite

后面再体验一下 DeepSeek V4 Pro，听说模型能力很强。当然还有这两天刚发布的Kimi K3模型，有机会再尝试下。

个人觉得 GLM 是目前最好用的模型–虽然也需要多轮对话才能完成任务，但起码能真正听懂我的需求，说明上下文信息都真正用来做推理了。偶尔也会像人一样犯错，比如大小写就分不清。

6. 上下文百万？实际用不到

虽然主流模型都标称支持百万上下文长度，但实际使用中基本用不到那么长，可用上下文甚至只有四分之一，大约 256K 左右。

有两个感受：

• 在 256K 以上的推理中，模型会开始丢失重要信息，导致推理质量下降

• 推理成本很高，在 128K 到 256K 的区间，上下文推理成本翻了好几倍，而且 200K 左右的推理很容易被模型服务商限流

OpenClaw 里还会出现一种情况：不产生回复，但模型后台也消耗了额度。主要原因是模型其实已经做了几次推理，但最终回复时需要再执行一次推理，那次推理可能被限流了，无法完成一次完整的回复。一旦发生限流，只能 Compact 会话，把上下文压缩到几 K，这样立马可以恢复使用。这也间接说明长上下文的资源消耗巨大。

实际上这张图里的上下文连 200K 都不到，就已经触发超时了。说明百万上下文在实际使用中要打很大的折扣。

四、顺便试了试 Codex

这段时间除了用 OpenClaw 做这三个项目，我还用了一下 Codex。

尝试用 Codex 去制作 Moonlit Sailor 的《Dollar Underwater》鼓谱，以及制定西双版纳的旅行计划。鼓谱调了很多轮，慢慢靠近了原版，但还不够准确–说明最好的模型在音频识别方面也存在弱点。

旅行计划方面，我让它生成了一份 PDF，包含景点信息和位置等。一开始图片里有很多重复的地方，不过经过几次调整就完全修复了，之后再调整旅行内容，也不会影响整个 PDF 的格式。

Codex 的体验比 OpenClaw 友好很多–有思维链执行过程，也有生成的最终回复，交互体验感很好。而且 ChatGPT 就像一个理性的工科生，任务执行不带情绪。后面会花点时间深度用一下 Codex，尝试让它深度做两个项目。

五、揭晓答案

一开始说的那个模型–是 Seed-2.0。

这不就是网上短视频里面的段子豆包嘛。

*作者：Kun｜一个AI Cloud从业者*