Обмежені запити: як не дати штучним інтелекту-асистентам створювати паралельні стеки
Чому нечіткі запити щодо функцій змушують асистентів з кодування додавати дублікати бібліотек та обгортки, і як обмежений запит із шляхами, інваріантами та жорсткими обмеженнями це вирішує.
Джерела: AI Doesn’t Need Better Prompts. It Needs Boundaries.
Якщо попросити асистента з програмування „створити сторінку налаштувань користувача“, зазвичай ви отримаєте щось, що компілюється, відображається та виглядає готовим. Але якщо придивитися уважніше, часто виявляється, що цей код має власний сховище стану, власні функції отримання даних та бібліотеку валідації, якою ваш репозиторій ніколи не користувався. Нічого не ламається, і саме тому проблема залишається непоміченою під час перевірки. У цій статті пояснюється, чому нечіткі запити призводять до таких наслідків, чому додавання прикметників не допомагає, та як скласти чіткий запит, а також наводиться перелік перевірок, який допомагає зберегти створений код у межах вашої існуючої архітектури.
Чому нечіткі запити призводять до проблем
Уявіть команду, яка працює над додатком адміністрування для клієнта, створеним за допомогою React та TypeScript. У кодовій базі вже є примітиви форм, спільний клієнт API та хук для сповіщень. Хтось просить асистента створити сторінку налаштувань у одному короткому реченні. Результат включає вкладки, форми, повідомлення типу toast, інтерфейси завантаження та невеликий магазин станів. Однак ці зміни тихо суперечать кодовій базі:
- Стан форм керується бібліотекою, яку проект не використовує.
- Нові обгортки для функції fetch знаходяться поруч із спільним клієнтом API.
- Повідомлення типу toast створюються безпосередньо, а не через хук сповіщень проекту.
- Схеми валідації ігнорують структури, вже визначені у папці
types/. - „Магазин налаштувань“ з боку клієнта містить три поля, які насправді повинні знаходитися на сервері.
- Інтерфейси завантаження не відповідають решті панелі керування.
Жоден з цих варіантів не спричиняє помилок, і вони можуть пережити швидкий огляд, якщо тільки хтось не відкриє файл package.json. Ось у чому небезпека: нечіткі запити призводять до м’яких помилок. Вони створюють другий спосіб виконання завдання, яке команда вже вирішила, і кожен майбутній адміністратор успадковує обидва варіанти. Асистент добре справляється з кодом, який може бачити; саме файли, які він ніколи не відкривав, визначають, чи справді ця функція належить до вашого додатку.
Чому довший запит — не рішення
Зазвичай радять бути конкретнішими. Природною наступною спробою є запит на сторінку налаштувань „досконалої, готової до використання“ з „чистим інтерфейсом користувача, якісним TypeScript та надійною обробкою помилок“.
Це створює ту саму паралельну архітектуру, проте з більшою впевненістю. Ці слова описують смак, а смак залишає модель цілком вільною у створенні структури. Того, чого бракувало, ніколи не було елоквенції. Це були межі: чіткі вказівки щодо того, що модель може використовувати, чого не повинна додавати та що вважається завершеним.
Написання обмеженої версії
Наведений нижче обмежений запит просить про ту саму функцію, але формулюється як опис посади. У ньому вказані точні компоненти, hook, клієнт API та файл схеми для повторного використання, перелічене поводження під час роботи з вкладками та надсилання даних, визначені тести, а наприкінці — чіткі заборони.
Build a user settings page in React and TypeScript.
Use ONLY these existing pieces:
- `src/components/FormField.tsx`
- `src/components/Button.tsx`
- `src/hooks/useNotify.ts`
- `src/api/client.ts` (no new fetch wrappers)
- validation schemas from `src/types/userSettings.ts`
Behavior:
- Tabs: Profile, Notifications, Security
- Preserve unsaved edits when switching tabs
- Show server field errors beside the matching inputs
- Disable submit while in flight
- Ignore duplicate submits
Tests:
- loading, success, server error, duplicate click
- empty required fields
Do NOT:
- add a state-management library
- add a toast library
- create a new API client
- invent types that duplicate `src/types/userSettings.ts`
Це скоріше примітка щодо архітектури, якої мусить дотримуватися модель, ніж кращий запит. Порівняно з однорядковим формулюванням, воно передає сім аспектів, які раніше залишалися на волю випадку:
- Які існуючі компоненти слід використовувати знову.
За наявності цих обмежень отриманий різниця стає досить одноманітним. Використовуються ті самі FormField, те саме useNotify, ті самі api/client. Вкладки зберігають свій незбережений стан без необхідності створення нового сховища, а подвійна передача даних обробляється за допомогою вимкненої кнопки та тесту, а не коментаря „обробити пізніше“. У вже існуючих кодових базах є готові шаблони; завдання інструкції — чітко вказати на них, щоб модель не могла їх пропустити.
Це також пояснює, чому досвідчені розробники отримують кращі результати від асистентів. Їхня перевага полягає не у формулюванні, а у знанні заздалегідь того, які деталі мають значення. Важливо — передати архітектуру, а не просто прикрасити запит.
Швидкий тест на обмеженість
Якщо ваш запит мав би сенс, якщо його вставити до будь-якого репозиторію у світі, він ще не є обмеженим. Хороший запит має бути дещо безкорисним поза вашою власною структурою коду, оскільки він посилається на ваші шляхи, типи та конвенції.
Перелік перевірок перед використанням
Зберігання шаблону над кожним запитом на функцію допомагає зробити дотримання певного стилю звичкою. Шаблон нижче групує запитання за такими категоріями: контекст, інваріанти, поведінка, обмеження та визначення завершеності роботи. Розділ з інваріантами найчастіше ігнорується: рішення щодо того, чи знаходяться дані на сервері, у URL чи у локальному стані інтерфейсу, допомагає уникнути проблеми „зберігання трьох полів“ ще на початковому етапі.
CONTEXT
- Stack: React + TypeScript
- Relevant paths: ...
- Patterns to copy: ...
INVARIANTS
- Where does data live (server / URL / local UI state)?
- What must survive refresh?
- What is the source of truth for types/validation?
BEHAVIOR
- Happy path
- Empty / invalid input
- Server errors (field-level + form-level)
- Slow network / double submit
- Permission failure
CONSTRAINTS
- Do not add: ...
- Do not invent parallel: API client / store / toast / form lib
- Prefer editing: [files]
DONE
- Tests for: ...
- Manual checks: ...
Використовуйте шаблон як критерій готовності. Якщо ви не можете заповнити розділи з обмеженнями та відповідними шляхами, ви ще не готові до створення коду; ви все ще знаходитеся на етапі проектування. Створення коду під час активного проектування саме так призводить до появи другої архітектури. Стабільні частини цього списку перевірок можуть знаходитися у файлі інструкцій проекту; дивіться наш посібник з створення ефективного файлу CLAUDE.md.
Що ще потребує людського перегляду
Обмежені запити усувають більшу частину «шуму», але вони не замінюють собою оцінку. Переглядаючи відмінності, все одно перевіряйте:
- Новий пакет, який ніхто не схвалив.
- Інший спосіб виклику API.
- Типи, які відхиляються від умов контракту сервера.
- Стан на стороні клієнта для даних, які має володіти сервер.
- Тести, які не перевіряють нічого поза сценарієм успішної роботи, який припустив модель.
Написання запиту — це проста частина; розуміння того, які обмеження важливі в цьому кодовому базисі, — складна частина, і ці знання належать команді.
Найменша зміна, яку можна внести сьогодні
Якщо повний перелік завдань здається обтяжливим, додайте до свого наступного запиту на функціонал лише три рядки: які шляхи використовувати, які бібліотеки не додавати та як виглядає стан «готово», включаючи принаймні один сценарій невдачі.
Use only: [paths]
Do not add: [libs]
Done when: [2–3 behaviors + one failure path]
Підсумок
- Розпливчасті запити рідко спричиняють збої; вони створюють дублікати інфраструктури, які виглядають готовими, але згодом коштують вам дорого.
- Більше прикметників змінює тон результату, а не його структуру. Обмеження змінюють структуру.
- Чітко сформульований запит визначає назви файлів для повторного використання, джерело інформації про дані та типи, поведінку у крайніх випадках, тести та залежності, які є забороненими.
- Якщо модель вигадує щось поза межами визначених правил, сприйміть це як відсутність меж: виправте запит та генеруйте результат заново, замість того щоб просто вдосконалювати формулювання.