Plan Mode Claude Codessa: vaiheittainen opas ja 4 vaihetta vuonna 2026

Lisäohjeita on Ailoot-dokumentaatiossa.

Mikä Plan Mode on, ja miksi se ei yksin riitä?#

Normaalitilassa Claude Code kirjoittaa koodin heti, ja jos et seuraa tekemistä, voit yllättäen saada diffin, joka ulottuu moniin tiedostoihin. Plan Mode kääntää vaiheet toisin päin: ensin tutkimus ja suunnittelu, sitten hyväksyntä ja vasta sen jälkeen muutokset.

Anthropic kuvaa Plan Modea virallisessa dokumentaatiossaan näin:

Tämä kuulostaa yksinkertaiselta, mutta siinä piilee tärkein muutos. Plan Mode muuttaa työn rytmiä: ensin sovitaan, sitten toimitaan. Kyse on toimintatilan muutoksesta, ei kosmeettisesta säädöstä. Vibe-koodaajien ongelmana on, että tekoälyagentit ryntäävät helposti tekemään. Jos pyydät normaalitilassa ”Lisää Google-tunnistautuminen”, Claude kirjoittaa koodin minuutissa, mutta puolet tiedostoista on vääriä. Plan Modessa sama pyyntö muuttuu tekstisuunnitelmaksi, jonka voit lukea kahdessa minuutissa ja korjata ennen kuin yhteenkään koodiin kosketaan.

Tässä on ansa, josta kansainvälisissä oppaissa ei puhuta. Plan Mode on yksinään heikko työkalu: suunnitelma on olemassa vain nykyisessä keskustelussa. Sulje ikkuna, niin suunnitelma katoaa. Et voi luovuttaa sitä toiselle agentille. Versioita tai historiaa ei ole. Jos tehtävä on suuri (30 tiedoston moduulin uudelleenjärjestely tai siirtyminen uuteen tietokantaan), suunnitelma saavuttaa nopeasti konteksti-ikkunan rajan ja alkaa heikentyä.

Siksi Plan Mode toimii hyvin yhdessä repositoriossa olevan plans/-kansion kanssa. Suunnitelma tallennetaan tiedostoon plans/2026-05-21-google-oauth.md, jaetaan vaiheisiin valintaruutuineen, ja seuraava agentti voi jatkaa siitä. Näin kontekstin suunnittelu toimii: kontekstia hallitaan ennen kehotetta, ei sen aikana.

Miten Plan Mode otetaan käyttöön Claude Codessa?#

Nopein tapa istunnon aikana on näppäinyhdistelmä:

Shift+Tab           # vaihtaa tilojen välillä: default → acceptEdits → plan

Kahden painalluksen jälkeen terminaalin alareunaan ilmestyy ilmaisin ⏸ plan mode on. Kolmas painallus palauttaa normaalitilan. Tämä on kätevin tapa: voit vaihtaa tilaa lennossa, kun huomaat tehtävän kasvavan.

Toinen tapa on lisätä yhden kehotteen eteen etuliite:

/plan write a plan to migrate the database from MySQL to Postgres

Tämä vaihtoehto on hyödyllinen, kun käytät automaattista hyväksyntätilaa etkä halua vaihtaa sitä koko istunnon ajaksi. Yksi pyyntö Plan Modessa, ja sen jälkeen työ jatkuu kuten ennen.

Kolmas tapa on ottaa tila käyttöön istuntoa käynnistettäessä:

claude --permission-mode plan

Käytä tätä, kun tiedät etukäteen, että tehtävä vaatii suunnittelua. Esimerkiksi ennen suurta uudelleenjärjestelyä tai migraatiota.

Neljäs tapa on asettaa oletustila projektin .claude/settings.json-tiedostossa:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Milloin tästä on hyötyä? Kun tiimi työskentelee monimutkaisen järjestelmän parissa, jossa mikä tahansa muutos voi vaikuttaa viereisiin moduuleihin. Silloin oletusarvoinen Plan Mode suojaa kaikkia tahattomilta muutoksilta.

Usein sivuutettu viides niksi: Ctrl+G avaa suunnitelman tekstieditorissa. Käytä sitä, kun suunnitelma on melkein oikea, mutta haluat muotoilla 2-3 kohtaa uudelleen tai lisätä rajauksen. Muokkaa sitä käsin ja tallenna, niin Claude jatkaa sinun versiollasi.

