企业官网建设流程全解析

1. 这套组合到底在解决什么问题

先把话说清楚：标题里说的“凤雏”和“太空兔”，指的是两个近期在 AI coding 圈子里被反复提及的模型服务入口——MiniMax 3.1 和 Space Bunny。把它们“一锅炖”，意思不是真的把两个模型合并，而是把两者的能力通过一个统一的调用层串起来，让它们在同一个编码工作流里各司其职。这件事之所以值得聊，是因为现在做 AI coding 的人普遍面临一个很现实的困境：单个模型要么在长上下文理解上差点意思，要么在代码生成的细节上不够稳，要么就是额度贵得让人心疼。与其死磕一个，不如把几个入口编排起来，按任务类型分流。

我自己的做法是：用 OpenCode 作为本地编码代理的交互层，后端通过 OpenRouter 这类聚合接口来路由请求，把 MiniMax 3.1 和 Space Bunny 分别配置成不同的“工种”。MiniMax 3.1 在处理中文语境下的需求描述、长文件重构、以及需要较强指令跟随的场景里表现比较扎实；Space Bunny 则在快速生成样板代码、补全函数体、写测试用例这类“短平快”的任务上响应更利落。两者不是替代关系，而是互补关系。

这套方案适合谁？如果你已经在用命令行工具做开发，对 API 调用不陌生，并且手头有至少一个可用的模型额度，那这套编排思路可以直接抄。如果你是完全没接触过 AI coding 的新手，也不用慌，我会把每一步拆到能照着敲命令的程度。核心关键词就几个：MiniMax 3.1、Space Bunny、OpenCode、OpenRouter、coding 工作流编排。整篇文章围绕这几个词展开，不跑题。

需要提前说明的是，下面涉及的具体配置和参数，一部分来自我本地的实际记录，一部分是基于这类工具常见实践做的合理补全。不同时间点服务商的接口地址、额度规则可能有变化，你实操时以自己控制台里看到的为准。

2. 为什么要把两个模型“炖”在一起

2.1 单模型工作流的三个真实痛点

先说为什么要折腾。我最早也是只用一个模型跑所有任务，用了大概两周就发现三个问题。

第一个是上下文窗口的性价比问题。做代码重构的时候，你往往需要把整个文件甚至整个模块喂进去，token 消耗非常快。有些模型虽然支持长上下文，但超过一定长度后注意力就散了，生成的代码开始出现前后不一致。这时候如果换一个在长文本上更稳的模型来处理这类任务，成本和质量都能改善。

第二个是任务类型和模型特长的错配。写一个 CRUD 接口和排查一个内存泄漏，对模型能力的要求完全不同。前者要的是模板熟悉度和生成速度，后者要的是推理深度和对错误信息的理解。用一个模型硬扛所有场景，结果就是有些任务快但糙，有些任务慢且贵。

第三个是单一入口的额度风险。这个不用多解释，做过 API 调用的人都懂。把所有请求压在一个服务上，一旦额度用完或者接口抖动，整个工作流就断了。多入口编排本质上是一种降级策略。

2.2 两个模型的分工逻辑

基于上面三个痛点，我给 MiniMax 3.1 和 Space Bunny 划了不同的职责范围。这个划分不是拍脑袋定的，是实际跑了几十个任务之后总结出来的。

MiniMax 3.1 主要承担三类任务：需求理解与拆解、跨文件重构、以及需要严格遵循项目规范的代码生成。它在理解中文技术描述时歧义更少，你写“把这个 service 层的错误处理统一成 Result 包装”，它能比较准确地定位到需要改哪些文件。Space Bunny 则负责：单文件内的函数补全、单元测试生成、注释和文档字符串撰写、以及快速的原型代码草稿。这些任务的共同点是范围小、目标明确、对生成速度敏感。

注意：这个分工不是绝对的。如果你手头只有其中一个模型的额度，完全可以先用一个跑起来，等熟悉了工作流再考虑加第二个。编排的价值在于灵活，不在于数量。

