5 правил роботи з ШІ
Вітаю, пані та панове, мене звати Макс, я продукт-інженер у Goodly (ви це вже знаєте), і це мій перший досвід написання будь-яких статей, не рахуючи шкільні роботи та листи святому Миколаю. Отже, сподіваюсь, це перша із серії статей, де ми з вами пройдемо шлях від людей, яким дуже цікаво працювати з ШІ, до людей, які хапають панічку, коли в Клода лежать сервери.
Маленьке передслово: колись дуже давно, у 18 років, я був дуже щасливою людиною, бо моя родина могла собі дозволити подарувати мені авто на 18-річчя. Памʼятаю, як батько ходив по домі і розповідав, який я безвідповідальний, бо я в магазин за хлібом на машині катаюсь, а його ж ондо видно з вікна! З тих пір нічого не могло порівнятися з тим бажанням першою справою зранку сісти за кермо і швидко нарізать собі справу, а краще дві, щоб з важливим виглядом кататись по літньому Києву. Аж допоки в моєму житті не зʼявився ШІ (це був просто дим у лісі), а потім Клод Код (момент, коли я побачив пожежу).
Отже, зараз я знову в точці, де тепер без Клода навіть браузер на ноутбуці не відкриваю, а головним критерієм вибору сервісу для мене стала наявність можливості додати API-ключ і віддати його ШІ разом із набором інструкцій, щоб він там у всьому розібрався і розповів мені, коли зрозуміє суть. Якщо я зможу навчити Клода їздити за батоном у найближчий АТБ — гарантую вам, я відмовлюсь і від цього задоволення.
Ви бачили приблизно, де я є setup-wise (на едью токс), наскільки сильно інтегрую ШІ у своє життя, наскільки мені пощастило мати команду, яка поділяє це бажання, і як я хочу поділитися цією любовʼю з вами та показати простими прикладами, що між мною і вами мінімальна дистанція в 3 місяці ентузіазму і цікавої роботи. І ви зможете підкорювати нові горизонти, а я — підглядати за вашими рішеннями і красти ідеї.
Зі вступом на цьому всьо, давайте почнемо.
Для початку короткі організаційні деталі. Моя ціль тут, як я написав вище, допомогти вам увійти у світ ШІ або розвинутись у ньому якомога швидше, якщо ви вже є його частиною. Я не є гуру, вчителем, всезнайкою чи майстром хоч чогось. Я просто приділяю дуууууже багато часу роботі з ШІ і готовий ділитись досвідом. А ще я не проти навчитись писати.
Час від часу (комічуся раз на два, три, ну мааааксимум чотири тижні, пинайте і гнобіть мене, якщо запізнююсь) я планую випускати статті на якусь певну тему, яку ми разом обиратимемо у Goodly AI чаті — тиць. Сподіваюсь, мої тіммейти підхоплять цю ідею, а кожен із вас буде як мінімум активно брати участь в обговоренні, ставити питання, сперечатись і кидати в мене помідори, направляти мене далі і розповідати, що вам би було цікаво почути, а також, якщо вам є що розповісти, писати і викладати статті разом зі мною.
Отже, план наразі надійний, як батьківська обіцянка повернути тобі 200 грн, які подарували дідусь і бабуся: я починаю розповідати все хаотично (так працює мій мозок), а ви підказуєте, куди йдемо.
Сьогоднішня стаття — це вступ + перші кейси. Я дуже хочу одразу почати з якихось персональних правил взаємодії з ШІ і одного практичного кейсу, де намагатимусь довести вам, що ШІ — це просто, там немає магії і вам не потрібно мати три вищі освіти, щоб уміти ним користуватись у повсякденному житті.
Це не універсальна методологія і не святе письмо. Це просто набір правил, які в мене найчастіше спрацьовують.
Почнемо з 5 правил, якими я керуюсь при роботі з ШІ. У деяких я додам пояснення, десь піду в мрії і спогади, а десь буде нічо не ясно, але сподіваюсь, якісь із них ви зможете перейняти чи, принаймні, зрозуміти, як точно не треба робити :)
Правило номер 1
ШІ може все (або нічого)
Якщо коротко, я по життю не мав жодного домену, де я досяг повного розуміння і знання. Кожне завдання було для мене челенджем, де мені потрібно було робити рісьорч, і мій мозок нагадував бібліотеку рандомних фактів, які на перший погляд не мали нічого спільного, але якимось чином видавали потрібні рішення. Потім прийшов ШІ.
Я це до чого: зараз я підходжу до роботи з ШІ з позиції, що він може все, бо якщо він не може, то я тим паче не можу і ми в дупі.
Не в сенсі, що він безпомилковий. А в сенсі, що я стартую з припущення: рішення існує, просто ми ще не знайшли правильний шлях до нього.
Я стикнувся з проблемою, коли починав, що коли підходиш з точки зору того, що ти знаєш і в чому певен — ШІ не працює так само ефективно, як якщо б ти обрав підхід незнайки.
Коли ж підходити до вирішення завдання з точки зору того, що скоріше за все ви зможете його вирішити, просто ще не знаєте як, бо погано вчились, — стається диво. А саме: завдання, де людина з профільними знаннями знала б 33 блокери і проблеми, бо вже вчила це все чи практикувала в до-ШІ еру, для мене не є проблемою. У результаті вони стають або моїми big WIN, або проєктом, де не вийшло, бо Клод ще не там. Але, за моїм відчуттям, 60% випадків — це біг він, де ви зможете швидко, легко і без малєйшего поніманія, як це працює, заделіверити корисне рішення.
Коротенький приклад і підемо далі. Приклад вкрав у друга. Завдання в нього було цікаве: у вебапці зробити хаптік на айфонах робочим. І тут більшість iOS-інженерів казали, що це неможливо чи Apple не дає такого функціоналу. Це й жеж чєловєк, за допомогою дикої впертості і Клода, який мав перти вперед, незважаючи на жодні обмеження, знайшов варіант, як можна використати якісь там екстрені сповіщення в браузері: якщо їх зафейкати, хаптік дуже навіть працює.
Суть не в тому, що це красиве або канонічне рішення. Суть у тому, що людина не зупинилась на “неможливо” і змусила ШІ шукати обхідний шлях.
Правило номер 2
Правильна побудова процесу
Усім нам відомий факт, що ШІ любить недопрацювати: там забув, там прикинув, там відклав — і в результаті нічого не працює. Мене це не влаштовувало, як і вас, але потім я припустив, що проблема насправді в мені. Отже, я вирішив знайти формулу, за якою ШІ таки працює як потрібно, і вона неочевидна, але проста.
Research -> Research more -> Explore -> Plan -> Challenge your plan -> Research again -> Implement
Якщо коротко — ми завжди покладаємось на те, що моделі вже знають все, знають, як і з чим працювати, і знають, як все зробити з першої спроби. Це не так. Головна умова для гарної імплементації — гарний рісьорч. Пошук документації, реддіт-статей, Stack Overflow, простігосподі, постів у X і так далі. І ще — гарно описане завдання. Не технічно правильне, а саме гарно описане: просто передайте ШІ все, що є у вашій голові, коли ставите завдання.
Потім йде планування з урахуванням усієї зібраної інформації, потім челендж плану за допомогою самого ж ШІ (плани я інколи навіть не читаю, там 5000 символів! Клод, за що я плачу, щоб читати!?) і потім тільки імплементація.
Зрозумівши цей підхід, я все частіше отримував робочі рішення з перших 3-5 промптів, Клод перестав тупити чи відповідати нерелевантними варіантами, а якість делівері готових фічей стала кращою.
Ще простий приклад для тих, хто вже використовує ШІ для написання коду. Не потрібно просто впрягати його робити якусь фічу в сінглпейджі і дивуватись, чому не вийшло. Скорміть йому проєкт, хай розбере його за ніч на деталі, зрозуміє, про що він, як написаний, що використовує, вивчить весь код, складе собі мапу імплементацій і функціоналу. А потім усі фічі починайте розробляти з чіткого рісьорчу вашої актуальної кодбази + інтернету, в місцях, де потрібно більше даних. Ви здивуєтесь, наскільки це ефективно.
Правило номер 3
Інформаційний шум
У мене є друг, який дуже любить все блискуче. Якщо дуже хочеться забайтити його на щось — достатньо просто викласти на ютуб відео з назвою “THIS CLAUDE CODE SECRET CHANGES EVERYTHING!!!111!!!111!!!111”, і він піде його дивитись від кірки до кірки і тестувати.
Я навіть окремого телеграм-бота завів, щоб перекидати йому на рісьорч усе з категорії “о, диви, як круто”, що прилітає від нього.
Спостерігаючи за цим, а також ловлячи фомо від усіх новин, які летять у нас із кожної труби, про нові ШІ, нові моделі, нові можливості і так далі, я прийняв єдине правильне рішення: відрізати себе від цього шуму. Я відписався від усіх “крутих і унікальних” пабліків з новинами, перестав відкривати ютуб і зробив автоматизацію, яка раз на день видає мені максимум 5 найважливіших матеріалів зі світу AI згідно з реддітом (дуже раджу, якщо ви активно рісьорчите) і твітером.
Цього цілком достатньо, щоб дізнатись про все, що ви пропустили. Все інше ви або почуєте, або воно ніколи до вас не дійде, а значить, ви нічого не втратили.
Правило номер 4
Люди — про ідеї, ШІ — про імплементацію
Це правило пішло з багатьох кав, де я бачив очікування у людей почути від мене конкретне рішення для своєї проблеми чи блокера, а потім бачив розчарування, коли вони чули від мене: “Клод знає краще, спитай у нього”.
Ідея дуже проста, і це правило буде коротким: ніхто не підкаже краще за сам ШІ, як працювати з Клодом, як щось імплементувати або чому щось не працює. Всі мої рішення пішли з довгих переписок з ним же, де я просто мав косплеїти 6-річну дитину і питати “чому” на кожне незрозуміле рішення, відповідь чи момент, де він каже, що не може. А потім відправляти його подумати ще раз.
Люди ж є крутим джерелом ідей, шерінгу готових рішень (в деяких випадках) і напрямку для руху. “Спитай у ШІ” — це нове “загугли”. Але якщо в “загугли” ми знаходили щось пасивно-агресивне, то в “спитай у ШІ” такого підтексту немає. Це чесна порада, бо в цьому контексті ШІ знає краще за мене і будь-кого, кого я можу швидко спитати.
Tiny tip: для всіх своїх проєктів я прошу Клода пояснювати мені як 15-, 10- або 5-річній дитині. Навіть коли мені це не дуже потрібно. Завжди легше і зрозуміліше читати текст, де пояснюють “на яблучках”, а не словами, які потрібно окремо ще гуглити.
Правило номер 5
Від потреби до реалізації
Остання порада, яка теж частково народилася з мого досвіду кав, спілкування з іншими людьми, що активно працюють із ШІ, а також читання реддіт-постів. Не поспішайте робити ідеальні рішення. ШІ не про ідеал. Коли ви хочете зробити супер чудове рішення, за всіма правилами і канонами, по дорозі використавши ідеальний сетап Claude Code і неймовірно єдино правильне налаштування взаємодії через MCP, ви порушуєте першочергове правило і взагалі причину, з якої ви прийшли в ШІ: швидко заделіверити робоче рішення.
Завжди виходьте з проблеми.
“Правильний” claude.md зʼявився в моєму сетапі, коли мій Клод почав сильно тупити. Свій plan mode — коли стандартний перестав справлятись. Економію токенів я почав досліджувати, коли однієї підписки стало недостатньо на тиждень, а кожен скілл, рул або агент зʼявилися з чіткого запиту або проблеми.
Якщо завтра я вам скину свій сетап і допоможу його налаштувати 1:1 — гарантую, воно у вас не заведеться і не полетить, як у мене. І це не тому, що я шарю, а ви — ні. Це просто тому, що набір моїх запитів був унікальний, корелював з кожним проєктом, з яким я працював, і має купу своїх багів і проблем, з якими я не стикаюсь або через те, що я специфічно пишу промпти, або бо звик і ще не полагодив.
Тому тут немає мене, який шарить, і когось ще, хто не шарить. У кожного свій шлях розвитку, де ви будете вивчати ШІ під свої потреби і знаходити унікальний сетап, налаштування, секрети, tips and tricks саме для себе.
Вам не потрібно встановлювати бібліотеку з 100 агентів чи супер унікальний меморі сетап чужу магічну коробку виключно бо вона у когось працює. Дочекайтесь, поки щось стане для вас проблемою, а потім знайдіть своє унікальне рішення для неї.
А потім поділіться зі мною, я все вкраду і скажу, що сам то зробив.
Приклад
Для прикладу я обрав нещодавній кейс із колегою, яка поставила собі ціль переробити наш ноушен, прибрати все зайве і побудувати “правильну” структуру для подальшої ефективної роботи і залучення ШІ до роботи з даними. Покажу перший промпт, з якого ми почали, і фінальну версію, яка “спрацювала”.
Я не буду тут прикрашати і казати, що після фінального промпта більше не було правок. Звісно, ми не все взяли до уваги, не про все згадали і так далі. Але принаймні робота перетворилась з хаосу в систему, яка дала достатньо гарний результат для того, щоб надалі нашаровувати правки на цей результат. Також у фінальному промпті ви побачите використання деяких із правил, описаних вище.
Отже, промпти.
З чого ми почали
Орфографію й структуру оригінального запиту майже збережено, крім очевидної назви Goodly:
Ми стартап Goodly. В нас дуже-дуже забрузнана ноушн дуже бардак там, Мені треба навести порядок. Допоможи мені. Давай відштовхуватись від того, що наш ноушн зараз як для стартапи на 15 людей мають просто виконувати функції щоб нам було зручно, легко і щоб це спонукало команду трекати свої таски бо це дає нам візибіліться це просто інтуїтивно і легко і зручно. Такі принципи. В нас зараз дуже багато всього, нам треба цю структуру навпаки спростити. Нічого зайвого не треба. Тільки необхідна давай подумаємо над структурою: від верхнього рівня до конкретних речей. Давай виходити з потреб наших. Я буду і став мені питання. Щоб переорганізувати ці таски. Тут багато тасок, які вже неактуальні Ми не трекали їх ідеально. Деякі люди вже з нами не працюють. Деякі треки вже закінчились, дещо взагалі не проект, а таска. В різних місцях створено. Мені треба перебрати. Це все все і переорганізувати.Що в нас вийшло
# Goodly Notion v2: Refactor Program
Refactor the Goodly work Notion workspace through MCP + OAuth. Treat this as a phased program: research -> audit -> design -> grill -> implement -> verify.
## Rules
- No Notion structural changes before Phase 3.
- Maintain `~/Desktop/goodly-notion-v2/TRACKER.md` as source of truth.
- Re-read `TRACKER.md` before every action.
- Tracker statuses: `todo / researching / awaiting-grill / decided / blocked / planned / in-progress / done / skipped / merged-into-X`.
- No silent decisions. Put ambiguities in `DECISIONS.md` and grill us before implementation.
- Do not delete anything without explicit approval. Archive instead.
- Preserve original page/database titles in audit logs before renaming.
- Log every Notion mutation in `CHANGELOG.md` with before/after IDs and rationale.
- Use target namespace: `Goodly v2`.
- Measure effort by scope, not calendar time.
- Add `<!-- COMPACT-HERE -->` at every phase boundary.
## Required Folder
`~/Desktop/goodly-notion-v2/`
Files to maintain:
- `TRACKER.md`
- `RESEARCH.md`
- `AUDIT.md`
- `AUDIT-RAW.json`
- `DECISIONS.md`
- `PLAN.md`
- `MIGRATION-MAP.md`
- `CHANGELOG.md`
- `DONE.md`
- `FEATURES.md`
- `VERIFICATION.md`
- `HANDOFF.md`
## Phase 1: Research & Audit
No structural changes.
Research Notion OAuth/MCP, API limits, workspace architecture, databases, templates, reusable components, permissions, navigation, and safe migration practices.
Audit the full workspace: every page, database, schema, relation, parent, title, ID, timestamps, duplicates, stale areas, orphaned pages, broken relations, restricted content, and sensitive content.
Outputs:
- `RESEARCH.md`
- `AUDIT.md`
- `AUDIT-RAW.json`
- updated `TRACKER.md`
- `DECISIONS.md`
## Phase 2: Design & Grill
No structural changes.
Create:
- `PLAN.md`: proposed Goodly v2 structure, databases, templates, permissions, archive strategy, migration waves, risks
- `MIGRATION-MAP.md`: every existing item mapped to migrate / merge / archive / preserve / skip
- updated `DECISIONS.md`
Grill us on all unresolved decisions. Do not proceed until `PLAN.md` and `MIGRATION-MAP.md` are explicitly approved.
## Phase 3: Execute Migration
Only after approval.
Execute in waves: structure -> databases -> page moves -> relation rewiring -> templates/components -> cleanup/archive.
For each wave:
- re-read tracker
- snapshot affected IDs
- apply approved changes
- log all mutations in `CHANGELOG.md`
- verify affected items
- update `TRACKER.md` and `DONE.md`
Also produce `FEATURES.md`.
## Phase 4: Verify & Handoff
Compare pre/post inventories and prove no content loss.
Verify:
- every migration-map item exists in its destination
- archived items are preserved
- relations, rollups, formulas, and links work
- all grill decisions were applied
- unresolved issues are surfaced
Outputs:
- `VERIFICATION.md`
- `HANDOFF.md`
- final `TRACKER.md`
## Start
First: create the folder/files, scaffold `TRACKER.md`, and confirm the number of major work items before Phase 1.Не лякайтесь довжини. Тут головне не англійська і не формат, а те, що ми дали ШІ процес: фази, заборони, трекер, логування, точки перевірки й правило не приймати тихі рішення.
В нас не було питань до оригінального промпту. Мабуть, у нашій уяві це і є щось, з чим має вміти працювати ШІ і давати гарний результат на основі такого запиту. Єдина проблема: так це поки не працює.
Усе, що ми зробили з цим промптом: додали в нього “специфічні” інструкції, які розкривають сильні сторони моделі, організовують роботу ШІ і контролюють, що вся робота буде зроблена, нічого не буде загублено і, якщо навіть Клод затупить і вимкнеться на будь-якому етапі, ми зможемо продовжити і нічого не втратити. Також після проведеної роботи цей “план” стає знанням Клода, на яке він може спиратись наступного разу, коли працюватиме з нашим Notion.
Що змінилося:
- дали процес по фазах;
- заборонили тихі рішення;
- змусили вести трекер;
- додали логування змін;
- заклали перевірку й handoff;
- зробили так, щоб роботу можна було продовжити після будь-якого збою.
На цьому в нас сьогодні все. Якщо у вас є якісь питання чи коментарі, пишіть у чаті або мені в Slack. Також прошу, давайте почнемо серію обговорень із будь-чого в цій статті чи того, що стосується вашої персональної/робочої взаємодії з ШІ. Наша ціль — побудувати активну спільноту, де люди допомагають одне одному і розвивають культуру використання і розуміння штучного інтелекту на будь-якому рівні.