Blog

Miért vesznek el az AI-chatben hozott döntések, és hol érdemes tárolni őket

A ChatGPT- vagy Claude-chatben hozott döntések eltűnnek, ahogy a chat elgördül; rögzítsd őket a táblán, a feladathoz kötve, hogy a következő AI-munkamenet ezzel kezdjen.

A Weft az AI-feladatkezelő egyszemélyes alapítóknak és kis csapatoknak.

Minden cikk

Írta: Andrei Finogeev ·

A ChatGPT- vagy Claude-beszélgetésben hozott döntések azért vesznek el, mert egy chatnek nincs állapota. Semmi sem jelöl meg benne egy sort úgy, hogy „ezt döntöttük el”, semmi sem köti ezt a sort ahhoz a munkához, amelyre hatással van, és egy új chat üresen indul. A megoldás az, hogy az AI írja le a döntést ott, ahol a munka él, rövid rekordként az indokaival együtt, a következő munkamenet pedig olvassa el ezeket a rekordokat, mielőtt cselekszik.

A Weftet mi készítjük. A más termékekre vonatkozó tények a hivatalos oldalaikról származnak, 2026. október 27-én ellenőrizve. Az a gondolat, hogy egy szálnak „nincs állapota”, a Hypertask Slack-szálakról szóló cikkéből származik. Ez az útmutató az AI-chatekre alkalmazza.

Miért tűnnek el a ChatGPT-vel vagy a Claude-dal hozott döntések?

Negyven percet töltesz egy asszisztenssel két adatbázis-szolgáltató, két árazási modell vagy egy API két felépítése közötti mérlegeléssel. Az egyik mellett döntesz. Az érvelés jó, az asszisztens egyetért, és továbblépsz a következő dologra.

Egy héttel később a következtetés még mindig abban a chatben van, valahol kétszáz másik üzenet fölött. Egy új chat semmit sem tud róla. Egy csapattárs sosem látta. És ha másnap egy másik AI-klienst nyitsz meg, például egy kódoló ügynököt a terminálban, az a nulláról indul, és vidáman javasolhatja azt az opciót, amelyet elvetettél.

Ez nem fegyelem kérdése. A beszélgetés üzenetek sorozata. Nincs benne „eldöntve” mező, nincs gazdája, nincs feladathoz kötve, és nem lehet benne azt mondani, hogy „ez felváltja, amit kedden mondtunk”. Egy eldöntött és egy félbehagyott kérdés ugyanúgy néz ki, miután elgördültek.

Nem oldja ezt meg már a chat memóriája?

Erre a feladatra nem. Sok asszisztens ma már megjegyez rólad dolgokat a chatek között, és ez hasznos a preferenciákhoz és a háttérhez. Ez a memória azonban egy termékhez és egy fiókhoz tartozik. Arra írták, hogy az az asszisztens használja, nem pedig olyan nyilvántartásnak, amelyet egy ember soronként átnézhet, és egy másik AI-kliens nem tudja olvasni. Azt sem mondja meg, melyik feladatra vonatkozott egy választás, vagy melyik korábbi választást váltotta fel.

Egy döntési naplóval szemben mások a követelmények. Megtalálhatónak kell lennie a projekten dolgozó emberek és ügynökök számára, olvashatónak bármelyik AI-kliens számára, amely legközelebb elveszi a munkát, a munkához kell kötődnie, és őszintének kell lennie az előzményekkel: amikor egy döntés megváltozik, a réginek láthatónak kell maradnia azzal az indokkal együtt, amiért felváltották.

Mi számít rögzítésre érdemes döntésnek?

Akkor rögzíts egy választást, ha valaki ésszerűen másként is dönthetett volna, és a választás meghatározza a későbbi munkát. Jó példák:

  • Egy eszköz, szolgáltató vagy könyvtár kiválasztása egy másikkal szemben.
  • Valaminek a szándékos elvetése („ebben a negyedévben nincs ajánlói program”).
  • Egy szabály felállítása, amelyet a munkának követnie kell („az EU-ban minden ár áfával együtt jelenik meg”).
  • Egy korábbi választás megváltoztatása, az indokkal együtt.
  • A saját káron megtanult lecke („ne futtasd a migrációt munkaidőben”).

