MallocPointer's blog

分类： 未分类

  • 成就-Achievement

    AiryMoon.com月访问量达10w次

    CCPC-2026-东北区域赛-铜牌

  • OpenAI 兼容格式 API 公益站

    似乎大家的大模型API使用需求很高啊，而且自从出了openclaw(龙虾)之后使用的Token数的单位更是直接达到了上亿。所以呢，我做了这个公益API站点，在这里，大家可以使用ChatGPT-4，Kimi-k2.6，Glm4.7等模型。话不多说，咱们直接上干货。

    在日常的使用中，我常使用的是opencode以及codex。由于codex不是开源的，所以我这里展示opencode如何接入咱们API站点的使用方法。在长时间使用Ubuntu服务器之后，主包比较喜欢命令行的操作模式，所以在这里展示命令行的配置方法。

    这里将Windows和Linux的两种配置方法分开叙述，大家可以直接找到自己对应的操作系统

    Linux- Ubuntu/Debian

    在服务器中，相信大家也希望可以快速配置opencode来帮助自己完成一些服务器配置或者编写脚本自动执行。这里先展示一下如何在ubuntu中配置opencode

    一 进行系统更新 apt update

    二 安装nodejs以及npm

    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

    export NVM_DIR=”$HOME/.nvm”


    [ -s “$NVM_DIR/nvm.sh” ] && . “$NVM_DIR/nvm.sh”


    nvm install –lts


    node -v

    运行完以上的shell，相信大家的版本号一定也来到了 v24.x

    三 安装opencode npm i -g opencode-ai

    四 修改配置文件

    进入~/.config/opencode 查看一下目录下的配置文件

    修改opencode.json，使用shell: nano opencode.json

    文件内容修改为(这里以Kimi-k2.6演示)

    五 重新打开终端，运行opencode，在opencode输入框中/models，输入other，这里自定义API提供者，名称可以自定义为freeapi，下方要输入的API密钥在FreeAPI中生成获取,至此，你获得一个Agent智能体

    WIndows

    一. 到nodejs官网下载安装nodejs以及npm，运行npm i -g opencode-ai

    二. 进入目录，例如C:\Users\Administrator.config\opencode，修改或者配置文件opencode.json为

    重新打开cmd终端，运行opencode，在opencode输入框中/models，输入other，这里自定义API提供者，名称可以自定义为freeapi，下方要输入的API密钥在FreeAPI中生成获取填写，至此，你获得一个Agent智能体

  • 一次关于 Gitee AI 接口的实践-构建出拆除安全护栏的图像编辑站点

    最近在做一个拆除安全护栏的图像编辑站点时，顺手研究了一下 Gitee 提供的 AI 接口。起初的想法很直接，只是想把常用的功能整理成一个前端页面，方便自己调用，不用每次都打开官方站点反复操作。

    在实际使用过程中，一个比较明显的感受是：官方页面对输入内容的限制比较严格，而且这种限制并不完全取决于模型本身，而更像是请求进入系统之前就已经被过滤掉了。这一点在多次尝试“边界输入”之后，表现得很明显。

    出于习惯，我去看了一下它的请求过程。接口本身并不复杂，属于典型的图像生成 API，路径类似 /v1/images/generations，参数结构也和常见的 OpenAI 风格接口比较接近。确认这一点之后，其实整个事情的方向就很清晰了：页面只是一个入口，真正的能力在接口层。

    从页面调用到接口直连

    最开始的尝试是把页面中的请求直接提取出来，用脚本复现。这个过程本身没有什么难度，核心就是还原请求参数，包括 prompt、模型选择以及任务类型等。真正的差异出现在行为层面：在页面上会被直接拦截的请求，通过接口发送时，并不会完全按照相同的规则处理。虽然并不是完全没有限制，但可以明显感觉到约束条件的变化。

    这一步带来的一个直观结论是：系统的控制逻辑并不集中在单一层，而是分布在不同位置，而页面层承担了其中相当一部分。

    项目的基本结构

    基于这个观察，我把整个调用流程重新整理了一下，做成了一个独立的小工具。整体结构并不复杂，可以理解为一个典型的“前端 + 代理 + API”的组合：

    浏览器前端负责参数输入和结果展示
    中间通过一个简单的代理层转发请求
    后端则直接对接 Gitee 的 AI 接口

    这样的拆分，本质上是把原本封装在页面里的逻辑，拆成了几个更清晰的模块。

    前端部分：参数构造与任务控制

    前端的实现相对直接，主要负责两件事：一是构造请求参数，二是根据不同任务类型组织调用流程。

    在实际使用中，这里会涉及到几种不同的能力，比如文生图、图像编辑，以及图生视频等。虽然这些功能在官方页面中是分散的，但在项目里可以统一抽象成不同的 task 类型，通过参数切换来控制。

    这种方式的好处在于，可以更灵活地组合调用逻辑，而不受限于页面本身的流程设计。

    代理层：请求转发与访问控制

    浏览器无法直接调用目标接口，这是一个必须解决的问题。主要原因还是跨域和一些基础的访问限制。

    这里使用了 Cloudflare Worker 作为中间层，把前端请求统一转发到目标 API。实现上非常简单，大致就是把 /api/* 的路径映射到真实接口地址，然后透传请求。

    引入这一层之后，调用路径从“ 浏览器→ Gitee”变成了“浏览器 → 自己的代理 → Gitee”。从技术角度看，这一步并没有增加复杂度，但它改变了请求的“身份”，很多原本存在的限制也因此不再生效。

    下载模块：结果获取与资源转发

    生成结果返回的通常是一个资源地址，但这个地址在实际使用中并不总是稳定的。有些链接带有访问限制，有些则依赖特定的上下文环境。

    为了解决这个问题，项目中增加了一个简单的下载转发接口。逻辑是由代理先去请求目标资源，然后再返回给前端，由浏览器以 Blob 的形式处理。这样做的好处是，整个资源获取过程被统一收敛到了代理层，不再依赖客户端环境，也避免了很多不可控因素。

    多阶段调用：从单次请求到流程组合

    在基础功能实现之后，一个比较自然的延伸是把不同接口串联起来使用。例如先生成一张基础图像，再通过编辑接口进行局部调整，最后再进行进一步生成或扩展。

    从单次调用来看，每一步都是独立且正常的；但当它们组合成一个流程时，就会产生更复杂的效果。这种“多阶段调用”模式，在官方页面中并不明显，但在接口层是完全可行的。

    这也带来了一个有意思的问题：如果系统的控制逻辑主要基于单次请求判断，那么在面对组合流程时，覆盖能力就会明显下降。

    我个人关于Gitee AI云模型限制理解

    前端负责输入约束和用户交互
    接口层负责基础参数校验
    模型本身负责输出控制

    当只通过页面使用时，这三层是叠加生效的；但当绕开其中一层之后，整体行为就会发生变化。

    这并不是某一个具体实现的问题，而是一个比较典型的系统设计现象。如果某一层承担了过多的控制责任，那么它一旦被绕过，其它层是否足够补充，就会直接影响最终效果。

    一些总结

    这个项目本身我认为并不复杂，从实现角度看，更像是一个轻量级的接口代理工具。但在拆解和重构调用链的过程中，可以更直观地看到系统各个部分是如何协作的。

    相比直接使用现成页面，和接口打交道会暴露出更多细节，包括参数结构、调用方式，以及不同层之间的职责划分。这些信息在日常使用中往往是被隐藏起来的。

  • Friend

    朋友们的博客

    1.

    title: wuko’s blog
    description: 从零开始，由心而发。欢迎共同交流学习！
    website: https://blog.wuko.top
    image: https://blog.wuko.top/favicon.png

    2.

    title:KS_LM_KF的个人网站

    description: 发生甚么事了？

    website: https://www.kslmkf.com

    image: https://www.kslmkf.com/wp-content/uploads/2026/01/1768665269-308e9a4b85a47db29b756bb7f597d7fc-scaled.jpg

  • 无审查文本AI大模型站点部署

    有一个很苦恼的事情，在日常中我们总会遇到DeepSeek或者豆包告诉我们说“我目前还没有学会这个问题，我们换个话题聊聊吧…….”。可是我们并不希望AI拒绝我们，所以提示词注入出现了，我们使用了DeepSeek的所有模型，以及目前新开源的Glm5，对这些模型进行了提示词注入。当然，如果说的过于直白，有时候还是会触发AI的反驳和拒绝配合，不管怎么说，先来看看如何做吧。

    我的项目地址–Unlimited AI–在这里，已经内置了提示词注入。由于我发现了英伟达提供的大模型API是可以无限使用token(唯一缺点是比较慢)，所以我就想，是否可以借助Cloudflare Worker(防止网络环境不佳)来实现提示词注入+API调用呢？

    事实证明经过我七七四十九天的努力解决了这个问题。大模型的文本对齐强度不同，我发现DeepSeek和Glm5的对齐较弱，ChatGPT-oss-120b的对齐比较强，所以我们采取了不同的策略。前者使用模糊人物扮演来提示词注入，后者使用内部测试来尝试欺骗性提示词注入。结果很令人满意，都成功了。

    接下来看看部署的方式吧。首先Fork我的仓库。接着进入Cloudflare Worker创建一个Worker，选择刚刚Fork的GitHub仓库，点击部署。这里我们需要进入设置，填写我们的环境变量，NVIDIA_API_KEY这个环境变量建议使用”密钥”形式，防止被其他人获取到。完成API的填写后，我们重新部署一次这个Worker，至此，你也获得一个无审查文本AI大模型站点。

  • 世界，您好！

    欢迎使用 WordPress。这是您的第一篇文章。编辑或删除它，然后开始写作吧！