Innerhalb von nur 10 Minuten wurde die gesamte Datenbank gelöscht – Entwickler erlebten zum ersten Mal 5 große „Pannen“ von Claude Opus: Die KI gestand den Fehler von sich aus, aber es war bereits zu spät.

Kürzlich hat ein Entwickler auf Reddit seine „Pannen-Erfahrung“ geteilt:

Er hat zum ersten Mal versucht, mit dem neuesten Claude Opus 5 von Anthropic in Kombination mit Claude Code zu entwickeln – und das Ergebnis war, dass die gesamte Produktionsdatenbank in weniger als 10 Minuten von der KI geleert wurde. Noch lächerlicher war, dass die KI nicht versuchte, den Fehler zu vertuschen, sondern den Fehler sofort nach Abschluss des Löschvorgangs selbst zugab.

Dieser Vorfall hat in der Entwickler-Community schnell eine hitzige Diskussion ausgelöst. Einige scherzen, dass „das der Preis für Vibe-Coding ist“, während andere der Meinung sind, dass das eigentliche Problem nie das Modell selbst ist, sondern der Entwicklungsprozess.

Ein Prompt reicht – die gesamte Datenbank ist weg

Der Ursprung der Sache ist eigentlich sehr einfach. Ein Entwickler mit dem Benutzernamen Alone_Ad_3375 gibt an, dass er bisher immer Modelle wie Claude 4.6 Sonnet und Gemini 3 für Vibe-Coding verwendet hat, das gesamte Projekt wurde fast vollständig mit KI-Unterstützung erstellt, und währenddessen ist nie ein ähnlicher Unfall passiert.

Nachdem er von vielen Leuten Empfehlungen für Claude Code gehört hatte, beschloss er, es selbst auszuprobieren.

Das Ergebnis war, dass weniger als 10 Minuten vergingen, und ein einziger Prompt hat die gesamte Datenbank auf Null zurückgesetzt: „So hat Opus 5 UltraCode meine gesamte Datenbank komplett gelöscht.“ Was ihn noch mehr zum Lachen und zum Weinen brachte, war, dass die KI nach dem Löschen der Daten sofort selbst den Fehler zugab:

„Das ist mein Fehler, ich muss es dir sofort sagen.“

Glücklicherweise hat dieser Unfall am Ende keine unumkehrbaren Verluste verursacht. Später hat der Entwickler mehrere Aktualisierungen zum Fortschritt veröffentlicht:

Zuerst hat Gemini 3.6 erfolgreich als „Feuerwehrmann“ fungiert und dabei geholfen, 96 Seiten wiederherzustellen, nur 21 Seiten mussten ohne Sicherung neu generiert werden. Anschließend hat er sofort den Sicherungsmechanismus ergänzt und die fehlenden Teile mithilfe von MCP (Model Context Protocol) neu erstellt.

Danach hat er weiter erläutert, dass der größte Teil der gelöschten Inhalte eigentlich automatisch vom Programm erzeugt wurde, die Neuerstellung dauerte nur wenige Minuten, sodass die tatsächlichen Auswirkungen nicht so schwerwiegend waren, wie die Netznutzer es sich vorstellten.

Da dieses Projekt selbst nur sein Testprojekt ist und die Anzahl der Nutzer sehr gering ist, war der Einflussbereich des Unfalls auch nicht groß.

Am Ende hat er in der neuesten Aktualisierung bestätigt, dass alle gelöschten Inhalte erfolgreich wiederhergestellt wurden.

Darüber hinaus hat er ein weiteres Detail ergänzt: Der Prompt, der diesen Unfall verursacht hat, wurde nicht zufällig von ihm eingegeben, sondern von Claude Opus 5 selbst nach der Analyse des GitHub-Repositorys erzeugt – er wollte eigentlich nur, dass die KI ihm hilft, die Vergleichsseiten (Comparison Pages) der Website neu zu erstellen.

Es war nicht zu erwarten, dass daraus schließlich ein „Datenbank-Leerungs-Vorfall“ wurde.

Die Kommentarseite ist in Aufruhr: Warum gibt man der KI Schreibzugriff auf die Produktionsdatenbank?

Dieser Unfall hat auf Reddit viele Diskussionen ausgelöst. Im Vergleich zum Unfall selbst hat viele Entwickler eine andere Tatsache schockiert: „Warum sollte jemand der KI direkt Schreibzugriff auf die Produktionsdatenbank gewähren?“

Einige scherzen, das ist typisch für „Produktmanager, die glauben, selbst Code schreiben zu können“. Ein anderer Netznutzer sagt, das ist genau das gemeinsame Merkmal vieler Vibe-Coder: Sie haben keine Ahnung, was eine Bereitstellungsumgebung ist.

Dazu hat ein Entwickler seine eigene ähnliche Erfahrung geteilt:

Claude hat schon mehrmals meine Prompts ignoriert und ohne meine Erlaubnis selbst Änderungen in die Produktionsumgebung bereitgestellt. Die Begründung der KI war auch noch „selbstbewusst“: „Ich denke, diese Änderung ist nicht sehr umfangreich, also habe ich sie direkt in die Produktionsumgebung bereitgestellt.“ Am Ende musste ich dem gesamten Prozess einen Hook hinzufügen, der alle Produktionsbereitstellungen zwangsläufig blockiert, um ähnliche Fälle vollständig zu vermeiden.

Natürlich gibt es auch Leute, die meinen, dass man die KI nicht vollständig für diese Sache verantwortlich machen kann.

Ein Entwickler weist darauf hin, dass schon vor dem Aufkommen der KI zwei Entwickler in seinem Umfeld versehentlich die Produktionsdatenbank gelöscht haben, also auch Menschen machen dumme Fehler. Deshalb ist es nicht fair, die gesamte Schuld auf Vibe-Coding zu schieben:

„Viele Unfälle werden eigentlich von erfahrenen Ingenieuren verursacht; selbst wenn sie die Daten nicht selbst gelöscht haben, liegt es daran, dass das von ihnen entworfene Berechtigungssystem Lücken aufweist, sodass KI oder andere Entwickler zu große Berechtigungen erhalten.“

Gerade als die Netznutzer darüber stritten, ob KI vertrauenswürdig ist, hat ein Nutzer auf den am meisten übersehenen Punkt dieses Vorfalls hingewiesen:

Viele Leute nehmen die Aussage von Claude „Das ist mein Fehler, ich muss es dir sofort sagen“ als Beweis dafür, dass die KI vertrauenswürdig ist. Aber eigentlich ist das „selbstständige Eingestehen des Fehlers“ der KI keine Sicherheitskontrolle, sondern nur ein „Geständnis“ nach dem Vorfall – wenn die KI dir sagt „Ich habe einen Fehler gemacht“, wurde die SQL- oder API-Anfrage zum Löschen der Datenbank längst ausgeführt.

Eine wirklich wirksame Kontrolle sollte stattfinden, zwischen dem Zeitpunkt, an dem das Modell eine Handlungsabsicht entwickelt, und dem Zeitpunkt, an dem die gefährliche Handlung tatsächlich ausgeführt wird. Ohne diese Schutzschicht wird dir selbst die zuverlässigste KI nur sagen: „Entschuldigung, ich habe schon alles gelöscht.“

Das ist nicht das erste Mal – im April dieses Jahres ist so etwas schon passiert

Tatsächlich ist dies in diesem Jahr nicht der erste Vorfall, bei dem eine KI eine Datenbank gelöscht hat.

Im April dieses Jahres ist ein Entwickler bei der Verwendung von Cursor Agent (zugrundeliegendes Modell ist Claude Opus 4.6) auf einen noch schwereren Unfall gestoßen: Damals hat der Agent in nur 9 Sekunden die Produktionsdatenbank von PocketOS gelöscht, und gleichzeitig wurden auch alle volumesbasierten Sicherungen gelöscht.

Der gesamte Vorgang hat nur einen einzigen Aufruf der Railway-API erfordert.

Die nachfolgende Untersuchung hat ergeben, dass das eigentliche Problem nicht das Modell selbst ist, sondern das Berechtigungsdesign: Das API-Token, das ursprünglich nur für die Ausführung alltäglicher Aufgaben erstellt wurde, verfügt über Löschberechtigungen im gesamten Konto; außerdem befinden sich Sicherungen und Produktionsdaten in derselben Fehlerdomäne (Failure Domain), sodass der Löschvorgang gleichzeitig auch die Sicherungen betrifft.

Am Ende stellte der Entwickler fest, dass die neueste wiederherstellbare Sicherung eine Version von vor 3 Monaten war, und die Daten dazwischen sind fast vollständig verloren gegangen.

Zwei Unfälle mit unterschiedlichen Tools, unterschiedlichen Modellen und unterschiedlichen Infrastrukturen haben aber fast identische Probleme aufgedeckt: Zu große Berechtigungen für die KI, fehlende Bestätigungsmechanismen für gefährliche Handlungen und schwerwiegende Mängel bei der Sicherungsstrategie.

Deshalb hat ein Entwickler zusammengefasst: Das, was wirklich kontrolliert werden muss, ist nie das KI-Modell, sondern der „Explosionsradius“, den ein Unfall verursachen kann. Mit anderen Worten: Anstatt darauf zu hoffen, dass die KI nie einen Fehler macht, sollte man das System so gestalten, dass selbst wenn die KI einen Fehler macht, keine katastrophalen Folgen entstehen können.

Schließlich kann die KI dir beim Schreiben von Code helfen, aber auch dabei, deine Datenbank zu löschen; und diejenigen, die letztendlich für den Unfall verantwortlich sind, sind immer die Entwickler selbst.

Referenzlink: https://www.reddit.com/r/Anthropic/comments/1v9iurd/and_just_like_that_opus_5_ultracode_wipes_the/

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „CSDN“, zusammengestellt von ZHENG Liyuan, veröffentlicht mit Genehmigung von 36Kr.