由零到 500 stars：Tickets Hunter 如何用 AI Pair Programming 做出一款搶票產品

香港人對搶票嘅痛點，絕對係刻骨銘心嘅集體創傷。Clockenflap 仆咗、Coldplay 秒殺、Anson Lo 演唱會個城市售票網直接癱瘓——每次大型活動賣飛，都係一場技術同運氣嘅角力。成千上萬人同一秒撳掣，有人開到 Chrome 分頁都未 load 完，有人已經用 bot 掃走幾十張。以往呢啲 bot 通常係灰色地帶嘅封閉工具，由細規模嘅開發者私下維護，source code 唔公開，功能亦隨住票務網站改版而漸漸失效。但今年出現咗一個完全相反嘅 open source 項目——Tickets Hunter——用一種極端嘅方式重新定義咗呢類工具嘅開發模式：由始至終，一行 human-written code 都冇。

唔寫 code 嘅軟件工程實驗

Tickets Hunter 最初只係一個 fork。原作者 max32002 嘅 tixcraft_bot 因為維護者精力所限已經停滯，香港開發者 bouob 決定接手嘅時候，冇行傳統嘅路——搵個 codebase 慢慢讀、逐行 debug、然後自己 patch。佢選擇嘅係一條當時仲好新嘅路：用 AI 做開發夥伴。

整個項目的 README 入面坦白寫住：「本專案是一項 AI 輔助軟體工程實驗——主要透過自然語言指令與 Claude Code 及 Codex 協作進行開發、除錯與維護，不手寫任何程式碼。從架構設計、功能實作到 PR 審查，皆由 AI 協助完成。」

呢句說話唔係 marketing。如果你行入個 GitHub repo，你會發現接近 200 個 commits 裏面，每個 commit message 都係 AI 生成嘅結構化描述，程式碼使用咗 Python 嘅 nodriver 架構（zendriver 嘅非同步版本），支援超過 12 個票務平台——由台灣嘅 TixCraft、KKTIX，到香港嘅 Cityline、HKTicketing（快達票），再到國際嘅 TicketMaster。一個由人類用自然語言描述需求、由 AI 生成實作、再由 AI 互相 code review 嘅閉環，就咁運行咗接近一年。

對於習慣咗「唔識寫 code 就學咗先」嘅香港開發者社群嚟講，呢個做法係一種觀念上嘅衝擊。佢暗示咗一個問題：如果我哋對「寫軟件」嘅理解，可以由 keyboard typing 轉移到 intent articulation，咁開發者嘅競爭力究竟仲係咪建基於 syntax 嘅熟練度？

從 CAPTCHA 到 Cloudflare：AI 點樣處理真實世界嘅屎窿

搶票工具最令人頭痛嘅部分，永遠唔係業務邏輯——而係對抗反機器人機制。Tickets Hunter 支援嘅每一個平台都有自己一套折磨人嘅防護：Cloudflare Turnstile、reCAPTCHA、Cloudflare Challenge 頁面、IP 封鎖、Queue-IT 排隊系統、CDN 快取污染、Dynamic DOM structure 變更。

呢啲問題喺傳統開發模式下，意味住開發者要逐個研究 bypass 方法，寫 hardcode selector，然後每當平台改版就要重新逆向工程。Tickets Hunter 嘅做法截然不同：佢用 OCR 模型（自訓練模型 + ddddocr）處理 CAPTCHA，用 nodriver 嘅 DOM 工具動態偵測 Cloudflare 驗證頁面，再靠 AI 去理解每個平台嘅獨特 DOM 結構變化。

睇返個 commit history 會發現一個有趣嘅 pattern：幾乎每個「支援新平台」或「修復反爬機制」嘅 commit，都唔係透過大量手動 testing 去做 regression，而係開發者將 error log 直接 feed 俾 AI，由 AI 分析 root cause 然後生成修復 patch。例如 Cityline 搶票流程卡頓、Cloudflare Turnstile 自動解題、iBon 嘅 Queue-IT 排隊偵測——呢啲傳統上要花幾日至一個星期去 debug 嘅問題，喺 AI pair programming 模式下變成一條 prompt 嘅事。

