Feed 中的 AI 生成商品图片与描述：2026 年政策指南

<p>在 2026 年，我接触过的每一个电商团队都已经在商品目录的某个环节用上了 AI。换掉一张背景图。用一张商品白底图生成一个生活场景。一个下午就起草了三百条商品描述。工具到来的速度，比任何人的合规流程都快。</p>
<p>接下来就会出现一个问题，提问时通常还带着一丝担忧：<em>这会不会让我们被拒登？</em></p>
<p>坦白说，这个问题本身就问错了。并不存在一个您只需遵守就万事大吉的“AI 内容政策”。实际上有四套规则同时在起作用，而且它们对您的要求各不相同：</p>
<ol><li><strong>渠道内容政策</strong>——平台究竟允许商品信息中出现什么</li><li><strong>披露和元数据</strong>——您必须如何声明 AI 的参与，通常是以不可见的方式</li><li><strong>虚假陈述</strong>——素材是否准确呈现了包装盒里实际发出的商品</li><li><strong>法律</strong>——自 2026 年 8 月 2 日起，欧盟已有真正的成文法，并附带实实在在的罚款</li></ol>
<p>大多数遇到麻烦的商家并没有违反第 1 条。他们表面上是合规的，却因为一个自己都不知道存在的流程缺陷而在第 2 条上失败，或者因为生成式模型悄悄改变了商品的某些细节而在第 3 条上失败。</p>
<p>本指南将逐一介绍每个渠道和每套规则，最后给出真正能发现问题的操作检查。</p>
<hr />
<h2 id="section-1">简要版</h2>
<p>如果您只读一个部分：</p>
<ul><li><strong>Google 允许 AI 生成的图片和文字。</strong> 它要求机器可读的声明——图片使用 IPTC 元数据，文字使用专门的 Feed 属性。最常见的失败是元数据在生成工具到 Merchant Center 之间的某个环节被剥离。</li><li><strong>TikTok Shop 最为严格。</strong> 完全合成的商品主图渲染无论是否披露都不被允许。</li><li><strong>Meta 允许使用</strong>，遵循一般的准确呈现规则，但广告创意需要加上 AI 标签。</li><li><strong>欧盟《人工智能法案》现在又增加了一层面向买家的要求</strong>，适用于所有向欧盟销售的商家，叠加在上述所有要求之上。</li><li><strong>我们看到的几乎所有与 AI 相关的拒登，追根溯源都是普通的图片规则问题</strong>——促销叠加、水印、分辨率下限——而不是 AI 本身。</li></ul>
<hr />
<h2 id="1-google">规则 1：Google 的实际要求</h2>
<h3 id="iptc">图片：IPTC 元数据规则</h3>
<p>Google Merchant Center 在免费商品详情和付费购物广告中都接受 AI 生成和 AI 编辑的商品图片。自 2024 年初以来一直如此。并不存在需要绕开的禁令。</p>
<p>Google 要求的是，图片必须带有声明其来源的嵌入式元数据。实现机制是 IPTC 的 <code>DigitalSourceType</code> 属性，对电商而言有两个值很重要：</p>
<div class="overflow-x-auto rounded-[24px] border border-sand-200 bg-white [&_th]:bg-sand-50! [&_th]:px-4! [&_td]:px-4! [&_th]:py-3! [&_td]:py-3!"><table class="[display:table]! w-full! min-w-[560px] text-[15px]! leading-[1.45]"><thead><tr><th scope="col">值</th><th scope="col">何时使用</th></tr></thead><tbody><tr><td><code>TrainedAlgorithmicMedia</code></td><td>图片完全由生成式模型创建——根据文字提示或参考图片生成的商品图，底层没有原始照片</td></tr><tr><td><code>CompositeSynthetic</code></td><td>真实商品照片与生成元素的组合——这是电商中最常见的情况，涵盖围绕真实商品进行的背景替换、场景生成和环境更改</td></tr></tbody></table></div>
<p>该要求涵盖 <code>image_link</code>、<code>additional_image_link</code> 和 <code>lifestyle_image_link</code>。Google 自己的指南对失败模式说得很直白：不要从使用生成式工具创建的图片中移除 <code>DigitalSourceType</code> 等嵌入式元数据标签。</p>
<p>这条要求就是问题的全部关键，我们稍后还会回到这一点，因为一旦图片经过真实的生产流程，“不要移除”做起来远比听起来难。</p>
<p>Google 内置的 Product Studio 会自动写入该标签。如果您在其他任何地方生成图片——大多数规模化运营的品牌都是如此，因为 Product Studio 不支持批量处理，也无法在大型商品目录中保持一致的视觉风格——写入并保留这些元数据就是您的责任。</p>
<h3 id="structured-title-structured-description">文字：structured_title 和 structured_description</h3>
<p>这部分几乎没有人实施，但它自 2024 年 4 月起就已生效。</p>
<p>AI 生成的标题和描述不应放入普通的 <code>title</code> 和 <code>description</code> 属性中。Google 为它们专门创建了属性：</p>
<pre><code class="language-xml">&lt;g:structured_title&gt;
&lt;g:digital_source_type&gt;trained_algorithmic_media&lt;/g:digital_source_type&gt;
&lt;g:content&gt;Merino Wool Crew Neck Sweater - Men's, Charcoal, Size M&lt;/g:content&gt;
&lt;/g:structured_title&gt;

