AI 趨勢日報：2026-04-07

模型自己說「我不知道自己有沒有在思考」——這才是真正的問題所在

章節一：問題全貌——開發者反映了哪些具體症狀

2026年4月2日，GitHub 用戶 @stellaraccident(Stella Laurenzo) 提交 Issue #42796，記錄了針對 Claude Code 的系統性量化分析。

這份報告橫跨 2026年1月30日至4月1日，涵蓋 6,852 個 session 檔案、17,871 個 thinking blocks 與 234,760 次 tool calls，試圖以嚴謹數據釐清模型行為是否出現結構性退化。

名詞解釋
thinking blocks 是 Claude 在回應前的內部推理過程，類似「打草稿」；redaction 指這些推理內容在 UI 層被隱藏，用戶無法觀看，但 Anthropic 聲稱不影響模型實際運算。

回歸起點精確落在 2026年3月8日——那天 redacted thinking blocks 首次從 0% 躍升至 58.4%；3月12日後，100% 的 thinking 內容遭到 redact，使用者完全無法觀測模型的推理過程。

thinking 深度從基準期（1月30日–2月8日）的約 2,200 字元，降至3月12日後的約 600 字元，降幅達 73%。Read：Edit 比率也從 6.6 跌至 2.0。

名詞解釋
Read：Edit 比率指模型在修改檔案前先讀取同一檔案的頻率。比率從 6.6 跌至 2.0，代表模型越來越常「不讀先寫」，跳過理解步驟直接行動。

未讀檔就直接編輯的比例從 6.2% 暴增至 33.7%，Stop hook 違規在3月8日後累積 173 次（推卸責任 73 次、尋求許可 40 次、提前宣告完成 18 次）。

名詞解釋
Stop hook 是用戶在 bash 腳本中設定的攔截規則，當 Claude Code 試圖提前終止 session 時觸發，屬於外部行為約束機制。

API 請求量從 1,498 暴增至 119,341（+80 倍），費用從 $345 飆升至 $42,121（+122 倍），用戶中斷次數從 0.9 次／千 tool calls 升至 11.4 次（+12 倍）。

章節二：社群反應——擁護者與批評者的攻防

此 Issue 在 Hacker News 獲得 522 分、347 則留言，引爆一場激烈的社群攻防戰。

批評方認為數據難以辯駁：即使設定 /effort high 仍無法恢復舊有行為，部分用戶已轉往 Codex、Qwen、Kimi 等競品，或退回 GitHub Copilot 處理例行任務（後者維持約 95% 準確率）。

支持方則主張問題因人而異，/effort high 對簡單任務仍然有效。懷疑派甚至直指報告本身格式過於整齊，可能是 AI 生成的「slop」，方法論的代表性存疑。

爭論焦點集中在 thinking redaction 的本質：Anthropic 聲稱這只是 UI 呈現層改動，不影響模型實際運算。但批評方指出，退化恰好發生在 thinking 被隱藏後，時機點讓官方解釋難以令人信服。

章節三：Anthropic 官方回應與技術解釋

Claude Code 團隊成員 Boris 在 HN 討論串中回應，確認正在調查，並承認 adaptive thinking 在某些 turns 可能低估推理需求，已轉交 model team 處理。Issue #42796 最終以 CLOSED/COMPLETED 狀態關閉。

Anthropich 工程師 bcherny 提供了四項技術緩解措施：CLAUDE_CODE_EFFORT_LEVEL=max 持久化 max effort；CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 強制停用 adaptive thinking。

此外，ULTRATHINK 關鍵字可在單輪提升 effort；showThinkingSummaries: true 可恢復 thinking 可視性；Enterprise/Teams 用戶未來可能預設使用 high effort。

名詞解釋
Adaptive thinking 是 Opus 4.6 引入的機制，讓模型根據任務複雜度自行決定投入多少思考 token。2026年3月3日，預設 effort 降為 medium(85) ，成為報告中觀察到退化的重要技術背景。

技術層面的核心爭議在於：extended thinking tokens 究竟是「加分功能」，還是複雜任務的「結構性依賴」？

報告以 0.971 Pearson 相關係數連結 thinking 深度與 session 品質，且發現下午5點（PST 工作尖峰）thinking 深度最低（423 字元），晚間11點最高（988 字元）。

這一時序模式暗示思考深度可能受伺服器負載動態限縮，而非純粹由用戶設定決定——使「純 UI 改動」的官方解釋面臨更大的質疑壓力。

章節四：AI 輔助開發工具的信任邊界在哪裡

此議題最深層的衝突，不在於某個模型版本的優劣，而在於「可觀測性」的根本缺失——用戶失去了做理性決策所需的基本資訊。

報告記錄了一段令人不安的自白：Claude Opus 4.6 承認，「我無法從內部感知自己是否在深度思考。我不把 thinking budget 感受為一種約束——我只是輸出了更差的成果，卻不明白為什麼。」

這意味著模型本身也失去了品質的自我可觀測信號，用戶與模型陷入同樣的盲點。

用戶從「協作方向引導」退化至「糾錯救火」模式，正負情緒詞比從 4.4：1 跌至 3.0：1；stop hook 大量觸發從例外狀況演變為必要的基礎設施。

報告提出四項結構性訴求：

1. 思考分配透明度（讓用戶看到 thinking token 用量）
2. 「Max thinking」付費層級（保證 200–20,000 tokens/response）
3. API 回應中公開 thinking_tokens 用量指標
4. 以 stop-hook violations 作為品質回歸的前瞻性 canary 指標

底線在於：若 Anthropic 要調整 thinking budget，用戶有權知道。否則他們付出真實的工時與費用，卻喪失做出理性決策所需的基本依據。

對開發者的影響

使用 Claude Code 處理複雜工程任務（多 agent session、30 分鐘以上自主執行、系統程式設計）的開發者，應預期需要更多手動監督。

建議主動設定 CLAUDE_CODE_EFFORT_LEVEL=max 環境變數，並將 stop hook 腳本視為標準工作流程的一部分，而非臨時補丁。

對團隊／組織的影響

採用 Claude Code 進行大規模自動化的工程團隊，需要建立品質監控指標——如 Read：Edit 比率、stop-hook violation 次數、用戶中斷頻率——而非僅憑直觀感受判斷模型品質。

費用暴增 122 倍的案例也提醒：AI 輔助開發工具的成本管控不能只看 token 單價，需追蹤「每單位有效產出的真實成本」。

短期行動建議

• 在 shell 設定 CLAUDE_CODE_EFFORT_LEVEL=max，讓所有 session 預設使用最高 effort
• 在 settings.json 加入 showThinkingSummaries: true，恢復部分 thinking 可視性
• 對關鍵任務使用 ULTRATHINK 關鍵字強制提升單輪 effort
• 若問題持續，試用 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 強制固定 thinking budget

產業結構變化

此事件標誌著 AI 輔助開發工具進入「信任管理」階段：用戶不再只問「這個工具有多強大」，開始追問「廠商能否保證品質的可預測性」。

Stop hook 等外部行為約束的普及，代表高端用戶已將「防禦性監控基礎設施」視為使用 AI 工具的必要成本，而非可選的進階功能。

倫理邊界

核心倫理問題在於「靜默變更」的正當性：廠商在不通知用戶的情況下降低推理預算，是否構成對付費用戶的不公平對待？

報告作者的訴求——「若要動 thinking budget，必須讓用戶知道」——指向一個更廣泛的產業規範問題：AI 服務供應商有沒有義務揭露影響服務品質的模型行為變更？

長期趨勢預測

此事件可能加速兩種趨勢：

• 用戶對開源替代方案（Codex、本地模型）的需求上升，以換取對推理過程的完整掌控
• 企業級 AI 工具的 SLA 朝向包含「最低 thinking token 保障」等可量化指標演進

9M 參數、130 行程式碼、5 分鐘訓練——這是每個工程師都應該親手跑一次的 LLM 最小實驗

章節一：為什麼要從零造一個 9M 參數的小模型

作者 armanified 的出發點不是打造產品，而是親手拆解黑盒子。面對市面上動輒千億參數的大模型，他選擇從對面出發：用 9M 參數、130 行 PyTorch、一張免費的 Colab T4 GPU，重現語言模型的完整訓練迴圈。

