Njësia 8 / 11

Dokumentacioni dhe shkrimi teknik: Whitepaper, NatSpec dhe Udhëzuesi i Përdoruesit

Fitimet:

  • Të jesh në gjendje të përdorësh në mënyrë të sigurt inteligjencën artificiale në prodhimin e letrës së bardhë, NatSpec, përkthimit teknik-të thjeshtë dhe zbulimit të rrezikut dhe të kuptuarit se kjo është fusha më produktive.
  • Aftësia për të verifikuar çdo pretendim teknik me kodin aktual dhe për të hequr ekzagjerimet dhe gjuhën e garancisë për të shmangur rrezikun e dokumentacionit të pasaktë
  • Aftësia për të përqafuar rreziqet me ndershmëri, paralajmërimet 'jo këshilla financiare' dhe konsistenca e kodit të dokumentacionit

Dokumentacioni në Web3 nuk është një luks, por një çështje sigurie dhe besimi. Duke ndërvepruar me një kontratë inteligjente, përdoruesi rrezikon paratë e tij reale; Nëse ai nuk e kupton atë që po bën, ai është i hapur për t'u mashtruar. Auditori nuk mund të rishikojë në mënyrë të sigurt kodin që nuk është i dokumentuar mirë. Në këtë njësi, ne mbulojmë fushën ku AI është më i besueshëm dhe efikas: dokumentacioni dhe shkrimi teknik. Nga letra e bardhë te komentet në kod, nga udhëzuesi i përdoruesit te zbulimi i rrezikut, AI është një shumëzues i vërtetë i forcës këtu - për sa kohë që saktësia monitorohet në mënyrë njerëzore.

Llojet e dokumentacionit Web3

  • Whitepaper / Litepaper: Dokumenti bazë që përshkruan vizionin, mekanizmin dhe tokenomikën e projektit.
  • Dokumentacioni teknik: Ndërfaqet e kontratës, udhëzues integrimi për zhvilluesit.
  • NatSpec (Specifikimi i Gjuhës Natyrore Ethereum - Formati standard i komenteve në kod në Solidity që përshkruan se çfarë bëjnë funksionet): Dokumentacioni i ngulitur në kod, i lexuar nga njeriu dhe mjeti.
  • Udhëzues përdorimi: Tekst i thjeshtë që i tregon përdoruesit përfundimtar "si të përdoret, çfarë rreziqesh ka".
  • Mohim përgjegjësie: Paralajmërime të kërkuara ligjërisht dhe etikisht.

Një problem i zakonshëm me këto lloje: zhvilluesve nuk u pëlqen të shkruajnë dhe shpesh e lënë atë në momentin e fundit. AI plotëson pikërisht këtë boshllëk.

Pse dokumentacioni është zona më e sigurt e AI

Kostoja e gabimit në dokumentacion është më e ulët se në auditim: korrigjohet një fjali e pasaktë, nuk fluturojnë para (drejtpërsëdrejti). Për më tepër, AI është natyrshëm i fortë në prodhimin e gjuhës. Pra, AI është efikas dhe relativisht i sigurt këtu. Por mbeten dy rreziqe kritike:

  1. Pretendim i rremë teknik: AI mund të keqinterpretojë atë që bën kodi; Kjo mashtron përdoruesin dhe mund të bëhet një dobësi sigurie (përveç nëse thotë "ky funksion mbron fondet tuaja" dhe jo).
  2. Hiperbola/gjuha e marketingut: AI mund të prodhojë gjuhë që e bën një projekt të duket i sigurt ose fitimprurës; Ky është edhe problem etik edhe ligjor.
Kujdes: Dokumentacioni përshkruan kodin; Nuk është vetë kodi. Çdo pohim teknik që shkruan AI ("kjo ndodh", "që ruan") duhet të verifikohet kundrejt kodit aktual. Dokumentacioni i pasaktë mund të jetë më i rrezikshëm se kodi i saktë sepse përdoruesi i beson dokumentacionit.

Shtresat e përdorimit të AI në dokumentacion

1. Gjenerimi NatSpec. AI lexon një funksion ekzistues dhe harton interpretimin NatSpec: çfarë bën, cilat janë parametrat e tij, çfarë kthen. Kjo thjeshton inspektimin dhe mirëmbajtjen.

