З сярэдзіны красавіка да сярэдзіны чэрвеня я амаль не чапаў функцый свайго прадукту.
Я будаваў OwlMeans — канвеер распрацоўкі, які ператварае карыстальніцкія гісторыі ў праграмы. А праца вакол яго тым часам была раскіданая. Стратэгія, нататкі пра брэнд, даследаванні і тэксты для сайта ляжалі ў розных месцах.
Штораз, калі прасіў агента дапамагчы, я нанова распавядаў яму пра кампанію.
На тое, каб гэта змяніць, я патраціў два месяцы. Я збудаваў працоўную прастору, дзе цяпер трымаю веды кампаніі і вяду рэгулярныя справы.
Праблема давала пра сябе знаць у звычайных задачах.
Для артыкула было патрэбна актуальнае пазіцыянаванне. Для праўкі на сайце — тое, што прадукт умее насамрэч. Для даследавання — пытанне кліента, на якое мы спрабавалі адказаць.
Штораз патрэбныя былі адны і тыя ж факты, а я ўсё роўна падаваў іх уручную. Часам я забываў дадаць агаворку. Часам у чарнавік трапляў тэзіс з тых часоў, калі кампанія была іншай.
Здольны агент спраўляўся з тым матэрыялам, які я яму даваў. А вось надзейнага месца, дзе гэты матэрыял шукаць, я для яго так і не стварыў.
Розніца тут была істотная. Я мог шліфаваць запыт для кожнай задачы асобна, а мог зрабіць так, каб працоўныя веды кампаніі было лягчэй знаходзіць і абнаўляць. Я ўзяўся за другое.
Агульныя запісы
Вікі кампаніі я зрабіў у Markdown.
Там стратэгія, веды пра кліентаў, правілы брэнда і дакументацыя прадукту. Індэксы тэчак падказваюць агенту, дзе шукаць. Кожная старонка мае канкрэтную тэму, а месца новай знаходкі — побач з ведамі, якія яна змяняе.
Гучыць як раскладванне папер па тэчках. Шмат у чым так і ёсць.
І даследаванні, і сама праца могуць абапірацца на адны і тыя ж запісы. Калі для артыкула патрэбны факт пра прадукт, агенту ёсць дзе яго праверыць. Калі праўка на сайце выяўляе састарэлы факт, выпраўленне ёсць дзе запісаць — у вікі.
І ўсё ж запісы трэба ацэньваць крытычна. Неправеранае ўяўленне пра рынак не стане праўдай толькі таму, што агент паклаў яго ў добра ўпарадкаваную тэчку. Адкрытыя гіпотэзы мы трымаем асобна ад усталяваных ведаў.
Наступным пластом сталі навыкі.
Я запісаў працоўныя працэсы, якія паўтараў раз за разам: даследаванні, падрыхтоўку артыкулаў, сінхранізацыю сайта і падтрымку дакументацыі прадукту. Кожны навык апісвае задачу і тыя нашы правілы, пра якія лёгка забыцца.
Тады выпраўленне можа палепшыць наступны запуск. Але яго трэба ўнесці ў адпаведныя інструкцыі: мадэль не вывучае кампанію раз і назаўсёды толькі таму, што я паправіў яе ў чаце.
Навык можа састарэць гэтак жа, як і дакумент. Нехта мусіць правяраць, ці па-ранейшаму адпавядае яго працэдура інструментам і самой працы.
Спецыфікацыя Agent Skills задае агульны фармат тэчкі і метаданых. А інструкцыі ўнутры нашых навыкаў пішам і падтрымліваем мы самі.
Код побач з кампаніяй
Яшчэ я падключыў да працоўнай прасторы нашы рэпазіторыі.
На практыцы гэта змяніла працу з тэкстамі. Артыкул пра рэліз мог абапірацца на напісаны код, а не на ўспаміны пра тое, што мы збіраліся выпусціць. Тэхнічная дакументацыя магла аддзяляць код, ужо зафіксаваны ў камітах, ад ідэі з дарожнай карты.
Сувязь з кодам не сцірае розніцы паміж гэтымі крыніцамі. Праектны дакумент апісвае намер. Каміт паказвае рэалізацыю. Ні тое, ні другое не даказвае, што пэўны працоўны працэс кліента ўжо паспяхова праверылі ў дзеянні.
Калі кампанія прадае AI-канвеер распрацоўкі, трымаць гэтыя адрозненні навідавоку — частка яе працы.
Гэтая структура адразу спатрэбілася ў працы над артыкуламі.
Я мог надыктаваць тэму, а агент правяраў нашу вікі і знешнія крыніцы, рыхтаваў чарнавік і прапускаў яго праз рэдактарскую праверку. Ілюстрацыі і версіі для сацыяльных сетак былі асобнымі крокамі. Да публікацыі справа даходзіла толькі тады, калі я гэтага прасіў.
Фактам больш не трэба было вандраваць з маёй памяці ў кожны запыт.
Тая ж схема дапамагла і з сайтам. Публічную старонку і ўнутранае тлумачэнне можна было ўзгадніць паміж сабой, пакуль абодва тэксты былі пад рукой.
Кампанія ад гэтага не пачала працаваць без мяне. Я па-ранейшаму выбіраў, што публікаваць, правяраў сцверджанні і вырашаў, якая праца вартая ўвагі.
Гэты досвед уплывае і на нашы паслугі. Апроч самой праграмы важна апісаць працоўны працэс і падрыхтаваць перадачу праекта. Для гэтага трэба канкрэтна акрэсліць аб’ём работ у праекце кліента, а не абяцаць, што бізнесам будзе кіраваць агент.
Файлы памяці
Чэрвеньская версія гэтага тэксту апісвала файлы кантэксту, якімі я тады карыстаўся. Цяпер усё ўладкавана інакш.
На кастрычнік нашы агульныя інструкцыі жылі ў AGENTS.md і супольнай тэчцы навыкаў, а там, дзе трэба, дадаваўся невялікі мост CLAUDE.md. Асобныя копіі інструкцый для кожнага агента перасталі быць схемай, якой варта прытрымлівацца.
Цяперашняя дакументацыя Claude Code пра памяць адрознівае інструкцыі праекта і аўтаматычную памяць. Таму ранейшае катэгарычнае сцверджанне, што гэты інструмент не мае сталай памяці, цяпер недарэчнае.
Запісы кампаніі маюць іншае прызначэнне. Яны фіксуюць, што вырашылі ў OwlMeans, якія доказы стаяць за сцверджаннем пра прадукт і які працоўны працэс адпавядае задачы. Мне трэба, каб гэтыя запісы заставаліся даступнымі для праверкі, з якім бы інструментам я ні працаваў.
Пазнейшую структуру рэпазіторыяў падрабязней апісвае гісторыя пра перабудову харнеса.
Чаго гэта каштавала
Два месяцы — вялікі крук для заснавальніка, які працуе адзін.
З працоўнай прасторай паўторную працу стала лягчэй падхопліваць, але пакуль я будаваў саму прастору, функцыі прадукту чакалі. А яшчэ яна дала мне сталы абавязак: інструкцыі і веды трэба трымаць актуальнымі.
Я ўклаўся б у гэта зноў, бо сам карыстаюся гэтай структурай у працы. Але калі б я рабіў гэта яшчэ раз, пачаў бы з меншага. Надзейныя запісы для некалькіх паўторных задач карысныя яшчэ да таго, як стануць сістэмай для ўсёй кампаніі.
Перагледжана 15 кастрычніка 2026 г. Гісторыя пра крук у красавіку–чэрвені засталася без змен; апісанні структуры рэпазіторыяў і памяці вышэй аддзяляюць першапачатковую схему ад цяперашняй.