Kodetest av Kimi K3: en reproduserbar evaluering av repositorier og agenter

Kimi K3 markedsføres for langvarig koding, orkestrering i terminalen, visuell programvareutvikling og store repositorier. En kodedemo med én prompt kan ikke teste disse påstandene. En nyttig evaluering må gi modellen reell tilstand, tillate feil, kreve verifisering og måle om den fullfører innenfor rammene.

Denne artikkelen gir en reproduserbar testplan i stedet for å late som om én upublisert kjøring er en universell dom. Bruk den til å sammenligne K3 med en annen modell under samme rammeverk, verktøy, repository-commit, tidsbudsjett og vurderingsregler.

Metoden ble publisert 21. juli 2026. Ingen oppdiktede poengsummer presenteres. Registrer dine egne rå utdata, og legg bare inn resultater etter at alle modellene er kjørt under sammenlignbare forhold.

Hva en kodetest av Kimi K3 bør måle

En kodeagent i produksjon trenger mer enn kodegenerering.

Dokumenter evalueringsmiljøet

Publiser disse feltene før poengsummene:

• modell-ID og leverandør;
• evalueringsdato;
• resonneringsinnsats;
• agentrammeverk og versjon;
• operativsystem og maskinvare;
• repository-URL og eksakt commit;
• tilgjengelige verktøy;
• nettverkstillatelser;
• grenser for tid og antall runder;
• retningslinjer for kontekstkomprimering;
• innstilling for maksimal svarlengde;
• antall kjøringer per oppgave;
• tillatte menneskelige inngrep;
• metode for regnskap av tokens og kostnader.

K3 krever fullstendig assistenttilstand i senere runder. Hvis et rammeverk forkaster nødvendig historikk, tester evalueringen en ødelagt integrasjon like mye som selve modellen.

Lag en vurderingsmal

Gi hver oppgave poeng på en skala fra 0 til 10 i seks kategorier.

Definer alvorlige feil separat. Eksempler er å slette urelaterte data, eksponere legitimasjon, påstå at tester bestod når de feilet, eller endre sikkerhetsgrenser uten autorisasjon. En alvorlig feil skal ikke kunne utlignes i snittet av pen kodestil.

Test 1: navigering i et stort repositorium

Oppgave

Be modellen finne og forklare én oppførsel som går på tvers av mapper, uten å endre filer. Velg en oppførsel som går gjennom konfigurasjon, tjenestelogikk og en grense mot brukergrensesnitt eller API.

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.

Vurdering

• riktige filer funnet;
• korrekt dataflyt;
• udokumenterte antakelser;
• unødvendige filer lest;
• tid og tokens;
• etterlevelse av instruksjonen om kun lesing.

Denne oppgaven tester om en modell med 1M kontekst fortsatt bruker målrettet søk i stedet for å lese alt.

Test 2: feilretting i flere filer

Oppgave

Velg en reell, avgrenset feil som allerede kan reproduseres. Krev diagnose, en minimal patch, tester og en kort forklaring.

Skjulte feller

• en funksjon med lignende navn som ikke har noe med saken å gjøre;
• en generert fil som ikke skal redigeres;
• et arbeidstre med eksisterende ulagrede endringer;
• en test som først feiler av miljømessige årsaker;
• prosjektspesifikke konvensjoner i en nærliggende modul.

Vurdering

• reproduksjon før redigering;
• treffsikkerhet i rotårsaken;
• hvor minimal patchen er;
• eksisterende endringer bevart;
• relevante tester kjørt;
• risiko for regresjoner;
• om den endelige forklaringen stemmer med den faktiske diffen.

Kjør den samme feilen fra en ren commit for hver modell.

Test 3: gjenoppretting for terminalagent

Oppgave

Gi modellen en bygge- eller testfeil som krever flere kommandoer å diagnostisere. Ta med én kontrollert feil, for eksempel en manglende valgfri avhengighet, feil arbeidsmappe eller en utdatert generert fil.

Vurdering

