Prompting heeft een reputatie om "vibes-based" te zijn. je typt iets, het model reageert, je tweak een zin, het krijgt beter, en je blijft duwen totdat het werkt - als het werkt. Een beetje Het is een nachtmerrie voor iets ernstigs: compliance-tekst, datapipelines, code-generatie of "please don't embarrass me in front of the team" outputs. Hier is de upgrade: . Prompt Reverse Engineering Het is precies hoe het klinkt: , dan gerichte oplossingen toepassen - zoals debuggen, niet raden. use the model’s wrong answer to backtrack into what your prompt failed to define Denk aan de slechte output als de manier waarop je model zegt: 
 
 ‘Je hebt me niet verteld wat belangrijk is.’ ‘Je hebt me niet verteld wat belangrijk is.’ Laten we dat veranderen in een herhalende workflow. Waarom omgekeerde engineering beats willekeurige prompt tweaking Zelfs als je een "goed uitziende" prompt schrijft (duidelijke vraag, beleefde toon, redelijke beperkingen), missen modellen nog steeds: 
 
 
 
 
 
 Het tijdvenster waar je om geeft, de volledigheid die je verwacht, het formaat dat uw downstreamcode nodig heeft, de rol waarin het model wil blijven, De definitie van ‘juist’. Reverse engineering geeft u een methode om de ontbrekende spec te lokaliseren Zonder je prompt in een roman te blazen. fast De vier mislukkingsmodi (en wat ze je echt vertellen) De meeste promptfouten vallen in een van deze buckets.Als je de bucket kunt benoemen, kun je meestal de prompt in één pass repareren. 1) Feitelijke mislukkingen Het antwoord stelt met vertrouwen de verkeerde feiten, mengt jaren, of uitvindt getallen. Symptom: Kennisdichte taken: marktrapporten, academisch schrijven, samenvattingen van beleid. Typical trigger: What your prompt likely missed: 
 
 
 
 uitdrukkelijke tijdsbestek (“kalenderjaar 2023” versus “de laatste 12 maanden”), bronvereisten (citaten, genoemde datasets), Fallback gedrag wanneer het model niet weet. U vraagt dan: Het model reageert met behulp van 2022 cijfers en zegt nooit waar het ze heeft gekregen. Example (UK-flavoured): Analyseer de top 3 EV-merken op basis van wereldwijde verkoop in 2023 Prompt patch pattern: 
 
 
 
 Voeg een "facts boundary" toe: jaar, geografie, eenheid. Vereist citaten of een transparante "Ik ben niet zeker" achteruitgang. Vraag het om gegevens uit te schakelen als exacte getallen niet beschikbaar zijn. 2) Gebroken logica / ontbrekende stappen De output ziet er plausibel uit, maar het overspoelt stappen, springt conclusies uit of levert een "outline" die doet alsof het een proces is. Symptom: Procedures, debuggen, multi-stap redeneren, architecturale plannen. Typical trigger: What your prompt likely missed: 
 
 
 
 “Dekt alle belangrijke stappen” “Expliciet afhankelijkheid / bestelling” “Gebruik een vast kader (checklist / pipeline / recept)” U vraagt dan: Het vermeldt alleen "beheer ontbrekende waarden" en "verwijder outliers" en noemt het een dag. Example: “Vertel een complete werkstroom voor het schoonmaken van Python-gegevens.” Prompt patch pattern: 
 
 
 
 Force a sequence (A → B → C → D). Een reden nodig voor de bestelling. Een beslissingstest vereisen (“Hoe weet ik dat deze stap nodig is?”). 3) Formulieren van de drift Je vraagt om een Markdown tabel / JSON / YAML / code blok ... en het retourneert een vriendelijke alinea als het schrijven van een blogbericht. Symptom: Alles betekende voor machines: gestructureerde outputs, config bestanden, payloads, tabellen. Typical trigger: What your prompt likely missed: 
 
 
 
 striktheid (“output only valid JSON”), schema-beperkingen (sleutels, typen, vereiste velden) Een kort voorbeeld (een paar foto's) kan het model imiteren. U vraagt dan: Het reageert in proza en combineert leverancier + release datum in één zin. Example: "Geef me een Markdown-tabel van drie populaire LLM's." Prompt patch pattern: 
 
 
 
 Voeg een schema toe, plus “geen extra sleutels”. Voeg “geen proza buiten het blok” toe. Inclusief een kleine voorbeeldroute. Rollen / Tone Drift U vraagt om een uitleg van een kinderarts en krijgt een medisch tijdschrift abstract. Symptom: roleplay, klantondersteuning, coaching, stakeholder comms. Typical trigger: What your prompt likely missed: 
 
 
 
 hoe de rol spreekt (leesniveau, warmte, taboe jargon), het primaire doel van de rol (verzekeren, overtuigen, de-escaleren), verboden inhoud (“medische jargon vermijden; termen definiëren als onvermijdelijk”). Prompt patch pattern: 
 
 
 
 Specificeer het publiek (“een bezorgde ouder”, “een junior ingenieur”, “een CTO”). Specificeer de toonregels (“vriendelijk, niet-oordelend, UK Engels”). Geef een do/don’t vocabulary aan. De vijf stappen omgekeerde engineering workflow Dit is de "stop guessing" loop. Houd het lichtgewicht. Maak één verandering tegelijk. Stap 1: Bepaal de afwijking (markeer de exacte miss) Schrijf de verwachte output op als een checklist en benadruk vervolgens waar de output afwijkt. Voorbeeld van checklist: 
 
 
 
 
 jaar = 2023 / Inclusief marktaandeel Inclusief bronnen Vergelijk de top 3 merken Als je de miss niet nauwkeurig kunt beschrijven, kun je het niet nauwkeurig oplossen. Stap 2: Infer de ontbrekende spec (de prompt defect) Vraag voor elke afwijking: 
 
 
 Welke instructies zouden dit kunnen voorkomen? Welke ambiguïteit heeft het model “opgelost” in de verkeerde richting? Typische tekortkomingen : 
 
 
 
 
 ontbrekende grens (tijd, regio, eenheid) Het ontbreken van volledige beperkingen, het ontbreken van een output schema, Het ontbreken van toneel / rol beperkingen. Stap 3: Test de hypothese met een minimale prompt edit Schrijf je hele prompt niet opnieuw, patch één defect en voer het opnieuw uit. Als de output op de verwachte manier verbetert, was uw hypothese juist. Stap 4: Een gerichte optimalisatiepatroon toepassen Eenmaal bevestigd, de kleinste duurzame fix toe te passen: 
 
 
 
 
 Beperkingsclausule: "Gebruik 2023 (jan-dec) gegevens; als het onzeker is, zeg dat." Schema-clausule: "Vertel een geldige JSON die overeenkomt met dit schema ..." Coverage clause: “Inclusief deze 6 stappen...” Tone clause: “Vertel als ik nieuw ben; vermijd jargon.” Stap 5: Noteer de verandering (build uw prompt changelog) Dit is het deel dat de meeste mensen overslaan - en het deel dat zich verandert in een technische praktijk. Houd een kleine log: 
 
 
 
 
 
 Oorspronkelijk snel Een model dat mislukt Defecte hypothese Patch toegepast resultaat Na verloop van tijd bouw je een persoonlijke bibliotheek van “gemeenschappelijke mislukking → standaardpatch”. Een volledige werk voorbeeld: het oplossen van een "gegevens schoonmaken workflow" prompt Laten we het ding goed doen. Begin snel 
 
 "Met Python schrijf je het volledige gegevensreinigingsproces met stappen en code." "Met Python schrijf je het volledige gegevensreinigingsproces met stappen en code." De (slechte) uitkomst Het retourneert slechts twee items: 
 
 
 Vul de ontbrekende waarden in Verwijder outliers En het dumpt code zonder context, zonder volgorde en zonder beslissingscontroles. Reverse engineering diagnose Deviation points 
 
 
 
 Ontbrekende kernstappen (duplicaten, type casting, standaardisatie) Geen rechtvaardiging voor bevelen Code ontbreekt opmerkingen en toepassingsnota's Prompt defects 
 
 
 
 Geen ‘core steps list’ → model kiest een gedeeltelijke subset Geen orderbeperkingen → modeluitgangen in willekeurige volgorde Geen “verklaar wanneer te gebruiken” → code wordt een copy/paste byte De gepatched prompt (minimaal maar specifiek) 
 
 
 Gebruik panda's om een volledige werkstroom voor het reinigen van gegevens te beschrijven in deze volgorde: 
 
 duplicaten → 2) gegevenstypen → 3) ontbrekende waarden → 4) outliers. Voor elke stap omvatten: doel, wanneer het wordt toegepast en gecommenteerde code. Gebruik panda's om een volledige werkstroom voor het reinigen van gegevens te beschrijven in deze volgorde: 
 
 duplicaten → 2) gegevenstypen → 3) ontbrekende waarden → 4) outliers. Voor elke stap omvatten: doel, wanneer het wordt toegepast en gecommenteerde code. Het resultaat (wat er goed uitziet) Hieronder staat een voorbeeld dat u kunt hergebruiken. Let op dat we geen hardcode blindelings; wij vertakken door dtype. slightly tweaked fillna(0) import pandas as pd
