一個多益 App 到底有多大？單手刷990 的規模盤點：65 萬行程式、28,640 題、8 萬個音檔

先給結論：一張總表

項目	數字
開發天數	156 天（2026-05-19 第一次存檔）
程式碼	654,678 行
自動化測試	5,069 個
題目（多益七大題 + 補充練習）	28,640 題
題目與教材裡的英文	約 116 萬個英文字
翻譯對照字串	976,479 條
圖片	7,153 張（App 專案內）+ 2,538 幅畫作（雲端）
音檔	79,854 個，約 80 小時
影片	24 支
程式改動 / 審查合併 / 工作單	5,523 次 / 1,521 包 / 1,226 張
發布版本	81 個（1.0.0 → 1.74.0）
官網頁面 / 文章（本篇上線前）	445 頁 / 84 篇
設計與工程文件	234 份，57,536 行

下面一項一項講。

程式碼：65 萬行，最大的一個檔案裡沒有任何邏輯

區塊	檔案數	行數
App 本體	301	297,228
自動化測試	303	133,087
網頁版	426	116,584
內容生成、檢查、發布的腳本	336	89,262
雲端後台（轉送回報、驗證訂閱…）	25	10,256
官網產生器	8	7,568
手機系統專用的小片段	5	693
合計	1,404	654,678

幾個值得知道的細節：

• 最大的檔案是介面文字檔，20,712 行，裡面沒有一行「程式」。App 裡每一句話都住在這裡：2,960 句介面文字，16,839 條字串。第二名是首頁，17,232 行。我們知道，我們也很想拆。
• App 本體的 29.7 萬行裡，約 1.9 萬行是程式從資料自動產生的表格（例如字根課程的展開表、解題鐵則的詞性表）。這些行數算不上「寫」的，但它們確實要編譯、要測。
• App 本體有 3,945 個程式單元，其中 1,550 個是畫面元件，約 380 個是完整的畫面。跨裝置同步的資料有 98 種，每一種都有自己的合併規則——這是另一篇文章的題目了。
• 測試的 13.3 萬行是 App 本體的 45%。自動化測試共 5,069 個，每一次改動都要全部通過，才能併進正式版。網頁版另外有 2.1 萬行測試。

順帶一提，「行數」是全世界最差的生產力指標。它衡量的不是品質，是要維護的東西有多少。65 萬行的意思是：改任何東西，都有 65 萬行可能被你弄壞。

題目：28,640 題，分成兩堆

第一堆是多益本身的七大題，11,032 題，分在 4,364 組題組裡：

Part	題數
Part 1 照片描述	335
Part 2 應答問題	1,375
Part 3 簡短對話	2,082
Part 4 簡短獨白	1,536
Part 5 句子填空	1,216
Part 6 段落填空	680
Part 7 閱讀測驗	3,808

第二堆是補充練習，17,608 題：片語 9,417、單字 3,834、文法 2,445、搭配詞 1,000、句子重組 441、改錯 246、口音辨識 225。

每一題不是寫完就算數。Part 1 到 Part 7 的每一題都有難度標記和中文對照——Part 3 到 7 對照每個選項，Part 1、2 的選項是用聽的，對照放在逐字稿上；其中 8,329 題（四分之三）附答案證據——文章或對話裡哪一句話支持這個答案；Part 5 和 Part 6 另有文法標籤；另外 5,682 題 Part 5–7 附了詳解。至於題庫到底夠不夠用，我們在〈多益題庫夠不夠？〉裡用 9,854 份雲端備份算過。

教材：題目以外的東西，比題目還多

「題目」只是練習的入口。單字、片語、文法這些模組，底下各自有一層又一層的資料：

• 單字 3,834 個，每一個都有：詞典釋義、字源故事、搭配詞（合計 19,930 組）、三種口音的發音、例句朗讀。另外有 737 個單字家族、201 組衍生字、152 個字根字綴、145 張主題地圖，以及長按任何字都查得到的 10,176 條詞庫。
• 片語 3,022 個，9,417 題，分成 196 個片語家族；149 個片語有來歷故事。
• 文法 48 個主題，每個都有講解；另有〈互動文法書〉46 章，每一節一幅漫畫，共 139 幅。
• 生活實用英語：290 句英語諺語（12 個主題）、230 個刁鑽發音字（8 種陷阱）、480 則文化典故（9 個部分）、136 篇荒謬單字故事（34 個等級，每級四篇）。
• 其他：93 堂字根課程、83 張小撇步卡、240 句聽寫語料、225 題口音比較（每題三種口音）、77 級單字隨身聽、2,538 幅單字畫作，還有一個做了 10 集、正在問大家意見的單字電台（另外約 860 集已錄好等著）。

