Kehitystyön prompt-suunnittelu: 7 mallia, joita käytämme päivittäin Claude Codessa ja Cursorissa (2026)

Kehitystyön prompt-suunnittelu: 7 mallia, joita käytämme päivittäin Claude Codessa ja Cursorissa (2026)

Kehitystyön prompt-suunnittelu on se tekijä, joka erottaa agentin, joka toimittaa toimivan vetopyynnön, agentista, joka hiljaa rikkoo jotain tuotantoympäristössä. Opimme tämän kantapään kautta: yksi epämääräinen ohje omassa putkistossamme loi kerran 54 duplikaattia live-sivua, ennen kuin kukaan huomasi. Nykyään 16 agentin Claude Code -asetelma kirjoittaa, kääntää ja julkaisee sisältömme, ja sitä ohjaavat promptit eivät lainkaan muistuta Googlen ensimmäisen sivun 50 mallin listoja. Tässä ovat 7 mallia, jotka kirjoitamme joka päivä, kukin mukana todellinen ennen-jälkeen-esimerkki.

Pikavastaus: Hyvät koodauspromptit noudattavat yhtä rakennetta. Kerrot tavoitteen ja määritelmän sille, milloin työ on "valmis", nimeät tarkat tiedostot, jotka ovat soveltamisalassa, pakotet suunnitelman ennen mitään muokkauksia, annat testit ja vaadit näyttöä pelkän "näyttää hyvältä" -lausuman sijaan. Kun teet näin, moderni agentti (Claude Code, Cursor, GitHub Copilot) kirjoittaa koodia, joka läpäisee tarkistuksen ensimmäisellä kerralla huomattavasti useammin. Jos ohitat tämän, saat itsevarmaa, uskottavalta vaikuttavaa roskaa.

7 mallia siinä järjestyksessä, jossa turvaudumme niihin:

1. Tehtävän kehystäminen: tavoite, rajoitteet ja "valmis"-määritelmä alussa
2. Kontekstin valinta: nimeä tiedostot, eristä loput
3. Suunnitelma ensin: anna sen ehdottaa ennen kuin se muokkaa
4. Testit ensin: laita hyväksymistestit promptiin
5. Vianetsintä: virhe plus toistettava esimerkki plus odotettu tulos, syy ennen korjausta
6. Refaktorointi: muuta rakenne, säilytä toiminta, näytä diff
7. Tarkistus: lista, jota vasten grepata, plus näyttö

Kehitystyön prompt-suunnittelu vs. konfiguraatiotiedostot: Mikä minnekin

Konfiguraatiotiedostot ja tehtäväkohtaiset promptit hoitavat eri tehtäviä, ja niiden sekoittaminen on yleisin virhe tällä alueella. CLAUDE.md- tai .cursor/rules-tiedosto on pysyvä käytäntö, jonka agentti lukee jokaisessa istunnossa: teknologiapino, nimeämiskäytännöt, testikomento. Prompti on tietty työ, jonka annat sille juuri nyt. Kestävät säännöt menevät konfiguraatioon; tehtävä menee promptiin.

Useimmat "koodauspromptien" kokoelmat summentavat tämän ja kehottavat liittämään jättimäisen personapromptin .cursorrules-tiedostoon. Tämä paisuttaa konfiguraatiota, jonka agentti lataa jokaisessa yksittäisessä tehtävässä, eikä silti kehystä sitä yhtä edessä olevaa tehtävää. Pidä nämä erillään:

Jos haluat saada konfiguraatiopuolen kuntoon, käsittelemme sitä syvällisesti artikkeleissamme CLAUDE.md:n parhaat käytännöt ja Cursor-sääntöjen opas. Tämä artikkeli on toinen puolikas: promptit, jotka kirjoitat uudestaan joka kerta. Molemmat kuuluvat laajempaan prompt-suunnitteluoppaaseemme, jos haluat ensin perusteet.

Kehitystyön prompt-suunnittelu: 7 mallia, joita käytämme päivittäin

