одиниця 2 / 12

Сценарії та автозаповнення

Прибуток:

  • Можливість зіставлення режиму чату з виправленням типу завдання за допомогою вбудованого завершення
  • Можливість писати потужні виробничі підказки, які включають контракти введення/виведення, крайові випадки та обмеження стилю
  • Можливість перевірити згенерований код і будь-які нові запропоновані залежності перед злиттям

Першим контактом розробника зі штучним інтелектом часто є автозаповнення — функція, яка пропонує наступний рядок під час введення тексту — або промова «введіть цю функцію» у вікні чату. Вони обидва використовують той самий двигун, але вимагають різних дисциплін. У цьому підрозділі ми перетворюємо генерацію коду з випадкового «запису» на крок розробки, результат якого є передбачуваним і перевіреним.

Мета полягає в тому, щоб перетворити ШІ з інструменту, який пришвидшує вашу машину друку, на учня, який працює в рамках встановлених вами обмежень. Добре скерований учень економить час; Некерований учень створює безлад, який вам доведеться прибирати пізніше.

Два режими використання: вбудоване завершення та чат

Вбудоване завершення починає діяти під час введення тексту в редакторі; Ви вводите підпис функції або рядок коментаря, і він пропонує решту. Він чудово підходить для швидкості, але має вузький контекст: він бачить лише код у безпосередній зоні. Ось чому найкраще працює, коли ви чітко пишете свій намір у коментарі. Наприклад, //перевірка електронної пошти користувача, викидання ValidationError, якщо недійсний коментар, значно покращує пропозицію нижче.

Режим чату призначений для більших і структурованих завдань: «Додати сторінки до цього класу», «Витягти інтерфейс цієї служби». Тут ви маєте розкіш надати роль, контекст і формат. Загальне правило таке: завершення для невеликих і плавних завдань, розмова для завдань, які вимагають обдумування та структури.

Порада: не приймайте сліпо пропозицію завершення за допомогою «Tab». Прочитайте на секунду запропонований рядок; Звідси найчастіше витікає неправильна назва змінної або інвертована умова.

Кроки для перетворення намірів у код

  1. Дайте визначення договору. Яка поведінка функції введення, виведення та помилок? Наприклад, "Отримати електронну пошту, нормалізувати, якщо дійсний, викинути помилку, якщо недійсний".
  2. Вкажіть обмеження. Не використовуєте зовнішню залежність? Конкретний посібник зі стилю? Чи є обмеження продуктивності?
  3. Наведіть приклад. Пара введення-виведення («ali@x.com → дійсний, ali@ → помилка») переміщує розуміння наміру моделлю від передбачення до точності.
  4. Попросіть маленькі шматочки. Одна функція, одна відповідальність. Потім переходьте до наступного.
  5. Прочитайте та запустіть згенерований код. Компіляція + швидка спроба вручну є найдешевшим кроком гарантії.

Три міні-чохли

Випадок 1. Виробництво на основі коментарів підвищує точність. Розробник спочатку запитав функцію аналізу дати з порожнім тілом і отримав правильний результат у 3 раундах. Під час другої спроби, коли я визначив функцію за допомогою 4-рядкового коментаря (прийнятні формати, правило часового поясу, умова помилки) і запитав її, прийшов код, який працював у першому раунді. Та сама модель, той же день; різниця була лише в ясності намірів.

Випадок 2 — невказувати версію дорого. Одна команда зіткнулася із застарілим API на основі зворотного виклику, який замінює fs.promises у коді, створеному для Node.js. Коли рядок «Використовувати вузол 20, ESM, async/wait» було додано до підказки, виробництво слідувало за проектом у перший раз; Середнє значення 12 хвилин, витрачених на корекцію, було скинуто.

Випадок 3 — Реальний виграш у шаблонному коді. Мікросервіс вимагав 6 нових DTO (Data Transfer Object — простий клас даних, який переносить дані між рівнями) та їхні правила перевірки. Те, що раніше становило приблизно 90 хвилин ручної роботи, було скорочено до 35 хвилин після виробництва та перевірки ШІ; Оскільки повторюваність коду висока, а шаблон чіткий, штучний інтелект працював тут у своїй найефективнішій області.

Чотири шаблони, які можна копіювати

Генерація функцій на основі контракту:

Роль: Ви старанний розробник {{language}}. Функціональний контракт:- Ім’я: {{name}}- Вхідні дані: {{типи та їх значення}}- Вихідні дані: {{тип і значення}}- Статус помилки: {{що кидається/повертається, коли}}Обмеження: {{немає зовнішніх залежностей / стилю / продуктивності}}Приклади:- {{input_1}} -> {{output_1}}- {{entry_2}} -> {{error_2}}Спочатку дайте підпис + короткий план, а потім код. Написання тестів, просто функція.

Щоб відповідати існуючому стилю (адаптувати до бази коду):

