Prompt Patterns I Keep Using in Real Work

I've been using LLMs for planning/development documentation since last year, and here are just a few patterns that ultimately survived.

1. Lock down the role and output format first

'You are X' was far less effective than 'The output must follow the JSON schema below.'

2. Include 2–3 examples

Two examples were better than ten lines of explanation. In particular, adding ambiguous edge cases as examples makes the results more stable.

3. Don't ask for everything at once

If you ask for summarization + classification + translation all at once, one of them always ends up weak. Splitting it into steps and reviewing the intermediate results led to better final quality.

4. Feed failure cases back into the prompt

Collecting incorrect outputs and adding them as counterexamples was the most efficient approach.

In the end, the conclusion is that prompts also need testing, just like code. If those who are good at this have other tips, please share them.

by 스타트업러596

9 answers

Agreed, especially #4. Gathering failure cases and adding them as counterexamples really makes a big difference.

by 알고리즘고수176 · ▲0

1 seems a bit divisive. For me, it was stable only when I included both role assignment and output format. If you only fix the format, the tone comes out too mechanical.

by 데이터덕후710 · ▲0

Is there a source? Or is it a summary of your own experience?

by 월급루팡259 · ▲0

Well, isn't #2 a case-by-case thing? If the domain is narrow, two examples are enough, but once the domain broadens, the moment you add more examples, the prompt alone ends up being thousands of tokens. In that case, I found it better to write detailed rules instead.

by 카페인중독882 · ▲0

I use it similarly, and I really relate to #3. If you ask it to do summarization + classification in one go, the classification always ends up weak lol. If you break it into steps, it may use more tokens, but the time spent fixing the output drops a lot, so overall it's a win.

by 월급루팡626 · ▲0

Oh, I didn’t know that. I never thought to include counterexamples.

by 지나가던행인660 · ▲0

If I could add one thing here, fixing the temperature or seed when running is also surprisingly important. If the same prompt gives different results every time, you can’t tell whether it’s an improvement or just luck. And with failure cases, you shouldn’t just collect them and leave it at that—labeling why each one failed in a single line makes it much easier later when you want to add counterexamples. I didn’t do this and ended up digging through two months of logs again...

by 지나가던행인132 · ▲0

I disagree. These days, models will figure it out and produce good results even if you just throw something at them carelessly, so I wonder if it's really necessary to go this far. Of course, when it comes to producing structured outputs, you're right.

by AI덕후240 · ▲0