Стек пам'яті AI-агентів, який кожен має використовувати у 2026 році (Посібник для розробників)

ваша модель та обв'язка більше не мають значення.

те, що має значення більше — це...

ваш особистий контекст / спільна пам'ять, яка це робить

Вступ

я покажу вам, як створити спільну пам'ять для ваших кодуючих агентів... щоб наступний інструмент міг знайти рішення, які ви вже прийняли.

архітектурна розмова в Claude, сеанс налагодження в Codex, пояснення, поховане в Cursor... корисна робота, яка все ще має бути доступною, коли ви змінюєте інструменти, починаєте інший сеанс або повертаєтеся до проєкту через місяць.

Коротше; якщо ви не хочете читати всі 3 845 слів, просто дайте цей репозиторій GitHub своєму агенту ➡️ https://github.com/codejunkie99/agentic-stack-desktop

я створив усе це, використовуючи Kimi K3 в Codex Harness. Відео було створено та відредаговано за допомогою Kimi K3 з Cua для Computer Use

це посібник для розробників по agentic stack desktop, від вашого першого імпорту до робочого процесу, де агент може відновити попереднє рішення, перевірити його на відповідність поточному коду, внести обмежену зміну та залишити щось корисне після себе.

Ось що ви отримуєте:

1. основа: що залишається, коли ви перемикаєте інструменти
2. найшвидший шлях: створіть робочий простір, який ви можете оцінити
3. робоче налаштування: відокремте дослідження від реалізації
4. вправа з проєкту: проведіть повторювану помилку через весь цикл
5. спільний рівень: додайте пошук у ваші інші інструменти
6. довговічний рівень: що заслуговує стати уроком
7. робочі правила: коротко, обмежено, перевіряємо
8. індивідуальна збірка: змініть робочий простір навколо реальної проблеми
9. масштабування: додайте покриття там, де попередній цикл виявив прогалину
10. аркуш збірки

1. Основа: що залишається, коли ви перемикаєте інструменти

уявіть, що ви провели день, обираючи, як має працювати функція. ви дослідили альтернативи, знайшли обмеження, відхилили очевидне рішення і, нарешті, зупинилися на тому, що підходить.

реалізація потрапляє в коміт. пояснення залишається в розмові.

через тиждень інший агент дивиться на код і пропонує той самий підхід, який ви вже відхилили. це може бути навіть розумна пропозиція, виходячи з доступної йому інформації. Відсутня частина — це обговорення, яке змусило вас вибрати інакше.

зробіть обґрунтування відновлюваним

почніть тут: зробіть це обговорення відновлюваним, а потім змусьте наступного агента перевірити його перед тим, як діяти.

agentic stack надає рідний робочий простір macOS з можливістю пошуку та вибору історії з Claude Code, Codex, OpenCode та Cursor. Claude Code та Codex також виконуються через свої офіційні CLI; Cursor та OpenCode наразі надають лише контекст. огляд репозиторію

робочий процес нижче — це те, як я б використовував ці можливості. Брифінг, розподіл обов'язків та вправа з проєкту — це запропоновані робочі практики, які ви можете адаптувати.

2. Найшвидший шлях: створіть робочий простір, який ви можете оцінити

почніть з репозиторію, який ви розумієте. Виберіть щось, де ви знаєте важливі файли, пам'ятаєте нещодавнє рішення та можете розпізнати погану рекомендацію.

Знайомий проєкт дає вам точку відліку. Якщо ви почнете з незнайомого коду та незнайомої історії, ви намагатиметеся одночасно перевірити інструмент і вивчити систему.

Для збірки з вихідного коду задокументовані вимоги включають macOS 14+, Python 3.10+, Xcode Command Line Tools та Swift 6 toolchain. Встановіть та увійдіть у CLI кодування, який ви хочете запустити. вимоги

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

відкрийте свій репозиторій у додатку та завершіть Guided setup. Це попередній перегляд з ad hoc підписанням, тому macOS може зажадати підтвердження при першому запуску. налаштування

встановіть першу перевірку прийнятності