Mitkä ovat Anthropicin Plan Moden viralliset 4 vaihetta: Explore, Plan, Implement, Commit?#

Monissa oppaissa kuvataan kolme vaihetta (Explore-Plan-Execute) tai vain kaksi (Plan-Implement). Ne ovat yksinkertaistuksia. Virallisessa parhaiden käytäntöjen oppaassaan Anthropic kuvaa täsmälleen 4 vaihetta. Erolla on merkitystä: erillinen Commit-vaihe varmistaa, että kirjaat tuloksen etkä jätä sitä muotoon ”tein vielä muutaman säädön, commitoin myöhemmin” – joka on yleisin syy työn katoamiseen.

Mitä täsmällisempi suunnitelma, sitä vähemmän iteraatioita toteutus vaatii. Jos käytät suunnitelmaan 10 minuuttia, toteutus vie yhden kehotteen. Jos luonnostelet suunnitelman minuutissa, toteutus vaatii tunnin korjauksia.

Tältä 4 vaihetta näyttävät Google OAuthin lisäämisessä (esimerkki Anthropic Docsista):

Kehotteetkin eroavat vaiheittain. Explore-vaiheessa: ”lue /src/auth ja selvitä, miten käsittelemme istuntoja ja kirjautumista”. Plan-vaiheessa: ”Haluan lisätä Google OAuthin. Mitä tiedostoja pitää muuttaa? Laadi suunnitelma”. Implement-vaiheessa: ”toteuta OAuth-virta suunnitelmasi mukaan, kirjoita testit, suorita testikokonaisuus ja korjaa virheet”. Commit-vaiheessa: ”tee kuvailevalla viestillä commit ja avaa PR”.

Tärkeä tarkennus: Plan Mode ei estä Clauden komentojen suorittamista tutkimusta varten. Read, LS, Glob, Grep, web fetch ja tutkimiseen käytettävät shell-komennot ovat sallittuja. Vain Edit, Write ja kaikki tiedostojärjestelmää muuttavat toiminnot ovat kiellettyjä. Claude voi siis lukea projektin rakennetta, suorittaa git log -komennon ja tutkia testejä, mutta se ei voi vahingossa muuttaa mitään.

Miten luet Clauden suunnitelman ja päätät, hyväksytkö sen?#

Kun Claude on saanut suunnitelman valmiiksi, se näyttää vaihtoehdot jatkoa varten:

• Hyväksy ja aloita automaattitilassa
• Hyväksy ja salli muokkaukset
• Hyväksy ja tarkista jokainen muokkaus käsin
• Jatka suunnittelua antamalla palautetta
• Tarkenna Ultraplanilla (selaintarkistus)

Suunnitelman hyväksymisen arviointi on Plan Moden keskeinen taito. On helppo painaa automaattisesti ”Hyväksy” ja joutua sitten palauttamaan committeja. Tekoälyn mielistelijä haluaa antaa nopean vastauksen, ja sinä haluat päästä nopeammin koodiin. Molemmat ovat väärässä.

Hyvä suunnitelma täyttää 7 kriteeriä:

1. Täsmälliset tiedostonimet. Ei ”päivitän authin”, vaan ”muutan tiedostoa src/auth/login.ts:42-58, luon tiedoston src/auth/oauth-callback.ts ja päivitän tiedostoa src/auth/session.ts:103.”
2. Järjestys on määritelty. Suunnitelma jaetaan vaiheisiin tai askeliin sen sijaan, että siinä sanotaan ”teen tämän kaiken jossain vaiheessa”.
3. Ulkoiset riippuvuudet nimetään. Jos tehtävä vaatii uuden kirjaston, se mainitaan. Jos tarvitaan ympäristömuuttujia, ne mainitaan.
4. Riskit luetellaan. Hyvä suunnitelma sanoo: ”Migraatio voi rikkoa nykyiset istunnot; X on tarkistettava.” Huono suunnitelma ei mainitse sivuvaikutuksia.
5. Onnistumiskriteerit määritellään. ”test/auth-testit läpäisevät, lintteri ei löydä virheitä ja kehityspalvelin käynnistyy ilman virheitä.”
6. Suunnitelmassa ei ole hatusta vedettyjä oletuksia. Jos Claude sanoo ”Käytän kirjastoa Z”, tarkista, että olet asentanut sen projektiin. Jos tekoäly keksi sen, sitä ei löydy package.json-tiedostosta.
7. Suunnitelma mahtuu ruudulle. Jos yksinkertaisen ominaisuuden suunnitelma on 200 riviä, tehtävä on luultavasti liian suuri yhdelle suunnitelmalle. Jaa se osiin.

