Shipping AI-Generated Code That Won't Hurt You (Much)
三句話摘要
如何透過嚴謹流程管理 AI 生成的程式碼，讓「vibe coding」產出真正安全可信的軟體。 AI vibe coding 的成敗取決於流程嚴謹度，而非 prompt 魔法：把 AI 當成需要密切監督的實習生，在 V-model 每個階段給它小而具體的任務，並持續積累可交付的正確性證據，才能讓 AI 生成的程式碼真正值得信任。 正確性不只是「能跑」，而是有完整的證據體系。 程式碼本身只是最終交付物不到 25% 的部分，真正的品質來自測試、模糊測試、形式驗證、靜態分析與審計報告所構成的「正確性證據（body of evidence）」。
重點整理
重點- 1
正確性不只是「能跑」，而是有完整的證據體系。 程式碼本身只是最終交付物不到 25% 的部分，真正的品質來自測試、模糊測試、形式驗證、靜態分析與審計報告所構成的「正確性證據（body of evidence）」。
- 2
流程設計應能容忍劣質輸入，包括 AI 產生的 slop。 V-model 的核心思想是：無論程式碼由人還是 AI 寫，只要流程足夠嚴格，最終產品品質就能被保證。AI 應在流程中扮演「輔助」角色，而非「取代」角色。
- 3
Vibe coding 本質上是專案管理技能，而非純技術技能。 大多數開發者失敗在於沒有把 AI 當作需要被 spec 清楚的外包工程師，而是把它當成魔法黑盒，跳過規格定義直接要求實作，導致方向一開始就偏。
- 4
給 AI 小而具體的任務，避免丟整個 context window。 實際有效的使用方式是把問題切小：讓 AI 針對單一函式進行查詢、生成某個元件的測試條件、或找出 codebase 某個面向的所有實例，而非「幫我把整個專案做好」。
實用技巧與重點
乾貨- 工具與平台：
- Claude Code（含 plan mode）：講者主要使用工具
- symbolic.dev：Runtime Verification 開發的 debugger，Q1 2026 整合 AI 功能
- 靜態分析工具（almanac scanner、Olympics tool 等，作為 agent validation）
- 具體數字：
- AI agent 獨立作業上限：約 10 分鐘（超過就開始出錯）
- 程式碼在整個開發週期中佔比：不到 25%
- 講者花在與 AI 討論計畫的時間：有時達 30 分鐘才按下執行
- V-model 七個階段（對應 Web3）：
- 白皮書（Specifications）
- 規格書（Requirements）
- 詳細設計（Detailed Design）
- 實作（Implementation）
- 測試與整合（Testing & Integration）
- 系統驗證（System Verification / Validation）
- 監控（Operation & Maintenance → Monitor）
- AI 輔助的具體 prompt 範例：
- 「我的白皮書是否有明顯設計缺陷？」
- 「這份規格是否有矛盾之處？各元件是否可實作與可測試？」
- 「需求清單中是否有互相矛盾的不變量？」
- 「這個設計能否滿足所有需求？」
- 「請為此元件生成反映協議需求的測試與模糊條件」
- 監督頻率參考：
- 資深工程師：每週一次
- 實習生：每天一次
- AI agent：每 10-30 分鐘一次
結論
結論“AI vibe coding 的成敗取決於流程嚴謹度，而非 prompt 魔法：把 AI 當成需要密切監督的實習生，在 V-model 每個階段給它小而具體的任務，並持續積累可交付的正確性證據，才能讓 AI 生成的程式碼真正值得信任。”
完整解析
詳細Runtime Verification 執行長 Everett Henbrand 在本場演講中直接挑戰了一個常見迷思：在 prompt 裡加上「secure」這個詞，並不能讓 AI 生成的程式碼變得安全。問題的核心在於，LLM 雖然能產出可執行的程式碼，但我們對其正確性毫無把握。他將「安全程式碼」重新定義為「擁有完整正確性證據的程式碼」，這些證據包括測試、CI 結果、靜態分析、形式驗證、模糊測試日誌，以及人工審計報告。缺乏這些證據，程式碼不論由人還是 AI 所寫，都不能稱為安全。
他援引 V-model（廣泛應用於航太、汽車等安全關鍵軟體領域）說明一個已被多個產業驗證的事實：從人類意圖出發，逐步細化為規格、需求、設計、實作，再以對稱的測試與驗證活動回頭確認每個層次，是目前唯一被證明有效的開發方法。講者的核心主張是：流程本身必須被設計為能夠「容忍劣質輸入」，包括 AI 生成的低品質程式碼（他稱之為 slop）。只要流程夠嚴謹，垃圾進去也能產出品質可接受的結果。因此，AI 應被加入流程中作為輔助，而非取代流程本身。
在實務操作層面，Henbrand 分享了他的具體做法：他用 Claude Code 的 plan mode 先與 AI 反覆討論計畫，有時花上 30 分鐘確認方向，然後才按下執行——但執行過程中不會離開，而是持續監看 AI 的每個操作，一旦發現它違反設計決策就立刻介入。他強調 AI 不適合處理需要長時間連續推理的大型任務，而是應該被分配小而具體的重複性工作，例如針對特定函式進行查詢、生成某元件的測試條件、或掃描 codebase 中某類模式。他明確建議：不要把整個 repository 丟進 context window，而是挑出相關片段，讓 AI 針對每個片段獨立思考 30 秒。
他也提出一個有趣的類比來校準預期：你會讓一位資深工程師自己埋頭工作多久才回來 review？大概一週。實習生呢？大概一天。AI agent？大概 10 分鐘。這個框架幫助開發者以正確的監督密度使用 AI，而非把它當作可以放任的自動化工具。最後他指出，vibe coding 失敗的根本原因通常不是技術問題，而是缺乏「管理一個需要清晰 spec 的協作者」的專案管理經驗。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
