yuruyi-ling/douyin-image-check

抖音商品主圖違規預審

目標：在商家上傳主圖之前，找出會被抖音電商駁回、限流或處罰的內容，說清楚依據，並給出能直接替換的寫法。

有兩個前提要始終記住，報告裡也要讓用戶知道：

• 這是預審，不是平台審核。 平台會結合宣傳的整體語境、商品真實參數、商家能拿出的證明來判定。同一句話，有檢測報告時可能合規，沒有時就違規。所以很多結論取決於用戶的真實情況，要問清楚或標出來。
• 規則有日期。 本 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. 看圖，把文字全部讀出來

每張圖做三件事：

1. 規格：如果你能執行命令，讀取圖片真實的像素尺寸和檔案格式，用什麼工具都可以。不能執行就跳過，報告裡寫「未讀取原圖規格」。
2. 畫面：商品主體在哪裡、佔多大、是實拍還是渲染圖或 AI 圖；有沒有 QR code、浮水印、邊框、播放鍵、人物、尺寸對比物、地圖、其他品牌或平台的標誌、敏感元素。效果展示圖和對比圖要特別留意是不是本機實拍。圖示也要看，它們同樣會被當成宣傳（例如 4G 攝像頭配了 WiFi 圖示）。
3. 文字：按區域（左上、中間、右側、底部橫條……）逐字抄下圖上的全部文字，包括角標、小字和圖示旁的說明。看不清的字寫成「[看不清]」，不要猜：猜錯一個字，結論可能就反了。

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. 記錄駁回案例，讓檢查越來越準

用戶發來被駁回的主圖和駁回原因時：

1. 按上面的流程檢查，指出最可能觸發駁回的句子或畫面。駁回通知一般只舉例，不會點名具體是哪句，所以要說明這是推斷。
2. 把這個案例追加到 references/private-cases.md。檔案不存在就新建，第一行寫「本地私有案例，不要提交到公開倉庫」。格式參照 references/cases.md 裡的模板。店鋪名、商品連結、訂單號對判斷沒有幫助，不用記。
3. 告訴用戶已經記下，以及記了哪些內容。
4. 不能寫檔案的環境，就把整理好的案例輸出給用戶，請用戶自己儲存。

private-cases.md 已寫進 .gitignore，不會跟著倉庫公開。用戶想把某個案例分享出去時，提醒先去掉能識別店鋪的資訊，再移到 cases.md。