Печалби:
- Възможност за картографиране на режима на чат за коригиране на типа задача с вградено завършване
- Възможност за писане на мощни производствени подкани, които включват договори за вход/изход, крайни случаи и стилови ограничения
- Възможност за валидиране на генерирания код и всички нови предложени зависимости преди сливане
Първата точка на контакт на програмиста с AI често е автоматичното довършване – функция, която предлага следващия ред, докато пишете – или казването „напишете тази функция“ в прозорец за чат. И двете използват един и същ двигател, но изискват различни дисциплини. В този модул ние трансформираме генерирането на код от произволно „записване“ в инженерна стъпка, чийто резултат е предвидим и проверим.
Целта е да превърнете AI от инструмент, който ускорява вашата машина за писане, в чирак, който работи в рамките на зададените от вас ограничения. Добре ръководеният чирак спестява време; Неръководен чирак създава бъркотия, която трябва да почистите по-късно.
Два режима на използване: Вградено завършване и Чат
Вграденото завършване влиза в действие, докато пишете във вашия редактор; Вие въвеждате подпис на функция или ред за коментар и той предлага останалото. Той е страхотен за скорост, но има тесен контекст: той вижда само код в непосредствена близост. Ето защо работи най-добре, когато напишете ясно намерението си в коментар. Например, //валидиране на потребителски имейл, хвърляне на ValidationError ако невалиден коментар значително подобрява предложението по-долу.
Режимът на чат е за по-големи и структурирани задачи: „Добавяне на пагинация към този клас“, „Извличане на интерфейс на тази услуга“. Тук имате лукса да дадете роля, контекст и формат. Общото правило е: завършване за малки и течащи задачи, разговор за задачи, които изискват мислене и структура.
Съвет: Не приемайте сляпо предложението за завършване с „Tab“. Прочетете предложения ред за секунда; От тук най-често изтича неправилно име на променлива или обърнато условие.
Стъпки за превеждане на намерение в код
- Определете договора. Какво е поведението на входа, изхода и грешките на функцията? Като „Получаване на имейл, нормализиране, ако е валидно, извеждане на грешка, ако е невалидно“.
- Посочете ограниченията. Не използвайте външна зависимост? Специфично ръководство за стил? Има ли ограничение на производителността?
- Дайте пример. Двойка вход-изход („ali@x.com → valid, ali@ → error“) премества разбирането на модела за намерението от предвиждане към прецизност.
- Поискайте малки парчета. Една функция, една отговорност. След това преминете към следващия.
- Прочетете и стартирайте генерирания код. Компилирането + бърз ръчен опит е най-евтината стъпка за осигуряване.
Три мини калъфа
Случай 1 — Производството, управлявано от коментари, повишава точността. Разработчик първо поиска функция за анализ на дата с празно тяло и получи правилния резултат в 3 кръга. При втория опит, когато дефинирах функцията с 4-редов коментар (приети формати, правило за часовата зона, условие за грешка) и я поисках, дойде кодът, който работи в първия кръг. Същият модел, същия ден; разликата беше само в яснотата на намерението.
Случай 2 — Непосочването на версия е скъпо. Един екип се бори с наследеното API, базирано на обратно извикване, което замества fs.promises в кода, произведен за Node.js. Когато редът „Използване на възел 20, ESM, async/await“ беше добавен към подканата, производството последва проекта за първи път; Средните 12 минути, изразходвани за корекция, бяха нулирани.
Случай 3 — Реална печалба в шаблонен код. Една микроуслуга изискваше 6 нови DTO (обект за прехвърляне на данни — прост клас данни, който пренася данни между слоевете) и техните правила за валидиране. Това, което преди беше приблизително 90 минути ръчна работа, беше намалено до 35 минути, когато беше произведено и прегледано от AI; Тъй като повторението на кода е високо и моделът е ясен, AI работи в най-ефективната си област тук.
Четири копируеми шаблона
Генериране на функция, базирана на договор:
Роля: Вие сте усърден {{language}} разработчик. Договор за функция:- Име: {{name}}- Вход: {{типове и тяхното значение}}- Изход: {{тип и значение}}- Статус на грешка: {{какво се хвърля/връща, когато}}Ограничения: {{няма външни зависимости / стил / производителност}}Примери:- {{input_1}} -> {{output_1}}- {{entry_2}} -> {{error_2}}Първо дайте подпис + кратък план, след това код. Писане на тестове, просто функция.
За да съответства на съществуващия стил (адаптиране към кодовата база):
По-долу е примерна функция от нашия проект; Научете именуване, обработка на грешки и стил на коментиране тук. Напишете функция за {{new_task}} със СЪЩИЯ стил. Пример: {{current_code}}
От скелета до пълнежа (мъниче → изпълнение):
Попълнете функционалния скелет по-долу според TODO в коментарите. ПРОМЕНЕТЕ подписа и типа на връщане. Не създавайте помощна функция, която не съществува; ако е необходимо, уведомете ме "необходим е този помощник". {{skelet_kod}}
Сравнение на алтернативно приложение:
Дайте 2 различни реализации за {{task}}: (a) приоритизиране на четливостта, (b) приоритизиране на производителността. Запишете по 1 изречение „кога е за предпочитане“ под всяко.
Слаба подкана / Силна подкана
Слабо: „Напишете ми функция за потвърждение на имейл.“
Силно: "TypeScript 5, само стандартна библиотека. Напишете isValidEmail(input: string): boolean. Изрежете интервалите, направете го нечувствителен към главни и малки букви, a@b.co е валиден, a@, @b.co, празният низ е невалиден. Ако ще използвате regex, не бъдете прекалено сложни; добавете 2 реда коментари."
Мощна версия; Връща езика, версията, подписа, крайните случаи и ограничението за стил. По този начин генерираният код работи и се вписва във вашия проект.
подход
Кога да използвате
внимание
Вградено завършване
Малки вложки в потока
Не приемайте предложението, без да го прочетете
Производство на базата на договор в чат
Нова функция/клас
Дайте пример и крайния случай
Производство по стилова проба
Добавяне към съществуващ код
Изберете текущия примерен код
пълнеж за скелет
Подписът е фиксиран, тялото е празно
Смяна на подписа
Дублиране на код и капана на зависимостта
AI често препоръчва нова библиотека, за да улесни работата си. Понякога това е точно, понякога добавя ненужна зависимост към вашия проект или предлага пакет, който не съществува (халюцинация). Правило: потвърждавате всяка нова зависимост. Не го добавяйте към проекта, без да проверите дали пакетът действително съществува, поддържа се и има съответния лиценз. През повечето време помощникът, който вече е в проекта, е по-добър от нов пакет.
Внимание: Прегледайте линиите за импортиране, предложени от AI. Несъществуващо име на пакет (което също може да наподобява фалшиви пакети, наречени „печатна грешка“) нарушава компилацията и представлява риск за сигурността.
Често срещани грешки
- Има сигнатура, определена от модела. Ако не коригирате типовете вход/изход, с всяка продукция идва различен подпис и интеграцията става трудна.
- Да не говорим за крайните случаи. Празен вход, нула, отрицателно число, много голяма стойност — ако не посочите тези, моделът записва „щастливия път“, като прескача ръбовете.
- Комбиниране на предложението без тестване. Кодът, който изглежда работи, не означава, че работи.
- Приемане на ненужна зависимост. Добавянето на цяла библиотека за едноредов създава технически дълг.
- Несъответствие в стила. Различното именуване и обработка на грешки от останалата част от проекта прави кодовата база неравномерна.
В обобщение
Генерирането на код е мощно, когато преведете намерението в ясен договор. Използвайте вградено завършване за малки задачи в поток и за задачи, които създават структура в разговора. Вие определяте входно/изходни типове, крайни случаи, версия и стил; Дайте пример за модела; проверявайте всяка нова зависимост; и стартирайте и прочетете всяка произведена част. AI се отплаща най-добре във формулиран, повтарящ се код – стартирайте го точно там, в границите, които сте задали.
Задача за приложение
Изберете действителна малка функция от вашия проект, която трябва да напишете. Първо го отпечатайте в AI с шаблона „генериране на функция, базирана на договор“, давайки типове вход/изход, два крайни случая и ограничение на стила. Компилирайте генерирания код и го опитайте с два различни входа. След това попитайте отново същата функция, този път „напишете ми това“ без никакъв контекст и сравнете двата изхода ред по ред: кои крайни случаи са пропуснати, колко корекции са били необходими?
контролен списък
- [ ] Знам къде да използвам режим на чат с вградено завършване.
- [ ] Определям договора за вход/изход и крайните случаи при генериране на функция.
- [ ] Създадох си навик да добавям информация за език и версия към подканата.
- [ ] Компилирам и тествам всяка произведена част, преди да я сглобя.
- [ ] Потвърждавам всяка нова зависимост, предложена от AI, като проверявам нейното съществуване и необходимост.
- [ ] Проверявам дали генерираният код отговаря на стила на проекта.