Jokaisessa alla olevassa mallissa on heikko versio, jota ihmiset todella kirjoittavat, ja vahva versio, joka tuottaa toimivaa koodia. Heikon ja vahvan välinen ero on lähes aina sama liike: korvaa toive spesifikaatiolla.

1. Tehtävän kehystäminen: Ilmoita tavoite, rajoitteet ja "valmis"-tila

Tehtävän kehystäminen tarkoittaa tavoitteen, rajoitteiden ja "valmis"-tilan määrittelyä ennen kuin agentti koskee riviinkään koodia. Agentti optimoi sen, mitä kirjaimellisesti pyysit, joten sumea pyyntö ansaitsee sumean paikan. Nimeä tiedosto, haluamasi toiminta, hyväksymistarkistus ja asiat, joita se ei saa muuttaa.

Tämä on malli, joka maksoi meille 54 sivua. Vanha käännösohjeemme oli pohjimmiltaan toive:

Weak: Re-translate this post into German and keep the brand names.

Siinä ei sanota mitään siitä, mitä slugille saa tehdä. Uudelleenajossa agentti siis "paransi" URL-slugia, ja koska uusi slug tarkoittaa uutta dokumenttia, päädyimme kahteen live-saksalaiseen sivuun samasta artikkelista. Kerro tämä kielille ja vanhoille artikkeleille, ja saat 54 duplikaattia sekä kasan duplikaattisisällön poissulkuja. Korjaus oli spesifikaatio, ei kauniimpi toive:

Strong: Re-translate this post into German.
- If a German file already exists, copy its existing slug verbatim. Never
  re-derive or "improve" it.
- Before creating any document, look up the existing one by its canonical
  reference and reuse that record.
- If the slug you would generate differs from the live one, STOP and tell me.
  A changed slug creates a second live URL for the same page.

Vahva prompti nimeää vikatilan ääneen. Tämä yksittäinen tapa, sanoa ääneen, mitä ei saa tapahtua ja miksi, on arvokkain muutos, jonka useimmat tiimit voivat tehdä. Lopetamme myös jokaisen tehtäväpromptin eksplisiittiseen tulossopimukseen ("lopullisen viestisi on ilmoitettava sanamäärä, validointipisteet ja kaikki kosketetut tiedostot"), jotta agentti tietää, mitä "valmis" tuottaa, ei vain mitä tehdä.

2. Kontekstin valinta: Nimeä tiedostot, eristä loput

Kontekstin valinta tarkoittaa, että kerrot agentille tarkalleen, mitkä tiedostot sen tulee lukea ja mitkä jättää rauhaan, sen sijaan että annat sen etsiä ympäriinsä ja täyttää ikkunansa kohinalla. Anthropicin oma ohjeistus on suoraviivaista syyn suhteen: konteksti-ikkuna täyttyy nopeasti ja laatu laskee sen täyttyessä, joten useimmat parhaat käytännöt ovat olemassa sen suojelemiseksi (Claude Coden parhaat käytännöt).

Weak: Fix the bug in the checkout flow.

Strong: Read only src/checkout/cart.ts and src/checkout/tax.ts. The tax
rounding is wrong for orders over $1,000 (it rounds each line item instead
of the order total). Fix the rounding. Do not touch anything outside
src/checkout/.

Me eristämme tiukasti. Todellinen rivi agenttiprompteistamme kuuluu: "älä kirjoita tiedostoihin url-mapping.json, pipeline.md tai config.json, etkä koske koskaan mihinkään tiedostoon scratchpad-hakemistosi ulkopuolella." Tämä yksi lause on estänyt enemmän vahingossa aiheutettuja vaurioita kuin mikään määrä jälkikäteen tehtyä siivousta. Kun tehtävä todella tarvitsee live-dokumentteja tai lisätyökaluja, lisäämme ne harkitusti MCP-palvelimien kautta sen sijaan, että toivoisimme agentin sattuvan oikeaan tiedostoon. Ja jos jokin tuo kontekstista tulee reposi ulkopuolelta, käsittele sitä epäluotettavana: katso huomautuksemme prompt-injektion estämisestä ennen kuin liität skrapatun sivun koodausagentille.

