CommunityProgramación y desarrollogithub.com

yuruyi-ling/douyin-image-check

Preauditoría de infracciones en imágenes principales de productos para el comercio electrónico de Douyin (Tiendas Douyin, Pequeñas Tiendas Douyin, Centro Comercial Douyin). Revisa imágenes, texto y especificaciones según las reglas oficiales de Douyin, clasifica las infracciones en 🔴 clara infracción / 🟡 riesgo de experiencia / ⚪ posible error de juicio, señala la ubicación del problema y la base de la regla, y proporciona texto alternativo directamente reemplazable.

¿Qué es douyin-image-check?

Este skill es una herramienta de preauditoría para que los vendedores de Douyin verifiquen si sus imágenes principales de productos (incluidas imágenes principales, detalles, SKU y texto de imagen) infringen las reglas de la plataforma antes de subirlas, evitando así el rechazo, la limitación de tráfico o sanciones. Su objetivo principal es simular la lógica de revisión de la plataforma, identificar posibles infracciones en el texto visual (como afirmaciones de rendimiento, expresiones absolutas) y la composición de la imagen (como marcas de agua, códigos QR, otras marcas), y proporcionar sugerencias de modificación que cumplan con las reglas. Soporta las plataformas del ecosistema Douyin (Tiendas Douyin, Pequeñas Tiendas Douyin, Centro Comercial Douyin) y se basa en las reglas oficiales de Douyin (especificaciones de imágenes principales, reglas de afirmaciones, casos de rechazo), así como en reglas de categorías específicas como vigilancia de seguridad. El skill funciona analizando las imágenes y el texto en el diálogo, leyendo las reglas de los archivos de referencia correspondientes (como `references/main-image-rules.md`, `references/claim-rules.md`), y realizando una revisión comparativa elemento por elemento, clasificando las infracciones en tres niveles: 🔴 clara infracción, 🟡 riesgo de experiencia y ⚪ posible error de juicio. Al mismo tiempo, el skill enfatiza la postura de "preauditoría, no revisión de la plataforma", advirtiendo a los usuarios que las conclusiones pueden variar según las circunstancias reales y que las reglas se actualizan con frecuencia. Además, el skill admite el registro de casos de rechazo pasados para mejorar la precisión de revisiones futuras y puede exportar un informe detallado en formato CSV.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/yuruyi-ling/douyin-image-check/tree/HEAD

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Preauditoría de infracciones en imágenes principales de productos de Douyin

Objetivo: Antes de que los vendedores suban la imagen principal, identificar contenido que podría ser rechazado, limitado en tráfico o sancionado por Douyin E-commerce, explicar la base y proporcionar una redacción que pueda ser reemplazada directamente.

Siempre ten en cuenta dos premisas, y también haz que el usuario las conozca en el informe:

  • Esto es una preauditoría, no una revisión de la plataforma. La plataforma juzga considerando el contexto general de la promoción, los parámetros reales del producto y las pruebas que el vendedor pueda presentar. La misma frase puede ser conforme si hay un informe de prueba, o puede ser una infracción si no lo hay. Por lo tanto, muchas conclusiones dependen de la situación real del usuario, por lo que debes preguntar claramente o señalarlo.
  • Las reglas tienen fecha. Este skill se basa en reglas recopiladas hasta el 2026-11-07 (ver rules-updated en el frontmatter). Las reglas de Douyin se actualizan con frecuencia; si tienes dudas o el usuario tiene preguntas, consulta el texto original más reciente del Centro de Aprendizaje de Douyin E-commerce, cuyo enlace está en references/sources.md.

Archivos de reglas

Léelos según sea necesario, no los leas todos de una vez:

ArchivoCuándo leerlo
references/main-image-rules.mdLéelo siempre. Especificaciones de la imagen principal, requisitos de la primera imagen, contenido prohibido en la imagen
references/claim-rules.mdLéelo siempre. Infracciones relacionadas con el texto: promesas de efectos, palabras extremas, promociones que requieren prueba, precios, desvío fuera de la plataforma
references/cases.mdLéelo siempre. Casos confirmados de rechazo, referencias directas para escrituras similares
references/private-cases.mdLéelo si el archivo existe. Casos de rechazo acumulados por el usuario, guardados solo localmente
references/category-security-camera.mdLéelo cuando el producto sea cámara, vigilancia o dispositivo de seguridad
references/category-template.mdLéelo cuando necesites organizar reglas para una nueva categoría
references/sources.mdLéelo cuando necesites dar el enlace original de la regla o el usuario pregunte "¿dónde está la base?"