2.3 编排层选 OpenCode 的理由

把两个模型串起来需要一个中间层。我选 OpenCode 的原因有三个：它是命令行原生的，跟我的终端工作流无缝衔接；它支持自定义 provider 配置，可以指向不同的 API 端点；它的会话管理机制允许我在同一个项目里切换模型而不丢失上下文。

OpenCode 的工作方式是在项目目录下启动一个会话，它会读取当前目录的文件结构作为上下文，然后你通过自然语言下达指令。它本身不绑定任何特定模型，你需要在配置文件里指定 provider 和 model。这就给了我们“一锅炖”的操作空间——配置多个 provider，按需切换。

3. 环境准备与基础配置

3.1 OpenCode 的安装与初始化

安装 OpenCode 的方式取决于你的系统。我用的是 macOS，通过包管理器安装最省事。如果你用其他系统，去它的官方仓库找对应的安装说明。

# macOS 下通过 Homebrew 安装 brew install opencode # 验证安装 opencode --version

安装完成后，第一次运行需要在项目目录下初始化。进入你的代码仓库根目录，执行：

cd /path/to/your/project opencode init

这个命令会生成一个配置文件，通常在.opencode/config.json或者项目根目录下的opencode.json。具体文件名以你安装的版本为准，用ls -a看一下就知道了。

初始化之后，你需要配置 provider。OpenCode 支持多种 provider 类型，我们这里要用的是兼容 OpenAI 接口格式的自定义端点。配置文件的结构大概是这样：

{ "providers": { "minimax": { "type": "openai-compatible", "baseURL": "你的 MiniMax 接口地址", "apiKey": "你的密钥", "models": { "minimax-3.1": { "maxTokens": 8192, "contextWindow": 128000 } } }, "spacebunny": { "type": "openai-compatible", "baseURL": "你的 Space Bunny 接口地址", "apiKey": "你的密钥", "models": { "space-bunny": { "maxTokens": 4096, "contextWindow": 32000 } } } } }

这里有几个点要说明。baseURL和apiKey必须从你实际使用的服务控制台获取，我不在这里写具体地址，因为这类信息变动频繁，写死了反而误导人。maxTokens控制单次生成的最大长度，contextWindow是模型支持的上下文总长度。这两个参数设得合理，能避免很多“生成到一半断了”的问题。

3.2 通过 OpenRouter 做统一入口的配置

如果你不想分别管理两个服务的密钥和账单，可以用 OpenRouter 作为聚合层。OpenRouter 的好处是一个密钥就能访问多个模型，计费也统一。配置方式是把上面两个 provider 的baseURL都指向 OpenRouter 的接口地址，然后在model字段里填对应的模型标识。

{ "providers": { "openrouter": { "type": "openai-compatible", "baseURL": "https://openrouter.ai/api/v1", "apiKey": "你的 OpenRouter 密钥", "models": { "minimax-3.1": { "model": "minimax/minimax-3.1", "maxTokens": 8192 }, "space-bunny": { "model": "spacebunny/space-bunny", "maxTokens": 4096 } } } } }

用 OpenRouter 的代价是中间多了一层转发，延迟会略微增加，而且它的计费单价通常比直连略高。但换来的是配置简单、额度统一、切换模型方便。我个人在项目初期用 OpenRouter 快速验证，等确定长期用某个模型后再考虑直连。

提示：OpenRouter 的充值方式支持多种渠道，具体操作在它的控制台里跟着引导走就行。这里不展开，避免涉及具体的支付流程描述。

3.3 验证配置是否生效

配置写完之后，别急着上复杂任务。先用一个最简单的请求验证链路通不通。

# 在项目目录下启动 opencode opencode # 进入交互界面后，输入一个简单指令 # 比如：解释一下当前目录下 package.json 的作用