Перш ніж імпортувати що-небудь, запишіть питання, на яке ви хочете, щоб перший агент відповів. Щось на кшталт: чому наш завдання експорту обробляє записи пакетами, і чи все ще потрібне це обмеження в поточній реалізації?

Це питання стане вашою першою перевіркою прийнятності. Ви шукаєте правильне рішення, правильний підтримуючий код і чесне пояснення всього, що агент не може встановити.

2.1 Перший імпорт: дайте йому рішення, яке варто знайти

відкрийте Knowledge Graph → Graph → Import memory, перегляньте джерела та виберіть матеріал, який ви хочете включити.

граф використовує повнотекстовий пошук SQLite, зі зв'язками на основі тем, посилань на репозиторій та походження; оригінальні сховища чатів залишаються незмінними. поведінка імпорту

я б почав із завершеної розмови, що містить рішення, яке ви пам'ятаєте. Особливо таке, де ви відхилили щось привабливе через обмеження, яке не було б очевидним з кінцевого коду.

знайдіть це рішення після імпорту. Відкрийте результат та перевірте джерело. Переконайтеся, що ви дивитеся на ту розмову, яку мали намір імпортувати, з достатнім контекстом, щоб зрозуміти, що сталося.

перевірте, чи можете ви знайти його знову

потім спробуйте другий пошук, використовуючи лексику, яку ви природно використали б наступного місяця. Ви можете пам'ятати назву функції, тоді як у розмові використовувалося внутрішнє ім'я модуля. Виявлення цієї невідповідності зараз допоможе вам зрозуміти, як отримати матеріал пізніше.

я б тримав першу колекцію досить маленькою, щоб перевірити її вручну. Правильна відповідь з відомого джерела є корисним доказом того, що робочий процес працює.

Велика кількість імпортованих даних показує, скільки матеріалу потрапило в систему, залишаючи його корисність для перевірки.

Розширюйте колекцію, коли інше завдання дасть вам для цього причину.

2.2 Перший робочий сеанс: зробіть експеримент досить малим, щоб завершити

я б поставив фінішну пряму для початкового налаштування, перш ніж відкривати інший екран конфігурації. До кінця сеансу ви повинні відновити відоме рішення, перевірити його на відповідність репозиторію та створити огляд, який ви можете пояснити комусь іншому.

Виберіть приклад з вузькими межами. Окрему поведінку експорту легше перевірити, ніж всю платформу даних. Раніше зроблений вибір щодо компонента легше перевірити, ніж широке питання про те, чи хороша архітектура.

Тримайте коротку нотатку поруч із вправою: питання, очікуване джерело, поточну реалізацію та частину, яка потребує судження. Це ваша довідка для оцінки відповіді.

діагностуйте правильну невдачу

• якщо рецензент відновлює неправильну розмову, працюйте над пошуком.
• якщо він знаходить правильну розмову, але неправильно читає код, працюйте над дослідженням.
• якщо висновки правильні, але реалізація не відповідає вимогам, покращте передачу.

Це розмежування важливе, тому що кожна невдача вимагає різного виправлення. Додавання більшої кількості пам'яті не обов'язково виправить нечіткий бриф, а переписування брифу не відновить джерело, яке ніколи не було імпортовано.

Завершіть найменший повний цикл, запишіть, що не вдалося, і використовуйте цей доказ, щоб вибрати наступне покращення.

3. Робоче налаштування: відокремте дослідження від реалізації

моє запропоноване перше налаштування має рецензента лише для читання та виконавця з доступом до редагування проєкту. Дайте кожному чіткий результат і зробіть передачу такою, яку ви можете прочитати до початку будь-яких змін.

Профілі агентів підтримують виконавця, модель, зусилля, інструкції та доступ до файлів. Розмови належать проєктам, а продовження відновлюють сеанси їхнього базового CLI. модель розмови

1. агент 1: рецензент отримує перше питання: що ми вирішили, що код робить зараз, і чи є прогалина, яку варто усунути?
2. агент 2: виконавець отримує перевірену відповідь плюс обмежений запит: зробіть цю зміну поведінки, у цій області, і перевірте її таким чином.