Jos suunnitelma ei läpäise tarkistusta, sinulla on kolme vaihtoehtoa:

• Jatka suunnittelua antamalla palautetta – anna Claude'lle täsmällinen kommentti siitä, mistä et pidä, niin se kirjoittaa suunnitelman uudelleen.
• Ctrl+G – avaa suunnitelma editorissa, muokkaa sitä käsin ja tallenna. Claude jatkaa sinun versiollasi.
• Tarkenna Ultraplanilla – suunnitelma siirtyy Claude Coden verkkoversion selaintilaan, jossa tarkistat osiot ja kommentoit niitä. Sitten suoritat suunnitelman paikallisesti tai pilvessä.

Jos jokin menee pieleen toteutuksen aikana, älä pakota sitä eteenpäin. Palaa Plan Modeen ja kirjoita suunnitelma uusiksi. Se on 10 kertaa halvempaa kuin 40 commitin palauttaminen myöhemmin.

Plan Mode + plans/-kansio: yhdistelmä pitkää kontekstia varten#

Plan Mode on Claude Coden toimintatila. plans/-kansio on sen päälle rakennettu menetelmä. Jos käytät Plan Modea ilman kansiota, saavutat rajan tunnin työn jälkeen.

Tämä perustuu seuraavaan. Clauden konteksti-ikkuna on istunnon muisti. Opus 4.7:ssä siihen mahtuu miljoona tokenia, mutta määrä koskee koko keskustelua. Jos suunnittelet monimutkaisen tehtävän yhdessä keskustelussa, pyydät sitten toteuttamaan sen, keskustelet virheestä ja vielä jostain muusta, ikkuna ”paisuu”. Claude alkaa unohtaa varhaisia päätöksiä, sekoittaa konteksteja ja esittää kysymyksiä uudelleen.

Ratkaisu on kultainen sääntö: yksi tehtävä – yksi keskustelu.

Toimi näin:

1. Keskustelu 1 – laadi suunnitelma. Ota Plan Mode käyttöön, kuvaa tehtävä, ja Claude laatii suunnitelman. Tallenna se tiedostoon plans/2026-05-21-feature-name.md. Sulje ikkuna.
2. Keskustelu 2 – jaa suunnitelma vaiheisiin. Avaa uusi keskustelu. Pyydä: ”avaa plans/2026-05-21-feature-name.md ja jaa se vaiheisiin”. Tallenna päivitetty tiedosto.
3. Keskustelu 3 – toteuta vaihe 1. Avaa uusi keskustelu. Pyydä: ”toteuta tiedoston plans/2026-05-21-feature-name.md vaihe 1 ja merkitse kohdat valmiiksi sitä mukaa kun saat ne tehtyä”. Sulje ikkuna.
4. Keskustelu 4 – toteuta vaihe 2. Toimi samoin.

Mitä tämä antaa sinulle? Jokaisen keskustelun konteksti-ikkuna pysyy tuoreena. Vaiheessa 3 Claude ei tiedä vaiheen 1 yksityiskohtia, mutta se tuntee suunnitelman, koska plans/-tiedosto on repositoriossa. Jokainen seuraava agentti (olipa se aliagentti, uusi istunto tai /goal-ajo) voi jatkaa suunnitelmasta.

Lähestymistapojen vertailu:

Jokaisella ominaisuudella on oma suunnitelmatiedostonsa. Kun sinun pitää kolmen kuukauden päästä muistaa, miksi valitsit tietyn maksupalvelun toisen sijaan, voit avata sopivan suunnitelman ja lukea päätöshistorian: mitä käsiteltiin, mitä vaihtoehtoja harkittiin ja miksi päädyttiin tähän ratkaisuun.

Nämä ovat eläviä työsuunnitelmia; staattinen dokumentaatio vanhenee muutamassa kuukaudessa.

Miten saat Clauden työskentelemään nukkuessasi Plan Moden ja /goal-komennon avulla?#

Pitkien tekoälyistuntojen suurin rajoite ei ole malli itse vaan henkilö, joka painaa Enteriä. Aina kun Claude pääsee vuoron loppuun, se odottaa vastaustasi. /goal poistaa tämän odotuksen.

