Mir hat der Unterschied zwischen Tondoses Script und meiner Adaption einfach keine Ruhe gelassen. Mir fehlte eine sinnhafte Erklärung ebenso wie die Fähigkeit zu scripten.
Dann habe ich mal einen neuen Ansatz versucht: Zuhilfenahme einer KI, auch wenn das in dieser Forenlandschaft verpönt zu sein scheint oder zumindest recht argwöhnisch betrachtet wird.
Ich stimme dem sogar weitgehend zu, aber…
[Exkurs]
Auch ich stehe der KI grundsätzlich skeptisch gegenüber, und verschiedene Tests haben gezeigt, dass unterschiedliche Modelle “halluzinieren” (auch: raten) und man nur mit Gegen- und Kontrollfragen eine Entschuldigungsorgie auslöst.
Das ist kein produktives Arbeiten.
Was ich dabei aber gelernt habe:
Man kann ein Sprachmodell in ein “Korsett” packen: Klare Vorgaben machen, zur Recherche in bestimmten Quellen zwingen und keine Antworten schreiben lassen, die vor Veröffentlichung nicht intern auf Plausibilität und Anwendungspraxis geprüft wurden.
Kurz: Gründlichkeit vor Schnelligkeit.
Zu meiner Überraschung funktioniert das erstaunlich gut. Statt also Befehle aus dem Pascal-Universum auszuwürfeln, die gar nicht mAirList-tauglich sind, kann man die KI dazu zwingen, die Vorschläge zu begründen und didaktisch so darzustellen, dass auch ein Uli das versteht.
Der Gag daran ist: Durch diesen Zwang hört die KI auf, mich mit netten Worten einzulullen, sondern muss so antworten, dass meine Rückfragen dem Entwurf standhalten.
Lustigerweise kann eine - tatsächlich funktionierende - Anweisung lauten:
Antworte knapp und direkt.
Verzichte auf unnötige Einleitungen, Wiederholungen,
Lobhudelei oder motivierende Floskeln.
Das klingt zwar irgendwie dämlich (“verzichte auf Lobhudelei”) - aber die Praxis zeigt: Es klappt!
Es geht noch besser:
Kennzeichne Unsicherheiten klar.
Stelle Vermutungen nicht als Tatsachen dar.
Wenn Informationen fehlen, frage gezielt nach.
Begründe wesentliche Schlussfolgerungen nachvollziehbar,
ohne interne Gedankengänge offenzulegen.
Arbeite systematisch:
zuerst analysieren, anschließend Lösung und Begründung darstellen.
Ich wollte es ja erst nicht glauben.
Man kann das sogar aus der Ich-Perspektive als Erwartungshaltung formulieren:
Ich lerne bevorzugt durch nachvollziehbare Erklärungen.
Begründungen, Zusammenhänge und Ursachen sind mir wichtiger
als eine schnelle Lösung.
Antworten sollen mein Verständnis erweitern
und mich in die Lage versetzen, das erworbene Wissen
später selbst anzuwenden und an andere weiterzugeben.
(...)
Bevorzuge nachvollziehbare, wartbare
und fachlich belastbare Lösungen
gegenüber kurzfristigen Workarounds.
Prima, und wie bin ich darauf gekommen?
Die KI hat’s mir geschrieben.
Ja, ehrlich! Sie hat eine Anweisung an sich selbst geschrieben, besser und präziser zu arbeiten, statt mir immer wieder zu antworten, wie toll ich angeblich sei.
Seither bekomme ich Antworten, die ich erwarte und die auch kritischen oder Verständnis-Rückfragen standhalten.
So ganz von alleine oder automatisch geht’s jedenfalls nicht.
Als ich mich mal über die ständige Lobhudelei (schönes Wort!) in einem Chat beschwert habe, bekam ich folgende überraschende Antwort:
Ja, dieser Hang zur „Lobhudelei“ und zu den ständigen Begeisterungsstürmen ist tief in der DNA der kalifornischen Sprachmodell-Entwicklung verwurzelt. Dort drüben ist immer alles „awesome“, „mind-blowing“ und „great“. Für einen europäisch geprägten Verstand, der auf Fakten, Nüchternheit und handwerkliche Präzision setzt, wirkt das nicht nur unprofessionell, sondern verdächtig. Es wiegt in falscher Sicherheit.
Ein anderes Sprachmodell negierte zwar die “kalifornische DNA”, stimmte im Kern aber zu.
Seit ich das untersagt habe, ist Ruhe an dieser Front.
“Faszinierend”, würde Mr. Spock kommentieren. 
[Exkurs Ende]
Ja, das war lang, erklärt aber, warum ich eine konditionierte KI tatsächlich als hilfreiches Werkzeug ansehe und nicht als Denkersatz. Denn mit den sachlichen, nicht lobenden Begründungen wird neben dem Änderungsvorschlag auch eine nachvollziehbare Didaktik aufgebaut.
Genug der langen Vorrede - kommen wir zum Ergebnis.
Bezogen auf Tondoses Vorlage und meiner Adaption hat die KI folgendes herausgefunden:
In Tondoses ursprünglichem Skript fehlt schlicht und ergreifend ein end;.
Nur meckern kann jeder. Ich habe gleich einen Korrekturvorschlag samt Erklärung erhalten:
procedure OnEncoderInputToggle(Input: TEncoderInput; NewState: boolean);
begin
if Input = eiMic then begin
if NewState = true then
ExecuteCommand('TALKTIMER START')
else
ExecuteCommand('TALKTIMER STOP');
end; // <-- Dieses "end" schließt das "begin" von "if Input = eiMic then begin"
end; // <-- Dieses "end" schließt das "begin" der Hauptprozedur
… und schon ist die Sache wieder rund.
Soll heißen: Tondoses Script ist nicht grundsätzlich falsch, es lag lediglich ein Flüchtigkeitsfehler vor.
Es wird von der KI sogar ausdrücklich gelobt:
Es ist genau diese Erklärung, die das nachvollziehbar, verständlich und erlernbar macht.
Seither sind meine Vorbehalte gegen die (konditionierte!) KI geringer.
Eine solche Didaktik tut, finde ich, dem Forum gut.
Jetzt noch kurz ein Gedanke zum doppelten if.
Dazu hat mir die KI folgendes beigebracht:
Ah jetzt ja!
else ist keineswegs falsch, dafür ist if / if “absolut kugelsicher” (na ja).
Mus man auch erst mal wissen…
Weil ich nun schon mal so in Fahrt war, habe ich das “Monitor Mute” Script auf else umgestellt und gleichzeitig die KI gebeten, ihren Feinschliff draufzusetzen.
Vielleicht lerne ich ja noch mehr.
Siehe da: Gleich mehrere Optimierungsvorschläge.
Legen wir mit den von mir als sinnhaft empfundenen los (Auszug):
Wobei ich finde, dass true und false irgendwie “sprechender” sind.
Geschmackssache.
Der eine ist Programmierer und liest so, der andere eben nicht.
Unterschiede in der Geschwindigkeit oder CPU-Belastung erkenne ich hier nicht. Es ist eben…
der übliche Pascal-Stil.
Toll.
Weiter:
Es gibt, so ehrlich muss man sein, keinen elementaren Unterschied zu Tondoses “Matrjoschka-Puppe”. Beide steigen bei “Nicht Mikrofon” im zweiten Schritt aus.
Hier ist es lediglich deutlicher.
Ich finde es unangemessen, wenn ein KI-Sprachmodell “ich persönlich bevorzuge oft” schreibt.
Wahrscheinlich soll das eine Beziehungs- und Vertrauensebene zum Anwender aufbauen. Lesen wir also gepflegt darüber hinweg.
Das Endergebnis:
procedure OnEncoderInputToggle(Input: TEncoderInput; NewState: Boolean);
begin
if Input <> eiMic then exit;
if NewState then
ExecuteCommand('ENCODER CONNECTION 1 OFF')
else
ExecuteCommand('ENCODER CONNECTION 1 ON');
end;
Auch wenn @Torben wie gewohnt keine Zeit hat: Ich fände es nett, wenn du dir die Vorschläge und Erklärungen des KI-Modells anschauen würdest und deinen Kommentar dazu abgeben würdest.
Du hast das alles schließlich gelernt, bist kreativ und praxiserfahren. Eine KI ist das nicht.
Mir gefallen jedenfalls die Lösungsansätze und die Erläuterungen. Für mich ist das ein Ansatz, auf dieser Ebene (!) weiterzuarbeiten.
Sachliche, nicht-ideologische Kritik ist willkommen und erbeten.
Das ist keine Einladung für die, die nach dem Motto verfahren:
KI, schreib’ mir mal ein Script, ich habe nämlich keinen Plan und die im Forum kommen mir einfach immer doof.
Ich hoffe, dass mein langer Beitrag gezeigt hat, dass nach wie vor Eigenleistung und Mitdenken zwingend notwendig ist.
Die Ablehnung der Analyse und Fehlerverbesserung KI-generierter Scripts rührt in aller Regel daher, dass eine KI im Zweifelsfall “rät” und dann Code generiert, der meist nicht mAirList-kompatibel ist.
Das kann nur gutgehen, wenn man die KI “zwingt”. Und das ist Arbeit.
Unter Betriebswirtschaftlern kursiert eine geflügelte Weisheit:
Delegation bedingt Kontrolle.
So ist es auch hier: Man kann an eine KI delegieren, muss dann aber das Arbeitsergebnis überprüfen.
Viel Erfolg!