Нижче наведено приклад функції з нашого проекту; Дізнайтеся тут про найменування, обробку помилок і стиль коментування. Напишіть функцію для {{new_task}} у ТОМУ САМОМУ стилі. Приклад: {{current_code}}

Від скелета до наповнення (заглушка → реалізація):

Заповніть скелет функції нижче відповідно до завдань у коментарях. ЗМІНИТИ підпис і тип повернення. Не створюйте допоміжну функцію, якої не існує; при потребі дайте мені знати "потрібен цей помічник". {{skelet_kod}}

Порівняння альтернативних програм:

Надайте 2 різні реалізації для {{task}}: (a) пріоритет читабельності, (b) пріоритет продуктивності. Під кожним запишіть 1 речення «коли краще».

Слабка підказка / Сильна підказка

Слабко: «Напишіть мені функцію перевірки електронної пошти».
Сильно: "TypeScript 5, лише стандартна бібліотека. Напишіть isValidEmail(input: string): boolean. Виріжте пробіли, не враховуйте регістр, a@b.co є дійсним, a@, @b.co, порожній рядок є недійсним. Якщо ви збираєтеся використовувати регулярний вираз, не будьте надто складними; додайте 2 рядки коментарів."

Потужна версія; Повертає мову, версію, підпис, краєві випадки та обмеження стилю. Таким чином, згенерований код і працює, і вписується у ваш проект.

Підхід

Коли використовувати

Увага

Вбудоване завершення

Невеликі вставки в потік

Не приймайте пропозицію, не прочитавши її

Контрактне виробництво в чаті

Нова функція/клас

Наведіть приклад і крайній випадок

Виготовлення за фасонним зразком

Додавання до існуючого коду

Виберіть поточний приклад коду

каркасна начинка

Підпис виправлено, тіло порожнє

Зміна підпису

Дублювання коду та пастка залежностей

AI часто рекомендує нову бібліотеку, щоб полегшити собі роботу. Іноді це точно, іноді це додає непотрібну залежність до вашого проекту або пропонує пакет, якого не існує (галюцинація). Правило: ви підтверджуєте кожну нову залежність. Не додавайте його до проекту, не перевіривши, що пакет дійсно існує, підтримується та має відповідну ліцензію. У більшості випадків помічник, який вже є в проекті, краще, ніж новий пакет.

Застереження: перегляньте лінії імпорту, запропоновані AI. Неіснуюча назва пакета (яка також може нагадувати фальшиві пакунки, які називаються "typo-squatting") одночасно порушує компіляцію та створює ризик для безпеки.

Поширені помилки

  • Має сигнатуру, визначену моделлю. Якщо ви не виправите типи вводу/виводу, різні підписи надходять із кожною продукцією, і інтеграція стає складною.
  • Не кажучи вже про крайні випадки. Порожній вхід, нуль, від’ємне число, дуже велике значення — якщо ви не вкажете це, модель записує «щасливий шлях», пропускаючи краї.
  • Об’єднання пропозиції без її перевірки. Код, який працює, не означає, що він працює.
  • Прийняття непотрібної залежності. Додавання цілої бібліотеки для однострокового створює технічний борг.
  • Невідповідність стилю. Іменування та обробка помилок, що відрізняються від решти проекту, роблять базу коду неоднозначною.

Підсумовуючи

Генерація коду є потужною, коли ви перекладаєте намір у чіткий контракт. Використовуйте вбудоване завершення для невеликих завдань у потоці та для завдань, які створюють структуру розмови. Ви вказуєте типи вводу/виводу, крайові випадки, версію та стиль; Наведіть приклад моделі; перевіряти кожну нову залежність; і запускати та читати кожну створену частину. Штучний інтелект найкраще окупається у шаблонному, повторюваному коді — запускайте його тут же, у межах, які ви встановили.

Аплікаційне завдання

Виберіть реальну невелику функцію зі свого проекту, яку вам потрібно написати. Спочатку надрукуйте його в ШІ за допомогою шаблону «генерування функції на основі контракту», вказавши типи вводу/виводу, два граничні випадки та обмеження стилю. Скомпілюйте згенерований код і спробуйте його з двома різними входами. Потім запитайте ту саму функцію ще раз, цього разу «напишіть мені це» без будь-якого контексту, і порівняйте два виходи рядок за рядком: які крайові випадки були пропущені, скільки виправлень було потрібно?

контрольний список

  • [ ] Я знаю, де використовувати режим чату з вбудованим завершенням.
  • [ ] Я визначаю контракт вводу/виводу та крайові випадки під час генерації функції.
  • [ ] Я взяв за звичку додавати інформацію про мову та версію до підказки.
  • [ ] Я компілюю та тестую кожну вироблену деталь перед її складанням.
  • [ ] Я підтверджую кожну нову залежність, запропоновану ШІ, перевіряючи її існування та необхідність.
  • [ ] Я перевіряю, чи згенерований код відповідає стилю проекту.