这次记录两个独立项目的接入过程。第一个项目只验证 Codex 通过 OpenAI 兼容接口调用 Kimi-K3，完成一个原生前端页面；第二个项目再从零实现任务列表，把后端、前端和测试分别交给不同模型。两个项目的代码目录和任务都不相同，只有接口地址、API Key 和模型 ID 的配置方式相同。

接口和模型 ID

AiiOnly 控制台提供 OpenAI Chat Completions 和 Anthropic Messages 两种兼容接口：

OpenAI：https://llm.aiionly.com/v1/chat/completions
Anthropic：https://llm.aiionly.com/v1/messages

想先自己体验，可以从我的专属注册链接进入：https://maas.aiionly.com/login?inviteCode=0029773。当前活动下，注册就送16-15的金币充值代金券+5元token plan无门槛代金券

这两种接口的请求体不能混用。这两个项目都使用 Codex 或 VeryClaw，实际走 OpenAI 兼容接口。配置时使用控制台中的精确模型 ID，不使用页面上的中文展示名称。

接口地址确认后，还要先核对模型清单和调用 ID，再进入具体工具配置。控制台目前列出 DeepSeek、GLM、Kimi 和 MiniMax 四个系列，共 11 个模型。GLM-5.3 是后来加入的模型，ID 为 glm-5.3；后面的两个项目分别实际调用 kimi-k3、deepseek-v4-pro 和 glm-5.2。

接口地址确定之后，模型 ID 就是请求路由的关键字段。工具里的槽位名称可以继续保留，但发送给服务端的值必须是控制台给出的 ID。

项目一：Codex 调用 Kimi-K3 完成前端看板

第一个项目没有后端，目的是验证 Codex 是否能通过 OpenAI Chat Completions 接口完成一个完整的前端任务。我在 Codex 中配置 AiiOnly，把 gpt-5.4 槽位映射到 kimi-k3，然后在空目录中创建原生 HTML、CSS 和 JavaScript 文件。

我给它的任务是创建一个“AI 编程任务看板”：页面包含三个任务、状态筛选、进度切换和响应式布局，不使用前端框架和构建工具。任务要求、当前模型槽位和执行过程在同一个 Codex 会话中完成，生成的文件是 index.html、style.css 和 script.js。

页面生成后，我直接在浏览器中打开文件检查交互。筛选按钮可以切换任务状态，任务状态和总进度会随操作更新，窗口缩小时布局也能保持可用。页面卡片中出现的模型名称只是演示数据，真正完成这次页面生成的是映射后的 Kimi-K3。

回到控制台的调用明细，可以看到 Kimi-K3 的请求次数、输入输出 Token 和 Credits 扣减。这张记录对应的是上面这个独立的前端看板项目，不是后面的任务列表项目。用量记录和项目目录一一对应，后面分析任务列表时不会把两次调用混在一起。这里同时确认了请求确实抵达指定模型，而不是只完成了本地文件生成。模型名称、请求数量、输入输出数量和额度扣减都能在同一条记录里对照，前端结果也有了服务端证据。

这个项目验证了最小接入路径：Codex 使用 OpenAI Chat Completions，模型 ID 配置为 kimi-k3，模型根据任务创建前端文件，浏览器负责最后的交互检查。

项目二：任务列表的后端实现

第二个项目是一个独立的本地任务列表，目录为 task-list。它要保存任务数据，并支持新增、查询、修改、删除、状态更新、状态筛选和关键词搜索。任务字段包括 id、title、description、priority、due_date、status 和 created_at。

这一步使用 deepseek-v4-pro。我要求它先只创建 Flask + SQLite 后端和 pytest 测试，不生成前端，先把接口边界固定下来。接口包括 GET/POST /api/tasks、GET/PUT/DELETE /api/tasks/<id> 和 PATCH /api/tasks/<id>/status，列表接口支持 status 与 keyword 查询参数；空标题、非法优先级和非法状态需要返回 JSON 错误。

生成结果包括 app.py、requirements.txt、SQLite 初始化代码和 tests/ 目录。服务默认监听 http://127.0.0.1:5000，测试使用临时数据库，避免测试数据污染开发环境。

第一次执行测试时得到 21 个通过。此时后端已经可以独立启动，前端只需要按照接口路径发送请求，不需要再猜字段名称和状态值。

项目二：Kimi-K3 实现前端