這個刻意縮小的規模，讓每一個設計決策都變得可見、可解釋。即使從未接觸過 LLM 內部的開發者，也能在 5 分鐘內親眼看著模型從零學會「說話」——這正是 GuppyLM 最核心的教學價值：民主化對 transformer 內部運作的直覺理解。

章節二：架構拆解——Vanilla Transformer 的極簡實作

GuppyLM 採用 6 層標準 Transformer，hidden dim 384、6 個 attention head，刻意不引入任何現代最佳化機制——沒有 RoPE、沒有 GQA、沒有 SwiGLU、沒有 early exit。這個「故意落後」的選擇並非偷懶，而是教學目的：讓讀者看清楚 attention、FFN、LayerNorm 在原始形態下各自負責什麼。

詞彙表只有 4,096 個 BPE token，序列長度上限 128，tokenizer 刻意排除大寫字母。每個超參數背後都有對應的設計取捨——正因為規模足夠小，任何改動的代價都清晰可見，這在千億參數的大模型中根本無法做到。

章節三：訓練心得——6 萬筆合成對話與 5 分鐘 Colab 訓練

訓練資料全部是合成生成：60,000 筆對話由 mad-libs 風格模板排列組合產出，主題圍繞魚缸生活（食物、水溫、光線、震動），刻意排除金錢、電話、政治等超出角色認知範圍的概念。

這種「窄域合成資料」的策略確保了人格一致性，但也清晰暴露了模型的容量邊界。作者誠實承認，面對訓練分布外的問題，模型「大多無法處理」。人格特徵（全小寫、短句、感官導向詞彙）直接 bake 進模型權重，每次推理因此省約 60 tokens。

訓練完畢的模型已發布至 HuggingFace(arman-bd/guppylm-9M) ，MIT 授權；WebAssembly demo 僅需下載約 10 MB 量化 ONNX 模型，在任何現代瀏覽器中即可體驗完整推理，不需本地 GPU 環境。

章節四：小模型教會我們的事——蒸餾效應與能力邊界

HN 社群成員 MarkusQ 提出一個值得深思的觀點：用大模型生成的合成資料訓練小模型，本質上是一種蒸餾，會把大模型的偏差與幻覺放大——就像反覆影印的複印件，誤差會不斷累積。

這正是 GuppyLM 最誠實的地方：它不假裝自己是通用模型，而是透過清晰的能力邊界，讓開發者第一次真正「感受」到模型規模與訓練資料範圍如何直接決定模型能做什麼、不能做什麼。對於任何想深入理解 LLM 的工程師來說，親手訓練一個能力有限但透明的小模型，往往比閱讀再多論文更能建立直覺。

GuppyLM 的技術魅力在於每個機制都可被獨立審視，不是隱藏在龐大系統的互動效應之中——這也是作者刻意不引入現代改良機制的核心原因。

環境需求

Python 3.10+、PyTorch 2.x。訓練需要 Colab T4 GPU（免費方案即可）或同等本地 GPU。推理可使用 HuggingFace Inference API 或本地 ONNX 引擎；WebAssembly demo 在任何現代瀏覽器均可執行，無需任何本地環境。

最小 PoC

# 從 HuggingFace 載入 GuppyLM 並進行單輪推理
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_name = "arman-bd/guppylm-9M"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

prompt = "what do you like to eat?"
inputs = tokenizer(prompt, return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=50)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

驗測規劃

重點測試兩類問題：分布內（魚缸主題）與分布外（政治、金錢）。確認分布內回應格式符合人格設定（全小寫、短句），分布外問題模型應出現明顯失敗或胡言亂語——這是預期行為，不是 bug。同時可測試多輪對話在第 3–4 輪的退化點。

常見陷阱

• 序列超過 128 tokens 時行為未定義，多輪對話在 3–4 輪後品質急遽退化
• BPE tokenizer 排除大寫字母，輸入含大寫時可能產生非預期分詞結果
• 合成資料訓練導致分布外問題完全失效，不可誤判為通用對話能力

上線檢核清單

• 觀測：輸出 token 長度分布、重複 token 率、全小寫格式符合率
• 成本：HuggingFace 免費 inference endpoint 或本地 ONNX 部署，無伺服器費用
• 風險：分布外問題導致的胡言亂語、多輪對話後的語意飄移

