AI Project Memory pod kapotou: technická případová studie

Jak kontroluji zdroje, kde zapojuji model, co jsem opravovala při vysoké spotřebě tokenů a které limity zůstávají otevřené.

Tato část jde hlouběji do architektury systému. Zachycuje konkrétní pořadí kontrol, hranice mezi modelem a pevnými pravidly i věci, které stále nepovažuji za uzavřené.

Základem je společná složka s textovými soubory, jejichž změny sleduje Git. Git tu funguje jako historie: ukáže, co se změnilo, kdy a kým. Markdown je jednoduchý způsob zápisu textu pomocí nadpisů, odrážek a tabulek.

V této technické části

1. Architektura a nástroje
2. Tok od zdroje k přehledu
3. Co jsem ladila u tokenů
4. Příjem a schvalování úkolů
5. Model, pravidla a člověk
6. Otevřené limity

Co v systému dělají jednotlivé nástroje

Dvě úrovně paměti

Detail zůstává u projektu. Rozhodovací pohled vzniká nad projekty.

Vrstva 1 · Projektová paměť

Pracovní záznamy, aktuální stav, rozhodnutí, otevřené věci, rizika a další krok.

Zdrojové projekty zůstávají pouze pro čtení.

Vrstva 2 · Portfoliová paměť

Společný přehled, registr úkolů, kontrolní záznamy a ranní či večerní rozhodovací pohledy.

Vybírá pouze informace, které mění další akci.

Od změny v projektu k rannímu přehledu

Ranní a večerní kontrola má přesné pořadí.

1. Kontrola nejprve prověří zdroje

Skript projde registr projektů a u každého vyhodnotí jeden ze tří stavů:

• Updated – aktualizováno,
• Confirmed no change – potvrzeno bez změny,
• Needs confirmation – je třeba potvrdit.

Tato kontrola nepoužívá jazykový model. Sleduje čas změn, dostupnost zdroje a konkrétní umístění nových souborů. Nerozumí jejich významu. Pomáhá ale potvrdit, že žádný registrovaný projekt nevypadl, a zúží množství podkladů, které musí AI interpretovat.

2. Model dostane přesně vymezený kontext

Pokud je projekt potvrzený bez změny, AI ho znovu detailně nečte. Při stavu Updated nebo Needs confirmation dostane konkrétní změněné soubory a související aktivní úkoly.

Současná verze systému vytvoří jeden přesně vymezený balík podkladů. Obsahuje registr projektů, seznam důkazů, předchozí souhrn, chráněný obsah od jiného nástroje, související úkoly a změněné soubory.

Dříve se stejné podklady otevíraly v několika kolech. Model opakovaně četl instrukce, celý registr úkolů a příliš širokou historii. Výstup byl podobný, cesta k němu byla dražší a méně předvídatelná.

3. Vznikne rozpracovaný kontrolní záznam

Po kontrole zdrojů se vytvoří záznam se stavem Pending, tedy rozpracováno.

Zachycuje jeden ranní nebo večerní běh: kontrolované období, způsob spuštění, vykonavatele a jeden řádek pro každý projekt. Díky tomu si dokážu ověřit, že se na nic nezapomnělo.

Záznam má i ochrannou funkci. Pokud další kontrola uvidí čerstvý rozpracovaný běh, skončí bez nového spuštění AI. Dvě automatizace tak nezačnou současně vyrábět stejný souhrn.

4. Kontrola podle pevných pravidel ověří důkazy

Před aktualizací společného přehledu se kontroluje například:

• zda kontrolní záznam existuje,
• zda má všechny povinné údaje,
• zda má každý projekt právě jeden řádek,
• zda jsou pojmenované mezery v důkazech,
• zda zůstal zachovaný obsah patřící jinému nástroji.

Pokud tato brána neprojde, aktuální přehled se nezmění. Pro mě je to důležité. Nechci otevřít souhrn, který působí aktuálně, když kontrola podkladů selhala.

5. Model vytvoří rozhodovací pohled

Až po úspěšné kontrole model interpretuje změny napříč projekty. Připraví ranní nebo večerní pohled a závěrečná kontrola podle pevných pravidel prověří povinné části, jejich pořadí a dokončení procesu.

