O que 抖音商品主图违规预审 faz?
目标：在商家上传主图之前，找出会被抖音电商驳回、限流或处罚的内容，说清楚依据，并给出能直接替换的写法。
有两个前提要始终记住，报告里也要让用户知道：
- 这是预审，不是平台审核。 平台会结合宣传的整体语境、商品真实参数、商家能拿出的证明来判定。同一句话，有检测报告时可能合规，没有时就违规。所以很多结论取决于用户的真实情况，要问清楚或标出来。
- 规则有日期。 本 skill 的规则整理于 2026-11-07（见 frontmatter 的
rules-updated）。抖音规则更新频繁，拿不准或用户有疑问时，以抖音电商学习中心的最新原文为准，链接在references/sources.md。
规则文件
按需读取，不要一次全部读进来：
| 文件 | 什么时候读 |
|---|---|
references/main-image-rules.md | 每次都读。主图规格、首图要求、禁止出现的画面 |
references/claim-rules.md | 每次都读。文案类违规：效果承诺、极限词、需要证明的宣传、价格、站外导流 |
references/cases.md | 每次都读。已确认的驳回案例，同类写法直接参照 |
references/private-cases.md | 文件存在就读。用户自己积累的驳回案例，只保存在本地 |
references/category-security-camera.md | 商品是摄像头、监控、安防设备时读 |
references/category-template.md | 要为新类目整理规则时读 |
references/sources.md | 需要给出规则原文链接，或用户问「依据在哪」时读 |
目前只收录了安防监控一个类目的专项规则。其他类目先用通用规则检查，并在报告里注明「暂未收录该类目的专项规则」，建议用户查看学习中心里该类目的《行业管理规范》。如果你能上网，可以提出帮用户整理一份新的类目规则文件。
检查流程
1. 弄清检查对象
从对话里找这些信息。缺的先用默认值，不要因此停下来不检查：
- 类目：从图片判断。判断不了就问一句，同时先用通用规则检查。
- 第几张：用户没说就按发来的顺序，第 1 张按首图标准检查。首图要求最严。
- 商品真实参数：比如分辨率和像素、电池容量、是否含太阳能板、各 SKU 的配置、流量和云存储政策、有没有检测报告。很多宣传是否违规，取决于它和实际是否一致。用户没提供的，相关问题标 🟡，并在报告末尾的「需要你确认」里列出。
- 是不是原图：聊天里粘贴的图片可能被压缩、裁剪或转了格式。尺寸、比例、格式这类结论如果不是基于原图，降为 ⚪，提醒用户以上传到抖店的原图为准。
2. 看图，把文字全部读出来
每张图做三件事：
- 规格：如果你能运行命令，读取图片真实的像素尺寸和文件格式，用什么工具都可以。不能运行就跳过，报告里写「未读取原图规格」。
- 画面：商品主体在哪里、占多大、是实拍还是渲染图或 AI 图；有没有二维码、水印、边框、播放键、人物、尺寸对比物、地图、其他品牌或平台的标志、敏感元素。效果展示图和对比图要特别留意是不是本机实拍。图标也要看，它们同样会被当成宣传（例如 4G 摄像头配了 WiFi 图标）。
- 文字：按区域（左上、中间、右侧、底部横条……）逐字抄下图上的全部文字，包括角标、小字和图标旁的说明。看不清的字写成「[看不清]」，不要猜：猜错一个字，结论可能就反了。
3. 对照规则逐条检查
- 每一句文案，对照
claim-rules.md和类目文件。 - 每张图的画面和规格，对照
main-image-rules.md。 - 图文对照：宣传语和同一张图里的配图、步骤图、参数表是否矛盾。例如大字写「免打孔」，安装步骤图里却在用螺丝和膨胀管固定支架。
- 跨图检查：同一个卖点在不同图里的说法是否一致；主图展示的配置（例如「双摄」「含太阳能板」「8000mAh」）是不是每个 SKU 都有。只要最低价 SKU 没有，就属于价格违规里的「低价 SKU 作弊」。
- 对照案例：和
cases.md、private-cases.md里已被驳回的写法同类的，按 🔴 处理，并注明「与案例 XXX 同类」。
4. 分级
按「依据有多硬」分级，而不是按「问题有多严重」：
- 🔴 明确违规，满足任意一条：
- 规则原文或官方示例点名禁止的词、写法或画面；
- 对效果、性能或服务做出不带条件的绝对性、保证性承诺。《商家【虚假宣传】细则》4.2 明确禁止这一类，例如「永不断电」「无死角」「100% 识别」；
- 图里的配图、步骤或参数已经证明这句宣传不成立；
- 与已确认的驳回案例属于同一种写法。
- 🟡 经验风险：规则没有点名，但属于同一类风险；或者是否违规取决于用户能不能拿出依据（检测报告、专利号、授权书、参数一致）。要写明「有依据可以保留，没有就按 🔴 改」。
- ⚪ 可能误判：你拿不准的情况，包括看不清的字、可能被误伤的行业通用词、只出现在网上非官方词表里的词、基于非原图得出的规格结论。
一句话同时踩了几条规则，合并成一行，依据都写上。不要为了显得全面，把正常的描述硬判成问题：误报太多，用户就会忽略真正要改的地方。
5. 给出改法
改法要能直接复制使用，方向就是平台对商家的要求：「是啥写啥」。
- 把承诺改成描述，把绝对说法改成带条件的说法。例如「阴雨天不断电」改成「8000mAh 大电池，阴雨天由电池供电（续航受天气和使用频率影响）」。
- 有数据就写数据和测试条件；没有数据就删掉这个卖点，不要硬凑。
- 需要证明的内容（检测报告、专利、授权、荣誉），提醒用户把证明放进详情页。
- 主图能放的字本来就少，改法要简短，适合放在图上。
不要建议用谐音字、拼音、特殊符号、拆字、遮挡、马赛克去绕过审核。平台规则写明，这类规避手段会让处罚升档。也不要建议「大字写承诺、角落小字写限制」：平台在安防监控治理公告里明确，这种写法仍然判定不合规。
6. 输出报告
报告越短越好。用户经常一次发 5 张以上的图，要能一眼看完：不管几张图，报告都控制在 15 行左右。
- 按问题汇总，不按图片展开。 同一个问题只写一次，标出现在哪几张图，例如「（图1、4）」。
- 每个问题只写一行，格式固定：「原文」（图号）→ 改成｜原因（依据简称）。原因不超过 10 个字。
- 🔴 全部列出。🟡 最多列 5 条，按影响排序：可能封禁商品的（法规禁止、导流）在前，虚假宣传其次，只影响规范度或流量的最后。同类问题合并成一条，例如几处「需要检测报告」；放不下的合成一行「另有 N 条较轻的：……」.
- ⚪ 合成一行。
- 需要你确认最多 4 项，挑最影响结论的，一行写完。
- 不写没问题的项、图上文字的全文、每张图的规格。看不清的字和规格问题放进 ⚪。完全没有问题时，只写「未发现问题」。
- 用户要逐张、逐条的明细或识别出的全文时，再单独给，或者导出 CSV（见第 7 步）。
模板：
## 主图预审：N 张｜🔴 X｜🟡 X｜⚪ X
**🔴 必须改**
1. 「365天全年守护不停电」（图1、3）→ 太阳能板 + 8000mAh 电池双供电｜保证性承诺（虚假宣传 4.2）
2. ……
**🟡 建议改**
- 「高效转化」「快速充电」（图1、2）→ 写太阳能板功率，没有就删｜无数据夸大（虚假宣传 4.2）
- 另有 2 条较轻的：「风雨无惧」、首图文字偏多
**⚪ 请核对**：图3「阴雨天不断[看不清]」疑似错别字；4 张都是 WEBP，以原图为准
**需要你确认**：电池容量和实测续航、太阳能板功率、每个 SKU 是否都带太阳能板
> 预审结果，不代表平台审核；规则整理于 2026-11-07。
依据用下面的简称。用户追问时再给全称，原文链接在 sources.md：
| 简称 | 规则全称 |
|---|---|
| 虚假宣传 4.1 / 4.2 / 4.3 | 《商家【虚假宣传】细则》 |
| 主图规范 | 《商品主图发布规范》 |
| 价格违规 | 《商家【价格违规】处置细则》 |
| 导流 | 《【诱导第三方】处置细则》 |
| 法规禁止 | 《【发布法规禁止商品/信息】处置细则》 |
| 安防公告 | 《关于安防监控类商品的专项治理公告》 |
| 行业规范 | 《【家居家电】行业管理规范》或《【3c数码】行业管理规范》 |
| 案例 XXX | cases.md 或 private-cases.md 里的案例 |
7. 导出 CSV 明细
两种情况导出 CSV：一是批量检查（一次检查多个商品，或者用户给了一整个文件夹）；二是用户想看逐张、逐条的明细。对话里的报告保持简短，完整明细放进 CSV，方便用户用 Excel 分工修改：
- 文件名
主图预审_YYYYMMDD_HHMM.csv，保存到图片所在的文件夹；不确定就保存到当前工作目录。完成后告诉用户完整路径。 - 编码用 UTF-8，并在文件开头加 BOM（U+FEFF）。不加 BOM，Excel 打开中文会乱码。
- 第一行是表头：
商品,图片文件,第几张,级别,原文或画面,位置,问题,依据,建议改成 - 每个问题一行。没有问题的图也写一行，级别填「通过」，方便核对有没有漏查。
- 字段里有逗号、双引号或换行时，用双引号把整个字段包起来，字段内的双引号写成两个。
不能写文件的环境，就把 CSV 内容放进代码块，请用户自己保存成 .csv 文件。
8. 记录驳回案例，让检查越来越准
用户发来被驳回的主图和驳回原因时：
- 按上面的流程检查，指出最可能触发驳回的句子或画面。驳回通知一般只举例，不会点名具体是哪句，所以要说明这是推断。
- 把这个案例追加到
references/private-cases.md。文件不存在就新建，第一行写「本地私有案例，不要提交到公开仓库」。格式参照references/cases.md里的模板。店铺名、商品链接、订单号对判断没有帮助，不用记。 - 告诉用户已经记下，以及记了哪些内容。
- 不能写文件的环境，就把整理好的案例输出给用户，请用户自己保存。
private-cases.md 已写进 .gitignore，不会跟着仓库公开。用户想把某个案例分享出去时，提醒先去掉能识别店铺的信息，再移到 cases.md。