聽力練習模式｜工作報告

1　還需要你決定的事

結論：有 4 題等你決定，都不擋上線。我的建議是：前 3 題都「先照現在的用一週，再決定」，第 4 題另開小案子處理。

第 1 題：新加的畫面文字，要不要換說法？

問題：最後兩輪照試用者的建議加了幾句新文字。你授權我先做（04 寫明「字眼照試用者建議先做」），但字眼本來是你要拍板的事。

我推薦：先用，用一週再說。
為什麼：前四句是第 3 關試用者建議的說法，最後一句是監工建議的；監工（05k）在手機上看過實際樣子，不會擠爛版面。字眼好不好，要你自己累的晚上用過才知道。哪句讀起來卡，直接告訴我改哪句就好。

第 2 題：複習卡要不要把「上次的選項和對錯」收起來？

問題：複習卡現在還顯示上次的 5 個選項、上次的對錯（例如紅色「✗ 錯誤 · 正解：…」）。手機上一張卡約 899 px 高。

我推薦：要收（預設收起，點「看上次的題目」才展開），但不急：先用一週，覺得礙眼再開一個小案子做。
為什麼：

• 複習是在驗耳朵，舊的對錯跟耳朵無關，還讓手機多滑好幾個畫面。第 3 關 5 輪試用者每輪都提（r1 L2、r2 L2、r3 L3、r4 L3、r5 L3）。
• 但它一直被評為「低」，不影響做完一次。04 記錄不改的原因是「要動版面較大」。

第 3 題：學新題那段時間，複習會先堆起來，能接受嗎？

問題：這是 D6 規則（到期超過 10 句時，先排最難的）的必然結果。監工用模擬算出來的樣子（05j 低 3）：

• 第 5～25 次，每次到期的句子都超過 10 句，最多 44 句（第 11 次）。
• 面板的「之後還會再出現 N 句」會先漲到 50～60 句，才開始下降。
• 「只點過 1 個字」的句子會一直被更難的擠到後面，最多等 16 次才輪到。
• 新題全部學完後約 15 次（第 26 次）清空。
• 每一次都還是「複習 10＋新學 10」，做得完，不會卡住。

注意：這是模擬，假設「新題 70% 會點 1～3 個字、複習 60% 按都聽出來」。這兩個比例是監工假設的，不是你的實際資料。

我推薦：接受，先照現在的用。
為什麼：

• 每次的分量不變，1.5 小時內做得完。
• 先練最難的，符合你 10/5 說的「學會的字之後會在新題目裡自然重複，舊題目只要把真正難的磨到聽得出來」。
• 真的覺得「數字一直漲」有壓力，還有兩條退路：改面板的說法，或改用停車場 P3 原本的推薦（複習多時新題少排幾題，總量不變）。

第 4 題：文法課綱裡「每遍試說中文」那段，要不要另案改掉？

問題：課綱的聽力格式寫「先聽三遍不看字，每遍試說中文」。這跟本案的新方法「只抓聲音、不翻成中文」相反。你 10/5 決定本案不做「每遍試說中文」（停車場 P1），但課綱檔本身沒改。

我推薦：另開一個小案子，把課綱那段改成「聽到→一秒內出現畫面或懂意思」。
為什麼：合約第 41 條規定之後出第 2 冊要照課綱的規則。兩份文件說法相反，之後出題或複習課綱時會混淆。

A　合約原文

結論：合約動工前就鎖定了，收工時一個字都沒改；後來只追加了第 42、43 條（手冊放上網站）。

合約原文的條號順序就是 35、37、38、39、36、40、41（第 36 條放在「不能弄壞的」底下），照原樣保留。

合約增補 1（第 42、43 條）

檔案 02-contract-amend-1.md。主理人 2026-10-04 提出並同意；是追加，不改動原文。

B　驗收對照表

結論：43 條裡，最後 38 條「一樣」、5 條「有差異」（第 13、16、20、37 條是你已追認的 D 差異，第 30 條是一個少見操作的小差異）、0 條「沒做到」。

怎麼讀這張表

• 第一遍：第一位監工（05-review.md）的判定。當時 36 條一樣、7 條不一樣、0 條沒做到。
• 最後狀態：照最後三次複查（05i、05j、05k）和 04 的修正紀錄判斷。
• 「有差異」不等於壞掉：是做法跟合約字面不同，原因寫在 D 段。

