Kaip sukurti AI MVP naudojant „Codex“, „Claude“, „VS Code“ ir „Replit“ 2026 m.

Kas atsitiks po idėjos

Dauguma žmonių nebeužstringa ties idėjų generavimu. AI padaro šią dalį pigiu. Tikroji problema prasideda vienu žingsniu vėliau.

Jie turi apytikslę produkto idėją, atidaro kodavimo įrankį, prašo per daug per anksti, gauna krūvą kodo, praranda aiškumą ir pamažu atsisako projekto.

Pataisymas nėra geresnis entuziazmas. Pataisa yra geresnė seka.

Stiprus dirbtinio intelekto kūrimo procesas atrodo taip:

Šiame straipsnyje kalbama apie vidurinį atkarpą. struktūra."

1 veiksmas: prieš paliesdami kodą, padėkite procesą ant popieriaus

Prieš pasirinkdami „Codex“, „Claude“, „VS Code“, „Replit“ ar bet ką kitą, parašykite darbo eigą paprasta kalba.

Būk žiauriai paprasta:

• Kas yra vartotojas?
• Kokią įvestį jie pateikia?
• Kokios išvesties jie nori?><
• Koks sprendimas neturėtų įvykti?
• Koks sprendimas neturėtų būti toliau? pradžios taškas: „Noriu sukurti dirbtinio intelekto įdarbinimo platformą“.

  Geresnis atspirties taškas: „Verbuotojas įklijuoja interviu pastabas, gauna struktūrizuotą santrauką, ją redaguoja ir išsaugo kandidato įraše.

  Jei negalite penkiomis eilutėmis paaiškinti darbo eigos, dirbtinio intelekto kūrimo įrankis jums dažnai pritaiks vieną gerą pastabą.

  Tai turėtų apimti problemą, vartotoją, srautą, sėkmės kriterijus ir kraštutinius atvejus. Šis puslapis tampa kiekvieno vėlesnio raginimo instrukcijų prierašu.

2 veiksmas: paprašykite AI susisteminti idėją, o ne kurti visą įmonę

Jūsų pirmasis naudingas AI raginimas paprastai nėra „sukurti šią programą“. Tai yra „padėkite man sukonstruoti šią programą“.

Naudokite modelį, kad sugriežtintumėte apimtį prieš jam įrašant kodą.

Turiu AI produkto idėją. Padėkite man tai paversti maža, tikroviška MVP specifikacija.

Idėja:
[įklijuokite savo apytikslę idėją]

Prašome grąžinti:
1. tikslinis vartotojas
2. tiksli darbo eiga
3. MVP taikymo srities funkcijos
4. nepatenka į taikymo sritį
5. duomenų įvedimai
6. išvesties schema
7. tikėtinų nesėkmių atvejai
8. audito patikrinimai
9. paprasčiausia techninė architektūra
10. 7 dienų statybos planas

Laikykite MVP siaurą. Neplėskite gaminio.

Toks raginimas naudingas, nes sumažina triukšmą. Jūs prašote modelio apriboti projektą, o ne jį papuošti.

Kai išvestis bus gera, išsaugokite ją trumpo projekto faile, pvz., project-brief.md. Tas failas tampa visos versijos veikimo kontekstu.

3 veiksmas: pasirinkite tinkamą statybinį paviršių

Viena didžiausių klaidų – įrankių pasirinkimas pagal ažiotažą, o ne darbo eigą. Geriau pirmiausia pasirinkti kategoriją, o tada produktą.

Šios svetainės įrankių puslapyje jau naudojama naudinga klasifikacija:

Gerai veikia paprasta sprendimo taisyklė:

• naudokite AI kūrimo platformas, kai svarbiausia yra greitis, o programa vis dar nestabili.
• Naudokite AI-NativeU, kai norite stipresnio IDEkonfigūravimo. CLI, kai norite vietinių saugyklų, terminalo darbo eigos ir aiškaus failų valdymo.
• Naudokite Agentinį kodavimą, kai norite, kad sistema imtųsi didesnių diegimo dalių, bet vis tiek būtų ribotoje atpirkimo vietoje.

Pasirinkite kūrimo paviršių, atitinkantį jūsų mintis, o ne paleidimo vaizdo įrašą su lou>.

4 veiksmas: pradėkite nuo vietinio „git“ atpirkimo

Rimčiausiems MVP paleiskite vietinį, net jei programa galiausiai gali būti naudojama „Replit“ ar kitoje naršyklės kūrimo priemonėje.

Vietinis atpirkimas iš anksto suteikia tris dalykus:

• versijų istoriją.
• Stabilią vietą raginimams, pastaboms ir specifikacijoms.
• Aiškios AI kodavimo įrankių ribos.

  mažytis:

  my-ai-mvp/
    README.md
    projektas-brief.md
    auditas-checks.md
    raginimai/
    programa/
    scenarijai/
    sample-data/

  Esmė ne elegancija. Esmė yra izoliavimas.

  Sukurkite atpirkimo sandorį, atlikite pirmąjį įsipareigojimą po to, kai bus išsaugotas trumpinys, tada leiskite dirbtinio intelekto įrankiui dirbti su realia projekto struktūra, o ne tuščia tuštuma. Tai sumažina atsitiktinį išsiplėtimą ir palengvina vėlesnę peržiūrą.