Ne rögzítsd:

  • A felvetett, de el nem fogadott ötleteket.
  • Magának a munkának a lépéseit (az a feladatba és annak eredményébe tartozik).
  • Bármit, amibe a személy még nem egyezett bele, hacsak nincs egyértelműen javaslatként jelölve.
  • Olyan tényeket, amelyeket bárki egy perc alatt újra kikereshet.

Egy hasznos próba: ha egy új AI-munkamenet éppen visszacsinálná ezt a választást, szeretnéd, hogy megálljon, és elolvassa, miért született? Ha igen, rögzítsd.

Hogyan néz ki egy jó döntési rekord?

Legyen rövid, és tartsd meg az indokokat. Az alábbi formátum a MADR (Markdown Architectural Decision Records) könnyített változata, ezt használja a Weft record_decision eszköze:

Cím:          Fájlfeltöltés: objektumtár, nem az adatbázis
Eredmény:     A feltöltött fájlok az objektumtárba kerülnek; az adatbázis
              csak a fájlkulcsot és a metaadatokat tárolja.
Állapot:      accepted
Kontextus:    A felhasználók legfeljebb 50 MB-os fájlokat csatolnak. Ha az
              adatbázisban tárolnánk őket, a mentések lassúak és nagyok lennének.
Opciók:       1. Objektumtár       + olcsó, a mentések kicsik maradnak
                                   - még egy beállítandó szolgáltatás
              2. Adatbázis-oszlop  + minden egy helyen
                                   - a mentések minden feltöltéssel nőnek
Következmények: Aláírt URL-ek kellenek a letöltésekhez.
              Egy feladat törlésekor a fájljait is törölni kell.
Újragondolás: Ha a fájlok tartalmában kell keresnünk.
Feladat:      Fájlfeltöltés
  • A Cím megnevezi a döntést, hogy átfutva is megtaláld.
  • Az Eredmény egyetlen mondat, amely alapján egy újonnan érkező is cselekedni tud.
  • A Kontextus az, ami akkor igaz volt. Ez a rész tűnik el elsőként az emlékezetből.
  • Az Opciók csak azt sorolja fel, amit ténylegesen mérlegeltek, nem az utólag kitalált alternatívákat.
  • A Következmények az elfogadott hátrányokat is tartalmazza, hogy később senki ne „fedezze fel” őket hibaként.
  • Az Újragondolás azt mondja meg, mi tenné a választást rosszá.

Hogyan tárolja a Weft a döntési rekordokat?

A Weft egy feladattábla, amelyet az AI-klienseid MCP-n keresztül érnek el a https://letsweft.com/api/mcp címen. A 32 eszközéből három foglalkozik döntésekkel:

  • A record_decision címet és eredményt vár, plusz kontextust, legfeljebb öt opciót előnyökkel és hátrányokkal, következményeket és az újragondolás feltételét. Feladathoz (taskId) vagy projekthez köthető. A rekordok megváltoztathatatlanok: módosításhoz az AI új döntést rögzít, amelynek supersedesId mezője a régire mutat, a régi rekord pedig megmarad, felváltottként jelölve.
  • A get_context a munkaterület élő döntéseit és tanulságait adja vissza, a legújabbal kezdve, egy tokenkeretbe csomagolva (alapból 800 token). Szűkíthető egy projektre vagy egy feladatra. Minden sor hordozza a dátumát, felváltott döntés sosem jelenik meg, a be nem fért sorokat pedig megszámolja, nem rejti el.
  • A get_task_history decisions módban egy feladatról rögzített összes döntést listázza, az átnézési ítéleteket és indokaikat is beleértve.

A record_decision eszköznek van egy második felhasználása is: annak az ítéletnek a továbbítása, amelyet a személy egy beszélgetésben az átnézésére váró munkáról mondott (elfogadva, átdolgozás, elvetve vagy elhalasztva). Az eszköz leírása közli az AI-jal, hogy itt ő a hírnök, nem a döntéshozó, ezért soha nem használhatja a saját munkája elfogadására.

Mivel a rekordokat sosem szerkesztik helyben, az előzmények őszinték maradnak. Ha márciusban szolgáltatót váltasz, a januári döntés még ott van, felváltottként jelölve, a márciusi rekord pedig elmondja, miért.

Hogyan kérjem meg az AI-t, hogy rögzítse a döntéseket?

Csatlakoztasd a Weftet az AI-kliensedhez, majd illessz be egy ilyen utasítást a chat elején, vagy a kliens egyéni utasításaiba vagy projektfájljába, ha van ilyen:

Amikor ebben a chatben valódi választást hozunk (egy opciót választunk egy másikkal
szemben, elvetünk valamit, vagy megváltoztatunk egy korábbi választást), rögzítsd
a Weftben a record_decision eszközzel, mielőtt továbblépnénk:
- title: a döntés, néhány szóban megnevezve
- outcome: a választás egyetlen mondatban
- context: mi volt igaz, ami kikényszerítette a választást
- options: csak a ténylegesen mérlegelt opciók, előnyökkel és hátrányokkal
- consequences: mi következik belőle, jó és rossz
- confirmation: mikor kell újragondolnunk
- taskId vagy project: a feladat vagy projekt, amelyről szól
Ha egy korábbi döntést változtat meg, szerkesztés helyett add meg a supersedesId mezőt.
Ne rögzíts csevegést, találgatást vagy olyasmit, amibe még nem egyeztem bele.
Ha még nem köteleztem el magam, használd a "proposed" státuszt.
Minden nem triviális munka elején először hívd meg a get_context eszközt, és mondd
el, mely korábbi döntések vonatkoznak rá.

A csatlakozás egy percig tart. A ChatGPT-ben a Weft publikált app a pluginkönyvtárban, minden csomagon elérhető, az Ingyenest is beleértve (beállítás). A Claude Code-ban egyetlen parancs (beállítás). A claude.ai és a Claude Desktop egyéni konnektorként adja hozzá. A bejelentkezés böngészős OAuth, így nincs kimásolandó kulcs, és a Weft frissítő tokent ad ki, így a kliens maga újítja meg a bejelentkezést. Más kliensek, köztük a Cursor és a Codex beállítási oldalai a dokumentációban találhatók.

Mi történik, ha másnap a ChatGPT-ről a Claude Code-ra váltok?

Íme az eset, amelyre az utasítás készült.

  1. Hétfőn a ChatGPT-ben megtervezel egy funkciót. Úgy döntesz, hogy a feltöltéseket objektumtárban tárolod, nem az adatbázisban, és a ChatGPT meghívja a record_decision eszközt a kontextussal, mindkét opcióval és a következményekkel, a „Fájlfeltöltés” feladathoz kötve.
  2. Kedden megnyitod a Claude Code-ot a repóban. Ha még nem csatlakoztattad: claude mcp add --transport http weft https://letsweft.com/api/mcp.
  3. Megkéred, hogy vegye elő a feltöltési feladatot. Mielőtt kódot írna, meghívja a get_context eszközt arra a feladatra, vagy a get_task_history eszközt decisions módban, és visszakapja a hétfői rekordot.
  4. Objektumtárra építkezik, ahelyett hogy újranyitná a kérdést. Ha valódi okot talál arra, hogy a választás rossz, javasolhat egy új döntést, amely felváltja a hétfőit, és te döntesz.

Mindkét kliens ugyanazt a táblát és ugyanazokat a döntéseket olvassa, mert a rekord a Weftben él, nem valamelyik chatben. Minden OAuth-kapcsolat külön szereplő, és a tábla azt a nevet mutatja, amellyel az egyes kliensek regisztráltak, így láthatod, melyik kapcsolat melyik feladatot hozta létre. Több ügynök ütközés nélküli futtatásáról egy táblán lásd: több AI-ügynök, egy tábla.

Hová kerüljenek a ChatGPT-ben hozott döntések?

Négy gyakori hely, azon szempontok szerint összevetve, amelyek egy döntési naplóhoz kellenek:

Ahová a döntés kerülKésőbb megtalálhatóEgy másik AI olvashatjaA munkához kötveIndokkal felváltható
ChatelőzményCsak ha emlékszel, melyik chat volt, és a keresés megtaláljaNem, egy másik kliens nem tudja megnyitniNemNem, egy későbbi üzenet megjelölés nélkül mond ellent neki
Dokumentum vagy jegyzetoldalIgen, ha valaki leírtaCsak ha az az AI csatlakozik a dokumentumhozLazán, linkeken keresztülÁltalában szerkesztéssel, ami hajlamos eltüntetni a régi érvelést
Feladat-hozzászólásIgen, azon a feladatonHa az AI tudja olvasni a feladatkövető hozzászólásaitIgenKifejezetten nem, az újabb hozzászólások nem jelölik a régieket felváltottként
Döntési rekord a Weft-táblánIgen, a get_context és a get_task_history révénIgen, bármely, a munkaterülethez MCP-n csatlakozó kliensIgen, feladat vagy projekt szerintIgen, a supersedesId megtartja a régi rekordot, felváltottként jelölve

