免費直播｜別再問 AI「能不能做」本期談的「可審查產物」，我會在 Hahow 免費直播裡現場示範：如何把模糊的一句話，轉成能交付的文件。 時間：2026/9/9（三）20:00–21:00｜形式：Hahow 線上直播，免費參加 |
主題一｜上線前：全綠的稽核報告，反而可疑——可審查產物系列・站 4（完結）
嗨，我是凱文大叔。
最後一站：上線前。程式寫完了、測試綠了，要見人了。這站也是系列完結篇——結尾會把四站收成一張總表。
這句話的問題是：沒有基準
❌「幫我看看有沒有資安漏洞」
沒有基準，AI 只會回你泛泛而談的三五點：「注意 SQL injection、記得驗證輸入、密碼要加密」。聽起來都對，但你不知道它漏了什麼。
給它一份清單，它就變成逐項稽核，而且有覆蓋率可以談。這裡分兩層：你寫的程式碼，和你拉進來的東西。
第一層：我寫的程式碼——對照 OWASP 與 CWE
提示詞全文（可直接複製）
對照 OWASP Top 10:2025 與 CWE Top 25（2025 版）逐項檢查這份程式碼，
輸出表格：分類代號、是否命中、程式位置、風險等級、修補建議。
沒命中的項目也要列出，並說明為什麼不適用。
關鍵在最後一句：「沒命中的項目也要列出，並說明為什麼不適用。」這一句是逼它交出覆蓋率。只列命中項目的報告，你根本無法判斷它是查得仔細，還是只挑了幾個好講的講。
而且請注意清單版本。OWASP Top 10 在 2025 年 11 月發表新版、2026 年 1 月定版，新增了兩個分類：A03 軟體供應鏈失效、A10 例外狀況處理不當，SSRF 則被併進 A01。如果你拿 2021 年的舊清單去問，你會整整漏掉供應鏈跟例外處理這兩塊。
實際跑出來的稽核摘要：
命中 4 項 OWASP、1 項 CWE——不是全綠。這很重要：全綠的稽核報告通常代表查得不夠仔細。
其中 A10（例外狀況處理不當）這項不是「可能有風險」，是實際驗證出來的：我故意把資料檔弄壞，然後打 API——它回了 500，而回應裡帶著我的檔案系統路徑。
第二層：我用的第三方元件——已知 CVE
自己寫的程式碼是一回事，你拉進來的東西是另一回事。
提示詞全文（可直接複製）
列出本專案所有相依套件與版本，逐一查有無已知 CVE，
標出 CVSS 分數、影響說明與建議升級版本，依風險排序。
我的示範專案 npm audit 是乾淨的，0 個已知漏洞。但重點在下一行：5 個直接相依，帶進了 106 個套件。
0 漏洞的意思是「今天乾淨」。沒有任何機制會在明天有新漏洞的時候通知你——這正好對應 2025 新版特地加進來的 A03 軟體供應鏈失效。定期重跑這一層，或在 CI 裡掛上自動掃描，才算把「今天」變成「每天」。
修掉之後：資訊不是消失，是換了去處
稽核出來的問題修掉之後，對比長這樣：
修補後，用戶端只會收到「伺服器內部錯誤」，而完整的錯誤——包含路徑跟 stack——進了日誌。資訊不是消失，是換了去處。
順帶一提，這也是為什麼「開啟日誌」必須先做：把錯誤從回應裡拿掉卻不記錄，等於把問題變成靜默失敗——你只是把洩漏改成了失明。
一句誠實話
AI 稽核取代不了滲透測試。它沒有實際嘗試組合攻擊路徑、沒有測競爭條件、沒有驗證商業邏輯能不能被繞過。
它的價值是便宜的第一道網——在你花錢請人測之前，先把明顯的東西掃掉。
稽核全綠不等於安全。只等於「清單上的項目都看過了」。
系列完結：四句型總表
四站走完，收成一張表：
| 階段 | ❌ 別這樣問 | ✅ 這樣問 | 你會拿到的產物 |
|---|---|---|---|
| 想法期 | 這個能不能做？ | 做一份可行性評估報告，含難易度分級、風險、驗證順序 | 可進會議、可被打槍的評估文件 |
| 設計期 | 幫我寫一個 X | 先選型分析 → 再開發計畫 → 才實作 | 選型比較表＋里程碑與驗收標準 |
| 開發驗收 | 幫我測試有沒有問題 | TDD 紅綠重構 → Playwright 腳本 → 截圖生 SOP | 回歸測試資產＋操作手冊 |
| 上線前 | 幫我看有沒有漏洞 | 對照 OWASP／CWE 逐項稽核，含未命中原因 | 有覆蓋率的稽核表 |
這四招的共通點只有一個：你要求了一份別人可以審查的東西。
可行性評估報告可以被打槍、開發計畫可以被改、測試會紅、稽核表有覆蓋率。這四樣東西都可以被審查——而「可以做」不行。
把「一句話回答」換成「可審查產物」。就這一句。
系列完結，感謝收看。下次開口問 AI 之前，先想一下：我要的是一句話，還是一份文件？
主題二｜事件收得下來：重複執行的代價
上期用 Outbox 把事件變成一筆資料，確保它不會在交易失敗時亂送、也不會在當機時消失。
但 Outbox 帶來了下一個問題。排程的流程是這樣的：
- 撈出還沒送出的事件
- 送出去
- 標記「已送出」
如果在第 2 步和第 3 步之間當機——事件已經送出去了，但資料庫還記著「這筆還沒送」。重開之後，排程會再送一次。
這不是 Outbox 特有的毛病。訊息佇列、webhook、任何跨程序的傳遞都一樣，因為要真正做到「剛好一次」，送出方和接收方得在同一個交易裡，而它們在不同的機器上。
所以整個業界的共識是：先保證「至少一次」，剩下的交給接收端自己處理重複。
上期講 Webhook 的時候我引過一句話：那四道關卡，本質是在 HTTP 上手工補回訊息佇列原生提供的保證。這期要補的就是其中最關鍵的一道——去重。
一般系統重跑沒事，Agent 重跑要命
在一般的 CRUD 系統裡，重複處理通常是無害的。重新計算一次訂單總額，答案還是同一個；重新更新一次狀態，結果也一樣。
Agent 不是。我實際跑了一次「沒有任何保護、同一個事件送兩次」：
I1 沒有保護時，同一事件送兩次就呼叫兩次 LLM
LLM 呼叫次數=2
兩次呼叫代表：
- 付兩次錢——按 token 計費，跑幾次算幾次
- 拿到兩份不一樣的摘要——LLM 不保證同樣輸入給同樣輸出
- 後寫入的覆蓋先寫入的——而哪一份會贏，取決於誰先跑完，完全隨機
第三點最麻煩：這不是「多花一點錢」的效率問題，而是資料變得不可預測。同一筆客戶資料，重整頁面前後看到不同的摘要，而你查不出為什麼。