Verification Loop Prompt：让你的助手在你之前自行测试其工作

Source: Dev.to

如果你在使用助手进行编码或写作，可能已经见过以下模式：

1. 你提出一个具体的请求。
2. 你得到看起来正确的结果。
3. 接下来花 20 分钟发现隐藏的陷阱。

解决办法并不是“换个更好的模型”或“更具体”（虽然两者都有帮助）。关键是改变请求的形态。

我把它称为 Verification Loop Prompt（验证循环提示）：一种两阶段的提示，迫使助手在交付给你之前测试并审查自己的输出。

这并不是追求完美，而是要在早期、低成本且可重复的方式下捕获前 80 %的失败模式。

思路

大多数提示要求提供答案。

验证循环要求提供答案 + 证据。

你不仅仅是在请求“做 X”。你实际上在请求：

那最后一步很重要：一个好的验证循环不会假装确定——它会揭示不确定性。

基础提示（复制/粘贴）

将其作为默认模板，根据任务需要调整验证部分。

You are helping me with: 

Constraints:
- 
- 
- 

Deliverable:
- 

Verification loop (do this *after* you draft the deliverable):
1. List assumptions you made (bullet list).
2. Check the deliverable against each constraint (pass/fail + fix if fail).
3. Provide 5 edge cases / failure modes relevant to this task.
4. Propose a minimal test plan (steps I can actually run).
5. If anything is uncertain, flag it explicitly and ask up to 3 clarifying questions.

Only then output the final deliverable.

如果你没有其他操作，请请求边界情况和最小化测试计划。

示例 1：AI 辅助编码（带护栏的微小重构）

假设你正在重构一个解析用户输入的函数。

未进行验证

你经常会得到一个看起来很干净的重构，但它悄悄改变了行为。

进行验证

你强制助手证明它理解行为契约。

提示

You are helping me with: refactoring a TypeScript function that parses a date input.

Constraints:
- Must preserve current behavior for valid ISO strings (YYYY‑MM‑DD).
- Must reject ambiguous formats (e.g., 03/04/05) instead of guessing.
- Must keep the same public function signature.
- Must include unit tests for at least 6 cases.

Deliverable:
- Updated function + Jest test cases.

Verification loop:
1. List assumptions about existing behavior.
2. Compare old vs. new behavior for the 6 test cases (table).
3. Identify 5 tricky inputs that could break parsing.
4. Provide a minimal test plan: commands to run + expected output.

你得到的结果会截然不同：不仅是代码，还有一个 小规格说明。
关键在于第 2 步：强制进行明确的旧‑新行为对比，使助手停止“美化”代码，转而“保持原有行为”。

实用变体：“编译 + 运行”检查

• “这应该能够通过类型检查，因为 …”
• “此测试断言 X，对应约束 Y。”

示例 2：数据库更改（错误代价高）

模式更改是验证循环的理想场景，因为其失败模式众所周知：

• 数据丢失
• 长时间锁定
• 缺少回滚
• 性能回退

提示

You are helping me with: writing a PostgreSQL migration to split a full_name column into first_name and last_name.

Constraints:
- No data loss.
- Must be reversible (down migration required).
- Must be safe for large tables (avoid long table locks).
- Must include a backfill strategy.

Deliverable:
- up.sql + down.sql + short rollout notes.

Verification loop:
1. List assumptions about existing data (nulls, formatting, edge cases).
2. Identify the riskiest operation in the migration.
3. Provide a rollback plan and what data cannot be perfectly recovered.
4. Give a minimal test plan using a temp table with sample rows.

这迫使助理面对现实：并非所有转换都是完全可逆的。
如果它不能说明哪些是有损失的，说明它可能没有深思熟虑。

验证循环

1. 列出对现有数据的假设（空值、格式、边缘情况）。
2. 确认迁移中风险最高的操作。
3. 提供回滚计划以及哪些数据无法完美恢复。
4. 使用包含示例行的临时表给出最小化测试方案。

验证的“更改预算”（防止螺旋上升）

一种常见的失误模式是思考过度：助理先生成交付物，然后写出 40 条批评，随后再次重写所有内容。

使用小预算来解决：

• 限制为 5 个边缘案例。
• 限制为 一次 修订。
• 限制为 3 个澄清问题。

在提示中加入以下行：

Verification budget: one pass only. If you find issues, fix them once and move on.

验证应当是 安全带，而不是绕路。

适用于日常任务的简化版

对于较小的需求（邮件、文档、摘要），使用此快速循环：

Before you finalize:
- What did you assume?
- What’s the most likely mistake here?
- What would you check if you had 2 minutes?

它简短，但能可靠地捕捉到：

• 缺少上下文
• 语气不匹配
• 遗漏需求

为什么它有效（机械原理）

Assistants are great at producing plausible completions. The Verification Loop changes the objective:

That second step triggers a different mode: comparison, constraint checking, and counter‑example generation.

In human terms: you’re making the assistant review its own work like a teammate would.

# A small checklist to keep

When you’re not sure how to structure the verification loop, pick **3** from this menu:

- **Assumptions** – what did you infer?
- **Constraint check** – pass/fail
- **Edge cases** – counterexamples
- **Test plan** – minimal, runnable
- **Rollback plan** – for risky changes
- **Confidence + uncertainty** – what might be wrong?

If you build the habit, you’ll notice something subtle: you spend less time “prompting harder” and more time shipping.

That’s the whole point.