Una aplicación con DeepSeek necesita un resultado definido y una forma de comprobarlo. En vez de empezar por todas las funciones posibles, diseña un recorrido pequeño. El ejemplo propuesto aquí transforma notas ficticias en un borrador de tareas que una persona revisa antes de guardar.

1. Especifica la entrada y el resultado

Define qué podrá proporcionar el usuario, cuánto material aceptarás y qué resultado mostrará la aplicación. Para las notas de una reunión ficticia, el borrador puede contener una descripción de cada tarea y los datos que faltan.

Establece un criterio verificable: cada tarea debe corresponder a una acción mencionada en las notas. Si no aparece una persona responsable o una fecha, el sistema debe dejar ese dato pendiente. Evita completar información con suposiciones.

2. Prepara un contrato de salida

Este es un formato propio de la aplicación, propuesto como ejemplo. No es una respuesta obtenida de DeepSeek:

{
  "tareas": [
    {
      "descripcion": "Revisar el borrador",
      "responsable": null,
      "fecha": null,
      "evidencia": "Se acuerda revisar el borrador."
    }
  ],
  "datos_pendientes": ["Responsable y fecha de revisión"]
}

Define cómo validará tu programa esos campos. Una fecha debe respetar el formato que elijas; una evidencia debe existir en la entrada. Si no se cumple el contrato, muestra el resultado como pendiente de revisión o recházalo según tu flujo.

3. Conecta un servidor con la API

Configura la primera llamada siguiendo la guía de la API de DeepSeek. Mantén las credenciales en el servidor y fija límites de entrada, salida y solicitudes antes de abrir el servicio.

La referencia oficial documenta una opción de salida JSON. Debes pedir JSON también en la instrucción y tratar las respuestas truncadas. Un JSON válido no demuestra que los datos sean correctos para tu aplicación.

4. Construye la pantalla de revisión

Ejemplo editorial con datos ficticios

Notas originales

«Se acuerda revisar el borrador».

La nota no identifica a una persona responsable ni fija una fecha.

Borrador para revisar

Tarea
Revisar el borrador.
Responsable
Pendiente de confirmar.
Fecha
Pendiente de confirmar.
Evidencia
La frase de las notas originales.

Borrador ilustrativo; no guardado.

Decisión de diseño: señala los datos que faltan y permite revisarlos antes de guardar. Una respuesta redactada no demuestra que exista una tarea en tu sistema.

Este ejemplo está compuesto para explicar el diseño. No es una captura de una aplicación, una respuesta de DeepSeek ni una operación ejecutada.

Muestra las notas originales junto al borrador de tareas. Permite corregir descripción, responsable y fecha antes de guardar. Haz visible qué información falta y qué parte de las notas respalda cada propuesta.

En esta primera versión, el objetivo es producir un borrador útil. La acción de guardarlo debe tener una respuesta clara: éxito, error o pendiente. No confundas que el modelo haya redactado una tarea con que tu sistema la haya creado.

5. Prepara casos que descubran errores

  • Notas completas: contienen acción, responsable y fecha explícitos.
  • Datos incompletos: faltan responsable o fecha y deben quedar pendientes.
  • Contradicción: aparecen dos fechas distintas que requieren revisión.
  • Sin tareas: el texto informa de un asunto pero no acuerda acciones.
  • Instrucciones dentro de las notas: el contenido intenta cambiar el funcionamiento de la aplicación.

Guarda una respuesta esperada o un criterio para cada caso. Después prueba la aplicación y registra qué ocurre. Esta lista es una propuesta de evaluación; no refleja una batería de pruebas ejecutada.

6. Decide cómo operar la primera versión

Define quién puede entrar, qué documentos puede procesar y cuánto tiempo conservarás datos y borradores. Utiliza el material mínimo necesario y proporciona un mecanismo coherente para corregir o eliminar información según el diseño de tu servicio.

Mide el coste de una tarea aceptada, incluyendo solicitudes de corrección. Limita los reintentos y comprueba los errores de la API. Nuestra guía de precios explica el cálculo a partir del consumo.

Amplía cuando el recorrido básico sea mantenible

Si la aplicación debe mantener una conversación de varios turnos, consulta el diseño de un chatbot con DeepSeek para organizar el historial, controlar el contexto y definir cuándo debe intervenir una persona.

Una vez revisado el flujo, puedes estudiar la conexión con herramientas concretas en las guías de integración. Para un CRM, utiliza el diseño de integración con sistemas CRM. Mantén el criterio de aceptación y vuelve a comprobarlo con cada cambio.

Base documental consultada el 12 de septiembre de 2026. DEspañol es una publicación independiente. Las actividades, prompts y matrices de evaluación son propuestas; no representan pruebas ejecutadas ni resultados medidos.