Hur jag gör prompts återanvändbara över flera projekt

När ett prompt-workflow fungerar i ett projekt vill jag kunna flytta metoden till nästa utan att kopiera hundratals rader projektspecifik kontext. Lösningen har för mig blivit lager: stabil kärna, lokal kontext, variabel input och separat eval-pack.

Återanvänd inte hela prompten — återanvänd kontraktet

När jag vill använda samma AI-arbetsflöde i flera projekt försöker jag inte bygga en gigantisk universell prompt. Jag separerar det som är konstant från det som är projektdata. Konstanten är workflow, output contract och quality gates. Projektet levererar kontext, schemas, exempel och begränsningar.

Fyra lager räcker långt

Jag delar ofta upp i core instruction, project context, task input och examples/evals. Anthropic rekommenderar också tydlig separation av instruktioner, kontext, exempel och variabla inputs. För mig är vinsten främst versionshantering: jag kan ändra ett lager utan att kopiera en 400-raders prompt till fem repos.

Låt projektet äga sin verklighet

Databasschema, tonalitet, produktregler och interna namn hör inte hemma i en global prompt. De ska ligga nära projektet och kunna uppdateras där. Då kan samma reviewer- eller researchworkflow användas över flera utan att bära gammal kontext.

Definiera adapters för verktyg

Ett workflow kan vara samma även om exekveringen skiljer sig mellan , Codex eller Gemini CLI. Jag vill därför att kärnan säger vad som ska göras, medan adapterlagret säger vilka tools eller filer som används. Det är samma princip jag använder för portabla Skills.

Versionera beteendet

När core prompt ändras ska det gå att veta vilken version som producerade ett resultat. Det gör regressioner möjliga. Annars kan två team köra 'samma prompt' men i praktiken ha olika kopior och olika kvalitetsnivå.

Bygg ett litet eval-pack

För verklig återanvändning behöver jag 5–20 representativa testfall som följer med workflowet. Då kan jag se om en förändring förbättrar ett projekt men försämrar ett annat. OpenAI:s eval-/grader-upplägg — fortfarande en beta-yta som kan ändra fältnamn och beteende — stödjer samma grundidé: definiera testdata och criteria separat från modellen som körs.

Återanvändbarhet är ett arkitekturproblem

Det som gör prompten portabel är alltså inte smartare formulering. Det är separation of concerns, stable contracts, adapters och regressionstestning. När de delarna finns blir prompttexten ofta kortare.

Min praktiska tumregel

Återanvänd workflow och kontrakt; låt projektet äga sin kontext och sina data.