Како да прегледате код генериран со AI

За да прегледате код генериран со AI, почнете со она што е променето — кои датотеки и зошто — па тестирајте го однесувањето сами пред да прочитате ниту една линија код. После тоа, проверете ги областите каде AI кодот најчесто греши: недостасувачки проверки на дозволи на серверот, тајни изложени на прелистувачот, невалидиран внес, пакети или функции што не постојат и измени на работи што никогаш не ги барале да ги допрете.

AI пишува код што обично работи и често изгледа уреден. Тоа го прави лесно да се одобри без вистинска проверка. Овој водич е рутина за преглед што функционира без разлика дали кодот го читате течно или воопшто не.

Прилагодете го прегледот на ризикот

Не секоја промена бара иста внимание.

Чекор 1: Видете што е променето

Пред да го судите кодот, добијте список на промени:

• Ако проектот е во Git, погледнете го diff-от: датотеките и редовите што се променети од последниот commit. Видете како да користите Git со апликација изградена со AI.
• Или прашајте го AI директно:

Наведете ги сите датотеки што ги променивте во последната промена и за секоја со една реченица објаснете што се променило и зошто.

Црвени знаменја во оваа фаза: датотеки што не се поврзани со барањето, избришани датотеки, промени на конфигурација или зависности што не сте ги побарале.

Чекор 2: Прво тестирајте го однесувањето

Читањето на кодот ви кажува што треба да прави; тестирањето ви кажува што навистина прави. Пред читање:

• Пробајте ја промената како обичен корисник, на десктоп и на екран со големина на телефон.
• Пробајте со погрешен внес: празни полиња, многу долг текст, негативни броеви, датум во минатото.
• Пробајте одјавени и како друг корисник.
• Повторно пуштете ги текови што најмногу се важни: регистрација, најава, главната акција, плаќање.

Ако тестирањето не успее, заштедивте време за читање — пријавете го јасно и нека AI го поправи. Видете како да напишете добар извештај за грешка.

Чекор 3: Проверете ги дозволите на серверот

Најважното нешто за проверка. AI алатките често скријуваат копче во страницата, но го оставаат серверот подготвен да ја изврши акцијата за секој што ќе побара.

За секоја патека или функција што чита или менува податоци, прашајте:

• Дали проверува дека корисникот е најавен?
• Дали проверува дека овој корисник смее да пристапи до овој запис?
• Дали таа проверка е на серверот, а не само во страницата?

За секоја API патека што ја додадовте или променивте, кажете ми каква проверка на дозвола прави на серверот, цитирајќи ја линијата. Означете секоја патека без таква.

Потоа тестирајте ја: најавете се како корисник А, забележете го ID на запис, најавете се како корисник Б и побарајте го. Листата за безбедност за апликации изградени со AI го содржи целосниот тест.

Чекор 4: Барајте изложени тајни

• Пребарајте ги променетите датотеки за нешто што личи на клуч или лозинка.
• Проверете дали тајните клучеви се читаат од променливи на околината и се користат само во серверски код.
• Внимавајте на јавни префикси како VITE_ или NEXT_PUBLIC_ кај тајни променливи — тие се вградуваат во кодот за прелистувачот.

Видете како да ги чувате API клучевите безбедни.

Чекор 5: Проверете внес и грешки

• Валидација на серверот. Проверките во прелистувачот може да се заобиколат. Задолжителните полиња, должините, форматите и дозволените вредности треба да ги проверува и серверот.
• Упитите до базата користат параметри, не текст составен со спојување на внесот на корисникот во упит.
• Грешките не се голтаат. try/catch што не прави ништо ги крие неуспесите. Грешките треба да се запишуваат во логови, а корисниците да гледаат едноставна порака.
• Без внатрешни детали за корисниците — стек трасите и грешките на базата припаѓаат во логовите.

Чекор 6: Проверете дали е вистинско

AI моделите понекогаш произведуваат код што изгледа точно, но се повикува на работи што не постојат.

• Пакети: секоја нова зависност треба да е вистински, одржуван пакет со тоа точно име. Внимавајте на имиња што личат на грешки во правопис на популарни.
• Функции и API опции: ако кодот повикува функција од библиотека или опција од надворешен API што никогаш не сте ја виделе, проверете ја официјалната документација.
• Placeholder код: пребарајте за TODO, mock, fake, вградени примерок-податоци или функции што враќаат фиксна вредност.

Додадовте ли нови пакети? За секој дајте го точното име, за што е и дали би можеле без него.

Чекор 7: Проверете дали се вклопува

Кодот може да работи и сепак да ја отежнува идната промена на апликацијата:

• Дуплирање. Истата логика копирана на неколку места ќе се раздвои.
• Доследност. Треба да ги следи обрасците што ги користи остатокот од апликацијата.
• Големина. Барање од 20 линии што создало 600 линии заслужува прашање.
• Мртов код. Стари верзии оставени до нови.

Има ли код во проектот што сега е неискористен поради оваа промена, или логика што е дуплирана на друго место? Не менувајте ништо; само наведете го.

Чести грешки

• Одобрување затоа што изгледа чисто. Уреден код сè уште може да прескокне проверка на дозвола.
• Читање наместо тестирање. Прво тестирајте; потоа читајте.
• Тестирање само на главниот тек. Пробајте лош внес, погрешен корисник и одјавени.
• Игнорирање промени во неповрзани датотеки. Прашајте зошто се променети сите датотеки.
• Целосно верување во самопреглед. Користете го прегледот на AI како прв премин и потврдете со тестирање.
• Преглед на неделна вредност промени одеднаш. Прегледувајте мали промени додека се случуваат.

Листа за проверка

• Знам кои датотеки се променети и зошто, и ништо неповрзано не е променето.
• Промената работи на десктоп и телефон, со лош внес, одјавен и како друг корисник.
• Секоја патека за податоци проверува најава и сопственост на серверот.
• Нема тајни во кодот или во пакетите за прелистувачот.
• Внесот се валидира на серверот; упитите користат параметри.
• Грешките се запишуваат во логови, не се голтаат и не се прикажуваат детално на корисниците.
• Новите пакети се вистински и потребни; не остануваат измислени функции или placeholder-и.
• Промените со висок ризик имаат внимателно читање и, каде што треба, втор рецензент.

Преглед на код на Mythex

• Ask режимот одговара на прашања за кодот без да го менува — идеален за барања „објасни секоја промена“ и „кои патеки немаат проверка на дозвола“. Видете Chat.
• Code прегледот ги прикажува стеблото на датотеките, уредникот и терминалот на секој план (само за читање на Free, за уредување на Pro), за да можете сами да прочитате што е променето. Видете Code editor.
• /test го прави агентот да кликне низ прегледот како корисник и да ги пријави расипаните текови.
• Checkpoint-ите ви овозможуваат да вратите промена што не поминува преглед.

Ако програмер ви прегледува, како да работите со програмер на апликација изградена со AI ја опфаќа предавањето; ако прегледот открие грешка, видете како да дебагирате апликација изградена со AI.

Прашања