3. Suunnitelma ensin: Anna sen ehdottaa ennen kuin se muokkaa

Suunnitelma-ensin-promptaus saa agentin esittämään lähestymistavan ennen kuin se muokkaa mitään. Claude Codessa Plan Mode on kova, pakotettu vain-luku-tila, ei kohtelias "ajattele ensin", jonka malli voi ohittaa, joten se ei kirjaimellisesti voi kirjoittaa, ennen kuin hyväksyt suunnitelman. Tutkimuksen ja suunnittelun erottaminen toteutuksesta on käytäntö, johon Anthropic nojaa eniten välttääkseen väärän ongelman ratkaisemista.

Weak: Add rate limiting to the API.

Strong: Before writing any code, give me a numbered plan: which middleware,
where the counters live, how you handle the 429 response and headers, and
which tests you'll add. Wait for my approval before editing.

Miksi se toimii: suunnitelma on halpa lukea ja halpa korjata. Väärän suunnitelman korjaaminen maksaa yhden lauseen; väärän koodin korjaaminen maksaa tarkistuskierroksen. Tämä sopii luonnollisesti yhteen mallin pyytämisen kanssa perustella askel askeleelta ensin (katso chain-of-thought-promptaus), ja se on selkäranka monivaiheisille Claude Code -työnkuluille, joita ajamme kaikessa ei-triviaalissa työssä.

4. Testit ensin: Laita hyväksymistestit promptiin

Testit-ensin-promptaus laittaa hyväksymiskriteerit promptiin konkreettisina syötteinä ja tuloksina, jotta agentti kirjoittaa koodia määrittelemääsi tavoitetta kohti sen sijaan, että se arvaisi sen. Liitä epäonnistunut testi tai pieni taulukko odotetuista tuloksista ja sano "saada tämä läpäisemään muokkaamatta testiä".

Weak: Write a function to parse ISO 8601 dates.

Strong: Make this failing test pass without changing the test:

  parseIso("2026-07-20T15:00:00Z")   -> Date at that exact UTC instant
  parseIso("2026-07-20")             -> Date at 2026-07-20T00:00:00Z
  parseIso("not-a-date")             -> throws RangeError
  parseIso("")                       -> throws RangeError

Return only the function and its imports.

Konkreettiset esimerkit voittavat adjektiivit joka kerta. "Huomioi reunatapaukset" on toive; neljä riviä syötteestä tulokseen on spesifikaatio, jonka malli voi todella täyttää, ja voit ajaa ne heti, kun koodi laskeutuu.

5. Vianetsintä: Virhe, toisto, odotettu tulos, syy ennen korjausta

Vianetsintäprompti antaa agentille virhetekstin, sen laukaisevan syötteen ja sen, mitä odotit, ja pyytää sitten syytä ennen mitään korjausta. Ohita tämä, ja agentti paikkaa oireen, jolloin bugi vain siirtyy jonnekin hiljaisempaan paikkaan.

Weak: This is throwing an error, fix it.

Strong: This throws on checkout. Here's the stack trace: [paste]. It happens
only when the cart has a discount code AND a gift card (repro: add both, then
check out). Expected: both apply, gift card last. Find the root cause and
explain it in one sentence before you change anything. Do not wrap it in a
try/catch that hides the error.

Rivi "selitä syy yhdellä lauseella ensin" tekee todellista työtä. Se pakottaa mallin sitoutumaan diagnoosiin, jonka voit tarkistaa, sen sijaan että se toimittaisi korjauksen, jonka logiikkaa et koskaan näe. Rivi "älä piilota sitä try/catch-lohkoon" sulkee yleisimmän pakoreitin.

6. Refaktorointi: Muuta rakenne, säilytä toiminta, näytä diff

Refaktorointiprompti rajoittaa soveltamisalaa tiukasti: muuta rakenne, pidä toiminta identtisenä ja näytä diff. Ilman aitaa agentit "siistivät" asioita, joista et koskaan pyytänyt, ja menetät kyvyn tarkistaa muutosta, joka mattered.

