我把 Mac 客户端项目丢给一只 "神秘兔子模型"：43 项 + 67 项检查全过

中秋三天假期，一晃过去了，第一天徒步摄影，第二天吃大餐然后看了《奥德赛》，晚上就开始做我的墨问 App 的 Mac 版本。不过，现在 Codex 的 Astra 模型真是太不抗用了，给 App 做个基础框架来，周额度就用了一半。正好 Vibe 群的用户告诉我，试试 OpenCode 吧，最近有个匿名神秘模型上线，现阶段免费蹬，据说性能还不错，速度堪比 DS V4.1 Flash。

赶紧去 x 上扒拉一下，还挺火的，口碑相当不错。

既然有好用的模型，那就试试吧，于是整个假日里我都在和这只“兔子 Space Bunny”协作写代码。好消息是，Space Bunny 稳稳的接住了我的研发任务，开心。

1、假期里跑来了“一只兔子”

这个神秘模型叫做 Space Bunny，大家戏称太空兔，OpenRouter 上的正式名称是 Space Bunny Alpha，9 月 23 日上线，平台标注百万 token 上下文，调用量非常离谱，很快登上了 OpenRouter 和 OpenCode 的 9 月 26 日单日 token 使用量榜首。

我是在 OpenCode 上使用这款模型的：

这一天多的时间里，我给这只兔子安排了两份工作：首先和另外两个模型做同一道编程题。如果确认模型可用，就把墨问桌面客户端的一部分工作交给它完成。前一份是例行考题，后一份要看它能不能接住真实的工程产品。

执行任务时，我只看三点：能不能一次做对，做错了能不能快速补救，以及速度够不够快。

2、出一道复杂工程题，周末咱们去哪玩

我设计了一个两日旅行规划器。项目起点是统一的 React、TypeScript 和 Vite 工程，提供 24 个虚构地点和图片，由模型完成发现页、详情页、行程编辑页，功能上支持筛选、收藏、拖拽、费用与时间联动、冲突提示、撤销和刷新恢复。

设计的难点在于：用户反复调整行程时，应用能否正确处理每一步操作。比如，把去早餐店的时间从第一天挪到第二天，原先设定的 90 分钟停留时长要原样保留；博物馆上午 10 点才开门，如果日程表安排了 9 点参观，页面必须及时提示时间冲突，一旦参观时间改回营业时段内，提示也应随之消失；误删某个地点后点击撤销，应完整恢复它原本的日期、顺序和停留时长；即使刷新页面，已收藏的地点和排好的行程也不能丢失。

我把验收拆成了 14 组，还要看桌面版与移动版布局，检查按钮能否替代拖拽等等。这道题的代码量不大，但足够检验模型执行长程任务的工程质量。

我选的三个模型是 Space Bunny、GLM 5.3 Flash 和 DeepSeek V4.1 Flash。

Space Bunny 在 OpenCode 中运行，后两者跑在 Qoder 中。三份工程、数据和提示词相同，各自开新会话。第一个版本都是一次性交付，我没有追加开发提示词，也没有改动任何代码。

先看同为 1440 × 900 的首版截图。Space Bunny 把地点筛选、收藏和两日行程编辑组织得比较清楚，费用与营业时间冲突的提示也有明确层次。同时配合统一的暖色背景和图片卡片，我们有了一个可继续打磨的旅行产品雏形。GLM 的也不错，布局紧凑，第一屏能看到更多地点；DeepSeek 的行程页则把费用、时间和冲突反馈呈现得比较直观。

Space Bunny 首版发现页

GLM 5.3 Flash 首版发现页

DeepSeek V4.1 Flash 首版发现页

把页面切换到手机尺寸后，Space Bunny 可以顺利完成从筛选地点、收藏到编排行程的流程。它为调整地点顺序和日期提供了按钮，用户可以直接点击操作，降低对拖拽落点的依赖。这说明 Space Bunny 考虑到了小屏幕上的实际操作需求。

GLM 的布局更紧凑一些，日期切换入口和按钮容易找到，不过拖拽时还需要更清楚地提示最终插入位置。DeepSeek 的顶部内容则比较多，进入行程编辑等主要操作区域需要向下多滑一段。如果进一步压缩顶部介绍和筛选区域，小屏幕上的操作效率还可以提升。

首次验收，GLM 通过 14 组，Space Bunny 和 DeepSeek 各通过 13 组。

Space Bunny 的问题出在跨天拖拽上：如果第二天还没有安排任何地点，把第一天的地点拖过去，它仍然留在第一天。但通过按钮把同一个地点改到第二天，又能正常完成。也就是说，“移动到另一天”这个功能已经有了，拖进空白行程的操作却没有处理好。

