抖音商品主图违规预审
目標：在商家上傳主圖之前，找出會被抖音電商駁回、限流或處罰的內容，說清楚依據，並給出能直接替換的寫法。
有兩個前提要始終記住，報告裡也要讓用戶知道：
- 這是預審，不是平台審核。 平台會結合宣傳的整體語境、商品真實參數、商家能拿出的證明來判定。同一句話，有檢測報告時可能合規，沒有時就違規。所以很多結論取決於用戶的真實情況，要問清楚或標出來。
- 規則有日期。 本 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。