Since you don’t know how to solve it, you first write a test that goes vaguely in the direction.
If you can’t do that yet, you spike, mess around with it, get your bearings and some insight into where you want to go, try a few things out. Then, trash that and then write the first test as above.
It almost always works, and excels somewhat in legacy code vs just changing things.
It isn’t about ‘might work’. The TDD paradigm isn’t about finding shiny places where you can use. It is just a nice way of writing clean maintainable software in almost all areas.
Places where TDD won’t work are usually by exception rather than the norm.
Often those exceptions are where something already exists and wasn’t put in by TDD because by the definition of TDD you wouldn’t have been able to write that in the first place.
It might work if you are starting on some new, relatively self-contained feature...