Grok для розробників

Grok — це чудова «гумова качечка», яка вміє відповідати. На grok.online це безкоштовно та без реєстрації: Grok 4.20 швидкий для простих запитань, Grok 4.3 Thinking міркує перед відповіддю та краще підходить для пошуку багів, а Grok 4.7, найновіша модель, впорається з найскладнішими завданнями завдяки 10 із ваших 30 щоденних повідомлень. Усі три моделі розпізнають скриншоти. Ось сім сценаріїв використання із готовими промптами, які ви можете відкрити в чаті та змінити під себе.

Пошук і виправлення помилок

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

Розбір стек-трейсу

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

Я використовую [мова та версія] з [фреймворк]. Ось повна помилка та стек-трейс: [вставте помилку]. Ось код, на який вона вказує: [вставте код]. Поясни простими словами, що пішло не так і чому. Спочатку назви найімовірнішу причину, а потім покажи мінімальні зміни, які це виправлять.

Відкрити в чаті. Інструмент Code Assistant робить те саме в одній зручній панелі.

Огляд незнайомого коду

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

Мені щойно дістався цей файл на [мова], і мені потрібно змінити [функціонал]. Зроби короткий огляд: за що відповідає файл, які основні функції та в якому порядку вони викликаються, за яким глобальним станом чи побічними ефектами варто стежити, і де найбезпечніше внести мої зміни: [вставте код]

Отримати огляд, а потім розпитайте про функції, які досі викликають запитання.

Пошук логічного багу за допомогою моделі з міркуванням

Коли нічого не падає, але результат неправильний, потрібне ретельне трасування. Grok 4.3 Thinking аналізує логіку коду перед відповіддю, що ідеально підходить для помилок на одиницю та неправильних умов.

Ця функція на [мова] має [очікувана поведінка], але для вхідних даних [вхідні дані] вона повертає [фактичний результат] замість [очікуваний результат]. Простеж виконання крок за кроком для цих вхідних даних, покажи значення ключових змінних на кожному кроці та вкажи точний рядок, де виникає помилка: [вставте функцію]

Простежити з Grok 4.3 Thinking.

Виправлення верстки за скриншотом

Додайте скриншот поточної сторінки, вставте відповідний HTML та CSS і опишіть, який вигляд вона повинна мати.

Я додаю скриншот сторінки, де [опишіть проблему, наприклад: бічна панель перекриває контент на вузьких екранах]. Ось HTML та CSS цієї частини: [вставте код]. Поясни, що викликає проблему, і дай виправлений CSS із мінімальною кількістю змін.

Відкрити цей промпт і додати свій скриншот.

Планування ризикованого рефакторингу

Розплутування великого модуля — це саме те завдання, заради якого варто витратити одне з обмежених щоденних повідомлень найновішої моделі. Просіть план, а не готовий переписаний код.

Нижче наведено модуль на [мова], який стало важко змінювати: [вставте код]. Поки не переписуй його. Опиши його зони відповідальності, приховані залежності та покроковий план рефакторингу невеликими діями, щоб після кожного кроку код залишався робочим. Вкажи, які тести варто додати перед першим кроком.

Спланувати з Grok 4.7, а потім передавати кроки по черзі до Grok 4.20.

Створення супровідного коду

Тести, запити, код-рев'ю та документація — це те, чим зазвичай нехтують, коли горять дедлайни.

Тести для крайових випадків, які ви пропустили

Спочатку попросіть список випадків, а вже потім код тестів. Найбільша користь криється саме в списку.

Ось функція на [мова]: [вставте функцію]. Спочатку склади список крайових випадків, які варто протестувати (порожні вхідні дані, межі діапазонів, некоректні типи тощо), додавши короткий коментар до кожного. Потім напиши тести за допомогою [тестовий фреймворк], по одному тесту на кожен випадок, зі зрозумілими назвами.

Згенерувати тести, запустіть їх і залиште ті, які виявили реальні проблеми.

Рев'ю коду від суворого сеньйора

Grok із радістю зіграє роль рев'юера, який бачив кожен баг двічі. Бути суворим — це добре, але розмиті коментарі не допоможуть, тому просіть посилання на конкретні рядки.

Зроби рев'ю цього диффу як суворий, але справедливий senior engineer. Вкажи на баги, незрозумілі назви, відсутність обробки помилок і все, що створить проблеми через пів року. До кожного зауваження додай номер рядка та варіант виправлення. Відсортуй проблеми за важливістю й пропусти дрібні стилістичні причіпки: [вставте дифф]

Запитати рев'ю ще до того, як код побачать колеги.

Перетворення схеми на SQL та README

Надайте опис таблиць і запитання простими словами, а також попросіть коротке пояснення разом із самим запитом.

Ось структура моїх таблиць для [база даних, наприклад: PostgreSQL]: [вставте схему]. Напиши запит, який повертає [опишіть потрібний результат простими словами]. Поясни кожне об'єднання (join) та фільтр в один рядок і підкажи, який індекс може прискорити роботу, коли в таблицях будуть мільйони рядків.

Скласти запит, а потім попросіть створити розділ для README з описом цих таблиць.

Чого слід уникати

• Вставляти секретні дані. API-ключам, паролям, токенам і персональним даним клієнтів не місце в жодному чаті. Завжди замінюйте їх на плейсхолдери.
• Сліпо довіряти тонкощам бібліотек. Знання моделей обмежені певною датою, і вони не мають доступу до інтернету, тому функція чи параметр можуть бути застарілими або взагалі вигаданими. Звіряйтеся з офіційною документацією.
• Пушити непротестований код у прод. Навіть якщо код читається бездоганно, він може містити помилки. Запускайте його, тестуйте й перевіряйте власноруч.
• Надсилати цілі репозиторії. Занадто довгі повідомлення обрізаються. Надсилайте лише ту функцію, яка має значення.

Корисні сторінки

• Ще двадцять ідей у списку промптів для програмування.
• Наш гайд із кодингу з Grok та пояснення щодо моделей міркування.
• Створюєте власний застосунок? Дізнайтеся більше про Grok API.