GitHub 讓 AI 幫程式準備闖關，模糊測試到底在忙什麼

先想像一個星期六下午：桌上有飲料，筆電已經打開，某個小組終於把程式湊成能動的樣子。正常輸入丟進去，成功。再試一次，還是成功。游標已經快移到「收工」兩個字上面，旁邊突然飄來一句：「那如果有人什麼都不填呢？」

好喔，飲料可以再喝慢一點了。

這個假想場景還能繼續加戲：有人輸入一大串重複文字，有人貼進奇怪符號，有人把完全不相關的內容當成檔案交出去。問題跟著冒出來：程式會好好拒絕、正常處理，還是出現出乎預期的反應？平常乖乖照規則走的測試，到這裡才開始有點闖關感。

而且，想讓程式接受考驗，得先找到考場入口。不能把一整包奇怪資料放在旁邊，就期待程式自己過來拆禮物。這個入口怎麼接、流程怎麼走，正是這次工具很值得拆開看的地方。

假設團隊接手一個 C/C++ 專案，想知道它遇到奇怪輸入會不會出問題。開始測試前，卻先得回答一串問題：程式怎麼建置？資料從哪裡進來？要寫什麼程式，才能把測試資料送進去？光是走到「可以開始測」這一步，就有不少工作要處理。

GitHub Security Lab 介紹的 Fuzzing Taskflow，瞄準的正是這段流程。GitHub 在 2026 年 9 月 24 日發布的文章中表示，使用者提供 GitHub 儲存庫連結後，系統可自動辨識入口點、分析建置系統、撰寫測試程式，再執行 AFL++，最後產生漏洞報告。[S1]

換成遊樂園試營運，就突然很好懂

先把一個程式想成準備開放的遊樂園。正式遊客可能會乖乖排隊，也可能在路口繞來繞去，走出工作人員沒想到的路線。試營運的任務，就是在正式開放前，多安排一些情境，看看哪裡的路線、指示與設施需要調整。

這裡只是理解流程的比喻。入口點像遊客可以進去的門，測試程式像把遊客送到指定設施的接駁車。車子如果只在停車場兜圈，園區裡那座很想檢查的設施就一直等不到人。螢幕上的動靜可以很熱鬧，重點仍然是：有沒有真的到達目的地？

沿著這個畫面看，準備測試就不只是按下「出發」。還得確認門開得了、接駁路線接得上、測試對象找得到。這些事情有一項沒接好，後面的流程就可能忙得很認真，卻離原本想問的問題有點遠。

所以閱讀工具介紹時，可以試著把每個動詞畫成一站。「辨識」「分析」「撰寫」「執行」「產生報告」，每站都問一下：前一站交過來的是什麼？下一站需要什麼？原本一長串像魔法咒語的技術介紹，就會變成可以沿路檢查的小地圖。

先看它把哪些工作串起來

模糊測試可以先理解成：持續把各種輸入交給程式，觀察是否出現異常。其中的 harness，就是讓測試工具能呼叫目標程式的測試程式。在這套流程裡，辨識入口、處理建置、寫好 harness，都發生在執行 AFL++ 之前。[S1] 因此，整套流程是否有用，也取決於前面的準備是否正確。

假設測試程式雖然能執行，卻沒有真正碰到團隊關心的功能，測試時間拉長也未必能回答原來的問題。從這個情境就能理解：自動完成一個步驟，和完成正確的步驟，仍要分開檢查。

官方說明也提到，Fuzzing Taskflow 建立在 Taskflow Agent 之上。這個框架用來撰寫由大型語言模型驅動的安全自動化，將工作表達成一連串任務流程，交給代理從頭執行到尾。[S1] 從這個設計來看，LLM 的角色包含串接原本需要分別處理的工作。這是理解其應用方式的重要線索。

假想小劇場：報告出來，香檳先別開

把鏡頭拉回那個小組，來一段純屬示意的對話。

阿晴：「跑完了，還有報告，感覺可以交差。」

小路：「等等，剛才測到的是哪個功能？」

阿晴：「畫面一直在動耶。」

小路：「接駁車一直在動，也可能只是找不到下車處。」

阿晴：「好，那先找路線圖。」

這段對話好笑的地方，是「有在跑」真的很有安定感。像等下載時盯著進度條，數字只要持續變化，就會忍不住覺得事情正往好的方向前進。可是在測試裡，進度需要配上目標，才知道那份忙碌究竟回答了什麼。

如果把這段小劇場帶進會議，可以少問一句「跑了沒」，多問一句「這次最想確認哪件事」。假設關心的是某段輸入處理，就先確認測試有沒有走到那裡。問題變具體，後續看報告也比較不會像在拆一個不知道誰寄來的包裹。

自主執行之後，還要驗證結果

如果這些準備步驟能穩定自動化，團隊可能比較容易替專案建立第一條測試流程，也能把更多時間放在檢查測試範圍與分析結果。這是依流程設計提出的推論。要知道實際省下多少力氣，可以從一個範圍清楚的專案開始，把原本的準備時間與導入後的複核時間一起記下來。

尤其 C/C++ 專案的規模與複雜程度不同，評估時可以沿著流程逐站檢查：建置完成了嗎？入口選得對嗎？測試程式碰到了預定功能嗎？卡住時需要誰處理？把這些問題寫成檢查清單，比只記錄最後是否產生報告，更容易找出自動化真正省力的環節。

另一個關卡是漏洞報告。系統能產生報告，是官方列出的流程結果；報告裡的問題能否重現、是否真的構成漏洞，則需要另外的證據。[S1] 如果只看產出份數，很容易忽略後續驗證花了多少時間。團隊試用時，可以把「成功執行測試」與「確認有效發現」分開記錄，才看得出自動化幫忙到了哪裡。

對不同問題的適用程度，也值得分開觀察。團隊可以把邏輯錯誤、記憶體安全錯誤等類型分別整理，看看哪些測試產生了有效發現，哪些仍需要人補充案例。這樣整理之後，每份報告都能回到具體的程式行為，方便決定後續修正與再次測試的順序。

工具冷知識，藏在那些很容易滑過去的字裡

第一個小細節，是 Fuzzing Taskflow 與 Taskflow Agent 這兩個名稱。前者是這次介紹的模糊測試流程，後者是它建立其上的框架。官方用一連串 taskflows 來表達工作，交由代理執行。[S1] 把名稱拆開看，就比較不會把底下的框架和這次的應用當成同一個東西。

第二個細節，是流程裡仍然明確寫著「執行 AFL++」。[S1] 讀到 AI，很容易把整套工具想成一個對話框。其實在這份流程描述裡，還有辨識入口、分析建置、撰寫測試程式與執行測試等不同工作。看清楚每個角色，比只記住用了哪個模型，更能理解系統怎麼運作。

第三個細節，是最後還有「產生漏洞報告」這一站。[S1] 這提醒了一件很日常的事：發現值得注意的現象之後，還要整理成別人能接手的內容。就像小組報告不能只丟一句「那邊怪怪的」，至少要讓接手的人知道該看哪裡、怎麼重現、接下來要確認什麼。

幾個容易讓人腦補太多的說法

先來一句看似合理的話：「測得越久，應該就越安心吧？」回到遊樂園的接駁車，如果目的地與路線已經確認，增加測試時間才有清楚的討論基礎。要是還不知道車子開去哪裡，先延長營業時間，並不會自動把地圖補齊。

另一句是：「報告多，代表工具很厲害？」可以先把報告當成待拆的小紙袋，每袋裡裝的是需要檢查的線索。整理時不妨問：內容是否重複？能否照著步驟再看到同樣的現象？哪些項目已經確認值得處理？這樣評估，才不會被一桌滿滿的紙袋晃到眼睛。

還有一句特別容易出現在忙碌的星期五：「交給 AI，之後就可以先不管了吧？」比較有幫助的安排，是先約定在哪些地方停下來看結果。譬如建置完成後確認目標，測試啟動後確認範圍，報告出來後確認可重現性。把檢查點排好，休息時也比較知道自己等的是哪一件事。