把這些文本全部加起來：題目與逐字稿裡約 116 萬個英文字（閱讀 48.7 萬、聽力逐字稿 67.3 萬），對照用的翻譯字串 976,479 條。全部內容的資料檔有 563 個，共 230 MB。以一頁 250 個字、400 頁一本來算，差不多是十一本半的書。

圖片、音檔、影片

圖片在 App 專案裡有 7,153 張：

類型	張數
單字意思貼圖	3,672
商店截圖與宣傳圖	1,029
官網插圖、截圖、分享卡	565
文化典故插圖	484
聽力 Part 1 照片與圖表	357
互動文法書漫畫	139
單字故事插圖	136
單字攻城的城堡	78
Happysaur 吉祥物各種姿勢	29
圖示、品牌、電台角色、其他	664

另外有 2,538 幅單字畫作放在雲端，你點開那個字才下載，不隨 App 打包。

音檔是最大的一塊。專案裡有 79,854 個音檔。我們抽了 250 個量長度，再乘回去，估計總長約 80 小時——不睡覺從頭聽到尾要三天多：

類型	檔案數	估計時長
聽力題目音檔（Part 1–4）	9,306	≈ 21 小時
單字隨身聽（字、釋義、拼字、例句、搭配詞）	54,996	≈ 40 小時
單字例句朗讀	6,639	≈ 10 小時
單字發音（美音）	3,834	≈ 1 小時
片語朗讀	3,064	≈ 1 小時
口音訓練	1,365	≈ 1 小時
暖身題、刁鑽發音	650	< 1 小時

這還沒算放在雲端、要用時才下載的英音與澳音單字發音 7,668 個，以及專案其他角落的聽寫 240 句、故事朗讀 136 篇、考場環境音 159 段。單字隨身聽的 54,996 個檔案裡，有 3,834 個是把一個字一個字母一個字母拼出來的——沒有人想親口錄這個，所以是請電腦錄的。

影片最少：官網連到 YouTube 上的 24 支（23 支短影片加 1 支長片），分成 2 個播放清單。專案裡只有 1 支示範用的影片檔。做影片的時間，大部分花在做上面那些東西了。

開發紀錄：5,523 次改動、1,521 包審查、81 個版本

先解釋三個詞。程式每存一次正式紀錄叫一次 commit（改動）；一批改動要先經過別人審查、通過測試，才能併進正式版，這一批叫一個 PR（合併請求）；而每一個 bug、回報、提案，都是一張 issue（工作單）。

• 5,523 次改動，156 天，平均一天 35 次，週末也算在內。七月 1,408 次是高峰，之後每個月都在 1,250 到 1,400 之間。
• 1,521 包合併請求，1,509 包併進去了。每一包都要先通過全部 5,069 個自動化測試；有 213 包的討論串有五則以上留言，那通常是審查的人和寫的人來回了好幾回合。
• 1,226 張工作單，1,190 張已關閉。其中 562 張是題目回報、534 張是意見回饋——也就是說，1,096 張（89%）是你們在 App 裡按「回報問題」開的。這個專案最大的測試團隊沒有領薪水。剩下的 130 張是我們自己開的：功能提案、bug 和待辦事項。這條生產線值得單獨講一節，就在下面。
• 81 個發布版本，從 5 月 19 日的 1.0.0 到今天的 1.74.0，平均每 1.9 天一版。這不是計畫，是回頭看才發現的。
• 另外發過 106 則 App 內公告，包括幾次問卷——最近一次的結果在〈用戶說我們方向錯了〉。

你按下「回報問題」之後，發生了什麼事？

你在某一題按「回報問題」，寫兩句話，送出。接下來是這樣的：

1. 幾秒內，它變成一張工作單，掉進我們的追蹤系統，跟上面那 1,226 張排在一起。你不用填的東西，App 替你附上了：那一題的編號、你的 App 版本、手機型號、系統版本、你用的語言。這些正是修 bug 最需要、而寫信的人幾乎永遠忘了寫的東西。
2. 你的手機記住了這張單的號碼。 到「設定 → 我的回報」，你會看到它現在的狀態：已收到 → 處理中 → 已修正。如果我們看不懂，狀態會變成「等待你補充說明」，旁邊有個按鈕讓你補。不用帳號，不用 email，不用登入任何地方。
3. 我們在單子上寫的每一句回覆，都會原文出現在你的手機上。 你可以再回、可以補圖、也可以在我們結案之後重新打開它說「沒好」。
4. 修好之後，單子會標上修正的版本，你那邊會顯示「已在 1.xx 修正」，首頁也會跳一條「你的回報有新進度」。你知道該更新了，也知道為什麼。

這就是為什麼我們一直、一直請大家用 App 裡的回報，而不是其他管道：