Následující běh pak pokračuje od posledního potvrzeného kontrolního bodu.

První verze fungovala, ale spotřebovala příliš mnoho tokenů

Tohle byl jeden z momentů, kdy mi došlo, že funkční AI workflow ještě nemusí být dobrý workflow.

První verze ranních a večerních kontrol dokázaly vytvořit použitelný přehled. Cesta k němu ale spotřebovala víc tokenů, než dávalo smysl. Model opakovaně četl pracovní instrukce, celý registr úkolů, staré stavy a příliš širokou historii změn. Někdy znovu otevíral podklady, které už jednou dostal.

Další problém byl v tom, co systém považoval za změnu. Kontrolní skript zachycoval i vlastní manažerské výstupy, pomocné soubory, buildy webu nebo výsledky testů v prohlížeči. Projekt tak mohl vypadat jako aktualizovaný jen proto, že předchozí běh vytvořil souhrn.

Pravidelné kontroly se navíc mohly překrývat se záložní obnovou pomocí AI. Dva procesy pak četly podobný kontext a připravovaly podobný výsledek.

Postupně jsem proto upravila několik věcí:

• skript nejprve prověří všechny projekty a model detailně čte pouze Updated nebo Needs confirmation,
• povolené podklady se spojí do jednoho přesně vymezeného balíku,
• odvozené výstupy, buildy, knihovny a testovací soubory se z kontroly vyloučí,
• druhé kontroly zdrojů, široké opakované čtení a smyčky s dalšími pokusy jsou zakázané,
• ranní a večerní cyklus používají úspornější model a nastavení,
• opakovaná záložní obnova pomocí AI je pozastavená,
• zůstala hodinová kontrola, která dokáže rozhodnout bez spuštění modelu.

Za mě je nejužitečnější ta poslední hranice. Nejúspornější běh AI je ten, který se nemusí spustit.

Kontrola v počítači dokáže před spuštěním modelu zjistit, že:

• dnešní kontrolní záznam je kompletní,
• plánovaný cyklus ještě běží,
• rozpracovaný záznam je mladší než 90 minut,
• systém je stále v ochranném časovém okně,
• není dostupná síť,
• stejnou obnovu už provádí jiný proces.

V těchto případech se model nespustí.

Je tu jedno důležité upřesnění. Pravidelný cyklus v 08:00 nebo 18:00 už začíná jako automatizace s AI. Skript v něm snižuje rozsah čtení, ale neodstraní první spuštění modelu. Úplné vynechání AI funguje jen tam, kde se kontrola provede ještě před jejím spuštěním.

Přesnou procentuální úsporu zatím neuvádím. Architektonická změna je ověřená, finanční výsledek ještě měřím.

Od návrhu AI k hlavní evidované úloze

Druhá větev systému řeší úkoly z Fireflies, přímého chatu, Codexu, Claude Code, kontroly nebo manuálního vstupu.

Když každý nástroj zapisuje přímo do hlavního seznamu, snadno vzniknou paralelní úkoly, kolize identifikátorů a změny stavu bez jasného důvodu. Proto má tento postup čtyři kroky.

1. Příjem návrhu — Zdroj a důkaz zůstanou viditelné.
2. Kontrola duplicity — Model upozorní, nic nemaže.
3. Lidské schválení — Člověk rozhodne o významu a stavu.
4. Zápis změny — Uloží se původní i nová hodnota.

Příjem návrhu

Fireflies GPT zapisuje do vlastní části Fireflies Input. Návrhy z chatu směřují po potvrzení do Intake & Review, tedy na příjem a kontrolu.

Vstup obsahuje zdroj, navrhovanou změnu, případný identifikátor úkolu, důkaz, míru jistoty a stav kontroly. Hlavní úloha se v tuto chvíli ještě nemění.

Kontrola stejných úkolů

Systém porovná návrh s existujícími úkoly přes přesný identifikátor, stejný název v projektu, stejný zdroj a výsledek a nakonec významově stejný cíl.