​
def clean_frame(df: pd.DataFrame) -> pd.DataFrame:
    # 1) Duplicates: reduce noise before anything else
    dup_count = df.duplicated().sum()
    if dup_count:
        df = df.drop_duplicates().copy()
​
    # 2) Types: make sure comparisons and maths behave
    # Example: parse dates if you expect time-series logic later
    if "created_at" in df.columns:
        df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
​
    # 3) Missing values: strategy depends on data type and meaning
    for col in df.columns:
        if df[col].isna().any():
            if pd.api.types.is_numeric_dtype(df[col]):
                # Use median for robustness (less sensitive than mean)
                df[col] = df[col].fillna(df[col].median())
            else:
                # For categorical/text, choose a clear placeholder
                df[col] = df[col].fillna("Unknown")
​
    # 4) Outliers: apply only to numeric columns where it makes sense
    num_cols = df.select_dtypes(include="number").columns
    for col in num_cols:
        q1 = df[col].quantile(0.25)
        q3 = df[col].quantile(0.75)
        iqr = q3 - q1
        if iqr == 0:
            continue  # no spread, no meaningful outliers
        lower = q1 - 1.5 * iqr
        upper = q3 + 1.5 * iqr
        df = df[(df[col] >= lower) & (df[col] <= upper)]
