Тосынсыйсыз релиздер үшін промпттарды нұсқалау

Неліктен релизден кейін промпттар бұзылады

Промпт нашарлап кеткендіктен емес, көп жағдайда бір ұсақ түзету модельдің мінез-құлқын бірнеше жерде бірден өзгертіп жібереді. Сіз бір нақтылауды алып тастайсыз, абзацтың орнын ауыстырасыз, қысқалық туралы бір сөйлем қосасыз — сосын ассистент қарсы сұрақтарды сирек қоя бастайды, жауап пішімін нашар сақтайды немесе маңызды детальдарды өткізіп жібереді.

Мәселе мынада: промпт бір ғана репликаға емес, жауаптың бүкіл барысына әсер етеді. Ол тонды, әрекет ретін, шектерді және форматты анықтайды. Команда релизге дейін бір сөйлемді ғана өзгертсе де, продта көп нәрсе өзгеруі мүмкін: модель JSON-ды қалай жазады, құралды қалай таңдайды, қателерді қалай өңдейді және екіұшты сұранысқа қалай жауап береді.

Бұл әсіресе бір сценарийді әртүрлі модельдер арқылы өткізгенде байқалады. Егер команда бір OpenAI-compatible шлюз арқылы жұмыс істесе, мысалы AI Router, клиент кодын бір рет ұстап тұрып, интеграцияны қайта жазбай-ақ провайдерлер мен модельдерді ауыстыра алады. Бірақ бірдей промпт көрші модельде локалдық тесттегідей әрекет етпей жатады. Түзету қауіпсіз сияқты көрінеді, ал продта жауаптар әлдеқашан басқа бағытқа кетеді.

Тағы бір жиі себеп — команда мәтіннің қазіргі нұсқасын жоғалтады. Бір адам промптты чатта түзетеді, екіншісі құжаттағы бір бөлігін өзгертеді, үшіншісі кодтың ішіне "уақытша" нұсқаны тікелей қойып қояды. Бір аптадан кейін продта қай мәтін шын мәнінде жұмыс істеп тұрғанын ешкім білмейді. Формалды түрде промпт бар, бірақ сенімді жалғыз дереккөз жоқ.

Чаттар мен құжаттар талқылауды жылдамдатады, бірақ тәртіпті бұзады. Онда тұжырымды талқылау ыңғайлы, ал жұмыс істейтін нұсқаны сақтау ыңғайсыз. Өзгеріс күні, кім түзеткені, не үшін түзетілгені, қандай тестке қатысты екені және қай нұсқаға қайта оралуға болатыны тез жоғалады.

Кері қайтару болмаса, тіпті ұсақ қате тез арада инцидентке айналады. Қолдау боты релизден кейін тым жалпы жауап бере бастайды, ал команда бес минут ішінде бұрынғы мәтінге қайта алмайды. Әзірлеушілер чаттан "әлгі" нұсқаны іздеп жүргенде, пайдаланушылар нашар жауап алады, ал бизнес уақыт жоғалтады.

Промпттарды нұсқалау репозиторийді әдемі көрсету үшін керек емес. Ол кез келген түзетудің артында автор, тест, нұсқа нөмірі және кері жол болу үшін қажет.

Промпттың нұсқасы деп нені есептеу керек

Промпттың нұсқасы тек system өрісіндегі жаңа мәтін емес. Егер сіз temperature, жауап форматын немесе мысалдар жиынын өзгертсеңіз, модельдің мінез-құлқы да өзгереді. Демек, бұл да жаңа нұсқа.

Промптты қолданба мен модель арасындағы келісім сияқты қарастырған ыңғайлы. Оның құрамына әдетте мыналар кіреді:

• ережелері мен рөлі бар system-промпт
• айнымалылары және деректер қойылатын орындары бар user шаблоны
• егер few-shot қолдансаңыз, жауап мысалдары
• параметрлер мен шектеулер: модель, temperature, max_tokens, JSON-схема, тақырыпқа немесе жауап ұзындығына тыйым

Мұның бәрін бір файлға салсаңыз, бір айдан кейін нәтижені нақты не бұзғанын ешкім түсінбейді. Сондықтан system, user және мысалдарды бөлек ұстаған дұрыс. Сонда Git ішіндегі айырмашылықты көру, өзгерісті тексеру және ойланбай-ақ кері қайтару жеңілдейді.

Нұсқамен бірге не тұруы керек

Промпт мәтінінің жанында нәтижеге әсер ететін баптауларды сақтаңыз. Бірдей тұжырымда temperature 0.1-ден 0.7-ге ауысу жауаптың үніне, ұзындығына және дәлдігіне екі жолдық түзетуден де қатты әсер етуі мүмкін. Модель атауына да солай.

Жауап пішімін бөлек бекітіңіз. Егер қолданба status және reason өрістері бар қатаң JSON күтсе, бұл да нұсқаның бір бөлігі. Егер кеше модель еркін мәтін жазса, ал бүгін JSON қайтаруы керек болса, промпт релизі өзгерді деген сөз, тіпті нұсқаудың мағынасы қатты ауыспаса да.

Өзгеріске қысқа түсіндірме де керек. Ұзақ есеп емес, 1-2 анық сөйлем жеткілікті: не өзгерді және не үшін. Мысалы: "Оператор қысқарақ жауап көрсін деп артық түсіндірмелерді алып тастадық" немесе "Модель сервис жасамайтын нәрсені уәде етпеуі үшін бас тарту мысалын қостық".

Сонда команда жай ғана "жаңа мәтінді" емес, тексеруге, салыстыруға және артқа қайтаруға болатын толық шарттар жиынтығын көреді.

Репозиторийді қалай құру керек

Нашар репозиторий нашар промпттан да көп шатастырады. Егер бір папкада черновиктер, жұмыс істейтін нұсқалар, тесттер және чаттан алынған жазбалар жатса, команда тіпті ұсақ түзетуден де қорқа бастайды.

Құрылымды модельдер бойынша да, авторлар бойынша да емес, өнімдер немесе сценарийлер бойынша бөліңіз. Қолдау чаты, шартты талдау және шоттан өрістерді алу — бұлар әртүрлі міндеттер. Олардың қателері де, сапа өлшемдері де бөлек. Бір сценарийді әртүрлі модельдерден өткізсеңіз де, папка провайдерді емес, тапсырманы сипаттауы керек.

Мұндай қаңқа көбіне жақсы жұмыс істейді:

prompts/
  support_chat/
    prod/
      system.md
      developer.md
      params.yaml
    tests/
      cases.yaml
      fixtures/
    rules.md
    drafts/
  invoice_extraction/
    prod/
    tests/
    rules.md
    drafts/

Шаблондарды, тесттерді және fixture-ларды бір жерде ұстаңыз. Адам промпт мәтінін өзгерткенде, ол бірден кіріс мысалдарын және күтілетін нәтижені көреді. Бұл уақытты үнемдейді және сирек, бірақ қымбат сценарийді бұзып алу тәуекелін азайтады. Егер тесттер басқа жерде жатса, оларды жаңарту да тез ұмытылады.

Жалпы ережелерді бөлек файлдарға шығарған дұрыс. Ол жерге әдетте жауап стилі, тонға қойылатын шектеулер, PII жасыру, қызметтік нұсқаулар және қажет болса заңға немесе ішкі саясатқа байланысты контент белгілері кіреді. Бірақ бәрін бір алып файлға жинап қоймаңыз. Рөлі анық бірнеше қысқа файл көбіне ыңғайлырақ.

Черновиктер мен прод нұсқаларын араластырмаңыз. drafts және prod папкалары ойлағаннан да көп мәселені шешеді. Редактор бірден не еркін өзгертуге болатынын, ал ненің релизге қатысатынын түсінеді. Мәтін ревьюдан өтпесе, ол prod-қа кірмейді. Кері қайтару да оңайырақ болады: команда final_final_new сияқты папкалар арасынан емес, бұрынғы жұмыс істейтін нұсқаны қайтарады.