這些問題聽起來沒有一鍵完成那麼帥，卻很適合拿來決定下一次要改什麼。流程不順時，如果只說「AI 不行」，整件事就停在一團霧裡；若能說清楚是入口沒選好，或報告還缺重現步驟，下一輪就有明確的調整方向。

哪些新資料值得等

最能改變判斷的，會是一組交代條件的實測：用了哪些專案、規模多大、多少能完整跑完，以及中途需要幾次人工修正。這些數字可以幫助區分，工具目前適合快速試做，還是已經能承擔團隊固定的測試工作。

接著要看報告品質。若有可重現的案例、經確認的漏洞數，以及不同類型問題的結果，就能更具體地評估價值。比較時也應把前置設定、執行資源與人工複核一起算進去，避免只看到自動執行的那一段。

同樣重要的是讓結果留得下來。試用時若能保留測試目標、設定、執行紀錄與人工判讀，就比較容易比較不同次執行，也能讓接手的人理解某項發現為何值得處理。這些紀錄可以成為調整下一輪測試的起點。

Fuzzing Taskflow 把值得追問的問題往前推了一步：當測試準備更容易啟動，團隊能否因此測得更深入？可行的觀察方式，是選定目標、跑完流程，再把有效發現與人工負擔放在一起看。累積這些具體結果，才能決定下一步要擴大到哪些專案。

週末小練習：不裝工具，也能玩一輪測試設計

找張紙，替一個想像中的活動報名程式畫出三個欄位：暱稱、場次、備註。先不用碰任何真實網站，也不用輸入任何人的個資。練習的主角是一個紙上程式，規則全部由這張紙來決定。

第一步，寫下「怎樣算正常」。例如暱稱要能看懂、場次得是清單裡的選項、備註可以留白。這裡沒有標準答案，重點是先把期望說清楚。否則等會兒出現奇怪結果時，很容易各說各話：有人覺得應該接受，有人覺得應該擋下來。

第二步，替每個欄位準備幾張搞怪小卡。暱稱只有空白、場次填進清單外的文字、備註塞進一長串重複字。每抽一張，就問：「希望程式怎麼回應？」可以拒絕，可以提示重填，也可以接受並正常處理，但要講得出理由。

第三步，把小卡交給另一個人，請對方只看規則，描述預期結果。若雙方答案不同，就把那張卡留下來。先別急著分勝負，因為這正好指出哪一條規則還需要補充。測試有時很像幫說明書找漏字，最值得討論的地方常常是「大家以為都懂」的那一格。

最後，替其中一張卡寫一份迷你報告：想測什麼、放了什麼輸入、預期看到什麼，以及還需要確認什麼。如果連紙上案例都能交代清楚，再看工具產出的報告，就比較知道該找哪些資訊。整個練習沒有動到陌生系統，卻已經把目標、輸入、判斷與交接走過一遍。

後記：進度條很好看，路線圖也要留著

自動化最讓人期待的地方，是那些原本得反覆準備的小事，終於有機會被妥善串起來。當接駁車有人安排、入口有人辨識，負責測試的人就能把注意力移到更具體的問題上：這次到底想知道什麼？得到的答案足夠清楚嗎？

下次再看到「自主式」或「一條龍」這類介紹，可以帶著遊樂園小地圖一起讀。不用急著按讚，也不用立刻皺眉，先找出各站怎麼連接，再看最後留下什麼結果。技術說明一旦能被拆成幾個看得懂的動作，討論起來其實沒有想像中那麼遙遠。

至於那杯從開場放到現在的飲料，劇情裡可以慢慢喝。程式的闖關進度，交給目標、紀錄與可重現的結果一起說明。那張路線圖若畫得清楚，下次出發就不用重新猜入口在哪裡。

來源

• [S1] AI-powered fuzzing with the GitHub Security Lab Taskflow Agent｜GitHub Blog｜發布：2026-09-24T18:26:12+00:00｜擷取：2026-09-25T00:06:22.258046+00:00｜https://github.blog/security/application-security/ai-powered-fuzzing-with-the-github-security-lab-taskflow-agent