AI 生成图片 API 怎样区分文本到图像与图像编辑

AI 图片 API 的区别不在于提示词里有没有“修改”二字，而在于模型实际收到什么输入。文本到图像主要根据文字描述生成画面；图像编辑需要把已有图片作为条件交给支持该能力的模型。只上传文件却没有把它传给推理接口，不能算完成了编辑。

Hugging Face 官方文档入口：https://huggingface.co/docs/inference-providers/。下面以它的任务划分解释概念，资源表和失败处理则是应用侧设计建议，不是平台统一规定，也不代表实际调用结果。

先看请求里有没有需要保留的原图

先把用户需求改写成一句可以判断的约束。例如，“画一个蓝色陶瓷杯”没有指定已有原图，可以选择文本生成；“把这张杯子的背景换成浅灰色，杯身轮廓尽量保持”依赖原图，应选择支持图像编辑的能力。

Hugging Face 将根据文字产生图片列为 text-to-image，将以源图为基础进行变换列为 image-to-image。后者可以涵盖多种图像变换，但不等于每个模型都同时支持局部修补、多图参考和精确保留。参见文本生成任务说明和图像变换任务说明。

在需求阶段写清“必须保留什么、允许改变什么”。如果要求背景完全一致或商品文字一个字符都不能变，不要仅凭“编辑”这个名称承诺效果；生成式编辑仍须结合具体模型能力判断，必要时由确定性图像处理承担严格不变部分。

按模型能力接收图片，不把上传当成编辑

接入时按“提供商、模型、任务、参数”这一组组合确定请求。模型名称相近并不证明任务相同；同一模型在不同提供商上的参数映射也可能不同。先读所选组合的调用文档，再决定传文件字节、编码内容或资源地址，不要把这三种形式当成可以任意互换。

这里应区分两个独立事实：上传成功说明应用有了文件；推理请求包含该文件，才说明它参与了本次任务。建议在应用内部明确保存任务模式、输入资源标识和编辑指令。模式为编辑而输入资源缺失时，在应用内报错，不把请求悄悄转换成文字生成。

接收图片的应用还应限制文件大小、解码后的像素规模、允许的格式和用户访问权限。这些是服务自身的输入边界，不是本文给出的厂商限额。浏览器报告的文件类型只是一条线索，不能代替服务端实际解析。访问远程图片时，也应限制来源，避免让后端无条件访问任意用户提供的地址。

为原图和生成结果保存不同的资源记录

把“任务”和“图片”放进同一条记录，容易出现再次编辑覆盖原图的问题。更稳妥的方式是拆成三类对象：任务记录、原图资源和结果资源。

任务记录保存所属用户、任务模式、所选模型和提供商、输入资源标识、请求状态以及实际返回的请求标识。图片资源保存自己的资源标识、存储位置、媒体类型、尺寸、访问权限和保留策略。结果资源再通过来源任务标识关联到任务；如果来自编辑，任务同时关联输入原图。

例如，原图资源为 source-cup，编辑任务为 edit-background，结果资源为 result-cup-gray。这些名称只是教学用标识。用户决定继续修改 result-cup-gray 时，新任务应把它当成新的输入资源，原图 source-cup 不因此被覆盖。

提示词可以作为受限任务元数据保留，但不应把敏感图片内容、带签名的访问地址或完整凭据直接写进普通日志。只有业务需要时才存储相应数据，并明确谁能查询和何时删除。索引设计可优先覆盖“用户与创建时间”和“来源任务”，方便找回版本而不必扫描全部图片。

按结果类型提供预览和再次编辑

页面展示图片，并不代表 HTTP 响应一定是图片网址。Hugging Face 上述任务文档描述了图片字节响应，示例 SDK 则把结果呈现为 PIL.Image 对象。这里要区分传输层数据与客户端已经解码的对象，不应把对象直接当作可长期保存的下载链接。

建议在提供商适配层将各自返回形式转成应用自己的结果资源：先识别实际返回类型，完成相应接收或解码，再持久化文件并登记资源记录。若另一个提供商返回临时下载地址，应按它的契约接收结果，不要假设地址永久有效；若使用异步任务接口，应保留任务状态，不能把“已接收”显示成“已生成”。

前端只拿应用授权的资源标识或访问地址用于预览和下载。再次编辑按钮绑定的是结果资源，而不是界面上的缩略图地址。缩略图可能经过缩放，不应在用户不知情时替代高分辨率原始结果成为下次编辑输入。

模式不支持或请求超时时不要偷换任务

失败原因应保留足够细节。模型不支持当前模式、图片无法解析、参数不被接受，与网络超时是不同问题；前几类应修正请求条件，而不是更换提示词反复提交。Hugging Face 的InferenceClient 文档列出了各方法的签名和异常，接入时应按实际方法处理。

客户端超时只说明调用方没能及时获得完整结果，不足以证明远端没有开始生成。应用可以记录“结果未确认”，向用户说明需要等待或主动重试；只有提供商提供查询或幂等机制时，才能按其文档利用对应能力。不要凭空添加一个通用幂等字段，就宣称不会重复计费。

尤其不要在编辑失败后自动切换成文字生成。这样可能返回一张看起来相似、但与原图无可靠关联的新图，破坏用户的保留要求。需要降级时，先明确告知“将重新生成，无法保证延续原图”，让用户选择，而不是把新图当作编辑成功。

清理临时文件时保留用户仍在使用的版本

清理策略要区分上传暂存文件、推理中间资源和用户已经保存的成品。上传后未被任务引用的临时文件可以设置较短保留期；仍被活动任务读取的输入文件不能按普通临时文件直接清除。删除成品时也要处理缩略图、缓存和访问链接，但不应因此顺手删除仍被其他任务使用的输入版本。

一种可落地的清理方案是：资源记录维护引用关系与删除状态；清理任务先挑出达到保留期、未被活动任务或用户保留版本引用的对象，再删除存储文件并更新记录。保留期由业务约定，本文不提供可套用到所有服务的天数。访问地址过期与底层文件删除也应分别处理。

提示词写“修改这张图片”，就会自动进入编辑模式吗？

不会。需要应用选择正确能力并实际传入图片；文字本身不会把不存在的图片带给模型。

编辑一定需要蒙版吗？

不一定。有些能力根据整图和文字指令编辑；只有明确支持区域蒙版的接口，才按其规范传递蒙版。不要跨接口照搬字段。

文本生成与编辑可以共用结果表吗？

可以共用图片资源表和展示组件，但任务必须保留模式与输入引用。共用输出结构，不等于把输入契约合并成一个模糊的“图片请求”。

选择模式时看输入条件，调用接口时看能力组合，保存结果时看资源身份。把这三件事分清，才能既保留原图，又让用户知道每张新图从哪里来、还能否继续编辑。