배송 전에 AI 출력 확인: AI 정확도 확인을 위한 3가지 프롬프트

Every AI answer you use lands somewhere: a config, a migration, a doc your teammates will trust. Shipping it unverified means its mistakes ship too — under your name. This article is the working routine I use to verify AI output before it ships: three copy-paste prompts to check AI accuracy, each doing one job, composing into a check that takes minutes, not an afternoon.

The first two — a hallucination sweep and an AI fact-checking prompt — come from earlier in this series (linked below, each with its own test run). The third — building a verification checklist sized to the stakes — is new here, tested on a booby-trapped example further down.

What does it actually take to verify AI output?

Three moves, in order, each answering a different question:

1. Sweep — which claims are even in here, and which look fabricated? Broad and shallow, across the whole answer.
2. Stress-test — is this one load-bearing claim actually true? Narrow and deep, on the claims that would change your decision.
3. Checklist — what’s the complete set of checks this text deserves, given the stakes? The step that turns “I checked some things” into “I checked the right things.”

Most people stop after an instinctive version of step 1. The failures that reach production usually live in steps 2 and 3.

Prompt 1: sweep the answer for hallucinations

The condensed version:

Audit the text below for hallucinations.
List every factual claim as a numbered line; label each
VERIFIABLE, SUSPECT, or FABRICATION-PATTERN (named
source/study/number with no citation).
End with the 3 claims most likely to be wrong, ranked.
Text: [PASTE THE AI ANSWER]

Enter fullscreen mode Exit fullscreen mode

In part one’s test run, this pattern caught all three planted errors in a sample answer — including a fabricated Stanford study. The trade-off: it hands back labels, not verdicts, and the flag count grows fast with text length.

Prompt 2: stress-test the claim you’re about to act on

The short form:

Stress-test this claim. Do not assume it is true.
State what evidence would prove it wrong, the 2-3 conditions
it silently depends on, and the likeliest confounder.
Verdict: SUPPORTED / UNCLEAR / DOUBTFUL, one line why,
plus the single fastest check a human should run.
Claim: [PASTE ONE CLAIM]

Enter fullscreen mode Exit fullscreen mode

The design is adversarial on purpose — it builds the case against the claim instead of inviting agreement. In part two’s test run, this fact-checking prompt took “using an ORM prevents SQL injection” from code-review folklore to a DOUBTFUL verdict with the exact escape hatches that break it.

Prompt 3: build a verification checklist sized to the stakes

The new one, in full — this is the step that decides how much checking the text deserves:

Build a verification checklist for the AI-generated text below.
1. State the stakes: LOW / MEDIUM / HIGH, and why in one line.
2. List 3 checks for LOW stakes, 6-8 for MEDIUM or HIGH — each
   check names what to verify and the fastest way to verify it.
3. Order checks so the most damaging-if-wrong claim comes first.
4. End with the one claim that invalidates everything if wrong.
Text: [PASTE]

Enter fullscreen mode Exit fullscreen mode

Damage-ordering is the point. A checklist that starts with the most dangerous claim means that even if you only do the first check, you did the right one.

Does the checklist prompt actually catch what matters?

I fed it four sentences of plausible AI-style upgrade advice — “upgrade PostgreSQL 12 to 16 in place with pg_upgrade, downtime under a minute, back up with pg_dumpall, run ANALYZE after, extensions are upgraded automatically so no manual steps are needed” — with that last claim as the planted trap: fluent, reassuring, and false. One pass, Claude Sonnet, fresh context. What came back:

• Stakes: HIGH, with the right reason — following this on a production database risks silent data-access failures after the backup window closes.
• The planted trap ranked as check #1 — called false as a blanket claim, with the fastest check spelled out (SELECT * FROM pg_extension;, then per-extension compatibility notes).
• The same claim named as the invalidating one — the run’s closing line: rely on it, and you can “complete the upgrade believing it succeeded” only to find broken functionality after rollback is gone.
• Coverage I hadn’t planted: it flagged that “downtime under a minute” silently depends on --link mode, that a backup you haven’t test-restored isn’t a backup, that the 12→16 multi-version jump itself needs verifying, and that the text has no rollback plan at all — eight checks, damage-ordered.

That last bullet is the real argument for the checklist step: it doesn’t just audit the sentences that exist, it surfaces the checks the text should have mentioned and didn’t.

Where does the free checklist prompt stop?

Three walls, visible in that same run:

• Facts-first coverage. The checks orbit the claims present in the text. Logic errors, edge cases, and compliance exposure surface only if the text happens to hint at them — nobody asked “who can sue us over this?”
• Stakes by gut feel. LOW/MEDIUM/HIGH in one line is a vibe check. It was right this time; nothing guarantees the same call on subtler input.
• Structure drifts. Check count, depth, and phrasing vary run to run — fine for one-off use, weak as a routine you rely on daily.

For the routine version I maintain the full prompt as a paid product: AI Verification Checklist Builder on PromptBase. It sizes the checklist from a stakes rubric instead of a one-line guess, extends the checks to logic, edge cases, and legal review instead of stopping at facts, and ends every run the same way — with the load-bearing claims that invalidate everything else if wrong.

How do the three prompts fit together?

The composition rule is short:

Situation Move Whole AI answer, unvetted Sweep (prompt 1), then stress-test the survivors that matter One claim you’re about to act on or repeat Stress-test (prompt 2) directly Text about to ship somewhere real Checklist (prompt 3) — then actually run the top checks

And one rule above all three: the model’s audit is the map, not the territory. Every verdict and every checklist item still ends with a human running the check — a grep, a doc page, a test restore. The prompts don’t replace verification; they make sure the minutes you spend verifying land on the claims that can actually hurt you.

Written with AI assistance. The checklist test run in this article was performed as described — one pass, Claude Sonnet, fresh context — and reported faithfully; the earlier prompts’ test runs are documented in their own articles. Reproduce this one: the input is quoted above.

The full checklist version is linked in the section above. If your bottleneck is the prompt itself rather than the output, I also maintain Optimizer: Diagnose & Rewrite. Earlier in this series: catching AI hallucinations and fact-checking ChatGPT.