Англійська для GitHub Copilot

«Копілот написав це» не є поясненням, яке переглядач коду повинен прийняти — словник в цьому посібнику дозволяє команді обговорювати код з допомогою ШІ з такою ж точністю, як і код, написаний людиною, включаючи назву, коли інструмент отримав щось конкретно не так.

Ключовий словник

** Завершення ** — блок коду, який Copilot створює на основі навколишнього контексту, який буде запропоновано під час введення тексту і прийнято або відхилено за допомогою натискання клавіші.

• “Це завершення виглядало правильно на перший погляд, але використовувався застарілий підпис методу — завжди варто подивитись ще раз перед прийняттям, особливо у незнайомих частинах коду.” *

** Підказка (контекст) ** — навколишній код, коментарі і відкриті файли, які Copilot використовує як вхідні дані для створення завершення; якість завершення залежить від того, наскільки значною є кількість відповідного контексту, який буде показано програмі.

• “Підказки стали значно кращими після того, як ми відкрили визначення типів у іншій вкладці — підказка Copilot включає відкриті файли поблизу, отже більш відповідний контекст у перегляді означає краще завершення.” *

** Галюцинація ** — впевнена, але неправильна гіпотеза, наприклад, функція або метод бібліотеки, який насправді не існує, створена тому, що модель передбачає код, який виглядає правдоподібним, а не перевіряє його на реальних API. *“Це галюцинація — на цьому клієнті немає методу fetchWithRetry. Він виглядає точно так само, як справжній API, саме тому він пройшов перегляд без того, щоб хтось ставив під сумнів його»

** Вбудований балачок ** — інтерфейс розмови у редакторі, за допомогою якого ви можете запитати у Copilot про пояснення, переробку або виправлення певного фрагмента вибраного коду, відмінного від завершення у стилі автоматичного завершення. “Замість прийняття необробленого завершення, я використав вбудований чат, щоб запитати його про пояснення регулярного виразу, який він створив — виявилося, що він не обробляв необхідний нам крайній регістр, тому я переписав цю частину вручну.”

** Частота прийняття пропозицій ** — показник, за яким деякі команди стежать за тим, як часто створені завершення приймаються або відкидаються, використовується як приблизний (і недосконалий) сигнал про те, наскільки корисним є інструмент для певної бази коду або типу завдання. “Рівень прийняття наших пропозицій набагато нижчий у старій службі, ніж у нових службах — Copilot має менше відповідного контексту для витягування у старій, менш послідовно структурованій базі коду.”

Звичайні фрази

• Чи ви перевірили це завершення, чи це просто виглядало правдоподібним?»
• Чи це галюцинація — чи дійсно існує цей метод?»
• Чи можна в цьому контексті говорити про кращі результати?»
• Чи використовували ви вбудований чат, щоб отримати пояснення, або прийняли його так, як є?»
• Чи є рівень прийняття, що говорить нам щось корисне тут, або це просто шум? “

Приклади висловлювань

Позначення проблеми під час перегляду коду: “Це завершення посилається на параметр налаштування, якого не існує у нашій версії бібліотеки — це галюцинація, а не друкована помилка. Варто двічі перевірити все, що пропонує Copilot, коли мова йде про незнайомий або старий API. ”

Пояснення, чому пропозиції не є надійними: “Завершення в цьому файлі постійно виключені, оскільки майже немає відкритого відповідного контексту — визначення типів і функція, яку він викликає, знаходяться в файлах, які ми не торкалися в цьому сеансі.”

Опис вибору потоку роботи:

• “Для будь- чого нетривіального, я використовую вбудований чат замість того, щоб просто приймати необроблене завершення — попросивши його пояснити свою власну пропозицію, я захоплюю дивовижну кількість галюцинаційних деталей, перш ніж вони перетворяться на PR.” *

Професійні поради