如果模型能正常返回内容，说明配置没问题。如果报错，重点检查三个地方：baseURL是否有多余的斜杠、apiKey是否过期、model字段的标识是否和服务商文档一致。我踩过的坑是baseURL末尾多写了一个/，导致请求路径拼接错误，排查了快半小时。

4. 核心工作流拆解与实操

4.1 任务分流的具体规则

配置通了之后，关键是怎么在两个模型之间分流。我的规则很简单，按任务的文件影响范围和推理深度来分。

这个表格不是死的。实际用的时候，我会根据当前会话的上下文长度动态调整。如果会话里已经积累了大量文件内容，切到 Space Bunny 做小任务时要注意它的上下文窗口较小，可能需要开新会话。

4.2 在 OpenCode 中切换模型的实操

OpenCode 的交互界面里通常有切换模型的命令。具体快捷键或命令可能因版本而异，常见的是/model或者Ctrl+M。切换之后，后续的对话就用新模型处理。

我的习惯是：开一个会话专门做重构，全程用 MiniMax 3.1；另开一个会话做测试和补全，全程用 Space Bunny。这样避免频繁切换导致上下文混乱。OpenCode 支持多会话并行，在终端里开多个标签页就行。

# 终端标签页 1：重构会话 cd /path/to/project opencode --session refactor # 终端标签页 2：测试会话 cd /path/to/project opencode --session testing

--session参数会给会话命名，方便后续恢复。如果你经常做同一类任务，这个习惯能省不少事。

4.3 一个完整的重构任务实录

拿一个真实场景来说。我有一个 Node.js 项目，service 层的错误处理很乱，有的地方直接 throw，有的地方返回{ error: ... }，还有的地方用回调。我想统一成返回Result<T, E>类型。

第一步，用 MiniMax 3.1 做需求拆解。我在 OpenCode 里输入：

当前项目 service 层的错误处理方式不统一。请先扫描 src/services 目录下的所有文件， 列出每个文件的错误处理方式，然后给出一个统一成 Result 类型的改造方案。 不要直接改代码，先出方案。

MiniMax 3.1 会读取目录下的文件，输出一个分析报告。这一步很关键，因为跨文件重构最怕的就是漏掉某个文件或者误解了某个函数的契约。让它先出方案，我人工确认之后再动手。

第二步，确认方案后，让它逐个文件改造。这里要注意，不要一次性让它改所有文件。我的做法是一个文件一个文件来，每改完一个就 review 一下。

现在按照方案改造 src/services/userService.js。 保持函数签名不变，只改错误处理部分。 改完之后把改动前后的对比贴出来。

第三步，改完所有文件后，用 Space Bunny 生成对应的单元测试。因为测试用例的模板化程度高，用 Space Bunny 更快。

为 src/services/userService.js 生成单元测试， 覆盖正常路径和所有错误分支。 用 Jest 框架。

这套流程跑下来，一个中等规模的重构任务大概需要 40 分钟到 1 小时，其中大部分时间花在我 review 和确认上。模型本身生成的速度很快，瓶颈在人的判断。

4.4 参数调优的实操记录

在跑任务的过程中，有几个参数值得调。

temperature：做重构和错误分析时，我调到 0.2 左右，让输出更确定。做原型草稿和头脑风暴时，调到 0.7 左右，让生成更多样。OpenCode 的配置文件里可以给每个模型单独设默认 temperature。

maxTokens：这个值设小了会导致生成被截断。我的经验是，重构任务设 8192，测试生成设 4096，注释生成设 2048。设大了浪费额度，设小了反复重试更浪费。

contextWindow：这个参数影响 OpenCode 决定往请求里塞多少文件内容。设得太大，每次请求的 token 消耗高；设得太小，模型看不到足够的上下文。我一般设成模型实际支持值的 80%，留一点余量给系统提示和对话历史。

{ "models": { "minimax-3.1": { "maxTokens": 8192, "contextWindow": 100000, "temperature": 0.2 }, "space-bunny": { "maxTokens": 4096, "contextWindow": 24000, "temperature": 0.5 } } }