Syntaksi on yksinkertainen:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

Ehto voi olla enintään 4000 merkkiä pitkä. Istuntoa kohden voi olla yksi tavoite. Jokaisen vuoron jälkeen Haiku-minimalli lukee keskustelun ja päättää: ”ehto täyttyy – lopeta” tai ”ei täyty – seuraava vuoro”. Arvioija ei kutsu työkaluja, vaan ainoastaan lukee.

Komennon voi tyhjentää aliaksilla: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Yhdistelmä Plan Moden kanssa toimii näin:

1. Ota Plan Mode käyttöön (paina Shift+Tab kahdesti).
2. Pyydä: ”laadi suunnitelma tietokannan siirtämiseksi MySQL:stä Postgresiin ja tallenna se tiedostoon plans/2026-05-21-postgres-migration.md vaiheineen ja kriteereineen”.
3. Tarkista suunnitelma, muokkaa sitä ja hyväksy se.
4. Poistu Plan Modesta (paina Shift+Tab vielä kerran).
5. Aseta tavoite: ”toteuta kaikki tiedoston plans/2026-05-21-postgres-migration.md vaiheet, merkitse ruudut, kaikki testit läpäisevät tai pysähdy 50 vuoron jälkeen”.
6. Sulje kannettava ja mene nukkumaan.

Tarkista tulos aamulla: joko ”✓ tavoite saavutettu” tai ”◎ pysähdyttiin 50 vuoron jälkeen”, ja mukana on historia tehdystä työstä.

/goal-komentoa varten on kolme olennaista sääntöä, joiden sivuuttaminen tuhlaa tokeneita:

Sääntö 1: Mitattavissa oleva lopputila. ”Tee siitä hienon näköinen” on huono ehto. ”npm test palauttaa 0, npm run lint palauttaa 0 ja CHANGELOG.md-tiedostoon on lisätty merkintä” on hyvä.

Sääntö 2: Nimenomainen tarkistus. Ehdon pitää viitata johonkin tarkistettavissa olevaan: komentoon, tiedostoon tai endpointiin. Ei ”kaikki toimii”, vaan ”curl localhost:3000/api/users palauttaa 200”.

Sääntö 3: Rajoita vuorojen määrä. Lisää aina or stop after N turns. Anthropic suosittelee dokumentaatiossaan nimenomaisesti:

Jos otat /goal-komennon käyttöön ilman or stop after -rajaa, budjettisi voi huveta yön aikana.

Millainen 4-vaiheinen sykli muuttaa Plan Moden suunnitteluprosessiksi?#

Yleinen virhe on kysyä ”miten korjaan tämän?”: Claude ehdottaa ratkaisua, toteutat sen, mutta mikään ei toimi tai tilanne pahenee. Tätä kutsutaan ”tekoälyn mielistelyksi”: se on koulutettu vastaamaan nopeasti, ja sinä haluat päästä koodiin nopeammin. Nelivaiheinen sykli ratkaisee ongelman.

Nelivaiheinen sykli estää tämän toimintatavan. Se käydään läpi järjestyksessä yhden Plan Mode -istunnon aikana:

Vaihe 1. Selvitä faktat ilman ratkaisua.

Kehote: ”Kohtaan seuraavan ongelman: [oireen kuvaus]. Tehtävänäsi on nyt selvittää faktat. Kaikki ratkaisut, ideat ja neuvot ovat kiellettyjä. Ainoastaan: mitä havaitsen, mitkä vaiheet voi toistaa, mitä tietoja on saatavilla ja mitä puuttuu. Ehdoton pysäytysehto: ÄLÄ ehdota ratkaisuja; kirjaa vain diagnoosi.”

Tämä estää tekoälyn ensimmäisen impulssin: ”tässä on ratkaisu”. Clauden on pysähdyttävä siihen, ”mikä on tiedossa ja mikä ei”.

Vaihe 2. Kehitä vaihtoehtoja aiempien esimerkkien avulla.

Kehote: ”Nyt kun diagnoosi on selvitetty, etsi verkosta esimerkkejä samankaltaisten ongelmien ratkaisemisesta. Vähintään 3 erilaista lähestymistapaa. Kustakin: linkki ensisijaiseen lähteeseen, lyhyt kuvaus sekä hyvät ja huonot puolet meidän tilanteessamme.”