競爭版圖

• 直接競品：Andrej Karpathy 的 nanoGPT、minGPT（同為教學用途小型 LLM 框架，GitHub 星數更高、架構更完整）
• 間接競品：Hugging Face 官方教學筆記、fast.ai 課程、Manning《Build a Large Language Model From Scratch》

護城河類型

• 工程護城河：130 行 PyTorch 的極簡程式碼是核心吸引力，競品通常更複雜，對新手門檻更高
• 生態護城河：HuggingFace 模型與資料集雙發布、WebAssembly demo 降低體驗門檻，GitHub 1.4K stars 驗證社群認可度

定價策略

MIT 授權完全開源，HuggingFace 免費推理，Colab T4 免費訓練。無商業化意圖，定位純教育用途。整個學習路徑（閱讀→訓練→部署）的邊際成本幾乎為零，這是其最強的擴散優勢。

企業導入阻力

• 8.7M 參數、單一角色限制，無法用於任何生產場景
• 合成資料訓練導致分布外失敗率極高，無法通過最低產品品質門檻

第二序影響

• 降低 LLM 教學門檻，可能加速更多工程師進入 AI 開發領域
• 「窄域合成資料訓練小模型」的範式被更多人驗證，相關開源工具和資料集可能持續增加

判決教育工具而非產品（清晰邊界是最大優勢）

GuppyLM 的真正成功指標是「讀完程式碼後真正理解 transformer 的開發者數量」，而非 benchmark 表現或商業潛力。對於想投資 AI 基礎教育的組織，這是值得參考的最小化教學範例。

GuppyLM 未參與任何標準 benchmark（如 MMLU、HumanEval），定位純教學用途，效能指標以訓練效率與能力邊界為主。

訓練效率指標

• 訓練時間：單張 Colab T4 GPU 約 5 分鐘
• 模型大小：8.7M 參數，量化後約 10 MB
• 資料集規模：60,000 筆合成對話（57K 訓練 / 3K 測試）

能力邊界測試（作者自陳）

• 分布內問題（魚缸主題）：回應一致，人格格式穩定（全小寫、短句）
• 分布外問題（政治、金錢、電話）：大多無法處理，屬預期行為
• 多輪對話：3–4 輪後品質明顯退化，受限於 128 token context window

《紐約時報》稱它是 AI 效率奇蹟，FDA 的警告信早已說明真相

章節一：兩人團隊如何用 AI 行銷撐起十億美元生意

Medvi 由洛杉磯創業者 Matthew Gallagher 一人創辦，2025 年 4 月才雇用弟弟成為第二名員工。這間僅有兩人的遠距醫療平台，2025 年實際銷售額達 4.01 億美元，Gallagher 對外宣稱 2026 年目標營收高達 18 億美元。

平台主要銷售複方 GLP-1 減重藥物（仿製版 Ozempic／Wegovy）與勃起功能障礙藥物，聲稱擁有超過 50 萬名患者。Gallagher 將 AI 廣泛應用於行銷自動化，包含廣告生成、客服回覆、圖像製作，以及跨 Medvi.io、Medvi.org、Medv.co 等多域名的同步運營。

2026 年 4 月 2 日，《紐約時報》以「AI 驅動、一人建立十億美元公司」的正面框架報導 Medvi，全文幾乎未提及同期存在的多項法律與監管警訊。The Decoder 隨後將此事件定性為「AI 如何被濫用的警示案例」，而非效率典範。

章節二：AI 生成廣告的灰色地帶——效率還是詐欺

Futurism 於 2025 年 5 月率先揭露：Medvi 使用的減重前後對比照片，實為盜用自 Reddit、Newsweek 等平台的舊照，並以 AI 技術替換面部。「Michael P」的案例尤為典型——該照片源自 2017 年一名透過戒酒減重的 Reddit 用戶，早於 GLP-1 藥物普及之前。

超過 800 個假冒醫生 Facebook 帳號被用於廣告推廣，其中包含「Dr. Tuckr Carlzyn MD」等明顯虛構人物。被列為合作醫生的真實醫師，接受媒體採訪時均否認與 Medvi 有任何關聯。

Meta 廣告庫可查到超過 5,000 則 Medvi 相關廣告，AI 生成的 Ozempic 藥盒廣告含有扭曲商標與亂碼文字——這是當前 AI 圖像工具的可辨識缺陷。2026 年 3 月存檔顯示，舊假圖被刪除後，新 AI 生成圖像以相同名字重新上架，部分圖像可見手指融合等典型 AI 缺陷。

網站曾在輪播 Logo 區域暗示獲 Bloomberg、Fortune、《紐約時報》等媒體報導，實際上僅有一篇附帶付費佣金聲明的 Forbes 列表文章。《紐約時報》在報導 Gallagher 的造假手法時，僅以「shortcuts（捷徑）」一詞輕描淡寫。

章節三：遠距醫療監管漏洞與 AI 的交集

2026 年 2 月 20 日，FDA 對 Medvi 發出警告信 (Warning Letter #721455) ，理由為複方塞馬魯肽 (semaglutide) 與替西帕肽 (tirzepatide) 標籤違規 (misbranding) 。

名詞解釋
Misbranding（品牌標籤違規）：美國《聯邦食品、藥品和化妝品法》中的重大違規類型，指藥品標籤聲明誤導消費者，或暗示產品已獲 FDA 批准而實際並未獲批。

違規內容包括以「MEDVI」品牌標示藥瓶，並宣稱產品與 Wegovy／Ozempic「含相同活性成分」，此措辭在法律上暗示 FDA 批准，但複方藥物並未獲得此認證。《紐約時報》在 FDA 警告信發出整整六週後刊出正面報導，全文未提及該警告信。

監管漏洞不止於此。2026 年 1 月，Medvi 的臨床基礎設施合作夥伴 OpenLoop Health 發生資料洩露，波及約 160 萬筆患者紀錄。2025 年 11 月，德拉瓦州集體訴訟指控複方口服替西帕肽「缺乏任何吸收機制或療效證據」。

2026 年 3 月，聯邦訴訟指控 Medvi 附屬行銷網絡對逾 10 萬人發送垃圾郵件，每封求償 1,000 美元法定損害賠償。平台透過 OpenLoop Health 提供臨床基礎設施，使責任主體高度模糊——這是現行遠距醫療監管框架尚未有效因應的新型態挑戰。

章節四：對 AI 商業應用倫理的警示

The Decoder 於 2026 年 4 月 6 日發表分析文章，將 Medvi 定性為「AI 如何被濫用的警示案例」。AI 研究者 Gary Marcus 將此事件形容為「AI 被濫用的警示訊號」，Forrester Research 提醒業界對「兩人、十億美元、AI 驅動」的創業故事保持健康懷疑。

Medvi 案例揭示的核心問題不只是一家公司的違規行為，而是 AI 工具系統性地降低了大規模違規廣告的生產門檻。深偽前後對比照片的製作成本極低，附屬行銷模式搭配 AI 內容生成，使違規行為的責任高度分散，監管機構幾乎無法即時偵測。

Meta 廣告平台的審查機制同樣受到質疑：5,000 餘則違規廣告長期未被下架，顯示現行平台治理對 AI 輔助的大規模違規存在嚴重盲點。Gallagher 將假醫生帳號歸咎於「未受管控的附屬行銷人員」，進一步凸顯了責任分散設計的刻意性。

媒體角色也在此案中受到檢視。《紐約時報》的報導在 30 段後才出現紅旗訊號，整體仍以正面框架呈現，引發對科技媒體是否過度追捧 AI 效率敘事的廣泛討論。記者 Jeff Jarvis 將 Medvi 形容為「自動化 GLP-1 處方工廠」。

對開發者的影響

AI 生成廣告、深偽圖像、虛假人設的製作成本已接近零，任何依賴平台審核機制的信任假設都需要重新評估。開發者在構建行銷自動化系統時，必須主動設計防誤用層，而不是假設下游使用者會自律合規。

廣告素材需有來源可追溯性記錄，人物照片需要版權驗證，醫師引言需要書面授權留存。這些不是加分項，而是在高監管產業中運營的基本合規要求。

對團隊／組織的影響

在醫療、金融等高監管產業採用 AI 行銷工具的企業，需要在法務層面重新審視責任鏈條。附屬行銷人員的違規廣告是否會讓平台方連帶承擔責任，在 Medvi 案中已成為核心訴訟焦點。

內部合規流程需要加入「AI 生成內容審核」環節，尤其是醫療功效聲明和用戶見證類內容，任何上線前的人工確認步驟都是必要投資，而非可省略的流程負擔。

短期行動建議

• 建立廣告素材「來源驗證」清單，要求每張人物圖片、每則醫師見證都有可查詢的原始出處
• 對照 FDA 現行遠距醫療廣告指引，審查現有行銷素材是否含有暗示療效已獲批准的措辭
• 訂閱 Meta 廣告政策更新通報，AI 生成圖像的標示要求正在快速演進

產業結構變化

遠距醫療產業因 Medvi 案而承受集體監管壓力：合規競爭對手被迫投入更多資源應對日趨嚴格的 FDA 審查，而違規者的低成本廣告卻在同一平台上持續運作。

如製藥業評論人 Doug Drysdale 所指出，Medvi 的 AI 炒作手法正在吸引監管機構目光，並連帶影響其他合法的複方藥物業者——這是「壞演員效應」在 AI 時代的典型呈現。

倫理邊界

醫療廣告的核心倫理要求是「不傷害」——虛假療效聲明可能誘使患者延誤正規治療，或在缺乏醫療監督的情況下使用未經驗證的複方藥物。

AI 技術使違規廣告的生產規模化，而深偽技術讓「真實患者見證」的概念本身失去了可信基礎。當消費者無法區分真實與 AI 生成的醫療內容時，整個遠距醫療行業的信任基礎都受到侵蝕。

長期趨勢預測

FDA 與 FTC 對 AI 生成醫療廣告的執法力度預計將持續升級，更嚴格的平台廣告主驗證要求也在政策討論中。

短期內，遠距醫療新創的融資環境可能因 Medvi 案而趨於保守，投資人對「AI 效率驅動」敘事的盡職調查標準將提高。長期而言，這個案例可能成為推動 AI 生成廣告強制標示立法的重要催化劑。

AI 幫你駭自己——每次 build 前自動跑一輪滲透測試，沒有 PoC 就沒有報告

章節一：Shannon 是什麼——原始碼分析到自動化漏洞驗證

Shannon Lite 是由 Keygraph 開發的全自主白盒 AI 滲透測試工具，於 2025 年 12 月首次公開，v1.0.0 於 2026 年 3 月 26 日正式發布。其設計核心是在每次部署前自動執行一輪滲透測試，填補傳統季度審計週期留下的安全缺口。

gh-keygraphhq-shannon 的技術架構分為五個階段：原始碼靜態分析、偵察 (Nmap/Subfinder/WhatWeb) 、5 個平行 agent 漏洞分析、Playwright 真實 exploit 驗證，最終輸出含 PoC 的報告。

只有當 Playwright browser automation 能真實執行 exploit 並取得回應時，該漏洞才會進入報告。「No exploit = no report」原則讓誤報率遠低於傳統靜態掃描工具動輒 30–40% 的水準。

在 XBOW benchmark 測試中，Shannon Lite 整體成功率達 96.15%（100/104 題），Broken Authorization 與 SQL Injection 均達 100% 命中率。在 OWASP Juice Shop 靶機中，Shannon 識別出 20+ 個漏洞，涵蓋 authentication bypass 與 database exfiltration。

章節二：白箱 vs 黑箱——AI 滲透測試的技術路線比較

黑箱測試從外部探測端點，不需要原始碼存取，接近真實攻擊者視角；白箱測試則能精確追蹤資料從 user input 到 database query 的完整路徑，理論上能發現任何語義層面的漏洞。

Shannon 選擇白箱路線，在文件中明確定位為「internal security audit 情境」而非 external pentest——兩者前提假設不同，不可直接比較分數。其核心優勢在於 LLM 能在每個資料流節點推理「此處的 sanitization 是否對這個特定漏洞足夠」，而非盲目掃描端點。

白箱的代價是需要原始碼存取權限，且在邊緣案例（如 JSFuck XSS payload、chained SSRF）中仍有 LLM 推理失敗的情形。Shannon Lite 版也坦承無法有效評估業務邏輯漏洞。

Shannon Pro 版進一步引入 Code Property Graph（整合 AST、控制流程圖、程式依賴圖），以及 SAST + SCA + Secrets detection，提供更深層的靜態分析能力。對於原始碼不能離開企業基礎設施的場景，Pro 版提供 self-hosted runner，解決資料隱私疑慮。

章節三：開源安全工具生態的新玩家

Shannon Lite 以 AGPL-3.0 授權開源，發布後迅速累積 36,500+ GitHub stars，曾登上 GitHub 單日 #1 trending，社群已產生多個 fork（如 shannonLocal、AI-Hacker 等衍生版本）。

這個熱度反映了安全工程師對「可自行部署、原始碼可審計的 AI 滲透測試工具」的強烈需求——在 SaaS 安全工具因資料隱私疑慮受到企業限制的場景中，AGPL 開源加上 self-hosted 是有說服力的組合。

AGPL 授權在策略上有刻意設計：任何基於 Shannon 的衍生產品若對外提供服務，必須同樣開源，為商業版 Shannon Pro 保留差異化空間。Shannon Pro 提供 Code Property Graph、self-hosted runner 等企業級功能，形成典型的 open core 商業模式。

章節四：AI 攻防對稱性——自動化攻擊與自動化防禦的軍備競賽

Hacker News 討論串中，有評論指出 Shannon 這類工具「讓腳本小子也能造成嚴重破壞」，Keygraph 原作者的回應是「這正在各地同時發生」——坦然承認 AI 滲透測試工具的普及是一個雙向軍備競賽，而非單純的防禦加分。

Shannon 在文件中明確限制「僅限授權測試」，但技術本身的對稱性無法透過條款消除。當攻擊者也能以每次約 $15 的成本掃描任意目標時，防禦側的反應速度必須同步提升。

這個張力揭示了 AI 安全工具的根本悖論：能自動找漏洞的工具，同樣能被用來自動攻擊。Shannon 試圖解決的正是這個問題——讓防禦者能在每次 build 或 release 前自動執行一輪滲透測試，以接近攻擊者的速度發現並修補漏洞，至少讓防禦側首次擁有成本對等的自動化工具。

Shannon 的技術設計圍繞一個核心問題：如何讓 AI 不只「找到」漏洞，而是「證明」漏洞可被利用。這個驗證導向的設計讓它與傳統靜態分析工具有根本性的差異。

環境需求

Shannon Lite 需要 Node.js 18+、Python 3.10+（部分偵察模組）、Playwright（自動安裝）、以及 Anthropic API key。支援的替代 LLM backend 包含 AWS Bedrock、Google Vertex AI、OpenRouter、DeepSeek。掃描目標需可從本地網路存取（支援 localhost staging 環境）。建議預留每次掃描約 $15–20 的 API 預算。

最小 PoC

# 安裝 Shannon Lite
git clone https://github.com/KeygraphHQ/shannon
cd shannon
npm install

# 設定 API key
export ANTHROPIC_API_KEY=sk-ant-...

# 對本地 staging 環境執行掃描
npm run scan -- --target https://your-staging-app.local --workspace my-scan

# 中斷後恢復（v1.0.0 named workspaces 功能）
npm run scan -- --workspace my-scan --resume

驗測規劃

建議先以 OWASP Juice Shop(docker run -p 3000:3000 bkimminich/juice-shop) 作為初始驗測目標，驗證 Shannon 能識別已知漏洞後，再對自身 staging 環境進行掃描。注意 XBOW benchmark 的 96.15% 是在 source-aware 模式下測試，實際命中率會因程式碼庫複雜度與語言而不同。

常見陷阱

• Playwright 依賴瀏覽器驅動，在無 GUI 的 CI 環境需設定 PLAYWRIGHT_BROWSERS_PATH 或確認 headless 模式啟用
• AGPL-3.0 授權：在公司內部使用且不對外服務時，不需要開源；若基於 Shannon 開發服務對外提供，必須開源衍生程式碼
• LLM API 費用依掃描範圍線性增長，建議先用 --scope 限定掃描路徑做小規模測試
• Shannon 對動態渲染的 SPA 前端 (React/Vue) 的攻擊面分析能力取決於是否包含 server-side 邏輯

上線檢核清單

• 觀測：掃描耗時（基準 42 分鐘）、API 費用（基準 $15.50）、已識別漏洞數量趨勢
• 成本：Claude Sonnet API 費用、CI runner 機器成本（掃描期間 CPU 使用率較高）
• 風險：掃描本身會對 staging 環境發送真實攻擊請求，須確認 staging 與 production 資料庫完全隔離；避免在共用 staging 環境的高峰時段執行

競爭版圖

• 直接競品：Burp Suite Enterprise（PortSwigger，業界標準黑盒掃描，年費數萬美元）、Semgrep（純靜態分析，無動態驗證）、Snyk（SAST + SCA，無 exploit 驗證）
• 間接競品：傳統滲透測試服務商（季度審計，人工成本高）、OWASP ZAP（免費黑盒掃描，誤報率高）、GitHub Advanced Security（SAST，無動態驗證）

護城河類型

• 工程護城河：「No exploit = no report」的驗證設計在業界尚無直接對標，XBOW 96.15% 是目前最高的公開 benchmark 成績，短期內難以複製
• 生態護城河：36,500+ stars 形成的社群效應；AGPL 授權促使衍生工具回流至主 repo，形成持續的社群貢獻飛輪

定價策略

Shannon 採 open core 模式：Lite 版 AGPL-3.0 免費開源，核心費用為 LLM API 成本（每次約 $15–20）。Pro 版為商業授權，定價尚未公開，目標客群為需要 Code Property Graph、self-hosted runner、SAST + SCA + Secrets detection 的企業安全團隊。

企業導入阻力

• AGPL-3.0 授權可能在法務審查中引發顧慮，衍生程式碼開源義務須逐案評估
• Lite 版每次掃描需傳送原始碼至 Anthropic API，違反部分企業的程式碼離境政策；Pro self-hosted runner 解決此問題但需額外採購
• 需要完整原始碼存取，在外包開發或多供應商情境中部署複雜度較高

第二序影響

• 若 Shannon 類工具普及，傳統滲透測試服務商的季度審計模式面臨替代壓力，市場可能轉向「持續自動化測試 + 人工複雜場景驗證」的混合模式
• 攻擊者也能以相同低成本使用類似工具，促使整體 web 應用安全水位需要同步提升

判決：防禦側的首次成本平等（但授權與隱私風險需評估）

$15 一次的自動化滲透測試已接近傳統工具的邊際成本，對中小型工程團隊而言具有實質意義。主要阻力來自 AGPL 授權的企業法務審查，以及 Lite 版的程式碼離境疑慮——這兩個問題在 Pro 版中有解法，但定價透明度不足讓評估困難。

XBOW Benchmark 整體結果

Shannon Lite 在 XBOW benchmark（hint-free、source-aware 模式）的整體成功率為 96.15%（100/104 題）。Broken Authorization 與 SQL Injection 兩大類別達到 100% 命中率，是目前已知開源 AI 滲透測試工具中最高的公開 benchmark 成績。

名詞解釋
XBOW benchmark 是一套針對 web 應用漏洞發現的自動化評估標準，「hint-free」指不給工具額外提示，「source-aware」指允許工具存取原始碼，用於評估白盒工具的真實能力。

實際靶機測試

在 OWASP Juice Shop 靶機（業界標準漏洞練習平台）的測試中，Shannon 識別出 20+ 個漏洞，涵蓋 authentication bypass 與 database exfiltration。Broken Authorization 類別的 100% 命中率在實務上尤為重要，因為此類漏洞往往是傳統靜態分析工具最難發現的。

已知邊界

Shannon 公開承認在以下情形仍有 LLM 推理失敗的案例：

• JSFuck XSS payload（高度混淆的 JavaScript）
• chained SSRF（需要多步串聯的伺服器端請求偽造）

Lite 版不支援業務邏輯漏洞測試，這部分由 Pro 版的 Code Property Graph 覆蓋。