后端接口确定后，我在同一个 task-list 目录中切换到 Kimi-K3，让它只负责页面和浏览器交互。Codex 中显示 gpt-5.4 槽位，实际映射为 kimi-k3；任务要求明确写了“不修改后端接口”。

前端使用原生 HTML、CSS 和 JavaScript，不引入 Vue、React 或构建工具。页面需要支持新增、编辑、删除、完成状态切换、状态筛选、关键词搜索、优先级和截止日期，并处理加载中、空列表和接口错误状态。

生成的页面把任务表单和列表放在同一屏：左侧填写标题、备注、优先级和截止日期，右侧显示全部、待办、进行中和已完成筛选，以及搜索框和任务卡片。前端通过 fetch 调用 Flask API，刷新页面后重新从 SQLite 读取数据。

我在浏览器中新增了两条任务，设置不同优先级，完成其中一条，再切换筛选条件和搜索关键词。列表数量会随筛选变化，编辑、删除和刷新后的数据也能对应到后端记录。这里的 Kimi-K3 与项目一中的 Kimi-K3 是两次独立调用，只是承担的前端任务不同。页面验证完成后，才进入下一步测试，不把浏览器效果当成接口测试结果。

项目二：GLM-5.2 做测试和修复

前后端第一次联调完成后，再用 glm-5.2 检查整个 task-list 项目。它先读取 app.py、script.js 和现有测试，执行全部 pytest，并检查新增、编辑、删除、完成状态、筛选和错误处理。

第一次检查得到 21 个通过。测试范围还包括任务为空时的前端提示、无匹配搜索、title 为空、非法 priority 和 status，以及删除不存在任务时的状态码。

第一轮检查发现了几处实际问题：服务每次启动都会 DROP TABLE，重启会清空任务；title 为 null 时被转换成字符串 None；前端直接解析失败响应，错误信息不清楚；空列表和无匹配筛选使用了同一段提示文字。GLM-5.2 没有重写项目，而是修改数据库初始化参数、请求字段校验、前端 JSON 解析和空状态文案，并补充边界测试。

修复后再次执行完整测试，结果从 21 个增加到 37 个，全部通过。新增用例覆盖 null 字段、非法状态、空请求体、CORS 预检、PATCH 请求和无结果搜索。测试命令、通过数量和修改文件都保留在同一次会话里，便于复查修复是否真的生效。这个结果也把第一次实现、问题定位、代码修改和最终验证连成了一条可复查的记录。前面的失败点、对应的修复文件、补充的测试数量和最后的通过结果都在终端输出中明确列出，便于继续定位回归问题。

VeryClaw 的本地调用路径

任务列表项目之外，我还用 VeryClaw 单独确认了模型提供商和 Chat 调用。添加提供商时选择 AiiOnly，填入 API Key 和模型 ID；页面注明密钥保存在本机。这里配置的是 deepseek-v4-flash，与上面两个项目的 Codex 配置相互独立。

配置完成后，Chat 输入框下方可以选择模型。我用 GLM-5.2 做了一个 Python 滑块算法任务，返回内容包含实现说明、运行命令和生成的 slider_solver.py 文件。对话消息、工具调用和文件变更都留在同一个会话中。

这次对话还确认了模型选择、工具调用和文件生成可以连续发生，不需要把返回内容复制到另一个终端。VeryClaw 的输入区还提供 Word、PDF、PPT、技能查找和自我改进等入口，底部显示本地 gateway 连接状态。它和 Codex 的差别在于，模型、Chat、Agent、技能和本地文件操作都集中在一个桌面会话中。

结果与边界

两个项目的结果可以分别复现：项目一是 Codex + Kimi-K3 的原生前端看板；项目二是 DeepSeek-V4-Pro 后端、Kimi-K3 前端和 GLM-5.2 测试修复的任务列表。它们没有共用代码，也没有把一次调用伪装成另一个项目。

想先自己体验，可以从我的专属注册链接进入：https://maas.aiionly.com/login?inviteCode=0029773。当前活动下，注册就送16-15的金币充值代金券+5元token plan无门槛代金券

平台侧需要留意 Standard 的月度 Credits、QPS 和模型倍率。输入、输出和缓存 Token 会按模型换算 Credits，所以记录模型 ID、测试命令和最终测试结果，比只记录“请求成功”更有用。实际接入时，先确认协议，再复制模型 ID，最后用最小请求验证工具和服务端的连通性。