GPT Image 2 出图出现脏点、碎纹、重复花纹或“假细节”时，先别把所有问题都归结为 quality: "low"，也别立刻给提示词堆“干净、高清、无噪点”。最有效的第一步，是保存原始输出并给症状分型：整体细节少、原图就有重复伪影、编辑后才变脏、还是上传后才出现压缩痕迹。
OpenAI 当前把 quality、size、输出格式与压缩列为可控项，同时也明确列出文字渲染、一致性和构图控制等限制；官方文档并没有给“脏纹、铺纹、白点”指定一个通用根因，也没有承诺某个档位能一键修复。因此，下面的目标不是猜中模型内部发生了什么，而是用最少的对照确定：问题在哪一层出现，下一步该改什么，以及什么时候应该停手。
先给结论：别把低画质和伪影混成一件事
quality: "low" 适合草稿、缩略图和快速迭代。它可以解释“整体细节较少”，却不能自动解释跨区域重复的纹理、成片白点、棋盘状铺纹或编辑多轮后的覆盖感。若这些症状在 medium 或 high 仍出现，就应进入伪影排查，而不是继续把质量档位当作唯一答案。
先做三件事：保存未经转换的原始文件；记录生成入口、模型标签、quality、size 和参考图；在 100% 视图与最终展示尺寸各看一次。只看网页小预览，会把生成缺陷、浏览器缩放和发布压缩混在一起。
症状到检查项：先定位可控层
下面这张表既是分类器，也是停止猜测的起点。每一行只给“先查什么”，不把相关性写成根因。
| 可见症状 | 第一检查项 | 只做一次的动作 | 可以得出的结论 | 不能得出的结论 |
|---|---|---|---|---|
| 整张图偏软，但没有重复花纹 | quality、size、原始文件 | 固定其他条件，只把 low 改为 medium | 这一个样本是否随质量档位改善 | high 一定能消除所有伪影 |
| 原始文件干净，上传后变糊或有块状噪点 | 输出格式、压缩、CMS 转换 | 对比原图与发布文件的尺寸和格式 | 问题是否出现在交付链路 | 模型本身画质差 |
| 无关区域反复出现白点、碎纹、棋盘或铺纹 | 原始输出、参考图、编辑状态 | 保存原样本，再做一轮干净输入对照 | 症状是否能在更窄条件下复现 | 已确认某个模型内部机制 |
| 只在参考图或连续编辑后变脏 | 输入图、mask、上一轮输出 | 固定 prompt 和设置，移除一项输入再比 | 该输入是否与当前样本相关 | 参考图必然污染后续生成 |
| 只有文字、Logo、重复角色或版式失控 | 任务约束与模型限制 | 把它从噪点记录中单列 | 这是另一类验收问题 | 调高分辨率就会自动修好 |
| 只有某个封装入口出现问题 | 入口标签、模型映射、默认压缩 | 在同一入口先锁定可见参数 | 这个入口下的结果是否稳定 | 所有 GPT Image 2 路线都相同 |
社区帖子里常见“污点、过密细节、重复图案、棋盘感、迭代后变脏”等描述。这些报告能说明症状并非只有一种叫法，却不能证明同一个根因。有人认为新请求有帮助，也有人在新请求或 API 调用里仍遇到相似现象；这类冲突正是需要单变量对照的原因。
怎样做一次只改一个变量的对照
一次有效对照必须固定 prompt、输入图、生成入口、模型标签和 size，只改一个当前可见的质量控制项。例如在 Image API 中只把 quality 从 low 改成 medium；不要同时换提示词、删参考图、改尺寸、换入口，否则即使结果变好，也无法知道哪一步起作用。
建议把两次结果并排填进这张记录表：
| 字段 | A 组 | B 组 |
|---|---|---|
| 生成表面与模型路线 | 写清 Image API、Responses API、ChatGPT 或具体封装入口 | 与 A 组完全相同 |
| prompt 与输入 | 保存原文、参考图和 mask | 与 A 组完全相同 |
| size | 记录精确尺寸或界面显示值 | 与 A 组完全相同 |
| quality | 例如 low | 例如 medium；本轮唯一变化 |
| 原始输出 | 保存未经上传和转换的文件 | 保存未经上传和转换的文件 |
| 观察位置 | 100% 视图、最终展示尺寸、暗部、边缘和重复区域 | 使用同一检查位置 |
| 结果 | 记录整体细节、白点、重复纹理、边缘与文字 | 记录同一组症状 |
| 停止条件 | 两组均不合格就停止把档位当作唯一解释 | 保存证据并转下一条分支 |
如果 B 组更干净，只能说“这个样本在当前入口和设置下随 quality 变化”，不能推广成万能修复。如果 A、B 两组出现同一种铺纹，就保持质量档位不动，另开一轮对照只移除参考图；再下一轮才考虑会话状态或交付转换。每轮只动一个变量。
官方控制项能证明什么
OpenAI 图像生成文档当前列出的 gpt-image-2 质量选项是 low、medium、high 和 auto。size、quality 与 background 可使用 auto；PNG 是默认输出格式，JPEG 与 WebP 可设置压缩。文档还说明，超过 3,686,400 总像素的输出属于实验范围。实验范围不等于“更差”，也不等于“像素越多越好”，它只提醒你不要把大尺寸当作稳定性保证。
Image API 与 Responses API 也不是同一个测试表面。Image API 直接选择 GPT Image 模型；Responses API 由主模型调用图像生成工具，工具负责 GPT Image 模型选择。若你在两者之间切换，改变的不只是一个质量值，所以应把它记成“路线对照”，不要和 quality 对照混在同一轮。
官方限制说明覆盖文字清晰度、重复角色或品牌元素的一致性，以及精确构图控制。若失败集中在小字、Logo、角色一致性或严谨版式，应按这些限制验收，不要统称为噪点，也不要期待降噪提示词解决结构错误。
先排除发布压缩，再怀疑生成结果
原图和发布图必须分开看。PNG 转成低质量 JPEG/WebP、社交平台二次压缩、CMS 缩放和浏览器插值，都可能制造块状纹理、边缘振铃或整体发软。
按这个顺序检查：
- 打开生成后直接保存的原始文件，记录像素尺寸与格式。
- 打开最终页面或平台下载回来的文件，记录同一组信息。
- 在相同缩放比例下比暗部、渐变、细线和文字边缘。
- 原图干净而发布图变差时，修转换链路；不要继续消耗生成次数。
如果原图已经有重复纹理，再去看质量、输入与编辑状态。这个顺序能避免拿发布压缩后的截图去判断模型。
参考图和连续编辑只是一条待验证分支
社区中有人报告参考图、图生图或多轮编辑后伪影更明显，但这不是 OpenAI 已确认的统一机制。正确做法不是宣布“上下文污染”，而是把输入继承变成可观察变量。
先保存当前失败样本。下一轮保持 prompt、入口、模型标签、quality 和 size 不变，只移除参考图或换回未经反复编辑的底图。如果症状消失，结论仍然是“这项输入与本次结果相关”；若症状继续存在，就不要把参考图当作唯一原因。
新聊天或新 API 请求也只能作为隔离条件。它能减少旧输入与旧指令，但“新请求变好”不等于已经找到模型根因，“新请求仍坏”也不等于所有用户都会遇到同一问题。
在 YingTu 中只能做平台内手动对照
YingTu 当前公开可见的是 gpt-image-2-vip，质量选项为手动的 low、medium 和 high。它不是 OpenAI 官方 gpt-image-2 表面，也没有经过验证的自动伪影诊断或去除功能。
若你已经在这个界面工作，可以按上面的记录卡做一次平台内对照：固定 prompt、参考图、size 和 gpt-image-2-vip 路线，只改一个 quality 值。这个结果只说明该平台内的当前样本，不能证明上游接受所有参数组合，也不能代替 Image API 或 Responses API 的官方行为说明。
什么时候继续，什么时候停手
继续下一条分支的条件很简单：上一轮只有一个变量发生变化，而且原始文件已保存。以下情况应立即停手：
- 同一轮同时改了 prompt、尺寸、参考图和入口，结果无法归因；
- 只有发布文件变差，生成原图本身正常；
- 连续两组受控对照都不合格，却仍把素材当成最终交付；
- 文字、Logo 或构图错误被误记成噪点；
- 只凭社区说法或第三方教程宣布了模型根因；
- 用一张预览图声称某个修复对所有场景有效。
受控对照仍复现相同症状时，保留 prompt、输入图、模型标签、quality、size、生成表面、时间和原始文件。开发者还应保存请求 ID 与错误信息。然后把问题反馈给对应官方或服务提供方，而不是继续无上限重生成。
若问题只在大尺寸暴露，下一步看 GPT Image 2 4K 尺寸与文件验证指南，把“尺寸是否合规”和“内容是否有伪影”分成两个验收任务。
三个常见判断
high 会自动消除脏纹和噪点吗
不会。high 值得作为最终质量对照，但官方没有把它描述为通用伪影修复。它若改善了当前样本，也只能证明这次对照中的相关性。
新聊天为什么有时看起来更干净
新聊天减少了旧图片与旧指令，是一个有用的隔离条件。但社区报告并不一致，所以它应是一轮单变量测试，而不是已确认根因或永久修复。
4K 更容易出现伪影吗
大尺寸会让细小纹理、边缘、文字和重复图案更容易被看见；这不等于 4K 必然制造伪影。先比较原始文件与同条件尺寸对照，再决定问题属于生成、检查尺度还是发布转换。
真正可靠的排查结果，不是“我换了很多设置终于有一张能用”，而是“我知道哪一层出现问题、哪一个变量与当前样本相关，并且知道何时不再继续猜”。