C1　實際怎麼做

結論：網站把你的每個動作記成一行流水帳；進度就是「把帳本從頭算一次」。所以兩台裝置、斷線時做的事，合起來永遠不會互相蓋掉。

1. 事件流水帳＋server 同步

你每做一個動作（播放、作答、點字、按複習鈕、按完成），網站就記一行，像記帳本。這叫事件流水帳。

• 進度＝重算帳本。從第一行算到最後一行，就得到「你現在學到哪」。
• 兩台裝置合帳本就好。同一行只算一次（每行有一個獨一無二的編號）。不管先收到哪一行，算出來都一樣。
• server 只會往後加，不會改舊的。所以 server 上的資料庫本身就是完整歷史，要回到哪個時間點都可以。
• 做完動作 0.4 秒後送到 server；每 30 秒去 server 拿別台的新動作。連不上時先存在這台，每 15 秒重試。

另外 server 有一張epoch（資料庫的身分證）。從備份還原時會換一張新的。裝置看到身分證換了，就知道「server 可能少了東西」，把自己有、server 沒有的全部補送回去。

所以對你的影響是：電腦做到一半、手機接著做、斷線時做的，都不會掉。

程式片段 1：重算帳本（app\js\plan.js 第 284–288、363–371 行）

  function sortEvents(events) {
    const byId = new Map();
    for (const e of events) if (e && e.id && !byId.has(e.id)) byId.set(e.id, e);
    return [...byId.values()].sort((a, b) => a.t - b.t || (a.dev < b.dev ? -1 : a.dev > b.dev ? 1 : 0) || a.n - b.n);
  }
  …
  function replay(events, book) {
    const s = emptyState();
    s.skipped = 0;
    for (const e of sortEvents(events)) {
      try { apply(s, e, book); }
      catch (err) { s.skipped++; if (typeof console !== "undefined") console.warn("skipped event", e && e.type, err && err.message); }
    }
    return s;
  }

白話：

• sortEvents：先把重複的行丟掉（同一個編號只留一筆），再照「時間 → 哪台裝置 → 第幾筆」排好。
• replay：從空白的進度開始，一行一行套用。
• 某一行壞掉，只跳過那一行並記下跳過幾筆，不會讓整份進度打不開。

2. IndexedDB＋「還沒寫完」便條

每台裝置也在瀏覽器裡存一份帳本副本，放在 IndexedDB（瀏覽器內建的大倉庫，空間很大）。

• 原本放在 localStorage（瀏覽器的小抽屜，上限約 5 MB）。監工實測約 10 個月就會塞滿，而且每點一下要把整本重寫（100～220 毫秒）。所以改放 IndexedDB。
• IndexedDB 的問題：寫入要排隊，點完立刻關頁會掉。實測連點 20 下後立刻重新整理，掉 8 筆。
• 解法：寫之前先在 localStorage 貼一張「還沒寫完」的便條（localStorage 是當場寫完的）；寫完撕掉。下次開頁看到便條就補寫。改後實測三次一筆不少。

所以對你的影響是：點完立刻關手機瀏覽器，也不會少一筆；3 萬筆時每點一下約 0.1 毫秒，開頁約 0.2 秒（04 實測）。

