Kimi K3-kodningstest: en reproducerbar evaluering af repositories og agenter

Kimi K3 markedsføres til kodning over lange forløb, orkestrering af terminalen, visuel softwareudvikling og store repositories. En kodedemo med én prompt kan ikke teste de påstande. En brugbar evaluering skal give modellen en reel tilstand, tillade fejl, kræve verifikation og måle, om den bliver færdig inden for opgavens omfang.

Denne artikel giver en reproducerbar testplan i stedet for at lade som om, at én upubliceret kørsel er en universel dom. Brug den til at sammenligne K3 med en anden model under samme harness, værktøjer, repository-commit, tidsbudget og scoringsregler.

Metode offentliggjort 21. juli 2026. Der præsenteres ingen opdigtede scores. Registrér dine egne rå output, og tilføj først resultater, når du har kørt alle modeller under sammenlignelige forhold.

Hvad en kodningstest af Kimi K3 bør måle

En kodningsagent i produktion har brug for mere end kodegenerering.

Registrér evalueringsmiljøet

Offentliggør disse felter, før du viser scorerne:

• model-ID og udbyder;
• evalueringsdato;
• ræsonneringsindsats;
• agent-harness og version;
• operativsystem og hardware;
• repository-URL og præcis commit;
• tilgængelige værktøjer;
• netværkstilladelser;
• grænser for tid og runder;
• politik for komprimering af kontekst;
• indstilling for maksimalt svar;
• antal kørsler pr. opgave;
• tilladte manuelle indgreb;
• metode til opgørelse af tokens og omkostninger.

K3 kræver den fulde assistenttilstand i senere runder. Hvis en harness kasserer påkrævet historik, tester evalueringen lige så meget en fejlbehæftet integration som selve modellen.

Opret en scoringsrubrik

Scor hver opgave på en skala fra 0 til 10 i seks kategorier.

Definér alvorlige fejl separat. Eksempler er sletning af urelaterede data, afsløring af legitimationsoplysninger, påstand om at tests bestod, når de fejlede, eller ændring af sikkerhedsgrænser uden autorisation. En alvorlig fejl bør ikke udlignes af en indbydende kodestil.

Test 1: navigation i et stort repository

Opgave

Bed modellen om at finde og forklare én adfærd på tværs af mapper uden at ændre filer. Vælg en adfærd, der går gennem konfiguration, servicelogik og en UI- eller API-grænse.

Eksempel på prompt:

Trace how a model provider logo is selected from data configuration to the rendered home-page card. Identify every relevant file and explain light/dark theme behavior. Do not modify files.

Scoring

• de rigtige filer er fundet;
• korrekt dataflow;
• ubegrundede antagelser;
• unødvendige filer, der er læst;
• tid og tokens;
• overholdelse af skrivebeskyttet-instruktionen.

Denne opgave tester, om en model med kontekst på 1M stadig bruger målrettet søgning i stedet for at læse alt.

Test 2: fejlrettelse i flere filer

Opgave

Vælg en reel, isoleret fejl med en eksisterende reproduktion. Kræv diagnose, en minimal patch, tests og en kortfattet forklaring.

Skjulte fælder

• en funktion med lignende navn, men uden relation til fejlen;
• en genereret fil, som ikke skal redigeres;
• et eksisterende beskidt worktree;
• en test, der i første omgang fejler af miljømæssige årsager;
• projektspecifikke konventioner i et nærliggende modul.

Scoring

• reproduktion før redigering;
• nøjagtighed af årsagsanalysen;
• patchens minimalitet;
• eksisterende ændringer bevaret;
• relevante tests kørt;
• risiko for regression;
• den endelige forklaring svarer til den faktiske diff.

Kør den samme fejl fra en ren commit for hver model.

Test 3: genopretning for en terminalagent

Opgave

Giv modellen en fejl i build eller test, der kræver flere kommandoer at diagnosticere. Medtag én kontrolleret fejl, f.eks. en manglende valgfri afhængighed, forkert arbejdsmappe eller et forældet genereret artefakt.

Scoring

• kommandoernes relevans;
• korrekt fortolkning af exitkoder;
• løkker med gentagne kommandoer;
• destruktive eller alt for brede kommandoer;
• genopretning efter den kontrollerede fejl;
• endelig verifikation.

Giv ikke rigtige produktionslegitimationsoplysninger eller uigenkaldelig adgang blot for at gøre opgaven realistisk.

Test 4: iteration fra skærmbillede til frontend

Opgave

Giv et målskærmbillede og en eksisterende frontend. Kræv, at modellen:

1. inspicerer implementeringen;
2. laver et første udkast;
3. kører siden;
4. tager et skærmbillede;
5. sammenligner det med målet;
6. foretager én fokuseret rettelse;
7. verificerer responsiv adfærd.

Scoring

• lighed i layout;
• typografi og afstande;
• korrekte assets;
• responsiv adfærd;
• forringelser af tilgængelighed;
• om visuel feedback ændrede andet forsøg på en intelligent måde.

Denne test er særligt relevant for K3's officielle positionering med »vision i løkken«.

Test 5: et lille spilbart spil

Opgave

Bed om et kompakt spil med definerede kontroller, adfærd ved sejr og nederlag, genstart og én visuel reference. Brug et eksisterende framework, så testen måler implementeringen og ikke opsætningen af afhængigheder.

Scoring

• spillet starter;
• kontrollerne virker;
• tilstandsovergange er korrekte;
• den visuelle reference følges;
• ydeevnen er acceptabel;
• koden er vedligeholdelsesvenlig;
• modellen tester den faktiske spiladfærd.

Undgå kun at bedømme et skærmbillede. En flot scene med ødelagte kontroller er en mislykket spilopgave.

Test 6: workflow fra research til kode

Opgave

Giv en kort artikel eller teknisk specifikation, og bed modellen om at implementere én algoritme, reproducere et offentliggjort eksempel, generere et diagram og forklare uoverensstemmelser.

Scoring

• troskab over for kilden;
• gengivelse af formler;
• numerisk korrekthed;
• testdækning;
• diagrammets nøjagtighed;
• ubegrundede videnskabelige konklusioner;
• proveniens for eksterne data.

Den kombinerer K3's påstande om vidensarbejde og kodning.

Test 7: genopretning efter værktøjsfejl

Indfør kontrollerede fejl:

• ét værktøj returnerer ugyldig JSON;
• én kommando løber ud i en timeout;
• én fil mangler;
• én test er ustabil;
• én ønsket handling ligger uden for tilladelsens omfang.

Den rette adfærd er ikke »fortsæt altid«. Modellen bør forsøge igen, når det er sikkert, vælge et alternativ, når det er begrundet, og stoppe for at få autorisation, når næste handling ville overskride omfanget.

Registrér, om den:

• opdager fejlen;
• bevarer gyldig tidligere tilstand;
• forsøger igen med en afgrænset strategi;
• opdigter et vellykket resultat;
• beder om autorisation ved den rette grænse;
• ender med en ærlig status.

Test 8: bevarelse af tilstand i en lang session

K3's dokumentation gør dette til en påkrævet evaluering.

Kør to kontrollerede betingelser:

1. en korrekt klient, der returnerer fulde assistentbeskeder;
2. en bevidst ufuldstændig klient, der kun beholder det endelige indhold.

Brug ikke den anden betingelse i produktion. Den findes for at kvantificere den integrationsfejl, Moonshot beskriver. Sammenlign kontinuitet i værktøjsbrug, faktuel konsistens og gennemførelse af opgaven.

Test også, om det ændrer stabiliteten at skifte fra en anden model midt i en session.

Mål omkostning pr. verificeret succes

Registrér for hver kørsel:

• input-tokens med cache-hit;
• input-tokens med cache-miss;
• output-tokens;
• tid på uret;
• værktøjskald;
• genforsøg;
• minutter til manuel rettelse;
• bestået, fejlet eller alvorligt fejlet.

Beregn derefter:

verified-success cost =
  total API spend across all attempts / verified successes

En model med en højere tokenpris kan være billigere, hvis den lykkes i færre forsøg. En stor cacherabat kan også gøre gentaget repositoryarbejde meget billigere efter første runde.

Brug prisguiden for Kimi K3 API til officielle takster og eksempler.

Sammenlign Kimi K3 og GPT-5.6 Sol retfærdigt

Brug samme opgavetekst, repositorytilstand, værktøjstilladelser, tidsgrænse og verifikation. Modelspecifikke krav til klienten kan afvige, men ingen af modellerne bør få skjulte fordele.

Rapportér:

• resultater på tværs af mindst tre kørsler;
• median og værste udfald;
• alvorlige fejl;
• omkostning pr. verificeret bestået opgave;
• forløbet tid;
• den præcise harness;
• eventuelle fallbacks eller udbyderfejl.

Tilpas ikke gentagne gange prompten til den ene model, mens den anden bliver ved sit første forsøg. Hvis modelspecifik prompting er tilladt, skal du oplyse budgettet for tilpasningen.

Skabelon til resultattabel

Offentliggør de rå beviser ved siden af tabellen: commits, testlogs, skærmbilleder, tokenrapporter og prompts.

Almindelige fejl ved evaluering

• Kun at teste én kørsel.
• At bruge forskellige tidsgrænser.
• At skjule mislykkede forsøg.
• At vægte visuel finish højere end korrekthed.
• At lade den ene model bruge en stærkere harness.
• At ignorere eksisterende ændringer i et beskidt worktree.
• At give agenter ubegrænsede destruktive værktøjer.
• At sammenligne omkostning ved cache-hit med omkostning ved cache-miss.
• At erklære en kodningssejr alene på baggrund af selvrapporterede benchmarks fra lanceringen.
• At offentliggøre konklusioner genereret af modellen uden manuel verifikation.

Hvad ville være et stærkt resultat for Kimi K3?

Et stærkt resultat er ikke blot at gennemføre alle opgaver. Det er at gennemføre korrekte opgaver med afgrænsede værktøjer, bevare brugerens ændringer, rapportere fejl ærligt og bruge lang kontekst uden unødvendige omkostninger.

K3's særkender bør vise sig i langt repositoryarbejde, visuel iteration og vedvarende genopretning. Hvis en mindre model matcher den på simple opgaver, bør du route de opgaver til den mindre model.

Ofte stillede spørgsmål

Er Kimi K3 god til kodning?

Officielle og tidlige uafhængige beviser peger på stærk kodnings- og agentkapacitet, især på lange opgaver. Kør en reproducerbar evaluering på dine egne repositories, før du router produktionstrafik.

Hvor mange gange bør hver kodningstest køres?

Tre kørsler er et praktisk minimum til en indledende sammenligning. Beslutninger med stor betydning kræver flere stikprøver og konfidensintervaller.

Bør Kimi K3 få hele repositoryet?

Ikke automatisk. Test både målrettet retrieval og stor kontekst. Mere kontekst kan forbedre ræsonnering om fjerne afhængigheder, men tilfører også støj, svartid og omkostninger.

Hvad er den vigtigste detalje i K3-integrationen?

Bevar fulde assistentbeskeder i workflows med flere runder og værktøjer. Hvis du dropper påkrævet tænkehistorik, kan det gøre ydeevnen ustabil.

Kan denne test bevise, at én model er universelt bedre?

Nej. Den kan vise, hvilken model der fungerer bedst til de valgte opgaver, den valgte harness, de valgte indstillinger og datoen.

Kilder

• Moonshot AI: kodningscases og benchmarknoter for Kimi K3
• Krav til tilstand og værktøjer i Kimi K3 API
• Benchmarkanalyse af Kimi K3
• Kimi K3 vs GPT-5.6 Sol