Meine Bot-Befehlsstrategie für Telegram & Discord

Hey zusammen, Marcus hier von ai7bot.com. Es ist der 13. März 2026, und ich habe in letzter Zeit mit einem bestimmten Problem gekämpft, von dem ich wetten würde, dass viele von euch, die Bots bauen, es schon einmal erlebt haben oder bald erleben werden. Ich spreche von der Verwaltung von Bot-Befehlen und Interaktionen über mehrere Plattformen hinweg, ohne den Verstand zu verlieren. Genauer gesagt habe ich mich intensiv mit Telegram und Discord beschäftigt und versucht herauszufinden, wie man die Dinge im Griff behält, wenn dein Bot an beiden Orten ähnliche Aufgaben erledigen muss.

Eine Zeit lang war mein Ansatz das, was ich als „brutale Duplication“ bezeichnen würde. Wenn mein Bot einen /help-Befehl auf Telegram hatte, schrieb ich den Code dafür. Dann, wenn ich einen ähnlichen !help-Befehl auf Discord benötigte, kopierte ich ihn einfach, passte ihn an und fertig. Das funktionierte eine Zeit lang, besonders als meine Bots klein und fokussiert waren. Aber als sie wuchsen und ich mehr Funktionen hinzufügte, wurde es zu einem Albtraum. Ein Befehl zu aktualisieren bedeutete, zwei, drei oder sogar mehr Stellen zu aktualisieren. Fehlerbehebungen? Multipliziere mit der Anzahl der Plattformen. Es war langsam, fehleranfällig und raubte mir ehrlich gesagt die Freude am Basteln.

Ich erinnere mich an eine späte Nacht, wahrscheinlich genährt von zu viel Kaffee und zu wenig Schlaf, als ich versuchte herauszufinden, warum der /status-Befehl meines Telegram-Bots veraltete Informationen anzeigte, während der !status-Befehl des Discord-Bots einwandfrei war. Es stellte sich heraus, dass ich die Datenquelle an einem Ort aktualisiert und den anderen völlig vergessen hatte. Das war mein „Aha!“-Moment. Es musste einen besseren Weg geben. Und dieser bessere Weg bestand für mich darin, stark in einen einheitlichen, API-getriebenen Ansatz für die Kern-Logik des Bots zu gehen und die plattformspezifischen Dinge so weit wie möglich zu abstrahieren.

Die Multi-Plattform Bot-Kopfschmerzen: Ein echtes Problem

Seien wir ehrlich, einen Bot für eine einzelne Plattform zu bauen, ist schon herausfordernd genug. Man hat es mit API-Schrullen, Rate-Limits, Benutzererwartungen und der allgemeinen Unvorhersehbarkeit des Internets zu tun. Fügen Sie eine zweite, dritte oder sogar vierte Plattform hinzu, und plötzlich bauen Sie nicht nur einen Bot; Sie bauen eine Übersetzungsschicht, eine Synchronisations-Engine und ein mentales Gesundheitsmanagementsystem für sich selbst.

Mein erster Bot, „WeatherBot 2000“ (ganz originell, oder?), begann auf Telegram. Es war einfach: Du tippst /weather <city> ein und erhältst die aktuellen Bedingungen. Großartig! Dann fragte ein Freund, ob ich ihn auch auf Discord bringen könnte. „Sicher!“ sagte ich selbstbewusst. Ich kopierte die Logik zum Abrufen des Wetters, packte einen Discord-Befehl drumherum und boom, „WeatherBot 2000“ war auch auf Discord und reagierte auf !weather <city>. Mission erfüllt, oder so dachte ich.

Dann kamen die Anfragen: „Kann er eine 3-Tage-Vorhersage anzeigen?“ „Kann er Celsius statt Fahrenheit verwenden?“ „Kann er mir auch die Luftqualität sagen?“ Jede neue Funktion bedeutete, dass ich Code an mindestens zwei Stellen anfassen musste. Die Vorhersage-Funktion erforderte beispielsweise eine Änderung, wie ich die Antwort der Wetter-API parste und wie ich die Ausgabe formatierte. Das zweimal zu tun, einmal für das Markdown von Telegram und einmal für das leicht unterschiedliche Markdown von Discord (oder Embeds für eine ansprechendere Darstellung), war mühsam. Es war nicht nur Kopieren und Einfügen; es war das Präsentations-Logik neu implementieren.

