KI an deinem Schreibtisch: Ein praktisches Setup für die tägliche Arbeit

Die meisten Menschen, die KI bei der Arbeit nutzen, sind darauf beschränkt, Text in ein Chat-Fenster im Browser zu kopieren und einzufügen, und wechseln den Kontext jedes Mal, wenn sie Hilfe brauchen. Das funktioniert bei gelegentlichen Fragen, bricht aber zusammen, sobald du mehrmals pro Stunde KI für Coding, Schreiben und Recherche einsetzt. Dieser Leitfaden behandelt ein Setup, das KI in der Nähe deiner gewohnten Arbeitsfläche hält und dabei Kosten, Privatsphäre und Geschwindigkeit berücksichtigt.

Wähle das richtige Modell für die richtige Aufgabe

Nicht jede Aufgabe benötigt GPT-4-Klasse-Reasoning. Wenn du Meeting-Transkripte zusammenfasst oder eine E-Mail umschreibst, macht ein kleineres, schnelleres Modell die Arbeit in einem Bruchteil der Zeit und Kosten. Führe etwas wie Llama 3.1 8B oder Mistral 7B lokal über Ollama aus für schnelle, risikoarme Aufgaben:

ollama pull llama3.1:8b
ollama run llama3.1:8b "Summarize this in 3 bullet points: ..."

Bewahre die größeren gehosteten Modelle (GPT-4o, Claude 3.5 Sonnet) für Aufgaben auf, die echtes Reasoning benötigen: Debugging eines komplexen Stack Trace, Erstellung eines technischen Vorschlags oder Überprüfung von Architekturentscheidungen. Diese Aufteilung der Arbeit senkt deine API-Rechnung merklich, wenn du pro Token zahlst, und lokale Modelle antworten in Millisekunden gegenüber Sekunden für Hin- und Rückfahrt-API-Aufrufe.

Integriere KI in deinen Editor, nicht in deinen Browser

Wenn du Code schreibst, ist der größte Hebel, KI direkt in deine IDE zu integrieren. VS Code mit der Continue-Erweiterung ermöglicht es dir, entweder auf ein lokales Ollama-Modell oder einen Cloud-API-Schlüssel zu zeigen, und du kannst Code auswählen und inline Fragen stellen, anstatt den Kontext in ein Chat-Fenster umzuschreiben.

{
  "models": [
    {
      "title": "Local Llama",
      "provider": "ollama",
      "model": "llama3.1:8b"
    }
  ]
}

Für Terminalarbeit sparen Tools wie aichat oder eine einfache Shell-Funktion, die die OpenAI CLI umhüllt, dich davor, überhaupt einen Browser zu öffnen:

function ask() {
  curl -s https://api.openai.com/v1/chat/completions \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"model\":\"gpt-4o-mini\",\"messages\":[{\"role\":\"user\",\"content\":\"$1\"}]}" \
    | jq -r '.choices[0].message.content'
}

Rufe es mit ask "explain this regex: ^(?=.*[A-Z]).{8,}$" auf und erhalte eine Antwort, ohne die Shell zu verlassen.

Halte sensible Daten von Servern Dritter fern

Bevor du etwas in ein Cloud-Modell einfügst, frage dich, ob es Kundendaten, Anmeldedaten oder proprietären Code enthält, den dein Unternehmen nicht aus seinem Netzwerk lassen möchte. Viele Teams legen eine einfache Regel fest: Alles, das interne Codebases oder PII berührt, läuft durch ein lokales Modell oder eine Enterprise-API mit einer Zero-Retention-Vereinbarung, und alles andere kann zu einem Consumer-Tool gehen.

Ollama auf einem Machine mit einer anständigen GPU (eine einzelne RTX 4070 oder besser bewältigt 7B-13B-Modelle mühelos) deckt den meisten alltäglichen Drafting und Code-Review ab, ohne dass ein einziges Byte deinen Laptop verlässt. Für schwerere lokale Arbeit tauschen quantisierte Modelle (Q4_K_M oder Q5_K_M) eine kleine Menge Genauigkeit gegen Geschwindigkeit und niedrigere Speichernutzung ein.

Baue kleine Scripts statt wiederholte Prompts zu schreiben

Wenn du feststellst, dass du immer wieder die gleiche Prompt-Struktur tippst, mache ein Script daraus. Ein täglicher Standup-Zusammenfasser, der aus deinem Git-Log zieht, ist ein guter Anfang:

git log --since="yesterday" --author="$(git config user.name)" --oneline | \
  ask "Turn these commits into a 3-sentence standup update"

Diese Art von kleiner Automatisierung verdoppelt sich. Fünf Minuten pro Tag bei einem Team von zehn sparen sich wirklich Stunden im Monat, und es beseitigt die Reibung, die Menschen davon abhält, KI-Tools überhaupt zu nutzen.

Achte auf die Fehlermodi

KI an deinem Schreibtisch macht immer noch Fehler auf spezifische, vorhersehbare Weise: Sie erfindet Funktionsnamen, die nicht in deinem Codebase existieren, missliest indentationsabhängigen Code und gibt selbstbewusst veraltete Library-Syntax. Führe generierten Code immer aus, bevor du ihm vertraust, und behandle jede Faktenaussage (eine CVE-Nummer, das Standardverhalten einer Library, ein Abschaffungsdatum) als etwas, das du unabhängig überprüfst, anstatt es als Tatsache zu nehmen.

Das Ziel ist nicht, dein Urteil durch die Ausgabe eines Modells zu ersetzen. Es geht darum, die Zeit zwischen einer Frage und einem nützlichen ersten Entwurf einer Antwort zu verkürzen, damit du mehr deines Tages für die Teile der Arbeit aufwendest, die tatsächlich einen Menschen benötigen.

Wenn du weiter gehen möchtest mit lokalen Modellen, Prompt Design oder der Erstellung eigener Tools, schau dir die KI- und Scripting-Segmente bei Korra Studio an.