• Email：沒有題號、沒有版本、沒有機型，我們得先回信問三個問題；而且它不在追蹤系統裡，很容易被下一封信蓋掉。
• 問卷：問卷是匿名的，我們看得到問題，卻找不到人問細節，也沒辦法告訴你修好了。
• 商店評論（最糟的一種）：我們可以公開回覆一次，但沒有對話串：問不到題號和版本，修好了也沒有辦法通知你。更慘的是，一條「第 1,204 題答案錯了」的一星評論，在那題第二天就修好之後，還會在商店頁面上掛好幾年。

在 App 裡按回報的 1,096 張單子，每一張都有人看、有人回、修完有人通知。寄到別處的，我們只能盡力。

官網：445 頁、84 篇文章

在這篇上線之前，官網 handy990.happysaur.com 有 445 個網頁，繁體中文版 102 頁。文章分五區，共 84 篇：技術文件 24 篇、英文知識 33 篇、多益指南 14 篇、實戰報告 3 篇、開發筆記 10 篇——你正在讀的是第 11 篇。

設計文件：234 份、5.7 萬行

這一項通常不會有人數，但它大概最能說明「這個專案是怎麼做的」。每一個功能在寫程式之前，都先有一份設計文件：要解決什麼問題、為什麼這樣做而不是那樣做、資料怎麼存、怎麼測、哪些事刻意不做。功能上線後，文件留著，下一個改它的人先讀文件。

類別	份數
功能設計	81 份，31,142 行
內容編寫規範與審查	24
工程（同步、帳號、遙測、媒體託管、網頁版）	18
行銷	16
推廣文案	57
商業模式	4
商店文案	6
其他	28

旁邊還有一整套「工具的工具」：336 支腳本、51 個一鍵建置指令、11 套封裝好的工作流程（出題、審題、發版、修 bug、寫這種文章……）。這些東西沒有一行會出現在 App 裡，但沒有它們，上面的內容做不出來。

還有幾個不好歸類的數字

• 專案裡有 117,208 個檔案，5.06 GB；加上每一次改動的完整歷史，8.7 GB。
• 另外有 2.4 GB 的半成品內容，還沒通過審查、還沒進 App。
• 32 個補充練習模組（還不含諺語、發音、典故、故事這些「生活實用英語」）。
• 截至 9 月 8 日，9,854 份雲端備份。

小小的七人團隊怎麼做到的？

單手刷990 是七個人做的，156 天。（七人團隊是本站長期堅持的官方說法。如果你在 App 的「關於開發團隊」頁看到「獨立開發」四個字，請當作沒看見；如果你數了數下面提到的人只有一個，那是因為另外六位都很低調。）老實說，做法沒有什麼秘密，只有幾條一開始就定下來、之後沒有破例的規矩：

• 先寫文件，再寫程式。 上面那 81 份功能設計不是事後補的。一個功能想不清楚「為什麼」和「不做什麼」，就不會動工。
• 內容走同一條生產線。 每一題都經過：出題 → 跟現有題庫查重 → 人工審題 → 上架。不管是 Part 7 的閱讀文章還是一句諺語的翻譯，都一樣。工具（包括 AI 工具）幫忙產初稿和找問題，但沒有一題是沒人看過就上架的。
• 測試擋在門口。 5,069 個自動化測試，每一包改動都要全過。這是我們敢每 1.9 天出一版的原因。
• 用的人告訴我們哪裡壞了。 89% 的工作單來自 App 裡的回報按鈕。我們回每一張，修完也在 App 裡告訴回報的人。

七個人（姑且這麼說）、156 天、65 萬行，聽起來很快。但真正花時間的從來不是「做出來」，是「做出來之後判斷它對不對」——文件和測試，就是把這些判斷留下來的方法。

但是老實說

照例把話說清楚：

• 大不等於好。65 萬行、2.8 萬題、80 小時音檔，對你明天的練習毫無意義。重要的是今天推給你的那 10 題選得對不對。這些數字說明的是「有多少東西要顧」，不是「有多好」。
• 音檔時長是抽樣估計，誤差可能有幾個小時。英文字數是用空白切的，不是語言學意義上的「詞」。
• 行數包含大量不是程式的東西：介面文字、自動產生的表格、測試。如果只算真正的程式邏輯，答案大概是上面那個數字的一半。
• 562 張題目回報不是勳章。每一張都是有人被一道有問題的題目耽誤了時間。數字大代表題庫大、用的人多，也代表我們欠的修正多。
• 所有數字都是 2026 年 10 月 22 日當天的。下週就不對了。

---

這篇是單手刷990 的開發筆記。相關文章：〈多益題庫夠不夠？〉從使用紀錄看題庫覆蓋率，〈用戶說我們方向錯了〉是最近一次問卷的結果。