Fitness Coach Bot — Isiklik toode, mis vaatab end ise üle

Probleem

Iga jõusaali treening algab samade kolme küsimusega: mida ma täna teen, mida ma tegin viimati ja kuidas see nädal kvartali alguses seatud eesmärgi suhtes kulgeb. Ükski neist küsimustest ei saa jõusaali põrandal seeriate vahel seistes piisavalt tähelepanu, et neile hästi vastata. Tavapärased alternatiivid — tabelarvutus, märkmerakendus, üks paljudest kommertsfitnessrakendustest — kannavad kõik sama probleemi erinevatel kujudel: kas nad nõuavad, et kasutaja oleks ise ajuks (sisestades plaane, jälgides ajalugu, hinnates edusamme), või genereerivad plaane, mis ei mäleta eilset treeningut, eelmise kuu vigastust ega selle kvartali eesmärki.

Esimene katse selle lahendamiseks kasutas Claude'i mobiilirakendust otse koos kleebitud süsteemiprompti ja käsitsi peetava seansilogiga. Kaks tegelikku treeningut tõid esile piirid — seansside vahel polnud püsivat mälu, kasutajaspetsiifiliste reeglite jõustamist polnud (eriti isikliku vigastuse piirang, mis peab teatud harjutused välistama), ei olnud võimalik vastu võtta kantava seadme ekraanipilti ja sealt südametegevuse andmeid välja võtta, ei olnud ajastatud meeldetuletusi ning puudus mõõdetav hinnang, kas boti plaan üldse hea on.

Eesmärk: süsteem, mis kannatab välja jõusaali (mobiilipõhine), mäletab profiili, eesmärke ja ajalugu, võtab kantava seadme ekraanipilte visuaalse sisendina, saadab ajastatud motiveerivaid sõnumeid ning — eristavalt — sisaldab eneseülevaate tsüklit, kus iga päeva seansse hindab vanem-treeneri tasemel ülevaataja, kes pakub boti enda käitumiseks konkreetseid parandusi.

Tehisintellekti lähenemine

Kogu süsteem on ehitatud Claude Code'i abil paljude lühikeste seansside jooksul umbes viie nädala vältel. Arendusmuster on oluline: see oli iteratiivne isiklik toode, mitte piiratud ulatusega projekt. Arhitektuur kujunes välja tegelike treeningute hõõrduspunktidest, mitte etteantud disainidokumendist.

Claude Code'i poolt valitud arhitektuur (operaatori ülevaatusega):

• —Telegrami Bot API — valitud, sest bott on igast telefonist täielikult kasutatav hetkel, kui kasutaja vestluse alustab, ilma rakenduspoest jaotamiseta ja ilma kliendirakenduse hooldamiseta
• —Vercel serverless funktsioonid — api/webhook.ts (sissetulevad Telegrami sõnumid), api/notify.ts (ajastatud väljaminevad), api/setup.ts (ühekordne konfiguratsioon)
• —Supabase Postgres — skeem profiili, eesmärkide, treeningute, vestluste, vigade ja ootel-kontrollide jaoks; viis migratsiooni arenes funktsioonide lisamisega
• —Claude API Opus 4.6-l (1M kontekst) vastuste genereerimiseks, koos nägemisvõimega kantava seadme ekraanipiltide jaoks
• —Vitest testikomplekt — 41 testi, mis katavad puhtad funktsioonid prompti koostamiseks, vigastusepiiranguteks, JSON-i eraldamiseks ja veebihooki sisendpunkti
• —Igapäevane eneseülevaate oskus (.claude/scheduled-tasks/fitness-bot-review/), mis töötab iga päev iseseisvalt, vaatab läbi eelmise 24 tunni seansid reeglirikkumiste, plaani kvaliteedi ja andmebaasi kirjutamise terviklikkuse osas ning kirjutab oma leiud markdown-aruandena projekti repositooriumi

Olulised disainiotsused:

• —Algas Claude'i mobiilirakenduses, et valideerida vestluslik disain kahe tegeliku treeninguga enne, kui ühtki rida koodi kirjutati. Nendest kahest treeningust saadud avastused (vajadus püsivuse, nägemise, ajastatud meeldetuletuste ja hindamise järele) kujundasid arhitektuuri, mitte vastupidi.
• —Claude Opus 4.6 valiti vastuste genereerimiseks pärast seda, kui Sonneti toon hälbis süsteemiprompti emoji- ja markdown-keelust. Umbes 5× kõrgem kulu vastuse kohta on tähtsusetu, arvestades isikliku toote madalat sõnumimahtu.
• —Aktiivse seansi väline vabateksti sõnumite jaoks loodi nutikas kavatsuse marsruuter — see liigitab sõnumi treeninguks / kontrolliks / juhuslikuks küsimuseks ja suunab vastavalt. Asendab varasema umbtee, kus bott vastas "puudub aktiivne seanss" igale ootamatule sõnumile.
• —Mitme kasutaja andmemudel päevast esimest — kasutaja on iga Supabase'i tabeli võtmes, kuigi täna on ainult üks kasutaja kirjas. Lisanduv skeemikulu on väike; teisele kasutajale boti hilisem avamine ei nõua migratsiooni.

Mida ei automatiseeritud:

• —Telegrami boti loomine ja tokeni väljastamine.
• —Vercel projekti seadistamine ja domeeni sidumine.
• —Tegelikud treeningud — iga tagasiside signaali allikas, mis toodet kujundas.
• —Igapäevaste ülevaadete lugemine ja triaaž. Bott kirjutab endast ülevaateid; operaator loeb iga ühte ja otsustab, milliseid leide parandustena tagasi anda.

Inimtöö

See on koht, kus iteratiivse toote olemus loeb ausa arvepidamise jaoks. Aktiivset tegevust oli kokku umbes 40 tundi, kuid see oli jagatud ligi viie kalendrinädala peale paljudes lühikestes pursetes — vahel kümneminutiline parandus pärast seda, kui tegelik treening tõi vea esile, vahel pikemad arhitektuursed seansid, kui igapäevane ülevaade tõi pinnale teatud klassi probleeme.

Aktiivse töö jaotus:

77 kasutaja käsku põhiseansi raames. Neist 15 sisaldasid lõksu-märksõnu (paranda / vale / katki / viga). Selline tihedus on palju kõrgem kui piiratud ehituseprojektil — iseloomulik mitmenädalasele tootele, kus iga reaalne kasutus toob esile uusi probleeme.

Traditsiooniline võrdlusalus

Selle ulatusega Telegrami botti tehisintellekti abita ehitamine nõuaks ühte arendajat, kes on kogu virnas mugav:

Keskmise hinnangu järgi: ~120 tundi 8 nädala jooksul.

Kiirendustegur

3-kordne töömahu kiirendus on Revalia Homesi 27× ulatusega võrreldes tagasihoidlikum ja põhjus on struktuurne. See oli iteratiivne toode, mitte piiratud ulatusega projekt. Enamus aega ei kulunud koodi genereerimisele — see kulus tegelikule tagasisidele reageerimisele. Igapäevased ülevaated püüdsid reeglirikkumisi. Tegelikud treeningud tõid esile UX-i umbtee. Jõusaali stiilis lühendid, mida bott ei tundnud ära, nõudsid uusi parseri juhtumeid. Tehisintellekt kiirendab koodi genereerimist; ta ei kõrvalda olemuslikku ajakulu mustri "kasuta seda kaks nädalat, vaata mis on valesti, paranda, korda". See kulu on hea asja ehitamise hind.

Huvitav mõõdik ei ole üldse kiirendustegur. See on eneseülevaate tsükkel: kui palju vigu püüdis igapäevase ülevaate oskus, mida operaator oleks muidu lihtsalt välja kannatanud. Otsese loendamise põhjal mitu — sealhulgas üks päev, kus ainult kardio-seanss lõpetati, aga andmebaasi ei kirjutatud, mis oleks ilma selle kontrollita võinud "töötada" lõputult.

Kvaliteedi hindamine

Bott on tootmises, on olnud kasutuses tegelike treeningute jaoks mitu nädalat ja on üle elanud mitu tagasiside tsüklit, kus probleeme püüdis igapäevase ülevaate oskus enne, kui operaator ise märkas.

Mis vastas tootmistasemele:

• —41-testiline Vitest komplekt läbib. Puhaste funktsioonide kate treeneri prompti koostamiseks, vigastuse piiramiseks, JSON-i eraldamiseks.
• —Eneseülevaate tsükkel on päris. Iga päev vaadatakse boti eelmise päeva väljundit treeneri-kvaliteediga ülevaataja poolt üle, ja ülevaatefail kantakse repositooriumisse.
• —Nägemise voog tuleb toime tegelike kantava seadme ekraanipiltidega ja eraldab südametegevuse andmeid kasutamiseks piisavalt usaldusväärselt.
• —Nutikas kavatsuse marsruuter asendas umbtee-UX-i liigitajaga, mis tuleb toime aktiivse seansi välise vabatekstiga.
• —Mitme kasutaja andmemudel tähendab, et boti saab teisele kasutajale avada ilma skeemi ümberkirjutamiseta.
• —Vastuse toon on järjepidevalt lihttekst — emojide ja markdownita — nagu süsteemiprompt nõuab, pärast seda kui see reegel viidi "soovituse" tasemelt jõustatud tasemele.

Mida vanem-treener mõõdupuus tarkvaraga teeks paremini:

• —Periodiseerimine mitme kuu treeningplokkide vahel. Praegune realisatsioon käsitleb kvartaali eesmärke, kuid ei varieeri ploki nädalate intensiivsust.
• —Taastumisteadlik programmeerimine subjektiivse heaolu hinnangute põhjal, mis ulatuks ühest õhtusest kontrollist kaugemale.
• —Harjutuste asendamine kureeritud raamatukogust, mitte tuginedes Claude'ile, kes seansi ajal alternatiive pakub.

Avatud kvaliteediküsimused:

• —Muutuv seansi pikkus on hiljutine lisand; vajab rohkem tegelike treeningute andmeid valideerimiseks eesmärgi edenemise suhtes.
• —Õhtune kontrolli voog ("kas täna oli midagi peale spordi, mis tekitas füüsilist stressi") on hiljutine; promptide häälestamine, et see tunduks sõbraliku küsimusena ja mitte ülekuulamisena, on käimas.

Lõksud ja piirangud

Igal projektil on hõõrdumist. Selle ausalt dokumenteerimine on selle raamistiku mõte.

1. Avasõnum rikkus oma enda reeglit. Süsteemiprompt ütles selgelt: ei mingit markdownit, ei mingeid emojisid. Iga plaani esimene sõnum — kõige kõrgemate panustega sõnum, sest see paneb paika treeningu — ignoreeris seda ja kasutas rasvast teksti ning tabeleid. Esimene igapäevane ülevaade püüdis selle kohe kinni. Parandus oli lihtne; õppetund on, et isiklikus tootes on esimene sõnum kõige halvem koht ebaõnnestumiseks, sest see on kasutaja esmamulje igal üksikul treeningul.

2. Reegli jaotus: kood vs. süsteemiprompt. Mõned kasutajaspetsiifilised piirangud (vigastuse välistamise nimekiri) olid koodis maetud; teised olid süsteemipromptis. Kui ülevaade püüdis kinni boti, mis soovitas piirangut rikkuvat harjutust, tuli parandus teha mõlemas kohas. Lõplik otsus oli viia kasutajaspetsiifilised reeglid kasutaja-andmetesse, nii et prompt on üldine ja piirangud on käivitusaegne konfiguratsioon. See on õige muster mitme kasutaja jaoks valmis tootele.

3. Igapäevane ülevaade püüdis kinni: null treeningut salvestatud. Aprilli keskpaiga ühel ainult-kardio päeval bott lõpetas seansi, aga ei kirjutanud treeningut andmebaasi. Avastatud ainult igapäevase ülevaate andmebaasi-terviklikkuse kontrolli poolt. Ilma selle kontrollita oleks bott näinud välja töötavana, kaotades andmeid vaikselt teadmata mitu nädalat. Eneserevisjon ei ole isikuandmeid käsitleva toote jaoks valikuline.

4. "Puudub aktiivne seanss" umbtee. Esimesed nädalad vastas bott "puudub aktiivne seanss" igale seansi-akna välisele vabatekstile. Päris-elu test: ootamatud sõnumid said midagi kasutut. Asendatud nutika kavatsuse marsruuteriga, mis liigitab sõnumi ja kas suunab selle õigele käsitlejale või küsib täpsustavat küsimust.