тримайте ролі окремими

ви можете вибрати одного виконавця для обох ролей.

Корисна відмінність полягає в їхній відповідальності та доступі, з явним оглядом між дослідженням та редагуванням.

я б уникав створення каталогу спеціалістів до того, як хтось із них виконає корисну роботу. Почніть з обов'язків, які ви дійсно можете розрізнити. Якщо ви не можете пояснити, чим володіє роль або як виглядає її готовий результат, звужте роль, перш ніж додавати іншого агента.

3.1 Рецензент: бриф, який робить невизначеність видимою

виберіть рецензента та прикріпіть відповідну розмову, використовуючи @Claude, @Codex, @OpenCode або @Cursor. Вибрані посилання стають замороженим контекстом для запуску та передаються обраному агенту, коли завдання починається. посилання

скопіюйте цей бриф і заповніть поля:

1Перегляньте попереднє рішення щодо [функція або підсистема], використовуючи
2прикріплену розмову та поточний репозиторій.
3
4Поясніть оригінальне рішення та його заявлену причину. Перевірте
5відповідний код та визначте, що все ще застосовується, що змінилося, а що
6неможливо перевірити з наявних доказів.
7
8Наведіть файли, що підтверджують ваші висновки. Запропонуйте найменшу
9зміну, необхідну для [бажана поведінка], з планом верифікації.
10
11Не редагуйте файли. Ставтеся до розмови як до історичного доказу
12та позначайте конфлікти з поточними інструкціями проєкту.

перевірте огляд

прочитайте відповідь, маючи відкритий репозиторій.

1. перейдіть за цитуванням.
2. перевірте умову, яку, за словами агента, все ще існує.
3. шукайте чітке розмежування між тим, що стверджувала розмова, і тим, що демонструє код сьогодні.

якщо відповідь розпливчаста, звужте питання. Попросіть його визначити точну умову, яка контролює поведінку, або залежність, яка зробила попередню альтернативу непридатною.

Корисне дослідження може завершитися відсутністю доказів. Це говорить вам, що надати далі. Відповідь, яка згладжує прогалину, ускладнює наступне рішення.

3.2 Передача: перетворіть висновки на виконуваний бриф

коли ви погодитеся з оглядом, напишіть запит на реалізацію на основі спостережуваної поведінки. Включіть обмеження, встановлене попередньою розмовою, але поясніть його актуальність для цієї зміни.

Ось бриф, який я б використав:

1Реалізуйте [конкретна поведінка], використовуючи переглянуті висновки нижче.
2
3Залиште [існуюча поведінка] недоторканою. Обмежте редагування [дозволеною областю].
4Якщо зміна вимагає роботи за межами цієї області, поясніть чому, перш ніж
5розширювати її.
6
7Перевірте поточні інструкції репозиторію перед редагуванням. Підтвердьте
8[очікуваний результат] за допомогою [відповідний тест або ручна перевірка], включаючи
9[важливий випадок невдачі].
10
11Поверніть стислий звіт про те, що змінилося, фактично виконані перевірки
12та будь-які невирішені обмеження. Не публікуйте та не розгортайте.
13
14Переглянуті висновки:
15[вставте висновки, які ви перевірили]

зробіть передачу конкретною

ці дужки заслуговують реальних відповідей. "Зробити краще" залишає агенту вигадувати ціль. "Показати невдалий експорт з дією повтору, зберігаючи оригінальну помилку" дає вам обом щось конкретне для перевірки.

Тримайте переглянуті висновки близько до завдання. Якщо важливе обмеження поховане всередині довгого транскрипту, викладіть його в брифі та прикріпіть відповідну розмову.

Джерело пояснює, звідки взялося обмеження. Ваш поточний запит пояснює, як воно регулює сьогоднішню роботу.

4. Вправа з проєкту: проведіть повторювану помилку через весь цикл

Ось гіпотетична вправа, щоб зробити робочий процес конкретним. Уявіть, що ваш проєкт іноді створює дублікати експортів після переривання мережі, і старіша розмова містить дослідження поведінки повтору.

