一个连开发商是谁都不知道的免费 AI 模型，Space Bunny，为什么让我愿意主动掏钱订阅？
最近三个星期，我一直在用一个叫 Space Bunny ，又叫太空兔的 AI 模型写代码。
它在 OpenRouter、OpenCode、Cline 上免费提供。我通过 OpenCode 使用。直到现在，我也不知道它究竟是哪家公司开发的。
前几天，我甚至专门问过 ChatGPT，也问过 Bunny 自己，想知道它到底是谁家的。
原因很简单：我想订阅它。
倒不是因为免费额度不够，而是用了三个星期以后，我觉得这个模型值得付钱。
我平时也使用 GPT、Claude、GLM 等各种模型，其中不乏价格不低、编程排行榜成绩很好的产品。
但真正让我愿意放心交出项目的，反而是这个免费的 Bunny。
它并不是从不犯错，有时候甚至挺烦人的。
不过，今天发生的一件事，让我觉得有必要把这三个星期的使用感受认真写下来。
因为这可能比单纯比较模型跑分，更能说明什么叫 AI Agent 的用户体验。
一、同样的任务，两种完全不同的做事方式
我有一个正在开发的 AI 网站，没错，就是聚模合，最近准备完善其中的模型使用费用计算器。
简单来说，用户选择一个模型，再选择使用场景和任务规模，就能估算大概需要花多少钱。
看起来只是个计算器，实际上涉及模型价格、请求次数、上下文长度、缓存费用、会话复杂度等不少变量。
网站原本已经有一些相关数据，也有一版计算器。
我先让 GPT-6.1 Sol 处理这件事，而且使用的是 High 推理模式。
它很快给出了估算结果。
其中一个关键假设是：每分钟发生一次模型请求，所以一小时大概 60 次。
我觉得不对。
因为我自己做过实际测试，知道真实请求数远不止这些。
于是我告诉它：
不准，你先测几次，我再告诉你，请求数估得少了很多。
GPT 承认之前的假设缺乏实测依据，决定重新验证。
到这里，一切正常。
接下来不出意外的话意外出现了。
它在本地发现了一份相关实测数据，但认为既然已经看过结果，再拿它验证就不算真正的盲测。
这个思路本身没什么问题。
然后，它决定做几次新的编程测试。
它真的启动了三个编程任务，开始调用付费模型。
其中两个已经结束的任务，CLI 显示的估算费用分别是：
- $0.259
- $0.266
第三个任务还没有完整费用结果。
我看到它在执行这些任务，赶紧问：
你想干嘛？测试什么？
然后把任务叫停了。
它后来承认，未经确认实验范围，就自行启动付费 API 测试是不合适的，甚至还整理了一份 Bug Report。
但我当时想到的是另一个问题。
如果我没盯着呢？
我原本只是让它估算一个费用计算器。
它却可能为了提高估算精度，针对不同场景启动更多编程任务，消耗更多 API 费用。
当然，最后究竟会花多少钱，没人知道。
可问题不在于最终花了多少钱，而在于它根本没有事先跟我确认。
它的技术思路可能合理，但是否值得为这个实验花钱，至少应该让我知道。
这让我想起以前使用 GPT 做项目重构时遇到的情况。
有时候它并不是不会做，而是很快就决定了一条路线，然后一路干下去。
等我发现不对，可能已经做了不少工作。
二、我把同样的问题交给了 Bunny
后来，我新开了一个 OpenCode Session，把同样的费用测算需求交给 Space Bunny。
注意，这是一个全新的 Session。
没有延续昨天的对话，也没有我专门给它写好的复杂操作规则。
Bunny 的第一句话是：
我先摸清仓库里现有的计算器页面和「会话成本榜」的数据结构。
接下来，它启动了两个搜索代理。
一个查找计算器页面和模板，另一个查找已有的成本数据。
它自己则开始查看项目里的价格文件和计算器代码。
很快，它发现：
已有计算器存在，且已有一版场景参数。看它的计算逻辑。
看到这里，我其实已经觉得挺舒服了。
因为它没有急着重新设计一套算法，也没有马上给我一个结果。
它首先想知道，这个项目里已经有什么。
这听起来应该是程序员最基本的工作习惯。
但实际使用过不少编程 Agent 以后，我发现并不是每个模型都会这么做。
有些模型拿到需求，会很快给出一套自己的实现方式。
代码可能能运行，测试也可能通过，但它未必认真考虑过项目原来是怎样实现的。
对于从零开发，这不一定是什么问题。
但对于已经运行的项目，这种习惯有时候很危险。
Bunny 接下来的表现，更让我觉得有意思。
三、它一路分析，一路推翻自己的结论
Bunny 开始分析本地的真实成本数据。
它先发现，不同开发工具即使使用同一个模型，实际请求成本也可能相差很大。
如果把它们混在一起统计，结果就容易失真。
于是它重新按工具分类。
随后，它尝试使用回归分析建立成本预测模型。
但计算过程中，它发现数据不足以可靠地识别某些参数。
它没有强行拟合出一个看起来漂亮的公式，而是直接得出结论：
回归不可辨识已经确证。
然后换一种方法。
新方法算出来的结果又不符合预期。
它继续检查，发现自己之前把不同开发工具的数据混在一起了。
修正以后，趋势才恢复正常。
接着，又发现统计脚本的数据分组方式有问题。
还是自己发现，自己修改。
整个过程我基本没参与。
它没有每隔两分钟就跑来问我下一步怎么办，也没有把计算失败的问题丢给我。
能自己解决的，它就继续研究。
后来，它又发现现有费用计算器的一个问题。
某个用来区分任务复杂度的选项，在现有算法下竟然不会改变每小时费用。
用户选简单还是复杂，结果一样。
它把原因分析出来，提出了新的计算方式。
至于新方案最终是否准确，还需要真实数据验证。
但它至少发现了一个原本没人注意到的问题。
这已经超出了我最初交代的任务范围。
我让它完善费用估算，它却顺便帮我检查了现有产品的逻辑。
四、真正需要我决定的时候，它才停下来
分析到一定程度，Bunny 找到了一个可能影响现有榜单的数据处理问题。
它没有马上修改。
因为这部分代码不只服务于费用计算器，还关系到网站上几个正在运行的榜单页面。
如果贸然修改，可能导致现有榜单数值发生变化。
于是它告诉我，建议单独处理。
同时提出了另外两个问题。
一个涉及算法参数应该偏保守，还是更贴近实测数据。
另一个涉及计算器应该优先使用实测数据，还是使用覆盖范围更广的估算结果。
它给出了自己的建议，然后等我决定。
我回复得很简单：
1 建议评估
2 取值需测算，或者找资料，我可以去找些标准
3 A 和 B 是啥
Bunny 没有要求我先把所有问题想清楚。
它先解释我没理解的两个方案，然后继续调查其他问题。
接下来，它开始量化那个数据处理问题的影响，重新计算算法参数。
中间又发现原来的数学假设不合理，于是重新调整方法。
最后还主动搜索公开资料，寻找独立参考。
这个过程持续了相当长一段时间。
但我不需要坐在旁边指挥。
我只告诉它方向。
具体怎么查、怎么算、发现问题怎么办，它自己想办法。
这才是我希望编程 Agent 能做到的事情。
五、让我捧腹的是，它认出了我的测试数据
后来，我准备拿一份真实账单验证它的费用预测。
我告诉它：
163 次请求，花了大约 1.6 美元。
Bunny 的反应把我逗笑了。
它说：
163 次请求 / $1.6 —— 这个数字我认得，它就是站内那篇实测文章。先核对。
我当时真的笑了。
因为这是新开的 Session。
而且我说的是约数。
真实费用是 $1.5869，并不是恰好 $1.60。
它之所以能认出来，是因为之前调查项目时，已经读到了网站上的那篇实测文章。
更有意思的是，它没有因为认出了数字，就直接拿来计算。
它还要核对。
我觉得这很像一个长期参与项目的工程师。
老板随口提到一组数据，他马上想起来：
这不是我们以前做过的那个测试吗？
然后去查原始记录。
这种感觉很特别。
不是因为它有什么神奇的记忆能力，而是它之前确实认真了解过项目里的资料，并且知道什么时候应该使用这些信息。
六、它还主动找到了第二组实测数据
故事到这里还没结束。
Bunny 继续调查的时候，又发现了网站里的另一篇实测文章。
这篇文章记录了同一个模型在另一个编程场景中的实际费用。
它主动把两组数据放在一起比较。
| 指标 | 修改真实项目 | 开发马里奥游戏 |
|---|---|---|
| 模型 | Haiku 5.5 | Haiku 5.5 |
| 开发工具 | Claude Code | Claude Code |
| 请求数 | 163 | 32 |
| 时长 | 60 分钟 | 19 分钟 |
| 总费用 | $1.5869 | $0.342 |
| 平均每次请求成本 | $0.009736 | $0.010688 |
| 平均请求间隔 | 22.1 秒 | 35.6 秒 |
两个任务使用相同模型和开发工具，单次请求的平均成本比较接近，但请求频率明显不同。
这也说明，最初简单假设每分钟发生一次请求，并不可靠。
当然，只有两组数据，还不足以建立适用于所有场景的成本模型。
但它们可以用于检查之前的估算假设。
这里最让我满意的是：
我根本没有要求 Bunny 再去找第二组数据。
它自己在调查过程中发现了相关资料，觉得值得比较，就主动整理出来告诉我。
这和我最初让它做的事情有什么关系？
关系很大。
因为费用计算器真正需要的，不是某个看起来精确的数字，而是一个经得起实际数据检验的估算方法。
Bunny 正在围绕这个目标不断寻找证据。
七、当然，Bunny 也会犯错
写到这里，可能有人觉得我是在吹捧一个免费模型。
其实不是。
今天 Bunny 就犯了好几个错误。
有一次，我说：
忘了说，是让他改代码，你就估算一下，我等下给你结果。
我的意思是，前面的费用来自另一个模型执行代码修改任务。
结果 Bunny 理解成了我要它修改代码。
它开始查看测试文件，准备动手。
我赶紧打断：
不不不，不是让你改。
它停下来，调整了方向。
还有一次，它检查数据处理代码时，认为某个统计结果会受到数据读取顺序影响。
它甚至已经计算了可能造成的影响。
后来，它进一步阅读原始实现，发现自己判断错了。
原来的程序早就考虑过这个问题，并且使用了正确的合并逻辑。
它随即告诉我：
我之前只 grep 到调用处就下了结论，没读实现，这是我的错。
然后撤回之前的判断，重新计算。
这个错误其实挺典型的。
只看到了调用代码，没有看完整实现，就匆忙下结论。
很多程序员也会犯类似错误。
但有一点很重要：
它没有为了维护自己的结论，继续沿着错误的方向解释。
发现不对，就承认，再重新调查。
甚至它后来还明确告诉我，自己之前提出的一项参数推算建议，是早已被现有数据证明不可行的方法，不应该再次提出。
它不是从不犯错。
恰恰相反，今天我看着它推翻了不少自己的判断。
但这些错误多数是在它继续工作时被发现并纠正的。
当然，也有需要我提醒的时候。
我并不要求一个模型永远正确。
我更在意的是，它犯错以后，能不能及时发现，能不能认真处理。
八、说实话，它有时候挺烦人的
Bunny 有个习惯。
每次完成任务，它经常会提醒我：
哪些问题还没有处理，哪些地方需要验证，哪些风险暂时保留。
有些事情它甚至反复提醒。
我有时候真的觉得烦。
明明已经知道了，它还要再讲。
而且它经常需要我确认。
确认修改、确认方案、确认是否继续。
但用了三个星期以后，我逐渐发现：
这些让人烦的小确认，反而让我少了很多真正需要操心的事情。
因为它通常能够自己处理技术问题。
遇到需要改变现有设计、影响其他功能，或者涉及我必须作出选择的地方，它才停下来。
有时候它提出的方案，我根本没仔细看，就直接选 Yes。
这并不是说所有确认都应该无脑批准，而是长期使用以后，我已经比较熟悉它的工作方式。
我知道它通常会先调查，再判断，然后才行动。
这种信任不是来自某一次精彩表现。
而是三个星期里，一次次实际开发慢慢建立起来的。
它偶尔会走错方向，但通常能够及时修正。
这和那种一路执行、最后需要我检查整个工程有没有偏离目标的体验，是两回事。
九、今天最让我满意的，不是它算出了什么
今天从早上开始，Bunny 就在另一边处理费用计算器的问题。
它调查代码、分析数据、计算参数、发现错误、推翻假设、寻找新资料。
期间不断有新的发现。
它会告诉我：
这里的数据有问题。
那个算法的假设不成立。
现有代码中发现了另一个需要注意的地方。
之前的结论不准确，需要重新核对。
有些事情它自己解决了，有些事情它会停下来让我确认。
而我在干什么？
我一直在跟 ChatGPT 聊天。
聊模型、聊编程 Agent、聊 GPT 为什么容易偏离任务、聊 Bunny 为什么让我觉得放心。
Bunny 那边持续工作，我这边继续聊天。
偶尔切过去看一眼，需要确认的时候点一下。
然后回来继续聊。
甚至我跟 ChatGPT 聊了这么久，Bunny 还在不断发现新问题，给出新的分析结果。
直到后来，它又从项目里翻出第二份实测数据，主动拿来交叉比较。
我才突然意识到：
这不就是我一直想要的 AI Agent 吗？
我不需要看着它写代码。
不需要提醒它下一步应该干什么。
也不需要替它考虑所有可能发生的问题。
我只要告诉它想做什么，它就可以自己去做。
当然，它并不完美。
它会犯错，会误解，也会在某些问题上反复尝试。
但大部分时间，我不用替它操心。
这才是最重要的。
十、为什么我宁愿使用免费的 Bunny？
我之前也尝试过让 GPT 完成长时间的自主开发任务。
甚至为了让它理解得更准确，我特意改变了自己的习惯。
平时我很少写特别长的需求。
但那次项目重构，我把需求拆成了很多条，连技术栈、数据库、部署方式、验收条件都写得清清楚楚。
而且在 GPT 接手之前，Bunny 已经从原项目中理解了业务逻辑，搭建了部分新框架，数据库结构和 SQL 也经过讨论。
GPT 不是从零开始。
但后面的开发仍然出现了明显偏差。
它重新设计数据库，把原本需要结构化处理的 json 大数据放进了一个字段，甚至重新写了与既定技术路线不符的脚本。
最后我选择回退 Git，重新初始化数据库。
那一轮工作等于白做。
这件事让我开始怀疑：
一个模型即使能够长时间自主工作，究竟意味着什么？
连续运行几个小时、生成很多代码、所有测试都通过，这些当然有价值。
但如果方向从一开始就错了，最后又有什么意义？
我不是说 GPT 每次都会犯这样的错误。
也不是说它的编程能力一定不如 Bunny。
事实上，Bunny 在某些复杂技术任务上也可能不如 GPT。
但我的实际使用感受是：
使用 GPT 时，我经常担心它有没有充分理解原项目，会不会按照自己的习惯重新实现，会不会突然走偏。
而使用 Bunny，我没有那么多顾虑。
不是因为 Bunny 不犯错，而是因为它让我觉得，即使犯错，也有比较大的机会在过程中发现并纠正。
这种感觉很难用一个 Benchmark 分数表达。
却直接决定了我敢不敢把整个项目交给它。
十一、比模型能力更重要的，可能是信任
现在各种 AI 编程排行榜越来越多。
我们经常看到一个模型用几十分钟做出漂亮的网页、小游戏，甚至完整的应用程序。
这些展示当然有价值。
但真正的软件开发，尤其是维护已有项目，远远不只是把功能做出来。
现有代码有没有认真阅读？
以前的业务逻辑有没有保留？
数据库设计是否合理？
有没有遗漏那些不容易被测试发现的细节？
发现原来的技术判断不成立时，会不会主动修正？
用户没有想到的问题，模型能不能替他想到？
这些事情，很难通过一段演示视频看出来。
一个模型可能很擅长从零生成东西，却不一定擅长接手一个已经运行的项目。
一个模型可能编程成绩很高，但在长期协作中，未必能让用户真正放心。
当然，我并不认为今天的 Bunny 已经证明自己是最好的编程模型。
它只是让我看到了另一种更符合我需求的工作方式。
它不只是执行指令，还在主动理解项目、寻找证据、检查自己的判断。
而我作为使用者，不需要一直陪着它工作。
这才是我觉得最有价值的地方。
最后
用了三个星期，我越来越少需要告诉 Bunny 应该怎样完成任务。
很多时候，我只需要说清楚想做什么。
接下来它自己研究。
该查资料的时候查资料，该修改代码的时候修改代码，发现问题就继续追查。
真正需要我决定的时候，它再回来找我。
有时候我嫌它啰唆。
有时候它理解错了，我也会直接打断它。
但这些都没有改变我对它的信任。
因为我逐渐发现，它的工作方式是可预期的。
我不需要时时担心，等我回来以后，项目是不是已经被它改得面目全非。
今天最让我满意的一幕，其实不是它找出了什么复杂算法，也不是它认出了我提供的那份测试数据。
而是：
我在这边跟 ChatGPT 聊了大半天，Bunny 在另一边一直替我干活。
我没有因为不盯着它，就一直担心它会做错什么。
这种感觉，才是我真正想要的 AI Agent。
所以前几天，我才会到处问 Space Bunny 是谁家的。
我想找到它的开发商。
我想订阅它。
不是因为它最聪明，也不是因为它的排行榜分数有多高。
而是因为三个星期的实际使用，让我觉得它值得。
我愿意为强大的 AI 付费，但更愿意为一个让我放心的 AI 付费。
附：那个费用计算器也是它写的
上面反复提到的费用计算器，方案设计和代码都是 Space Bunny 写的。
不过因为模型调用太过复杂，里面的参数只能做个参考，别当成精确报价用。
注：本文根据最近三周的实际开发经历及部分会话记录整理。为避免暴露项目内部实现，对部分技术细节进行了简化。文中的 GPT-6.1 Sol 与 Space Bunny 分别运行在不同的 Agent 环境中，因此这些经历反映的是具体工具组合的实际使用体验，并非严格的模型能力对照实验。