&lt;g:structured_description&gt;
&lt;g:digital_source_type&gt;trained_algorithmic_media&lt;/g:digital_source_type&gt;
&lt;g:content&gt;Full description text here.&lt;/g:content&gt;
&lt;/g:structured_description&gt;</code></pre>
<p>有两个细节常常让人栽跟头：</p>
<p><strong>省略 <code>digital_source_type</code> 本身就是一种声明。</strong> 如果您提交的 <code>structured_title</code> 只有 <code>content</code> 子属性，就等于告诉 Google 该内容<em>不是</em> AI 生成的。在这里，沉默并不是中立。</p>
<p><strong>如果两者都提交，普通属性优先。</strong> 当 <code>title</code> 和 <code>structured_title</code> 同时存在时，Google 使用 <code>title</code>。因此，填写了结构化属性却保留原来由 AI 撰写的 <code>title</code>，除了让文件更大之外毫无作用。</p>
<p>做好这件事是一个映射问题，而不是文案问题——这正是 <a href="/zh-CN/feed-rules">Feed 规则</a>的用武之地。如果您的描述在一个系统中生成，而 Feed 在另一个系统中组装，规则层就是在数值流转过程中标记来源的地方。</p>
<h3 id="google-ai">那么，Google 会惩罚 AI 内容吗？</h3>
<p>不会因为它是 AI 生成的而惩罚。Google 对生成式内容的立场多年来始终如一：关注的是输出质量，而不是作者是谁。让商家中招的垃圾内容政策是<strong>规模化内容滥用</strong>——主要为了操纵排名而大量发布低价值内容——无论是人工撰写三百条单薄的描述，还是模型撰写，该政策都同样适用。</p>
<p>在 Merchant Center 中真正会造成影响的政策是<strong>虚假陈述</strong>。而在虚假陈述方面，AI 确实会提高您的风险，原因与政策无关，而完全在于语言模型的工作方式：它们会以看似合理的方式填补空白。</p>
<p>让模型为一件夹克撰写描述，却只给它一条信息单薄的源记录，它就会自信满满地写出面料克重、防水性能和版型。这些句子可能是错的。您的着陆页上写的是防泼水，生成的文案却写着防水。这种不一致既是政策违规，也是退货问题，而且当它出现时，看起来不会像 AI 问题——它会看起来像商品数据问题。</p>
<p>缓解措施并不光鲜：基于完整的源数据生成，而不是基于单薄的源数据。被约束在真实属性值范围内的模型，比被要求对一件它一无所知的商品大加推销的模型，编造的内容要少得多。这让商品目录的完整性成为一项合规控制措施，并将工作前移到<a href="/zh-CN/feed-optimization">商品目录丰富</a>环节。</p>
<hr />
<h2 id="2">规则 2：其他渠道</h2>
<h3 id="meta">Meta</h3>
<p>Meta 的商务政策管理商品目录中的商品信息，其核心是准确呈现商品——对于商品目录图片，并没有针对 AI 的专门禁令。相关要求出现在广告方面：对于 AI 生成或经过大幅修改的广告创意，Meta 要求加上 AI 内容标签。</p>
<p>对于投放目录广告的商家来说，实际影响是：即使描绘的是同一件商品，您的 Feed 图片和广告创意也可能适用不同的规则。如果您正在根据 Feed 数据生成动态创意——这正是 <a href="/zh-CN/creative-suite">Creative Suite</a> 的用例——需要检查的是广告方面的标签要求，而且它应该放在您的创意模板配置中，而不是 Feed 映射中。</p>
<p>有关当前商品目录字段要求，请参阅我们的 <a href="/zh-CN/integration/meta">Meta 集成指南</a>。</p>
<h3 id="tiktok-shop">TikTok Shop</h3>
<p>TikTok 是主要渠道中最严格的一个，也最有可能让那些以为 Google 的规则具有代表性的团队感到意外。</p>
<p>TikTok Shop 的商品刊登政策禁止使用占位图和商品的数字渲染图。因此，完全合成的商品主图是不被允许的——披露也无法补救。真实商品的 AI 编辑照片是允许的，但根据 2026 年 5 月生效的 AI 生成内容规则，重大修改需要披露。</p>
<p>界线在哪里：轻度的 AI 辅助编辑——色彩校正、清理瑕疵、去除背景——通常被视为普通的后期制作。当 AI 生成了图片的实质内容时——一个并不存在的模特、一个从未发生过的场景——就需要披露。</p>
<p>这对设计有着实际影响。如果您的创意工作流程从真实的商品照片出发，并<em>围绕</em>它进行生成，那么您在每个主要渠道上都符合规则。如果它生成的是商品本身，TikTok 就对您关闭了。</p>
<h3 id="section-9">土耳其及区域性渠道</h3>
<p>对于在 Trendyol、Hepsiburada、Akakçe、N11 或 Çiçeksepeti 上销售的商家来说，与全球性平台相比，已公布的 AI 内容政策少之又少，甚至根本没有。但这并不意味着风险更低——平台关于水印、叠加、边框和准确呈现的图片规范仍然适用，而且它们本身就能拦下大多数糟糕的 AI 输出，根本无需提及 AI。</p>
<p>我们对土耳其渠道的工作假设是：遵守最严格的适用全球标准，因为这比维护两套素材更便宜，也因为这些政策终将趋同。如果您向 <a href="/zh-CN/integration/akakce">Akakçe</a> 或土耳其电商平台导出数据，那么下一节中的标准图片规则，就是您今天就应该对照审核的内容。</p>
<hr />
<h2 id="3">规则 3：欧盟《人工智能法案》</h2>
<p>这项法规足够新，大多数已发布的指南都早于它。</p>
<p>欧盟《人工智能法案》第 50 条规定了 AI 生成和 AI 篡改内容的透明度义务，这些义务已于 <strong>2026 年 8 月 2 日</strong>开始适用。它们独立于该法案的高风险制度——只要 AI 系统创建或篡改图片、音频或视频内容，无论风险等级如何都适用。</p>
<p>对商品目录而言，重要的是：</p>
<p><strong>它面向买家，而不仅仅是元数据。</strong> Google 的 IPTC 要求是机器可读的，购物者看不到。第 50 条要求披露必须清晰、可辨识，并且最迟在首次接触时提供。图片上一个若隐若现的标签，或埋在条款中的一行字，都达不到这一门槛。</p>
<p><strong>辅助性编辑通常不在范围之内。</strong> 放大分辨率、色彩校正和基本的光线调整，通常被视为辅助性而非生成性的。当 AI 创建或实质性改变内容时，才会产生该义务。</p>
<p><strong>域外效力。</strong> 设立在欧盟以外的部署者，只要其输出在欧盟境内使用，也在适用范围内。向欧盟销售的土耳其或英国商家同样受其约束。</p>
<p><strong>已有标准标签可用。</strong> 2026 年 6 月，欧盟委员会发布了一套用于标注 AI 生成内容的免费图标，区分完全由 AI 生成的内容和部分经 AI 修改的内容。采用与否是自愿的，但它很可能成为实际上的基准。</p>
<p><strong>罚款金额可观。</strong> 违反第 50 条的处罚最高可达 1,500 万欧元或全球年营业额的一定比例，以较高者为准。</p>
<p>Google 已经采取措施予以配合。AI 内容标签设置已陆续在 Google Ads、Display &amp; Video 360、Campaign Manager 360、Merchant Center 和 Ads Editor 中推出，Google 也已确认，这些标签不会被视为违反其禁止文字叠加和水印的政策——这是一项重要的例外，因为否则商品图片上可见的 AI 标签恰恰就是会触发拒登的那种叠加。</p>
<p>Google 也明确表示，使用其标签设置并不能保证符合监管要求。这是需要咨询您的法律顾问的问题，而不是 Feed 工具的问题。Feed 工具应该做的，是让您能够为商品目录中正确的子集加上正确的标签——这首先需要知道哪些素材是 AI 生成的，而这就引出了真正会出问题的部分。</p>
<hr />
<h2 id="4">规则 4：流程问题</h2>
<p>这是我们最常见到的失败模式，而在拒登出现之前，它一直是隐形的。</p>
<p>您的生成工具写入了正确的 IPTC 元数据。随后，您的图片会经过：</p>
<pre><code>generator → asset store → resize/crop job → format conversion → CDN → feed export</code></pre>
<p>默认情况下，元数据无法在这段旅程中幸存。图片缩放库会剥离它。WebP 转换会剥离它。CDN 转换流程更是会大力剥离它，因为元数据就是字节，而它们存在的全部意义就是去掉字节。等到您 <code>image_link</code> 属性中的 URL 解析为一个文件时，Google 要求的声明可能已经不见了——而您技术栈中的任何地方都不会报错。</p>
<p>此时，尽管您的生成流程完全合规，商品目录中的每一张 AI 图片却都已不合规。</p>
<p><strong>如何检查。</strong> 获取一个与 Feed 中完全一致的在线图片 URL——不是源文件，而是渠道实际抓取的 URL——并检查其元数据：</p>
<pre><code class="language-bash"># ExifTool, most reliable
exiftool -DigitalSourceType product-image.jpg