5 veiksmas: sukurkite vieną vertikalią pjūvį, o ne visą planą

Greičiausias būdas sustabdyti pagreitį – sukurti autentifikavimą, atsiskaitymą, komandas, nustatymus, informacijos suvestines, integracijas ir įmantrią vartotojo sąsają prieš pradedant pagrindinę darbo eigą.

Sukurkite vieną vertikalią pjūvį:

• viena įvestis
• vienas modelio iškvietimas
• vienas išvesties schema yra vienas išsaugomas paviršius
• vienas paviršius
• li> pakanka rimtai pirmai versijai.

  Geras diegimo raginimas atrodo taip:

  Naudodami projekto trumpą informaciją šiame atpirkimo sandoryje, sukurkite tik pirmą vertikalią pjūvį.
  
  Taikymo sritis:
  - vienas įvesties ekranas
  - vienas galinis maršrutas
  - viena struktūrinio modelio produkcija
  - vienas peržiūros ekranas
  - vienas išsaugojimo veiksmas
  
  Nepridėkite autentifikavimo, atsiskaitymo, komandos funkcijų, analizės informacijos suvestinių ar papildomų darbo eigų.
  Kodas turi būti mažas ir skaitomas.
  Po kodavimo apibendrinkite:
  1. kas buvo pastatyta
  2. ko dar trūksta
  3. ką reikėtų išbandyti rankiniu būdu

  Šis raginimas svarbus, nes neleidžia įrankiui paleisti paleisties modeliuoklio.

6 veiksmas: pakartotinai naudokite atvirąjį kodą prieš atkurdami pagrindus

Dauguma naujokų kūrėjų sugaišta daug laiko ir atkuriant žetonus.

Jie prašo dirbtinio intelekto sukurti tinkintą prisijungimą, tinkintą šifravimą, tinkintą failų tvarkymą, pasirinktines fonines užduotis, tinkintus administratoriaus įrankius ar net tinkintus duomenų bazės pagalbininkus, kol produktas dar nepasiekė tokio sudėtingumo.

Tai paprastai yra klaida. infrastruktūrą, sukurkite tik produkto logiką.

Produktas turi būti naujas. Santechnika turi būti standartinė.

Tai nėra tinginystė. Tai yra išgyvenimas. Kiekvienas tinkintas posistemis prideda daugiau kodo, kad būtų galima pasitikėti, daugiau klaidų derinimui ir daugiau AI įrankio paviršiaus.

Kai paprašote Codex, Claude, VS Code ar kito įrankio padėti, būkite atviri: nurodykite pirmiausia integruoti patikrintus įrankius ir nekurti tinkintos infrastruktūros be tikros priežasties.

7 veiksmas: pridėkite audito veiksmus, kol programa nebus baigta

Nelaukite iki paleidimo savaitės ir paklauskite, ar sistema patikima.

Iš anksto sukurkite failą audit-checks.md. Čia daugelis statybininkų rimčiau užsiima. Jie nustoja klausti tik "ar tai veikia?" ir pradėkite klausti „ką tiksliai audituojame kiekvieną kartą, kai jį keičiame?“

Praktinis AI MVP auditas gali būti labai paprastas, tačiau jis vis tiek turėtų būti aiškus. Stipri pirmoji versija dažnai patikrina dvidešimt dalykų:

1. Schema galioja.
2. Yra privalomi laukai.
3. Laukai, kurie turi likti tušti, neatspėjami.
4. Neapdorota įvestis išsaugoma.
5. Neapdorota modelio išvestis išsaugoma.
6. Peržiūrėta žmogaus išvestis išsaugoma redaguojant. galima sekti.
7. Laimingo kelio pavyzdys vis tiek praeina.
8. Krašto atvejo pavyzdys vis tiek praeina.
9. Tuščia arba silpna įvestis tvarkoma saugiai.
10. Ilga įvestis sutrumpinama arba tyčia suskaidoma į dalis.
11. Prieštaringa įvestis rodoma, o ne paslėpta. Rezultatai yra svarbūs, o ne paslėpti.
12. Rodomi šaltinio įrodymai.
13. Pakartotiniai bandymai ir skirtojo laiko pabaiga elgiasi protingai.
14. Lasena matuojama.
15. Matoma apytiksliai kaina už vieną paleidimą.
16. Pataisos rodiklis matomas žmogui peržiūrėjus.
17. Žurnaluose galima ieškoti, kai kas nors sugenda.
18. Auksiniai pavyzdžiai nereikėtų paleisti iš naujo. milžiniška platforma tai padaryti. Reikia disciplinos.

    Naudingas audito ritmas po kiekvieno reikšmingo pakeitimo yra toks:

    • paleiskite 5–20 žinomų pavyzdžių
    • patikrinkite, kas pagerėjo
    • patikrinkite, kas regresavo
    • parašykite vieną trumpą pastabą CHANGELOG.md arba >audit-cheulckp>. iteracija mažiau trapi. Be jų kiekvienas skubus koregavimas atrodo kaip lošimas.