Från research paper till fungerande AI Skill
Det finns en frestande men dålig genväg när man vill bygga en AI Skill från forskning: ladda upp ett paper, be modellen "gör en skill av det här" och acceptera den första sammanfattningen som instruktion. Jag gjorde i praktiken motsatsen när jag byggde min Humanizer.
Det finns en frestande men dålig genväg när man vill bygga en AI Skill från forskning: ladda upp ett paper, be modellen "gör en skill av det här" och acceptera den första sammanfattningen som instruktion. Jag gjorde i praktiken motsatsen när jag byggde min Humanizer. Jag behandlade inte forskningen som en promptkälla utan som ett råmaterial som först behövde brytas ned i evidens, begränsningar, regler och testbara beteenden. Skillen kom sist.
Det är en viktig skillnad. Ett research paper är skrivet för att beskriva en studie. En Skill är skriven för att styra ett system i återkommande arbete. Mellan de två behövs därför en översättning från vad forskarna observerade till vad modellen faktiskt får göra. Den översättningen är där nästan hela kvalitetsarbetet ligger.
Paperet är inte specifikationen
Det första jag låser är vad ett paper faktiskt kan stödja. Om studien exempelvis analyserar lång engelskspråkig fiktion kan jag inte utan vidare göra regler som påstår sig gälla svensk myndighetstext, CV:n och produktcopy. Resultatdelen ger observationer inom en viss korpus och metod. Den ger inte automatiskt universella skrivlagar.
Därför skapar jag tre lager innan jag skriver en enda instruktion:
Om det tredje lagret inte går att formulera utan att tänja på det första eller andra blir resultatet en referensnotering, inte en regel. Det här är kanske den viktigaste principen i hela flödet: all forskning behöver inte bli beteende.
Jag bygger ett evidence ledger före SKILL.md
För Humanizer-arbetet blev nästa steg ett evidence ledger. Jag vill att varje stark regel ska kunna spåras tillbaka till ett underlag och att jag tydligt ser vilka regler som är redaktionell praxis snarare än forskningsfynd.
En förenklad rad kan se ut så här:
Det sista fältet är viktigt. Jag använder inte bara "regel/ingen regel", utan exempelvis CORE, CONDITIONAL, EDITORIAL och EXPERIMENTAL. Då tvingas jag skilja mellan sådant som alltid bör gälla, sådant som bara är relevant under rätt trigger och sådant som är en rimlig redaktionell tumregel men inte får säljas in som forskningsbevis.
Det minskar också en vanlig AI-bias: modellen älskar tydliga listor. Ett paper fullt av reservationer kan på några sekunder förvandlas till "17 regler som mänskliga skribenter följer". Evidence ledgern bromsar just den förvandlingen.
Extrahera inte bara findings — extrahera villkoren
När jag går igenom ett paper letar jag därför efter minst sex saker: forskningsfrågan, korpus/population, metod, observerade fynd, begränsningar och vad författarna uttryckligen inte visar.
Det sjätte är lätt att missa. Om studien hittar statistiska skillnader mellan två korpus betyder det inte automatiskt att ett enskilt stilgrepp är dåligt, att det avslöjar AI-ursprung eller att en text blir bättre om greppet tas bort. Klassificerande drag och kvalitetsproblem är två olika saker.
För mig blev detta centralt i Humanizer 2.3.0, den version jag arbetade med när det här skrevs. Skillen fick uttryckliga regler om att inte använda forskningen som AI-detektor och inte skapa slumpmässig "mänsklighet" genom stavfel, slang, märklig variation eller fabricerade erfarenheter. Det är ett exempel på hur en begränsning i forskningen kan bli en safety/fidelity-regel i Skillen snarare än en skrivregel.
Gör operationaliseringen lokal och observerbar
En dålig Skill-instruktion låter ofta så här:
Gör texten mer mänsklig och mindre AI-typisk.
Det går inte att testa ordentligt. Jag föredrar instruktioner som pekar på observerbar friktion:
Nu finns både trigger, åtgärd och gräns. Det går att skapa eval-exempel där regeln ska aktiveras och där den absolut inte ska aktiveras. Jag försöker formulera varje viktig regel som TRIGGER -> ACTION -> CONSTRAINT -> STOP CONDITION. Det är betydligt mer användbart än ett långt dokument med stilideal.
Bygg beslutsträd där flera villkor styr utfallet
En del av översättningen handlar inte om enskilda regler utan om regler som interagerar. När flera villkor tillsammans avgör utfallet blir ett långt stycke text lätt oprecist — jag skriver då hellre ett beslutsträd. Om källan är primär och aktuell fortsätter jag. Om den är sekundär men verifierbar kvalificerar jag påståendet. Om källor motsäger varandra blockerar jag och eskalerar. Det gör regeln testbar på ett sätt som löpande text sällan blir.
Samma översättning håller principen portabel. Själva regeln — inte ett specifikt verktygsanrop — hör hemma i kärnan, medan plattformsspecifika detaljer kan ligga i en adapter. Då fungerar samma metod oavsett om modellen körs i Claude, ChatGPT eller Gemini, även när verktygsgränssnitten skiljer sig åt.
SKILL.md ska vara kontrollplanet, inte forskningsarkivet
När evidensarbetet är klart blir det tydligare vad som faktiskt ska ligga i Skillens entrypoint. Anthropic beskriver Skills som mappar med SKILL.md och valfria stödresurser som laddas dynamiskt. Samma grundidé återkommer i moderna Skill-system: metadata avgör när en Skill är relevant, medan tyngre material kan ligga i separata resurser och bara laddas när det behövs.
Jag använder därför ungefär denna struktur:
SKILL.md innehåller workflow, prioriteringar, non-negotiables och navigation. Den behöver veta att en forskningsavgränsning finns och när den ska läsas, men den behöver inte återge fem sidor metodbeskrivning varje gång användaren vill putsa ett mejl. Det är progressive disclosure i praktiken: håll den alltid laddade instruktionen liten och flytta detaljer till resurser som aktiveras vid behov.
Från regel till eval
En Skill utan evals är lätt att överskatta. Den kan kännas bra på tre lyckade exempel och samtidigt ha en regressionsrisk som man aldrig ser.
För varje viktig regel försöker jag skapa minst tre typer av testfall: positive trigger — regeln ska användas, negative trigger — regeln ska inte användas, och fidelity trap — modellen kan förbättra stil men riskerar att ändra fakta eller ståndpunkt.
Exempel för en Humanizer:
Det tredje fallet är ofta viktigast. Evals ska inte bara bevisa att Skillen kan "göra mer"; de ska också bevisa att den kan låta bli.
Separera forskning, redaktion och säkerhet
En annan förändring jag gjorde var att sluta låta allting hamna i samma regellista. Jag vill kunna säga varför en regel finns: RESEARCH är en direkt härledd men avgränsad observation, EDITORIAL är professionell skriv- eller redigeringspraxis, och SAFETY/FIDELITY förhindrar fabricering, betydelseglidning eller överredigering.
Det här gör Skillen ärligare. En bra redaktionell regel behöver inte låtsas vara akademiskt bevisad för att vara bra. Samtidigt blir det svårare att använda ett spännande forskningsfynd som universell sanning.
Vad jag gör när flera papers pekar åt olika håll
När underlaget växer kommer källor att överlappa och ibland motsäga varandra. Jag försöker inte be modellen skapa en "balanserad kompromissregel" direkt. Först skiljer jag på konfliktens typ: olika genre, olika språk, olika modellgeneration, olika metod, olika definition av samma fenomen, eller verkligt motstridiga resultat.
Ofta försvinner konflikten när man återinför kontexten. Ett drag kan vara problematiskt i lång fiktion men neutralt i teknisk dokumentation. En annan studie kan mäta detektion medan jag bryr mig om redaktionell kvalitet. De svarar då på olika frågor.
Om konflikten kvarstår får regeln lägre säkerhetsgrad eller blir EXPERIMENTAL. Skillen ska inte låta säkrare än källmaterialet.
Hur jag använder ett paper utan att låsa fast Skillen i paperet
Det finns också en arkitektonisk risk: man bygger Skillen så tätt runt ett enskilt paper att hela systemet måste skrivas om när bättre forskning kommer.
Jag försöker därför låta forskningen fylla en stabil abstraktion: source -> evidence statement -> principle -> operational rule -> eval. Om en ny studie ändrar evidensläget kan jag uppdatera evidence statement, princip eller regel utan att behöva kasta hela workflowet. Det är samma anledning till att jag skiljer källregister från själva skrivinstruktionen.
Versionshantering blir då begriplig. Jag kan säga att R012 ändrades därför att evidensen breddades, inte bara att "prompten blev bättre".
Källor ska följa med hela vägen
När Skillen bygger på extern forskning vill jag kunna svara på två frågor även sex månader senare: varifrån kommer den här regeln, och vilken version av källan och vår tolkning användes när regeln skapades?
Därför sparar jag source metadata, gärna inklusive datum och identifierare. För PDF:er eller nedladdade artefakter kan en hash hjälpa till att visa att filen man granskar senare är samma fil som vid den ursprungliga analysen. Hashen bevisar inte sanningen i dokumentet. Den bevisar bara artefaktidentitet — vilket ändå är mycket användbart i ett reproducerbart researchflöde.
Min produktionsordning för paper → Skill
I praktiken ser min process nu ut så här:
Det ser långsammare ut än "sammanfatta PDF:en och skriv en prompt". Det är också därför resultatet går att förvalta.
Det viktigaste jag har lärt mig
En research-backed Skill är inte en forskningssammanfattning i YAML-kläder. Den är ett litet kunskapssystem med provenance, begränsningar, regler, routing och tester.
Det är där jag tycker Skills blir riktigt intressanta. De gör det möjligt att ta något som annars hade levt som anteckningar — ett paper, en bok, en standard eller en intern metod — och omvandla det till ett återanvändbart arbetsflöde. Men kvaliteten avgörs inte av hur snygg SKILL.md är. Den avgörs av om varje beteende fortfarande kan spåras tillbaka till rätt typ av evidens och om systemet vet när det inte ska använda regeln.
När ett paper innehåller tabeller, figurer och appendix
En praktisk detalj som har blivit viktig för mig är att "läsa paperet" inte betyder att bara extrahera löptext. Ofta ligger de mest användbara avgränsningarna i metodtabeller, appendix eller definitioner av features. Om ett paper bygger en klassificerare på hundratals textdrag behöver jag veta vilka drag som faktiskt var statistiskt stabila, hur de definierades och om författarna gjorde multipeltestkorrigering eller andra metodval som påverkar tolkningen. Jag vill inte att en språkmodell ser en figur med tio staplar och gör den till tio skrivregler.
Därför gör jag ett separat "method extraction"-pass. Jag noterar sample size, urvalskriterier, hur output annoterades, vilken modellgeneration som studerades, språk och genre, samt om resultaten är deskriptiva, prediktiva eller kausala. Det här är inte akademisk pedanteri för sakens skull. Det avgör vad Skillen får säga. Om en studie är bra på att klassificera AI- och människotext betyder det fortfarande inte att varje prediktiv feature är något en redaktör bör ta bort.
När paperet är en PDF sparar jag också sidreferenser i evidence ledger. Då kan en framtida granskare gå från R010 tillbaka till exakt tabell eller stycke, i stället för att lita på min sammanfattning av sammanfattningen.
Böcker kräver en annan extraktionsstrategi
En bok är ofta mer användbar som metodkälla men svagare som atomiserad evidens. För en fackbok vill jag därför först skapa en kapitelkarta: vilka kapitel innehåller principer, vilka innehåller exempel, vilka bygger argument och vilka bara ger bakgrund. Jag extraherar sedan återkommande beslutsregler snarare än varje tips.
Om tre kapitel på olika sätt säger "definiera problemet före verktyget" är det sannolikt en kärnprincip. Om ett enskilt exempel nämner ett visst verktyg är det oftare kontext än regel. Skillen bör representera metoden bakom boken, inte vara en komprimerad återgivning sida för sida.
Jag använder samma lineage: chapter -> principle candidate -> supporting examples -> boundary -> operational rule -> eval. Det gör det också lättare att ersätta bokreferensen om en framtida källa ger bättre stöd för samma princip.
Hur jag skiljer "bra idé" från "regel som ska styra modellen"
Jag använder fyra frågor innan något får flytta in i Skillens aktiva instruktioner: är beteendet observerbart i input eller output? Kan jag formulera när beteendet inte ska användas? Går det att testa utan att läsa modellens tankegång? Gör regeln resultatet bättre enligt uppgiftens mål, inte bara mer likt källmaterialet?
Om svaret på fråga två är nej är regeln ofta för generell. Om fråga tre är nej blir den svår att regressionssäkra. Om fråga fyra är nej har jag kanske bara lärt modellen att imitera en studie i stället för att lösa användarens uppgift.
Det här filtret har gjort mina Skills kortare. Det är en bra sak. En Skill ska inte vara så komplett som möjligt; den ska vara så operativt precis som möjligt.
Ett exempel på en regel jag medvetet inte skulle skapa
Säg att ett paper visar att AI-text i den studerade korpusen oftare använder en viss skiljeteckentyp. Den enklaste Humanizer-regeln vore då "undvik det skiljetecknet". Jag skulle inte lägga in den. Skiljetecknet kan vara fullt idiomatiskt och viktigt för rytm eller betydelse. Det faktum att det har prediktiv signal i en classifier gör det inte till ett kvalitetsfel.
I stället kan observationen hamna i evidence ledger med status NON-OPERATIONAL. Den är intressant för förståelsen av paperet men ska inte påverka redigeringen. Den här kategorin är nyttig eftersom den hindrar mig från att tro att varje insamlad observation måste "användas".
Hur jag hanterar uppdaterad forskning
När ett nytt paper kommer vill jag inte läsa om allt från noll. Jag jämför den nya källans scope mot befintliga evidence statements: stödjer den en befintlig regel, begränsar den regeln, motsäger den den eller introducerar den ett nytt fenomen? Kategorierna blir SUPPORTS, NARROWS, CONTRADICTS, EXTENDS och UNRELATED.
Det blir en ändringslogg för kunskapen. Om flera nya källor exempelvis visar att en tidigare fiction-specifik observation även finns i journalistisk prosa kan boundaryn breddas. Men det ska ske explicit och med nya evals för den nya genren. Jag vill aldrig att "mer research" automatiskt betyder "fler regler". Ibland betyder bättre research att en gammal regel ska tas bort.
När Skillen bör säga "underlaget räcker inte"
Research-backed betyder inte att varje fråga får ett research-backed svar. Om användaren vill tillämpa en fiction-specifik regel på juridisk text och Skillens källor inte stödjer det ska systemet inte låtsas att metoden generaliserar. Det bör växla till generella redaktionella principer eller säga att den forskningsspecifika regeln inte är tillämplig. För mig är den sortens avgränsning ett kvalitetstecken: Skillen vet både vad den kan och var dess evidens tar slut.
Vad jag vill se i en slutlig audit
Innan en research-backed Skill går i produktion vill jag kunna ta en slumpmässig regel och följa hela kedjan bakåt: från aktiv instruktion till princip, evidence statement, source location och eval. Jag vill också kunna göra motsatsen: ta en viktig källa och se vilka regler som påverkas om vår tolkning ändras. Om den spårbarheten saknas är Skillen fortfarande mer prompt än kunskapssystem.
Källor
Anthropic och OpenAI uppdaterar de här sidorna löpande, så innehållet kan ha ändrats sedan jag skrev det här.
Ett konkret exempel på hur en observation blir en regel
Anta att ett paper observerar att en viss korpus oftare överförklarar ett tema efter att scenen redan gjort betydelsen tydlig. En dålig operationalisering är "ta bort förklaringar". En bättre kedja är:
Här har forskningsfyndet inte blivit ett ord- eller stilförbud. Det har blivit en diagnostisk fråga som bara aktiveras när texten faktiskt visar problemet. Det är den typ av transformation jag söker genom hela systemet.
Vad jag skulle automatisera i nästa version
När antalet källor växer vill jag automatisera de delar som är mekaniska: source metadata, hashning, regel-ID:n, länkar mellan rule och eval och rapportering av regler som saknar test. Jag skulle däremot inte automatisera själva beslutet att ett forskningsfynd "bör bli en regel". Den bedömningen kräver fortfarande förståelse för metod, genre, konsekvens och risken för övergeneralisering.
Ett enkelt CI-test skulle kunna kontrollera:
Då får Skillen samma typ av hygien som ett litet kodbibliotek.
Innan jag kallar processen produktionsklar
Samma CI-logik gäller hela vägen ut till skarpt läge, inte bara reglerna. Jag kontrollerar att source register och evidence ledger är versionerade rad för rad, att varje rule_id går att spåra till en source_id med provenance, att first-hand-formuleringar i Skillen bara härleds från material som faktiskt finns i mina egna referensfiler, att CORE-reglernas eval-par (positive/negative/fidelity) existerar enligt CI-testet ovan, och att SKILL.md beskriver vad systemet ska göra när ett paper eller en källa saknar den täckning en regel kräver — inte bara när evidensen är fullständig.
De flesta produktionsproblem jag har hittat i det här arbetet har inte berott på att modellen saknade intelligens. De har berott på ett rule_id utan source_id, en status som inte matchade det bakomliggande underlaget, eller en eval som saknades för en CORE-regel. Därför är den här kontrollen samma sorts kvalitetsbarriär som ett testsuite är för vanlig programvara — bara tillämpad på ett regelbibliotek i stället för på kod.