I think this happens to all of us at some times. We all have to make some assumptions. If you can bounce your known assumptions off of someone that knows the ropes in your environment and "area" of development early on, I have found that helps root out half of the bad assumptions right off the bat. It usually only takes a couple minutes and as you alluded to, it can save you a lot of time if you can clarify before any time is wasted.
I find it's helpful to start any problem by getting all the information you have already together in one place (written or electronic), and ask questions to clarify what is needed is exactly what you are planning to do. Initial conversations clarifying requirements and what is expected from your client/boss/end users also helps you to clarify what you know and what you don't. It takes time to learn what questions need to be asked, and that's a learning curve in most vocations. Knowing what to ask, and of who, is a valuable skill we can all benefit from.
Also, as soon as an issue surfaces, challenge your assumptions. If none are apparent, you may need to debug things line by line to identify where things start to go wrong. With that information, you can then start diagnosing/fixing or getting another set of eyeballs on the problem.
Pay attention to types of questions others ask you to help narrow down the problem. I am lucky enough to work with some people who model good question asking. If I approach them with a problem, the first thing they do is ask questions to help narrow down the problem. Generally they will start with simple questions to rule out obvious issues... "Are you on the right server?" "Are you logged in as the correct user?" ... progressing to more specific questions along the lines of "Did you try it the way it works over here?". "Did you use VisDif to compare the two files, to make sure those are the only differences between code you know works and the code that isn't?" It might sound silly, but the HelpDesk question "Is it plugged in?" is asked for a reason. I would guess that 90% of problems are something simple that has been overlooked.
I believe all of the above is helpful when looking at how to ask better questions based on your known assumptions. As far as the assumptions you are "not aware of", I would recommend you do some self-reflection and consider the kinds of biases that you may be more prone to have, and make an effort to consciously consider if any of these might be in play. This may or may not guide the questions you plan to ask.
Finally, plan what you ask if possible. Gather known information, consider what you need to know, and write questions that will help you gather the information you need. Consider who the best person to ask the question of is, and ask concisely to respect the time of others. If you want to practice asking better questions, it might be a good idea to plan some questions about a piece of work, run those questions by others (ex- your boss/senior developers) and ask them if there is anything else they would be asking or anything they would ask differently.
Disclaimer: Being fairly self-aware, I know I have to work on some of the above myself. We all make mistakes and assumptions, but the key is to learn from past mistakes. If you made an assumption that makes you feel "silly", console yourself and others by making sure those aware of your mistake know that you won't be making that same error again... and do your best not make that same mistake again.