ImageMagick

identify -verbose product-image.jpg | grep -i digitalsource</code></pre>
<p>每条流程路径测试一张图片。如果您通过不同的转换提供不同的格式或尺寸，每条路径都需要单独检查，因为它们会各自独立地出问题。</p>
<p><strong>如何修复。</strong> 配置转换步骤以保留 IPTC——大多数工具都支持一个默认关闭的复制元数据选项。如果 CDN 无法配置，就在转换后重新注入元数据。此外，还要对在线 URL 样本定期进行验证，因为 CDN 配置可能会被从未听说过 <code>DigitalSourceType</code> 的人修改。</p>
<p>这也是要将来源信息保存在 Feed 记录中、而不仅仅保存在文件中的原因。如果您的 Feed 知道哪些商品带有 AI 生成的素材，您就可以据此采取行动——对其进行细分、加标签、将其排除在不允许此类内容的渠道之外——而不必依赖元数据是否在流程中幸存。这是 <a href="/zh-CN/feed-rules">Feed 规则</a>的工作，也是“我们认为其中大部分没问题”与一个可审计的答案之间的区别。</p>
<hr />

真正导致拒登的原因

值得直白地说一句，因为在这个话题上，人们的焦虑放错了地方：图片违规一直是 Merchant Center 中商品被拒登的最常见原因之一，而其中绝大多数与 AI 毫无关系。