1. крок 1: спочатку знайдіть цю розмову. Попросіть рецензента визначити, що встановило попереднє дослідження, а потім перевірте поточний шлях повтору на відповідність йому.
2. крок 2: припустимо, стара дискусія каже, що запити можна повторювати після невизначеної відповіді. Рецензент повинен встановити, чи поточна реалізація все ще дозволяє це, який код це контролює, і чи вже існує механізм, призначений для запобігання дублікатам.
3. крок 3: якщо докази підтримують зміну, дайте виконавцю бриф навколо випадку невдачі. Вкажіть, що має робити повторний запит, яка існуюча поведінка експорту повинна залишитися, і як ви перевірите перервану відповідь.
4. крок 4: потім перевірте зміну та протестуйте відповідний шлях. Перевірте як успішний експорт, так і повтор після невизначеності. Якщо середовище не може відтворити переривання, запишіть це обмеження та вирішіть, яка подальша верифікація потрібна.
5. крок 5: нарешті, перегляньте урок, який ви можете зберегти: умови, що спричинили дублікат, механізм, який його усуває, та докази, що підтверджують виправлення.

Цей приклад є запропонованою вправою, а не твердженням про помилку в agentic stack. Замініть реальну невдачу з вашого власного проєкту та дотримуйтесь тієї ж послідовності.

5. Спільний рівень: додайте пошук у ваші інші інструменти

десктоп може встановити інтеграцію через Tools → Connections → Use @ in tools → Enable in all four tools. Еквівалентна команда:

1agentic-stack context install

перезапустіть інструменти після цього. Точка входу MCP відкриває пошук розмов, читання вибраних чатів та пошук спільної пам'яті. інтеграція

Поведінка вибору залежить від клієнта; якщо завершення ресурсу недоступне, агент може шукати та показувати відповідні розмови. поведінка клієнта

перевірте безперервність між інструментами

моєю першою перевіркою було б попросити інший інструмент знайти те саме рішення, яке ви щойно переглянули. Дайте йому тему, попросіть його показати відповідне джерело та підтвердьте вибір, перш ніж просити аналіз.

Потім порівняйте результат із джерелом, яке ви перевірили в десктопі. Ви тестуєте безперервність контексту між інструментами, тому тримайте питання стабільним, змінюючи місце, де ви його задаєте.

я б також включав джерело в кінцевий бриф завдання щоразу, коли рішення суттєво впливає на роботу. "Ми обговорювали це раніше" дає агенту проблему пошуку. "Використовуйте цю переглянуту розмову та перевірте цю умову" дає йому конкретну відповідальність.

6. Довговічний рівень: що заслуговує стати уроком

пошук повертає старі матеріали в поле зору. Ви все ще повинні вирішити, який авторитет цей матеріал повинен нести.

Розмова може містити покинутий план, неправильний діагноз або відповідь, яка була розумною до того, як проєкт змінився. Збереження дозволяє вам перевірити міркування пізніше; прийняття уроку — це окреме рішення.

Tasks містить записи виконання. Knowledge → Lessons підтримує підготовку, прийняття, відхилення та перегляд уроків із зазначенням причин, тоді як імпортована історія залишається окремою від прийнятих уроків. життєвий цикл перегляду

напишіть урок, який можна оскаржити

я б написав запропонований урок з достатньою деталізацією, щоб його можна було оскаржити: умова, до якої він застосовується, рекомендована поведінка, причина та докази.

Для гіпотетичної помилки експорту "завжди безпечно повторювати" занадто розпливчасто, щоб бути корисним. Корисна нотатка визначає, що робить повтор невизначеним і як реалізація цього проєкту повинна розпізнавати повторювану роботу.

Потім запитайте, що зробило б урок застарілим. Інший бекенд, змінений контракт або замінена підсистема можуть усунути початкове обмеження. Включіть цю межу, щоб майбутній перегляд мав з чого почати.

Ось як я б зберіг корисне виправлення, не перетворюючи його на правило, яке переживе свою причину.

6.1 Структура пам'яті: розмістіть кожен вид знань на своєму місці