Warum separate Belange? Es geht um die Vernunft.

Der Kern des Problems war, dass meine „Business-Logik“ (Wetterdaten abrufen, verarbeiten) mit meiner „Präsentations-Logik“ (wie es auf Telegram aussieht, wie es auf Discord aussieht) verflochten war. Dies ist ein klassisches Problem der Softwareentwicklung, und die Lösung, wie ich auf die harte Tour gelernt habe, besteht darin, diese Belange zu trennen. Denken Sie daran:

• Kern-Logik: Das ist das, was Ihr Bot tut. Für WeatherBot besteht es darin, API-Aufrufe zu einem Wetterdienst zu machen, die JSON-Antwort zu parsen und relevante Daten zu extrahieren. Dieser Teil sollte plattformunabhängig sein.
• Plattform-Adapter/Präsentations-Logik: Das ist, wie Ihr Bot auf jeder Plattform redet. Es sind die Telegram-API-Aufrufe, die Discord-API-Aufrufe, das Handling von Befehlspräfixen, das Formatieren von Nachrichten mit Markdown oder Embeds, das Senden von Dateien usw.

Wenn Sie diese getrennt halten, können Sie Ihre zentrale Wetterabruf-Logik einmal aktualisieren, und es kommt sofort beiden, Ihrem Telegram- und Discord-Bot zugute. Wenn Telegram eine neue, schicke Nachrichtenformatierungsoption herausbringt, müssen Sie nur Ihren Telegram-Adapter aktualisieren. Der Teil zum Abrufen des Wetters bleibt unberührt.

Ein einheitlichen Kern mit APIs aufbauen: Mein „WeatherBrain“-Beispiel

Nach meinem Debugging-Albtraum beschloss ich, „WeatherBot 2000“ von Grund auf neu zu erstellen, aber diesmal mit einer klaren Trennung. Ich erstellte eine kleine, interne API für die Kernfunktionalität meines Bots. Ich nenne es „WeatherBrain“ (arbeite noch an den Namen, okay?).

WeatherBrain ist nur eine einfache Python Flask-Anwendung (es könnte alles sein, sogar eine Sammlung von Funktionen in einer Bibliothek, aber eine API erleichtert das Skalieren und unabhängige Testen). Es bietet Endpunkte wie /api/weather?city=london&units=metric und /api/forecast?city=london&days=3 an. Wenn es aufgerufen wird, greift es auf eine echte externe Wetter-API zu (wie OpenWeatherMap oder AccuWeather), verarbeitet die Daten und gibt eine saubere, konsistente JSON-Antwort zurück.

Hier ist ein vereinfachter Blick darauf, wie ein WeatherBrain-Endpunkt aussehen könnte:

# weather_brain_api.py (vereinfachtes Flask-Beispiel)
from flask import Flask, request, jsonify
import requests
import os

app = Flask(__name__)

# Dies sollte idealerweise in einer Konfiguration oder Umgebungsvariable sein
WEATHER_API_KEY = os.environ.get("OPENWEATHER_API_KEY") 
OPENWEATHER_URL = "http://api.openweathermap.org/data/2.5/weather"

@app.route('/api/weather', methods=['GET'])
def get_current_weather():
 city = request.args.get('city')
 units = request.args.get('units', 'metric') # 'metric' oder 'imperial'

 if not city:
 return jsonify({"error": "Stadtparameter ist erforderlich"}), 400

 params = {
 'q': city,
 'appid': WEATHER_API_KEY,
 'units': units
 }

 try:
 response = requests.get(OPENWEATHER_URL, params=params)
 response.raise_for_status() # Eine Ausnahme bei HTTP-Fehlern auslösen
 data = response.json()

 # Daten verarbeiten und vereinfachen
 weather_info = {
 "city": data['name'],
 "country": data['sys']['country'],
 "description": data['weather'][0]['description'].capitalize(),
 "temperature": data['main']['temp'],
 "feels_like": data['main']['feels_like'],
 "humidity": data['main']['humidity'],
 "wind_speed": data['wind']['speed']
 }
 return jsonify(weather_info)

 except requests.exceptions.RequestException as e:
 app.logger.error(f"Fehler beim Abrufen des Wetters für {city}: {e}")
 return jsonify({"error": "Konnte keine Wetterdaten abrufen"}), 500
 except KeyError as e:
 app.logger.error(f"Schlüssel-Fehler in den Wetterdaten für {city}: {e}")
 return jsonify({"error": "Unerwartetes Format der Wetterdaten"}), 500

