Andrew Koenig first coined the term "antipattern" in an article
in JOOP[1], which is sadly not available on the internet. The essential
idea (as I remember it [2]) 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 be 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.