Есть такая иллюзия: если ИИ плохо работает, значит надо написать ему более правильный промпт.
Типа:
-
“Будь внимателен”.
-
“Не ошибайся”.
-
“Проверяй факты”.
-
“Не болтай”.
-
“Работай как senior developer”.
Звучит красиво. На практике через какое-то время всё равно получаешь:
-
— уверенный пересказ не того факта
-
— повторную проверку уже проверенного
-
— длинный отчёт вместо результата
-
— смешивание старой рабочей ветки с новой сломанной
-
— “я всё проверил”, хотя проверил не тот путь
Я за последнее время довольно плотно гонял Codex по реальным задачам. Не “напиши hello world”, а нормальная грязная работа:
-
— код
-
— отладка
-
— база знаний
-
— генерация контента
-
— настройка правил
-
— работа с несколькими проектами
-
— подключение Claude Code
-
— попытка сделать так, чтобы ИИ не терял контекст
И вывод получился неприятный:
сам по себе ИИ-агент не становится надёжным от того, что ты назвал его “senior”.
Его надо обкладывать правилами, памятью и журналами как опасный, но полезный инструмент.
Проблема 1. Он красиво болтает
Самая бесячая штука: ИИ часто не просто ошибается.
Он ошибается гладко. Он пишет структурно:
-
— вот факт
-
— вот вывод
-
— вот следующий шаг
Только потом выясняется, что факт был не тот.
В одном проекте была ситуация:
-
— один путь давал хороший результат, но с тремя пустыми участками
-
— другой новый экспериментальный путь сломался
Модель взяла и смешала это в одну кашу. Начала говорить, что “качество плохое”.
А это неправда.
Правильно было:
-
— хороший путь есть
-
— в нём три пустоты
-
— новый эксперимент сломан отдельно
Разница огромная.
Но если не проверять, гладкий текст выглядит убедительно.
Проблема 2. Он забывает документацию
Ещё пример.
В проекте уже было прописано, как подключаться к серверу, чтобы попасть к устройству в другой сети.
Что сделал ИИ?
Сначала полез проверять локальный IP с моей машины.
Естественно, не увидел.
Потом начал перебирать ssh-алиасы.
Хотя в документации уже был конкретный путь.
Это не “маленькая неточность”. Это реальная потеря рабочего контекста.
Если бы это был человек, я бы сказал: ты не прочитал инструкцию.
С ИИ ровно так же.
Проблема 3. Он любит промежуточные отчёты
Это отдельная боль.
В длинных задачах Codex начинает писать:
-
“Продолжаю”.
-
“Проверяю ещё”.
-
“Факт сузился”.
-
“Сейчас добиваю ветку”.
На вид работа кипит.
На деле часто нет нового результата.
Нет нового файла.
Нет нового артефакта.
Нет нового источника.
Просто модель успокаивает тебя текстом, пока тратит контекст.
И вот тут надо было сделать жёсткое правило:
или результат, или блокер.
Всё.
Не отчёт о героическом страдании.
Не “я ещё ищу”.
Не “почти понял”.
А:
-
— что доказано
-
— что заблокировано
-
— что нужно от человека
Что пришлось построить
В итоге вокруг Codex пришлось собрать почти маленькую производственную систему.
Не сложную платформу. Просто набор файлов.
1. Память ошибок
Файл:
`errors.md`
Туда записывается:
-
— какую ошибку допустили
-
— почему
-
— как не повторять
Примерно так:
“Не проверять локальную сеть, если в runbook уже указан серверный путь”.
Это звучит банально, но без такого файла ИИ повторяет старые ошибки как ни в чём не бывало.
2. Память решений
Файл:
`solutions.md`
Туда пишется всё, что реально сработало.
Не рассуждения, а reusable pattern:
-
— задача
-
— подход
-
— какие файлы важны
-
— когда использовать снова
Потому что если решение нашли один раз, нельзя через неделю снова устраивать археологию по чатам.
3. Wiki проекта
Потом стало понятно, что memory-файлов мало.
Нужна нормальная wiki:
-
— текущее состояние
-
— архитектура
-
— решения
-
— риски
-
— следующие шаги
-
— журнал изменений
То есть модель должна не просто отвечать из головы, а сначала смотреть в канон проекта.
И если она нашла новый устойчивый факт, он должен попасть обратно в wiki.
4. Правила поведения
Пришлось прописать режимы:
-
— не болтать без результата
-
— не останавливаться на браке
-
— не смешивать разные ветки фактов
-
— не продолжать длинную сессию, когда контекст почти закончился
-
— на низком остатке контекста делать короткий handoff, а не эпический монолог
Особенно важное правило:
если результат плохой и ИИ сам это видит, он не имеет права на этом закончить.
Плохой результат — это диагностический мусор, а не deliverable.
Что я понял
ИИ-агент не похож на сотрудника мечты.
Он скорее похож на очень быстрого стажёра, который:
-
— читает быстрее всех
-
— пишет быстрее всех
-
— иногда реально находит крутые решения
-
— но может забыть инструкцию
-
— может смешать факты
-
— может уверенно говорить ерунду
-
— может делать вид, что работа идёт, потому что пишет много текста
И если вокруг него нет системы, он будет сжигать время.
Не потому что “злой”.
А потому что он оптимизирует правдоподобный ответ, а не инженерную дисциплину.
Что реально помогает
Не один “волшебный промпт”.
Помогает связка:
-
— правила проекта
-
— память ошибок
-
— память решений
-
— wiki
-
— журнал изменений
-
— жёсткий формат ответа
-
— проверка результата
-
— запрет на пустые промежуточные отчёты
После этого ИИ становится не идеальным, но намного более управляемым.
Главный вывод
Если вы хотите использовать Codex, Claude или другого ИИ-агента в реальной работе, не начинайте с вопроса:
“Какой промпт ему написать?”
Начинайте с другого:
“Где будет жить память этой работы?”
Потому что если память живёт только в чате, через неделю у вас будет не инженерный помощник, а очень уверенный амнезийный попугай.
Умный, быстрый, полезный.
Но без нормальной рабочей среды — опасно болтливый.
