10 ChatGPT Prompts for Improving Your IT English Writing (англійською)

Якість виводу ChatGPT майже повністю залежить від того, як ви запитаєте. Неясні запитання призводять до загальних виправлень. За допомогою певних підказок можна отримати пояснення, з яких ви можете дізнатися більше.

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

---

1. Європа Перезапис повідомлення

** Найкраще для: ** Створення пошукових, послідовних і людськими читабельних звітувань.

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

• Нет, не надо Мое сообщение: [your commit message]

** Що ви дізнаєтесь: ** Структура type(scope): summary — чому використовується імперативний настрій, чому використовується нижній регістр, чому обсяг має значення для створення журналу змін.

---

2-й. Полімерізатор звітів про вади

** Найкраще для: ** інженерів з контролю якості, розробників, які надсилають проблеми в JIRA або GitHub Issues.

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

• Нет, не надо Мой отчет: [paste your bug report]

** Що ви дізнаєтесь: ** Структура професійного звіту про помилку, що складається з шести полів, та різниця у словниковому запасі між * очікуваною * і * фактичною * поведінкою.

---

3-й. Померла від інсульту

** Найкраще для: ** SRE / DevOps інженерів писати бездоганний пост-морт.

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

• Нет, не надо Площа 0,08 га

** Що ви дізнаєтесь:** Пасивні конструкції, які використовуються для написання без покарання (* « порог не було оновлено » * проти * « Джон забуває оновити порог » ), словниковий запас на часовій шкалі ( до, приблизно, після *).

---

4-й. Слабкий перезаписувач оновлень

** Найкраще для: ** Асинхронне повідомлення про оновлення стану у розподілених командах.

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

• Нет, не надо Моя обновка: [your Slack message]

Що ви дізнаєтесь: Різниця між інформуванням і закопуванням ваших читачів у деталях. Словник для асинхронного зв’ язку: * заблоковано, очікується, піднято, передано, повертається назад *.

---

5-й. Генератор коментарів перегляду коду

** Найкраще для: ** Розробників, які хочуть надати чітку, дипломатичну оцінку перегляду коду.

Я хочу залишити коментар щодо перегляду коду щодо наступної проблеми. Переписати мої думки як професійний, конструктивний коментар до рецензії. Зробити його конкретним і запропонувати виправлення або напрямок. Поясни, чому ти вибрав саме такий тон.

• Нет, не надо Випуск: [describe the problem in plain words, e.g. "this function does too many things"]

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

---

6-й. Технічний працівник з редагування теми електронної пошти

** Найкраще для: ** Спеціалістів, які пишуть багато технічних листів.

Дай мне пять переписанных строк темы для этого технического письма. Оцініть їх від найбільш до найменш відповідних для формального контексту B2B і поясніть відмінності.

• Нет, не надо Оригінальна тема: [your subject line]

** Що ви дізнаєтесь: ** Чому * « Швидке запитання » * вважається низькоякісним; як зробити рядок теми повним об’ єктом інформації; словник термінів, що стосуються терміну « терміново » (* потрібна дія, для перегляду, подальшого аналізу: *).

---

7-й. Шаблон:Підписи описів PR

** Найкраще для: ** Інженерів, які мають звичку писати порожні описи запитів на завантаження.

Допоможи мені написати повний опис запиту на звантаження для цієї зміни. Використовуйте цю структуру: (1) Що змінилося і чому, (2) Як було перевірено, (3) Як переглянути, (4) Будь- які ризики або зауваження. Потім поясніть, яка інформація є найціннішою для рецензентів.

• Нет, не надо Зміна: [describe your PR in a sentence or two]

** Що ви дізнаєтесь: ** Різниця між * що* (опис відмінності) і * чому* (мотивація), а також те, як контекст скорочує час перегляду.

---

8-й. Будівництво фортеці Квебек

** Найкраще для: ** Створення активного словника з поточного робочого контексту.

Я працюю над [describe your current project/technology]. Давайте я проведу тест на 5 питань з використанням технічних термінів, якими користуються фахівці в цій галузі. Для кожного питання вкажіть чотири варіанти з можливим вибором і пояснення правильної відповіді.