Actualmente solo se ha recopilado una categoría de reglas especializadas para vigilancia de seguridad. Las demás categorías se revisan primero con las reglas generales, y se indica en el informe "aún no se han recopilado reglas especializadas para esta categoría", recomendando al usuario consultar el "Reglamento de Gestión de la Industria" correspondiente en el Centro de Aprendizaje. Si puedes acceder a internet, puedes ofrecerte para ayudar al usuario a organizar un archivo de reglas para una nueva categoría.

Proceso de revisión

1. Aclarar el objeto de revisión

Encuentra esta información en la conversación. Si falta, usa valores predeterminados y no te detengas por eso:

  • Categoría: Determínalo a partir de la imagen. Si no puedes, pregunta una vez, mientras tanto revisa con las reglas generales.
  • Número de imagen: Si el usuario no lo dice, sigue el orden en que se enviaron. La primera imagen se revisa con el estándar de la primera imagen (la primera imagen tiene los requisitos más estrictos).
  • Parámetros reales del producto: Por ejemplo, resolución y píxeles, capacidad de la batería, si incluye panel solar, configuración de cada SKU, políticas de datos y almacenamiento en la nube, si hay informes de prueba. Muchas promociones dependen de si son consistentes con la realidad. Si el usuario no los proporciona, marca con 🟡 y enumera en "Necesito que confirmes" al final del informe.
  • ¿Es la imagen original?: Las imágenes pegadas en la conversación pueden estar comprimidas, recortadas o con formato cambiado. Las conclusiones sobre tamaño, proporción, formato, si no se basan en la imagen original, se degradan a ⚪, recordando al usuario que se base en la imagen original subida a la Tienda Douyin.

2. Observar la imagen, leer todo el texto

Para cada imagen, haz tres cosas:

  1. Especificaciones: Si puedes ejecutar comandos, lee las dimensiones en píxeles y el formato de archivo reales de la imagen, usando cualquier herramienta. Si no puedes, omítelo y escribe en el informe "no se leyeron las especificaciones de la imagen original".
  2. Escena: ¿Dónde está el cuerpo principal del producto, qué tan grande ocupa, es foto real, render o imagen generada por IA? ¿Hay códigos QR, marcas de agua, bordes, botones de reproducción, personas, objetos de comparación de tamaño, mapas, logotipos de otras marcas o plataformas, elementos sensibles? Las imágenes de demostración de efectos y comparación deben revisarse especialmente si son tomas reales del dispositivo. También revisa los iconos, ya que también se consideran promociones (por ejemplo, una cámara 4G que muestra un icono WiFi).
  3. Texto: Copia todo el texto de la imagen por zonas (esquina superior izquierda, centro, lado derecho, barra inferior...), incluyendo marcas, texto pequeño y descripciones junto a los iconos. Las palabras ilegibles se escriben como "[ilegible]", no adivines: una letra mal adivinada podría cambiar la conclusión.

3. Revisar una por una contra las reglas

  • Cada texto promocional, contrastarlo con claim-rules.md y el archivo de categoría.
  • La escena y especificaciones de cada imagen, contrastarlas con main-image-rules.md.
  • Contraste texto-imagen: Verificar si el texto promocional contradice las imágenes, pasos o tablas de parámetros en la misma imagen. Por ejemplo, si el texto grande dice "sin perforación", pero la imagen de instalación muestra tornillos y tacos para fijar el soporte.
  • Revisión entre imágenes: Verificar si el mismo punto de venta es consistente en diferentes imágenes; si la configuración mostrada en la imagen principal (por ejemplo, "doble cámara", "incluye panel solar", "8000mAh") está presente en cada SKU. Si el SKU de precio más bajo no la tiene, esto es "trampa de SKU de bajo precio" dentro de las infracciones de precio.
  • Contraste con casos: Las escrituras similares a casos en cases.md o private-cases.md que ya han sido rechazados se tratan como 🔴, indicando "similar al caso XXX".

4. Clasificación por nivel