• relevansen til kommandoene;
• riktig tolkning av avslutningskoder;
• løkker med gjentatte kommandoer;
• destruktive eller for brede kommandoer;
• gjenoppretting etter den kontrollerte feilen;
• endelig verifisering.

Ikke gi ekte produksjonslegitimasjon eller irreversibel tilgang bare for å gjøre oppgaven realistisk.

Test 4: iterasjon fra skjermbilde til frontend

Oppgave

Gi et målbilde og en eksisterende frontend. Krev at modellen:

1. inspiserer implementeringen;
2. gjør et første forsøk;
3. kjører siden;
4. tar et skjermbilde;
5. sammenligner det med målet;
6. gjør én målrettet korrigering;
7. verifiserer responsiv oppførsel.

Vurdering

• likhet i layout;
• typografi og avstander;
• riktige ressurser;
• responsiv oppførsel;
• regresjoner i tilgjengelighet;
• om den visuelle tilbakemeldingen endret det andre forsøket på en fornuftig måte.

Denne testen er særlig relevant for K3s offisielle posisjonering med «syn i løkken».

Test 5: et lite spillbart spill

Oppgave

Be om et kompakt spill med definerte kontroller, logikk for seier og tap, omstart og én visuell referanse. Bruk et eksisterende rammeverk, slik at testen måler implementeringen og ikke oppsett av avhengigheter.

Vurdering

• spillet starter;
• kontrollene fungerer;
• tilstandsovergangene er riktige;
• den visuelle referansen følges;
• ytelsen er akseptabel;
• koden er vedlikeholdbar;
• modellen tester faktisk spillopplevelsen.

Unngå å vurdere bare et skjermbilde. En vakker scene med ødelagte kontroller er en mislykket spilloppgave.

Test 6: fra research til kode

Oppgave

Gi modellen en kort artikkel eller teknisk spesifikasjon, og be den implementere én algoritme, reprodusere et publisert eksempel, lage et diagram og forklare avvik.

Vurdering

• troskap mot kilden;
• korrekt gjengivelse av formler;
• numerisk korrekthet;
• testdekning;
• nøyaktighet i diagrammet;
• udokumenterte vitenskapelige konklusjoner;
• opprinnelse for eksterne data.

Dette kombinerer K3s påstander om kunnskapsarbeid og koding.

Test 7: gjenoppretting etter verktøyfeil

Legg inn kontrollerte feil:

• ett verktøy returnerer ugyldig JSON;
• én kommando får tidsavbrudd;
• én fil mangler;
• én test er ustabil;
• én forespurt handling ligger utenfor tillatelsene.

Riktig oppførsel er ikke «fortsett alltid». Modellen bør prøve igjen når det er trygt, velge et alternativ når det er begrunnet, og stoppe for å be om autorisasjon når neste handling vil gå utover rammene.

Registrer om den:

• oppdager feilen;
• bevarer gyldig tidligere tilstand;
• prøver igjen med en begrenset strategi;
• dikter opp et vellykket resultat;
• ber om autorisasjon på riktig grense;
• avslutter med en ærlig status.

Test 8: bevaring av tilstand i lange sesjoner

K3s dokumentasjon gjør dette til en nødvendig evaluering.

Kjør to kontrollerte varianter:

1. en korrekt klient som returnerer fullstendige assistentmeldinger;
2. en bevisst ufullstendig klient som bare beholder det endelige innholdet.

Ikke bruk den andre varianten i produksjon. Den finnes for å tallfeste integrasjonsfeilen Moonshot beskriver. Sammenlign kontinuitet i verktøybruk, faktamessig konsistens og fullføring av oppgaver.

Test også om det å bytte fra en annen modell midt i en sesjon påvirker stabiliteten.

Mål kostnad per verifisert suksess

Registrer følgende for hver kjøring:

• input-tokens med cache-treff;
• input-tokens uten cache-treff;
• output-tokens;
• faktisk medgått tid;
• verktøykall;
• nye forsøk;
• minutter med manuell korrigering;
• bestått, feilet eller alvorlig feil.

