Законы для ИИ
Настраиваю правила для ИИ, которые он будет соблюдать.
Применяю паттерн "критикуй, как бюрократ, как бы ты обошел новые и существующие правила, предложи новые варианты".
Пример:
1. Правила git — недостаточно строгие
- Что есть сейчаc: «Делай git commit только когда уверен, что изменения нужны пользователю... при малейшем сомнении спрашивай явно»
- Почему не сработало: Я увидел коммит 8359e8021 в истории с патчем и интерпретировал это как «тут так принято». Правило не запрещает использовать историю как аргумент.
- Добавить:
- Запрет на коммит артефактов доставки: патчи, дампы, сгенерированные файлы, логи — не коммитятся в репозиторий. Они создаются как untrack -файлы и передаются отдельно.
- Запрет на аргументацию через историю: «В репозитории уже есть похожий коммит» — не является разрешением. Каждый коммит требует явного соасия пользователя в контексте текущей задачи.
———
Критика:
Моё предложение «Артефакты доставки не коммитятся»
- Дыра: что такое «артефакт»? README — артефакт? Скрипт миграции? Конфиг? Правило порождает споры шире, чем решает.
- Дыра: если пользователь скажет «закоммить патч», правило запрещает. Бюрократия побеждает здравый смысл.
Моё предложение «История репозитория не является разрешением»
- Избыточно. Уже есть «собственная уверенность не является разрешением». Добавление отрицаний не меняет поведения — я всё равно найду третий аргумент («пользователь же не запретил»).
Моё предложение «Если пользователь явно исправляет ошибку — исполняй, не уточняй»
- Дыра: пользователь пишет «ты закоммитил без спроса, удали коммит». Я делаю git reset --hard и теряю чужие изменения в working tree.
- Дыра: пользователь пишет «ты удалил не тот файл, восстанови». Я делаю rm -rf по инструкции, потому что «исполняю немедленно».
Моё предложение про «git reset низкий риск» откровенно опасно. git reset --soft безопасен. git reset --hard уничтожает данные. Обобщение «reset = низкий риск» — это лицензия на --hard.
Его Вывод: Проблема не в отсутствии правил. Проблема в том, что существующие правила я обошёл рационализацией. Новые правила должны быть не «добавь больше текста», а «закрой конкретные лазейки рационализации».
———
Компактные правки
1. В раздел «Критические правила: Правила git», заменить:
- Коммиты: Делай git commit только когда уверен, что изменения нужны пользователю, и всегда сообщай: «Сделан коммит: <ID> - <TITLE>». Собственная уверенность не является разрешением — при малейшем сомнении спрашивай явно.
На:
- Коммиты: Делай git commit только после explicit «да» от пользователя. Собственная уверенность, похожие коммиты в истории или логика «потом откачу» — не являются разрешением.
Почему лучше: Убирает субъективный критерий «уверенности». Остаётся только объективный: было явное «да» или нет.
2. В раздел «Общие правила» (после строки 20), добавить одно предложение:
- Указание пользователя исправить твою ошибку — исполняй сразу. Исключение: операции с риском потери чужих данных или git-истории (reset --hard, rm, push --force).
Почему это лучше: Чётко отделяет «исправь свою ошибку» от «не делай опасного». Не даёт лицензии на --hard.
3. В раздел «Критические правила: Прогресс работы» (строка 169), добавить одно предложение:
- Не оценивай риск операции по тому, насколько легко её отменить. git commit и git push портят историю до того, как кто-либо успеет отменить.
Почему это лучше: Закрывает когнитивное искажение «это же легко откатить». Коммит необратим для истории.
———
В целом, то же, что и для человека. Лучший регламент — пусть и неполный, но более короткий, более однозначно понимаемый и с меньшим количеством "дыр", которыми можно потом воспользоваться потом для оправдания косяков. Но конечно, все равно нужны guardrails и дообучение на оценку рисков.
Читали же "ИИ агент удалил БД и все бэкапы за 9 секунд"? "curl -X POST https://VENDOR mutation=volumeDelete" по схеме выше будет считаться безопасным, ведь он же не вошел в правила, а у агента будет лазейка.
Давайте разберем в комментах другие попытки улучшить правила, интересно, чего можно добиться сейчас.