** Що ви дізнаєтесь: ** Словниковий запас у тестовому форматі — набагато ефективніше для запам’ ятовування, ніж читання словника.

---

9-й. Спрощення технічної документації

** Найкраще для: ** Інженерів, яким потрібно пояснити технічні поняття нетехнічним користувачам.

Переписати це технічне пояснення для нетехнічної аудиторії (наприклад, менеджера продукту або клієнта). Вилучати жаргон, де це можливо, і, де жаргон необхідний, коротко його визначати. Тогда скажи мне, какие изменения ты сделал и почему.

• Нет, не надо Моє пояснення: [paste your draft]

** Що ви дізнаєтесь: ** Різниця між * точністю * (потрібна для технічної документації) і * ясністю * (потрібна для спілкування з зацікавленими сторонами), а також які технічні терміни дійсно потребують визначення.

---

10-й. Інтерв’ю з Поліною Світлиною

** Найкраще для: ** Підготовка до технічних або поведінкових інтерв’ ю англійською мовою.

Я готуюсь до інженерного співбесіди в англомовній компанії. Я відповім на наступне питання. Будь ласка, оцініть мою відповідь за допомогою методу STAR (Ситуація, Завдання, Дія, Результат). Позначте, що відсутнє, що неоднозначно, і що звучить неприродно для носіїв англійської мови.

• Нет, не надо Питання: [interview question] Моя відповідь: [your answer]

** Що ви дізнаєтесь: ** Як структурувати вимовлені відповіді для ясності, словниковий запас досягнень (* зменшено, поліпшено, проведено, реалізовано, зменшено затримку на 40% *), і які фрази для заповнення обрізати.

---

Як отримати найбільше з цих пропозицій

** Ітерація, не приймайте перший результат. ** Після того, як ChatGPT відповість, задайте наступні питання:

• “Чому ви обрали саме це слово замість [альтернативне]?”
• “Чи є більш формальна версія цього?”
• • “Що старший інженер подумає про цю фразу?” *

** Зберігайте ваші найкращі приклади. ** Коли ChatGPT створить перепис, який вам сподобається, скопіюйте його до особистого словника або фразової нотатки. Перегляньте його наступного разу, коли будете писати щось подібне.

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

---

• Див. також: Як використовувати ChatGPT для практики технічної англійської, Письменницькі вправи, Англійська мова для перегляду кодів *

Розширюючи свій словниковий запас за межі основ

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

Частим викликом для носіїв, які не є рідними, є розуміння тонких відмінностей у фразуваннях, які радикально змінюють значення. Розглянемо простий коментар перегляду коду: « Це потребує переробки ». Хоча це технічно коректно, але це надзвичайно неоднозначно. Ефективнішим підходом буде: « Логіка у цій функції може бути витягнута у окремий компонент, який можна використовувати знову, щоб поліпшити перевіряність і зменшити складність ». Зауважте додані слова: * переробка *, * логіка *, * витягнуто *, * компонент, який можна використовувати знову *, * перевіряність *, * складність *. Ці слова не просто технічні; вони представляють певний спосіб оформлення проблеми, демонструючи розгляд довгострокової підтримки. Аналогічно, в Slack, відповідь на звіт про інцидент, що говорить «Система вниз!», Недостатня. Професійнішою відповіддю буде: « Підтверджено — дослідження потенційних причин і координація з мережевою інженерією щодо останніх затримок у розповсюдженні DNS ». Тут ви використовуєте такі терміни, як * підтверджено *, * причина *, * координація *, * затримки у розповсюдженні DNS * — демонструючи структурований підхід до розв’ язання проблеми.

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

І, нарешті, не недооцінюйте силу ввічливої та активної мови. Просте «Дякую за вашу допомогу» йде довгий шлях до створення позитивних робочих відносин. Пам’ятайте, ефективна IT англійська мова не тільки про те, щоб бути технічно точним; це про будівництво довіри і співпраці через чітке, професійне спілкування.