Clasifica según "qué tan sólida es la base", no según "qué tan grave es el problema":

  • 🔴 Infracción clara, que cumple cualquiera de las siguientes:
    • El texto original de la regla o los ejemplos oficiales mencionan explícitamente palabras, escrituras o escenas prohibidas;
    • Promesas absolutas y garantizadas sin condiciones sobre efectos, rendimiento o servicios. El artículo 4.2 de las "Reglas detalladas de [publicidad falsa] del vendedor" lo prohíbe explícitamente, por ejemplo, "nunca se apaga", "sin puntos muertos", "reconocimiento 100%";
    • Las imágenes, pasos o parámetros en la imagen ya demuestran que esta afirmación promocional no es válida;
    • Pertenece al mismo tipo de escritura que los casos confirmados de rechazo.
  • 🟡 Riesgo de experiencia: Las reglas no mencionan explícitamente, pero pertenecen al mismo tipo de riesgo; o la infracción depende de si el usuario puede presentar pruebas (informes de prueba, números de patente, licencias, parámetros consistentes). Debes indicar "se puede mantener si hay prueba, si no, cambiar como 🔴".
  • ⚪ Posible error de juicio: Situaciones en las que no estás seguro, incluyendo palabras ilegibles, términos comunes de la industria que podrían ser malinterpretados, palabras que solo aparecen en listas no oficiales en internet, o conclusiones sobre especificaciones basadas en imágenes no originales.

Si una frase infringe varias reglas a la vez, combínala en una sola línea y escribe todas las bases. No juzgues descripciones normales como problemas solo para parecer completo: demasiados falsos positivos harán que el usuario ignore lo que realmente necesita cambiar.

5. Dar una modificación

La modificación debe poder copiarse y usarse directamente, con la dirección que la plataforma exige al vendedor: "Escribe lo que es".

  • Convierte las promesas en descripciones, las afirmaciones absolutas en afirmaciones condicionales. Por ejemplo, "nunca se apaga en días lluviosos" se cambia a "batería grande de 8000mAh, alimentada por batería en días lluviosos (la duración se ve afectada por el clima y la frecuencia de uso)".
  • Si hay datos, escribe los datos y las condiciones de prueba; si no hay datos, elimina ese punto de venta, no lo fuerces.
  • Para contenido que necesita prueba (informes de prueba, patentes, licencias, honores), recuerda al usuario que ponga la prueba en la página de detalles.
  • La imagen principal tiene poco espacio para texto, la modificación debe ser breve y adecuada para colocarla en la imagen.

No sugieras usar homófonos, pinyin, símbolos especiales, caracteres divididos, ocultación o mosaico para eludir la revisión. Las reglas de la plataforma indican que este tipo de evasión hará que la sanción sea más severa. Tampoco sugieras "escribir la promesa en letras grandes y las restricciones en letras pequeñas en una esquina": la plataforma ha dejado claro en el anuncio de gobernanza de vigilancia de seguridad que esta escritura sigue considerándose no conforme.

6. Informe de salida

Cuanto más corto sea el informe, mejor. Los usuarios suelen enviar más de 5 imágenes a la vez, debe poder verse de un vistazo: sin importar cuántas imágenes, el informe debe tener alrededor de 15 líneas.

  • Resumir por problema, no por imagen. El mismo problema se escribe solo una vez, indicando en qué imágenes aparece, por ejemplo, "(Figura 1, 4)".
  • Cada problema se escribe en una sola línea, con formato fijo: "Texto original" (Número de figura) → Cambiar a | Razón (abreviatura de la base). La razón no debe exceder 10 caracteres.
  • 🔴 Se enumeran todos. 🟡 Máximo 5 líneas, ordenadas por impacto: primero lo que puede prohibir el producto (prohibiciones legales, desvío), luego publicidad falsa, y al final lo que solo afecta la estandarización o el tráfico. Los problemas similares se fusionan en una sola línea, por ejemplo, varios lugares que "necesitan informe de prueba"; si no caben, se combinan en una línea como "Hay otras N líneas más leves: ...".
  • ⚪ Se combina en una línea.
  • Necesito que confirmes máximo 4 elementos, elige los que más impactan en la conclusión, escríbelos en una línea.
  • No escribas elementos sin problemas, el texto completo de la imagen, las especificaciones de cada imagen. Las palabras ilegibles y problemas de especificaciones se ponen en ⚪. Cuando no haya ningún problema, solo escribe "No se encontraron problemas".
  • Cuando el usuario quiera detalles por imagen o línea, o el texto completo identificado, entrégaselo por separado, o exporta en CSV (ver paso 7).

Plantilla:

## Preauditoría de imagen principal: N imágenes|🔴 X|🟡 X|⚪ X

