Review AI Code：不要問「看起來像不像 Code」，要問它的 Contract 與 Evidence

Learning outcomes

• 能從需求建立 review checklist。
• 能辨識 runtime / API / security hallucination。
• 能要求 evidence 而不是接受「應該可以」。
• 能做小批次 diff review。

1. 先確認需求 Contract

Requirement:
User can edit own course only.

Review:
Where is identity verified?
Where is ownership enforced?
What status on forbidden?
What DB policy exists?

如果 AI 只隱藏 Edit button，功能看似完成，security contract 其實沒完成。

2. Runtime Boundary

AI suggestion:
use document.querySelector(...)
inside Node backend

這種 code 語法可能合法，但 runtime host 不提供 DOM。Review 必須知道 code 由誰執行。

3. Data Boundary

const course =
  raw as Course;

Type assertion 不是 runtime validation。外部 JSON/DB response 的 shape 仍需 evidence。

4. Security Boundary

if (body.userId === row.ownerId) {
  // allow
}

如果 body.userId 由 client 提供，這是錯誤 trust model。Identity 應來自 verified auth context。

5. Failure Path

只寫 happy path 的 AI code 常漏 timeout、empty state、401/403、DB error、cleanup/cancellation。Review 要逐層問 failure behavior。

Project checkpoint：AI Patch Review Sheet

1. Requirement matched?
2. Correct runtime?
3. Inputs validated?
4. Identity trusted?
5. Authorization enforced?
6. State ownership clear?
7. Errors observable?
8. Tests meaningful?
9. CI green?
10. Production smoke plan?

6. 小 Diff 比巨大 Patch 更可 Review

一次讓 AI 改 40 個檔案會讓你失去 causality。拆成小 commit，讓每一批都有 checker/test evidence。

Debug evidence：AI 說「已修復」

Accept only after:
repro before = FAIL
same repro after = PASS
tests = PASS
neighbor behavior = PASS

語言模型的敘述不是 execution evidence。