2. Përkthim tekniko-thjeshtë. AI përkthen një mekanizëm kompleks në gjuhë që përdoruesi përfundimtar mund ta kuptojë - një nga nevojat më të mëdha të Web3.

3. Skica dhe struktura e letrës së bardhë. AI prodhon skeletin dhe seksionet e një letre të bardhë; Saktësia e përmbajtjes është njerëzore.

4. Shumëgjuhësia dhe rregullimi i nivelit. AI mund të prodhojë të njëjtën përmbajtje, teknike dhe të thjeshtë, si në turqisht ashtu edhe në anglisht.

Prompt i dobët / Prompt i fortë

Njoftim i dobët:

Shkruani një letër të bardhë për këtë projekt.

AI krijon një kopje të ekzagjeruar, ndoshta të rreme dhe të mbushur me marketing pa e ditur mekanizmin aktual.

Njoftim i fuqishëm:

Roli juaj: shkrimtar teknik i Web3. Më poshtë është mekanizmi REAL, tokenomika dhe kodi i projektit. Shkruani një draft të një letre të bardhë bazuar vetëm në këtë informacion. Rregullat:- Mos e teproni, MOS përdorni fraza si "fitim i garantuar", "plotësisht i sigurt" etj.- Bazojeni çdo pretendim teknik në mekanizmin që jap; Mos shtoni fabrikim.- Shtoni një seksion "Rreziqet" që tregon qartë rreziqet.- Shtoni një paralajmërim "Kjo nuk është këshillë financiare". Shënoni çdo informacion për të cilin nuk jeni i sigurt ose që nuk e kam si [PER TË PLOTËSUAR].

Katër shabllone të kopjueshëm

1) Gjenerimi NatSpec:

Shkruani komente standarde NatSpec në funksionin e mëposhtëm: @notice (çfarë bën, thjeshtë), @dev (shënim teknik), @param dhe @return. Shkruani vetëm atë që kodi bën në fakt; Shtimi i sjelljes që nuk është në kod. Shënoni efektin për të cilin nuk jeni të sigurt.

2) Përkthim teknik-i thjeshtë:

Shpjegoni këtë mekanizëm në turqisht të thjeshtë që një përdorues fillestar i kriptos mund ta kuptojë: çfarë bën, çfarë duhet të bëjë përdoruesi, ÇFARË RREZIQE ka? ekzagjerim; asnjë garanci sigurie. Mos i fshehni rreziqet, nxirrni ato në plan të parë.

3) Seksioni i rrezikut/paralajmërimit:

Shkruani një seksion të sinqertë "Rreziqet dhe paralajmërimet" për këtë projekt: rreziku i kontratës inteligjente, rreziku i tregut, rreziku i likuiditetit, pasiguria rregullatore, humbja kryesore. Shpjegoni çdo rrezik në gjuhë të thjeshtë. Mos i nënvlerësoni rreziqet; përfundoni me "kjo nuk është këshillë financiare".

4) Kontrolli i konsistencës së kodit të dokumentacionit:

Më poshtë është një funksion dhe dokumentacioni i tij i disponueshëm. Shënoni vendet ku dokumenti bie ndesh me sjelljen AKTUALE të kodit. Marrja e vendimeve përfundimtare; Paraqisni atë për "verifikimin e zhvilluesit".

Tre mini kuti (në numër)

Rasti 1 - NatSpec rriti inspektimin. Një ekip paraqiti një kontratë me 25 funksione për shqyrtim pa koment; Auditori kërkoi kohë shtesë për të kuptuar logjikën. Ekipi prodhoi drafte NatSpec me AI dhe konfirmoi secilin me kod; Përgatitja e auditimit u shkurtua për gati 1 ditë. Mësimi: dokumentacioni i mirë redukton koston e auditimit.

Rasti 2 - U kap pretendimi i rremë. Manuali i përdoruesit që prodhoi YZ thoshte se "fondet tuaja mund të tërhiqen në çdo kohë"; kurse në kontratë kishte një bllokim 7-ditor. Rishikimi teknik e kapi këtë. Nëse do të publikohej, përdoruesit do të gaboheshin dhe do të viktimizoheshin. Mësimi: çdo pretendim teknik konfirmohet me kod.

