Gammal kod som “fungerar” kan ändå bli en daglig kostnad. Varje ändring känns riskfylld, logiken läser som en labyrint och ingen vill röra delarna med duplicerade grenar och defensiva kontroller staplade fem lager djupt. Du lägger mer tid på att bevisa att du inte har trasat sönder något än på att faktiskt förbättra produkten.
Den här prompten för att refaktorisera gammal kod är byggd för tekniska ledare som behöver säkrare diffar när roadmapen ska levereras, konsulter som städar upp ärvda script innan de lämnas tillbaka till en kund, och produktteam som sitter fast med att underhålla ett skört internt verktyg. Resultatet är en tydligare, mindre version av din befintliga kodsnutt plus en strukturerad förklaring av vad som ändrades, vad som förblev detsamma och var edge cases fortfarande behöver bekräftas.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Det här får du |
|---|---|---|
|
|
|
Hela AI-prompten: legacy-refaktor med tydlighet först
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[PRIMART_MAL] |
Ange huvudsyftet med omskrivningen, till exempel att förbättra läsbarhet, underhållbarhet eller prestanda. Till exempel: "Förbättra läsbarhet och underhållbarhet utan att ändra funktionalitet eller prestanda."
|
|
[PROGRAMMERINGSSPRAK] |
Ange vilket programmeringsspråk skriptet är skrivet i. Till exempel: "Python"
|
|
[KONTEXT] |
Ange relevanta begränsningar, krav eller bakgrundsinformation om skriptet, till exempel körtidsbegränsningar, beroenden eller användningsscenarier. Till exempel: "Måste stödja Python 3.6 och undvika externa bibliotek."
|
|
[SKRIPT] |
Klistra in hela skriptet som behöver skrivas om. Se till att all relevant kod för analysen finns med. Till exempel: "def calculate_sum(numbers):
total = 0
for num in numbers:
total += num
return total"
|
|
[VERSALER_MED_UNDERSCORE] |
Ge exempel på namnkonventioner för variabler som måste följas, om det är relevant. Till exempel: "Alla konstanter måste använda UPPERCASE_WITH_UNDERSCORES, t.ex. MAX_RETRIES, DEFAULT_TIMEOUT."
|
Proffstips för bättre resultat från AI-prompten
- Klistra in riktiga in- och utdata, inte bara koden. Om du kan, lägg med några exempelanrop och exakt den output (eller loggar) du förväntar dig. En snabb notis som “När
userIdsaknas ska den kastaInvalidArgumentmed det här meddelandet” förbättrar bevarandet av beteende dramatiskt. - Berätta vad “beteende” inkluderar i din miljö. Beteende är inte bara returvärden; det kan inkludera utskrivna loggar, DB-skrivningar, nätverksanrop, kastade feltyper och till och med ordningen på operationer. Lägg till en kort följdprompt: “Behandla loggrader, undantagstyper/-meddelanden och ordningen på sidoeffekter som en del av kontraktet.”
- Ange språk och begränsningar uttryckligen. Prompten föredrar vanliga idiom, men du behöver ändå sätta ramar som “endast Python 3.11” eller “Node 18, inga nya beroenden”. Har du stilkrav (lintregler, ramverksmönster), säg det i en mening.
- Iterera genom att strama åt en väg i taget. Efter första utkastet, be: “Fokusera nu endast på felhanteringsvägen; behåll success-vägen identisk, men förenkla guards och ta bort duplicerade kontroller.” Gör sedan samma för happy path och därefter för den “sällsynta” grenen.
- Använd en “diff-granskning” innan du mergar. Be modellen motivera varje ändring som ser semantisk ut. Prova: “Lista varje ändring som kan påverka runtime-beteende (även om du tror att den inte gör det), och förklara varför den förblir ekvivalent.” Ärligt talat fångar detta subtila problem som omordnade villkor eller annan tidpunkt för undantag.
Vanliga frågor
Seniora mjukvaruingenjörer använder den för att göra “bara Bob förstår den”-script till kod som hela teamet tryggt kan ändra. Engineering managers lutar sig mot den för att minska risken i leverans genom att tvinga fram en tidig definition av oförändrat beteende och förväntade sidoeffekter. Tekniska konsulter använder den när de städar upp kundägda verktyg, eftersom prompten ger både en refaktor och en tydlig förklaring att lämna över. QA- eller testingenjörer får nytta av flödesöversikten och frågorna kring oklarheter, som ofta avslöjar saknade testfall och odokumenterade felkontrakt.
SaaS-bolag använder den för att refaktorisera script för fakturering, onboarding eller rapportering där beteendeförändringar kan få verklig kundpåverkan. När ni levererar varje vecka blir underhållbarhet en tillväxthävstång, inte något “nice to have”. E-handelsbolag får värde när gammal rabattlogik, feed-generatorer eller script för lagersynk har blivit röriga under år av snabbfixar. Promptens fokus på att bevara output och felbeteende är viktigt eftersom nedströms system ofta förväntar sig exakta format. Finansiella tjänster och fintech gynnas eftersom “oförändrat beteende” inkluderar strikt edge-case-hantering, revisionsvänliga felmeddelanden och konsekventa sidoeffekter. Byråer använder den när de tar över en kunds interna verktyg och behöver en säkrare, mer läsbar kodbas innan de lägger till nya funktioner.
En typisk prompt som “Refaktorisera den här koden så att den blir renare” misslyckas eftersom den: saknar en tydlig definition av vad som inte får ändras (utdata, sidoeffekter och felbeteende), inte ger någon strukturerad bekräftelse i föranalysen, ignorerar att plocka ut avsikten så att omskrivningen optimerar för stil i stället för betydelse, producerar “snygga” men beteendeförändrande ändringar (som omordnade villkor eller annan tidpunkt för undantag) i stället för ekvivalens, och missar steget där oklarheter ska leda till frågor i stället för gissningar. Den här prompten är bättre eftersom den tvingar fram intention först, mekanik sen, och behandlar försiktighet kring semantik som ett hårt krav.
Ja. Även om prompten inte har inbyggda variabler anpassar du den genom att lägga en kort rubrik ovanför koden: språk/runtime-version, vad som räknas som “beteende” (loggar, undantag, sidoeffekter) och eventuella begränsningar som “inga nya beroenden” eller “behåll publika funktionssignaturer oförändrade”. Om du har edge cases du bryr dig om, inkludera 3–5 exempel (inputs plus förväntad output eller fel). En bra följdfråga är: “Innan du refaktorerar, lista de observerbara beteenden du kommer att bevara och ställ sedan alla frågor du behöver för att undvika att gissa.”
Det största misstaget är att lämna definitionen av beteende för vag — i stället för “ändra inte beteendet”, säg “returvärden, kastade feltyper/-meddelanden och loggrader måste vara identiska”. Ett annat vanligt fel är att utelämna målmiljön: “JavaScript” är vagt, men “Node 18, CommonJS, ingen TypeScript” styr idiom och undviker inkompatibel syntax. Folk klistrar också in delar av koden utan omgivande kontrakt; “här är funktionen” är svagare än “här är funktionen plus anroparens förväntningar och exempelpayloads”. Till sist glömmer team att bekräfta oklarheter; om null-hanteringen är oklar, skriv det (“null ska behandlas som tom array”) eller låt modellen fråga innan omskrivning.
Den här prompten är inte optimal för storskaliga omdesigner där du faktiskt vill ändra beteende, API:er eller datamodeller, eftersom den är konservativ av design. Den passar också dåligt om du inte kan ge tillräckligt med kontext för att definiera korrekthet (inga exempel på in-/utdata, ingen kunskap om sidoeffekter), eftersom prompten rimligen kommer att pausa och ställa frågor. Om du behöver prestandaoptimering som primärt mål, använd i stället ett profiling-först-upplägg och behandla läsbarhetsändringar som ett sekundärt steg.
Felfri kod handlar inte om estetik; det handlar om att göra nästa ändring billigare och mindre skrämmande. Klistra in din kodsnutt i prompt-visaren, kör prompten och börja refaktorisera med bevarat beteende och logik som äntligen går att läsa rakt igenom.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.