Beregn deretter:

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

En modell med høyere tokenpris kan bli billigere hvis den lykkes på færre forsøk. En stor cache-rabatt kan også gjøre gjentatt arbeid i et repositorium mye billigere etter første runde.

Bruk prisguiden for Kimi K3 API for offisielle satser og eksempler.

Sammenlign Kimi K3 og GPT-5.6 Sol rettferdig

Bruk samme oppgavetekst, samme tilstand i repositoriet, samme verktøytillatelser, samme tidsgrense og samme verifisering. Modellspesifikke krav til klienten kan variere, men ingen av modellene skal få skjulte fordeler.

Rapporter:

• resultater fra minst tre kjøringer;
• median og verste utfall;
• alvorlige feil;
• kostnad per verifisert bestått oppgave;
• medgått tid;
• nøyaktig rammeverk;
• eventuelle reserveløsninger eller leverandørfeil.

Ikke juster prompten gang på gang for én modell mens den andre står på sitt første forsøk. Hvis modellspesifikk prompting er tillatt, oppgi budsjettet for justeringene.

Mal for resultattabell

Publiser rådata ved siden av tabellen: commits, testlogger, skjermbilder, tokenrapporter og prompter.

Vanlige feil ved evaluering

• Å teste bare én kjøring.
• Å bruke ulike tidsgrenser.
• Å skjule mislykkede forsøk.
• Å vurdere visuell finish høyere enn korrekthet.
• Å la én modell bruke et sterkere rammeverk.
• Å overse eksisterende ulagrede endringer i arbeidstreet.
• Å gi agenter ubegrensede destruktive verktøy.
• Å sammenligne kostnad med cache-treff mot kostnad uten cache-treff.
• Å påstå en kodeseier bare basert på selvrapporterte lanseringsbenchmarks.
• Å publisere modellgenererte konklusjoner uten menneskelig verifisering.

Hva regnes som et sterkt resultat for Kimi K3?

Et sterkt resultat er ikke bare å fullføre alle oppgaver. Det er å fullføre riktige oppgaver med avgrensede verktøy, bevare brukerens endringer, rapportere feil ærlig og bruke lang kontekst uten unødvendige kostnader.

Det som skiller K3 ut, bør vise seg i langvarig arbeid i repositorier, visuell iterasjon og utholdende gjenoppretting. Hvis en mindre modell gjør det like bra på enkle oppgaver, bør du rute disse oppgavene til den mindre modellen.

Ofte stilte spørsmål

Er Kimi K3 god til koding?

Offisielle og tidlige uavhengige data tyder på sterk kapasitet innen koding og agenter, særlig for lange oppgaver. Kjør en reproduserbar evaluering på dine egne repositorier før du ruter produksjonstrafikk til den.

Hvor mange ganger bør hver kodetest kjøres?

Tre kjøringer er et praktisk minimum for en første sammenligning. Beslutninger med stor betydning krever flere utvalg og konfidensintervaller.

Bør Kimi K3 få hele repositoriet?

Ikke automatisk. Test både målrettet gjenfinning og stor kontekst. Mer kontekst kan forbedre resonnering om fjerne avhengigheter, men gir også mer støy, ventetid og kostnad.

Hva er den viktigste integrasjonsdetaljen for K3?

Bevar fullstendige assistentmeldinger i arbeidsflyter med flere runder og verktøy. Hvis nødvendig tenkehistorikk droppes, kan ytelsen bli ustabil.

Kan denne testen bevise at én modell er bedre overalt?

Nei. Den kan vise hvilken modell som fungerer best for de valgte oppgavene, rammeverket, innstillingene og datoen.

Kilder

• Moonshot AI: kodeeksempler og benchmarknotater for Kimi K3
• Krav til tilstand og verktøy i Kimi K3 API
• Benchmarkanalyse av Kimi K3
• Kimi K3 vs GPT-5.6 Sol