DeepSeek 的问题则出现在返回列表时：先用筛选条件找出两个地点，进入其中一个的详情页，刷新页面，再返回列表，原来的筛选条件就丢了，页面重新显示全部 24 个地点。如果中间不刷新，返回时就能保留筛选结果。

随后，我把出问题的操作步骤、应该出现的结果，以及实际发生的情况分别交回两个模型，让它们自己查原因。各自修改一轮后，bug 修复，相关功能正常运行。最终三个模型累计都通过了 14 组验收。

Space Bunny 修复后的跨天拖拽

Space Bunny 完成修复之后，早餐店可以拖到原本空白的第二天，90 分钟停留时间保留。左侧的展馆安排早于开馆时间，冲突提醒正常。

DeepSeek 修复后的筛选恢复

DeepSeek 修复后，进入详情、刷新再返回列表，原来的筛选条件和两个结果都还在。

通过这次交付来看，Space Bunny 能把多个页面和相互关联的业务功能组织起来，保持统一的界面风格，还处理了跨页收藏同步、删除撤销、刷新恢复这些容易遗漏的细节。遇到问题后，把复现步骤和预期结果告诉它，能很快排查并完成修复。这样的界面表现，加上需求落地能力，修复和迭代能力，让我愿意把真实项目交给它实现。

3、上手真实项目：墨问桌面客户端（Mac 版）

接下来，我开始让 Space Bunny 做墨问桌面客户端的功能。这个墨问 App 已经能打开多个标签页，也有墨问阅读入口、基础 PDF 显示和浏览历史等功能。

这次交给它的任务，是增加 macOS 顶部菜单栏入口，再完成PDF 文件的打开和阅读等功能，整个过程均在 OpenCode 里使用 Space Bunny 完成。

菜单栏功能，就是在 Mac 屏幕顶部放一个墨问图标，如图，点击出现下拉菜单，用户可以根据自己的需要打开主窗口、写笔记、进入 CatReader、查看消息、打开设置或退出。

这里需要考虑的是：连续点击“打开墨问 Dev”，不应该开多个窗口；关掉墨问 App 窗口后，应能从图标里重新打开 App；真正退出应用，图标也要消失。设置里还要提供显示或隐藏图标的开关。

这个功能 Space Bunny 基本是一次完成，43 项自动检查也通过了；消息入口、图标开关、关闭窗口后重新唤起，以及退出后菜单栏图标消失，都没有问题。

开发过程里，我回答了模型主动提出的两个有关产品决策的问题，模型拿到反馈后，处理速度很快，准确度也不错，基本没有返工。

PDF 功能就是为墨问和 CatReader 做一个 PDF 阅读器，还需要处理文件后缀和跳转的问题，有些 pdf 未必以 .pdf 结尾，有的链接需要跳转，有的带临时访问参数，还有的由网页即时生成等等。App 要识别这些情况，在文件打不开时给出说明。

Space Bunny 设计了 App 内的 PDF 阅读界面，实现了对不同类型附件的识别与处理。我用准备好的本地样本检查，类型校验没问题，翻页、缩放和查找也实际操作过，67 项自动检查全部通过。

这个功能也完成了。

4、这个太空兔表现得咋样呢？

把评测和真实项目放在一起看，毫无疑问，Space Bunny 可以保质保量完成实际开发工作。

做前端页面，在已有工程里新增功能，根据反馈排查和修正问题，表现都非常不错。在墨问桌面客户端的开发中，它精确地实现了菜单栏和 PDF 功能，遇到产品决策会向我提问，拿到反馈后推进执行，最终漂亮的完成了产品研发任务。这是让我愿意在实际场景里继续使用这款模型的主要原因。

目前这款神秘模型还没有正式发布，在 OpenCode 里依然是可用的状态，这只太空兔究竟是哪家的，我也忍不住猜一把。看到 Space，容易想到 SpaceX；看到玉兔，又能一路联想月之暗面的 Kimi，光凭名字就够聊半天的。

不过我目前更偏向 MiniMax：已经有针对 OpenCode 接口的独立测试发现，同一组文本在太空兔和 MiniMax 多款模型上的 token 计数特征一致。当然了，共用分词方式还不足以确认厂商，更不能锁定具体版本，OpenRouter 目前也仍将它列为匿名模型。我先把这一票投给 MiniMax，等兔子真正露面的那一天，再回来看我猜得准不准。

你也可以去 OpenCode 里试试这款模型的能力了，目前依然免费使用中。