呢度有一個好重要嘅 insight：當軟件工程嘅瓶頸由「寫 code」轉移到「描述問題」嘅時候，一個開發者能夠 handle 嘅系統複雜度可以提升一個數量級。Tickets Hunter 嘅 codebase 涉獵嘅範疇——瀏覽器自動化、分散式 CAPTCHA 處理、多線程非同步排程、Web UI 前後端——遠遠超過一個獨立開發者正常能夠 maintain 嘅範圍。

500 stars 背後嘅社會學意義

截至 2026 年 6 月，Tickets Hunter 喺 GitHub 上有大約 500 stars。呢個數字對於一個搶票工具嚟講，其實相當有趣。Star 嘅人唔係因為個 code 好優雅而嚟——Tickets Hunter 嘅 code beauty 唔係重點，重點係「佢真係 work」。

呢 500 stars 反映出一個更宏大嘅趨勢：open source 工具嘅 adoption 曲線，正正喺度印證緊「開發民主化」呢個現象。以往要整一個跨平台搶票系統，你需要前端開發、後端開發、瀏覽器逆向工程、CAPTCHA 解題、Docker 部署等等一系列技能組合。但 Tickets Hunter 嘅開發者只係需要識得表達需求、理解同驗證 AI 嘅輸出、以及對系統行為有足夠嘅批判性判斷力。

項目嘅演進亦展示咗一個健康 open source 社群點樣喺 AI-native 模式下運作。有人開 issue 報告特定平台嘅 bug，AI 分析之後生成 fix，開發者審查後 merge，成個流程唔需要參與者親手寫一行 code。Docker 支援嘅 PR（#314）由社群成員 YCNeo 提交，經過 AI code review 同詳細對話之後先至被合併——呢個 type 嘅「人機協作審查」可能係未來 open source 嘅新常態。

對香港開發者嘅幾個具體啟示

講到呢度，你可能會問：所以呢，我可以點樣套用呢個經驗？

第一，重新定義你嘅技能組合。如果你係一個獨立的開發者或者 tech startup founder，你嘅價值已經唔再係「我好叻寫 React/Python」，而係「我可以精準定義問題，然後用最快嘅方法驗證解決方案」。Tickets Hunter 嘅開發者唔需要用記憶背誦 Python 語法，但佢需要精準地向 AI 描述 Cityline 嘅 DOM 結構、Cloudflare Turnstile 嘅行為模式、以及點樣優化前後端互動。

第二，善用「AI pair stress test」。當你搵到一個真實嘅痛點（好似搶票咁），你唔需要等到自己 skill set 完備先開始——你可以用 AI 做你嘅 junior engineer，不斷疊代、不斷打磨。過程中最有價值嘅技能係 debugging articulation：你識唔識得將一個 error message 同佢發生嘅 context 用自然語言講清楚？如果你做到，你已經超越咗唔少仲喺度 copy-paste Stack Overflow 嘅開發者。

第三，重新思考 open source 嘅貢獻門檻。Tickets Hunter 嘅社群實踐證明，未來嘅 open source 貢獻可以唔再限於寫 code。識得寫清楚 bug report、test case、或者使用場景嘅人，都可以對項目產生實質影響。而人機協作嘅 code review 機制仲可能解決 open source 社群一個長期存在嘅問題：maintainer bottleneck。

搶票係一個入口

有人會質疑：你講到咁大，咪又係一個搶飛 bot？我嘅睇法係：搶票只係一個切入點。Tickets Hunter 係一個非常好嘅縮影，話畀我哋知當開發門檻被 AI 大幅降低之後，乜嘢先係真正嘅價值所在——係理解真實世界嘅複雜性、係有能力定義清楚嘅問題邊界、係對技術工具同商業場景之間嘅 gap 有批判性嘅判斷。

如果你係一個對 AI 開發有興趣嘅香港開發者，去 fork Tickets Hunter，試下用 Claude Code、Codex、或者 opencode 去加一個新平台支援。你唔需要識 Python 先開始。你需要嘅係一個真實嘅問題、一種清晰嘅描述能力，同行動。500 stars 只係開始。