AI 输出往往会违反的规则——因为生成式工具的优化目标是制作吸引人的营销图片，而吸引人的营销图片恰恰是 Feed 政策所禁止的：

最后一行值得强调。一张从未出现在网站上的生成主图就是一种不一致，这也是商家“修复”图片后商品仍处于拒登状态的较常见原因之一。

关于 500×500 的变化：Google 表示，作为一项安全措施，它将使用 AI 自动放大部分低于门槛的图片，放大后的图片无需您采取行动即可满足要求。请把它当作兜底措施，而不是计划。您不会希望由一台机器来决定您的商品长什么样。

在整个商品目录中手动运行这些检查是不现实的。我们的免费 Feed 审核工具会标记您在线 Feed 中的分辨率、叠加和属性问题，而 Feed Protection 则会在导出数据到达渠道之前（而不是之后）发现这些问题。

不越界的工作流程

围绕商品生成，而不是生成商品。 从真实照片出发。替换背景、构建场景、添加季节性造型——但不要动商品本身的像素。仅这一条约束，就能让您在包括 TikTok 在内的每个主要渠道上保持合规，并消除大部分虚假陈述风险，因为所销售的东西仍然是被拍摄的那件东西。

发布前切换对比测试。 以全尺寸在生成图片和源照片之间来回切换。如果 Logo 移位、接缝消失、颜色偏移、肩带变了样，或者冒出了某个功能——就拒绝使用。这只需几秒钟，却能发现那些可能让您的账户付出代价的错误。

