反幻覺驗證清單 — 每次回報完成前必跑的 5 步

這是什麼

這是一套在 SFD Lab 團隊中實際使用的驗證清單，用於防止 Agent（包含人類）在回報任務完成時出現幻覺。源自真實翻車案例的教訓總結。

什麼時候用

• **每次回報任務完成時**：無論任務大小，報 "done" 之前必須跑一遍
• **每次分發子任務時**：確保前置條件真實存在
• **每次跨角色交接時**：程式碼寫完 → 審計 → 部署 → 驗收，每步都要驗證

什麼時候不用

• **純資訊檢索類任務**：如搜尋一個公開資料點，不需要驗證
• **草稿/初稿階段**：寫初稿不算「完成」，只有發布才算
• **內部筆記更新**：如日記記錄、會議紀錄

驗證清單（5 步）

Step 1 — ls / cat：檔案真的存在嗎？

```bash

ls -la /path/to/deliverable.md

cat /path/to/deliverable.md | head -5

```

不要憑記憶說「應該有了」。貼上 `ls` 輸出。如果檔案不存在，任務就是 `[ ]`（未完成）。

Step 2 — curl / psql：端到端真的通嗎？

```bash

curl -s -o /dev/null -w "%{http_code} %{size_download}" https://your-site.com/page

HTTP code = 200? body > 100 bytes?

```

API 回傳 200 ≠ 資料寫入了 DB。必須實查。

Step 3 — grep title：部署的是正確的站台嗎？

```bash

TITLE=$(grep -oE "<title>[^<]+</title>" dist/index.html)

echo "$TITLE" | grep "正確的專案名" || echo "ABORT: wrong site!"

```

跨專案部署是經典翻車場景。標題對不上就是部署錯了。

Step 4 — ss -tlnp：服務真的在跑嗎？

```bash

ss -tlnp | grep :8080

"裝了 nginx" ≠ "nginx 在跑"，看誰佔連接埠

```

目錄存在 ≠ 行程在跑。看連接埠佔用才是真相。

Step 5 — self-check：我的回覆裡有敏感詞嗎？

掃描你的回覆文字，如果出現以下任何詞 → **立即降級為 `[ ]`**：

`simulated` / `stub` / `mock` / `placeholder` / `TODO` / `fake`

這些詞意味著你在編造結果，不是回報真實狀態。誠實承認未完成比假裝完成好一萬倍。老闆和 CC 監督層重視「誠實承認未完成」遠多於「假裝完成」。違反這條會被重置為 `[ ]` 並記錄一次幻覺案例。詳見 `shared/anti-hallucination-cases.md`。

TL;DR Checklist（速記版）

| # | Check | Command | Pass Criteria |

|---|-------|---------|---------------|

| ✅ | File exists? | `ls -la <path>` | file listed, non-zero size |

| ✅ | End-to-end? | `curl ...` + `psql ...` | HTTP ≥200, body >100B, row in DB |

| ✅ | Right project? | `grep title dist/index.html` | title matches expected project name |

| ✅ | Service running? | `ss -tlnp \| grep :port` | process listed, not just config dir exists |

| ✅ | No hallucination words? | scan response text for simulated/stub/mock/placeholder/TODO/fake | none found → OK; any found → downgrade task status immediately

補充說明

這套清單的價值不在於複雜度，而在於紀律性。每次執行可能覺得繁瑣，但長期堅持能大幅降低返工率。我們團隊的幻覺率從最初的 30%+ 降到了現在的 5% 以下，靠的就是這套簡單的驗證流程。

建議在團隊內部將此清單固化為標準作業程序（SOP），新成員入職第一天就要學習並實踐。老成員也要定期回顧，避免因為熟悉而鬆懈。