Weak: Clean up this file.

Strong: Extract the validation logic from submitOrder() into a pure function
validateOrder(). Keep every public signature and all behavior identical.
Change nothing else in this file. Show me a before/after diff and one line
on why each change is behavior-preserving.

Tämä on kääntöpuoli aiemmalle konfiguraatio-vs-prompt-jaolle: pysyvät tyylisääntösi elävät Cursor-säännöissä, mutta tämän refaktoroinnin soveltamisala kuuluu promptiin. "Älä muuta mitään muuta" on lause, joka pitää refaktoroinnit tarkistettavina.

7. Tarkistus: Lista, jota vasten grepata, plus näyttö

Tarkistusprompti antaa agentille listan, jota vasten grepata, ja vaatii näyttöä, ei tuomiota. "Näyttää hyvältä" on arvoton; komento, jonka se ajoi, ja tulos, jonka se sai, ei ole. Anthropic ilmaisee tämän suoraviivaisesti: anna agentin näyttää näyttöä (testituloste, komento ja sen tulos) sen sijaan, että se väittää onnistumista, koska näytön lukeminen on nopeampaa kuin varmistaminen itse uudelleen.

Weak: Review my PR.

Strong: Check this diff against exactly these five items:
1. No secrets or API keys added
2. Every new function has a test
3. No behavior change outside src/checkout/
4. Error paths return typed errors, not strings
5. No console.log left behind
For each item, quote the line that satisfies or violates it. Then run the
test suite and paste the output. Do not say "done"; show me.

Oma tarkistusporttimme on rakennettu juuri tällä tavalla. Ennen kuin agentti saa ilmoittaa artikkelin julkaistuksi, se greppaa luonnoksen kiellettyjen sanojen listaa vasten (kova esto, nolla toleranssi) ja ajaa kyselyn vahvistaakseen, ettei dokumentin runko ole tyhjä. Agentti ei saa väittää onnistumista; sen on tuotettava tarkistustulos. Tarkistajaroolien osalta, joita käytät paljon, promoteeraa tarkistuslista tallennetuksi personaksi, mistä järjestelmäpromptiesimerkit tulevat kuvaan.

Claude Code vs. Cursor vs. Copilot: Missä kukin malli sijaitsee

Kaikki kolme suurta vuoden 2026 agenttia tukevat kaikkia yllä olevia malleja, mutta käyttöliittymä eroaa. Claude Code nojaa Plan Modeen ja aliagentteihin, Cursor Agent modeen ja sen Agents-ikkunaan, ja GitHub Copilot agent modeen plus ohjetiedostoihin. Valitse työkalu, jossa tiimisi elää; mallit siirtyvät puhtaasti.

Muutama nykyinen yksityiskohta, jotka kannattaa tietää. Claude Coden Plan Mode on aito vain-lukolukko, ja sen aliagentit ajavat eristetyssä kontekstissa omilla työkaluillaan (aliagenttien dokumentaatio). Cursorin vuoden 2026 linja lisäsi Agents-ikkunan, joka käynnistää rinnakkaisia agentteja, kukin omassa git-worktreessään (Cursor 2.0). GitHub Copilotin agent mode lukee mukautetut ohjeet tiedostosta .github/copilot-instructions.md plus polkukohtaisista .instructions.md-tiedostoista, joissa on applyTo-kenttä (Copilotin mukautetut ohjeet). Jos Cursor on päivittäinen ajurisi, katso postauksemme Cursorin tehokkaammasta käytöstä.

Miten promptaamme koodausagenttejamme Techsyllä

Ajamme sisältöputkistoa 16 Claude Code -agentin tiiminä: tutkija, briefin kirjoittaja, sisällöntuottaja, yhdeksän kääntäjää, validaattori ja julkaisija, koordinoituna tehtäväviesteillä. Kaksi käytäntöä tästä järjestelmästä siirtyy mihin tahansa koodaustiimiin.

