През последните няколко години всички свикнахме с идеята, че ако искаме по-добър резултат от изкуствения интелект, трябва просто да напишем по-добър промпт.
При съвременните AI модели това вече е само част от картината.
Когато използвам Claude, Claude Code, Cursor или друг AI агент, все по-малко мисля за промпта като за въпрос към чатбот. Гледам на него по-скоро като на задание към човек, който разполага с инструменти, файлове, интернет, код и понякога достъп до цели системи.
Казвам се Олег Петров и голяма част от ежедневната ми работа вече минава точно по този начин. Работя с WordPress, разработвам DiveWP, използвам AI coding агенти и постоянно експериментирам с това как да им давам достатъчно контекст и инструменти, за да могат реално да свършат работата, а не просто да ми дадат красив текстов отговор.
Затова ми стана особено интересно новото официално ръководство на Anthropic за prompt engineering при Claude Fable 5.1.
В него вече не става дума само за класическите съвети от типа „бъдете конкретни“ или „дайте повече контекст“. Anthropic разглежда много по-практични проблеми: кога моделът да търси информация, как да използва инструменти, как да работи по дълги задачи, кога да действа самостоятелно, как да не променя излишен код и дори колко изчислително усилие е необходимо за конкретната задача.
Тук съм събрал нещата, които според мен са най-полезни за реална работа, и съм ги превел от документация на нормален човешки език.
1. Спрете да търсите „магическия промпт“
Това според мен е първото нещо, което трябва да променим в начина си на мислене.
Няма универсален промпт, който да превърне всеки AI модел в гений.
Има добре поставена задача.
Например вместо:
Направи ми WordPress плъгин за управление на резервации.
бих написал нещо подобно:
Искам WordPress плъгин за управление на резервации. Преди да започнеш разработката, анализирай структурата на проекта и съществуващите WordPress стандарти. След това направи кратък план. Реализирай функционалността изцяло, провери критичните части и накрая ми дай обобщение какво е направено и какво остава.
Това вече не е просто въпрос към AI. Това е задание.
Колкото повече използваме AI за реална работа, толкова повече според мен трябва да комуникираме с него точно по този начин.
2. Повече „мислене“ не означава автоматично по-добър резултат
Claude Fable 5.1 предлага различни нива на effort: low, medium, high, xhigh и max.
Anthropic препоръчва да не приемаме автоматично, че най-високата настройка винаги е най-добрият избор. По-високият effort може да означава повече изчисления, повече време и по-висока цена.
Аз бих го разглеждал много практично:
- За кратко обобщение или елементарна редакция не ми е необходим максимален effort.
- За проучване, което изисква няколко източника, бих дал повече ресурс.
- За архитектура на приложение, сложен debugging или голяма coding задача вече има смисъл от по-високо ниво.
Тоест целта не е винаги да използваме най-мощната настройка.
Целта е да използваме достатъчно мощната настройка за конкретната работа.
3. Кажете на AI да завърши задачата
Това изглежда очевидно, но всеки, който работи по-дълго с AI coding агенти, вероятно се е сблъсквал с подобна ситуация.
Давате голяма задача. Агентът започва работа и след известно време отговаря:
Следващата стъпка ще бъде да…
или:
Искате ли да продължа?
Въпреки че още в началото сте му казали какво трябва да направи.
При по-дълги задачи Anthropic препоръчва ясно да се укаже, че моделът трябва да продължи работата и да завърши поставената задача, вместо да иска разрешение за всяка следваща логична стъпка.
Една инструкция, която аз бих използвал, е:
Изпълни задачата докрай. Не ме питай дали да продължиш със следващата логична стъпка, ако тя вече е част от поставената задача. Спри само ако липсва информация или решение, без което не можеш безопасно да продължиш.
Звучи елементарно, но подобно правило може да промени сериозно поведението на един AI агент.
4. Независимите действия не трябва да се изпълняват едно по едно
Представете си, че дам следната задача:
Провери документацията на WordPress, намери актуалната информация за Abilities API, анализирай структурата на плъгина и провери съществуващите тестове.
Голяма част от тези действия не зависят едно от друго.
Няма причина агентът задължително да:
- провери първия източник;
- изчака резултата;
- провери втория;
- изчака отново;
- отвори проекта;
- чак след това да провери тестовете.
Anthropic препоръчва независимите tool calls да бъдат групирани и изпълнявани паралелно, когато архитектурата на системата го позволява.
В собствените си инструкции към агент бих го формулирал така:
Преди да започнеш работа, определи кои източници и инструменти ще са ти необходими. Когато няколко действия не зависят едно от друго, изпълнявай ги паралелно.
При една малка задача разликата може да е незабележима. При агентен workflow с десетки извиквания към инструменти вече може да спести сериозно време.
5. Не приемайте, че AI знае какво е актуално днес
Това за мен е едно от най-важните правила.
Работим в индустрия, в която нещо, което е било вярно преди шест месеца, днес може вече да е остаряло.
Това важи особено за:
- AI модели и AI услуги;
- Claude, ChatGPT и други асистенти;
- Cursor и AI coding инструменти;
- WordPress и WooCommerce;
- MCP;
- API-та и SDK-та;
- JavaScript библиотеки и framework-и.
В документацията за Fable 5.1 Anthropic отбелязва, че особено при по-нисък effort моделът може по-често да разчита на наличните си знания вместо автоматично да използва search или retrieval.
Затова една от постоянните ми инструкции би била:
Когато задачата се отнася до AI модели, API, библиотеки, WordPress версии или други бързо развиващи се технологии, не разчитай само на собствените си знания. Провери актуалната официална документация, преди да дадеш окончателен отговор.
Да разпознаваш името на една технология не означава, че знаеш актуалното ѝ състояние.
Това е изключително важна разлика.
6. Контекстът вече е по-важен от „умния промпт“
Тук стигаме до нещо, което според мен е много по-важно от класическия Prompt Engineering: Context Engineering.
Ако дам на Claude задача с три изречения, той трябва сам да предполага огромно количество информация.
- Как е структуриран проектът?
- Какви стандарти използвам?
- Какви решения вече сме взели?
- Какво не трябва да променя?
- Какви библиотеки използваме?
- Как изглеждат данните?
- Какви инструменти има на разположение?
Колкото повече от тази информация AI има предварително, толкова по-малко е принуден да предполага.
При agentic development това според мен е фундаментално.
Тук WordPress също започна сериозно да се променя. WordPress Abilities API предоставя стандартизиран начин WordPress, плъгините и темите да описват какви действия могат да извършват, какви са входните и изходните им данни и какви права са необходими.
Това позволява на AI системите да получават много по-структурирана информация за възможностите на даден сайт.
Разглеждам темата по-подробно във видеото ми WordPress AI & Abilities API for the 6.9 update – Explained!.
За мен точно тук е следващата голяма стъпка.
Не просто да обясним по-добре на AI какво искаме.
Да му дадем правилната среда, правилния контекст и правилните инструменти, за да може действително да го направи.
7. Не позволявайте на AI да „оправя“ всичко, което види
Това е класически проблем при AI coding.
Казвате:
Промени начина, по който се валидира тази форма.
Агентът отваря файла и междувременно вижда:
- функция, която според него може да бъде оптимизирана;
- стар naming convention;
- CSS, който може да бъде пренаписан;
- няколко липсващи теста;
- код, който може да бъде рефакториран.
И изведнъж вместо промяна на 20 реда получавате diff от 600 реда.
Anthropic конкретно препоръчва да поставяме ясни ограничения върху подобно поведение.
Ако AI открие съществуващ проблем, който не е част от задачата, не е необходимо автоматично да го поправя.
Аз бих използвал правило като:
Не прави промени извън обхвата на задачата. Ако откриеш друг проблем, който не блокира настоящата работа, отбележи го в края като препоръка, но не го променяй.
Това е особено важно, когато AI работи върху реален production проект.
8. Ако трябва да промените пет реда, не пренаписвайте 800
Друг много практичен проблем е пренаписването на цели файлове.
Ако трябва да бъдат променени пет реда в PHP файл от 800 реда, обикновено няма причина AI да генерира отново целия файл.
Това има няколко недостатъка:
- използва повече tokens;
- отнема повече време;
- създава ненужно голям diff;
- увеличава риска да бъде променен код, който няма общо със задачата.
Anthropic препоръчва при малки и средни промени да се предпочитат targeted edits вместо пренаписване на целия файл.
Една проста инструкция:
При промяна на съществуващ код редактирай само необходимите участъци. Не пренаписвай целия файл, освен ако голяма част от него действително трябва да бъде променена.
Малка инструкция, но изключително полезна в ежедневната работа.
9. Инструментите променят изцяло какво означава „добър AI“
Според мен тук много хора все още гледат на изкуствения интелект по стария начин.
Питаме го нещо и той ни отговаря.
Но един съвременен AI агент вече може да разполага с достъп до:
- файлова система;
- browser и web search;
- terminal;
- Git;
- бази данни;
- API-та;
- WordPress;
- MCP сървъри;
- вътрешни бизнес системи;
- документация и knowledge bases.
В този момент въпросът вече не е само:
Колко е умен моделът?
Все по-важен става въпросът:
С какъв контекст и инструменти разполага моделът и знае ли кога да ги използва?
Точно с това експериментирам и в DiveWP. Чрез WordPress Abilities API и MCP AI агент може да получава структурирана информация от WordPress и да използва конкретни способности, които плъгинът предоставя.
Показвам практически как работи това във видеото Добавих безплатен ПРО Cron Job Manager + интеграция с AI през MCP в DiveWP!.
За мен това е посоката, в която ще се развива голяма част от AI софтуера.
Моделът може да бъде мозъкът, но контекстът и инструментите са неговите очи и ръце.
10. Не карайте AI да пише сложно, за да изглежда умен
Това е друг интересен момент от препоръките на Anthropic.
При Fable 5.1 текстът в определени ситуации може да стане по-плътен: по-дълги изречения, по-малко разделяне на параграфите и повече информация в един блок.
Технически отговорът може да е правилен, но да бъде неприятен за четене.
Затова когато искам текст, който ще бъде четен от реални хора, бих дал ясни инструкции за стила:
Пиши директно и ясно. Използвай нормални кратки параграфи. Когато изброяването подобрява четимостта, използвай списък. Не използвай технически жаргон без причина и обяснявай специализираните понятия, когато аудиторията може да не ги познава.
Това е много по-полезно от общата инструкция:
Пиши професионално.
„Професионално“ може да означава сто различни неща.
11. Когато AI анализира изображения, дайте му възможност да вижда детайлите
Fable 5.1 има силни възможности за работа с изображения, но Anthropic препоръчва при сложни изображения, диаграми и интерфейси моделът да разполага и с възможност да увеличава или изрязва конкретни области.
И това отново ни връща към същия принцип:
Не очаквайте моделът магически да разполага с информация, до която не сте му дали достатъчно добър достъп.
При голям screenshot например инструкцията:
Анализирай изображението.
е по-слаба от:
Анализирай интерфейса. Ако даден текст или компонент не се вижда достатъчно ясно, увеличи съответната област и я провери отделно, преди да направиш заключение.
12. Базов промпт, който бих използвал за AI агент
Ако трябва да събера голяма част от тези принципи в една основна инструкция за coding или research агент, бих започнал приблизително така:
Работи по поставената задача автономно и я довърши изцяло.
Преди да започнеш, разбери крайния резултат, ограниченията и наличния контекст.
Когато ти е необходима актуална информация за бързо променяща се технология, AI модел, API или библиотека, провери официалните източници, вместо да разчиташ само на собствените си знания.
Ако са необходими няколко независими проверки или tool calls, изпълнявай ги паралелно, когато е възможно.
Не ме питай дали да изпълниш следващата логична стъпка, когато тя вече произтича от поставената задача.
При промяна на код се придържай към обхвата на задачата. Не извършвай несвързан refactoring и не добавяй функционалности, които не са поискани.
При малки промени редактирай конкретните участъци вместо да пренаписваш цели файлове.
Ако откриеш допълнителен проблем, който не блокира задачата, отбележи го в края като препоръка.
Преди да приключиш, провери дали задачата действително е завършена и обобщи какво си направил, как си го проверил и дали има нещо, което изисква допълнително внимание.
Това не е „перфектният промпт“.
Такъв според мен няма.
Това е добра основа, която след това трябва да бъде адаптирана към конкретната задача, проект и среда.
Prompt Engineering постепенно се превръща в управление на AI
За мен това е най-важният извод от всичко дотук.
Преди няколко години се опитвахме да намерим правилните думи, с които да накараме един езиков модел да даде по-добър отговор.
Днес вече говорим за цяла система от неща:
- промпт;
- контекст;
- инструменти;
- права за достъп;
- effort;
- паралелно изпълнение;
- търсене и retrieval;
- memory;
- MCP;
- API-та;
- файлове и бази данни;
- тестове;
- автономно изпълнение.
Това вече е много повече от Prompt Engineering.
Все повече прилича на управление на виртуален специалист.
Ако му дадете неясна задача, недостатъчно информация и неподходящи инструменти, резултатът вероятно няма да бъде добър, независимо колко мощен е моделът.
Ако обаче му дадете ясна цел, правилния контекст, необходимите инструменти и добре дефинирани граници, разликата може да бъде огромна.
И според мен точно това ще бъде едно от важните практически умения в следващите години.
Не да знаем някакви тайни магически думи за ChatGPT или Claude.
А да можем ясно да формулираме какво искаме, да предоставим правилния контекст и да организираме AI така, че той действително да може да свърши работата.
Често задавани въпроси
Как да пиша по-добри промптове за Claude Fable 5.1?
Започнете с крайния резултат, който искате да получите. Опишете ограниченията, контекста и какво моделът може да извърши самостоятелно. При актуални технологии го инструктирайте да провери официалната документация, вместо автоматично да разчита на запаметена информация.
Трябва ли винаги да използвам максимален effort?
Не. Anthropic препоръчва различните effort нива да бъдат тествани спрямо конкретния workload. По-висок effort има смисъл, когато действително носи достатъчно подобрение на резултата, за да оправдае допълнителното време и разход.
Каква е разликата между Prompt Engineering и Context Engineering?
Prompt Engineering се занимава основно с формулирането на инструкциите към модела. Context Engineering е по-широко понятие и включва информацията, файловете, правилата, историята, документацията и инструментите, които AI получава, за да изпълни задачата.
Какво е WordPress Abilities API?
Abilities API е част от WordPress и предоставя стандартизиран начин функционалности на WordPress, плъгини и теми да бъдат регистрирани и откривани като отделни „abilities“, със структурирани входни и изходни данни и правила за достъп.
Какво е MCP и защо е важно за AI агентите?
Model Context Protocol позволява AI приложенията да се свързват с външни източници на информация и инструменти по стандартизиран начин. Това позволява на един AI агент не само да говори за дадена система, а да получава контекст от нея и да използва предоставените инструменти за изпълнение на реални задачи.