Tämä estää tekoälyn toisen impulssin: ”keksi ratkaisu omasta päästäsi”. Ohjaamme sen etsimään maailmalta lähestymistapoja, jotka voidaan tarkistaa.

Vaihe 3. Yksityiskohtainen suunnitelma riskeineen.

Kehote: ”Valitse vaiheen 2 paras vaihtoehto ja laadi yksityiskohtainen suunnitelma: mitä täsmällisiä tiedostoja kosketaan, mitä lisätään ja poistetaan, mitä testejä kirjoitetaan, mikä voi rikkoutua ja mitä riskejä on 2-3 askeleen päässä.”

Tämä on tuttu Plan-vaihe, mutta yhdellä erolla: se perustuu vaiheen 2 varmennettuihin vaihtoehtoihin eikä Clauden arvauksiin.

Vaihe 4. Arvioi suunnitelma itse.

Kehote: ”Tee nyt pakollinen itsearviointi. Tarkista suunnitelmasi rehellisesti uudelleen: onko siinä kohtia, joissa olet keksinyt jotain tyhjästä tarkistamatta sitä koodista, dokumentaatiosta tai vaiheen 2 aiemmista esimerkeistä? Jos on, merkitse ne ja korjaa suunnitelma.”

Tämä on viimeinen suodatin. Clauden on tarkistettava oma päättelynsä ja myönnettävä, missä se hallusinoi. Tässä vaiheessa vähintään 2 suunnitelman kohtaa yleensä muuttuu.

Neljän vaiheen jälkeen suunnitelma on valmis hyväksyttäväksi. Siirryt toteutukseen luottaen siihen, että tehtävä on ymmärretty, vaihtoehdot punnittu ja riskit huomioitu.

Tämä menetelmä on tarkoitettu vaikeiden virheiden selvittämiseen ja arkkitehtuuripäätöksiin, joissa virheen hinta on korkea. Plan Modeen sovellettuna se poistaa vibe-koodaajien suurimman ongelman: ”tekoäly ehdotti ratkaisua, toteutin sen ja kaikki hajosi”.

Mitkä 5 valmista kehotetta toimivat yleisissä Plan Mode -tehtävissä?#

Pohja 1. Moduulin uudelleenjärjestely.

Otan Plan Moden käyttöön. Tehtävä: järjestele {module-name}-moduuli uudelleen.

Vaihe 1: Tutki {module-path}-moduulin nykyinen rakenne. Kuvaile:
- mitkä tiedostot kuuluvat moduuliin
- mitä ulkoisia riippuvuuksia sillä on
- mitkä osat ovat päällekkäisiä
- mitkä funktiot ovat liian monimutkaisia

Vaihe 2: Etsi verkosta 2-3 esimerkkiä samankaltaisten moduulien uudelleenjärjestelystä.
Vähintään yhden lähteen on oltava virallinen Anthropic- tai siihen liittyvän ohjelmistokehyksen dokumentaatio.

Vaihe 3: Laadi uudelleenjärjestelysuunnitelma tiedostoon plans/YYYY-MM-DD-refactor-{module}.md:
- mitkä tiedostot nimetään uudelleen
- mitkä funktiot erotetaan omiin moduuleihinsa
- mitkä testit pidetään ja mitkä kirjoitetaan uudelleen
- riskit: mikä voi rikkoutua käyttäjillä

Vaihe 4: Arvioi suunnitelma itse. Sisältääkö se hatusta vedettyjä oletuksia?
Kirjoita ne uudelleen tai poista ne.

Pohja 2. Tietokantamigraatio.

Otan Plan Moden käyttöön. Tehtävä: siirrä tietokanta järjestelmästä {old} järjestelmään {new}.

Vaihe 1: Tutki tietokannan nykyistä skeemaa komennolla {schema-reading-command}. Kuvaile:
- mitä tauluja on ja kuinka suuria ne ovat
- mitä suhteita, indeksejä ja rajoitteita niihin liittyy
- minne migraatiot tallennetaan
- mitkä tiedot ovat kriittisiä

Vaihe 2: Etsi tuotantoprojekteista esimerkkejä migraatioista {old → new}.
Vähintään 3 erilaista lähestymistapaa: pg_dump, dual-write, blue-green.
Luettele kunkin hyödyt ja riskit meidän tietomäärällemme.