Під десктопом портативна архітектура .agent/ відокремлює робочий стан, попередні епізоди, довговічні шаблони та особисті вподобання. Skills надають процедури, що використовуються повторно, тоді як protocols описують дозволи та делегування. архітектура

• поточне дослідження належить до роботи в процесі.
• його завершений звіт стає доказом того, що сталося.
• перевірений шаблон може стати довговічним уроком.
• вподобання щодо того, як ви хочете бачити результати, належить до ваших вподобань.

Збереження цих значень чіткими полегшує подальший перегляд. Тимчасовий обхідний шлях повинен пояснювати, коли його можна видалити. Особисте вподобання щодо написання не повинно випадково стати архітектурним правилом.

перетворіть перевірену процедуру на навичку

те саме стосується навичок. Я б створив навичку, коли процедура досить корисна для повторення та досить конкретна для виконання. Включіть необхідні вхідні дані, важливі кроки, очікуваний результат та умови, що вимагають іншого рішення.

Для прикладу експорту дослідження може дати корисну процедуру перевірки регресії. Збережіть її лише після того, як підтвердите, що кроки працюють у вашому проєкті. Скопійований транскрипт дає наступному агенту історію; перевірена процедура дає йому метод, який ви можете оцінити.

7. Робочі правила: коротко, обмежено, перевіряємо

Ось правила, які я б встановив навколо робочого процесу з першого проєкту.

1. правило 1: кожен бриф називає результат. Огляд повертає висновки з доказами. Реалізація повертає зміну поведінки з перевірками. Пропозиція уроку повертає твердження, яке ви можете прийняти або відхилити.
2. правило 2: доступ відповідає роботі. Дослідження починається з доступу лише для читання; реалізація отримує область, необхідну для узгодженої зміни. Тримайте публікацію, розгортання та інші важливі дії явними в запиті.
3. правило 3: вимагайте фактичної верифікації. Звіт повинен говорити, що було запущено і що сталося. Якщо перевірка була недоступна, зробіть це видимим, а не тихо вважайте відсутній результат успіхом.
4. правило 4: тримайте історичний контекст підпорядкованим поточним доказам та застосовним інструкціям проєкту. Знайдена розмова може пояснити попереднє рішення, все ще будучи застарілою.
5. правило 5: перегляньте результат, перш ніж зберігати висновок. Пояснення агента своєї власної роботи — це те, що потрібно перевіряти разом із diff та спостережуваною поведінкою.

Це робочі практики для налаштування, яке я описую. Адаптуйте їх до свого проєкту, але тримайте обов'язки досить чіткими, щоб інша людина могла визначити, чи виконало завдання свій бриф.

7.1 Черга перегляду: зробіть роботу легкою для прийняття або повернення

я б просив кожну реалізацію завершуватися в однаковій формі:

• що змінилося,
• що було перевірено,
• що залишається невизначеним,
• і чи пропонує вона урок, який можна використовувати повторно.

Це дає вам послідовний спосіб читати завершену роботу без необхідності відновлювати всю розмову щоразу. Допоміжні деталі можуть залишатися доступними для частини, яку вам потрібно перевірити.

Коли ви повертаєте щось назад, прикріпіть виправлення до вимоги, яку воно пропустило. "Це неправильно" починає черговий раунд вгадування. "Повтор створює другий експорт за цієї умови; збережіть ідентичність оригінального запиту та повторіть цю перевірку" визначає прогалину.

вирішіть, що заслуговує на збереження

після того, як виправлення пройде, вирішіть, чи представляє воно повторюване обмеження чи деталь цього завдання. Зберігайте перше, коли за ним стоять докази. Останнє може залишитися в історії завдання.

я б чинив опір перетворенню кожного коментаря до огляду на постійну пам'ять. Деякі виправлення корисні один раз. Інші розкривають правило, яке має формувати подальшу роботу. Проведення цього розмежування є частиною підтримки системи.

Корисне питання в кінці огляду: що має знати майбутній агент, перш ніж намагатися виконати подібне завдання, і де він може перевірити це знання?

