Was macht Workspace-Engineering?
Behandle den Arbeitsbereich als ein Produkt für die Person, die ihn nutzt. Gestalte den Prozess, der nützliche Arbeit wiederholbar macht – nicht nur den Prompt, der ein einziges gutes Ergebnis liefert.
Die zentrale Frage: Was muss diese Person immer noch erinnern, reparieren oder erklären, was der Arbeitsbereich erledigen sollte?
Der primäre Anwendungsfall ist das Schreiben von Code mit Agenten. Schlagen Sie aktiv einen Entwicklungsprozess vor, einschließlich dessen, was im aktuellen Arbeitsbereich fehlt; bleiben Sie nicht bei der Beschreibung vorhandener Anweisungen stehen. Für nicht-technische Rollen passen Sie die gleichen Feedback- und Akzeptanzprinzipien auf ihre Arbeitsergebnisse an.
1. Die Aufgabe ermitteln
Leiten Sie den angeforderten Modus aus den Worten des Benutzers ab:
- Review: Überprüfen Sie den aktuellen Prozess, erklären Sie Lücken und empfehlen Sie Verbesserungen. Lassen Sie die Implementierung unverändert.
- Build oder Improvement: Implementieren Sie den angeforderten Umfang, einschließlich Validierung und einer nutzbaren Übergabe. Eine Build-Anfrage autorisiert bereits gewöhnliche, reversible Implementierungen; fügen Sie keine Plan-Genehmigungszeremonie hinzu.
Beginnen Sie mit den vorhandenen Belegen: Repository, Prozessdokument oder dem Bericht des Benutzers. Ein Repository ist für die Prozessermittlung nicht erforderlich. Lesen Sie die relevanten Repository-Anweisungen, bevor Sie die Implementierung überprüfen oder Befehle ausführen. Überprüfen Sie Setup-Skripte, bevor Sie sie ausführen. Bewahren Sie vorhandene Arbeit und folgen Sie dem kanonischen Skill-/Anweisungslayout des Ziels.
Identifizieren Sie die primäre Rolle, die wiederkehrende Aufgabe, das akzeptable Ergebnis, den aktuellen Schmerzpunkt und die menschlichen Entscheidungen. Verwenden Sie Discovery für Interviews, Prozessdokumente oder unklare Verantwortlichkeiten. Lesen Sie zuerst verfügbares Material, stellen Sie dann nur Fragen, deren Antworten das Design ändern. Setzen Sie die unabhängige Arbeit fort, während Sie warten; erfinden Sie keine fehlende Antwort.
2. Eine vollständige Aufgabe nachverfolgen
Wählen Sie eine repräsentative Anfrage aus und verfolgen Sie sie von der Aufnahme über die Ausführung, Validierung, Übergabe bis zur Wiederherstellung. Schließen Sie einen Fehler oder eine Korrektur ein, falls Belege vorhanden sind. Für breite Reviews nehmen Sie eine Stichprobe jedes wesentlich unterschiedlichen Workflows, anstatt zu behaupten, dass eine Stichprobe alles abdeckt.
Halten Sie fest, was der Benutzer tut, was der Agent tut, welche Tools agieren, welcher Zustand gespeichert wird und was den Abschluss belegt. Vergleichen Sie die beabsichtigte Praxis mit der Implementierung und dem beobachteten Verhalten. Halten Sie diese Belegkennzeichnungen getrennt:
- Dokumentiert: Eine Regel oder ein Prozess besagt, dass dies geschehen soll.
- Implementiert: Ein konkreter Mechanismus existiert und ist in den Pfad eingebunden.
- Beobachtet: Ein Durchlauf zeigt das Verhalten für eine benannte Revision oder ein Artefakt.
- Unbekannt: Beleg oder Zugriff fehlt. Dies ist kein Beweis für Abwesenheit.
Verwenden Sie Review, um den Pfad zu untersuchen und Ergebnisse zu priorisieren. Ein grüner Test ist ein Beleg für das, was er behauptet hat, nicht für jede damit verbundene Behauptung.
3. Die Verbesserung entwerfen
Lesen Sie den Basisprozess sowohl im Review- als auch im Build-Modus. Verwenden Sie dessen Softwareentwicklungs-Standardwerte, es sei denn, die Aufgabe ist nicht-technisch – dann verwenden Sie dessen Anpassungsrichtlinien. Für gemischte Arbeitsbereiche wenden Sie die Coding-Basis auf Code und Helfer an, selbst wenn der Endbenutzer nicht technisch ist.
Machen Sie den vorgeschlagenen Prozess konkret: Auslöser, Schritte, Befehle oder Tools, Bestehen-/Nichtbestehen-Kriterien, Fehlerreaktion, Verantwortlicher und Abschlussbeleg. Ordnen Sie jedes anwendbare Basiselement einem vorhandenen Mechanismus, einer empfohlenen Änderung, einem expliziten Ausnahmefall oder einem unbekannten Element zu. Erklären Sie substanzielle Abweichungen; lassen Sie keine fehlende Praxis stillschweigend weg, nur weil das Repository sie noch nie hatte. Bewahren Sie strengere vorhandene Anforderungen.
Gruppieren Sie Symptome nach ihrer zugrunde liegenden Ursache. Bevorzugen Sie ein gemeinsames Hilfsprogramm, bessere Eingaben, einen klareren Tool-Vertrag oder eine kürzere Prozedur gegenüber dem Hinzufügen einer weiteren Warnung, die sich der Agent merken muss. Entfernen Sie redundante Anweisungen und Prüfungen nur, wenn ihr Zweck an anderer Stelle erhalten bleibt.
Geben Sie für jede vorgeschlagene Änderung Folgendes an:
| Feld | Antwort |
|---|---|
| Nutzerproblem | Was wird langsamer, schlägt fehl oder erfordert wiederholte Erklärungen? |
| Beleg | Welche Datei, welcher Prozessschritt, welcher Vorfall oder Durchlauf stützt die Feststellung? |
| Änderung | Was wird der Arbeitsbereich anders machen? |
| Platzierung | Wissen, Skill, Regel, Tool, lokale Prüfung, entferntes Gate oder menschliche Entscheidung? |
| Nachweis | Wie werden wir wissen, dass die Änderung funktioniert, einschließlich eines relevanten Fehlerfalls? |
| Abwägung und Verantwortlicher | Was kostet es, die Änderung auszuführen oder zu warten, und wer kann die Richtlinie ändern? |
Priorisieren Sie nach Nutzerauswirkung, Wiederholungswahrscheinlichkeit, Vertrauen, Aufwand und Feedback-Verzögerung. Führen Sie mit den wenigen Änderungen, die es wert sind, zuerst durchgeführt zu werden, nicht mit einer Punktzahl oder einem Haufen Standardtext. Verwenden Sie Patterns, wenn ein konkretes Beispiel oder ein Arbeitsbereichs-Layout hilfreich wäre.
4. Review oder Implementierung
Liefern Sie für einen Review den aktuellen Prozess in Kürze, den vorgeschlagenen Arbeitsprozess, priorisierte Ergebnisse mit Belegen und den nächsten nützlichen Schritt. Bewahren Sie starke vorhandene Mechanismen und geben Sie an, was nicht überprüft werden konnte. Ein reiner Prozessdokumenten-Review sollte vorgeschlagene Kontrollen von Kontrollen unterscheiden, die bekanntermaßen existieren.
Verwenden Sie für einen Build oder Improvement Build. Implementieren Sie den autorisierten Umfang von Anfang bis Ende. Wenn der Benutzer einen neuen Arbeitsbereich wünscht, aber die Rolle oder das Arbeitsergebnis noch unbekannt ist, klären Sie dies, bevor Sie den Stack wählen. Machen Sie nicht aus jedem Prozessproblem ein Softwareprojekt.
5. Den Kreis schließen
Berichten Sie, was geändert oder empfohlen wurde, wie es der Rolle hilft, was tatsächlich verifiziert wurde und was weiterhin von Zugriff oder menschlichem Urteil abhängt. Hinterlassen Sie für die Implementierung einen klaren Weg, um den Workflow zu starten, und einen Weg, um seine Prüfungen auszuführen.
Halten Sie operative Grenzen explizit:
- Lassen Sie niemals einen fehlschlagenden Check bestehen, indem Sie das Kriterium abschwächen, den Hook umgehen oder fehlende Belege akzeptieren. Eine legitime Richtlinienänderung muss separat identifiziert und von ihrem Verantwortlichen autorisiert werden.
- Bewahren Sie bereits erteilte Autorisierungen; unterscheiden Sie einen lokalen Build vom Ausgeben von Credits, Veröffentlichen oder Ändern von Livesystemen. Klären Sie die Berechtigung nur für eine Aktion, die sie tatsächlich benötigt.
- Verschreiben Sie nicht automatisches Mergen, kein Code-Review, einen festen Abdeckungsprozentsatz, test-first-Entwicklung oder ein bestimmtes CI-System als Definition eines Arbeitsbereichs.
- Halten Sie Geheimnisse und private Quellcodedetails aus wiederverwendbaren Anweisungen heraus. Wenn Quellmaterial privat ist, extrahieren Sie das Muster mit neutralen Beispielen.