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

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

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

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

从页面调用到接口直连

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

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

项目的基本结构

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一些总结

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

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