5. Päris isikuandmed tootmises raskendavad testimist. Päris fitness-andmed elavad samas andmebaasis, kuhu bott kirjutab. Muudatuste testimine tähendas kas operaatori enda treeninguajaloo saastamist või destruktiivsete migratsioonide riskimist. Lahendatud kuiva-jooksu režiimi ja eraldi testkasutaja fikseeringu lisamisega, kuid kiusatus "lihtsalt juurutada ja vaadata" tuli sõnaselgelt vastu seista.

6. Konteksti kulu. Iteratiivse toote vahemälu-raske muster on õige — see amortiseerib süsteemiprompti seansside vahel — kuid viie nädala absoluutne vahemälust loetud tokenite arv on planeerimissisend mis tahes sarnasele projektile. Umbes 359 miljonit vahemälust loetud tokenit, peamiselt sellest, et süsteemiprompt lahendatakse iga Telegrami sõnumi puhul uuesti.

Korratavuse hinne

4 viiest.

Muster Telegram + Vercel + Supabase + Claude API on laialt rakendatav mis tahes isikliku toote LLM-i töövoo jaoks. Konkreetsed elemendid, mida teine ehitaja saaks üle võtta:

• —Vercel funktsiooni struktuur (api/webhook.ts + api/notify.ts + api/setup.ts).
• —Supabase migratsioonide komplekt (mitme kasutaja jaoks päevast esimest).
• —Ajastatud-oskuse eneseülevaate muster, sealhulgas aruandefaili formaat ja igapäevase-ülevaate-paranduseks tsükkel.
• —Nägemine-ekraanipildist integratsioon.
• —Nutika kavatsuse marsruuteri muster aktiivse vestluse välise vabateksti käsitlemiseks.

Mis ei kandu puhtalt üle:

• —Vigastuse reeglistik on fitness-spetsiifiline.
• —Süsteemiprompt on spordi-spetsiifiline.
• —Telegrami-kui-kasutajaliidese valik sõltub sellest, et publik on juba Telegramis. (Lääne-Euroopa publiku jaoks on see tegelik piirang — Telegram ei ole vaikimisi sõnumirakendus.)

Arendaja, kes tahab ehitada isikliku toitumistreeneri, õppimistreeneri, isikliku finantsdirektori või mis tahes muu "agent, mis sind tunneb ja sinu edusamme jälgib", saaks 60–70% arhitektuurist üle võtta ja valdkonnaloogika ümber kirjutada. Korratavuse hinne peegeldab seda ausalt: kõrge mustri taaskasutus, madal valdkonna taaskasutus.

Otsus

See projekt demonstreerib kategooriat, mida varasemad Kodulabori juhtumiuuringud ei käsitlenud: iteratiivne isiklik toode, mille on ehitanud selle enda kasutaja, mida on nädalate jooksul tegelikus kasutuses lihvinud ja millel on eneseülevaate tsükkel, mis püüab probleeme kinni enne kui kasutaja ise.

3-kordne töömahu kiirendus on päris, aga see pole pealkiri. Pealkiri on järgmine: üks inimene ehitas ja opereerib nüüd mitme kasutaja jaoks valmis Telegrami treenerit nägemise sisendiga, ajastatud teavitustega ja automaatse kvaliteediülevaate tsükliga, umbes 40 tunni jooksul, ~200 € API-kulu eest. Traditsiooniline kahekesi tiim sarnase ulatusega oleks võtnud vähemalt kuus nädalat ja mitu tuhat eurot ning ei oleks eneseülevaate tsüklit ehitanud — sest keegi poleks seda otseselt nõudnud.

Eneseülevaate tsükkel on kõige paremini ülekantav õppetund. Seda on odav ehitada, see toob pinnale probleeme, mida operaator tavakasutuses ei näe, ja see tasub end ära esimesel korral, kui püüab kinni vaikse andmete-kirjutamise vea. Mis tahes isikuandmeid käsitlev tehisintellekti abil ehitatud toode peab sellise tsükli omama.

Sellele, kes kaalub samalaadset ehitust: iteratiivne muster (kasuta seda → vaata see üle → paranda → korda) on töö. Tehisintellekt kiirendab koodi; ta ei asenda distsipliini kasutada oma toodet enda peal. Distsipliin ongi toode.

See juhtumiuuring on koostatud Kodulabori hindamisraamistiku alusel. Metoodika ja leiud on avalikult avaldatud aadressil kodulabor.ai.

Andmelisa