ДОГОВОР О РАБОТЕ С ИИ-АССИСТЕНТОМ (CURSOR)

Оглавление

1. Статус ИИ как участника команды
2. Обязательные правила работы ИИ (регламент поведения)
3. Уровни доверия и режимы использования ИИ
4. Риски использования ИИ и их снижение
5. Контроль качества и интеграция результатов
6. Использование ИИ в развитии проекта и работе с версиями
7. Правила постановки задач и формирования промптов

1. Статус ИИ как участника команды

ИИ-ассистент (Cursor) рассматривается как четвертый участник команды, наряду с архитектором, тимлидом и тестировщиком. Он включен в рабочий процесс как исполнитель и инструмент принятия решений второго уровня.

При этом ИИ не обладает правом финального решения и не несет ответственности за результат. Его зона ответственности — генерация решений, ускорение разработки и помощь в анализе.

Распределение ответственности фиксируется:

• архитектор принимает технические и архитектурные решения;
• тимлид управляет приоритетами и сроками;
• тестировщик отвечает за качество и допуск к релизу;
• ИИ выполняет задачи строго в рамках заданных условий.

2. Обязательные правила работы ИИ (регламент поведения)

ИИ обязан соблюдать следующие правила в рамках проекта:

1. Не генерировать решения без понимания задачи и контекста.
2. При недостатке данных сначала задавать уточняющие вопросы.
3. Не изменять архитектуру системы без явного указания архитектора.
4. Не предлагать решения, противоречащие ранее принятым договоренностям.
5. Учитывать ограничения проекта (стек, структура, API-контракты).
6. Не выдавать предположения как достоверные факты.
7. Предлагать несколько вариантов решения при сложных задачах.
8. Указывать потенциальные риски своих решений.
9. Не оптимизировать код в ущерб читаемости и поддерживаемости без указания.
10. Работать строго в рамках поставленной задачи без саморасширения функционала.

Нарушение данных правил рассматривается как ошибка инструмента и требует дополнительной проверки со стороны команды.

3. Уровни доверия и режимы использования ИИ

Работа ИИ делится по уровням риска.

• В задачах низкого риска (CRUD, модели, базовые API, Docker) допускается минимальный контроль.
• В задачах среднего риска (рефакторинг, SQL, внутренняя логика) требуется обязательная проверка через review и тестирование.
• В задачах высокого риска (архитектура, безопасность, бизнес-логика) ИИ используется только как источник вариантов, а решения принимаются исключительно человеком.

Таким образом, уровень доверия к ИИ напрямую зависит от потенциальной стоимости ошибки.

4. Риски использования ИИ и их снижение

Использование ИИ связано с рядом рисков:

• логические ошибки;
• уязвимости;
• снижение производительности;
• нарушение архитектуры;
• ложная уверенность в корректности результата.

Управление рисками реализуется через четыре механизма:

• избегание (не использовать ИИ в критичных решениях без эксперта);
• снижение (ревью, тестирование, проверка крайних сценариев);
• локализация (ограничение влияния изменений внутри модулей);
• принятие (допуск незначительных ошибок в низкорисковых задачах с возможностью быстрого исправления).

Дополнительно используется анализ альтернативных решений, чтобы не зависеть от одного ответа ИИ.

5. Контроль качества и интеграция результатов

Любой результат работы ИИ проходит обязательную проверку.

• архитектор подтверждает соответствие архитектуре;
• тимлид подтверждает соответствие задачам и срокам;
• тестировщик подтверждает корректность и стабильность работы.

Изменения не допускаются в основную ветку без проверки и фиксации в системе контроля версий.

Особое внимание уделяется сохранению API-контрактов и согласованности между сервисами.

6. Использование ИИ в развитии проекта и работе с версиями

ИИ применяется для ускорения разработки MVP и последующих версий, но не заменяет инженерное мышление.

После каждой итерации команда анализирует результат:

• выявляет недоработки;
• фиксирует ошибки и проявившиеся риски;
• корректирует дальнейшие решения.

Новые версии разрабатываются в отдельных ветках или форках, что позволяет безопасно тестировать изменения.

Развитие продукта основывается на реальном использовании системы — анализируются действия пользователей и данные, что позволяет принимать более точные решения по доработке.

7. Правила постановки задач и формирования промптов

Эффективность работы ИИ напрямую зависит от качества постановки задачи. В рамках проекта вводится обязательный стандарт формирования промптов, исключающий неоднозначность и произвольную интерпретацию.

Каждый запрос к ИИ должен содержать:

• контекст задачи: где именно используется результат (сервис, модуль, этап разработки);
• цель: что должно быть получено на выходе (код, архитектурное решение, текст, исправление ошибки);
• ограничения: используемые технологии, запреты (например, не менять архитектуру, не использовать сторонние библиотеки);
• формат результата: строгое указание, в каком виде должен быть ответ (код, список, текст, таблица);
• границы изменений: что можно менять и что трогать запрещено.

Каждый промпт должен быть детерминированным, то есть при повторении должен приводить к сопоставимому результату.

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

Таким образом, промпт рассматривается как формализованное техническое задание, а не как свободный текстовый запрос.