你的"扮演专家"提示词正在骗你：免费提示词清单缺的是失败模式标注

Search "best ChatGPT prompts" and you'll get ten thousand lists, all free, all organized the same way: a category header, a block of italicized text starting with "Act as a world-class expert in X," and nothing else. No note on when it works. No note on when it quietly produces something wrong. No note on what to check before you trust the output.

That's not a prompt library. It's a collection of strings that once worked for someone, in a session you can't see, on a task you don't know, with a model that's since been updated twice.

The missing piece isn't the prompt — it's the annotation

A prompt that works for "summarize this document" and a prompt that works for "refactor this function" look similar on the page and behave nothing alike in practice. The thing that actually transfers from one person's successful session to your next one isn't the wording — it's the metadata around it: when to reach for it, what good output looks like, and specifically how it fails when the task is slightly outside its lane.

That failure-mode part is the one free lists never have, because writing it requires having watched the prompt fail. Nobody screenshots the failure. They screenshot the one time it worked.

Building the annotation habit yourself

You don't need someone else's library to start doing this — you need a place to write down what you already know and a format that forces the useful information out of your head.

Log every prompt you reuse more than twice. If you've typed a variant of the same instruction three times this month, it's a candidate. One-offs don't need a library entry.
Write the failure mode before you write the success case. Ask: what task, superficially similar to the one this prompt is good at, will this prompt handle badly? "This prompt assumes the function has no side effects — it will miss concurrency bugs" is a real annotation. "Works great!" is not.
Organize by job, not by persona. "Act as a senior engineer" tells you nothing about when to use it. "Debug a failing test with an unclear stack trace" tells you exactly when to reach for it.
Record the model and rough date. Prompts tuned against one model's instruction-following quietly rot as models change. A library with no dates is a library you can't trust six months in.
Re-test on real failures, not synthetic ones. The annotation that matters came from an actual session where the prompt misled you — not from imagining how it might fail.

What this catches that a free list never will

A prompt that's excellent for greenfield code and actively harmful on a legacy codebase with implicit invariants — the wording is identical either way; only the annotation tells you which situation you're in.
A "world-class expert" framing that measurably changes nothing about output quality, but costs you tokens and context window every single call — you only notice once you've A/B tested it against the same task without the framing.
A prompt that worked three months ago and silently stopped, because the model's defaults shifted — invisible without a date next to the entry.

None of this requires buying anything — a shared doc with five columns (prompt, job, when to use, failure mode, last verified) gets you most of the value, and the real cost is the discipline to update it after every bad session, not before. We built a pre-annotated version of exactly this (Prompt Ops, 150 prompts with the failure-mode notes already written from real sessions) for the version of you that would rather start from a tested baseline than build the log from zero — but the habit is the part that actually compounds, and that part you can start today with a blank spreadsheet.

The next time a prompt surprises you by failing, don't just fix the task and move on. Write down what it got wrong. That one line is worth more than the ten thousand free lists combined.