Хигиена на инструкциите: Какво все още трябва да съобщаваме на AI моделите
В официална публикация в блога на .NET от Microsoft [1], авторът Уенди Брайдинг разглежда критичната тема за „хигиената на инструкциите“ при работа с авангардни големи езикови модели (LLM). Според анализа, файловете с инструкции за разработка в рамките на софтуерните проекти имат вредния навик да се разрастват само в една посока: когато моделът направи грешка, разработчиците добавят ново правило; когато даден инструмент се промени, се вмъква заобиколно решение (workaround); а при появата на нов модел, старите насоки остават непроменени. Този процес бързо превръща файловете в хаотична смес от ръководства за въвеждане в експлоатация, дневници на минали проблеми и капсули на времето от остарял промпт инженеринг.
Изображение: Svetni.me / ИИ генерирано изображение
Въпреки че оставянето на всяка възможна инструкция изглежда като по-безопасен подход за предотвратяване на грешки, на практика това прави изкуствения интелект по-малко ефективен. Съвременните модели изискват значително по-малко процедурно напътствие в сравнение с предшествениците си. Те се справят отлично с изследването на директории, разпознаването на общи рамки и възстановяването от стандартни грешки при изпълнение. Те обаче все още нямат достъп до вътрешните решения, скритите архитектурни ограничения и специфичния оперативен опит на вашия екип.
Изображение: Svetni.me / ИИ генерирана инфографика
Концепцията за „хигиена на инструкциите“ и контекстният бюджет
Целта на хигиената на инструкциите не е просто съкращаване на текстовите файлове с цел пестене на място. Тя се стреми да запази възможно най-малкия набор от информация с високо качество на сигнала, който реално променя резултатите от работата на модела. Всеки ред в инструкциите се конкурира директно за ограниченото внимание на модела с текущата задача на разработчика, анализирания код, резултатите от инструментите, хронологията на разговора и останалите правила.
Големите контекстни прозорци на съвременните модели не означават, че допълнителните токени са безплатни. От Anthropic описват ефективното контекстно инженерство като процес на намиране на най-малкия набор от високосигнални токени, които максимизират вероятността за желания резултат. Насоките от GitHub за GitHub Copilot по подобен начин препоръчват инструкциите да се ограничават до кратък преглед на проекта, технологичния стек, основните насоки за кодиране, структурата на проекта и препратки към ключови ресурси [1].
Важно е да се отбележи, че оригиналният текст на Microsoft се фокусира върху практическите аспекти на управлението на инструкциите на ниво хранилище (repository instructions) и не разглежда теми като разграничението между системни и потребителски инструкции, префиксни/суфиксни инструкции, техники за подсилване (reinforcement techniques) или специфични емпирични бенчмаркове. Въпреки това, от гледна точка на приложното контекстно инженерство, внедряването на „добра хигиена“ включва разделяне на системните граници, избягване на излишно дублиране и въвеждане на ясни префикси, за да се гарантира, че моделът няма да игнорира критичните правила при дълги сесии на работа.
Какво все още трябва да споделяме с моделите
Авангардните модели притежават големи интелектуални способности, но нямат локално познание за спецификите на вашия проект. Инструкциите са най-полезни, когато предоставят информация, която е специфична, важна за крайния резултат и трудна за извеждане чрез обикновен анализ на кода:
Неочевидни факти за системата: Опишете накратко предназначението на хранилището и посочете архитектурните граници, които лесно могат да бъдат разбрани погрешно (например, коя услуга притежава публичния HTTP договор, кои папки съдържат автоматично генериран код или кои наследени модули все още са критични за производството).
Най-краткият надежден път за валидация: Документирайте авторитетните команди, които моделът трябва да изпълнява за компилация, тестване и проверка (особено когато очевидната команда е непълна или грешна). Това спестява време за изследване и дава конкретна дефиниция за успешно свършена работа.
Локални избори, които кодът не може да реши сам: Ако съществуват няколко разумни технологични подхода, изрично посочете кой е избран от екипа (например използване на конкретна библиотека за тестове, предпочитане на минимални API пред контролери или използване на споделен TimeProvider вместо директно извикване на системния часовник).
Твърди ограничения и критични грешки: Укажете кои аспекти не трябва да се променят при никакви обстоятелства поради съображения за сигурност, съвместимост или съответствие с регулации (например запазване на JSON договорите, забрана за запис на клиентски данни в лог файловете или изискване за обратно съвместими миграции на бази данни).
Локация на източника на истина: Вместо да копирате цялата документация, използвайте принципа на прогресивно разкриване (progressive disclosure). Насочете модела към файлове с архитектурни решения, правила за дизайн на API или конфигурации за версии на средата [1].
Какво трябва да премахме от файловете с инструкции
Най-бързият начин да подобрите един остарял файл с инструкции е чрез изваждане на ненужните елементи. Елиминирането на следните категории информация значително подобрява производителността на моделите:
Общи съвети за софтуерно инженерство: Моделите вече знаят правила от рода на „пишете чист код“, „следвайте добрите практики“ или „обработвайте грешките правилно“. Тези фрази са твърде неясни, за да помогнат при реални решения. Заменете ги с конкретни локални стандарти (например как точно да се мапират грешките при валидация към HTTP кодове).
Изчерпателни описания на директориите: Пълните списъци на папките бързо остаряват и само дублират информация, която моделът може да извлече сам за секунди. Включвайте само пътища, чиято цел е неочевидна или променя начина на разработка.
Правила, които вече се налагат от инструментите: Не описвайте форматиране на кода или настройки на компилатора, които се прилагат автоматично. Вместо това просто посочете командата за проверка на форматирането (например
dotnet format).Дублирана документация: Копирането на README файлове или наръчници за архитектурата увеличава разходите за поддръжка и създава условия за противоречия. Направете резюме на конкретното решение и дайте връзка към оригиналния източник.
„Промпт фолклор“ и психологическо напътствие: Фрази като „поеми си дъх“, „мисли стъпка по стъпка“ или „действай като архитект от световна класа“ не носят проектно знание. Съвременните модели нямат нужда от театрално насърчаване, а твърдите процедурни изисквания могат да влязат в конфликт с инструментите на средата [1].
Обхват и методология за поддръжка на инструкциите
Не всяко правило принадлежи на глобално ниво в проекта. GitHub Copilot, например, поддържа глобални инструкции в .github/copilot-instructions.md, специфични за определени пътища файлове под .github/instructions/ и агентски инструкции като AGENTS.md. Когато са налични и двата типа, те се комбинират. Добра практика е правилата за тестване на React компоненти да не натоварват модела по време на миграция на бази данни – те трябва да бъдат преместени в локален файл за съответната директория.
За поддържане на хигиената се препоръчва прилагането на рамката „Запази, премахни, премести, провери“ при всеки преглед:
Запази: Информация, която все още е вярна, важна и не може да бъде изведена от самия код.
Премахни: Насоки, които моделът вече разбира, инструментите налагат или са остарели.
Премести: Правила, които са полезни, но се отнасят за конкретен път или трябва да бъдат в отделен документ.
Провери: Инструкции за версии, команди или заобиколни решения, които може да са се променили.
След прегледа е важно да тествате съкратения файл върху реална и ограничена задача, да наблюдавате къде моделът греши и да добавяте само минималния обем контекст, за да коригирате поведението му. В крайна сметка здравословният файл с инструкции трябва да позволява на способния модел да започне полезна работа веднага, без да се налага да му обясняваме как да бъде способен модел [1].
Източници
- Breiding, W. Instructions Hygiene – What Frontier Models Still Need You to Say. .NET Blog, Microsoft, 2026. devblogs.microsoft.com