这些数值不是标准答案，是根据我自己的任务类型和额度情况调的。你刚开始可以用默认值，跑一段时间后根据实际消耗和质量再调。

5. 常见问题与排查技巧

5.1 接口报错与额度问题

问题一：请求返回 401 或 403。九成是密钥问题。检查密钥是否复制完整，有没有多余的空格。如果用的是 OpenRouter，确认密钥的权限范围是否包含你要调用的模型。

问题二：请求返回 429。这是触发了速率限制。两个处理方式：一是降低请求频率，在 OpenCode 里把并发请求数调低；二是切换到另一个 provider 临时顶一下。这就是多入口编排的好处，一个限流了另一个还能用。

问题三：生成到一半突然中断。先看maxTokens是不是设小了。如果maxTokens没问题，检查网络连接是否稳定。还有一种可能是模型的上下文窗口满了，OpenCode 在拼接请求时超出了限制。这时候需要开新会话，或者手动清理对话历史。

问题四：模型返回的内容和问题无关。这种情况通常是上下文污染了。OpenCode 会把之前的对话历史一起发给模型，如果历史里有大量无关内容，模型可能被带偏。解决办法是用/clear命令清空当前会话的上下文，重新开始。

5.2 模型切换后的上下文丢失

这是我在实操中遇到最多的坑。在 OpenCode 里切换模型后，新模型默认不会继承旧模型的对话历史，因为它不知道旧模型说过什么。如果你在一个会话里先让 MiniMax 3.1 分析了代码，然后切到 Space Bunny 让它改，Space Bunny 是看不到分析结果的。

解决办法有两个。一是把关键信息手动复制到新会话里，作为上下文喂给新模型。二是用 OpenCode 的会话导出功能，把当前会话的内容导出成文件，然后在新会话里引用这个文件。

# 导出当前会话 opencode export --session refactor > refactor-context.md # 在新会话里引用 opencode --session testing # 然后在对话里说：请参考 refactor-context.md 里的分析结果

这个操作稍微麻烦一点，但能保证信息不丢失。我现在的习惯是，跨模型协作时一定先导出上下文。

5.3 代码质量不稳定的应对

模型生成的代码质量波动是常态。我的应对策略是三层过滤。

第一层，提示词里明确约束。不要说“帮我改一下这个函数”，而要说“把这个函数改成纯函数，不产生副作用，参数和返回值类型保持不变，用 TypeScript 的严格模式”。约束越具体，输出越稳定。

第二层，要求模型自检。在提示词末尾加一句“改完之后检查一遍，确认没有引入新的依赖，没有改变函数签名”。这个简单的自检指令能过滤掉一部分低级错误。

第三层，人工 review 不可省。不管模型说得多自信，改完的代码一定要自己看一遍。我遇到过模型把async函数改成同步的，还信誓旦旦说“保持了原有行为”。这种错误只有人眼能抓出来。

5.4 常见问题速查表

6. 成本控制与额度管理

6.1 两个模型的消耗特征

MiniMax 3.1 的单次请求 token 消耗通常比 Space Bunny 高，因为它处理的上下文更长，生成的代码也更长。Space Bunny 单次消耗低，但如果你用它做大量小任务，累积起来也不少。

我的经验数据是：一个中等规模的重构任务，MiniMax 3.1 大概消耗 3 万到 5 万 token；同样规模的测试生成任务，Space Bunny 大概消耗 1 万到 2 万 token。具体数值取决于项目大小和对话轮次。

6.2 额度分配策略

如果你两个模型都有独立额度，建议按 6:4 分配，MiniMax 3.1 占六成，Space Bunny 占四成。因为重构和分析类任务更耗 token，而且这些任务对质量要求更高，值得用好模型。

如果通过 OpenRouter 统一计费，那就没有分配问题，但要注意设置预算上限。OpenRouter 的控制台里可以设每日或每月限额，防止意外超支。