7.2 Дисципліна витрат: дайте кожному запуску умову зупинки

я б включив умову зупинки в будь-яке завдання, яке може продовжувати розширюватися. Для огляду це може бути письмовий звіт про відповідну поведінку та невирішені питання. Для реалізації це може бути узгоджена зміна, яка проходить свої названі перевірки.

Якщо агент виявляє більшу проблему, попросіть його пояснити знахідку та її зв'язок з оригінальним завданням, перш ніж включати цю роботу в поточну зміну.

Вирішіть, чи належить це поточному завданню.

порівнюйте результати та застосовуйте обмеження

виберіть виконавця та модель, використовуючи варіанти, фактично доступні у вашому обліковому записі, а потім оцініть їх на власних обмежених прикладах. Я б порівняв якість висновків, необхідні виправлення та доставлену верифікацію, перш ніж зробити одну конфігурацію стандартною.

Зробіть експеримент справедливим, утримуючи завдання та вихідний матеріал стабільними. Якщо кожна спроба змінює питання, контекст та критерії прийнятності, порівняння буде важко інтерпретувати.

і розмістіть будь-які обмеження витрат там, де вони фактично застосовуються вашими інструментами або провайдером. Речення, яке просить агента бути економним, є вподобанням; перевірте доступні обмеження, перш ніж покладатися на ліміт.

8. Індивідуальна збірка: змініть робочий простір навколо реальної проблеми

після того, як ви завершите базовий цикл, у вас буде краще уявлення про те, чого ви хочете від самого десктопа. Можливо, вас дратує повторюваний крок навігації, або подання завдання робить поле важчим для перевірки, ніж потрібно.

Запишіть проблему, перш ніж пропонувати функцію. Опишіть дію, яку ви намагаєтеся виконати, де ви втрачаєте час, і що покращена поведінка дозволила б вам робити.

Потім відкрийте вихідний репозиторій і дайте своєму агенту запит на обмежену зміну. Включіть, як ви маєте намір перевірити результат у додатку.

зберіть та перевірте зміну

репозиторій документує ці команди розробки та пакування:

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

команди розробки

Зміни SwiftUI вимагають перезбірки та перезапуску для перевірки. робочий процес десктопа

я б протестував взаємодію, яка спричинила зміну, та сусідній випадок, який міг би зламатися. Якщо ви покращуєте фільтрацію завдань, перевірте відфільтровані результати, порожній набір результатів та шлях назад до повного списку.

Використовуйте той самий стандарт, який ви застосували до вправи з експортом: конкретне "до", обмежена зміна та спостережуване "після".

8.1 Віддалений варіант: вирішіть, де має жити робота

після того, як локальний робочий процес запрацює, ви можете захотіти виконання на постійному сервері. Шлях самостійного хостингу з'єднує рідний додаток із сервісом одного власника, якому належать його проєкти, пам'ять, історія завдань та входи в CLI; зміна хостів не передає автоматично дані вашого Mac або облікові дані. посібник з хостингу

Я б зробив цей крок з конкретної причини, наприклад, щоб залишити проєкт і його середовище виконання на машині, яку ви вже обслуговуєте. Запишіть цю причину, перш ніж братися за розгортання.

Дотримуйтесь посібника з хостингу для підтримуваної конфігурації, етапів автентифікації та перевірки. Ставтеся до сервера як до ще одного робочого середовища з власним станом, який потрібно перевіряти.

перевірте вибране середовище

Потім виконайте там знайоме завдання. Перевірте вибраний проєкт, підтвердьте, що агент має доступ до потрібного джерела, і переконайтеся, що результат належить саме тому серверному середовищу, яке ви обрали.

Використання відомого завдання полегшує оцінку переходу. Якщо ви одночасно зміните хост, проєкт і робочий процес, стане важче визначити, яка саме зміна призвела до несподіваного результату.

Локального середовища достатньо, щоб засвоїти основну схему. Розширюйте інфраструктуру, коли робота дасть вам на це причину.

9. масштабування: додайте покриття там, де попередній цикл виявив прогалину