程式片段 2：便條（app\js\store.js 第 104–110、132–137 行）

  const pendingNote = {
    add(list) { ls.set(K.pending, JSON.stringify(union(parse(ls.get(K.pending)) || [], list))); },
    done(list) {
      const ids = new Set(list.map(e => e.id)), left = (parse(ls.get(K.pending)) || []).filter(e => !ids.has(e.id));
      if (left.length) ls.set(K.pending, JSON.stringify(left)); else ls.del(K.pending);
    },
  };
  …
  async function saveLocal() {
    const changed = dirty; dirty = [];
    if (!changed.length && cache !== lsCache) return true;
    const idb = cache !== lsCache;
    if (idb) pendingNote.add(changed);   // synchronous: done before the page can close
    if (await cache.put(changed)) { if (idb) pendingNote.done(changed); cache.announce(changed); return true; }

白話：

• pendingNote.add：把這次要寫的幾行，先抄一份到便條上。
• cache.put：真的寫進 IndexedDB。成功了才 pendingNote.done（撕掉便條），並通知同一個瀏覽器的其他分頁。
• 如果中途頁面被關掉，便條還在，下次開頁會補寫。

3. 排程規則（D6）

程式片段 3：間隔與挑句子（app\js\plan.js 第 9、48–52、230–236 行）

  const INTERVALS = [1, 4];
  …
    let due = byDue.filter(q => s.review[q].due <= cur);
    if (due.length > REVIEW_CAP) {   // D6: too many due -> take the hardest (most missed words), still shown in due order
      const pick = new Set([...due].sort((a, b) => hard(b) - hard(a)).slice(0, REVIEW_CAP));
      due = due.filter(q => pick.has(q));
    }
  …
  function reviewAt(s, q, result, ses, snap) {
    delete s.mastered[q]; delete s.reviewPrev[q];
    if (result === "miss") { s.review[q] = { stage: 0, due: ses + 1 }; return; }
    const stage = (snap.stage || 0) + 1;
    if (stage >= INTERVALS.length) { delete s.review[q]; s.mastered[q] = ses; return; }
    s.review[q] = { stage, due: ses + INTERVALS[stage] };
  }

白話：

• INTERVALS = [1, 4]：只有兩格。第一格是「點過字後隔 1 次」，第二格是「第一次聽出來後隔 4 次」。
• 挑句子：先找出這次到期的句子；超過 10 句（REVIEW_CAP）時，照「點過幾個字」由多到少挑 10 句，再照原本的到期順序排。
• reviewAt：按「還是有沒聽出來的」→ 回到第 0 格、下一次到期。按「都聽出來了」→ 往下一格；走完兩格就移到「已學會」。

4. 畫面三區

畫面上一直有「下一題 ↓」「↓ 接著做」帶你往下走。只想複習的晚上，複習做完會停在「今天只複習，這次完成」的框。手機上左側面板收成底部一條。

C2　遇到什麼問題、怎麼解的

結論：最大的一次轉彎是：「整份進度互相比較、合併」修了兩輪還在掉資料，所以照規則三（修兩次不行就換方法）整個換成事件流水帳。之後的問題都是小修。

名詞先講清楚

• 第 1 關：e2e 測試（自動開瀏覽器，照合約一條一條點）。
• 第 2 關：監工逐條對照合約（05、05e～05k，共 7 次，每次換一個沒參與過的人）。
• 第 3 關：試用者扮演你本人實際操作、打分（05d r1～r5）。
• 第 4 關：掃描壞味道（程式寫法上「之後容易出錯或難改」的地方，05c、05h）。

依時間排

測試數量的變化

數字都來自 04-implementation.md 各節的「現況」。「流水帳上線後」那列 server 寫的是「5 個 API 測試＋2 個靜態檔測試」，這裡合計成 7。

C3　改了哪些檔案

結論：本案新做了整個 app\ 資料夾，另外在 docs\ 加了紀錄與報告。舊頁 toeic-drill-01.html 和 make-toeic-audio.py 都沒有改。

清單是 2026-10-05 用指令實際列出來的，不是憑印象寫。

app\（全部是本案新做的）

docs\

沒有改的

C4　怎麼退回

結論：本案不在 git，退回很簡單：停掉 server，回去用舊頁 toeic-drill-01.html。舊頁一個字都沒被改過。

步驟

補充：本機開發用的資料庫是 app\data\dev.db（config.json 指到它），跟實驗室電腦的 progress.db 是兩個檔。

D　差異段

結論：跟合約字面不同的地方有 6 個大差異（D1～D6，都已在 10/5 追認）、8 個小差異（6 個已修、2 個刻意不修），另外有一份「刻意不做」清單。

大差異 D1～D6（出處 05b-diff.md）

停車場 P1 是你親自決定（不做「每遍試說中文」）；P2～P4、D1～D6 是你授權代決（01-decisions.md「停車場裁決」節、00-parking.md 裁決結果）。05b 原本把 D2～D5 標為「小差異」、D1 標為「大差異」；這裡照你的要求把 D1～D6 都放在大差異。

小差異（出處 05j、05k）

05k 另外記錄、不算問題：手機上面板「收起」49×28、頂端「看全部題目」91×33 仍偏小。小6、小7 修完後沒有再請監工複查。

刻意不做的項目（出處 04「刻意不做」與各輪處理表、HANDOFF 第 6 節）

E　壞味道摘要

結論：會影響正確性的壞味道都修了；剩下的是「程式寫法可以更整齊」的部分，依你的規矩（重構是獨立任務）留著沒動。

壞味道＝程式寫法上「之後容易出錯或難改」的地方，不一定是 bug。重構＝不改功能，只整理寫法。

處置分三種

• 已修：04 有修正紀錄，或監工已確認。
• 重構候選：04「重構候選」節有列（只記錄、不動手）。
• 不處理：附原因。04 沒有逐項寫原因的，我寫「04 無逐項紀錄」，並標出目前程式的樣子是我讀程式確認的。

第 4 關第 1 次（05c）

監工範圍聲明（照抄）：「審查範圍：index.html、app.css、js/plan.js、js/store.js、js/ui.js、server.py、tools/extract_book.py、tests/*。book.js（產生的資料）與 guide.html（靜態文件）未審。判斷基準是 03-tech-spec.md 與 04-implementation.md 的既定設計（例如：不用框架、ui.js 單檔、三方合併是已記錄的決策 D1），不以個人偏好扣分。」

05c 的 28 項，第 4 關重掃（05h）已經整理過現況，照抄成下表：

第 4 關重掃（05h）

監工範圍聲明（照抄）：「審查範圍：index.html、app.css、js/plan.js、js/store.js、js/ui.js、server.py、tools/extract_book.py、tests/plan.test.js、tests/server_test.py、tests/e2e.js。book.js（產生的資料）與 guide.html（靜態文件）未審。判斷基準是 03-tech-spec.md（vanilla JS＋Python 標準函式庫、不建置、單一資料夾）與 04-implementation.md 已記錄的決策（例如面板門檻改 1240、ui.js 單檔），不以個人偏好扣分。」

第 2 關第 6 次（05j）的壞味道表

監工範圍聲明（照抄）：「12 條壞味道掃描（只看這輪改過的部分）」；「其餘幾條（3 過大類別、4 過長參數列、5 資料泥團、6 依戀情結、11 冗贅類別）在這輪改動裡沒有看到。」

第 2 關第 7 次（05k）的壞味道表

監工範圍聲明（照抄）：「壞味道（只看這兩輪改過的部分）」；「建議：照主理人規矩，壞味道的整理是獨立任務，不要跟修低 1～3 混在一起。」

05k 判定「沒看到」的：3 過大類別、11 冗贅類別。

第 3 關分數變化

結論：五個維度都比第 1 輪高；第 2 輪起就沒有低於 3 分的格子。最低的是「學習引導」3.6 和「手機介面」3.7。

第 3 關＝每一輪找一個沒參與過的試用者，扮演你本人（研究生、下班很累、聽力 70%、想無腦學習），實際操作、打 1～5 分。低於 3 分就一定要修。

數字照抄各 05d 檔的分數表平均列，沒有自己重算。

讀這張表要注意

• 每輪的情境不一樣，平均只能看大方向。r3 看的是「連用一週」，r4 看「第一次用＋手機」，r5 依你的指示只測正常使用、拿掉了斷線等極端情況。
• r1 評的是改到一半的版本：試用途中程式被改了，r1 檔案寫明「本報告評的是 23:06 以前的版本」。
• r1～r4 的音檔是假的（按 🔊 就算聽過）；r5 大部分用真的音檔，每個都有播完。
• r5 給 3 分的格子：手機讀手冊（L5）、學會那一刻沒表示（M1）、「接著學新的」跳過新字（M2）、沒先聽只有灰字（L4）。M1、M2、L5 已在 04 修好；L4 是 P4 的裁決結果。

接下來（給實驗室電腦）

結論：實驗室電腦上的 AI 照 HANDOFF.md 讀、照 DEPLOY.md 架起來；你只要打開網站，照「這一次」做完，按「這次完成」。

三份文件各在哪、做什麼

之後怎麼開始學

1. 打開網站（手機用 Tailscale 的 http://100.x.x.x:8765/）。
2. 照畫面上「這一次」的三區做：複習 → 新學 → 連續聽。不知道下一步就按「下一題 ↓」或「↓ 接著做」。
3. 做完按「這次完成」。累了也可以提早按，沒做完的會留到下一次。

本報告的每一項判斷都來自實際查證（讀案子資料夾的檔案與程式碼），不是推測。文中標「04 無逐項紀錄」的處置原因、第 1 節「我推薦」的理由，是我依紀錄做的判斷；第 1 節第 3 題的堆積數字是監工的模擬推估（假設的比例不是實際資料）。