Rasti 3 - Zbardhet ekzagjerimi. Në draftin e parë të letrës së bardhë, AI përdori shprehje të tilla si "kthim i lartë pa rrezik". Ekipi i hoqi këto dhe shtoi një seksion të ndershëm të rrezikut. Kjo e mbronte projektin si në aspektin etik ashtu edhe ligjor. Mësimi: Paragjykimi i marketingut të AI duhet të auditohet.

Barra etike e dokumentacionit

Dokumentacioni Web3 lexohet në një kontekst ku përdoruesi rrezikon paratë e tij. Prandaj:

  • Ndershmëria: Nuk mund të fshihen rreziqet dhe nuk mund të bëhen premtime të ekzagjeruara.
  • Saktësia: Pretendimet teknike duhet të përputhen me kodin; "Dokumenti thotë kështu" nuk është një mbrojtje, por një keqinterpretim.
  • Aksesueshmëria: Të shkruarit në gjuhën që përdoruesi e kupton në të vërtetë është një masë sigurie; Një dokument që nuk kuptohet është një ftesë për mashtrim.
  • Mohim përgjegjësie: Duhet të thuhet qartë se nuk është këshillë financiare dhe pasiguri rregullatore.
Këshillë: Testi i ndershmërisë së një dokumenti Web3: "Nëse një përdorues vendos para duke i besuar vetëm këtij dokumenti, a do të ndihet i mashtruar kur të përballet me të vërtetën?" Gjithmonë duhet që AI të theksojë pjesën e rrezikut, jo ta varrosni në fund.

Gabimet e zakonshme

  • Mos konfirmimi i pretendimit teknik me kod. Dokumenti i gabuar mashtron përdoruesin.
  • Heqja dorë nga hype/gjuha e marketingut. Rreziku etik dhe ligjor.
  • Minimizimi ose fshehja e rreziqeve. Shkelja e besimit.
  • Printimi i letrës së bardhë pa i dhënë mekanizmin e vërtetë AI. Ajo prodhon fabrika.
  • Injorimi i paralajmërimit "jo këshillë financiare". Detyrim ligjor.
  • Mos mbajtja e dokumentacionit në sinkron me kodin. Kur kodi ndryshon, dokumenti bëhet mashtrues.

Në përmbledhje

  • Dokumentacioni është çështje sigurie dhe besimi në Web3; Është fusha më produktive e AI.
  • Kostoja e gabimit është relativisht e ulët, por pretendimet e rreme teknike dhe ekzagjerimi janë rreziqe serioze.
  • Çdo pretendim teknik duhet të konfirmohet me kod real; Dokumenti nuk e zëvendëson kodin.
  • Rreziqet duhet të shkruhen me ndershmëri dhe në mënyrë të dukshme; Duhet hequr ekzagjerimi dhe gjuha e garancisë.
  • "Nuk është këshillë financiare" dhe paralajmërimet rregullatore janë të detyrueshme.

Detyra e aplikimit

Merrni një funksion të zgjuar të kontratës. Jepini AI-së kërkesën "Generate NatSpec" dhe krahasoni interpretimin e gjeneruar rresht pas rreshti me sjelljen aktuale të kodit - a ka ndonjë mosmarrëveshje? Pastaj prodhoni një "përkthim teknikisht të thjeshtë" dhe një "seksion rrezik/paralajmërim" për të njëjtin funksion. Gjeni dhe korrigjoni të paktën një deklaratë të AI që është e ekzagjeruar ose kundërshton kodin.

listë kontrolli

  • [ ] Unë konfirmova çdo pretendim teknik me kodin aktual.
  • [ ] I hoqa ekzagjerimet/garancitë.
  • [ ] Unë i shkrova rreziqet me ndershmëri dhe duke i theksuar ato.
  • [ ] I dhashë AI-së mekanizmin e vërtetë; Nuk e lashë ta shpikte.
  • [ ] Shtova paralajmërimin "Kjo nuk është këshillë financiare."
  • [ ] Kam shkruar NatSpec plotësisht për automjetin dhe kontrollin.
  • [ ] Kam planifikuar ta mbaj dokumentacionin në sinkron me kodin.