Artikkelkatalog
En venn spurte meg her om dagen hvordan man kan forbedre effektiviteten når man bruker Codex.
我说你想做的东西，GitHub 上大概率已经有人做过了，而且不少方案已经很成熟。能直接参考、修改，为什么还要从头写一遍？
Jeg ba deg om å kopiere følgende ledetekst og kjøre den før du starter hvert prosjekt.
他试了一下，回来跟我说，确实省了好多时间。
Jeg har tenkt på det, og det virker som om ganske mange ikke er klar over denne funksjonen. Det er som om mange bruker AI til å skrive kode, og starter med Vibe Coding, der AI-en kan generere nettsteder og skrive apper.
Det er egentlig ingen grunn til å forhaste seg.
Det du vil gjøre, har sannsynligvis noen på GitHub allerede gjort.
Det du vil gjøre er mest sannsynlig allerede gjort på GitHub. Mange løsninger er allerede modne, og kodekvaliteten kan til og med være høyere enn det du kan skrive selv. Hvorfor skrive det om fra bunnen av når du kan referere direkte til og endre eksisterende arbeid?
Min personlige vane er at når jeg vil starte et nytt prosjekt, skriver jeg ikke kode med en gang. Først sender jeg dette forslaget til Codex:
我要做一个XXX。先不要写代码。去GitHub找能直接使用或二次开发的开源项目，确认是否还在维护、部署是否麻烦、哪些功能可以复用。最后告诉我，应该直接用、基于现有项目改，还是自己开发，并给出最简单的MVP方案。等我确认后再动手。
Bare denne ene setningen.
Denne oppfordringen gjorde tre ting.
Tenk på det, denne ledeteksten gjør tre ting.
For det første lar det AI finne eksisterende løsninger på GitHub i stedet for å begynne å skrive sine egne. Mange vet kanskje ikke at Codex, når det integreres med GitHub-pluginen, faktisk kan søke etter åpen kildekode-prosjekter i sanntid; det er ikke bare en funksjon.
For det andre bruker den AI for å hjelpe deg med å evaluere kvaliteten på disse prosjektene: om de fortsatt vedlikeholdes, hvor komplisert utrullingen er, og hvilke funksjoner som kan brukes direkte. Hvis du skulle søke manuelt gjennom hvert prosjekt på GitHub, kan det ta en time eller to. La AI-en kjøre det, så får du resultater i løpet av minutter.
For det tredje lar den AI gi deg et klart beslutningsforslag: om du skal bruke den direkte, endre den eller skrive den fra bunnen av, og den hjelper deg også med å planlegge den enkleste MVP-løsningen.
Hvorfor kan vi spare mange tokens?
La meg fortelle deg, denne operasjonen kan virkelig spare deg for mange tokens.
Hvorfor? Fordi hvis du lar AI begynne å skrive kode direkte, vil den ikke vite at det du ønsker allerede finnes. Den vil generere en enorm mengde kode for deg fra bunnen av. Denne koden kan overlappe med funksjonaliteten til eksisterende åpen kildekode-prosjekter, og du må til slutt rydde opp selv.
Men hvis du lar AI hjelpe deg med å finne svaret først, vil forslagene være basert på det eksisterende økosystemet, og når du skriver koden, kan mengden kode reduseres med minst halvparten.
Det er det jeg gjør selv. Hver gang jeg starter et nytt prosjekt, kjører jeg først dette forslagsprogrammet, og deretter bestemmer jeg meg for neste trinn basert på AI-ens forslag. Det forbedrer effektiviteten virkelig.
For å være ærlig, er jeg ikke sikker på om denne metoden vil fungere for alle; noen prosjekter kan faktisk mangle lett tilgjengelige løsninger. Men tenk på det: for de fleste tingene du vil gjøre, med hundrevis av millioner repositorier på GitHub, er det en veldig høy sannsynlighet for at noen allerede har gjort det.
Stående på skuldrene til kjemper
Du er ikke programmerer, så du trenger ikke å skrive kode fra bunnen av. Du er ikke innholdsskaper, så du trenger ikke å lage originalt innhold hver dag. Du er bare en som vil gjøre noe meningsfullt, og den smarteste tilnærmingen er å først se hva andre allerede har gjort, og deretter stå på skuldrene til giganter.
Noen ganger føler jeg at den smarteste måten å bruke AI på i AI-æraen ikke er å la AI gjøre alt for deg, men å la AI gjøre informasjonsinnhenting og beslutningsanalyse for deg, og så kan du utføre det.
Hva er forskjellen på dette og å bruke en søkemotor før? Tidligere, når du søkte etter et spesifikt krav, dukket det opp en rekke lenker, og du måtte klikke deg gjennom dem én etter én for å se hvilke som fungerte og hvilke som ikke gjorde det. Nå forteller du AI-en dine krav, og den filtrerer dem for deg og gir deg konklusjonen direkte.
Kan du tro det?
Denne ledeteksten skal graveres.DNAi
Jeg personlig mener at denne oppfordringen bør være en del av DNA-et vårt . Å gjennomgå den før man starter et nytt prosjekt sparer virkelig mye tid.
En annen fordel med denne tilnærmingen er at du unngår å oppfinne hjulet på nytt. AI hjelper deg med å finne lett tilgjengelige løsninger, slik at du kan fokusere på de virkelig tilpassede aspektene. På denne måten kan energien din vies til de mest verdifulle områdene.
Min egen erfaring er at da jeg først begynte å bruke AI til å skrive kode, var jeg veldig begeistret og ville at AI-en skulle generere alt fra bunnen av. Men etter å ha brukt det en stund, fant jeg ut at det ofte var tregere å gjøre det. Dette er fordi du må feilsøke, endre og vedlikeholde koden generert av AI, mens eksisterende åpen kildekode-prosjekter har blitt verifisert av mange, slik at kvaliteten deres er mer garantert.
Dette høres kanskje kontraintuitivt ut, ikke sant? Men tenk over det: det viktigste med kode er ikke å skrive den, men å skrive den riktig. Eksisterende løsninger har allerede blitt validert; å bruke dem direkte vil redusere sjansene for å støte på problemer betydelig.
Så mitt råd er at neste gang du skriver kode med Codex eller annen AI, ikke forhast deg. Kjør først ledeteksten én gang, og la AI-en hjelpe deg med å finne svaret.
Du kan oppdage at det du prøver å gjøre allerede har blitt gjort av noen andre.
Du trenger bare å ta den og bruke den.
Bruk tiden du sparer til å gjøre noe mer interessant.
Siden du har lest så langt, så lik og del gjerne hvis du syntes det var nyttig. Hvis du vil motta oppdateringer først, kan du også følge meg!
Takk for at du leste artikkelen min. Vi sees neste gang.
Forhåpentligvis vil artikkelen «Vibe Coding Efficiency Doubling Techniques: A Must-Read Before Writing Code! Use AI to Find the Optimal Solution First», som er delt på Chen Weiliangs blogg ( https://www.chenweiliang.com/ ), være nyttig for deg.
Del gjerne lenken til denne artikkelen: https://www.chenweiliang.com/cwl-34473.html