Мадэлі, кантэкст і няправільныя адказы

Аддзяляйце магчымасці ад даступнай інфармацыі

Моўная мадэль выкарыстоўвае вывучаныя заканамернасці і інфармацыю, атрыманую падчас задачы. Сучасныя мадэлі могуць выконваць складаныя разважанні і карысную працу з праграмамі. Яны таксама могуць даць падрабязны адказ, які абапіраецца на памылковае дапушчэнне.

«Frontier-мадэль» апісвае ўзровень магчымасцей, які змяняецца. Гэты тэрмін не пацвярджае, што мадэль прачытала ваш рэпазіторый. Ён не паказвае, што мадэль ведае версіі вашых залежнасцей або непісаныя бізнес-правілы. Гэтыя факты павінна даць асяроддзе задачы.

Агент з адпаведнымі інструментамі можа атрымаць інфармацыю. Чат без доступу не можа вывучыць рэпазіторый. Калі адказ здаецца няправільным, задайце два пытанні. Ці можа мадэль вырашыць гэтую праблему з правільнай інфармацыяй? Ці атрымала мадэль гэтую інфармацыю?

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

Вызначце кантэкст гэтай задачы

Кантэкст — гэта інфармацыя, даступная для бягучага адказу. Ён уключае інструкцыі, перададзеныя файлы, адпаведную размову і вынікі інструментаў. Прадукты па-рознаму адбіраюць і захоўваюць гэтую інфармацыю. Яны таксама могуць сцісла пераказваць папярэдні змест.

Не лічыце, што мадэль чытае кожны файл у загружанай папцы. Не лічыце, што ранняя інструкцыя застаецца даступнай на працягу доўгай сесіі. Папрасіце інструмент назваць файлы і інструкцыі, якія ён выкарыстаў.

Больш кантэксту не заўсёды паляпшае адказ. Актуальнае архітэктурнае рашэнне можа дапамагчы больш, чым не звязаныя з задачай зыходныя файлы. Састарэлы дапаможнік па міграцыі можа выклікаць няправільны адказ, бо выглядае аўтарытэтным.

Разгледзім выдуманую функцыю налад уліковага запісу. Перадайце маршрут, middleware аўтарызацыі, адпаведную мадэль даных і наяўны тэст. Дадайце канкрэтнае абмежаванне: «Удзельнік можа змяняць сваё адлюстраванае імя. Удзельнік не можа змяняць сваю ролю ў арганізацыі». Цяпер мадэль мае выразнае правіла, якое трэба захаваць.

Правярайце сцверджанні ў тлумачэнні

Адказ можа сцвярджаць, што endpoint бяспечны, бо middleware правярае прыналежнасць рэсурсу. Праверце кожную частку гэтага сцверджання.

1. Праверце, што endpoint выкарыстоўвае ўказаны middleware.
2. Праверце, што middleware правярае прыналежнасць рэсурсу, а не толькі аўтэнтыфікацыю.
3. Вызначце крыніцу ідэнтычнасці карыстальніка.
4. Выканайце негатыўны тэст ад імя іншага карыстальніка.

Спасылка на рэпазіторый паказвае, дзе шукаць. Яна не пацвярджае, што тлумачэнне адпавядае коду.

Выкарыстоўвайце той самы метад для рэкамендацыі API. Згенераваны код можа выклікаць метад, які ўсталяваны пакет не экспартуе. Праверце версію пакета і афіцыйную дакументацыю перад заменай залежнасцей. Інакш непацверджанае дапушчэнне можа прывесці да непатрэбнай міграцыі.

Ператварыце нявызначанасць у праверку

«Будзь дакладным» — не план праверкі. Вызначце дапушчэнне, патрэбныя доказы і наступствы няправільнага выніку.

Напрыклад: «Мы не праверылі ізаляцыю арандатараў для гэтага endpoint. Вывучыце апрацоўшчык запыту. Дадайце тэст, у якім карыстальнік з іншага арандатара запытвае той самы запіс». Гэтая інструкцыя задае агенту канкрэтнае даследаванне і вынік, які можна назіраць.

Для пытанняў аб рэалізацыі вывучайце фактычную версію сістэмы. Дакумент можа апісваць задуманыя паводзіны. Агляд кода і тэсты дапамагаюць вызначыць бягучыя паводзіны. Калі яны адрозніваюцца, зафіксуйце розніцу, пакуль адказны яе не вырашыць. Не выбірайце моўчкі больш зручны адказ.

Кіраўнікі могуць карыстацца гэтым метадам, не чытаючы кожную змену кода. Спытайце, якія дапушчэнні праверыла каманда. Вызначце дапушчэнні, што засталіся адкрытымі, і адказных за іх. Такая інфармацыя падтрымлівае рашэнне аб выпуску больш непасрэдна, чым назва мадэлі.