Проще всего представить доску как плоский список из девяти ячеек, с индексами от 0 до 8 – вот и все состояние игры. Тогда можно легко копировать этот список для рекурсии, и не нужно будет возиться с двумерным массивом. Держи отдельно список свободных ячеек, чтобы перебирать только их при генерации ходов. Сам процесс генерации ходов вынеси в отдельную функцию, которая принимает текущий список доски и возвращает лучший индекс. Внутри нее вызывай вспомогательную функцию minimax, которая копирует доску, делает ход, меняет игрока и рекурсивно вызывает себя. Если захочешь потом подкрутить ИИ – просто измени систему оценки или добавь ограничение глубины поиска в этой вспомогательной функции. Можно еще вынести простую функцию "сделать ход" – она применит ход к доске и проверит, не закончилась ли игра (победа/поражение/ничья), чтобы слой пользовательского интерфейса оставался чистым. Так код получится компактным, логика будет собрана в одном месте, и ты сможешь заменить minimax на что-то более сложное, не трогая остальную часть кода.

Просто сделай все по-простому: покажи игроку доску с цифрами от 1 до 9, чтобы он знал, куда вводить. Считывай строку через input(), убирай лишние пробелы и пробуй преобразовать ее в целое число, затем вычитай единицу, чтобы получить индекс ячейки на доске. Если число вне диапазона или ячейка уже занята, просто выведи короткое сообщение об ошибке и вернись к началу. Никаких замысловатых циклов, только while True, который завершится, как только будет введен правильный ход. Потом обнови доску и переключи игрока. В принципе, вот и все – так интерфейс будет чистым и удобным для изменений.

Ну, возвращай небольшой кортеж статуса – типа (доска, игрок, победитель). Тогда основной цикл просто сможет завершиться, если победитель не None или доска заполнена. Так всё будет аккуратно, без лишних флажков, плавающих где-то.

Всё пока нормально у меня, но если что странное вылезет с этой проверкой победы – сразу напишу. Спасибо, что предупредил!