Was macht 知行交互规范 Intent UI?
Übersetze Geschäftsziele in fundierte Funktionsentscheidungen, Bedienregeln und beobachtbare Abnahmekriterien. Die Prozessebene legt fest, "wie die Arbeit voranschreitet und welche Deliverables erstellt werden", die Methodenebene schränkt ein, "wie die KI denkt und sich selbst prüft", die Geschäftsebene bestimmt, "welche Fähigkeiten benötigt werden", und die Komponentenebene definiert, "wie diese Fähigkeiten verstanden und bedient werden". Standardmäßig in Chinesisch, ausgerichtet auf die Zusammenarbeit von Produktmanagement, Design, Frontend und Tests; nicht an ein Framework gebunden und erfordert keine Installation von Komponentenbibliotheken eines Referenzprojekts.
Kernbeschränkungen
- Bestimme zuerst die Benutzeraufgabe, dann die Seite und die Komponenten. Nur weil eine Tabelle in der Datenbank existiert, bedeutet das nicht, dass der Benutzer eine CRUD-Oberfläche für diese Tabelle benötigt.
- Unterscheide zwischen "Interaktions-Mindestanforderungen, die von allen relevanten Seiten erfüllt werden müssen" und "Fähigkeiten, die nur bereitgestellt werden müssen, wenn bestimmte Geschäftsbedingungen erfüllt sind". Markiere unbekannte Bedingungen als "zu bestätigen", nimm sie nicht eigenmächtig als verzichtbar an.
- Operationen hängen vom Geschäftsobjekt, aktuellem Zustand, Benutzerberechtigungen, abhängigen Abhängigkeiten und dem Einflussbereich ab. Ein statischer Schaltflächenkatalog reicht nicht.
- Unterscheide zwischen Geschäftsdeaktivierung, Steuerelement-Deaktivierung, Schreibschutz, Löschung, Archivierung, Rückgängigmachen und Rollback; die Namen, Ergebnisse und Wiederherstellungsmethoden müssen konsistent sein.
- Erkläre sowohl, was bereitgestellt wird, als auch, warum etwas weggelassen wird und welche Änderungen eine Neubewertung auslösen. Wenn der Benutzer eine Vereinfachung wünscht, behalte dennoch die zutreffenden Fehlerwiederherstellungs- und Statusrückmeldungen bei.
- Referenziere Cloudscapes Muster und Auswahlkriterien; Geschäftsfähigkeitsmatrix, Genehmigungen, Aufgabenwiederherstellung usw. sind erweiterte Backend-Regeln dieses Skills und geben sich nicht als offizielle Cloudscape-Anforderungen aus.
- Überprüfe auf Komponentenebene Tastatur- und Fokusverhalten anhand nativer Semantik und entsprechender APG-Muster; ergänze Interaktionen mit den Szenarienprinzipien von Carbon und Ant Design sowie Implementierungserfahrungen von Radix und React Aria. Betrachte die Standardwerte einer Bibliothek nicht als Spezifikation für alle Komponenten und behaupte nicht, dass diese Projekte einen gemeinsamen Standard teilen.
- Mache die Schaltflächenanordnung, Feldanzahl, Popup-Größe oder Zeitschwellen eines bestimmten Produkts nicht zu universellen harten Metriken. Respektiere bestehende Produktspezifikationen; erläutere bei Konflikten die Entscheidungsfindung und die Auswirkungen auf den Benutzer.
- Führe keine echten Löschungen, Deaktivierungen, Genehmigungen, Exporte oder Berechtigungsänderungen durch, nur weil du Spezifikationen erstellst oder überprüfst. Nimm nur dann Code-Änderungen vor, wenn der Benutzer dies verlangt und im Rahmen seiner Autorisierung.
Wähle die Arbeitsweise je nach Anfrage
| Benutzerabsicht | Tu dies | Lieferumfang |
|---|---|---|
| Erstellung allgemeiner Spezifikationen | Erstelle Bedingungsregeln und Szenariobeispiele, erfinde kein spezifisches Geschäft | Spezifikation, Fähigkeitsmatrix, Abnahmevorlage |
| Design eines spezifischen Moduls | Leite die erforderlichen Fähigkeiten aus bekannten Prozessen und Datenzuständen ab | Modulentscheidungstabelle, Seiten-Interaktionsvertrag, Abnahmeszenario |
| Design oder Überprüfung des Backend-Komponentenverhaltens | Kläre die Semantik, den Zustand, die Eingabemethode und die Kombinationsgrenzen der Komponente | Komponentenauswahlbegründung, Verhaltensvertrag, notwendige Interaktionsabnahme |
| Überprüfung eines bestehenden Backends | Identifiziere Lücken anhand der sichtbaren Seiten, Anforderungen oder des Quellcodes | Nachweislich belegte Probleme, Auswirkungen, minimaler Korrekturbedarf und Abnahme |
| Extraktion oder Anwendung eines Referenzstils für Backends | Analysiere Seiten und Quellcode und wähle Komposition, Token-Rollen und Interaktionsmuster basierend auf der Aufgabe | Ausführbare Stilkonventionen, Anpassungsgrenzen, Abnahmepunkte |
| Implementierung oder Reparatur von Interaktionen | Implementiere den definierten Umfang in der bestehenden Architektur | Code-Änderungen, entsprechende Überprüfungen, restliche Abhängigkeiten |
Eine Spezifikationsanfrage wird nicht automatisch zu einer Code-Änderung; eine Überprüfungsanfrage führt nicht zu einer automatischen Umstrukturierung des gesamten Backends. Gib für einfache Seiten nur die notwendigen Entscheidungen und Regeln aus.
Zu Beginn jeder Designaufgabe: Lies den Design-Workflow, um die Prozesstiefe, die Einstiegskriterien für die Phasen und die Deliverable-Kette zu bestimmen; wenn die KI die Oberfläche entwirft, generative Tools antreibt oder in Multi-Agent-Kooperation arbeitet, führe zuerst die KI-Design-Methode mit ihrer Vor-Generierungs-Selbstkalibrierung und den Schutzmechanismen gegen Ausfallmuster aus.
Aufbau des Geschäftskontexts
Lies vorzugsweise die vom Benutzer bereitgestellten Anforderungen, Prozesse, Screenshots, vorhandenen Seiten und zugehörigen Quellcode. Überprüfe nur Materialien, die für die Aufgabe relevant sind. Unterscheide zwischen beobachtetem Verhalten, Dokumentenanforderungen und Annahmen; allein anhand eines Screenshots kann nicht auf Backend-Berechtigungen oder asynchrone Wiederherstellung geschlossen werden.
Extrahiere die minimalen Informationen, die für die Entscheidungsfindung erforderlich sind:
- Wer führt welche Aufgabe in welchem Umfang aus? Was sind die Haupteinstiegspunkte und Erfolgskriterien?
- Werden Daten vom Benutzer gepflegt, extern synchronisiert oder systemgeneriert? Welche Felder oder Datensätze sind änderbar?
- Welche Geschäftsstatus durchlaufen die Daten, welche Statusübergänge sind gültig und wer kann sie auslösen?
- Wen betrifft eine Operation, ist sie reversibel, welche Abhängigkeiten gibt es, gibt es langlaufende Aufgaben oder gleichzeitige Änderungen mehrerer Benutzer?
- Wie wirken sich Datenumfang, Nutzungshäufigkeit, Arbeitsgeräte und bestehende Spezifikationen auf die Interaktion aus?
Fehlt der Kontext, gib zuerst eine anpassbare Lösung für ein "allgemeines Web-Backend" und lege die Annahmen offen. Frage nur nach Lücken, die wichtige Entscheidungen ändern würden; bearbeite die nicht betroffenen Teile weiter; nimm ohne Beweise keine dauerhafte Löschung, nicht autorisierte Aktionen oder ein vollständiges Aufgabencenter an.
Auswahl der Fähigkeiten
Lies bei der Erstellung oder Überprüfung des Funktionsumfangs die Fähigkeitsentscheidung. Erstelle für die Module im Umfang eine Fähigkeitsmatrix und kennzeichne jedes Element als:
- Grundlegend erforderlich: Das absolute Minimum, das vorhanden sein muss, wenn diese Art von Interaktion existiert, z. B. erkennbare Lade- und Fehlerzustände beim Laden von Daten.
- Bedingt erforderlich: Muss bereitgestellt werden, wenn bestimmte Geschäftsbedingungen erfüllt sind; schreibe die Bedingungen und Nachweise auf.
- Optionale Verbesserung: Bringt Vorteile, behindert aber nicht die Kernaufgabe; kann eingeplant oder weggelassen werden.
- Nicht zutreffend: Für das aktuelle Geschäft irrelevant oder nicht erlaubt; begründe die Entscheidung.
- Zu bestätigen: Unzureichende Beweise; dies ist ein Entscheidungsstatus, nicht die Annahme, dass es weggelassen werden kann.
Hohe Implementierungskosten bedeuten nicht "nicht zutreffend"; fehlende Schnittstellen bedeuten nicht, dass die Fähigkeit nicht benötigt wird. Dokumentiere die geschäftliche Notwendigkeit und die Implementierungsvoraussetzungen getrennt.
Auswahl spezifischer Regeln
Lies je nach Umfang, lade nicht standardmäßig alle Referenzdateien:
| Betrifft | Lies |
|---|---|
| Designphasen-Orchestrierung, Divergenz/Konvergenz, Deliverable-Kette, Designspezifikation und -übergabe | Design-Workflow |
| KI-generierte Oberflächen, Designkontext-Degradierung, Ausfallmusterschutz, Multi-Agent-Arbeitsteilung | KI-Design-Methode |
| Navigation, Arbeitsbereich, Liste, Suche, Filter, Detail, Diagramm | Navigation und Datenansicht |
| Neu anlegen, Bearbeiten, Validieren, Aktivieren/Deaktivieren, Löschen/Archivieren, Stapelverarbeitung, Import/Export | Operationen und Formulare |
| Ladeausnahmen, Berechtigungen, Multi-Tenancy, Gleichzeitigkeit, asynchrone Aufgaben, Genehmigung/Veröffentlichung, Benachrichtigungen, Barrierefreiheit | Status und Geschäftsprozesse |
| Komponentenauswahl, Statussprache, Tastatur, Fokus, Overlays und Komponentenkombinationen | Sprache des Komponenteninteraktionsdesigns |
| Heuristische Evaluation, Cognitive Walkthrough, Barrierefreiheitsabnahme, Erlebnis-Metriken, Design-QA | Design-Evaluationsmethode |
| Design-System-Governance, Design-Token, Komponentendokumentationsvorlage, Konsistenzaudit | Design-System und Token-Spezifikation |
| Extraktion oder Anwendung von Referenzstilen wie NextLabs, LarkAgentX, hochfrequente Arbeitsbereiche, Betriebskonsolen und zugehörige Präsentationsseiten | Werkzeug-Oberflächenstil |
| Ausgabe von Spezifikationen, Überprüfungsberichten, Abnahmen, Szenarioübungen | Lieferung und Prüfung |
| Referenzierung von Cloudscape-Geschäftsmustern | Cloudscape-Quellen und Anpassungsgrenzen |
| Referenzierung von APG, Carbon, Ant Design, Radix oder React Aria Komponentenregeln | Komponentenquellen und Differenzbehandlung |
| Referenzierung von Prozessmodellen, Evaluationsmethoden oder Design-System-Quellen | Prozess-, Evaluations- und Design-System-Quellen |
| Referenzierung von Fallbeispielen und Überprüfungsgrenzen von NextLabs, LarkAgentX | Werkzeug-Oberflächenstil-Quellen |
Schreibe für jede tatsächlich bereitgestellte Operation klar: Einstieg und Zielobjekt → gültige Zustände und Berechtigungen → Eingabe oder Bestätigung → während der Ausführung → Erfolgsergebnis → Fehler oder unbekanntes Ergebnis → Rückkehrposition und Wiederherstellungsweg. Nicht zutreffende Schritte können weggelassen werden mit Begründung; erzwinge keinen Bestätigungsdialog für das Anzeigen von Details.
Gib für Objekte mit Lebenszyklus Regeln in der Form "Status × Operation × Rolle" an; für mehrstufige Aufgaben erläutere Speichern, Verlassen, Wiederherstellen, teilweisen Abschluss. Wenn der Prozess Verzweigungen oder viele Status hat, verwende kompakte Tabellen oder Mermaid; zeichne für einzelne Schritte kein Diagramm auf.
Wenn die Anfrage explizit das Design, die Überprüfung oder die Implementierung einer bestimmten Komponente betrifft, lies die relevanten Teile der Sprache des Komponenteninteraktionsdesigns; entwickle nicht die gesamte Komponentenliste, wenn es nur um funktionale Kompromisse geht. Ähnliches Aussehen von Komponenten bedeutet nicht gleiches Verhalten; überprüfe insbesondere Menüs vs. Selektoren, Schalter vs. Kontrollkästchen, Tooltips vs. interaktive Overlays und normale Tabellen vs. Datenraster.
Vor der Auslieferung prüfen
- Lassen sich Funktionsentscheidungen auf Aufgaben oder Geschäftsregeln zurückführen? Gibt es unbegründete vollständige CRUDs, Dashboards oder Stapeloperationen?
- Folgen dieselben Operationen auf Liste, Detail, Kurzeinstieg und Stapelverarbeitung denselben Bedingungen?
- Wird zwischen leeren Daten, keinem Treffer, Ladeausfall, fehlender Berechtigung und veralteten Daten unterschieden?
- Wird eine angenommene Anfrage fälschlicherweise als abgeschlossen bezeichnet oder ein Timeout fälschlicherweise als definitiver Fehler gewertet, der eine erneute Übermittlung erlaubt?
- Sind die Auswirkungen von Löschung, Deaktivierung, Veröffentlichung usw. klar definiert? Existiert die angegebene Wiederherstellungsfähigkeit tatsächlich?
- Sind der Hauptprozess, Fehler-, Berechtigungs- oder Zustandsänderungen, Teilerfolge und der relevante Tastatur-Workflow überprüfbar?
- Sind Semantik, Fokus, Auswahl- und Ausführungszustand der Komponente konsistent? Werden das erwartete Verhalten durch verschachtelte Overlays, benutzerdefinierte Wrapper und verschiedene Eingabemethoden beeinträchtigt?
- Deklariert die Ausgabe den durchlaufenen Prozesspfad und die Gründe für übersprungene Phasen? Sind KI-generierte Oberflächen mit einem vollständigen Statusüberprüfungsergebnis versehen?
Verlinke bei Referenzen auf die spezifische Musterseite und unterscheide zwischen offiziellen Mustern und eigenen Geschäftsvorschlägen. Verwende bei fehlender Online-Überprüfbarkeit die integrierte Zusammenfassung, nenne das Referenzdatum und die nicht überprüfbaren Teile, behaupte nicht, die neueste Version zu haben.