if __name__ == '__main__':
 app.run(debug=True, port=5001)

Jetzt kommunizieren weder mein Telegram-Bot noch mein Discord-Bot direkt mit OpenWeatherMap. Sie kommunizieren mit WeatherBrain. Das ist ein großer Gewinn! Wenn ich von OpenWeatherMap zu AccuWeather wechseln möchte, ändere ich nur den Code in weather_brain_api.py. Die Bots wissen nicht einmal, dass es passiert ist.

Telegram- und Discord-Bots: Zu dünnen Clients werden

Da WeatherBrain die Schwerarbeit erledigt, wurde mein tatsächlicher Telegram- und Discord-Bot-Code viel einfacher. Sie fungieren jetzt als „dünne Clients“ oder „Adapter“. Ihre Aufgabe beschränkt sich darauf:

1. Befehle anzuhören (z.B. /weather <city> oder !weather <city>).
2. Den Befehl zu parsen und Argumente zu extrahieren.
3. Eine HTTP-Anfrage an WeatherBrain zu senden.
4. Die JSON-Antwort von WeatherBrain zu empfangen.
5. Diese JSON-Antwort in eine plattform-spezifische Nachricht zu formatieren.
6. Die Nachricht an den Benutzer zurückzusenden.

Hier ist ein vereinfachtes Beispiel, wie der Telegram-Adapter aussehen könnte:

# telegram_bot.py (vereinfacht)
import telebot
import requests
import os

TELEGRAM_BOT_TOKEN = os.environ.get("TELEGRAM_BOT_TOKEN")
WEATHER_BRAIN_API_URL = "http://localhost:5001/api/weather" # Oder Ihre bereitgestellte API-URL

bot = telebot.TeleBot(TELEGRAM_BOT_TOKEN)

@bot.message_handler(commands=['weather'])
def send_weather(message):
 try:
 args = message.text.split(maxsplit=1)
 if len(args) < 2:
 bot.reply_to(message, "Bitte eine Stadt angeben. Z.B. `/weather London`")
 return

 city = args[1]
 
 # Interne API aufrufen
 response = requests.get(WEATHER_BRAIN_API_URL, params={'city': city, 'units': 'metric'})
 response.raise_for_status()
 weather_data = response.json()

 if "error" in weather_data:
 bot.reply_to(message, f"Fehler: {weather_data['error']}")
 return

 # Für Telegram formatieren
 output = (
 f"*{weather_data['city']}, {weather_data['country']}*\n"
 f"Wetter: {weather_data['description']}\n"
 f"Temperatur: {weather_data['temperature']:.1f}°C (Gefühlt wie {weather_data['feels_like']:.1f}°C)\n"
 f"Feuchtigkeit: {weather_data['humidity']}%\n"
 f"Wind: {weather_data['wind_speed']:.1f} m/s"
 )
 bot.reply_to(message, output, parse_mode='Markdown')

 except requests.exceptions.RequestException as e:
 bot.reply_to(message, "Entschuldigung, ich konnte das Wetter gerade nicht abrufen. Mein Gehirn scheint einen Nickerchen zu machen.")
 print(f"Fehler beim Aufruf der WeatherBrain-API: {e}")
 except Exception as e:
 bot.reply_to(message, "Ein unerwarteter Fehler ist aufgetreten. Bitte versuche es später noch einmal.")
 print(f"Allgemeiner Fehler im Telegram-Bot: {e}")

bot.polling()

Und der Discord-Adapter würde sehr ähnlich aussehen und einfach die Discord.py-Bibliothek (oder was auch immer Sie bevorzugen) verwenden, um Befehle zu verarbeiten und Nachrichten mit der spezifischen Discord-Syntax (z.B. Embeds für reichhaltigere Nachrichten) zu formatieren.

Der Schlüssel hier ist, dass beide Bots die gleichen strukturierten Daten von WeatherBrain abrufen. Sie präsentieren sie nur unterschiedlich. Dies reduziert drastisch den doppelten Code und erleichtert die Hinzufügung von Funktionen oder die Behebung von Fehlern.