提示：刚开始用的时候，建议把限额设低一点，跑一周看看实际消耗，再调整到合理水平。我见过有人第一天就把额度跑完的，就是因为没设限额，模型在循环里反复重试。

6.3 减少无效消耗的技巧

技巧一：先出方案再动手。让模型先分析再改代码，比直接让它改要省 token。因为分析阶段的输出短，而且你能提前发现方案有问题，避免改到一半推翻重来。

技巧二：分批处理。不要一次性把整个项目丢给模型。按模块分批，每次只处理一个目录或一个功能。这样每次请求的上下文小，token 消耗低，而且出错时影响范围小。

技巧三：复用会话。同一类任务尽量在同一个会话里完成，这样模型能复用之前的上下文，减少重复描述。但要注意会话太长会导致上下文窗口满，需要适时清理。

技巧四：用 Space Bunny 做草稿。需要生成大量样板代码时，先用 Space Bunny 出草稿，然后人工筛选和修改。草稿的质量不需要很高，能省下 MiniMax 3.1 的额度用在关键任务上。

7. 进阶玩法与扩展思路

7.1 把编排思路扩展到更多模型

MiniMax 3.1 和 Space Bunny 只是两个例子。这套编排思路可以扩展到任何兼容 OpenAI 接口的模型。比如你可以加一个专门做代码审查的模型，或者一个专门做 SQL 生成的模型。OpenCode 的配置文件支持任意数量的 provider，只要你的机器内存和网络扛得住。

扩展的时候注意一点：每加一个模型，配置复杂度就上升一截。我的建议是先从两个开始，跑顺了再加第三个。不要一上来就配五六个，管理不过来。

7.2 与版本控制系统的结合

OpenCode 在项目目录下工作，天然和 Git 配合。我的习惯是每完成一个模型的改造任务就提交一次，commit message 里注明用了哪个模型。这样出问题的时候可以快速定位是哪个模型的输出导致的。

# 用 MiniMax 3.1 重构完 userService.js 后 git add src/services/userService.js git commit -m "refactor: unify error handling in userService (by minimax-3.1)" # 用 Space Bunny 生成测试后 git add src/services/userService.test.js git commit -m "test: add unit tests for userService (by space-bunny)"

这个习惯看起来多余，但当你回滚代码时就知道好处了。你能清楚地看到哪些改动是模型做的，哪些是自己手动调的。

7.3 团队协作中的注意事项

如果你在团队里推广这套工作流，有几件事要提前对齐。一是配置文件里的密钥不能提交到仓库，要用环境变量或者本地配置文件加.gitignore。二是团队成员的模型额度可能不同，要约定好哪些任务用哪个模型，避免有人额度用完了影响进度。三是代码 review 的标准要统一，不能因为“这是 AI 生成的”就降低要求。

我自己的做法是在项目根目录放一个OPENCODE.md，里面写清楚本项目的模型使用规范、提示词模板、以及 review 检查清单。新成员加入时先读这个文件，能少走很多弯路。

7.4 后续可以尝试的方向

这套工作流跑顺之后，可以尝试几个方向。一是把常用的提示词模板化，做成 OpenCode 的自定义命令，减少重复输入。二是接入 CI 流程，让模型在提交前自动跑一遍代码审查。三是记录每个模型在不同任务上的表现数据，用数据驱动模型选择，而不是凭感觉。

我现在还在摸索阶段，上面这些方向有的试过有的没试过。但有一点是确定的：把多个模型编排起来用，比死磕一个模型要灵活得多。成本可控，质量可控，风险也可控。这个思路本身就值得花时间琢磨。

最后分享一个我踩过的坑：不要在同一个会话里频繁切换模型。我试过在一个会话里 MiniMax 3.1 和 Space Bunny 来回切，结果两边的上下文都乱了，生成的代码前后矛盾。后来改成按任务类型分会话，一个会话只用一个模型，问题就没了。这个教训花了我一个下午才总结出来，希望你能避开。