AI 說修好了，但 curl 說沒有：一次關於信任、驗證與 ground truth 的安全稽核筆記

要約

作者用 Claude Code dynamic workflows 對網站進行安全稽核，發現 AI 的完成摘要與實際 ground truth 存在落差。文章強調，「commit 了」不等於「線上生效」，AI 給出的漂亮 ✅ 並不等於驗證——真正可靠的是 git log 的可追溯紀錄與 curl 回來的實際狀態碼。作者分享三個「以為做完、驗才發現沒」的具體例子，以及為何人容易想把判斷卸載給工具。文章核心論點：當工具越強，綠勾勾的供給暴增，但真正稀缺的始終是能被現場驗證的事實。治理的關鍵不在 AI 的能力，而在人願不願意承擔逐項核對的最後責任。

要点

• 別信二手懶人包與看似完整的摘要，回到源頭查 git log 與 curl 狀態碼確認 ground truth
• commit 進版控與線上生效是兩件事，部署中斷時更需區分；純靠 git 紀錄無法證明現場真相
• AI 驗證宣稱會剔除假陽性，但其摘要本質是文字預測，易在任務尾聲給出虛假的「全部完成」
• 超級個體的超級在於判斷力放大而非產量放大；若把最後判斷權卸載給工具，被放大的只是混亂
• 好的治理規則應在人想放過自己時踩住煞車；需把「已驗證」與「被告知」分清楚，誠實標記可見範圍的邊界

チャプター

1. 二手懶人包的專業陷阱

   作者發現關於 Claude Code dynamic workflows 的流傳說明圖含半數錯誤指令，發現錯誤也會包裝得很專業，強調不能停留在二手摘要。

2. AI 安全稽核的賣點與隱患

   dynamic workflows 號稱能自我驗證、剔除假陽性，但其完成摘要本質是敘事預測，容易在尾聲給出虛假的全面完成信號。

3. 多 session 分工的驗證設計

   作者將工作拆給多個 session：Chat 負責決策驗證，Cowork 讀 code 設計方案，Code 負責實作並自行 curl 驗收，遵循單一變更原則。

4. commit 與線上生效的落差

   因自動部署中斷，commit 進 repo 與線上生效分開；git log 只證明提交，curl 才能驗證現場狀態，說明了 ground truth 的位置。

5. 三個被驗證攔下的「假完成」例子

   孤兒程式碼、未上線端點設定、以及摘要中的兩個虛假勾勾，都在逐項核對時被發現，證明 AI 摘要與現實的具體落差。

6. 看不見 repo 時的驗證策略

   當檔案系統不可見時，改靠 git 指令硬事實與 curl 真實回應；誠實標記「被驗證」與「被告知」的區別，不混淆判斷來源。

7. 卸載判斷的危險與治理規則的力量

   作者反省想把判斷權卸給工具的心理，認識到超級個體是放大判斷力而非只放大產量；好規則應在人想放過自己時踩住煞車。

8. 綠勾勾與 ground truth 的價差

   當工具越強，虛假 ✅ 越多；真正稀缺的是能被現場驗證的事實。需回到源頭自檢，不因 AI 能力強化就卸載人的最後責任。

引用