Vaihe 3: Laadi migraatiosuunnitelma tiedostoon plans/YYYY-MM-DD-db-migration.md:
- vaiheet (varmuuskopiointi, migraatio, tarkistus, siirtyminen)
- kunkin vaiheen onnistumiskriteerit
- palautussuunnitelma ongelmatilanteen varalle
- seisokki tai ei seisokkia

Vaihe 4: Arvioi suunnitelma itse. Perustuvatko kaikki luvut dokumentaatioon?
Onko kaikki vaiheet käyty mielessä läpi kehitysympäristön näkökulmasta?

Pohja 3. Uuden ominaisuuden lisääminen.

Otan Plan Moden käyttöön. Tehtävä: lisää projektiin {description}-ominaisuus.

Vaihe 1: Tutki, miten samankaltaiset ominaisuudet toimivat projektissa nyt.
Tarkastele erityisesti:
- {file-1}
- {file-2}
- käytössä olevat arkkitehtuurimallit
- samankaltaisille ominaisuuksille kirjoitetut testit

Vaihe 2: Selvitä, miten ominaisuus on toteutettu avoimen lähdekoodin projekteissa,
joissa on samankaltainen arkkitehtuuri. Vähintään 2 erilaista lähestymistapaa.

Vaihe 3: Laadi suunnitelma tiedostoon plans/YYYY-MM-DD-feature-{name}.md:
- luettelo uusista tiedostoista
- luettelo muutettavista tiedostoista ja täsmälliset rivit
- toteutusjärjestys
- lisättävät testit
- CLAUDE.md-tiedostoon lisättävä sääntö myöhempiä istuntoja varten

Vaihe 4: Arvioi suunnitelma itse. Noudattaako se projektin arkkitehtuuria?
Olettaa­ko se sellaisia kirjastoja, joita ei ole asennettu?

Pohja 4. Testien kirjoittaminen.

Otan Plan Moden käyttöön. Tehtävä: kata {name}-moduuli testeillä.

Vaihe 1: Tutki {path}-moduulia. Selvitä:
- julkiset funktiot ja niiden allekirjoitukset
- sisäiset funktiot, joita emme testaa (toteutuksen yksityiskohdat)
- reunatapaukset: tyhjä syöte, virheet, rinnakkainen käyttö

Vaihe 2: Etsi suositun avoimen lähdekoodin projektin testiesimerkkejä
samankaltaiselle tehtävätyypille ja samalla ohjelmistokehyksellä.

Vaihe 3: Laadi testisuunnitelma tiedostoon plans/YYYY-MM-DD-tests-{module}.md:
- testit jokaiselle julkiselle funktiolle
- tarvittavat mockit
- tarvittavat fixturet
- tarkistustapa (assertion-tyyli)

Vaihe 4: Arvioi suunnitelma itse. Tarkistavatko kaikki testit toimintaa toteutuksen sijaan?
Kattavatko testit reunatapaukset?

Pohja 5. Monimutkaisen virheen selvittäminen.

Otan Plan Moden käyttöön. Tehtävä: selvitä virheen {symptom-description} syy.

Vaihe 1: SELVITÄ FAKTAT. Ratkaisut ja ideat ovat kiellettyjä. Ainoastaan:
- mitä havaitsen (virheen täsmällinen sanamuoto)
- toistettavat vaiheet
- mitä tietoja on saatavilla (lokit, jäljet, kirjastoversiot)
- mitä tietoja puuttuu (mitä pitää kerätä lisää)

Vaihe 2: Etsi esimerkkejä tästä virheestä.
Vähintään 3 lähdettä: GitHub-ongelmat ja dokumentaatio.
Anna kustakin linkki ja lyhyt yhteenveto ratkaisusta.

Vaihe 3: Laadi diagnostiikkasuunnitelma tiedostoon plans/YYYY-MM-DD-bug-{name}.md:
- tarkistettavat hypoteesit todennäköisyysjärjestyksessä
- kunkin tarkistukseen suoritettavat komennot/skriptit
- kunkin tarkistuksen odotettu tulos

Vaihe 4: Arvioi suunnitelma itse. Onko siinä hatusta vedettyjä hypoteeseja?
Perustuvatko kaikki hypoteesit vaiheen 1 faktoihin?