• Скажіть ** галюцинація **, а не « помилка », коли пропозиція вигадує щось, чого не існує — це відмінний режим невдачі від логічної помилки, і відповідь на перегляд відрізняється (перевірте чи існує API взагалі, а не лише чи правильна логіка).
• Розглядати кожне ** завершення ** як чернетку, що вимагає перевірки, особливо навколо незнайомих API — прийняття коду, тому що « він виглядав правильно », це саме той режим невдачі, який дозволяє галюцинаціям у виробництві.
• Згадуйте, коли ви використовували ** вбудовану розмову ** для пояснення у описі PR — це надає переглядачам корисний контекст щодо того, як було отримано частину сформованого коду і що було фактично перевірено.
• Будьте обережні, роблячи висновки лише з ** ступеня прийняття пропозицій ** — високий ступінь може означати, що засіб є справді корисним, або що команда приймає пропозиції без достатнього вивчення.

Практичні вправи

1. Напишіть речення, у якому пояснюється, що таке галюцинація у контексті асистентів кодування штучного інтелекту.
2. Пояснити, чому кількість видимого контексту впливає на якість завершення.
3. Опишете ситуацію, у якій ви використовували б вбудовану балачку замість простого прийняття завершення.

Навигація по нумерації: понад базовим завершенням

Для не-англомовних носіїв англійської мови, особливо, освоєння специфічної термінології навколо інструментів завершення коду ШІ, таких як GitHub Copilot, може здатися пригнічуючим. Це не просто про розуміння * того, * що він робить; це про ефективне спілкування в рамках технічного потоку роботи - під час перегляду коду, обговорення Slack, і описи запитів на витяг. Багато нюансів полягає у тому, як ви формулюєте пропозиції, розв’ язуєте потенційні проблеми і описуєте поведінку цих інтелектуальних помічників. Часто просто сказати «це запропонував» недостатньо, щоб передати рівень впевненості або обережності, який потрібен.

Один з найчастіших сценаріїв - отримання коментаря перегляду коду, що пропонує зміну - можливо, рефакторинг для поліпшення читабельності або коригування для обробки кращих випадків. Замість того, щоб реагувати оборонно («Чому ви змінюєте мій код?»), більш професійна відповідь може бути: «Дякую за позначення цієї потенційної проблеми. Пропозиція другого пілота щодо вилучення цієї логіки у окрему функцію відповідає підходу нашої команди до підтримки і зменшує ризик помилок у довгостроковій перспективі. Зауважте використання таких фраз, як « флагінг », « відповідає » і « зменшує ризик ». Це не просто ввічливі слова; вони демонструють розуміння більш широкого технічного контексту. Аналогічно, при описі зміни, яку ви зробили на основі пропозиції Copilot в описі PR, стверджуючи «Copilot запропонував цю поліпшену обробку помилок» краще, ніж просто сказати «Я виправив помилку»

Іншим критичним елементом є розпізнавання і відповідне звернення до випадків, коли Copilot виробляє неточні або вводять у оману пропозиції - часто називаються “галюцинаціями”. Жизненно важливо бути прозорими про ці ситуації. Корисним підходом може бути такий: « Copilot створив цей фрагмент коду, але він, здається, засновано на застарілій версії бібліотеки. Я оновив його, щоб відобразити поточні найкращі практики і забезпечити сумісність. ” Не звинувачуйте Copilot безпосередньо; зосередьтеся на фактичній проблемі і вашій виправленій дії. Це демонструє критичне мислення і відповідальне використання інструменту.

Нарешті, коли запитувати Copilot ефективно - створювати чіткі і конкретні інструкції - це ключ до отримання корисних пропозицій. Неясні запитання дають неясні результати. Точне виконання ваших запитів значно покращує якість виводу.

Ось приклад, який показує, як можна використовувати Copilot у простому скрипту Python:

# Example: Using Copilot to generate a function for calculating the factorial of a number

def factorial(n):
  """Calculates the factorial of a non-negative integer."""
  if n == 0:
    return 1
  else:
    result = 1
    for i in range(1, n + 1):
      result *= i
    return result

Цей простий приклад демонструє, як Copilot може прискорити процес розробки. Пам’ятайте, ефективне спілкування і критичне оцінювання так само важливі, як і сам інструмент.