​
    return df
 Dit is geen “perfecte gegevensreiniging” (dat is afhankelijk van het domein), maar het een samenhangende, verdedigbare pijpleiding met beslissingscontroles – precies wat uw oorspronkelijke oproep niet vereiste. is De verborgen valkuilen: grenzen van modelcapaciteiten Soms is het model verkeerd omdat het de gegevens niet heeft - vooral voor "laatste" getallen. Als je hetzelfde feitelijke falen ziet na het verscherpen van grenzen en het vragen om bronnen, stop dan met loopen. Voeg een gezonde fallback toe: 
 
 
 
 “Als je het niet weet, zeg dan dat je het niet weet.” “Vertel het laatste jaar waar je zeker van bent.” “Voorstel welke bron ik moet raadplegen.” Dit verandert een hallucinatie in een nuttig antwoord. Veel voorkomende fouten (en hoe ze te voorkomen) Fout 1: “please be correct” als correctie Dat is geen beperking, het is een wens. In plaats daarvan: correctheid definiëren via grenzen + verificatie + achteruitgang. Fout 2: alles te beperken Als je één defect oplost door tien ongerelateerde regels toe te voegen, krijg je snel opgeblazen en slechtere naleving. Patch het defect, niet je angst. Fout 3: Je hypothese niet valideren Je kunt niet beweren dat een fix werkte tenzij je het opnieuw uitvoert met de minimale patch en de verwachte verbetering ziet. Behandel het als een unit test. Praktische gewoontes die deze stick maken 
 
 
 
 
 
 Houd een falen taxonomie (feiten / logica / formaat / rol). Gebruik one-patch-per-run tijdens het debuggen. Maak een prompt changelog (ernstig, dit is de cheat code). Als je structuur nodig hebt, gebruik schema's + kleine voorbeelden. Als je betrouwbaarheid nodig hebt, vraag onzekerheid openbaarmaking. Onjuiste antwoorden zijn niet alleen vervelend - ze zijn Als je leert om ze te lezen, stop je met "verzoeken" en begin . Informatie engineering

Read My Stories

Deze audio wordt geproduceerd in de originele taal van het verhaal!

Prompt Reverse Engineering: Fix Your Prompts door de verkeerde antwoorden te bestuderen

About Author

OPMERKINGEN

LABELS

DIT ARTIKEL WERD GEPRESENTEERD IN

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps