https://yennj12.js.org/yennj12_blog_V4/tags/anti-pattern/Recent content in Anti-Pattern on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part3-llm-security-zh/Mon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part3-llm-security-zh/一份有三個真實 MEDIUM 漏洞的報告， 比一份有三十個「潛在可能理論上存在風險」的報告有用十倍。 安全報告的公信力一旦失去，工程師會停止閱讀它。 一、為什麼 LLM Agent 特別容易產生廢話安全報告 LLM 有一個普遍的傾向：它會試圖看起來有幫助。 在安全稽核的場景，這個傾向帶來的問題是： 工程師期待的 LLM 行為： 如果沒找到漏洞 → 說「我沒找到漏洞，這個部分看起來安全」 LLM 實際的行為： 如果沒找到確定的漏洞 → 說「這裡可能存在潛在的風險...」 「雖然沒有明確的漏洞，但理論上...」 「建議加強這部分的防護，因為...」 這就是「廢話型安全報告」的根源——它讓 LLM 看起來有在做事，但對工程師毫無價值。 Cloudflare 的 security-audit-skill 明確列出了這個問題的解法，也列出了最常見的反模式。本篇把這些反模式系統化整理，並從 agent pipeline 設計的角度說明如何從根源消除。 二、反模式地圖 十個反模式的分類： ┌─────────────────────────────────────────────────────────────┐ │ 類型 A：「看起來嚴格，實際上沒用」的 finding │ │ 反模式 1：OWASP checklist 當 bug list │ │ 反模式 2：用模糊語言掩蓋不確定性 │ │ 反模式 3：Defense-in-depth 缺失膨脹成漏洞 │ │ 反模式 4：部署情境視而不見 │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 類型 B：「用量充數」的報告結構問題 │ │ 反模式 5：用 LOW 充厚度 │ │ 反模式 6：只說壞處，不說好處 │ │ 反模式 7：不提歷史漏洞基準 │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 類型 C：「懶惰的調查」導致的誤判 │ │ 反模式 8：太快放棄 │ │ 反模式 9：不驗證 parser/runtime 行為假設 │ │ 反模式 10：不做根本原因分析就重複報告 │ └─────────────────────────────────────────────────────────────┘ 三、類型 A：「看起來嚴格，實際上沒用」的 Finding 反模式 1：把 OWASP 偏離當成 Bug 症狀：