Resize the files all you want, but unless you find the root of the problem, it's just going to grow back to the same size. And now every time SQL Server has to grow the file, it will cause a performance hit. If you're going to shrink the file before finding the root cause, at least set your autogrowth to something like 1G increments.

Really though, follow Jason's suggestion and find the root cause. Personally, I have a stored procedure that logs the sizes and usage of all of my database files every hour. I then built a report to chart out this history. I then set up a data-driven subscription to alert me if any of the file sizes change, or if a database is using over 80% of it's available space. It took me about a day to set this up, but it is worth it. I am never suprised by database file growth. When there is a problem, I am able to pin-point the hour in which it occurred. Usually this is enough to give me a really good idea of what caused it.

--J