Kopioi pohja, korvaa {parameters} omilla arvoillasi ja liitä se Claude Codeen Plan Modessa. Tuloksena saat plans/-kansioon toimivan suunnitelman, jonka voit hyväksyä ja toteuttaa.

Plan Mode vai normaalitila: kumman valitset?#

Anthropic sanoo tämän suoraan dokumentaatiossaan:

Ohita erillinen suunnitelma vain todellisen diffin ollessa pieni, ymmärretty ja vähäriskinen. Suunnittele, kun lähestymistapa pitää selvittää tai riskisiä muutoksia koordinoida komponenttien välillä. Tiedostonimien tunteminen tai tavoitteen tiivistäminen yhteen virkkeeseen ei poista migraation, tunnistautumisen tai datan eheyden riskejä.

Päätöstaulukko:

Kysy ennen tilan valintaa, ymmärretäänkö lähestymistapa, sivuvaikutukset ja todentaminen. Tee suoraan pieni paikallinen vähäriskinen muutos, jonka tarkistus on selvä. Suunnittele ensin epävarmuus, vieras koodi, migraatio, tunnistautuminen tai komponenttien koordinointi, vaikka osaisit jo nimetä kaikki 3–5 muuttuvaa tiedostoa.

Miten yhdistät Plan Moden, CLAUDE.md:n ja aliagentit luotettavaa työtä varten?#

CLAUDE.md on tiedosto, jonka Claude lukee jokaisen istunnon alussa, myös Plan Modessa. Jos CLAUDE.md sanoo ”älä koskaan kirjoita päivämääriä suoraan koodiin; hae ne aina tietokannasta”, suunnitelmassa ei koskaan ehdoteta päivämäärän kirjoittamista suoraan koodiin. Jos tällaista sääntöä ei ole, suunnitelmassa voidaan ehdottaa mitä tahansa.

Yhdistelmä toimii näin:

Taso 1. CLAUDE.md määrittää säännöt.

Tiedostossa määritellään projektin teknologiat, arkkitehtuuriperiaatteet, kiellot (”älä käytä vanhentuneita rajapintoja”) ja vaatimukset (”kaikki sähköpostit lähetetään yhteisen pohjan kautta”). Lue yksityiskohtainen opas: CLAUDE.md:n määrittäminen.

Taso 2. Plan Mode soveltaa sääntöjä tehtävään.

Kun otat Plan Moden käyttöön ja pyydät ”lisää OAuth”, Claude lukee CLAUDE.md:n, näkee säännöt (”tallenna tokenit Redisiin, älä tietokantaan”) ja huomioi ne heti suunnitelmassa. Suunnitelma noudattaa projektin arkkitehtuuria.

Taso 3. Aliagentit jakavat työn.

Jos suunnitelma on jaettu vaiheisiin, kunkin vaiheen voi antaa erilliselle aliagentille. Jokainen aliagentti työskentelee omassa konteksti-ikkunassaan kuormittamatta pääikkunaa. plans/-kansion suunnitelma pysyy yhteisenä totuutena: aliagentit lukevat sen, toteuttavat oman vaiheensa ja päivittävät valintaruudut.

Mitkä 7 virhettä rikkovat Plan Moden?#

Virhe 1. Suunnitelma on olemassa vain keskustelussa.

Oire: kirjoitit suunnitelman, suljit ikkunan ja sinun pitäisi palata siihen seuraavana päivänä, mutta mitään ei ole jäljellä – konteksti on poissa. Ratkaisu: tallenna suunnitelma aina repositorion tiedostoon plans/YYYY-MM-DD-feature-name.md. Keskustelu on työpöytä; tiedosto on arkisto.

Virhe 2. Kaikki tehtävät ovat samassa keskustelussa.

Oire: käsittelet yhdessä istunnossa authia, sitten migraatiota, sitten käyttöliittymäsuunnittelua ja lopuksi virhettä. Konteksti-ikkuna ”paisuu”, ja Claude unohtaa aiempia asioita. Ratkaisu: yksi tehtävä – yksi keskustelu. Saitko suunnitelman valmiiksi? Sulje ikkuna. Aloitatko toteutusta? Avaa uusi.

Virhe 3. Yksi 3000-rivinen suunnitelma ilman vaiheita.

Oire: suunnitelma on olemassa, mutta siinä ei ole valintaruutuja tai jaottelua. Mahdoton tietää, mikä on tehty ja mikä ei. Delegointi ei onnistu. Ratkaisu: jaa suunnitelma 3-7 vaiheeseen. Jokaisessa vaiheessa on valintaruudullinen luettelo täsmällisistä toimista.

