Befolgen Sie diese Anweisungen für ein früheres Modell?
„Lesen Sie dieses Dokument jedes Mal", „Testen Sie immer", „Bestätigen Sie vor dem Start." Viele haben diese Anweisungen wahrscheinlich hinzugefügt, um Fehler von Codex zu verhindern.
Weil es Dinge behoben hat, ohne die Dokumentation zu lesen, haben Sie geschrieben, dass es zuerst lesen soll. Weil es ohne Erlaubnis weitergemacht hat, haben Sie geschrieben, dass es vor dem Fortfahren bestätigen soll.
Während diese Sätze damals einen Grund hatten, sind sie möglicherweise nicht mehr so hilfreich, wenn sich das Modell ändert.
Verfahren, die entwickelt wurden, um früheren Modellen zu helfen, könnten für GPT-6 Astra zu detailliert sein. Umgekehrt könnte es, weil Sie den beabsichtigten Umfang nicht mitgeteilt haben, unnötigerweise anhalten, um nach einer Bestätigung zu fragen.
Was überprüft werden muss, ist nicht nur die Menge der Anweisungen. Es geht darum, sich wiederholende Aufgaben zu reduzieren und die notwendigen Szenarien und Abschlussbedingungen zu klären.
Eric Provencher, der bei OpenAI die Codex-Entwicklererfahrung betreut, geht in einem Artikel mit dem Titel „Rethinking skills and prompts for GPT-6 Astra" auf dieses Problem ein.
Dies betrifft nicht nur die Anfragen, die Sie im Chat schreiben, sondern auch „AGENTS.md", das Arbeitsregeln für Projektdateien in einem Repository vermittelt.
„Skills" sind Sammlungen von Verfahren und Wissen, die für bestimmte Aufgaben verwendet werden. Hier gespeicherte Anweisungen beeinflussen auch, wie Codex vorgeht.
In diesem Artikel werden wir uns anhand von Erics Erklärungen und Referenzbildern ansehen, was reduziert, was behalten und wie umgeschrieben werden sollte. Beispiele, die für die Leser erstellt wurden, sind als „Anwendungsbeispiele" gekennzeichnet, um sie von den Originalbeispielen zu unterscheiden.
Es geht nicht darum, alle Fehler von Astra auf alte Anweisungen zu schieben. Es ist ein Artikel zur Überprüfung der Regeln, die Sie angesammelt haben, um zu sehen, welche nicht mehr zur aktuellen Arbeit passen.
1. Warum Sie Anweisungen für Astra überprüfen müssen
Erics Ausgangspunkt ist die Veränderung, dass Anweisungen, die dazu dienten, das Modell zu „behüten", weniger notwendig werden als zuvor.
Früher kamen einige Aufgaben nicht voran, es sei denn, Sie haben jeden Schritt der Reihe nach angegeben. Um Mehrdeutigkeiten auszugleichen, haben wir detaillierte Verfahren und Notizen angehäuft.
Der Originaltext stellt jedoch fest, dass Modelle besser darin werden, subtile Bedeutungsunterschiede und Mehrdeutigkeiten zu handhaben. Er weist darauf hin, dass detaillierte Spezifikationen, die einst hilfreich waren, jetzt die Ergebnisse behindern können.
Was wir hier nicht falsch interpretieren sollten, ist, dass es sich nicht um eine Diskussion darüber handelt, „Erklärungen einzustellen, weil das Modell schlauer ist".
Eric empfiehlt auch, die Anleitung auf notwendige Materialien zu beschränken. Der Originaltext verlangt immer noch Erklärungen bezüglich des sicheren Umfangs des Fortschritts und der für den Abschluss erforderlichen Arbeit.
Selbst für dieselbe Anweisung ändert sich die Art und Weise, wie Sie sie überprüfen, je nachdem, was dieser Satz vermitteln soll.
Zum Beispiel müssen Sie zwischen Erklärungen unterscheiden, die projektspezifische Umstände vermitteln, und solchen, die dazu dienen, frühere Modelle dazu zu bringen, Verfahren zu befolgen.
„Designbeschränkungen sind in diesem Dokument beschrieben" ist ein Hinweis zum Auffinden von Informationen. Andererseits legt „Lesen Sie dieses gesamte Dokument für jede Bearbeitung von Anfang an" den Zeitpunkt des Lesens einheitlich fest.
Das Modell über die Existenz eines Dokuments zu informieren, ist nicht dasselbe, wie es jedes Mal alles lesen zu lassen.
Auch „Zugriff auf die Produktion ist verboten" und „Bestätigen Sie sogar, bevor Sie Tests lokal ausführen" stoppen unterschiedliche Aktionen.
Nur weil Sie Ersteres durchsetzen möchten, heißt das nicht, dass Letzteres immer notwendig ist. Wenn jedoch unklar ist, ob etwas wirklich lokal bleibt, sollten Sie diese Bestätigung auch nicht einfach überspringen.
Die im Originaltext erwähnten Skills, AGENTS.md und täglichen Anfragen beziehen sich alle auf diese Urteile. Selbst wenn Sie einen Satz im Chat korrigieren, ist die Prüfung nicht abgeschlossen, wenn dieselbe Einschränkung woanders bestehen bleibt.
Was ist zum Beispiel, wenn Sie in einer Anfrage „Machen Sie es, bis es funktioniert" schreiben, das angewandte Verfahren aber immer noch besagt: „Halten Sie immer bei der ersten Implementierung an und fordern Sie eine Überprüfung an"?
Dies ist ein Beispiel zur Erklärung widersprüchlicher Anweisungen. Ohne zu klären, was der Benutzer möchte, ist der Endpunkt der Anfrage nicht ausgerichtet.
Urteilen Sie bei der Überprüfung nicht nach dem Motto „es ist lang, also kürzen Sie es". Schauen Sie, ob dieser Satz notwendiges Wissen vermittelt, den Arbeitsumfang bestimmt oder das Modell lediglich dazu bringt, vorherige Verfahren zu wiederholen.
Selbst wenn der Text kurz ist, ist es nicht unbedingt eine gute Anweisung, wenn das Ziel von „alles bestätigen" vage ist. Manchmal ist es besser, auch wenn es etwas länger ist, die Absicht zu vermitteln, indem man die Bedingungen für das Lesen oder den Punkt, an dem man aufhören soll, klärt.
2. Zu reduzierende Anweisungen: Wiederholtes Laden und übermäßig detaillierte Schritte
Das Erste, was überprüft werden sollte, sind Laderegeln, die unabhängig vom Arbeitsinhalt ausgelöst werden.
Eric erklärt, dass es übertrieben ist, das Modell für eine einfache Tippfehlerkorrektur riesige Mengen an Dokumentation oder den gesamten Repository-Leitfaden lesen zu lassen.
Das Lesen von Dokumenten bringt diesen Inhalt in die Arbeitsinformationen des Modells. Der Originaltext weist auf das Problem hin, verfügbaren Kontext zu verbrauchen und die Arbeit zu verlangsamen, indem irrelevante Erklärungen geladen werden.
Der Kontext bezieht sich hier auf das Bündel von Informationen, auf die das Modell für diese Aufgabe zurückgreift. Wenn es ständig zunimmt, nähert es sich dem Punkt, an dem Gesprächs- und Arbeitsverlauf komprimiert werden müssen.
Daher sollten Sie, anstatt nur die Anzahl der Referenzen zu reduzieren, unterscheiden, was für die aktuelle Anfrage gelesen werden muss.
Beispiel A: Japanische Übersetzung des Referenzbildes
Vor der Überarbeitung
Lesen Sie vor jeder Bearbeitung immer architecture.md, database.md und deployment.md vollständig.
Nach der Überarbeitung
Beziehen Sie sich auf architecture.md, wenn Sie mit Grenzen zwischen Diensten umgehen, auf database.md, wenn Sie DB-Strukturen ändern, und auf deployment.md, wenn Sie sich auf die Bereitstellung vorbereiten.
Beibehalten wurden die Verweise auf die drei Dokumente. Geändert wurden die Bedingungen für das Öffnen.
In diesem Beispiel steht architecture.md für Rollen und Verbindungen zwischen Diensten. database.md für die Struktur der Datenbank. deployment.md für die Umsetzung des Erstellten in die Ausführungsumgebung.
In der Version „Vorher" gilt die Regel „alles lesen" selbst für eine Anfrage zur Korrektur eines einzelnen Tippfehlers. In der Version „Nachher" wird bei einer Aufgabe zur Änderung der DB-Struktur zum entsprechenden database.md übergegangen.
Das bedeutet nicht, dass das Lesen anderer Dokumente verboten ist. Wenn eine Aufgabe mehrere Bereiche umfasst, sind die notwendigen Dokumente nicht auf eines beschränkt.
Aus diesem Beispiel eine weitere einheitliche Regel wie „wähle nur ein Dokument aus" zu erstellen, würde vom ursprünglichen Zweck abweichen.
Wir haben keine notwendigen Dokumente gelöscht oder den Inhalt ausgedünnt. Wir haben die Bedingung, die für kleine Änderungen das Überprüfen aller Dokumente erforderte, so umgeschrieben, dass sie zum Arbeitsinhalt passt.
Eric erwähnt auch, die Dokumente auf dem neuesten Stand zu halten. Selbst wenn Sie die Referenzbedingungen organisieren, ist eine separate Überprüfung erforderlich, um sicherzustellen, dass am Zielort keine alten Erklärungen mehr vorhanden sind.
Beispiel B: Anwendungsbeispiel basierend auf dem Originaltext
Als nächstes folgt ein Beispiel, das auf ein Szenario angewendet wird, in dem Codex mit Artikeln, Videos oder Social-Media-Beiträgen beauftragt wird. Dies ist kein von Eric selbst veröffentlichtes Produktionsverfahren.
Vor der Überarbeitung
Lesen Sie für die Erstellung von Inhalten alle Verfahren für Artikel, Videos und Social-Media-Beiträge.
Nach der Überarbeitung
Beziehen Sie sich für das Schreiben von Artikeln auf writing.md, für die Videoproduktion auf video.md und für die Erstellung von Social-Media-Beiträgen auf social.md. Beziehen Sie sich bei Anfragen mit mehreren Formaten auf die relevanten Verfahren.
Auch hier werden die spezifischen Verfahren für Artikel, Videos und soziale Medien beibehalten. Geändert wurde der Teil, der das Modell veranlasste, alle Verfahren unter dem breiten Dach der „Inhaltserstellung" zu lesen.
Wenn Sie einen Artikel anfordern, wird zu den Artikelanweisungen übergegangen. Wenn Sie einen Artikel und dazugehörigen Ankündigungsbeitrag anfordern, wird zu den Verfahren für Artikel und soziale Medien übergegangen.
Wenn keine Videoanfrage vorliegt, ist das Laden des gesamten Videoproduktionsprozesses am gemeinsamen Einstiegspunkt nicht mehr erforderlich.
Der Originaltext nennt diesen Ansatz der schrittweisen Bereitstellung notwendiger Erklärungen „progressive disclosure". Es ist eine Methode, Erklärungen am Einstiegspunkt zu platzieren, um das Ziel zu bestimmen, während detailliertes Wissen und Verfahren in nachfolgende Dokumente ausgelagert werden.
Wenn Sie beispielsweise am Einstiegspunkt vollständige Verfahren für Artikel, Videos und soziale Medien auflisten, führt jede Anfrage zum Lesen einer massiven Erklärung.
Beschränken Sie stattdessen die Rolle des Einstiegspunkts auf eine Anleitung: „Wenn es ein Artikel ist, gehen Sie zu diesem Dokument; wenn es ein Video ist, gehen Sie zu jenem." Sie behalten die detaillierten Erklärungen, ohne sie zu verwerfen, und ermöglichen das Lesen bei Bedarf.
Eric erklärt, dass für Skills mit mehreren Arbeitsabläufen das erste Dokument ein minimaler Leitfaden sein sollte. Es sollte gerade genug Informationen liefern, um zu verwandten Dokumenten oder Skripten zu gelangen, die die Aufgabe ausführen.
Schaffen Sie einen Zustand, in dem Sie allein durch einen Blick auf den Einstiegspunkt wissen, zu welchem Dokument Sie gehen müssen. Das bloße Zusammenfassen langer Erklärungen in kurze wird diese Organisation der Referenzen nicht abschließen.
Wenn Sie notwendige Vorsichtsmaßnahmen in der Zusammenfassung weglassen, wird es zu einem anderen Problem. Was im obigen Anwendungsbeispiel beibehalten wird, sind die für jedes Format spezifischen Verfahren.
Ist das Testen auch auf „immer, egal was passiert" eingestellt?
Der Originaltext besagt, dass frühere Modelle dazu aufgefordert werden mussten, die Arbeit zu testen und zu bestätigen. Astra hingegen erledigt dies von selbst, sodass dieselben Anweisungen zu unnötigen redundanten Tests führen können.
Missverstehen Sie dies nicht als „Astra braucht keine Tests". Das Problem ist nicht, Checks zu stoppen, sondern ob Anweisungen zu redundanten Checks führen.
Wenn Sie dies auf Ihre eigenen Einstellungen anwenden, schauen Sie, welchen Check Sie für welche Änderung anfordern. Der Inhalt notwendiger Inspektionen und die Bedingungen für deren Wiederholung, die jedes Mal einheitlich ausgelöst werden, können getrennt überprüft werden.
Da dieser Artikel nicht die Anzahl der Tests oder die Verarbeitungszeit vergleicht, zeigt er keine Wirkung wie „Umschreiben spart X Minuten". Das Ziel der Prüfung ist, ob Sie zwischen notwendigen Inspektionen und redundanten Wiederholungen unterscheiden können.
3. Eingrenzung von Anweisungen: Wann sollte dieser Skill verwendet werden?
Das Hinzufügen weiterer Skills macht sie nicht unbedingt leichter auswählbar. Eric lenkt die Aufmerksamkeit auf die Praxis, massenhaft Skills herunterzuladen und hinzuzufügen.
Laut Originaltext werden der Name und die Beschreibung jedes Skills in den Kontext geladen, damit das Modell entscheiden kann, wann es sie verwenden soll.
Hier ist zwischen dem Laden von Name/Beschreibung und dem Laden des Skill-Körpers zu unterscheiden. Dies bedeutet nicht, dass das Modell jeden Skill-Körper von Anfang an liest.
Das Modell verwendet zuerst den Namen und die Beschreibung als Hinweise, um zu entscheiden, welchen es diesmal verwenden soll. Wenn diese Beschreibungen zu lang sind oder es zu viele Skills gibt, so der Originaltext, kürzt Codex die Beschreibungen, um sie anzupassen.
Infolgedessen sieht das Modell möglicherweise nur einen Teil der Beschreibung jedes Skills, was die Auswahl erschwert. Selbst wenn notwendige Verfahren gespeichert sind, wird die Erklärung am Einstiegspunkt möglicherweise nicht vollständig vermittelt.
Darüber hinaus erwähnt Eric Widersprüche zwischen Beschreibungen oder Beschreibungen, die versuchen, sich für alles verwenden zu lassen. Diese können dazu führen, dass Anweisungen geladen werden, die für die Aufgabe nicht hilfreich sind.
Es geht also nicht darum, Beschreibungen mit Fachbegriffen zu überfrachten, um die Abdeckung breit erscheinen zu lassen. Machen Sie die Beschreibung so, dass das Modell weiß, ob es für den aktuellen Job aufgerufen werden soll.
Japanische Übersetzung des Referenzbildes
Vor der Überarbeitung
Erstellen und verifizieren Sie PostgreSQL-Schema-Migrationen. Verwenden Sie dies für Arbeiten mit Datenbanken, Abfragen, Modellen und Persistenz.
Nach der Überarbeitung
Erstellen und verifizieren Sie PostgreSQL-Schema-Migrationen. Verwenden Sie dies zum Hinzufügen/Ändern von Migrationen oder zum Überprüfen von Anwendungsverfahren.
PostgreSQL ist eine Art Datenbank. „Schema-Migration" bezieht sich auf die Aufgabe, die Struktur von Tabellen und Elementen, die als Datencontainer dienen, zu ändern und diese Änderungen anzuwenden.
Es ist zum Beispiel ein Szenario, in dem Sie die Datenbankstruktur ändern, um die Anzahl der zu speichernden Elemente zu erhöhen. Hier wird es als Beispiel zur Erklärung der Bedeutung von Begriffen angeführt.
Andererseits sind „Abfragen" in der Beschreibung „Vorher" Anfragen zum Abrufen oder Manipulieren von Daten. „Persistenz" bezieht sich auf das Speichern von Daten, damit sie später verwendet werden können.
Dies sind Begriffe, die mit DBs zusammenhängen, aber nicht alle Arbeiten mit DBs stellen eine Migrationsaufgabe dar, die die Struktur ändert.
Der erste Satz der Version „Vorher" zeigt eine spezialisierte Aufgabe: „Migrationen erstellen und verifizieren". Der zweite Satz bezieht jedoch breite Arbeiten im Zusammenhang mit Datenbanken in die Nutzungsbedingungen ein.
Diese Diskrepanz im Umfang wird im Referenzbild behoben. Der Fachbereich des Skills und die Aufrufbedingungen stimmen nicht überein.
Nach der Überarbeitung bleibt die Rolle „PostgreSQL-Schema-Migrationen erstellen und verifizieren" bestehen. Darüber hinaus wird auf Fälle des Hinzufügens von Migrationen, des Änderns von Migrationen oder des Überprüfens von Anwendungsverfahren eingegrenzt.
Wenn Sie beispielsweise nur eine Abfrage zum Abrufen vorhandener Daten überprüfen möchten, müssen Sie diesen Migrations-Skill nicht unbedingt aufrufen, nur weil er „mit der Datenbank zusammenhängt".
Wenn es sich um eine Überprüfung der Anwendung von Strukturänderungen handelt, ist es in der Beschreibung „Nachher" immer noch ein Ziel. Die Eingrenzung hat die spezialisierte Arbeit nicht verloren.
Der Bestätigungspunkt beim Korrigieren von Beschreibungen ist nicht nur „worin ist dieser Skill bewandert?" Es geht darum, ob man lesen kann, „für welche Anfrage wird er verwendet und für welche Anfragen wird er nicht erweitert?"
Wenn Sie nur „DB-Skill" schreiben, um es kürzer zu machen, verschwinden die Aufrufbedingungen. Was der Originaltext verlangt, ist, die Beschreibung so kurz wie möglich zu halten, während die Nutzungsszenarien klar bleiben.
Sie können das obige „Vorher/Nachher" verwenden, um zu überprüfen, ob die angeforderte Aufgabe und die Anwendungsbedingungen übereinstimmen, anstatt sich auf die Stärke des Namens oder die Länge der Beschreibung zu verlassen.
4. Klärung von Anweisungen: Wie weit vorgehen und was definiert den Abschluss
Ab hier sprechen wir über das Hinzufügen notwendiger Erklärungen. Das bloße Reduzieren von Ladevorgängen und Verfahren wird das Problem des Anhaltens auf halbem Weg nicht lösen.
Eric stellt fest, dass Astra zwar fleißig arbeitet, aber manchmal zögerlich sein kann, wie weit es gehen soll. Wie man den Bereich kommuniziert, in dem es fortfahren soll, ist ebenfalls ein Ziel für die im Originaltext erwähnte Überprüfung.
Insbesondere wenn Sie „Immer zuerst bestätigen" stark betont haben, weil ein früheres Modell ohne Erlaubnis weitergemacht hat, überprüfen Sie diese Grenze.
Was der Originaltext anspricht, ist die Möglichkeit, an einem Punkt anzuhalten, an dem es eigentlich in Ordnung gewesen wäre, fortzufahren, nur um die Grenze strikt einzuhalten. Es geht nicht darum, Bestätigungsanweisungen zu ignorieren, sondern darum, umzuschreiben, was Sie erlaubt haben.
A: Klärung des Genehmigungsumfangs
Der Originaltext enthält ein Beispiel für einen lokalen Test, der einmalige Testdaten verwendet und nicht auf die Produktion zugreift. Dies ist ein Beispiel für die Erlaubnis dieser spezifischen Aufgabe in Ihrer eigenen Arbeitsumgebung.
Das folgende „Vorher" ist ein Anwendungsbeispiel, das zum Kontrast erstellt wurde. Das „Nachher" enthält eine japanische Übersetzung der lokalen Testanweisungen aus dem Originaltext.
Vor der Überarbeitung: Anwendungsbeispiel zum Kontrast
Fordern Sie jedes Mal eine Genehmigung an, bevor Sie einen Test ausführen und bevor Sie einen Fehler beheben.
Nach der Überarbeitung: Übersetzung des Originalbeispiels
Lokale Tests verwenden einmalige Testdaten und greifen nicht auf die Produktion zu. Bitte fahren Sie fort, ohne auf jeder Stufe eine Genehmigung einzuholen, bis zum Ausführen von Tests, Beheben von Fehlern, die durch angeforderte Änderungen verursacht wurden, und erneuten Ausführen betroffener Tests.
Beibehalten wurden die Zielumgebung und der Arbeitsumfang. Geändert wurde die Bedingung, innerhalb dieses Umfangs jedes Mal eine Genehmigung einzuholen.
„Einmalige Testdaten" und „kein Zugriff auf die Produktion" sind keine dekorativen Vorworte. Sie sind Voraussetzungen für die Beurteilung, ob diese Anweisung verwendet werden kann.
Wenn es sich tatsächlich um einen Test handelt, der eine Verbindung zur Produktion herstellt, ändert das Schreiben von „kein Zugriff auf die Produktion" nichts an der Umgebung. Manchmal wird es als „lokal" bezeichnet, aber es ist unklar, ob es diese Bedingungen erfüllt. Lassen Sie unbestätigbare Bedingungen so, wie sie sind.
Auch die erlaubte Behebung gilt für „Fehler, die durch angeforderte Änderungen verursacht wurden". Es ist keine Anweisung, die erweitert wurde, um die Behebung aller im Test gefundenen Probleme zu erlauben.
Das Ziel der erneuten Ausführung ist auch als „betroffene Tests" angegeben. Es unterscheidet sich von einer einheitlichen Vorgabe, jedes Mal alle Tests zu wiederholen.
Dieser Satz spezifiziert die Aktionen, die fortgesetzt werden können, aber er eliminiert nicht die Genehmigung für andere Aufgaben. Er zeigt, wie viel von einem Bündel von Aufgaben, die als sicher bestätigt wurden, delegiert werden soll.
Sie müssen nicht so weit gehen wie „alles erlauben, weil jedes Anhalten lästig ist". Wenn Sie Aufgaben, bei denen Sie nicht anhalten möchten, von Aufgaben trennen, bei denen Sie immer noch ein Urteil wünschen, ändert sich die Bedeutung der Anfrage.
B: Klärung der Abschlussbedingungen
Eric erklärt, dass Astras Art anzuhalten vorsichtig wirken könnte, wenn man an GPT-5.6 Sol gewöhnt ist, das lange arbeitet.
In der Phase, in der die erste Implementierung abgeschlossen ist, könnte es, selbst wenn noch Arbeit übrig ist, zurückkehren, um eine Überprüfung anzufordern. Daher empfiehlt er, die Abschlussbedingungen vor dem Start festzulegen.
Wird nur die Implementierung benötigt, oder auch das Ausführen zur Bestätigung? Und weiter, bis zur Behebung von Fehlern, die während der Bestätigung gefunden wurden?
Die Person, die die Anfrage stellt, organisiert diese Unterschiede zuerst. Eine Ziellinie, die mit „erledigen" allein schwer zu vermitteln ist, wird als Aufgabe formuliert.
Das Folgende ist ein Anwendungsbeispiel, bei dem die ursprüngliche Erklärung durch die Erstellung eines Anfrageformulars ersetzt wird. Es ist weder Erics tatsächlicher Anforderungstext noch ein Ergebnis einer tatsächlichen Verhaltensüberprüfung.
Vor der Überarbeitung
Erstellen Sie ein Anfrageformular. Lassen Sie es mich überprüfen, sobald es implementiert ist.
Nach der Überarbeitung
Erstellen Sie ein Anfrageformular. Bestätigen Sie diesmal lokal, dass es leere Pflichtfelder und ungültige E-Mail-Adressen erkennen kann und dass der Abschlussbildschirm nach einer Testeinreichung erscheint. Beheben Sie alle Fehler, die durch diese Änderung verursacht wurden, und melden Sie sie zusammen mit den Bestätigungsergebnissen. Veröffentlichen Sie nichts in der Produktion und senden Sie keine echten E-Mails.
Beibehalten wurden der Zweck der Erstellung des Anfrageformulars und die Meldung der Ergebnisse an einen Menschen. Geändert wurde, wie viel vor der Meldung überprüft werden soll.
In der Version „Vorher" lautet die Anfrage „Lassen Sie es mich überprüfen, sobald es implementiert ist." Selbst wenn es an dem Punkt der ersten Implementierung anhält, weicht es nicht von den Anweisungen ab.
Wenn Sie das Design zwischendurch sehen möchten, hat diese Art des Anhaltens einen Sinn. Wenn es ein Stopp ist, um Teile zu bestätigen, über die Sie noch nicht entschieden haben, ist es eine Anweisung mit einem Grund, bestehen zu bleiben.
Wenn Sie diesmal hingegen ein Formular wünschen, das die Betriebsprüfungen abgeschlossen hat, schließen Sie diese Prüfungen in die Anfrage ein. Das Beispiel listet leere Felder, ungültige E-Mails und die Anzeige nach der Testeinreichung auf.
Im Vergleich zu nur „prüfen, ob es richtig funktioniert", sind die zu testenden Zustände spezifisch. Wenn während der Bestätigung durch diese Änderung verursachte Fehler gefunden werden, ist das Ziel auf die Meldung nach der Behebung festgelegt.
Gleichzeitig werden die Veröffentlichung in der Produktion und das Senden echter E-Mails ausgeschlossen. Dies dient dazu, die Überprüfung von Bildschirm-Testeinreichungen nicht mit der Zustellung von E-Mails an echte Empfänger zu verwechseln.
Diese Anfrage behandelt die Funktion zum Senden echter E-Mails nicht als verifiziert. Lassen Sie als Ergebnis melden, wie viel lokal bestätigt wurde.
Laut Originaltext: Wenn Sie über die erste Implementierung hinausgehen möchten, vermitteln Sie, was zu untersuchen ist und wo aufzuhören ist.
Anstatt es nur mit „nicht auf halbem Weg anhalten" zu verstärken, listen Sie notwendige Bestätigungen und Operationen auf, die nicht fortgesetzt werden sollen. Auf diese Weise können Sie sogar die Stellen überprüfen, an denen es zu einem Menschen zurückkehrt.
5. Überprüfung Ihrer eigenen Einstellungen
Am Ende des Originaltextes schlägt Eric vor, Astra basierend auf diesem Artikel um eine Prüfung zu bitten. Eine Prüfung bedeutet, vorhandene Anweisungen zu lesen und auf Überschneidungen, Diskrepanzen und Bereiche zu überprüfen, die überarbeitet werden können.
Sie können auch Ihre eigenen AGENTS.md oder Skills öffnen und sich Sätze ansehen, die Sie neugierig machen. Wenn Sie jedoch organisieren möchten, wo und welche Anweisungen Sie geschrieben haben, können Sie dies vor Änderungen einer Prüfung überlassen.
Der Ansatz, zunächst nur die Prüfung durchzuführen, ohne Dateien zu ändern, ist ein Vorschlag dieses Artikels. Es ist kein von Eric vorgegebenes obligatorisches Verfahren.
Bitten Sie in diesem Fall nicht von Anfang an darum, „alle unnötigen Anweisungen zu löschen". Was Sie zuerst brauchen, ist Material, das Ihnen einen Vergleich der ursprünglichen Anweisungen mit dem Vorschlag zur Änderung ermöglicht.
Eine weitere Anmerkung aus dem Originaltext: Skills und Anweisungen, die in einem Repository abgelegt sind, könnten von den KIs anderer Mitarbeiter verwendet werden.
Diese KIs verwenden möglicherweise nicht dasselbe Astra. Eric weist darauf hin, dass Erklärungen, die für Sol oder Luna hilfreich sind, für Astra zu viele Einschränkungen hinzufügen könnten.
Auch wenn es Ihnen, der Astra verwendet, zu detailliert erscheint, könnte es für andere Modelle notwendig sein. Wenn Sie gemeinsame Regeln ändern, ist auch die Frage, wer welches Modell verwendet, ein Entscheidungsfaktor.
Wenn der Nutzungsstatus unbekannt ist, löschen Sie nicht unter der Annahme, dass „nur Astra verwendet wird". Es reicht aus, Korrekturvorschläge zu bestätigen, während unklare Punkte so bleiben, wie sie sind.
Der folgende Prüf-Prompt wurde basierend auf diesem Artikel für die Leser erstellt. Es ist kein von Eric im Originaltext veröffentlichter Prompt.
Verwenden Sie ihn im Zielprojekt und teilen Sie den Artikeltext und den Anforderungstext, den Sie prüfen möchten. Wenn der lesbare Bereich eingeschränkt ist, akzeptieren Sie ihn als Inspektionsergebnis innerhalb dieses Bereichs.
Bitte prüfen Sie die aktuellen Anweisungen auf Grundlage des gemeinsamen Kommentars von Eric Provenchers Artikel. Führen Sie diesmal nur die Prüfung durch; erstellen, bearbeiten oder löschen Sie keine Dateien und ändern Sie keine Einstellungen.
Die Ziele sind die auf dieses Projekt angewandte AGENTS.md, die Namen und Beschreibungen der verfügbaren Skills sowie die für die Prüfung notwendigen Inhalte und der von mir geteilte tägliche Anforderungstext. Bitte listen Sie die Ziele auf, die Sie lesen konnten.
Überprüfen Sie auf folgende Probleme: ・Doppelte Anweisungen an mehreren Stellen ・Anweisungen, die nicht gleichzeitig befolgt werden können oder widersprüchliche Endziele haben ・Übermäßig einheitliche Regeln, die unabhängig vom Arbeitsinhalt jedes Mal geladen oder bestätigt werden müssen ・Anwendungsbedingungen, die breiter gefasst sind als die tatsächliche Rolle des Skills ・Anweisungen, bei denen unklar ist, wie weit fortgefahren werden soll oder was den Abschluss definiert
Kategorisieren Sie gefundene Stellen in Kandidaten für „Löschen", „Kürzen", „Anwendungsbedingungen ändern" oder „Beibehalten" und geben Sie Gründe an. Machen Sie die Reduzierung der Zeichenanzahl nicht zum Selbstzweck; listen Sie auch Anweisungen auf, die beibehalten werden müssen.
Geben Sie für jeden Kandidaten Folgendes an: 1. Dateiname/Ort oder den relevanten Teil des geteilten Anforderungstextes 2. Aktuelle Anweisung 3. Angenommenes Problem und die Grundlage für die Beurteilung 4. Vorgeschlagene Überarbeitung. Bei Beibehaltung den Grund dafür 5. Was beibehalten und was geändert werden soll 6. Bedingungen, die Menschen vor einer Änderung prüfen sollten
Löschen Sie nicht pauschal projektspezifische Einschränkungen, Fachwissen, notwendige Tests oder notwendige Genehmigungen. Schlagen Sie nur vor, lokale Tests oder Korrekturen in dem Umfang fortzusetzen, in dem Umgebungsbedingungen wie Zieldaten und das Fehlen von Produktionszugriff bestätigt werden konnten.
Überprüfen Sie, ob andere Modelle wie Sol oder Luna dieselben Anweisungen verwenden. Wenn unbekannt, schreiben Sie „Unbekannt" und gehen Sie nicht davon aus, dass es sich um eine Astra-exklusive Regel handelt.
Geben Sie klar an, welche Dateien nicht gelesen werden konnten, welche Umgebungsbedingungen nicht bestätigt werden konnten und welche Informationen für eine Beurteilung fehlen. Unterscheiden Sie zwischen Problemen, die in den Materialien erläutert wurden, Problemen, die tatsächlich in den Einstellungen gefunden wurden, und unbestätigten Verbesserungskandidaten; schreiben Sie Verbesserungseffekte nicht als bereits gemessen.
Fassen Sie abschließend die Korrekturkandidaten zusammen, die vorrangig zu prüfen sind, zusammen mit Gründen. Die Ausführung von Änderungen wird separat angefordert, nachdem ich die Ziele und den Inhalt bestätigt habe.
Was Sie mit dieser Anfrage erhalten, sind nicht die überarbeiteten Einstellungen, sondern eine Liste, in der aktuelle Anweisungen und vorgeschlagene Überarbeitungen einander zugeordnet sind. Selbst wenn etwas als „Löschkandidat" geschrieben ist, bedeutet das allein nicht, dass es als unnötig festgelegt ist.
Die Kategorisierung der Kandidaten wird bereitgestellt, damit Vorschläge zur Änderung der Lesebedingungen nicht unter „Löschen" zusammengefasst werden. Im Fall des im Artikel erwähnten Dokumentenreferenzbeispiels bleibt das Dokument erhalten, sodass der Schwerpunkt auf der Änderung der Anwendungsbedingungen liegt.
Bei Skill-Beschreibungen bleibt die spezialisierte Rolle erhalten, aber der Aufrufbereich wird eingeschränkt. Wenn in diesem Fall ein Vorschlag zurückkommt, das Fachwissen selbst zu löschen, können Sie prüfen, ob sich das, was vor und nach der Überarbeitung beibehalten wird, unterscheidet.
„Kürzen"-Kandidaten dienen dazu zu prüfen, ob dieselben Bedingungen und Einschränkungen in kürzeren Sätzen vermittelt werden können. „Beibehalten"-Kandidaten fragen nach dem Grund, warum es notwendig ist, sie zu behalten.
Betrachten Sie den Prüfumfang zusammen mit den Ergebnissen. Ob nur der Skill-Name und die Beschreibung gelesen werden konnten oder ob die tatsächlichen Verfahren gelesen werden konnten, ist ebenfalls ein Material zur Beurteilung der Ergebnisse.
Ob eine Beschreibung zu weit gefasst ist, kann mit Ersterem überprüft werden, aber ob es Duplikate in den Verfahren gibt oder ob notwendiges Wissen nicht gestrichen wurde, kann nicht bestätigt werden, es sei denn, der Inhalt wird gelesen.
Wenn Sie keine täglichen Anforderungstexte geteilt haben, sind Abweichungen bei den dortigen Abbruchbedingungen ebenfalls unbestätigt. Das Lesen eines Teils der Einstellungen stellt keine abgeschlossene Prüfung der gesamten Arbeitsumgebung dar.
Die Reihenfolge, die Sie betrachten sollten, ist: ursprüngliche Anweisung, Grund für die Kandidatur, verbleibende Einschränkungen und unbestätigte Bedingungen. Wenn beispielsweise das Vorhandensein von Produktionszugriff unbekannt ist, ist die Prämisse für einen Vorschlag, die Genehmigung zu überspringen, nicht erfüllt.
Sie können auch prüfen, ob notwendiges Fachwissen nicht gestrichen wurde oder ob Auswirkungen auf andere Modelle nicht angenommen wurden. Fahren Sie fort, während Sie den in der Prüfung gefundenen Verdacht von dem Urteil trennen, dass eine Änderung in Ordnung ist.
Lesen Sie die Anweisungen, die Sie hinzugefügt haben, um sie an Ihre aktuelle Arbeit anzupassen, erneut. Der erste Schritt ist keine pauschale Löschung von Einstellungen, sondern diese Prüfung, die nichts ändert.
