user11611479

Есть такая иллюзия: если ИИ плохо работает, значит надо написать ему более правильный промпт.

Типа:

• “Будь внимателен”.

• “Не ошибайся”.

• “Проверяй факты”.

• “Не болтай”.

• “Работай как 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 или другого ИИ-агента в реальной работе, не начинайте с вопроса:

“Какой промпт ему написать?”

Начинайте с другого:

“Где будет жить память этой работы?”

Потому что если память живёт только в чате, через неделю у вас будет не инженерный помощник, а очень уверенный амнезийный попугай.

Умный, быстрый, полезный.

Но без нормальной рабочей среды - опасно болтливый.

«нужно написать курсовую работу и программу»

Сервис считает такие услуги запрещёнными.

И их позиция:

👉 если ты откликнулся — значит согласился
👉 значит нарушил

Но есть нюанс

Заказ:

• был опубликован

• прошёл их модерацию

• был показан мне системой

Сам сервис пишет, что использует алгоритмы подбора заказов.

То есть:
👉 заказ мне сам показал Profi.ru

Что произошло дальше

Я просто нажал «откликнуться»
→ получил блокировку на 2 недели

Без:

• переписки

• подтверждения

• выполнения

Фактически:
блокировка за сам факт клика

Ещё интереснее

На момент блокировки у меня был действующий клиент.

Работа уже выполнена, её нужно было отправить.

Но:

👉 доступ к чатам заблокирован
👉 отправить результат невозможно

Ответ поддержки:

«Связаться с клиентами во время блокировки не получится»

То есть по факту

Платформа:

• сначала показывает заказ

• даёт на него откликнуться

• потом банит за отклик

• и параллельно мешает выполнять уже взятые обязательства

Мой вопрос

Это нормальная практика?

Блокировать специалиста:

• без переписки

• без факта работы

• без подтверждения

И при этом:

• не давать завершить уже начатые задачи

Итог

Я уже направил им претензию.

Но сам кейс, на мой взгляд, показательный:

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

Интересно услышать мнение:
у кого был похожий опыт с площадками?

Ответа по существу я не получил.

Вместо правового обоснования мне:

• сообщили о зачислении средств в WB Кошелёк;

• предложили писать на почту;

• повторили стандартную формулировку из правил.

Но вопрос о законности изменения способа возврата и невозможности возврата через СБП — остался без ответа.

Почему это важно

Если оплата производится через СБП (государственная платёжная система),
а возврат односторонне осуществляется через внутренний кошелёк маркетплейса —

это:

• меняет платёжный маршрут;

• может ухудшать положение клиента;

• создаёт риск недоступности средств при ограничениях на кошельке.

Мне интересно понять:
это единичная ситуация или системная практика?

Вопрос к сообществу

1. Сталкивался ли кто-то с возвратом не тем способом, которым платили?

2. Если платили через СБП — возвращали ли вам через СБП?

3. Были ли случаи зачисления именно в WB Кошелёк без отдельного согласия?

Если есть похожие кейсы — напишите, пожалуйста, в комментариях или в личку.

Я собираю информацию, чтобы понять масштаб ситуации.

Без эмоций, без обвинений.
Просто хочу разобраться, насколько это соответствует правилам и закону.

При этом:

• оплату через СБП принять — можно;

• товар продать — можно;

• а вернуть деньги тем же способом — нельзя.

Поддержка отвечает, что «так предусмотрено правилами».

Вопросы, которые меня реально волнуют

1. Почему возврат не идёт тем же способом, что и оплата?

2. Почему деньги возвращаются во внутренний кошелёк, а не туда, откуда они пришли?

3. Это вообще нормально с точки зрения прав потребителя?

Я не юрист и не ищу скандала.
Просто хочу понять, сталкивался ли кто-то с таким же и как в итоге решалось.

Если у вас был похожий опыт — напишите, пожалуйста.

UPD:
В процессе разбирательства обнаружился ещё один момент.

При оплате через WB-кошелёк Wildberries предоставляет скидку на товар.
При оплате другими способами (СБП, карта) — скидка не применяется.

При этом из истории операций видно, что даже при оплате через СБП средства фактически проходят через WB-кошелёк — они зачисляются и тут же списываются на оплату заказа.

При возврате товара деньги в одностороннем порядке возвращаются именно в WB-кошелёк, независимо от способа оплаты.

Таким образом, когда использование кошелька выгодно площадке — он применяется, а когда оно ухудшает положение потребителя — ответственность перекладывается на покупателя.