Ensinnäkin, jokainen tehtäväprompti päättyy tulossopimukseen. Viimeinen rivi on aina jonkinlainen versio lauseesta "lopullisen viestisi on ilmoitettava X, Y ja Z". Agentti, joka tietää "valmis"-tilan tarkan muodon, harhailee huomattavasti vähemmän kuin sellainen, jolle kerrotaan vain, mistä aloittaa.

Toiseksi, emme koskaan anna agentin arvioida omaa työtään proosamuodossa. Generointi ja varmistus ovat erillisiä vaiheita, ja varmistus on komento tuloksineen, ei mielipide. Tämä rakentamisen ja tarkistuksen erottelu on keskeinen osa sitä, miten Anthropic kehystää luotettavien agenttien rakentamisen, ja siksi tarkistusporttimme greppaa ja kyselyöi sen sijaan, että luottaisi "näyttää hyvältä" -lausumaan.

Tämä on myös päivittäinen työ. Techsyllä rakennamme tekoälyagentteja ja automaatiota B2B-tiimeille, ja tällainen promptidiscipliini on suurin osa siitä, mikä erottaa demon jostakin, jonka voit esittää asiakkaalle. Jos haluat koodaus- tai agenttityönkulun asetettuna kunnolla, AI-integraatiopalvelumme on paikka, jossa teemme juuri sitä, ja voit varata ilmaisen konsultaation keskustellaksesi pinostasi.

Kopioi-liitä-promptimalli, jota voit mukauttaa

Tässä on luuranko, josta aloitamme minkä tahansa ei-triviaalin koodaustehtävän kohdalla. Poista osiot, joita et tarvitse, mutta pidä järjestys, koska se heijastaa seitsemää mallia.

GOAL
One sentence: what should be true when you're done.

CONTEXT
Read only: <exact files>. Ignore everything else.
Relevant facts: <constraints, versions, the bug's trigger>.

PLAN FIRST
Before editing, give me a numbered plan and wait for approval.

TESTS / DONE
Done means: <paste failing test or input->output rows>.
Don't change the tests.

CONSTRAINTS
Keep all public signatures and behavior identical unless stated.
Do not touch <files/areas>. Name any assumption you make.

OUTPUT
Show a before/after diff, run the tests, and paste the output.
Don't say "done"; show the evidence.

Tallenna se snippettinä, tai vielä parempi, pilko se: pysyvät rajoitteet menevät konfiguraatiotiedostoosi, ja tavoite, konteksti ja testit menevät promptiin. Tämä jako on koko pointti.

Kirjoittajasta

Mert Batur Gurbuz on Techsy.io:n co-founder, jossa tiimi toimittaa tekoälyagentteja, automaatiojärjestelmiä ja voice/SDR-putkistoja B2B-asiakkaille. Hän opiskelee Birminghamin yliopistossa ja kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi todella käyttää tuotannossa.

Ansioitukset: Co-Founder, Techsy.io, Birminghamin yliopisto. Yhdistä LinkedInissä.

Usein kysytyt kysymykset

Mikä on kehitystyön prompt-suunnittelu?

Kehitystyön prompt-suunnittelu on käytäntö kirjoittaa ohjeita, jotka saavat tekoälyagentin tuottamaan correct, tarkistettavissa olevaa koodia. Käytännössä se tarkoittaa tavoitteen ja "valmis"-määritelmän ilmoittamista, soveltamisalan tiedostojen nimeämistä, suunnitelman pakottamista ennen muokkauksia, testien toimittamista ja näytön vaatimista. Se on lähempänä spesifikaation kirjoittamista kuin nokkelan lauseen kirjoittamista.

Miten se eroaa CLAUDE.md- tai .cursor/rules-tiedoston kirjoittamisesta?