Nem az a lényeg, hogy a chat vagy a dokumentumok rosszak. A chatben gondolkodsz. A döntést viszont abban a pillanatban, amikor megszületik, át kell másolni a chatből valami állapottal rendelkező helyre, és ezt annak kell megtennie, aki már amúgy is részt vesz a beszélgetésben: az AI-nak.

Ez kiváltja a dokumentációnkat vagy a wikinket?

Nem. A Weftnek nincs dokumentum- vagy wikifunkciója, és nem is akar ilyen lenni. A hosszú magyarázatok, a betanító útmutatók és a tervezési leírások a dokumentációs eszközödbe tartoznak. Egy döntési rekord szándékosan kicsi: egy választás, az indokai, és ami felváltotta. Ha a csapatod már wikiben vezeti a döntési rekordokat, és minden használt AI-kliens tudja olvasni, ez elég lehet. A Weft akkor hasznos, amikor a döntések AI-chatekben születnek, és a következő olvasó gyakran egy másik AI. Ha ehhez a Notiont mérlegeled, lásd: Notion-alternatívák AI-feladatokhoz.

Két másik őszinte korlát. A Weft nem olvassa a chatjeidet: egy döntés csak akkor kerül rögzítésre, ha az AI meghívja a record_decision eszközt, ezért fontos a fenti utasítás. És az AI tévesen ítélheti meg, mi számít döntésnek, ezért időnként olvasd el a get_context kimenetét, és váltsd fel, amit rosszul rögzített.

Mennyibe kerül?

A döntések rögzítése és olvasása az Ingyenes csomagon is működik, amely 50 aktív feladatot és havi 200 AI-eszközhívást tartalmaz. Minden record_decision vagy get_context hívás egy hívásnak számít. A Pro helyenként havi 8,26 € vagy évi 69,85 €, korlátlan feladattal és hívással (árak). A Weftnek nincsenek AI-kreditjei: a gondolkodás a saját AI-kliensedben történik, a Weft csak a táblát és a rekordjait tárolja.

Nem kérhetem meg egyszerűen a ChatGPT-t, hogy a chat végén foglalja össze a döntéseket?
Megteheted, és segít. Az összefoglaló viszont továbbra is abban a chatben él, vagy ahová beilleszted. Nincs a feladathoz kötve, egy másik AI-kliens nem tudja olvasni, és amikor a döntés megváltozik, nincs nyoma, mit váltott fel. Ha minden döntést akkor rögzítesz, amikor megszületik, mindhármat elkerülöd.
Kérés nélkül is rögzíti az AI a döntéseket?
A record_decision eszköz leírása azt mondja az AI-nak, hogy használja, valahányszor a felhasználó valódi választást hoz a beszélgetésben, így egyes kliensek meg is teszik. Ne számíts rá. A beillesztett utasítás ezt kifejezetté teszi, és bármikor mondhatod: „rögzítsd ezt a döntést”.
Szerkeszthető egy döntés, ha rosszul rögzítették?
Helyben nem. A rekordok megváltoztathatatlanok. Rögzíts egy javított döntést, amelynek supersedesId mezője a hibásra mutat. A régi rekord megmarad, felváltottként jelölve, és a get_context többé nem mutatja.
Kell feladat a döntésekhez?
Nem. Egy döntés köthető feladathoz, projekthez, vagy egyikhez sem. Ha feladathoz kötöd, a get_task_history az adott munka mellett mutatja, és a get_context leszűkíthető rá.
Ugyanaz ez, mint a Weft munkamemóriája?
Nem. A munkamemória (rövid, tanult jegyzetek) külön Pro funkció. A döntési rekordok a record_decision eszközből származnak, és a kód nem korlátozza őket a Próra.
Mi van, ha több AI-klienst használok?
Pont ez a fő ok, amiért érdemes ezt csinálni. Az ugyanahhoz a Weft-munkaterülethez csatlakozó ChatGPT, Claude Code, Cursor vagy Codex mind ugyanazokat a döntéseket olvassa a get_context eszközön keresztül, így a második kliens nem nyitja újra azokat a kérdéseket, amelyeket az első már lezárt.