Python-Skript und Browser-Fassung
Bauprojekte vorsortieren
Wer Bauprojekte als Auftragsquelle beobachtet, hat mehr Meldungen als Zeit. Die Auswahl fällt dann nach Gefühl, und was aussortiert wurde, lässt sich hinterher nicht mehr begründen. Dieses Werkzeug stuft jedes Projekt nach drei offen dokumentierten Kriterien ein – und führt getrennt auf, was sich mangels Angaben gar nicht einstufen lässt.
Bauprojekt-Daten strukturiert vorsortieren. Projekte, die sich mangels Angaben nicht einstufen lassen, werden als solche benannt.
Wonach sortiert wird
- drei offen dokumentierte Kriterien, genau eine Prioritätsklasse je Projekt
- zu jeder Einstufung eine Begründung
- fehlende und ungültige Angaben werden getrennt ausgewiesen
- aufgezeichneter Lauf: 5 min 45 s, 1,89 USD
Der Fall als Prozess
- Auslöser
- Ein Export von Bauprojekt-Datensätzen liegt vor – im Beispiel 18 Projekte.
- Eingangsdaten
- CSV mit definierten Pflichtspalten. Felder sind teils leer, teils ungültig befüllt.
- Regelwerk
- Drei offen dokumentierte Kriterien, ohne Gewichtung und ohne Punktesystem.
- Prüfschritt
- Je Kriterium erfüllt, nicht erfüllt oder nicht bewertbar. Fehlende und ungültige Angaben werden getrennt behandelt.
- Ausgabe
- Genau eine Prioritätsklasse je Projekt, dazu ein Begründungssatz – einschließlich der Projekte, die sich mangels Daten nicht einstufen lassen.
- Übergabepunkt
- Die Liste sortiert vor, sie entscheidet nicht. Wer angerufen wird, bestimmt ein Mensch.
- Grenze
- Die Kriterien sind selbst gesetzt und für einen bestimmten Zweck gewählt; sie sind keine Marktbewertung.
Was es tut
Prüft jeden Projektdatensatz gegen drei offen dokumentierte Kriterien, vergibt genau eine Prioritätsklasse, schreibt zu jeder Einstufung eine Begründung und trennt dabei fehlende von ungültigen Angaben. Läuft als Skript in unter einer Sekunde – und dieselben Regeln laufen im Browser.
Ausgangslage
Bauprojekte können Hinweise darauf liefern, wo später Freiraum- oder Gartenplanung relevant werden könnte – etwa über Grundstücksgröße, Fertigstellungstermin oder die Frage, ob im Projekt überhaupt eine Außenanlage erwähnt wird.
Bei vielen Projekten ist es aufwendig, diese Hinweise manuell zu strukturieren. Die Datenlage ist dabei typischerweise uneinheitlich: Manche Einträge sind vollständig, bei anderen fehlt die Fläche, der Termin oder jede Angabe zur Außenanlage.
Die Demo löst genau diesen kleinen Teil: die immer gleiche, regelbasierte Vorsortierung. Sie findet keine Aufträge und sagt nichts über Auftragschancen aus.
Kriterien
| Grundstücksfläche | mindestens 300 m² |
|---|---|
| Fertigstellung | 4 bis 14 Monate ab Stichtag |
| Außenanlage | ja erfüllt, nein erfüllt nicht, leer oder unerwartet = nicht bewertbar |
Prioritätsregel
| mind. 2 von 3 nicht bewertbar | unklar |
|---|---|
| 3 Kriterien erfüllt | hoch |
| 2 Kriterien erfüllt | mittel |
| höchstens 1 erfüllt | niedrig |
Ablauf
Version 1 · Python-Werkzeug
läuftLiest die CSV, prüft jedes Projekt gegen die drei Kriterien und schreibt einen sortierten Report. Der Stichtag ist fest im Skript hinterlegt und nicht das Systemdatum – sonst würden dieselben Beispieldaten je nach Aufrufzeitpunkt anders eingestuft.
Eingabe · bauprojekte_beispiel.csv
projekt_id,adresse,bezirk,projekttyp, grundstueck_m2,voraussichtliche_fertigstellung, aussenanlage_erwaehnt P-001,Ahornsteig 12,22,Wohnanlage mit Gärten, 1450,2027-03,ja P-011,Kirschbaumweg 17,21,Reihenhaussiedlung, ,,ja P-017,Werkstättenweg 60,11,Quartiersentwicklung, k.A.,2027-12,ja P-018,Rosenhügelgasse 8,12,Wohnanlage, 510,2027-13,ja
Auszug aus 18 Zeilen, Umbrüche zur Lesbarkeit eingefügt. Beachten
Sie P-011
(zwei leere Felder), P-017 (k.A. statt
Zahl) und P-018 (Monat 13).
Ausgabe · lead_radar_report.md
Geprüfte Projekte: 18 Hoch: 5 Mittel: 7 Niedrig: 4 Unklar: 2 ### P-011 – Kirschbaumweg 17, 21. Bezirk Priorität: UNKLAR - Grundstück: keine Angabe → unklar - Fertigstellung: keine Angabe → unklar - Außenanlage: ja → Kriterium erfüllt Begründung: Zur Grundstücksfläche liegt keine Angabe vor; sie wird nicht geschätzt. Zum Fertigstellungstermin liegt keine Angabe vor. Regel: 2 von 3 Kriterien sind nicht bewertbar. Eine belastbare Einstufung ist daher nicht möglich (→ unklar).
Quellcode ansehen – Schwellenwerte und Prioritätsregel
# Stichtag für die Terminberechnung. Bewusst fest gesetzt, damit die
# Demo-Ergebnisse reproduzierbar bleiben und nicht vom Systemdatum abhängen.
REFERENCE_DATE = (2026, 8) # Jahr, Monat
MIN_GRUNDSTUECK_M2 = 300
MIN_MONATE_BIS_FERTIGSTELLUNG = 4
MAX_MONATE_BIS_FERTIGSTELLUNG = 14
def bestimme_prioritaet(anzahl_erfuellt, anzahl_unbekannt):
"""Die vollständige Prioritätsregel – bewusst an einer Stelle und ohne Gewichte.
unklar : mindestens 2 der 3 Kriterien nicht bewertbar
hoch : alle 3 Kriterien erfüllt
mittel : genau 2 Kriterien erfüllt
niedrig: höchstens 1 Kriterium erfüllt
"""
if anzahl_unbekannt >= 2:
return "unklar"
if anzahl_erfuellt == 3:
return "hoch"
if anzahl_erfuellt == 2:
return "mittel"
return "niedrig"
Die Kernlogik ist durch 19 kleine Tests abgesichert
(python3 lead_radar.py --selftest), unter anderem für
Fenstergrenzen, ungültige Datumswerte und unerwartete Feldinhalte.
Dieselben Regeln laufen als JavaScript-Portierung im Browser – dort
gegen 20 Testfälle, die Sie selbst ausführen können.
Version 2 · Oberfläche
läuftDie Arbeitsliste als Ansicht statt als Textdatei. Diese Oberfläche ist gebaut und bedienbar: Das Regelwerk wurde nach JavaScript portiert und läuft im Browser des Besuchers – die gezeigten Werte werden dort berechnet, nicht eingetragen. Für denselben Datensatz liefert sie Kriterium für Kriterium dasselbe Ergebnis wie das Python-Skript oben, bis hinunter zum Wortlaut jedes Begründungssatzes.
Ein Klick auf eine Projektzeile öffnet die vollständige Begründung: jeden geprüften Rohwert, jeden Satz, aus dem die Einstufung folgt, und den Datenhinweis, falls ein Feld unbrauchbar war. Der Datensatz im Eingabefeld ist bearbeitbar – wer eine Fläche löscht oder einen Termin verfälscht, sieht die Einstufung sofort umspringen.
Begründung je Projekt in der Demo aufklappen →
| Projekt | Bezirk | Kriterien | Priorität | Kürzeste Begründung |
|---|---|---|---|---|
| P-008 Auwiesenweg 9 | 22 | 3/3 | hoch | alle drei Kriterien erfüllt |
| P-001 Ahornsteig 12 | 22 | 3/3 | hoch | alle drei Kriterien erfüllt |
| P-004 Marillenallee 88 | 23 | 2/3 | mittel | Grundstücksfläche fehlt |
| P-018 Rosenhügelgasse 8 | 12 | 2/3 | mittel | Termin ungültig (2027-13) |
| P-012 Salzachstraße 5 | 20 | 0/3 | niedrig | kein Kriterium erfüllt |
| P-011 Kirschbaumweg 17 | 21 | 1/3 | unklar | Fläche und Termin fehlen |
Standbild der laufenden Oberfläche, Auszug aus 18 Zeilen. „Unklar“ ist bewusst eine eigene Kachel und keine niedrige Priorität – ein Projekt ohne Daten ist nicht dasselbe wie ein Projekt, das die Kriterien verfehlt. Die Kachel „0 Werte geschätzt“ steht bewusst daneben: Sie bleibt auch dann auf null, wenn Felder fehlen.
Die nächste Version daneben
Was passiert, wenn die Projekte nicht als Tabelle kommen, sondern als Fließtext in einem Rundbrief? Das übernimmt ein Agent – und übergibt danach an dasselbe Regelwerk: Aus einem Rundbrief eine Arbeitsliste →
Der Projekttyp bleibt Kontext
Ein Projekttyp wie „Reihenhaussiedlung“ ist für Freiraumplanung grundsätzlich relevant. Er wird im Report deshalb als Kontexthinweis ausgegeben – fließt aber nicht in die Prioritätsregel ein und ersetzt keine fehlende Angabe.
Aus „Reihenhaussiedlung“ folgt im Report also nie „Außenanlage vermutlich vorhanden“, sondern der Hinweis, dass die Angabe fehlt. Genau dort verläuft die Grenze zwischen Daten und Interpretation.
Ebenso unterscheidet der Report zwischen einer fehlenden
und einer ungültigen Angabe. Ein Terminwert wie
2027-13 wird nicht stillschweigend als „unbekannt“
verbucht, sondern als ungültiger Eintrag benannt.
Automatisierung
- liest die Daten ein und prüft jedes Kriterium
- vergibt genau eine Prioritätsklasse nach offener Regel
- erzeugt zu jedem Projekt eine Begründung
- sortiert den Report und markiert Datenlücken
Mensch
- wählt die Kriterien aus
- legt Schwellenwerte und Stichtag fest
- interpretiert das Ergebnis
- entscheidet über jede Kontaktaufnahme
Grenzen
- Die Demo arbeitet ausschließlich mit fiktiven Beispieldaten. Es findet kein Live-Scraping statt und es werden keine echten Bauprojekt-Daten abgerufen.
- Für einen echten Einsatz müsste zunächst eine geeignete und rechtlich wie technisch zulässige Datenquelle angebunden werden.
- Die Kriterien und Schwellenwerte sind Beispielwerte. Ob sie fachlich sinnvoll sind, entscheidet der Mensch, nicht das Skript.
- Das Skript sagt nichts über tatsächliche Auftragschancen aus und trifft keine Entscheidung darüber, wer kontaktiert wird.
- Es wird keine KI und kein Machine Learning verwendet. Die Logik besteht aus lesbaren Regeln.
Dateien
- bauprojekte_beispiel.csv Eingabe
- lead_radar.py Logik
- lead_radar_report.md Ausgabe
- rules-lead.js Regelwerk
- tests-lead.js Tests
- rundbrief_beispiel.md Quelle V3
- agent.py Agentenlauf
- lead-extraktion.txt Prompt V3
- rules-lead-agent.js Nachprüfung
- tests-lead-agent.js Tests V3
- case_beschreibung.md Doku
Das Skript nutzt nur die Python-Standardbibliothek, die Browser-Fassung reines JavaScript ohne Bibliotheken. In beiden Fällen: kein Internetzugriff, keine Datenbank. Die vollständigen Dateien sende ich auf Anfrage gerne zu.
Wenn eine Liste vorsortiert werden muss
Wenn Sie eine Rolle in Datenqualität oder Prozessarbeit besetzen: Die Kriterien, die Prioritätsregel und die 38 Testfälle sind offen einsehbar und im Browser ausführbar.