If all commands are one-byte (no parameters), and ASCII, then you could modify your protocol to send two-byte commands, where one byte have high bit cleared and second byte have high bit set, and where there is a mathematical relation between first and second byte (such as 'a' followed by 0x80 + 'a' or 'a' followed by 0xff - 'a'). This would require two corrupt characters before the command is accidentally processed. And it would also mean that if you miss one character, you will still be able to synchronize again since each byte tells if it is a first or second byte. Also, a single-byte corruption (any bits) will result in an ignored command, instead of wrong command being executed. The two bytes with a mathematical relation may not be as optimal as a concept with hamming distance. But Hamming distance doesn't take into account the UART synchronization between each transmitted byte. It just considers how many bits that may be corrupted before you can get a different command.

Next thing is if there is a need for acknowledge, to let the sender know if a command (and potentially which) was executed or not. You could send the same two-character combo back as acknowledge, or some other character(s) (or just silence) as negative acknowledge if you didn't understand the command.

If there isn't a bandwidth limitation, then you could go all the way and define everything as packets - SOF + <cmd> + <len?> + <param?> + <crc16> + EOF, with all data in between SOF and EOF stuffed so you don't get false matches for SOF or EOF. With cmd + crc16, you will have quite good protection from bit errors in the transfer. And with unique SOF (at least), you will be able to pick up the synchronization after any transfer errors.

In all cases, you should have a pause between each command transfer of more than one byte transmit length (start bit + data + parity + stop bit(s)) just to make sure that the UART will recover from framing errors if it picks up a false start bit.