Помош има репутација за да биде "базирана на вибрации." Ти пишуваш нешто, моделот одговара, ти прилагодуваш реченица, тоа добива подобро, и ќе продолжите да нудите додека не работи - ако работи. малку Тоа е кошмар за се што е сериозно: текст за усогласеност, цевки за податоци, генерација на код или излези "не ме срамите пред тимот". Еве го и надградбата: . Prompt Reverse Engineering Тоа е токму она што звучи како: , а потоа се применуваат насочени поправки - како што е дебугирање, а не претпоставки. use the model’s wrong answer to backtrack into what your prompt failed to define Размислете за лошиот исход како начин на кој вашиот модел вели: 
 
 „Не ми кажавте што е важно. „Не ми кажавте што е важно. Да го претвориме тоа во повторувачки работен тек. Зошто обратен инженеринг победи случаен повик за прилагодување Дури и кога ќе напишете повик "добро изгледа" (јасно прашање, љубезен тон, разумни ограничувања), моделите сè уште пропуштаат: 
 
 
 
 
 
 Временскиот прозорец за кој се грижите целосноста што ја очекувате, формат на вашиот надолу-код бара, улогата во која сакате моделот да остане, Дефиницијата на „правилно“ Обратното инженерство ви дава метод за лоцирање на недостасувачката спецификација – Без да го надувате вашиот повик во роман. fast Четирите начини на неуспех (и она што навистина ви го кажуваат) Повеќето брзи неуспеси паѓаат во една од овие кутии. Ако можете да го именувате кутијата, обично можете да го поправите повикот во еден премин. 1) Фактички неуспеси Одговорот сигурно ги наведува погрешните факти, меша години или измислува броеви. Symptom: Задачи со густи знаења: извештаи за пазарот, академско пишување, резиме на политиката. Typical trigger: What your prompt likely missed: 
 
 
 
 експлицитен временски опсег („календарна година 2023“ против „последните 12 месеци“), изворни барања (цитати, именувани сетови на податоци), Повторно однесување кога моделот не знае. Вие прашувате: Моделот одговара со користење на бројките од 2022 година и никогаш не вели каде ги добил. Example (UK-flavoured): „Анализирајте ги топ 3 брендови на електрични возила според глобалната продажба во 2023 година.“ Prompt patch pattern: 
 
 
 
 Додадете „граница на фактите“: година, географија, единица. Потребни се цитати или транспарентна "Не сум сигурен" фалба. Побарајте од него да наведе прекинување на податоците ако точните броеви не се достапни. 2) Скршена логика / пропуштени чекори Излезот изгледа веродостоен, но тој ги прескокнува чекорите, ги прескокнува заклучоците или дава „облик“ кој се преправа дека е процес. Symptom: Процедури, дебагирање, размислување во повеќе чекори, архитектонски планови. Typical trigger: What your prompt likely missed: 
 
 
 
 „Покријте ги сите основни чекори“ “Објаснете зависност / нарачка” “Користете фиксна рамка (проверка / цевка / рецепт)” Вие прашувате: Таа само ги набројува „ракување со недостасувачките вредности“ и „отстранување на заостанувањата“ и го нарекува ден. Example: “Објаснете комплетен работен тек за чистење на податоци во Python.” Prompt patch pattern: 
 
 
 
 Притиснете ја секвенцата (A → B → C → D). Потребна е причина за нарачката. Потребен е тест за донесување одлуки („Како можам да знам дали е потребен овој чекор?“). 3) Формат на дрифт Ќе побарате табела за означување / JSON / YAML / блок на код ... и тоа враќа пријателски параграф како што е пишување на блог пост. Symptom: Сè што значеше за машините: структурирани излези, датотеки за конфигурирање, корисни оптоварувања, табели. Typical trigger: What your prompt likely missed: 
 
 
 
 строгост („исходот важи само за JSON“), ограничувања на шемата (клучи, типови, потребни полиња), краток пример (неколку снимки) моделот може да имитира. Вие прашувате: Таа одговара во проза и го меша продавачот + датумот на издавање во една реченица. Example: "Дајте ми табела за марка на три популарни LLMs." Prompt patch pattern: 
 
 
 
 Додадете шема, плус „без дополнителни клучеви“. Додадете „без проза надвор од блокот“. Вклучувајќи мал пример на ред. 4) Улогата / тонот на дрифт Барате објаснување од педијатар и добивате медицински дневник. Symptom: roleplay, поддршка на клиентите, коучинг, stakeholder comms. Typical trigger: What your prompt likely missed: 
 
 
 
 како зборува улогата (ниво на читање, топлина, табу жаргон), примарната цел на улогата (убедување, убедување, деескалација), Забранети содржини („избегнувајте медицински жаргон; дефинирајте термини ако се неизбежни“). Prompt patch pattern: 
 
 
 
 Забележете ја публиката (“загрижен родител”, “млад инженер”, “CTO”). Определете ги правилата за тонот („пријателски, не-судечки, англиски јазик во Велика Британија“). Напишете го речникот Do/Don’t. Пет чекори за обратен инженеринг Ова е "стоп претпоставувањето" лак. Држете го лесен. Направете една промена во исто време. Чекор 1: Идентификувајте го отстапувањето (означете го точниот недостаток) Напишете го очекуваниот излез како контролна листа, а потоа истакнете каде излезот се разликува. Пример за контролна листа: 
 
 
 
 
 година = 2023 / Вклучувајќи го пазарниот удел Извори Споредете ги топ 3 брендови Ако не можете точно да го опишете недостатокот, не можете точно да го поправите. Чекор 2: Инферирање на недостасувачката спецификација (прометниот дефект) За секое отстапување прашајте: 
 
 
 Кои инструкции би го спречиле ова? Која двосмисленост моделот „реши“ во погрешна насока? Типични недостатоци : 
 
 
 
 
 недостасува граница (време, регион, единица) недостаток на целосна ограниченост, Недостаток на шема за излез, недостаток на ограничувања на тонот / улогата. Чекор 3: Тестирајте ја хипотезата со минимална проба за уредување Немојте да го препишете целиот повик. Поправете еден дефект и повторете го. Ако резултатот се подобри на очекуваниот начин, вашата хипотеза е во право. Чекор 4: Применување на насочен модел за оптимизација Откако е потврдено, се применува најмалата трајна поправка: 
 
 
 
 
 Гранична клаузула: „Користете податоци од 2023 (јан-декември); ако не сте сигурни, кажете го тоа“. Клаузула за шема: „Врати валиден JSON што одговара на оваа шема...“ Клаузула за покривање: „Вклучете ги овие 6 чекори...“ Тонот на клаузулата: "Објаснете како да сум нов; избегнувајте жаргон." Чекор 5: Запишете ја промената (изградете го вашиот прост changelog) Ова е делот што повеќето луѓе го прескокнуваат - и делот што се претвора во инженеринг пракса. Чувајте мал дневник: 
 
 
 
 
 
 Оригинална брзина Моделот кој не успеа Недостаток на хипотеза Patch се применува Резултат Со текот на времето, ќе изградите лична библиотека на "обичен неуспех → стандарден патч". Еден целосен работен пример: поправање на повик за "работен тек за чистење на податоци" Ајде да го направиме тоа правилно. Почетна Брзо 
 
 Користејќи Python, напишете го целиот процес на чистење на податоците со чекори и код. Користејќи Python, напишете го целиот процес на чистење на податоците со чекори и код. Недостаток на (лоши) резултати Повторно се враќаат само две точки: 
 
 
 Пополнете ги недостасувачките вредности Отстранување на Outliers И го фрла кодот без контекст, без ред и без контрола на одлуките. Обратна инженеринг дијагноза Deviation points 
 
 
 
 Недостасуваат основни чекори (дупликати, тип лиење, стандардизација) Нема оправдување за наредба Кодот нема коментари и забелешки за применливост Prompt defects 
 
 
 
 Нема „листа на основни чекори“ → моделот избира делумен поднабор Нема ограничување на нарачката → Моделот излегува во произволен редослед Нема "објаснете кога да го користите" → кодот станува копирање / вметнување Поттикнување на барање (минимално, но специфично) 
 
 
 Користејќи панди, опишете комплетен работен тек за чистење на податоци во овој редослед: 
 
 duplicates → 2) data types → 3) missing values → 4) outliers.   For each step include: purpose, when it applies, and commented code.   Also state how to detect whether the step is needed.” Користејќи панди, опишете комплетен работен тек за чистење на податоци во овој редослед: 
 
 дупликати → 2) типови на податоци → 3) недостасува вредности → 4) outliers. За секој чекор вклучуваат: цел, кога се применува и кодот коментиран. Резултат (што добро изгледа) Подолу е а пример можете да го користите повторно. Ве молиме имајте на ум дека не го користите хардкодот слепо; ние се раздвои со 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
 Ова не е „совршено чистење на податоци“ (што зависи од доменот), но тоа е кохерентен, одбрамбен гасовод со контрола на одлуките – токму она што вашиот оригинален повик не го побарал. е Скриената стапица: границите на можностите на моделот Понекогаш моделот е погрешен затоа што нема податоци – особено за „последни“ броеви. Ако го видите истиот фактички неуспех откако ќе ги затегнете границите и ќе побарате извори, престанете да се лупате. Додадете здрав пад: 
 
 
 
 „Ако не знаете, кажете дека не знаете.“ „Запишете ја последната година во која сте сигурни.“ „Предложи кој извор треба да го консултирам.“ Ова ја претвора халуцинацијата во корисен одговор. Чести грешки (и како да ги избегнете) Грешка 1: „Ве молиме бидете точни“ како поправка Тоа не е ограничување, тоа е желба. Наместо тоа: дефинирајте ја коректноста преку граници + верификација + пад. Грешка 2: Претерано ограничување на сè Ако поправите еден недостаток со додавање на десет нерелевантни правила, веднаш ќе добиете надуеност и полошо усогласеност. Поправете го дефектот, а не вашата анксиозност. Грешка 3: Не ја потврдувате вашата хипотеза Не можете да тврдите дека поправка функционирала, освен ако не го рестартирате со минималниот патч и не го видите очекуваното подобрување. Третирајте го тоа како тест за единица. Практични навики кои го прават овој стап 
 
 
 
 
 
 Чувајте таксономија за неуспех (факти / логика / формат / улога). Користете One-Patch-Per-Run за време на дебугирањето. Изградете веднаш changelog (сериозно, ова е мамење код). Кога ви е потребна структура, користете шеми + мали примери. Кога ви е потребна доверба, побарајте откривање на неизвесноста. Лошите одговори не се само досадни – тие се Ако научите да ги читате, ќе престанете да „промотирате“ и ќе започнете . Информации engineering

Read My Stories

Ова аудио е произведено на оригиналниот јазик на приказната!

Prompt Reverse Engineering: Поправете ги вашите ветувања со проучување на погрешните одговори

About Author

КОМЕНТАРИ

ВИСЕТЕ ТАГОВИ

ОВОЈ СТАТИЈА БЕШЕ ПРЕТСТАВЕН ВО

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps