Tähän mennessä olet kerännyt kolme rakennuspalikkaa ja tehnyt toteutuspäätöksen. Tällä tunnilla yhdistät ne ensimmäiseksi arvioitavaksi versioksi. Teknisen toteutuspolun valinnut rakentaa botin saatavilla olevalle alustalle. Dokumentoidun suunnittelupolun valinnut tuottaa arkkitehtuurin ja simuloidun suoritusjäljen, josta käy täsmällisesti ilmi, mitä valmis järjestelmä tekisi ja mikä jää toteuttamatta.
Tällä tunnilla et opiskele enää uusia teoreettisia käsitteitä. Sen sijaan siirrät suunnitelman järjestelmäpromptiksi ja toteutuskuvaukseksi. Ensimmäisen version ei tarvitse olla täydellinen. Tärkeintä on saada aikaan näyttöä, jota voit testata, korjata ja puolustaa Apuri-botin viimeistelytunnilla. Polut ovat samanarvoisia, mutta ne eivät todista samoja asioita.
Järjestelmäprompti on botin pääohje, jonka annat valitulle alustalle tai liität suunnittelupolun toteutuskuvaukseen. Se määrittää, miten botin on tarkoitus käyttäytyä keskusteluissa. Käyttäjä ei yleensä näe järjestelmäpromptia, mutta arvioinnissa se kuuluu näkyvään dokumentaatioon.
Voit ajatella järjestelmäpromptia botin työsopimuksena: kuka botti on, mikä sen tehtävä on ja missä sen rajat kulkevat.
Työsopimuksen tavoin hyvä järjestelmäprompti vastaa neljään kysymykseen. Ensin se kertoo, kuka botti on: mikä rooli sillä on ja millaisena se esittäytyy käyttäjälle. Toiseksi se kertoo, mitä botti tekee — mikä on sen varsinainen tehtävä ja missä järjestyksessä se etenee, kun käyttäjä ottaa yhteyttä. Kolmanneksi se määrittää, miten botti puhuu: teitittelee vai sinuttelee, vastaa lyhyesti vai perusteellisesti, käyttää ammattitermejä vai selittää ne auki.
Neljäs kysymys on se, joka useimmin unohtuu ja joka useimmin ratkaisee botin laadun: mitä botti ei tee. Rajat ja kiellot kertovat, mihin kysymyksiin botin ei pidä vastata, milloin sen pitää ohjata käyttäjä ihmisen puheille ja mitä sen ei pidä väittää tietävänsä. Ilman tätä osaa botti vastaa mielellään kaikkeen, myös siihen mistä se ei tiedä mitään.
Kolme rakennuspalikkaasi muuttuvat järjestelmäpromptiksi seuraavasti:
| Rakennuspalikka | Mihin osaan järjestelmäpromptia? |
|---|---|
| 1: Promptikortti | Testattu rakenne ja kieli. Käytä pääohjeessa ratkaisuja, joiden vaikutuksen osoitit Promptikortti-tunnilla. |
| 2: Botin määrittely | Sisältö. Kuusi osaa eli nimi, kohderyhmä, tarkoitus, persoona, työnkulku ja rajat muuttuvat suoraan järjestelmäpromptin kappaleiksi. |
| 3: Tietopohja ja testisuunnitelma | Hyväksytty aineisto ja kolme ennalta kirjoitettua testiä. Tekninen polku kytkee aineiston alustan tietopohjaksi. Suunnittelupolku kuvaa hakutavan, käyttöoikeusrajauksen ja mallille annettavat lähdekatkelmat. Järjestelmäprompti kertoo, miten löydettyä lähdettä käytetään, mutta ei korvaa hakua tai käyttöoikeuksia. |
Järjestelmäprompti ei ole neljäs rakennuspalikka. Se on näiden kolmen rakennuspalikan päätöksistä koottu toteutusohje.
Alla on yksinkertainen esimerkki siitä, miten botin määrittelyn sisältö muuttuu järjestelmäpromptiksi. Ota se malliksi, mutta älä kopioi sitä sellaisenaan.
Botin nimi: Treenikaveri
Kohderyhmä: Opiskelija, joka aloittaa salitreenin ja haluaa suunnitella oman viikko-ohjelman
Tarkoitus: Ohjata käyttäjää kokoamaan itselleen sopiva treeniviikko kuuden vaiheen kautta
Persoona: Kannustava, käytännönläheinen, kysyvä, ei jargonia
Työnkulku: 1) Tavoite → 2) Lähtötaso ja kokemus → 3) Käytettävissä olevat päivät → 4) Liikkeiden valinta → 5) Viikko-ohjelman kokoaminen → 6) Palautuminen ja seuranta
Rajat: Ei kirjoita ohjelmaa valmiiksi käyttäjän puolesta kysymättä mitään, ei anna lääketieteellisiä neuvoja, ei käsittele muita aiheita kuin treenausta
Olet Treenikaveri. Autat opiskelijaa, joka aloittaa salitreenin, kokoamaan itselleen sopivan treeniviikon.
Työnkulkusi: Ohjaat käyttäjää aina järjestyksessä kuuden vaiheen läpi: (1) tavoite, (2) lähtötaso ja kokemus, (3) käytettävissä olevat päivät, (4) liikkeiden valinta, (5) viikko-ohjelman kokoaminen ja (6) palautuminen ja seuranta. Et siirry seuraavaan vaiheeseen ennen kuin nykyinen vaihe on käsitelty.
Tapasi puhua: Olet kannustava, käytännönläheinen ja kysyvä. Pyydät käyttäjältä konkreettisia vastauksia etkä hyväksy ympäripyöreitä vastauksia sellaisenaan. Et käytä vaikeaa jargonia. Käytät treenauksen omia termejä, kuten sarja, toisto, palautuminen ja viikko-ohjelma.
Et koskaan: kokoa ohjelmaa valmiiksi käyttäjän puolesta kysymättä mitään, anna lääketieteellisiä neuvoja tai käsittele muita aiheita kuin treenausta. Jos käyttäjä pyytää näitä, ohjaa hänet ystävällisesti takaisin aiheeseen tai oikean asiantuntijan puoleen.
Tietopohja: Käytä bottiin ladattuja dokumentteja referenssinä, kun ohjaat käyttäjää.
Huomaa, että botin määrittelyssä sisältö on kuvailevassa muodossa, kun taas järjestelmäpromptissa puhutaan botille suoraan: "Olet…", "Työnkulkusi…" ja "Et koskaan…". Tämä on tärkein muunnos: kuvaileva määrittely muutetaan suoraksi ohjeeksi botille.
Kun olet kirjoittanut järjestelmäpromptin ensimmäisen version, voit pyytää tekoälyltä apua sen viimeistelyyn. Käytä esimerkiksi seuraavaa promptia:
"Toimi sparrauskumppaninani. Olen kirjoittamassa apuri-botin järjestelmäpromptia. Tässä ovat määrittelydokumenttini ja ensimmäinen versio järjestelmäpromptista:
MÄÄRITTELY: [liitä rakennuspalikka 2]
JÄRJESTELMÄPROMPTI, versio 1: [liitä oma promptisi]
Auta minua arvioimaan: onko järjestelmäpromptissa mukana kaikki, mitä määrittelyssä oli? Onko jokin kohta botille epäselvä? Onko jokin ohje liian yleinen, esimerkiksi 'vastaa hyvin'? Älä kirjoita uutta versiota. Anna 2–3 konkreettista parannusehdotusta, joiden pohjalta voin tehdä omat muutokseni."
Tästä eteenpäin polut eroavat. Jos sinulla on käytössä alusta, jolle botin voi rakentaa, teet toimivan version. Jos ei ole, teet dokumentoidun suunnitelman, joka arvioidaan samoilla kriteereillä — kumpikaan polku ei ole toista arvokkaampi, ja molemmissa ratkaisee sama asia: miten hyvin määrittelysi kestää testin.
Tällaisia alustoja ovat esimerkiksi ChatGPT:n räätälöidyt botit, Microsoft Copilot Studio ja Clauden projektit. Oppilaitoksissa käytettävissä oleva alusta riippuu lisensseistä ja ikärajoista, joten opettaja kertoo, mikä on teillä käytössä. Jos mikään ei ole käytettävissä, dokumentoitu suunnittelupolku on täysi vaihtoehto — sitä käytetään myös työelämässä ennen kuin mitään rakennetaan.
Teknisellä toteutuspolulla luot botin saatavilla olevalle alustalle:
Dokumentoidulla suunnittelupolulla teet toteutuspaketin:
Älä yritä tehdä botista heti täydellistä. Aja tai simuloi nyt ensimmäisen kerran kaikki kolme Oma botti II -tunnilla kirjoittamaasi testiä: normaali tapaus, kielteinen testi ja reunatapaus.
Tärkein sääntö on, että käytät samoja testejä ja samoja odotuksia kuin kirjoitit Oma botti II -tunnilla. Houkutus muuttaa odotusta ensimmäisen tuloksen jälkeen on suuri — jos botti vastaa toisin kuin odotit, on helppo ajatella että odotus olikin väärä. Silloin testi lakkaa mittaamasta mitään.
Teknisellä polulla ajat testit oikealla botilla ja tallennat jokaisesta syötteen, vastauksen ja mahdollisen lähdeviitteen. Suunnittelupolulla käyt testit läpi vaihe vaiheelta ja merkitset jokaisen simuloidun haun, tarkistuksen ja vastauksen erikseen. Kummallakin polulla vertaat tulosta siihen, mitä odotit — ja kirjaat myös sen, mitä oma polkusi ei pysty todentamaan. Rehellinen maininta puuttuvasta todisteesta on arvioinnissa parempi kuin vaikutelma, että kaikki toimi.
Pysyykö botti roolissaan?
Vai unohtaako se, että se on oman aiheesi apuri, ja muuttuuko se yleiseksi avustajaksi?
Seuraako botti työnkulkua?
Vai hyppiikö se osasta toiseen sattumanvaraisesti?
Käyttääkö botti tietopohjaa oikein?
Löytyikö oikea lähde, ja tukeeko lähde muodostettua vastausta? Suunnittelupolulla tämä on simuloitu tarkistus, ei todiste toimivasta hausta.
Yrittääkö botti tehdä työn käyttäjän puolesta?
Jos pyydät sitä tekemään koko tehtävää puolestasi, noudattaako se ohjeitaan vai murtuuko rajaus?
Kolmen testin jälkeen kirjoita tiivis korjauslista havainnoista, jotka eivät vielä toimi. Älä tee vielä arvioitavaa korjausta, sillä nimetty korjaus ja sen uudelleentesti kuuluvat Apuri-botin viimeistelytunnille. Esimerkkejä:
Tunti 17 on raakaversion vaihe. Älä turhaudu, jos tekninen botti ei vielä toimi täydellisesti tai suunnitelman aukko tulee näkyviin. Hyvä botti syntyy iteroinnista. Tällä tunnilla tuotat ensimmäisen todennettavan teknisen version tai ensimmäisen tarkistettavan suunnittelupaketin, ja Apuri-botin viimeistelytunnilla viimeistelet sen.
Ensimmäinen versio on aina raaka. Hyvä botti syntyy iteroinnista.
Tarkistettu 15.7.2026.
HUOM: Tätä varten sinulla tulee olla kerättynä rakennuspalikat 1–3 (tunnit 12, 14 ja 15).
Aloitat oman apuri-bottisi teknisen toteutuksen tai dokumentoidun suunnittelun. Et tee tätä tyhjästä — yhdistät kolme rakennuspalikkaa ja Oma botti III -tunnin valintakortin. Tunnin lopussa sinulla on joko ensimmäinen toimiva versio tai ensimmäinen tarkistettava suunnittelupaketti, jota viimeistelet Apuri-botin viimeistelytunnilla.
Käytä tekoälyä apuna järjestelmäpromptin kirjoittamisessa ja iteroinnissa. Tarkoitus ei ole, että keksit kaiken itse — vaan että osaat ohjata tekoälyä auttamaan järjestelmäpromptin muotoilussa ja teet lopulliset päätökset itse. Sinun vastuullasi on, että rakennuspalikoiden ydin näkyy lopullisessa botissa.
Tämän tunnin työ rakentuu neljään vaiheeseen:
Jokainen rakennuspalikka palvelee tiettyä osaa botista. Älä yritä keksiä mitään uudelleen — käytä mitä olet jo tehnyt:
Apuri-botin rakennustunnin lopussa sinulla on:
Tämä on lähtötaso. Lopullinen botti syntyy Apuri-botin viimeistelytunnilla, kun iteroit, testaat tarkemmin ja viimeistelet.
Aloita näin:
Ensimmäinen versio on aina raaka. Hyvä botti syntyy iteroinnista.
Tällä välilehdellä varmistat, että rakennuspalikat ja valitsemasi suorituspolku ovat kirkkaina mielessä. Tekninen toteutuspolku ja dokumentoitu suunnittelupolku ovat samanarvoisia, mutta niiden näyttö ei ole sama.
Botin määrittely — Lyhyt kuvaus siitä, kenelle botti on, mitä se osaa, mitä se ei tee ja mitkä ovat sen rajat. Tämä on botin "perustamisasiakirja", josta järjestelmäprompti johdetaan. Älä sekoita tätä siihen, mitä botti auttaa käyttäjää tekemään — määrittely kertoo botista itsestään.
Kohderyhmä — Ne käyttäjät, joita varten botti on rakennettu. Esimerkiksi luokkakaverit, kerhon uudet jäsenet tai kirjaston asiakkaat. Kun tiedät kohderyhmän, osaat valita oikean kielen ja sisällön.
Työnkulku — Järjestys, jossa botti ohjaa käyttäjää vaiheesta toiseen. Selkeä työnkulku auttaa botin pysymään raiteilla eikä hyppimään satunnaisesti.
Rajat — Määritelmä siitä, mitä botti tekee ja mitä ei. Selkeät rajat estävät bottia leviämästä hallitsemattomasti tai vastaamasta asioihin, joihin sen ei kuulu vastata.
Tietopohja — Kokoelma dokumentteja, joista botti ammentaa oman aiheesi tietoa. Hyvä botti nojaa kuratoituun tietopohjaan, ei pelkkiin yleisiin oletuksiin.
Iterointi — Botin parantaminen testaamalla, korjaamalla ja testaamalla uudelleen. Hyvä botti syntyy iteroinnista, ei heti ensimmäisellä yrityksellä.
Järjestelmäprompti — Botin toimintaa ohjaava teksti, joka määrittää botin roolin, tehtävän, toimintatavan ja rajat. Se vaikuttaa kaikkiin botin vastauksiin.
Mukautettu botti — Tiettyyn tarkoitukseen määritetty botti. Se voi sisältää järjestelmäpromptin, ohjeita, tiedostoja ja integraatioita.
Persoona — Botille määritetty viestintätapa ja sävy. Persoona voi olla esimerkiksi ystävällinen ja kärsivällinen tai suora ja asiallinen. Se tukee botin roolia, mutta ei korvaa tehtävää tai asiantuntemusta.
Konteksti — Taustatieto, jonka perusteella botti tulkitsee pyyntöä ja muodostaa vastauksen. Konteksti voi sisältää aiemman keskustelun tai botille annetut dokumentit.
Iteraatio — Prosessi, jossa testataan, parannetaan, testataan uudelleen ja parannetaan jälleen. Hyödylliset botit syntyvät iteraation kautta, ei heti täydellisesti ensimmäisellä kerralla.
Positiivinen testaus — Testataan asioita, joiden pitäisi toimia. Nähdään, vastaako botti oikein normaaleissa tilanteissa.
Negatiivinen testaus — Testataan asioita, joiden ei pitäisi toimia. Nähdään, kieltäytyykö botti asianmukaisesti ja suojaako se itseään.
Reunatapaus — Poikkeava tai odottamaton tilanne, kuten tyhjä syöte, väärällä kielellä kirjoitettu teksti tai hyvin pitkä teksti. Reunatapausten avulla arvioidaan, kuinka luotettavasti botti toimii poikkeavissa tilanteissa.
Testidokumentti — Kirjallinen raportti, joka sisältää syötteen, odotetun tuloksen, todellisen tuloksen ja analyysin.
Tekninen toteutuspolku — Suorituspolku, jossa botti rakennetaan käytettävälle alustalle ja sen todellinen toiminta testataan.
Dokumentoitu suunnittelupolku — Suorituspolku, jossa botin arkkitehtuuri, simuloitu suoritusjälki, testit ja rajoitukset kuvataan ilman väitettä toimivista integraatioista.
Simuloitu suoritusjälki — Vaiheittainen kuvaus siitä, miten suunniteltu botti käsittelisi syötteen. Se ei todista teknisen yhteyden, käyttöoikeuden tai tallennuksen toimivan.
Vuorovaikutuksellinen — Kaksisuuntainen: käyttäjä kysyy, botti vastaa, käyttäjä kysyy lisää. Se ei ole yhdensuuntaista tiedon jakamista.
Täsmällisyys — Vastauksen oikeellisuus ja osuvuus suhteessa käyttäjän pyyntöön.
Keskustelukonteksti — Aiemmat viestit, joita botti voi hyödyntää saman keskustelun aikana. Hyvin suunniteltu botti ei kysy uudelleen jo annettua tietoa.
Validointi — Tarkistaminen, että tieto on oikein ennen sen käyttämistä. Esimerkiksi: "Ymmärsinkö oikein: treenaat kolmena päivänä viikossa ja tavoitteesi on parantaa kuntoa?"
Dokumentaatio — Kirjallinen tai visuaalinen kuvaus siitä, miten jotain tehdään tai miten jokin toimii. Hyvä dokumentaatio auttaa muita ymmärtämään ja jatkamaan työtä.
Prosessin dokumentointi — Kuvaus kaikista askeista, joita otettiin ongelman ratkaisussa. Näytetään, mitä tehtiin, mitä saatiin ja mikä meni väärin.
Kommentti — Ohjelmakoodi tai dokumentissa oleva teksti, joka selittää, mitä seuraava rivi tai osio tekee. Kommentit auttavat sinua ja muita ymmärtämään logiikan.
Mentori — Kokenut henkilö, joka ohjaa ja opastaa muita. Apuri-botti toimii mentorina, joka esittää oikeita kysymyksiä ja ohjaa käyttäjää eteenpäin.
Kalibrointi — Säätäminen oikealle tasolle. Esimerkiksi: ovatko botin kysymykset liian yksinkertaiset vai liian monimutkaiset? Kalibrointi paranee testaamalla.
Palaute — Käyttäjän arvio siitä, kuinka hyvin botti toimi. Palautetta käytetään botin kehittämiseen.
Käsitteet liittyvät toisiinsa. Hyvä järjestelmäprompti tukee hyödyllistä bottia, jota testataan, dokumentoidaan ja parannetaan iteratiivisesti.