Andrew Koenig first coined the term "antipattern" in an article in JOOP, which is sadly not available on the internet. The essential idea (as I remember it ) was that an antipattern was something that seems like a good idea when you begin, but leads you into trouble. Since then the term has often been used just to indicate any bad idea, but I think the original focus is more useful.
In the paper Koenig said:
An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one.
-- Andrew Koenig
This is what makes a good antipattern something separate to just a bad thing to point and laugh at. The fact that it looks like a good solution is its essential danger. Since it looks good, sensible people will take the path - only once you've put a lot of effort into it will you know it's bad result.
When writing a description of an antipattern it's valuable to describe how to get out of trouble if you've taken the bad path. I see that as useful but not necessary. If there's no good way to get out of it, that doesn't reduce the value of the warning.
It's useful to remember that the same solution can be a good pattern in some contexts and an antipattern in others. The value of a solution depends on the context that you use it.
1: Journal of Object-Oriented Programming, Vol 8, no. 1. March/April 1995. It was then reprinted in "The Patterns Handbook", edited by Linda Rising (Cambridge University Press)
2: I don't have a copy of the paper, so I'm going primarily off memory and some old notes.