Über Kommandos hinaus: Webhooks und Ereignisse

Dieser API-gesteuerte Ansatz ist nicht nur für Kommandos gedacht. Was ist, wenn Ihr Bot auf externe Ereignisse reagieren muss? Angenommen, Sie haben einen Überwachungsbot, der die Betriebszeit einer Webseite überprüft. Wenn die Webseite ausfällt, kann Ihr Überwachungsdienst einen Webhook an Ihr WeatherBrain (oder eine separate „NotifierBrain“-API) senden. Diese API entscheidet dann, welche Plattformen benachrichtigt werden sollen (Telegram, Discord, E-Mail, SMS) und welche Nachricht gesendet wird, wobei die strukturierten Alarmdaten an jeden Plattform-Adapter übergeben werden.

Hier zeigt sich die wahre Stärke. Ihre zentrale API wird zur einzigen Quelle der Wahrheit für die Intelligenz Ihres Bots, und die plattformspezifischen Komponenten sind lediglich Kommunikationskanäle.

Handlungsrelevante Erkenntnisse für Ihr nächstes Bot-Projekt

Wenn Sie einen Bot entwickeln, insbesondere einen, den Sie auf mehreren Plattformen erweitern oder komplexe Funktionen hinzufügen möchten, berücksichtigen Sie diese Punkte:

1. Isolieren Sie Ihre Kernlogik: Bevor Sie überhaupt eine plattformspezifische API ansprechen, notieren (oder kodieren) Sie, was Ihr Bot grundlegend tut. Welche Daten benötigt er? Welche Berechnungen führt er aus? Das ist Ihr „Gehirn“.
2. Erstellen Sie eine interne API (auch eine einfache): Egal, ob es sich um eine Flask-Anwendung, einen FastAPI-Dienst oder einfach ein gut strukturiertes Python-Modul mit klaren Funktionen handelt, schaffen Sie eine Schicht, die Ihre Kernlogik kapselt und konsistente, strukturierte Daten zurückgibt (JSON ist dafür großartig). Dies macht es testbar und wiederverwendbar.
3. Betrachten Sie plattformspezifische Bots als Adapter: Ihre Aufgabe ist es, Benutzereingaben in Aufrufe an Ihre interne API zu übersetzen und anschließend die Antworten der internen API in für diese Plattform geeignete Nachrichten umzuwandeln. Sie sollten „dünn“ sein – minimale Logik, maximale Kommunikation.
4. Planen Sie für die Fehlerbehandlung: Wenn Sie mehrere Schichten haben (Plattform-Bot -> interne API -> externe API), können Fehler in jeder Phase auftreten. Stellen Sie sicher, dass jede Schicht Fehler von der darunterliegenden Schicht elegant behandelt und informative (aber nicht zu technische) Rückmeldungen an den Benutzer gibt.
5. Berücksichtigen Sie die Bereitstellung: Wenn Ihre interne API ein separater Dienst ist, müssen Sie sie irgendwo bereitstellen. Dienste wie Heroku, Render oder sogar ein kleiner VPS können diese Mikrodienste hosten. Stellen Sie sicher, dass Ihre Plattform-Bots Ihre interne API erreichen können (z. B., wenn sie lokal ausgeführt wird, müssen sie im gleichen Netzwerk sein oder über eine öffentliche URL zugänglich sein).
6. Starten Sie klein, iterieren Sie: Sie müssen nicht sofort eine massive Mikrodienste-Architektur aufbauen. Beginnen Sie mit einer Kernfunktion, isolieren Sie sie und erstellen Sie dann Ihren ersten Plattform-Adapter. Wenn Sie weitere Funktionen oder Plattformen hinzufügen, werden Sie Ihre interne API natürlicherweise erweitern.

Diese Herangehensweise hat mir unzählige Stunden Debugging erspart und es mir ermöglicht, meine Bots viel effektiver zu skalieren. Die anfängliche Einrichtung mag wie ein wenig mehr Arbeit erscheinen, aber glauben Sie mir, die langfristigen Vorteile in Bezug auf Wartbarkeit, Skalierbarkeit und ehrlich gesagt, Ihre eigene geistige Gesundheit sind absolut lohnenswert. Viel Spaß beim Bot-Bau!

🕒 Published: March 27, 2026