Жақсы репозиторий жалықтыратын әрі алдын ала түсінікті көрінеді. Релиздер үшін бұл көбіне артықшылық.

Файлдар мен нұсқаларды қалай атау керек

Файлды автордың атымен немесе күнімен атаған кезде, команда тез арада мағынасын жоғалтады. ivan_fix_v2.txt бұл тапсырма, тәуекел және қолданылатын жер туралы ештеңе айтпайды. Атауы қарапайым сұраққа жауап беруі керек: бұл промпт не істейді және қай жерде қолданылады.

Жақсы үлгі көбіне мынадай болады:

• support/refund_request/system.md
• sales/lead_qualify/user.md
• risk/pii_redaction/system.md
• routing/model_fallback/policy.md

Сонда домен, сценарий және промпттың рөлі бірден көрінеді. Егер промпт тек тар бір жердегі мінез-құлықты өзгертсе, атауы да соны көрсетуі керек. Репозиторий үшін бұл автордың тегі, new сөзі немесе атаудағы күннен әлдеқайда пайдалы.

Нұсқаларға келгенде де сол логика. Шатастырмаңыз. Тұрақты күй үшін қарапайым тегтер жеткілікті: v1, v1.1, v2. Егер команда промпттарды кодпен бірге шығарса, тегті қолданба релизімен байланыстыру ыңғайлы, бірақ промпттың өзінде бәрібір бөлек түсінікті нұсқа болуы керек. Сонда: "продта support/refund_request/system.md-тің v1.2 нұсқасы тұр" деп айту оңай, ал бес final файлының қайсысы жұмыс істеп тұрғанын іздеудің қажеті жоқ.

Шұғыл түзетулер тәртіпті ең қатты бұзады. Адамдар асығып copy-final, final-2, really-final жасап жатады да, кейін продқа нақты не кеткенін ешкім есіне түсірмейді. Бір негізгі файлды ұстап, тек оның нұсқасын өзгерткен дұрыс. Егер түзету шұғыл болса, hotfix-2026-04 немесе v1.2.1 сияқты тег қосыңыз, бірақ клондар жасамаңыз.

Әр PR-де 3-4 жолдық қысқа сипаттама жеткілікті: қай сценарий қозғады, нақты не өзгерді, қандай тәуекелді азайтқыңыз келді және қандай тесттермен тексердіңіз. Бір айдан кейін мұның өзі түзетудің логикасын түсінуге жетеді.

Осылайша нұсқаларды салыстыру және ақауларды талдау жеңілдейді. Команда не өзгергенін көреді: мәтіннің өзін бе, параметрлерді ме, әлде модель таңдауды ма.

Промптты қадам-қадаммен қалай өзгерту керек

Команда промптты тәртіпсіз өзгертсе, ұсақ түзету оңай-ақ ұзақ инцидент талдауға айналады. Промптқа код сияқты қараған әлдеқайда тыныш: аз-аздан өзгерту, бірдей мысалдар жиынында тексеру және тез кері қайтаруды қол астында ұстау.

Жұмыс процесі әдетте мынадай болады:

1. Әуелі өзгерістің мақсатын бір сөйлеммен жазыңыз. "Жақсарту" емес, мысалы: "қолдау өтініштері үшін жауап ұзындығын 5 сөйлемге дейін қысқарту".
2. Сосын бұрын болған қателерге тест қосыңыз. Егер модель бұрын жауап тілін шатастырса, міндетті өрісті өткізіп алса немесе артық түсіндіруге кетсе, бұл жағдайлар мәтінді өзгертпей тұрып тексерулерге кіруі керек.
3. Бір уақытта тек бір нәрсені ғана өзгертіңіз. Егер рөлді, шығыс форматын және бас тарту ережелерін бірден қайта жазсаңыз, нақты не әсер еткенін ешкім түсінбейді.
4. Ескі және жаңа нұсқаны бірдей кіріс жиынына салыстырыңыз. Әйтпесе сізде салыстыруға келмейтін екі әдемі кесте ғана қалады.
5. Жаңа нұсқаны алдымен трафиктің аз бөлігіне шығарыңыз. Тіпті сұраныстың 5%-ы да қателердің өсуін, кешігуді немесе күтпеген жауап стилін байқауға жиі жетеді.

Мұндай тәртіп тек басында баяу көрінеді. Шын мәнінде ол сағаттарды үнемдейді: diff қысқа болады, тексеру тезірек өтеді, ал кері қайтару бес түзетудің қайсысы нәтижені бұзғанын болжауды қажет етпейді.

Жақсы мысал — команда қоңыраулардың қысқаша мазмұнын жасауға арналған промптты өзгертеді. Мақсат нақты: артық детальдарды алып тастап, тек оператор шешімін қалдыру. Команда тесттерге модель бұрын әрекет ойлап табатын бірнеше ескі қоңырауды қосады, содан кейін шығыс форматына қатысты бір нұсқауды ғана өзгертеді және екі нұсқаны бірдей жиында өткізеді. Егер жаңа нұсқа қысқарып, бірақ өтінім нөмірін жоғалтса, ол ары қарай өтпейді.

Егер LLM трафигі бір шлюз арқылы өтсе, canary іске қосуды да оңайлату болады: бірдей жүк бірдей жолмен өтеді де, сіз тек промпттың мінез-құлқын салыстырасыз. AI Router ішінде бұл үшін сол бір endpoint пен кодты қалдырып, нұсқаларды релиз және лог деңгейінде бөлуге болады.

Мұндай процестің нәтижесі анық: әр түзетудің мақсаты, тексеруі, шағын іске қосуы және кері жолы бар.

Жібермей тұрып қалай тексеру керек

Бір промпт қолмен тексеруден өтіп, бәрі дұрыс сияқты көрініп тұрса да, келесі күні продта бұзылады. Әдетте себеп қарапайым: команда жауаптың жалпы мағынасына қарайды, бірақ кейінгі тізбек жұмыс істеуі үшін қажет нәрсені тексермейді. Егер жауап intent, language және қысқа summary қайтаруы керек болса, тест дәл осы өрістерді тексеруі тиіс, тек "жалпы жаман емес сияқты" деген сезімді емес.

Merge алдында қысқа smoke-жиынтық пайдалы. Бұл — 10-20 сұраныс, олар бірнеше минутта өтіп, өрескел қателерді тез ұстайды: бос JSON, құрылымның айналасындағы артық мәтін, тонның ауысуы, міндетті өрістің жоғалуы. Мұндай жиынтық промпт жақсы екенін дәлелдемейді. Бірақ кішігірім түзетуден кейінгі бұзылуды жақсы ұстайды.

Бөлек regression жиынтығын да ұстаңыз. Оған команда бұрын күйіп қалған жағдайлар кіреді: ұзын user хабарламалары, тілдердің араласуы, токсикалық input, қате жазулар, қайшылықты сұраныстар. Егер баг бір рет болса, оның мысалы тесттерде қалуы керек.

Нені бекіту керек

Егер промпт нұсқаларын салыстырып жатсаңыз, бір уақытта бір ғана факторды өзгертіңіз. Модель, temperature және платформа қолдаса seed бірдей қалуы керек. Әйтпесе сіз промптты емес, шуды тексеріп жатасыз.

Егер бір API-шлюз арқылы жұмыс істесеңіз, тексеру кезінде нақты модель мен сұраныс параметрлерін бекіткен дұрыс. Әйтпесе маршрутизация ескі және жаңа нұсқаның арасындағы айырмашылықты жасырып қалуы мүмкін.

Прогоннан кейін нені сақтау керек

Тек "өтті / өтпеді" дегенді емес, жақсы және нашар жауаптарды да тест-кейспен қатар сақтаңыз. Кейін оларды diff арқылы салыстырып, нақты не өзгергенін оңай түсінесіз: құрылым ба, толықтық па, тон ба, әлде ұзындық па.

Релиз алдында ең аз дегенде мына жиынтық болғаны дұрыс:

• merge алдында шағын smoke-тест
• бұрынғы проблемалы мысалдарға regression тексеруі
• міндетті өрістер мен жауап форматын тексеру
• әділ салыстыру үшін модель параметрлерін бекіту
• жақсы және жаман жауап мысалдарын сақтау

Егер бір промптқа осындай тексеруге 15 минут кетсе, бұл релизден кейінгі түнгі инцидентті талдаудан әлдеқайда арзан.

Командалар көбіне қай жерде қателеседі

Ең қымбат қате қарапайым: команда бір коммитте әрі промптты, әрі модельді өзгертеді. Сосын жауап нашарлайды, бірақ нақты не бұзғанын ешкім түсінбейді. Мәтін, temperature, жүйелік нұсқау немесе жаңа модель — бәрі бір пакетке араласып кетеді.

Бұл әсіресе модельді бір минутта ауыстыруға болатын жерде жиі болады. Егер команда шлюз арқылы жұмыс істесе, бәрін бірден жаңарту азғыруы одан сайын күшейеді. Релиз үшін бұл жаман әдет: бір коммитке бір ғана өзгеріс, әйтпесе салыстырудың мәні жоғалады.

Екінші жиі қате — жаңа нұсқаны екі-үш ыңғайлы мысалда ғана тексеру. Ондайда промпт керемет көрінуі мүмкін, ал нақты сұраныс ағынында мүлдем сүрінеді. Әдетте ұзын диалогтар, сирек тұжырымдар, аралас тілдер және пайдаланушылар анық емес жазатын жағдайлар бұзылады.

Ең жаманы — ескі мысалдарды "керегі жоқ" деп өшіріп тастау. Олармен бірге команда бұрынғы қателер туралы жадын да жоғалтады. Бір айдан кейін біреу тағы бір түзету енгізіп, ескі мәселені қайтарып алады да, өзін шын мәнінде жақсырақ нәрсе таптым деп ойлайды.

Тағы бір тұзақ — мәтінді чатта, құжатта немесе жеке жазбада түзетіп, кейін оны продқа көшіру. Сырттай қарағанда бұл жылдам сияқты. Іс жүзінде ешкім өзгерістер тарихын көрмейді, шешімнің авторын білмейді және бір апта бұрын жұмыс істеген дәл нұсқаны қайтара алмайды. Промпттар репозиторийі әдемі тәртіп үшін емес, өзгеріс ізі үшін керек.

Кері қайтаруды да көп жағдайда тым кеш еске алады. Команда жаңа промптты шығарады, сапаның түскенін көреді де, "әлгі" ескі нұсқаны скриншоттар мен хат алмасудан іздей бастайды. Егер кері қайтару алдын ала дайын болмаса, релиз қолмен жасалатын апат талдауына айналады.

Әдетте тәуекел мына белгілер байқалса өседі:

• бір PR-да әрі нұсқау, әрі модель, әрі параметрлер өзгереді
• тест жиынтығы оннан аз мысалдан тұрады және онда күрделі жағдайлар жоқ
• жұмыс істейтін промпт нұсқасы Git-те емес, чатта немесе тарихы жоқ админкада сақталған
• команда бұрынғы сәтсіз кейстерді ұстамайды
• қай commit-ті бес минутта қайтару керегін ешкім білмейді

Жақсы тәртіп сырттай жалықтыратын сияқты көрінеді, бірақ көбіне сол құтқарады. Әр өзгеріске бөлек commit, ескі және жаңа мысалдар жиыны, Git-тегі нұсқа және алдын ала тексерілген кері қайтару — продтағы үнсіз бұзылулардан қорғанудың әдеттегі жолы.

Кәдімгі релизден мысал

Команда қолдау ботын жүргізеді. Кезекті спринттен кейін өнім иесі бір қарапайым өзгеріс сұрайды: бот қысқарақ жауап берсін, артық кешірімсіз және ұзақ кіріспесіз. Сөз жүзінде бұл ұсақ тапсырма сияқты, бірақ дәл осындай түзетулер релизді жиі бұзады.

Әзірлеуші жүйелік промптты ашып, бірнеше абзацты алып тастайды. Ол жалпы түсіндірулерді қысқартып, тон ережелерін қалдырады және жауапты қатаңырақ етеді. Репозиторийде бұл әдеттегі commit сияқты көрінеді: файлдың жаңа нұсқасы, өзгеріс себебі және тикет.

Мәселе продта емес, тестте шығады. Ботта міндетті ереже бар: егер ол пайдаланушыдан бас тартса, тек бас тартудың өзін ғана емес, себебін де бөлек өрісте қайтаруы керек. Промптты қысқартқаннан кейін модель мәні жағынан әлі де дұрыс бас тартады, бірақ себеп өрісі кейде жоғалып кетеді. Қолдау операторы үшін бұл уже бұзылу, өйткені интерфейс нақты жауап құрылымын күтеді.

Команда тесттерге қарсы шықпайды да, жұма кеште қолмен жөндеуге кіріспейді. Ол промпт релизін бұрынғы нұсқаға кері қайтарады. Егер нұсқалау дұрыс ұйымдастырылса, rollback бірнеше минут алады: сервис қайтадан алдыңғы тегті немесе нұсқа нөмірін алады, ал қолданба кодты қайта жазбай-ақ жұмысын жалғастыра береді.

Кері қайтарудан кейін команда diff-ті қарап, не жоғалғанын тез табады. Артық мәтінмен бірге әзірлеуші reason өрісін әр бас тартуда толтыруды талап ететін қысқа нұсқауды да өшіріп тастаған болып шығады. Бұл модельдің "ақылды мінез-құлқы" емес, жай ғана өңдеу кезіндегі қате.

Екінші талпыныста команда тек бір бөлікті өзгертеді. Ол reason өрісіне арналған нақты ережені қайтарады, бірақ бұрынғы көпсөзділікті қайтармайды. Содан кейін жаңа тест қосады: егер модель бас тарту жауап берсе, тек мәтін емес, дұрыс өрісте себептің бар-жоғы да тексеріледі. Мұндай тест келесі релизде жоғалмайды.

Міне, жұмыс істейтін схема осы. Команда промптты ұсақ бөліктермен өзгертеді, қателікті выкладкаға дейін ұстайды, тез кері қайтарады және жүйкені тоздырмайтын қолмен жөндеудің орнына нақты түзету шығарады.

Релиз алдындағы қысқа тексеру

Бір промпт ревьюдан өтіп, ұқыпты көрініп тұрса да, продтағы жауапты бұзып жіберуі мүмкін. Әдетте мәселе түзетудің өзінде емес, команда не үшін оны жасап жатқанын және нәтижені қалай түсінетінін алдын ала келіспегенінде. Жіберер алдында 10 минут қысқа тексеруге жұмсаған, кейін бір күн шағым талдағаннан жақсы.

Промпттар үшін бұл кезең кодтағыдай маңызды. Әсіресе бір сценарий бірнеше модель арқылы немесе ортақ API-шлюз арқылы өтсе: ондайда шуды шынайы регрессиямен оңай шатастырып алуға болады.

Бес нәрсені тексеріңіз.

• Түзетудің бір жауапты адамы бар. Бұл бүкіл команда емес, өзгерістің мақсатын бір сөйлеммен түсіндіре алатын нақты адам. Мысалы: "ұзын контексті сұраныстардағы бас тартулар санын азайту".
• Diff таза. Егер онда жаңа нұсқау, файлдардың атын өзгерту және мысалдарға кездейсоқ түзету бірге жатса, ревьюдің мәні жоғалады. Жақсы diff тек мінез-құлыққа әсер ететін нәрсені көрсетеді.
• Эталон тест жиынтығы жасыл. Айқын прогон керек: бірдей input, бірдей күтілетін жауап белгілері және бірдей іске қосу шарттары. Егер бір тест жақсарып, екі ескі кейс нашарласа, релизге әлі ерте.
• Командада кері қайтару нүктесі белгілі. Нұсқа нөмірі, тег немесе commit алдын ала жазылып тұруы керек. Ақау шыққанда үш final файлдың қайсысы соңғы жұмыс істегенін ешкім есіне түсіргісі келмейді.
• Алғашқы тәуліктегі метрикалар релизге дейін таңдалады. Көбіне 3-4 көрсеткіш жетеді: сәтті жауаптар үлесі, жауаптың орташа ұзындығы, қолмен эскалация саны, баға немесе кідіріс. Әйтпесе шығарғаннан кейін бәрі әртүрлі нәрсеге қарайды да, әсер туралы дауласады.

Жақсы белгі — команданың кез келген мүшесі бір минутта үш сұраққа жауап бере алуы: не өзгерді, қалай тексерілді және қайда кері қайтарылады. Егер осының кемінде біреуіне жауап жоқ болса, релизді сәл баяулатқан дұрыс.

Тәжірибеде бұл көп уақыт үнемдейді. Айталық, команда клиент қолдауының промптін өзгертіп, артық нақтылаулар азаяды деп күтеді. Егер алғашқы тәулікке арналған метрикалар алдын ала таңдалса, ол тек қайталама сұрақтардың азайғанын емес, қосымша әсерді де тез көреді: жауаптар қысқарып, детальдарды жиі өткізе бастайды. Сонда кері қайтару немесе түзету дауға емес, сағаттарға созылады.

Әрі қарай не істеу керек

Егер сізде әзірге жүйе болмаса, өнімдегі барлық промптты бірден реттеуге тырыспаңыз. Релизден кейін жиі бұзылатын бір сценарийден бастаңыз. Бұл клиентке жауап, өтінімді талдау немесе құжаттан өрістерді шығару болуы мүмкін. Сол промптты model параметрлерімен, кіріс мысалдарымен және күтілетін жауаппен бірге Git-ке көшіріңіз. Содан кейін өзгерістер жеке хабарламалар мен ауызша келісімде өмір сүрмейді.

Нормал нұсқалау осылай басталады. Үлкен схема мен мінсіз процестен емес, команда нақты не өзгергенін, оны кім мақұлдағанын және бұрынғы нұсқаны қалай қайтаруға болатынын көретін бір жерден.

Келесі релизге дейін шағын тест жиынтығын жинаңыз. Үлкен архивтің қажеті жоқ. Бастау үшін 10-15 мысал жеткілікті:

• күнде өтетін 5 кәдімгі сұраныс
• 2 ұзын немесе шуылы көп input
• 2 екіұшты тұжырымдалған жағдай
• модель жиі сүрінетін 1-2 нашар input
• бұрын продта бұзылған 1 мысал

Бұл өрескел регрессияны ұстауға жеткілікті. Егер жаңа промпт мәтіні бұрынғы кейстерде нашарласа, команда оны выкладкаға дейін көреді.

Тағы бір қадам дау-дамайдың жартысын азайтады: өзгерістерді кім бекітетінін алдын ала белгілеңіз. Әдетте екі рөл жеткілікті. Бір адам промптты өзгертеді және не үшін өзгерткенін жазады. Екіншісі тесттерді қарайды, diff-ті оқиды және релизге рұқсат береді немесе түзетуді кері қайтаруды сұрайды. Мұндай ереже болмаса, промпт тым тез өзгереді де, ақау үшін жауап беретін адам табылмай қалады.

Егер сіз LLM интеграцияларын қазірдің өзінде AI Router арқылы жүргізіп жүрсеңіз, промпт нұсқаларының жанында модельді, логтарды және кері қайтару ережелерін сақтау ыңғайлы. Сонда қай нұсқаның продқа кеткенін, қай модельде жұмыс істегенін және қашан кері қайтарылғанын тез түсінесіз.

Алдағы бір аптаға қарапайым жоспар жетеді: бір сценарийді Git-ке көшіру, шағын тест жиынтығы және бір келісу ережесі. Бұл мінсіз жүйе емес. Бірақ келесі релизді тосынсыйсыз өткізуге көмектеседі.