Konfiguraatiotiedostot sisältävät pysyviä käytäntöjä, joita agentti lukee jokaisessa istunnossa: teknologiapino, käytännöt ja testikomento. Tehtäväkohtainen prompt on tietty työ, jonka annat sille juuri nyt. Laita kestävät säännöt konfiguraatioon ja tehtävä promptiin. Kokonaisten tehtäväpromptien liittäminen konfiguraatiotiedostoon paisuttaa jokaisen istunnon eikä silti kehystä yksittäistä tehtävää.

Mikä on paras promptirakenne tekoälyn koodausagenteille?

Käytä nimettyjä osioita yhden kappaleen sijaan: GOAL, CONTEXT, PLAN, TESTS, CONSTRAINTS ja OUTPUT. Agentit jäsentävät jäsennellyt promptit luotettavammin kuin tekstiseinät. Ilmoita onnistumiskriteerit alussa, anna yksi–kolme konkreettista esimerkkiä adjektiivien sijaan ja määritä tarkka tulostemuoto, jonka haluat takaisin.

Miten kirjoitan hyvän vianetsintäpromptin?

Anna agentille neljä asiaa: tarkka virhe tai stack trace, sen toistava syöte, mitä odotit ja pyyntö juurisyystä ennen mitään korjausta. Lisää "selitä syy yhdellä lauseella ennen kuin muutat mitään", jotta voit tarkistaa diagnoosin, ja "älä piilota sitä try/catch-lohkoon", jotta se korjaa bugien sijaan peittää sen.

Pitäisikö minun sisällyttää testit koodausprompteihini?

Kyllä, aina kun mahdollista. Epäonnistuneen testin tai pienen taulukon syötteestä tulokseen -rivien liittäminen muuttaa sumean pyynnön kohteeksi, jonka malli voi todella osua, ja voit ajaa tuloksen välittömästi. Kerro agentille, että sen on saatava testit läpäisemään muokkaamatta niitä, jotta se ei voi siirtää maalitolppia saadakseen oman koodinsa näyttämään oikealta.

Toimivatko nämä promptit myös Cursorissa ja GitHub Copilotissa?

Kyllä. Mallit ovat työkaluriippumattomia. Claude Code paljastaa ne Plan Moden ja aliagenttien kautta, Cursor Agent moden ja sen Agents-ikkunan kautta worktree per agentti, ja GitHub Copilot agent moden plus .github/copilot-instructions.md-tiedoston kautta. Pintataso muuttuu; tehtävän kehystäminen, kontekstin valinta, suunnitelma ensin ja näyttöpohjainen tarkistus eivät.

Kuinka pitkän koodauspromptin pitäisi olla?

Tarpeeksi pitkä ollakseen spesifikaatio, tarpeeksi lyhyt pysyäkseen fokusoituneena. Päättelylaatu heikkenee kontekstin täyttyessä, joten suosii rakennetta volyymin sijaan: nimetty, 150–300 sanan prompt oikeilla tiedostoilla ja testeillä voittaa jaarittelevan promptin. Siirrä kaikki, joka pätee jokaiseen tehtävään, konfiguraatiotiedostoosi sen sijaan, että toistat sitä.

Miten estän tekoälyagenttia muuttamasta koodia, jota en pyytänyt?

Rajaa soveltamisala promptissa. Sano tarkalleen, mitkä tiedostot se saa muokata, lisää "älä muuta mitään muuta" ja vaadi "pidä kaikki julkiset signatuurit ja toiminta identtisinä, ellei toisin määrätä". Refaktoroinneissa pyydä ennen/jälkeen-diffiä yhdellä rivillä siitä, miksi kukin muutos säilyttää toiminnan, jotta kaikki pyytämättömät muokkaukset ovat ilmeisiä tarkistuksessa.

Ovatko kopioi-liitä-promptikirjastot sen arvoisia?

Lähtökohtana, joskus. Valmiina työkaluna, harvoin. 50 promptin kirjasto antaa sinulle formuloinnin, mutta se ei voi tietää tiedostojasi, testejäsi tai rajoitteitasi, missä oikeellisuus todella asuu. Opettele mallit, pidä yksi mukautettava malli ja täytä edessä olevan tehtävän yksityiskohdat.