Vinster:
- Förmåga att använda artificiell intelligens för att producera ramverk, tester och granska utkast baserat på beprövade bibliotek (t.ex. OpenZeppelin) och förstå att människor garanterar produktionssäkerhet
- Möjlighet att verifiera kodversion, mönster och åtkomstkontroll som produceras av artificiell intelligens genom kompilering, testning och testnät
- Att kunna urskilja den kompileringen betyder inte att vara säker och att testnät och revision är väsentligt.
Att skriva ett smart kontrakt skiljer sig från vanlig programvara: koden du skriver är offentlig, oföränderlig och ett program som direkt flyttar pengar. I den här enheten får du lära dig hur du använder AI som en smart kontraktsutvecklingsassistent; Vi kommer att lära oss från utkastproduktion till testskrivning, från återkallande av mönster till optimering av gas (transaktionsavgift). Men låt oss vara tydliga från början: AI producerar ritningar; Människor säkerställer säker kod som går i produktion.
Mark först: språk och miljö
Det vanligaste smarta kontraktsspråket är Solidity (språket för Ethereum och EVM — Ethereum Virtual Machine, den virtuella maskinen som kontrakt körs på — kompatibla kedjor). Alternativet är Vyper (ett Python-liknande språk som syftar till att vara mer begränsat och läsbart). Din kod förbrukar gas (kostnaden för varje transaktion till blockkedjan); Ineffektiv kod är dyr. Att hålla dessa termer tydliga i sammanhanget du ger dem till AI är nyckeln till att få korrekt utdata.
Där AI är mest värdefullt är inte att "skriva från grunden" utan att skapa ramverket + bra form: en standardkompatibel start, en plan för att lägga till din expertis.
Lager för att använda AI i kodning
1. Generera skelett. AI bryter snabbt skelettet av en standardtoken (ERC-20) eller NFT (ERC-721 — en unik standard för digital tillgång). Men se till att få AI att använda ett beprövat bibliotek: till exempel OpenZeppelin (gemenskapens betrodda, granskade standardbibliotek för kontrakterande). Regeln är att använda det testade blocket istället för att skriva säkerhet från början.
2. Funktionsbeskrivning och granskning. Genom att förklara en befintlig funktion för AI kan du upptäcka logiska fel tidigt.
3. Testgenerering. AI är bra på att generera testfall för edge-fall: noll input, mycket stort antal, obehörig uppringare, upprepade samtal. Detta påminner ett om de scenarier man hoppar över.
4. Gas och läsbarhet. AI flaggar dyra mönster som onödiga lagringsskrivningar och föreslår alternativ.
Tips: Instruera AI:en att "Bygga på OpenZeppelins granskade kontrakt, skriva om säkerheten från grunden." Det är mycket mer riskabelt för en AI att skriva original säkerhetskod än att använda ett testat bibliotek.
Svag prompt / Stark prompt
Svag uppmaning:
Skriv ett symboliskt kontrakt till mig.
Den här uppmaningen är farlig: det är inte klart vilken standard, vilken kedja, vilket bibliotek, vilket säkerhetskrav. AI:n genererar slumpmässig, möjligen föråldrad eller osäker kod.
Kraftfull uppmaning:
Din roll: senior Solidity-utvecklare. Generera ett ERC-20-tokenutkast för en EVM-kompatibel kedja. Regler:- Baserat på OpenZeppelins granskade ERC20 och Ownable-kontrakt.- Skriv Solidity-versionen och licensraden (SPDX) uttryckligen.- Endast ägaren har tillstånd att prägla; lägg till ett lock mot oändlig pressning. - Lägg till NatSpec-kommentar till varje funktion. - Skriv säkerhet från grunden; Använd standardblocket. - Lägg till en varning i slutet: "Detta är ett utkast; revision och testning krävs". Markera de områden du inte är säker på med // TODO.
Skillnad: stark prompt ger tydlig roll, standard, bibliotek, säkerhetsgräns, dokumentation och valideringsförväntningar.
Fyra kopierbara mallar
1) Standardbaserat skelett:
Din roll: Soliditetsutvecklare. Generera [ERC-20 / ERC-721 / staking]kontraktsramverk baserat på OpenZeppelin granskade bibliotek. Skriv SPDX-licens och pragmaversion. Lägg till åtkomstkontroll (vem kan ringa) till varje extern funktion. Återuppfinna säkerheten; Använd standardblock. Det här är ett utkast.
2) Funktionsgranskning:
Undersök följande funktion som en senior utvecklare: vad gör den, vilka tillstånd ändrar den, vem kan kalla den? Markera möjliga logiska fel och säkerhetsrisker som HYPOTES, länka var och en till en rad i koden. Säg inte "säkert" direkt; lista bara uppmärksamhetspunkterna.
3) Testscenario utkast:
Föreslå testfall för detta kontrakt (kan vara ett utkast för Foundry/Hardhat). Täck specifikt gränsfall: noll input, mycket stort antal, obehörigt samtal, återkommande samtal, otillräckliga medel. Skriv VAD varje test bekräftar.
4) Granskning av gas och läsbarhet:
Markera i detta kontrakt de mönster som kan minska gaskostnaden: onödig lagringsskrivning, externt samtal i slingan, upprepad beräkning. Förklara skillnaden före/efter i varje förslag. Rekommendera säkerhetsbrytande optimeringar; Om det inte är tydligt, säg "fråga revisorn".
Tre minifodral (i antal)
Fall 1 — Skelett sparat 4 timmar. Ett team bröt skelettet av ett granskat biblioteksbaserat intjänandekontrakt med AI på 30 minuter; Det tog ~4 timmar manuellt. Teamet ägnade tid åt säkerhet och testning. Vinsten kom inte från att överföra säkerhet, utan från att påskynda det tråkiga ramverket.
Fall 2 — Föråldrad version fälla. AI producerade ett mönster som skickar rå Ether genom överföring, vilket inte längre rekommenderas eftersom träningsdatan är föråldrad. Utvecklaren märkte detta och ändrade det till det nuvarande samtalsbaserade och återinträdesskyddade mönstret. Lektion: AI:s bibliotek/mönster bekräftas alltid vara uppdaterade; AI vet inte efter träningens slutdatum.
Fall 3 – Testutkast dök dold bugg. Testet "obehörig uppringare" som AI producerade avslöjade att utvecklaren hade glömt åtkomstkontrollen i en funktion. endast ägare saknar 1 rad, fångad på 5 minuter på testnät; Det kan ha blivit en förlust av pengar på huvudnätet. Lektion: AI täcker människans blinda fläck i tester.
Kom ihåg säkerhetsmönster med AI
AI är bra på att påminna dig om kända sårbarhetsmönster som en checklista. De vanligaste mönstren:
- Återinträde: Ringa ett externt samtal utan att uppdatera status. Lösning: checks-effects-interactions order, reentrancy guard.
- Brist på passerkontroll: Vem som helst kan ringa den kritiska funktionen.
- Heltalsspill/underfall: Modern Solidity fångar de flesta av dem, men fortfarande en risk i lågnivåkod.
- Otillräcklig ingångsvalidering: Nolladress, nollkvantitetskontroll.
- Oracle-beroende: Blind tillit till extern data (som pris).
Observera: AI kan återkalla den här listan, men den kan inte garantera om ett objekt i listan finns i din specifika kod. Checklistan är en början; Det är inte en ersättning för containerkontroll.
Att få rätt sammanhang: Hemligheten bakom bra kod från AI
Kvaliteten på koden som AI producerar beror direkt på kvaliteten på sammanhanget du ger den. I Web3 är detta särskilt viktigt eftersom en liten detalj (vilken kedja, vilken Solidity-version, vilken token-standard) ändrar hela utgången. Ett bra sammanhang inkluderar:
- Målkedja och miljö: Ethereum mainnet eller ett Layer 2 (billigare sidokedja som löper ovanpå huvudkedjan)? Gaskostnad och vissa funktioner varierar beroende på kedja.
- Version och bibliotek: Vilken Solidity-version, vilken OpenZeppelin-version? Om ingen version anges kan AI producera föråldrade, föråldrade mönster.
- Säkerhetskrav: Finns det ett tak, kan det pausas, kan det höjas? Dessa bör sägas från allra första början.
- Begränsningar: Tydliga gränser som "använd inte montering", "undvik externt samtal", "optimera gas men bibehåll läsbarheten".
En annan kraftfull teknik är att fråga AI om planen först, sedan koden: "Först lista funktionerna i detta kontrakt och vad var och en kommer att göra; skriv koden när jag godkänner den." Detta fångar AI på att gå i fel riktning tidigt och låter dig behålla det arkitektoniska beslutet.
Tips: Fråga AI:en "varför skrev du den här koden så här?" be. Att förklara logiken kommer både att påskynda din inlärning och ta upp eventuella logiska fel (t.ex. ett falskt säkerhetsantagande). Lita inte på resultatet från en AI som inte kan försvara sin egen kod.
Vanliga misstag
- Sätter säkerhet i AI från grunden. Använd ett testat bibliotek.
- Bekräftar inte versionen/mönstret som produceras av AI. Träningsdata kan vara gamla.
- Förbigå testnät. Varje utkast bör köras på testnätverket innan det går live.
- Lägger inte till NatSpec/dokumentation. Inspektion och underhåll blir svårt.
- "Det är sammanställt, så det är säkert" missuppfattning. Att vara sammanställd betyder inte att vara säker.
- Glömde åtkomstkontroll. Det är ett av de vanligaste och dyraste misstagen.
Sammanfattningsvis
- I smart kontraktsskrivning producerar AI ramverk, tester och granskningsutkast; Människan garanterar produktionssäkerhet.
- Bygg säkerhet inte från grunden utan baserat på beprövade bibliotek (t.ex. OpenZeppelin).
- Uppdateringen av de versioner och mönster som produceras av YZ bekräftas alltid.
- Teststubbar är värdefulla för att fånga mänskliga blinda fläckar (limitfall, åtkomstkontroll).
- Att vara sammanställd betyder inte att vara säker; testnet och revision är ett måste.
Applikationsuppgift
För en enkel ERC-20-token, generera ett utkast med hjälp av "standards-based skeleton"-prompten ovan. Sedan: (1) kontrollera om det använder ett kontrollerat bibliotek, (2) kontrollera åtkomstkontrollerna, (3) generera tester med prompten "testfallsutkast" och faktiskt köra minst ett skurksamtalstest. Hitta och notera minst en säkerhetspunkt som AI:n missade.
checklista
- [ ] Jag har tydligt angett standarden och kedjan i prompten.
- [ ] Jag ville ha beprövad biblioteksbaserad produktion.
- [ ] SPDX-licens och pragmaversion tillgänglig.
- [ ] Det finns åtkomstkontroll i varje kritisk funktion.
- [ ] Jag skapade och körde tester för limitfall.
- [ ] Jag bekräftade att biblioteket/mönstret är uppdaterat.
- [ ] Jag markerade koden för revision och testning; Jag fick det inte utan tillsyn på mainnet.