Model pomáhá hlavně u posledního bodu: dokáže upozornit na stejný úkol napsaný jinými slovy. Možnou duplicitu zapíše do Dedupe Review, tedy ke kontrole duplicit. Během hledání nic nemaže ani neslučuje.

Schválení a zápis

Člověk může návrh sloučit s existujícím úkolem, aktualizovat ho, ponechat oba s jasnějším rozsahem, označit novější řádek jako duplicitu nebo si vyžádat další potvrzení.

Odpovědná osoba, priorita, hlavní stav nebo termín se nezmění jen proto, že to navrhl model.

Až vykonávací krok změní hlavní evidovanou úlohu. Při zapsání schválené změny se uloží původní i nová hodnota, zdroj a schválení. Tím se zachová správnost a konzistentnost záznamů i historie rozhodnutí.

V jednom reálném případě jsem našla více významů pod identifikátorem T-038 a duplicitní řádek pro stejnou webovou práci. Schválené sloučení zachovalo starší identifikátor. Historický řádek se nesmazal a nesouvisející úkol s kolizí dostal nový identifikátor.

Výsledkem bylo méně nejasností bez ztráty historie.

Kde používám model a kde pevná pravidla

Pomáhá mi jednoduchá otázka: potřebuje tento krok porozumět významu, nebo jen ověřit jasně určené pravidlo?

Jazykový model používám pro interpretaci různých důkazů, rozlišení výsledku a překážky, přípravu souhrnu, významové porovnávání úkolů a návrh priorit.

Pevná pravidla používám pro kontrolu pokrytí všech projektů, povinných údajů, počtu a pořadí sekcí, stabilních identifikátorů a historie změn.

Model dostane význam a prostor pro úsudek. Kód drží hranice a konzistentnost. Člověk zůstává u rozhodnutí, která mění platný stav.

Kde vzniká praktická hodnota

Když se na jednotlivé části dívám samostatně, každá může působit jako malá administrativní vrstva. Jejich hodnota se ukáže až při propojení více projektů a nástrojů.

Systém mi pomáhá:

• omezit opakované čtení projektů, ve kterých se nic nezměnilo,
• snížit riziko, že si stejný úkol zapíšu vícekrát,
• oddělit potvrzenou změnu od nového návrhu,
• zachytit projekt, u kterého chybí důkaz nebo rozhodnutí,
• zachovat výstupy více AI nástrojů bez tichého přepsání,
• pokračovat od posledního potvrzeného kontrolního bodu,
• zpětně pochopit, proč se stav nebo úkol změnily.

Největší smysl to dává tehdy, když člověk nebo tým drží více paralelních projektů, používá více AI nástrojů a potřebuje se vracet k úkolům, které trvají déle než jeden chat.

U jednoho krátkého projektu by byl celý setup příliš těžký. Tam bych zůstala u jednoho hlavního seznamu úkolů, jednoduchého pracovního záznamu a jasného pravidla, kdo může měnit stav.

Co systém stále nevyřešil

AI Project Memory je funkční pracovní systém, stále má ale limity.

Kontrolní záznam potvrdí zahrnutí projektů a správný formát. Nezaručí, že model každý důkaz pochopil správně. Lidské schválení chrání citlivé změny, zároveň přidává čekání.

Porovnávání významově podobných úkolů zůstává úsudkovou prací. Potřebuji měřit případy, kdy AI spojí dva odlišné úkoly, přehlédne skutečnou duplicitu nebo člověk změní její doporučení.

Ochrana hlavních záznamů je dnes z velké části procesní. Produkční verze by měla mít oddělené účty a technická oprávnění pro navrhování, schvalování a zapisování změn.

Otevřená zůstává i přesná úspora nákladů a plně automatická obnova se spolehlivým vzdáleným ukládáním historie.

Tyto limity mi pomáhají odlišit fungující osobní pracovní systém od představy plně autonomního řízení projektů.

Co si z technické vrstvy odnáším

Funkční AI workflow ještě nemusí být spolehlivý ani úsporný. V mém případě pomohlo oddělit kontrolu zdrojů od interpretace, zúžit kontext a nechat změny hlavního stavu projít lidským potvrzením.