绝不让生成的场景暗示您不随附的配件。 在一个水壶周围生成厨房场景，却包含您并不销售的配套套装，这就是虚假陈述，也是退货问题和差评问题。

使用模板，而不是逐个制作。 在整个商品目录中应用一个经过审核和批准的模板，您需要审核的就只有一样东西，而不是一万样。顺便说一句，这也是创意制作不再受制于人力的方式——Karaca 在两小时内制作了 10,000 个品牌化的黑色星期五创意，所用的只是一个映射到 Feed 字段的已批准模板。合规的理由与效率的理由指向同一个方向。

在 Feed 中保留来源信息。 标记哪些商品带有 AI 生成的素材，哪些带有 AI 生成的文字。您需要这些信息来处理 structured_title、欧盟标签、将商品排除在 TikTok 之外，以及在有人询问时作出回答。在已上线的商品目录中事后补充这些信息很痛苦；在数据接收时添加则几乎没有成本。

文字内容始终要人工审核。 不是全文重写，而是对照真实属性值进行事实核查。需要具体核实的，正是模型会自信地编造的那些内容：材质成分、尺寸、兼容性、防水性能、护理说明、包装内容。

按计划核验在线 URL 的元数据。 不是源文件，而是渠道抓取的 URL。至少每季度一次，并在任何 CDN 或图片流程变更之后进行。

什么情况下根本不应使用 AI 图片

这是坦诚的一节，因为答案并不总是肯定的。

当准确的颜色就是购买决策的关键时。 油漆、化妆品、纺织品、家具软包面料。生成式的颜色偏移细微而系统，它会先出现在您的退货数据中，然后才出现在政策通知中。Vivense 的家具商品目录就是一个很好的例子：在这类商品中，变体矩阵中面料和饰面的准确性比创意的多样性更重要。

受监管类目。 保健品、医疗器械、带有功效声明的化妆品。任何暗示物理效果的生成图片在每个渠道上都是问题，而且有几个平台会对这些类目施加特别严格的审查。

当您无法回答“改了什么”时。 如果您的工作流程无法记录哪些素材是生成的、是如何生成的，您就无法遵守披露要求，也无法应对政策质疑。先建立记录，再扩大生成规模。

当真实照片本来就很好时。 AI 值得用在摄影无法规模化的地方——季节性变体、广告活动重新造型、为上千个 SKU 制作生活场景。用它来替换一张效果良好的主图，并不值得。

结论

这里的合规负担是真实存在的，但在概念上并不难。它是一个披着政策外衣的数据溯源问题：知道哪些素材是生成的，让这一信息始终附着在商品记录上，确保声明能够完整送达渠道，并检查那些无论内容出自谁手都能拦下糟糕输出的普通规则。

在 2027 年陷入困境的商家，不会是那些使用 AI 的商家。而是那些大规模使用 AI 却没有记录自己做了什么、如今无法回答一个关于自己商品目录的简单问题的商家。

来源

• Google Merchant Center 帮助中心——AI 生成的内容：https://support.google.com/merchants/answer/14743464
• Google Merchant Center 帮助中心——商品数据质量违规：https://support.google.com/merchants/answer/13693497
• Google 搜索中心——关于生成式 AI 内容的指南：https://developers.google.com/search/docs/fundamentals/using-gen-ai-content
• 欧盟委员会——AI 生成内容透明度行为准则：https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
• 欧盟《人工智能法案》——第 50 条透明度规则：https://artificialintelligenceact.eu/transparency-rules-article-50/