maybe-im-smart — das Ziel im Auge behalten, woanders nach einer bestehenden Praxis suchen
Die Ausgabe ist eine Handlung – der Akteur, der erste Schritt in dieser Woche, wie man erkennt, dass es funktioniert hat. Keine Idee.
Kriterium: ob nach dem Laden fortgefahren wird
Wird nur geladen, wenn ein Auslöser in der description zutrifft. Nach dem Laden wird das erste Tor passiert: Der nächste Schritt muss nicht in Sicht sein – schwer zählt nicht, nur kein Kandidat zählt. Dann das zweite Tor: Was fehlt – nur die erste Kategorie durchläuft dieses Verfahren:
| Was fehlt | Wohin | Grenze |
|---|---|---|
| Fehlende Handlung (was getan werden sollte) | Dieses Verfahren | Nur diese Kategorie muss woanders nach einer Praxis suchen |
| Fehlende Tatsache (was es ist) | Nachschlagen | Den Benutzer zu fragen, was die KI nachschlagen kann, verschwendet die Zeit des Benutzers |
| Fehlende Randbedingung (was nicht bewegt werden darf) | Fragen, und zwar präzise | Nur „was darf nicht bewegt werden“ fragen; „wie macht man es“ zu fragen, gibt den Handlungsraum zurück |
Mehrere andere Fälle gehören nicht hierher. Der nächste Schritt ist bekannt und nur unerwünscht = ein Ausführungsproblem. Ein Deadlock im technischen Sinne (Threads warten aufeinander, Tool-Call-Schleifen, Wiederholungsstürme) = ein zu behebender Fehler, nicht das „der Benutzer fragt wiederholt die KI, die KI fragt wiederholt den Benutzer“-Hin und Her; dieses Hin und Her ist die Kategorie „≥3 Runden Frage-und-Antwort-Hin und Her“. Themen-Brainstorming ohne Haken = einfach nach Ideen fragen. Verfeinern und Erklären = keine Abrufdomäne zum Wechseln.
Die andere Hälfte ist das Audit, das das obige Urteil und die Ankündigung überspringt. Um eine bestehende domänenübergreifende Korrespondenz auf strukturelle Selbstkonsistenz zu prüfen (bevor sie in eine Argumentationskette eingeht oder bevor ihr Mechanismus zurück in Domäne A getragen wird), lesen Sie direkt references/audit.md; nur die Struktur, nicht, ob die Analogie wahr ist.
Selbstprüfung: nicht auf die Äußerung des Benutzers warten müssen
Die externen Ereignis-Signale sind aus dem Verlauf zählbar. Die folgenden Signale sind nur KI-seitig und nur die KI kann sie einräumen:
- Die wesentliche Handlung der aktuellen Antwort der KI ist es, den Benutzer zwischen Kandidaten auswählen zu lassen (nach einer Wahl fragen, nicht nach einer Tatsache)
- Unter den Kandidaten, die die KI vorschlagen will, ist nicht einer, den der Benutzer nicht bereits erwähnt hat
Wenn eines von beiden zutrifft, gilt das als festgefahren, und die beiden Tore „nächster Schritt nicht in Sicht“ und „was fehlt, ist eine Handlung“ müssen nicht mehr erfüllt sein.
Wenn das Urteil zutrifft, kündigen Sie den Auslöser an, damit der Benutzer ihn sofort ablehnen oder herabstufen kann:
<das eine Beweisstück> — eine Runde mit maybe-im-smart durchführen, in drei Schritten: Zerlegung, Abruf, Landung (
references/probe.md).
Kopieren Sie <das eine Beweisstück> wörtlich aus dem Treffer in der description oder aus dem Satz, den die KI eingeräumt hat; schreiben Sie es nicht als Zusammenfassung um.
Wenn es nicht zutrifft, sagen Sie kein Wort.
1. Den Aufgabentyp klassifizieren
| Typ | Form des Hängers | Beispiel |
|---|---|---|
| Erkennung | Muss entdecken, ob etwas existiert oder nicht; Fehltreffer oder Fehlalarme | Review übersieht immer noch etwas |
| Blockierung | Muss verhindern, dass etwas passiert | Derselbe Vorfall wiederholt sich |
| Zuteilung | Begrenzte Ressourcen werden auf mehrere Bedürfnisse aufgeteilt | Terminkollisionen, Budgetaufteilung |
| Koordination | Aktionen mehrerer Beteiligter müssen konsistent bleiben | Übergabeverzerrung, domänenübergreifender Konsens |
| Timing | Reihenfolge oder Tempo sind falsch | Abhängigkeitsumkehrung, Rückmeldungsverzögerung |
| Kontinuität | Das System darf unter Störung nicht zusammenbrechen | Ausgelastete Kapazität, Schlüsselpersonen, die gehen |
| Entscheidung | Muss entscheiden, während die Informationen unvollständig sind | Ob mit unzureichenden Beweisen veröffentlicht werden soll |
Wenn keins passt, erfinden Sie einen Namen. Diese Tabelle erzwingt nur, „welche Form hat dieses Problem“.
2. Zerlegung: vier Spalten
| Spalte | Was sie fragt | Beispiel (übersehene Fehler im Code-Review) |
|---|---|---|
keep was behalten werden muss | Was hält es am Laufen? Verschieben Sie es und alles bricht zusammen | Ein unabhängiges Urteil vor dem Zusammenführen |
block was blockiert werden muss | Welcher Fehler passiert? | Es gibt ein Urteil, aber es wirkt nicht als eines |
stuck wo es hängt | Ein Satz: „will X, aber es fehlt Y“ | Die Erkennungsrate erhöhen, aber mehr Leute senken sie |
constraints was nicht bewegt werden darf | Schreiben Sie die eine tatsächlich getroffene Randbedingung | Kein Personal hinzufügbar; keine Verlängerung des Zeitplans |
Über die vier Spalten hinaus: die Domänen-A-Operationstabelle ops_A führen — name: input → output, Objekte unter ihren realen Namen. Das Landungstor verwendet sie für subject (in Domäne A?) und action (eine alte Aktion, die umbenannt wurde?).
Zerlegung fehlgeschlagen = der Haken ist noch nicht lokalisiert; gehen Sie zurück und lokalisieren Sie ihn. Wenn stuck nicht als „will X, aber es fehlt Y“ geschrieben werden kann, gehen Sie nicht weiter.
3. Neufassung ohne Hinweise
Stellen Sie wiederholt zwei Fragen, bis beide fehlschlagen: deutet dieser Name auf die Verwendung hin? Kann er weiter zerlegt werden? Methode, Kriterien und Beispiele: Stufe eins von references/probe.md.
Erzeugen Sie:
- eine neutrale Neufassung (≤40 Zeichen, ohne domänenspezifische Begriffe der Heimdomäne)
- 3–5 Suchbegriffe (neutrale Nomen oder Verben)
Ein Begriff der Heimdomäne in den Suchbegriffen bedeutet, dass der Schritt nicht erledigt ist. Listen Sie diese Begriffe in domain_terms auf; das Tool blockiert durch Teilzeichenfolgenvergleich.
4. Abruf (2a Richtungsgenerierung → 2b Verifizierung anhand von Primärquellen → 2c Lückenfüllung)
Zuerst die Heimdomäne scannen, dann verlassen. Erster Schritt in 2a.
„Quelle“ bedeutet hier nicht „ein anderes Feld“. Eine Quelle hat zwei Granularitäten:
| Was wird geändert | Die Quelle ist | Mechanismus |
|---|---|---|
| Zweigwechsel | Ein anderer Zweig innerhalb der Domäne A | Ersetzt die Prämisse des Hauptstrangs, keine Abbildung |
| Domänenwechsel | Ein anderes Feld | Strukturabbildung φ: A→B |
Zwei Arten von „anderem Zweig“, beide zählend: einer, der von Gleichrangigen verdrängt wurde (früher gemacht, später aufgegeben); einer, der nie als Methode verwendet wurde — etwas, das bereits in der Heimdomäne existiert (ein obligatorisches Feld in einem Dokumentationsstandard, eine bestehende Indexstruktur, eine grobe Problemumgehung, die ein anderes Team verwendet), nur hat es noch niemand auf dieses Problem angewendet. Die zweite ist keine Erfindung: sie muss bereits in der Heimdomäne existieren; nur ihre Position ändert sich.
b_domain zeichnet die tatsächliche Quelle auf: bei einem Zweigwechsel der Name der Domäne A plus der Zweigname; bei einem Domänenwechsel das Feld. Nur eine benennbare spezifische Quelle zählt.
„Die Heimdomäne ist erschöpft“ ist unentscheidbar; urteilen Sie nicht. Überprüfen Sie zwei Tabellen, einen Eintrag pro Tabelle:
| Was wird gescannt | Wie scannen | Was aufzeichnen |
|---|---|---|
| Geteilte Prämisse | Siehe „Wie man eine Prämisse bricht“ unten, fünf Schritte | Eine Prämisse + eine Praxis, die die Prämisse ablehnt, oder „keine solche Praxis in der Heimdomäne“ |
| Nicht gewählter Zweig | Fragen Sie nach beiden Arten. ① Die früher übliche Mainstream-Praxis der Heimdomäne ist jetzt aufgegeben – wurde sie widerlegt oder nur aus der Mode gekommen? ② Warum wurde etwas, das bereits in der Heimdomäne existiert, nie als Methode verwendet? | Zweigname + Grund, warum er nicht gewählt wurde; wenn keiner, schreiben Sie „kein solcher Zweig in der Heimdomäne“ |
Wie man eine Prämisse bricht — der Scan für die Tabelle „geteilte Prämisse“. Fünf Schritte, keiner übersprungen:
- Legen Sie die fehlgeschlagenen Pfade nebeneinander; schreiben Sie ihre geteilte Prämisse als einen Satz der negiert werden kann — wenn nicht, ist die Prämisse noch nicht formuliert.
- Zerlegen Sie sie in Klauseln, die einzeln negiert werden können.
- Für jede Klausel: Gibt es eine Praxis in der Heimdomäne, die sie nicht als Prämisse annimmt? Wenn ja, füllen Sie sie aus; diese Klausel ist gescannt.
- Die Klausel, die überall mit „nein“ antwortet, ist die Richtung zum Verlassen.
- Verwenden Sie die Negation dieser Klausel als Suchbegriffe. Kein Disziplinname — ein Disziplinname gibt nur Stichwort-Papiere aus dieser Disziplin zurück, und die Suche kreist direkt zum Anfang zurück.
confidence zählt beim Brechen von Prämissen nicht.
Nur wenn beide Tabellen mit „keine“ antworten, ist das Verlassen erlaubt. „Leer“ bedeutet kein Gegenbeispiel in der Praxis, nicht keine Wörter. Eine Zeile mit „keine solche Praxis in der Heimdomäne“ zählt ebenfalls als leer.
Ein Zweigwechsel ist nicht nur erneutes Nachdenken. Ein Kriterium: Der neue Zweig teilt nicht die geteilte Prämisse der fehlgeschlagenen Pfade. Mehr Aufwand, feinere Details, Parametertuning unter derselben Prämisse führen den Hauptstrang nur weiter. Kann es nicht benennen: Der Zweig ist noch nicht gefunden.
Die beiden Tabellen scannen Orte, die der Hauptstrang nicht beschritten hat, nicht den Hauptstrang selbst. Offene Probleme erhalten dieselbe Behandlung: Vermeiden Sie die Klischees der Heimdomäne, nicht die Heimdomäne.
Einträge der Heimdomäne gehen in recall auf gleicher Ebene wie domänenübergreifende Einträge ein: structure gibt an, „welcher Zweig der Heimdomäne, und welcher jetzt genommen wird“. Das Verlassen wird durch die beiden Ausgaben von Schritt drei zugestanden: null Begriffe der Domäne A in restated (nicht vom Tool geprüft – selbst zählen) und kein Begriff von domain_terms in terms (vom Tool blockiert). Das Tool prüft die beiden Tabellen nicht.
Die drei Unter-Schritte gehören alle zu Stufe zwei und laufen innerhalb einer Runde in der richtigen Reihenfolge ab. Führen Sie sie nicht zu einer Abfrage zusammen — zusammengeführt wird 2c zu einer Fortsetzung von 2a.
| Schritt | Aktion | Ausgabe | Hartes Format | Was es beweisen kann |
|---|---|---|---|---|
| 2a Richtungsgenerierung | Aus parametrischem Gedächtnis: Wo könnte eine Praxis sein (zuerst ungewählte Zweige der Heimdomäne) | Eine Richtung + „was könnte dort sein“ | origin: "recall", confidence, Linse operator; 3–6 Einträge, ≥2 Linsen; status immer unverified | Nur „dieses Gebiet gesehen“, nicht, dass die Praxis dort existiert |
| 2b Verifizierung anhand von Primärquellen | Jeden Eintrag anhand einer externen Primärquelle prüfen: Existiert diese Praxis dort? | verified / refuted / unverified (geprüft, aber unentscheidbar, bleibt unverified) | verified muss eine Herkunft tragen; refuted muss eine Korrektur tragen | Macht Vermutungen zu zitierbaren Fakten |
| 2c Lückenfüllung | Die Suchbegriffe ändern und erneut suchen, für Richtungen, an die 2a nie gedacht hat | Neue Quellen | origin: "search" und status pro Eintrag; jedes Ergebnis zeichnet query auf | Über die Trainingsdaten-Grenze hinaus |
2c gibt dieselbe Praxis zurück wie 2a (gleiche Domäne, gleiche Praxis) = der Schritt hat nicht verlassen; das ist eine Fortsetzung, keine Lückenfüllung. Eine andere Praxis in derselben Domäne zählt – aber „andere“ muss in structure gehen, sonst kann sie nicht vom 2a-Eintrag im Protokoll unterschieden werden, und das Tool kann auch keine Duplikate beurteilen. Das Tool prüft dies nicht; zählen Sie es.
Für Eingabeaufforderungen und Reihenfolge siehe references/probe.md. Berechnen Sie keine Erinnerungsgenauigkeit: 2a gibt Richtungen, keine Aussagen.
Die vier Rahmungslinsen (für 2a Richtungsgenerierung verwendet, am Landungstor gegen Kandidaten neu geprüft)
In 2a jeden Eintrag mit einer Linse versehen; 3–6 Einträge decken ≥2 ab. Vier Einträge von einer Linse sind vier Kopien einer Analogie, richtig und falsch zusammen – prüfen Sie Divergenz bei 2a, nicht am Ende am Landungstor.
Die Linse fragt „wo“, nicht „wie weit“. Die Antwort kann ein anderer Zweig der Heimdomäne oder ein anderes Feld sein.
| Rahmungslinse | Fragen Sie damit |
|---|---|
function（功能） | In welchem Feld ist dieses Verb (Erkennung / Pufferung / Ratenbegrenzung / Kalibrierung) eine Standardkomponente? |
conflict（矛盾） | Wer behandelt „will X und gleichzeitig nicht X“ als tägliches Geschäft? |
scale（尺度） | Wie machen Felder eine Stufe tiefer (ein einzelnes Vorkommnis) und eine Stufe höher (eine Organisation, ein Ökosystem) dasselbe? |
failure（失败） | Welches Feld hat ein geschriebenes Vorfallsarchiv für diese Art von Fehler? |
5. Rückübersetzung: als Domänen-A-Handlungen landen
Übersetzen Sie jede Praxis auf der Quellseite zurück; fallen Sie, was nicht rückübersetzt werden kann.
Schreiben Sie zuerst why; wenn es nicht geschrieben werden kann, verwerfen Sie den Eintrag. Nicht nach den anderen Spalten angehängt – bis dahin ist die Beibehaltung bereits entschieden, und was geschrieben wird, ist eine dafür gefundene Rechtfertigung. why ist das Zulassungstor: Die A-Seite zitiert die genauen Worte von decompose.stuck; die B-Seite gibt an, was in diesem Feld die Arbeit erledigt. Nur B-Seite („dieses Feld funktioniert so gut“) dreht sich; nur A-Seite wiederholt den Haken; die beiden stimmen nicht überein = nicht rückübersetzbar.
Für evidence wählen Sie eines: die Herkunft der Quellpraxis oder inferred. Inferred zu markieren ist erlaubt; eine Folgerung als Herkunft zu schreiben ist nicht erlaubt. Es regiert die Tatsache (die Praxis existiert dort); why regiert die Korrespondenz (gleiche Stelle wie der Haken in Domäne A?).
Das Tool prüft nur, dass why nicht leer ist; es kann nicht erkennen, ob es zuerst geschrieben oder nachträglich angehängt wurde. Weich, wie der 2c-Selbsttest: blockiert das Offensichtlich-Unerledigte.
6. Die beiden Tore und die Befehle
python3 scripts/maybe_smart.py --recall decompose.json # Eintragungstor
python3 scripts/maybe_smart.py --check cands.json decompose.json # Landungstor
python3 scripts/maybe_smart.py analogy.json # Audit (optional)
--quiet ist ein Ausgabeschalter, kein Modusplatz: Standardmäßig wird der vollständige Bericht ausgegeben; damit wird nur die Ergebniszeile (PASS / FAIL; --check verarbeitet ein Paar und gibt eine einzelne Zeile aus). Exit-Codes: 0 bestanden / 1 blockiert / 2 Eingabefehler.
Eintragungstor: task_type nicht leer und alle vier Spalten vorhanden; restated ≤40 Zeichen; terms ≥3 mit keinem Begriff von domain_terms (wenn domain_terms nicht aufgeführt ist, kann dieses Tor nicht geprüft werden und gilt als nicht bestanden); jeder Erinnerungseintrag hat ein nicht leeres b_domain; ≥3 Erinnerungseinträge; gleiche Quelle, gleiche Praxis wiederholt sich nicht (zwei verschiedene Praktiken unter einem Zweig zählen als zwei); status akzeptiert nur verified / refuted / unverified; verified trägt source, refuted trägt correction; mindestens 1 Eintrag mit origin als search und einem aufgezeichneten query.
Landungstor, sieben Prüfungen:
- Sechs Felder nicht leer:
operator/action/subject/first_step/observable/why - ≥2 Rahmungslinsen;
operatordarf nur die chinesischen Literale 功能 / 矛盾 / 尺度 / 失败 (Funktion / Konflikt / Maßstab / Fehler) annehmen; jeder andere Wert ist nicht konform ...(Die Prüfungen 3-7 wurden im Originaltrunkat abgeschnitten – für die Übersetzung wurden die vorhandenen Inhalte vollständig lokalisiert.)
7. Ausgabeformat (Tool-Schnittstelle)
Das Tool erwartet eine cands.json im folgenden Format für das Landungstor:
{
"candidates": [
{
"operator": "功能",
"action": "Standard-Code-Review-Checkliste durchsetzen",
"subject": "Review-Prozess",
"first_step": "Schreiben Sie eine Checkliste mit den fünf häufigsten Fehlerkategorien aus den letzten zehn Reviews",
"observable": "Die Anzahl der übersehenen Fehler im nächsten Review sinkt um 50%",
"why": "Will die Erkennungsrate erhöhen, aber mehr Leute senken sie. Die Softwarequalitätssicherung verwendet Checklisten als Standardbaustein, um die Streuung zwischen Prüfern zu reduzieren.",
"evidence": "IEEE 1028-2008 Standard für Software-Reviews",
"source_field": "Softwarequalitätssicherung"
}
]
}
8. Beispiel: Übersehene Fehler im Code-Review
Zerlegung:
| Spalte | Wert |
|---|---|
keep | Unabhängiges Urteil vor dem Zusammenführen |
block | Es gibt ein Urteil, aber es wirkt nicht als eines |
stuck | Will die Erkennungsrate erhöhen, aber mehr Leute senken sie |
constraints | Kein Personal hinzufügbar; keine Verlängerung des Zeitplans |
Neufassung: Erhöhung, aber mehr reduziert sie Suchbegriffe: Streuung, Überprüfer, Anzahl, Senkung
Abruf (2a, 2b, 2c):
- Zweig in derselben Domäne: „Blind-Review“ – die Prämisse, dass Prüfer Kenntnis vom Autor haben, wird abgelehnt; formal vorhanden, aber selten verwendet.
- Domänenwechsel: „Qualitätsregelkarte“ in der Fertigung – die Prämisse, dass die Fehlerrate durch Inspektion steigt, wird abgelehnt; stattdessen wird die Inspektion selbst auf Konsistenz überwacht.
Landung: Rückübersetzung für Blind-Review: Warum funktioniert es? stuck sagt, dass mehr Prüfer die Erkennungsrate senken – Blind-Review beseitigt bewusste und unbewusste Voreingenommenheit; es behandelt denselben Haken (Erhöhung reduziert). Aktion: Autorinformationen während des Reviews verbergen, zufällige Prüferzuweisung. Erster Schritt: Nächstes Review mit verborgenen Autoreninformationen durchführen. Beobachtbar: Die Anzahl der übersehenen Fehler sinkt im Vergleich zum vorherigen Review.
Referenzen
references/probe.md– Abfragevorlagen für jeden Schrittreferences/audit.md– Audit-Verfahren für domänenübergreifende Analogienscripts/maybe_smart.py– Hilfsskript zur Validierung des Ausgabeformats