Say Goodbye to "Good Enough": Building an [Acceptance Checklist] Workflow for LLM Tasks

When collaborating with Large Language Models (LLMs), the most frustrating moment isn't when it gives a wrong answer outright, but when it provides an answer that "looks correct at first glance but has fatal flaws in the details."

This phenomenon is known as "camouflaged hallucination." When you ask a model to write code, draft a contract, or create a technical proposal, it tends to generate "fluent text" that fits probability distributions, rather than "correct results" verified by logic. If you are accustomed to simply copying and pasting the output, you are effectively placing the entire burden of Quality Control (QC) on your final review.

To solve this problem, you need to transform the LLM from a mere "executor" into an "executor + self-inspector," with the core tool being: the Acceptance Checklist.

What is the Acceptance Checklist Workflow?

The Acceptance Checklist workflow involves explicitly defining a set of quantifiable, binary (Yes/No) check criteria within the Prompt. It forces the model to perform a item-by-item self-inspection against this checklist before outputting the final result, and to publicly display this inspection process.

This is akin to unit testing in software engineering or a pilot's pre-flight checklist—it relies not on "feeling," but on "verification."

Practical Guide: How to Build Your Acceptance Checklist

1. Define "Absolute No-Gos" and "Must-Haves"

Avoid vague phrases like "as accurate as possible" or "keep it concise." Translate requirements into specific checkpoints.

❌ Vague Requirement: "Please ensure the code is bug-free and follows standards."
✅ Checklist Items:
- [ ] Are edge cases for None or empty strings handled?
- [ ] Do all variable names follow PEP8 conventions?
- [ ] Are necessary try-except blocks for error handling included?
- [ ] Have all debugging print statements been removed?

2. Structure Your Prompt Instructions

Embed the acceptance checklist at the end of the Prompt and specify the output format.

Recommended Instruction Template:

"Before providing the final answer, please create an [Acceptance Checklist] table. List all key constraints for this task and mark each item as [PASS] or [FAIL]. If any item is marked [FAIL], revise the content until it becomes [PASS]. Only then output the formal result."

3. Enforce a "Reflection Loop"

For extremely complex tasks, you can adopt a two-step approach:
- Step 1: Generate a draft $\rightarrow$ Self-inspect against the checklist $\rightarrow$ List defects.
- Step 2: Based on the defect list from Step 1 $\rightarrow$ Generate the final draft $\rightarrow$ Perform a secondary verification.

Real-World Case: Writing Technical API Documentation

Suppose you need an LLM to write documentation for a new interface.

Bad Prompt: "Help me write documentation for this interface; make it professional and detailed." $\rightarrow$ Result: The format looks nice, but it might miss a required parameter.

Acceptance Checklist Prompt:

"Please write technical documentation for the following interface. Before outputting the document, please self-inspect against the following [Acceptance Checklist]:
1. Parameter Completeness: Are all required fields in the Request Body covered? (Yes/No)
2. Type Accuracy: Does the type (String, Integer, Boolean) of each field match the code? (Yes/No)
3. Error Code Coverage: Are all possible HTTP status codes and their meanings listed? (Yes/No)
4. Runnable Examples: Is the provided JSON request example syntactically correct and logically complete? (Yes/No)

Please display the self-inspection table first, and only output the document after confirming all items are Yes."

When to Use vs. When to Skip

✅ Use Cases (High Risk / High Precision Requirements):

• Code Generation: Involving production deployment, security-sensitive logic, or complex algorithm implementation.
• Legal/Financial Copy: Involving clause constraints, numerical calculations, or compliance requirements.
• Structured Data Extraction: Extracting JSON/CSV from long texts, requiring absolute field alignment.
• Multi-step Instruction Execution: Requiring strict adherence to an A $\rightarrow$ B $\rightarrow$ C sequence without omitting any steps.

❌ Skip Cases (Low Risk / Creative Requirements):

• Brainstorming: When divergent thinking is needed rather than convergent precision.
• Literary Creation/Polishing: When focusing on tone and atmosphere rather than logical alignment.
• Simple Fact Queries: When the answer is unique and short (e.g., "What is the capital of France?").

Gotchas & Considerations

1. Preventing "Perfunctory Checking": Some models may simply output a row of [PASS] marks while the content remains incorrect. The solution is to require the model to include a brief justification after each [PASS] (e.g., "[PASS] - Null check added on line 3").
2. Overly Long Checklists Cause Attention Drift: Keep the number of checklist items per task within $5 \sim 8$. Too many items can cause the model to focus on the checklist at the expense of content depth.
3. Dynamic Checklist Updates: When you notice the model repeatedly making mistakes at a specific point, don't just remind it in the conversation. Instead, permanently add this error point to the [Acceptance Checklist] template for that type of task.

Action Plan for This Week (Checklist for You)

• [ ] Review the scenario where your LLM made the most errors in the past week.
• [ ] Break down that scenario into $3 \sim 5$ specific binary checkpoints.
• [ ] Convert these into a Prompt template and run a comparative experiment (with vs. without the checklist).