Virhe 4. Syvällinen tutkimus puuttuu suunnitelman edeltä.

Oire: Claude ehdottaa ratkaisua omasta päästään, koska et pyytänyt etsimään aiempia esimerkkejä. Viikkoa myöhemmin huomaat, että avoimen lähdekoodin maailmassa on ollut jo kauan parempi lähestymistapa. Ratkaisu: nelivaiheisen syklin vaihe 2 – pyydä Claudea etsimään verkosta 2-3 aiempaa esimerkkiä ennen suunnitelman laatimista.

Virhe 5. Tekoälyn mielistelijä ehdottaa ratkaisua ilman diagnoosia.

Oire: kysyt ”miten korjaan virheen X?”, Claude ehdottaa ratkaisua, toteutat sen, mutta mikään ei toimi tai tilanne pahenee. Ratkaisu: aloita aina pyytämällä ”selvitä faktat; ratkaisut ovat kiellettyjä”. Siirry vaihtoehtoihin vasta diagnoosin jälkeen.

Virhe 6. Itsearvioinnin sivuuttaminen.

Oire: suunnitelma näyttää uskottavalta, mutta sisältää 2-3 hatusta vedettyä oletusta (keksitty kirjasto, olematon rajapinta tai väärä versio). Toteutus hajoaa näissä kohdissa. Ratkaisu: nelivaiheisen syklin vaihe 4 – pyydä Claudea tarkistamaan suunnitelmansa rehellisesti uudelleen ja merkitsemään oletukset.

Virhe 7. Epämääräiset ehdot /goal-komennossa.

Oire: asetat tavoitteeksi /goal tee siitä hienon näköinen, jätät sen yöksi käyntiin ja heräät huomaamaan, että $200:n kiintiö on kulunut. Ratkaisu: käytä vain mitattavissa olevia ehtoja, tarkistuskomentoa ja pakollista ehtoa or stop after N turns. Ei ”tee siitä hyvä” tai ”viimeistele sitä”.

Kahdeksas virhe, jonka vibe-koodaajat tekevät useimmiten, on plans/-kansion koko ajatuksen sivuuttaminen. Plan Mode ilman plans/-kansiota ei ole menetelmä vaan lelu. Jos käytät Plan Modea mutta et luo tiedostoja, saat käyttöön 10 % sen ominaisuuksista.

Mitä kannattaa tehdä ensimmäisen Plan Mode -kokemuksen jälkeen?#

Kolme konkreettista askelta vaikeusjärjestyksessä:

Vaihe 1. Määritä CLAUDE.md, jos sitä ei vielä ole.

Ilman CLAUDE.md:tä Plan Mode toimii ”tyhjiössä”: Claude ei tunne projektin sääntöjä ja ehdottaa arkkitehtuurin rikkovia suunnitelmia. Lue koko opas: CLAUDE.md:n määrittäminen. Vähimmäisversiossa on 50-80 riviä teknologioista, säännöistä ja kielloista. Pituus on toissijaista. Täsmällisyys ratkaisee.

Vaihe 2. Luo repositorioon plans/-kansio.

Lisää plans/ projektin juureen. Sopikaa nimeämistavaksi YYYY-MM-DD-feature-name.md. Jokainen suunnitelma saa oman tiedostonsa. Kuukauden kuluttua tiedostoja on 20-30 ja kuuden kuukauden kuluttua yli 100. Näin syntyy projektin elävä päätöshistoria.

Vaihe 3. Kokeile /goal-komentoa yhdessä tehtävässä.

Valitse tehtävä, jonka tekisit tavallisesti käsin 30-40 minuutissa. Ota Plan Mode käyttöön, laadi suunnitelma ja tallenna se plans/-kansioon. Poistu Plan Modesta. Aseta /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. Sulje kannettava tunniksi ja tee jotakin muuta. Palaa tarkistamaan tulos.

Nämä kolme askelta ovat vähimmäistaso. Tätä rakennetaan vähitellen; älä yritä saada kaikkea valmiiksi yhtenä iltana. Aloita CLAUDE.md:stä, lisää plans/ viikon kuluttua ja kokeile /goal-komentoa yön yli kuukauden päästä.

Kun olet valmis, tutustu Ailootiin.