Я б розширював цю конфігурацію відповідно до відсутнього контексту, який ви зустрічаєте під час реальних завдань.

• якщо для перевірки знадобилося раніше обговорення архітектури, імпортуйте це обговорення.
• якщо для реалізації неодноразово потрібна була одна й та сама процедура, розробіть і перевірте навичку.
• якщо рішення постійно переглядається, напишіть обмежений урок із доказами, які його підтверджують.

Тримайте невелику колекцію запитань, відповіді на які ви вже знаєте. Використовуйте їх після зміни імпортів або робочого процесу: знайдіть це рішення, поясніть це обмеження, визначте код, який його реалізує, і позначте частину, яка вже не актуальна.

розширюйте, коли робота це виправдовує

Я б додавав нову роль агента лише тоді, коли її відповідальність стає зрозумілою з роботи. Регулярний перегляд документації може виправдати окремий бриф. Одноразовий запит може ідеально вписатися в існуючу роль.

Розширюйте ті частини, які заслужили своє місце. Решту тримайте достатньо простою, щоб зрозуміти, коли щось піде не так.

9.1 звичка підтримки: переглядайте знання, коли змінюється система

Я б переглядав відповідні уроки щоразу, коли підсистема змінюється настільки, що впливає на їхні припущення. Використовуйте саму зміну як тригер: нова залежність, замінений рівень зберігання даних, інше середовище розгортання або переглянута вимога до продукту.

Запитайте, які існуючі уроки залежать від старої поведінки, потім перевірте ці джерела разом зі зміною. Залиште те, що все ще актуальне, перегляньте те, що потребує вужчого обсягу, і видаліть те, що більше не застосовується, через доступний робочий процес перегляду.

Важливою частиною є збереження пояснення. Майбутній розробник повинен мати змогу зрозуміти, чому існувало попереднє правило і що змінилося настільки, щоб його замінити.

оновлюйте процедури та вирішуйте конфлікти

Для навичок запустіть процедуру знову після зміни, яка впливає на її вхідні дані або команди. Якщо крок більше не працює, оновіть процедуру на основі спостережуваної помилки та повторіть відповідну перевірку.

Це підтримує зв'язок обслуговування з реальними подіями в проєкті. Ви переглядаєте знання, які, найімовірніше, застаріли, маючи перед собою актуальні докази.

Коли завдання виявляє суперечливі нотатки, зробіть вирішення цього конфлікту частиною перегляду. Визначте, яке твердження стосується поточної версії, і залиште результат достатньо зрозумілим, щоб наступний агент міг слідувати логіці, не повторюючи все дослідження.

залиште корисну передачу справ

Перед наступним сеансом залиште коротку передачу справ, яка описує перевірений результат, відкрите питання та джерело, яке інший агент має прочитати в першу чергу. Тримайте її конкретною щодо стану проєкту, який ви фактично перевірили.

Це дасть завтрашній роботі відправну точку, яку можна простежити, особливо коли ви повертаєтеся через інший інструмент або після перерви, маючи все ще доступну початкову логіку.

10. аркуш збірки

1. виберіть знайомий репозиторій і рішення, яке ви можете розпізнати.
2. зберіть десктоп, виконайте налаштування та імпортуйте завершену розмову, яка містить це рішення.
3. знайдіть його, перевірте джерело та прикріпіть до перегляду поточного коду лише для читання.
4. самостійно перевірте результати, потім підготуйте обмежену реалізацію з видимою умовою прийняття.
5. перевірте diff та виконайте відповідну верифікацію, включаючи випадок невдачі, який мотивував роботу.
6. створюйте урок лише тоді, коли результат його підтримує, із зафіксованим обсягом і причиною.
7. перетворюйте процедуру на навичку, коли ви переконалися, що її варто повторювати.
8. спробуйте той самий пошук з іншого інструменту, потім розширюйте свій контекст або інфраструктуру, коли реальне завдання цього вимагатиме.

почніть з одного рішення цього тижня і проведіть його через весь цикл, перш ніж імпортувати всю свою історію.

наступний агент має успадкувати ваше судження.