Why I treated GPT like a junior reviewer — and why prompts matter
When I first started using GPT to draft product reviews, I made the same mistake a lot of teams do: I handed the model a product name and asked for a “full review.” The output sounded great on the surface, but when I checked facts — specs, release dates, performance numbers — there were errors. Some were small, some were confidently wrong. That’s the hallmark of hallucination: fluent but not reliable.
Over the past year I iterated a practical approach to turn GPT into a trustworthy product review writer. It’s a mix of hard constraints in the prompt, explicit checkpoints during generation, and a verification workflow that leans on sources rather than on the model’s memory. Below I’ll share the exact prompts, checkpoints and process I use. They’re actionable — you can apply them with any GPT-style model and with retrieval-augmented tools like a browser or a vector DB.
Core mindset: model as assistant, not authority
First rule: never let the model be the single source of truth. I treat GPT as a skilled drafter that needs an evidence pack. The model’s job is to synthesize and write clearly; my job is to give it accurate inputs and to require traceable claims. Prompts should force the model to say where each factual statement comes from, or to mark uncertainty.
Essential prompt structure (use this as a template)
Start every request with a short brief, then a hard constraint block, then a source/instruction block. Here’s a compact template I use:
Prompt template — paste and adapt
"You are a product review writer for Mediaflash Co. Produce a concise, honest review of [PRODUCT NAME] aimed at marketers and tech buyers. Follow these rules strictly:
- Include a short summary, detailed pros & cons, key specs, and practical recommendations.
- Do not invent facts. For every factual claim (specs, release date, benchmark numbers, pricing), include an inline source bracket [1], [2], etc., and list full source links at the end.
- If you can't confirm a fact, explicitly state "Unverified: [fact]" and suggest how to verify (link or search terms).
- Limit opinion to clearly labeled sections (e.g., "My take").
- Be concise: aim for ~650-1200 words.
- Use plain English and explain technical terms briefly.
Use the following verified sources to base your review: [PASTE URLs OR DATABASE REFERENCES]. If no sources are supplied, respond with: 'No reliable sources provided — cannot produce factual review.'
Produce the review now."
Why those elements matter
Each rule addresses a common failure mode:
- Inline source requirements force traceability — you can map claims to links.
- Unverified flags prevent confident fabrication and make reviewers look for proof.
- Opinion labeling separates subjective judgment from verifiable facts — essential for editorial integrity.
- Source supply switches the task from "remember facts" to "synthesize given evidence."
Checkpoints to enforce during generation
I run the model through short checkpoints and ask for specific outputs. Use these as prompts between steps.
- Checkpoint 1 — Source inventory: "List the sources you will use and what fact each supports."
- Checkpoint 2 — Fact table: "Produce a table of key facts (release date, price, weight, battery life, CPU/GPU) and next to each fact, paste the citation." Use HTML table output for easy parsing.
- Checkpoint 3 — Confidence flags: "Mark facts as Verified or Unverified and explain why."
- Checkpoint 4 — Draft summary only: "Write a 100-word summary that contains no numbers or specific claims that are not cited in your fact table."
Sample fact table prompt and layout
Ask the model to produce a clear table you can scan quickly. For example:
| Field | Value | Source | Status |
|---|---|---|---|
| Release date | Q1 2024 | [1] https://example.com/product-announce | Verified |
This visual check is where you catch inconsistencies before the final write-up.
How I handle benchmarks and numbers
Numbers are where models most commonly hallucinate. My rule: only include benchmark or performance numbers that are directly in source material I supply, or that come from a trusted database (e.g., SPEC, PassMark, AnandTech, TechRadar). If the model must summarize multiple benchmark results, I force this phrasing:
- "Across sources [1][2], the score range is X–Y; median ~Z. Citation: [1] link, [2] link. If variance > 15%, explain likely causes."
Prompt examples for different review types
Consumer gadget (quick review):
"Write a 700-word review of the PixelPhone X using only these sources: [list]. Provide a fact table, inline citations, and a 'My take' section. Flag any unverified claim."
SaaS/productivity tool (feature-focused):
"Draft a 900-word product review of 'FocusFlow' targeted at marketing teams. Use supplied docs and the company pricing page. Include a feature matrix table, practical onboarding notes, integration checklist, and citation for each feature claim."
Verification workflow after generation
After the model produces the draft, I run a quick verification checklist. This is a human+tool step:
- Cross-check every inline citation — open the link and confirm the quoted value actually appears.
- If a claim references an unsupported source (e.g., [3] but no [3] in the list), reject and ask the model to fix.
- Spot-check one or two key numbers via independent sources (benchmarks, vendor pages).
- Run a plagiarism check if the text includes long paragraphs that closely match vendor copy.
Automating parts of this process
You can automate the source inventory and fact table checks with a lightweight pipeline:
- Use a retrieval-augmented generation (RAG) setup: index your allowed sources and pass top-k docs into the prompt.
- Automatically detect citations and verify link status via a script (HTTP status + basic regex to find the claimed text).
- If a citation fails the automated check, flag the draft for manual review.
Rubric I use to accept a review
My acceptance criteria are simple. I only publish when the draft meets all points:
- All factual claims have explicit citations and each citation points to a live source.
- No "Unverified" flags remain on critical specs or pricing.
- Opinion is clearly labeled and limited to designated sections.
- Language is clear, and technical terms are explained once.
- Length and structure fit the target audience (TL;DR summary + actionable recommendation).
Templates for asking the model to self-audit
One last trick I use: force the model to audit its own output before returning it.
Example audit prompt:
"Before returning the final review, run a self-audit: list three strongest claims and paste the exact sentence from sources that supports each. Then list two weakest claims and explain what would be needed to verify them."
I run that audit and if the model can’t produce clear source snippets for the strongest claims, the draft is not acceptable.
Use these prompts and checkpoints and you’ll go from elegantly written but risky AI drafts to reviews that are both readable and defensible. The pattern is consistent: force traceability, isolate opinion, and require verification. That’s how you make GPT a reliable member of your review workflow instead of a creative fiction generator.