**🔴 Debe cambiarse**
1. "Protección todo el año sin cortes de energía" (Figura 1, 3) → Panel solar + batería 8000mAh doble alimentación | Promesa garantizada (Publicidad falsa 4.2)
2. ......

**🟡 Se recomienda cambiar**
- "Conversión eficiente", "Carga rápida" (Figura 1, 2) → Escribe la potencia del panel solar, si no, elimina | Sin datos exagerados (Publicidad falsa 4.2)
- Otras 2 líneas más leves: "Sin miedo a la lluvia y el viento", demasiado texto en la primera imagen

**⚪ Por favor verifica**: En Figura 3, "Sin cortes en días lluviosos [ilegible]" parece un error tipográfico; las 4 imágenes son WEBP, basarse en la imagen original

**Necesito que confirmes**: Capacidad de la batería y duración real medida, potencia del panel solar, si cada SKU incluye panel solar

> Resultado de preauditoría, no representa la revisión de la plataforma; reglas recopiladas hasta el 2026-11-07.

Usa las siguientes abreviaturas para la base. Cuando el usuario pregunte más, da el nombre completo; el enlace original está en sources.md:

AbreviaturaNombre completo de la regla
Publicidad falsa 4.1 / 4.2 / 4.3"Reglas detalladas de [publicidad falsa] del vendedor"
Especificación imagen principal"Especificaciones de publicación de imagen principal de producto"
Infracción de precio"Reglas detalladas de manejo de [infracciones de precio] del vendedor"
Desvío"Reglas detalladas de manejo de [inducción a terceros]"
Prohibición legal"Reglas detalladas de manejo de [publicación de productos/información prohibidos por ley]"
Anuncio seguridad"Anuncio de gobernanza especializada para productos de vigilancia de seguridad"
Reglamento industria"Reglamento de gestión de la industria [Hogar y electrodomésticos]" o "Reglamento de gestión de la industria [3C digital]"
Caso XXXCaso en cases.md o private-cases.md

7. Exportar detalle en CSV

Exporta CSV en dos casos: primero, revisión por lotes (revisar varios productos a la vez, o si el usuario da una carpeta completa); segundo, cuando el usuario quiera ver el detalle por imagen o línea. El informe en el diálogo debe ser breve, el detalle completo se pone en CSV, para que el usuario pueda modificarlo con Excel:

  • Nombre de archivo Preauditoria_imagen_principal_AAAAMMDD_HHMM.csv, guárdalo en la misma carpeta donde están las imágenes; si no estás seguro, guárdalo en el directorio de trabajo actual. Al terminar, dile al usuario la ruta completa.
  • Codificación UTF-8, con BOM (U+FEFF) al inicio del archivo. Sin BOM, Excel mostrará caracteres chinos incorrectos.
  • La primera línea son los encabezados: Producto,Archivo de imagen,Número de imagen,Nivel,Texto original o escena,Ubicación,Problema,Base,Sugerencia de cambio
  • Cada problema en una línea. Para imágenes sin problema, también escribe una línea con nivel "Aprobado", para facilitar la verificación de que no se haya omitido ninguna.
  • Cuando un campo contenga comas, comillas dobles o saltos de línea, encierra todo el campo entre comillas dobles, y escribe las comillas dobles dentro del campo como dos comillas dobles.

Si no puedes escribir archivos en el entorno, coloca el contenido del CSV dentro de un bloque de código y pide al usuario que lo guarde como archivo .csv.

8. Registrar casos de rechazo para hacer la revisión más precisa

Cuando el usuario envíe imágenes principales rechazadas y el motivo del rechazo:

  1. Sigue el proceso anterior para revisar, señalando la frase o escena que más probablemente desencadenó el rechazo. Normalmente, la notificación de rechazo solo da ejemplos, no menciona la frase específica, por lo que debes indicar que es una inferencia.
  2. Agrega este caso a references/private-cases.md. Si el archivo no existe, créalo con la primera línea "Caso privado local, no enviar al repositorio público". El formato sigue la plantilla en references/cases.md. El nombre de la tienda, enlace del producto y número de pedido no son útiles para el juicio, no los guardes.
  3. Dile al usuario que ya lo has guardado y qué contenido has guardado.
  4. Si no puedes escribir archivos en el entorno, entrega el caso organizado al usuario y pídele que lo guarde.

private-cases.md ya está en .gitignore, no se hará público junto con el repositorio. Cuando el usuario quiera compartir algún caso, recuérdale que primero elimine la información que identifique la tienda y luego lo mueva a cases.md.

Skills relacionados