Skip to main contentSkip to footer
Search
LY Corporation Tech Blog

支持 LY Corporation 和 LY Corporation Group (LINE Plus, LINE Taiwan and LINE Vietnam) 服務，宣傳技術和開發文化。

Project OS：跑進大迫傑模式 AI Dev × Hackday 2026 · 讀懂身體、讀懂程式碼

Project OS 是我們在 LY Hackday 2026 打造的 AI 跑步夥伴，整合 Strava、OpenAI 與 LINE LIFF。它會從跑者的訓練紀錄中理解近期狀態，提供個人化建議，並把分析結果轉化成跑卡與「大迫傑模式」等體驗。這是 AI「讀懂身體」的部分。

image

但這篇文章主要想講另一半：AI 怎麼「讀懂程式碼」。我們是一支由 Backend、TPM、PM 組成、前端經驗偏少的三人小隊，靠著腦力激盪流程、多層驗證、gh CLI 工作流與 AI 簡報協作，在兩天內把產品從想法一路跑到終點。以下依照比賽節奏，分成起跑配速、補給站、跑表紀錄與最後一棒四個部分。

Part 1｜起跑配速：Superpower Workflows

團隊三人對後端邏輯、資料結構、需求拆解都很熟悉，但前端經驗普遍偏少。過去遇到這種組合，通常是硬著頭皮邊查邊寫，或是把前端整個丟給 AI 直接生成 code，能不能用全憑運氣。這次改用 Superpowers 的 brainstorming 技能，發現它剛好補上這個缺口。它不會一收到需求就直接生成 UI，而是先拆成三步。

  • 第一步：只要用白話描述想做的功能，不用先想清楚所有前端細節。
  • 第二步：AI 會主動反問我們容易忽略的體驗問題，例如「使用者第一次開始挑戰時，預設的可見度該是什麼」，並列出多個選項與建議理由，這些問題往往正是平常會漏掉、事後在測試或上線時才發現的坑。
  • 第三步：把選定方案具體化成畫面細節與 Demo 情境，讓我們動手前就能判斷這個方案值不值得做、展示起來夠不夠有 wow 感。

 

有技能 vs 沒技能：兩種開發流程的落差

 

沒用技能的傳統開發，也就是俗稱的 vibe coding：需求一丟出去，AI 立刻列出核心實作清單：資料庫要加欄位、UI 元件要刻、API 端點要處理、排行榜邏輯要改、多國語言字串要補齊。整份清單看起來很完整，但它是「事後補齊」的產物，沒有人在動手前先確認過使用者體驗上的關鍵決策，像是預設值該怎麼定、切換後的畫面回饋要多明顯。這種做法對熟悉前端的人沒問題，邊做邊調就好，但對我們這種前端直覺薄弱的組合，常常是等到測試或展示階段才發現「畫面怪怪的」或「這個預設值好像對隱私不太友善」，回頭修改的成本就冒出來了。

image

有 brainstorming 介入的流程則相反：前端該有的判斷力，先透過提問的方式外部化出來，變成一個個具體的選擇題，附上建議選項與理由，讓不擅前端的我們也能做出接近專業前端會做的決策。等真正進入開發，團隊要做的已經不是「這個畫面該怎麼設計」，而是「照著已經討論好的方案去實作」。它補的不是產出速度，而是前端該有的「提問習慣」與「決策依據」，這正是 Backend、TPM、PM 組成的隊伍最容易缺、也最容易在展示時被看出來的一塊。

image

Part 2｜補給站：不只 TDD，用多層驗證防止 AI 順手改壞系統

AI 寫 code 最大的風險不是寫不出來，而是「順手改壞你沒盯著的地方」。我們建立了四層驗證：hook 強制單元測試、Playwright E2E、playwright-cli 截圖目視驗證，以及由 AI 執行的自然語言測試案例，讓每一次 AI 改動都要穿過整個漏斗才算數。

 

痛點：測試全綠，畫面壞了

AI agent 改 code 又快又多，人類 review 的頻寬完全跟不上。更麻煩的是有一類 bug 測試根本抓不到：邏輯全對、單元測試全綠，但畫面上獎牌被拉成橢圓：WebKit 對 flex/grid item 的 aspect-ratio 處理與 Chrome 不同，測試全綠、只有 WebKit 壞。

 

所以問題不是「要不要測試」，而是「每一層測試各攔什麼」。

image

第一層：不是靠 AI 自律，是靠 hook 強制

AGENTS.md 寫「每次改完程式都要跑 npm test」沒有用。AI 會忘，就像人會忘。我們把它做成 Claude Code 的 hook：每次 Write/Edit 之後自動跑，失敗就 exit 2 把 AI 擋回去修。再加一個 Stop hook：AI 想收工時再跑一次，測試沒綠不准結束。這兩個 hook 合起來的效果是：AI 根本沒有「跳過測試」這個選項。

{
  "matcher": "Write|Edit",
  "hooks": [{
    "type": "command",
    "command": "out=$(node --test test/*.test.js 2>&1); [ $? -eq 0 ] || { echo 'unit tests failed after edit:'; echo \"$out\" | tail -15; exit 2; }"
  }]
}

單元測試本身刻意極簡：Node 內建 test runner（node --test），不用額外的測試框架，數百個測試案例只測匯出的純函式，不 stub 任何外部服務。因為 hook 每次編輯都要跑，測試套件必須秒級完成。

image

第二層：在真實資料庫上驗證啟動、schema 與 migration

Playwright 的 webServer 設定成等 /health 回應才開跑，而 /health 會真的 ping DB。在 CI 上這代表：mysql:8.0 service container 起來 → dbInit() 對這顆拋棄式 DB 跑一次 schema + migration → /health 回 db:ok → 22 個 smoke spec 才開始。連 migration SQL 都被驗到了，不用另外寫 migration 測試。

第三層：讓 AI 自己「看」畫面

這是本章的重點。前面那個獎牌比例跑掉的 bug 教會我們：有些問題只有透過實際畫面才能發現。所以我們規定 AI 改完 UI 必須用 playwright-cli 開瀏覽器截圖、自己目視確認，截圖產物放 repo 的暫存資料夾，改動大的直接把截圖貼進 PR。

 

比起讓 AI 寫斷言去「猜」畫面對不對，截圖是更誠實的驗證：支援視覺輸入的 AI 可以直接檢查截圖，人類 reviewer 也能在 PR 中快速確認結果。

image

第四層：人類可讀的測試案例，AI 來跑

截圖驗證回答的是「畫面看起來有沒有壞」；自然語言案例回答的是「使用者能不能完成一段有意義的任務」。

 

integration-test/ 放了 14 個分類檔、100+ 條用自然語言寫的測試案例：測試目的、步驟、預期，完全不寫 selector：

## TC-03-01 切換到 English [@smoke]

**測試目的**：選 English 後，整個 UI 文案改為英文並持久化。

**步驟**：1. 開啟 <base-url>/ 2. 點地球圖示 3. 選「English」

**預期**：底部分頁文字變為 Runs、Buddy、Quotes、Brown、Me

/run-integration-tests skill 會讀這些案例、開真實瀏覽器逐條執行、回報 PASS/FAIL。因為案例用「可見文字與操作意圖」描述而非 CSS selector，它同時是給 AI 跑的測試、給人讀的規格、給新成員看的功能導覽。案例用 tag 控成本：@costly（會打付費 API）、@slow、@manual 預設跳過。

這套做法的關鍵，不是要求 AI「記得」測試，而是讓它無法跳過驗證。單元測試、E2E、截圖與自然語言案例各自攔下不同類型的錯誤，也提醒我們：測試全綠，只代表已經定義的斷言通過，並不代表使用者看到的產品一定沒有壞。

Part 3｜跑表紀錄：把 GitHub 變成 AI 的工作系統

GitHub 保存狀態，gh CLI 提供操作，skill 封裝流程，AGENTS.md 補足專案慣例。

對短期、小團隊的 Hackathon 來說，我們不用額外的專案管理工具，直接把 GitHub issue/PR 當工作系統，讓 AI 透過 gh CLI 走完「開單 → 寫 code → 發 PR → review → merge → 關單」整條流程。Hackathon 期間團隊透過這套流程累積了 174 個 PR、170 個 issue，而且因為全在 GitHub 上，事後所有資訊都能用 gh CLI 撈回來分析。

痛點：AI 產出的資訊，散了就沒了

AI 一天可以產出好幾個 PR，但如果工作項記在聊天記錄、便條、腦子裡，兩週的 hackathon 結束時你只剩一堆 code，說不出「做了什麼、為什麼做、還剩什麼」。我們的答案很無聊但有效：全部進 GitHub，全部用 gh CLI 操作：AI 能用 CLI 做的事，就能自動化；存在 GitHub 上的資訊，就能被撈出來。

image

issue 就是 backlog

想到什麼功能，一句話請 AI 開 issue，標題直接用 Conventional Commits 風格（如 feat(gps-art): 跑圖面板提供下載路線 GPX）：開單那一刻就想好了它未來的 commit message。bug 則帶著 prod log 開單存證。label 做分類：bug、tech debt、demo。其中 AI Code Assistant 用來標記 AI 協助產出的 PR，事後可以直接作為 AI 參與的代理指標。

每個環節一個 skill，全域共用

我們把 gh 工作流做成幾個 Claude Code skill，放在全域（~/.claude/skills/）跨 repo 共用；repo 專屬的慣例則寫在 AGENTS.md，skill 執行時會先讀它。分工是：skill 管流程，AGENTS.md 管慣例。

 

Skill

做什麼

核心 gh 指令

create-pr

依 repo 慣例建立並標記 PR

gh pr create

review-pr

分析 diff 並產生分級 review

gh pr diff、gh pr review

codex-review

以第二個 AI 模型進行對抗式 review

gh pr checkout

gh-notifications

將通知分類為「需 review／被指派／CI 失敗」

gh api notifications

幾個有價值的慣例，全部明文寫在 AGENTS.md：

  • Reviewer 對照表：「assign 給 Anderson」→ AI 直接查表執行 gh pr edit <n> --add-reviewer gorockymin，不用每次打 API 查 collaborator。
  • issue ↔ PR 交叉引用：PR body 寫 Closes #152，merge 自動關單；follow-up PR 再引用回去，形成完整因果鏈（#152 開單 → #157 修復 → #161 follow-up，全部可追）。

image

一條龍跑起來長這樣

以真實的 #152 為例：

 

  1. 發現 LIFF 外部瀏覽器登入無限 loop → 請 AI 帶著 prod log 開 issue #152，標 bug
  2. AI 修完 → create-pr skill 發 PR #157，body 寫 Closes #152，標 AI Code Assistant
  3. review-pr + codex-review 兩個 AI 各自 review，發現問題直接留言在 PR 上
  4. squash merge → commit message 自帶 issue 與 PR 雙編號：fix(strava): 修 LIFF 外部瀏覽器登入 loop (#152) (#157) → issue 自動關閉
  5. 早上跑 gh-notifications，看昨晚的 CI 結果與待 review 清單

 

人的主要工作被收斂成兩個決策：做什麼，以及最後收不收；中間大量可重複的操作，則交給 AI 與 gh CLI 執行。

回收紅利：資訊都在，就能整理

因為每個工作項、每次 review、每張截圖都落在 GitHub 上，事後整理的成本就低很多：

gh pr list --state all --limit 200 --json number,title,mergedAt   # 產出週報素材

gh issue list --label 'tech debt' --state open                     # 盤點技術債

gh pr list --label 'AI Code Assistant' --json number | jq length  # AI 參與度

我們用這些資料自動產出每週 PR 統計（merge 數、lead time 中位數），並整理成 retrospective 文件。

這就是「一條龍」的完整意義：skill 負責封裝可重複的流程，AGENTS.md 保存每個 repo 的專屬慣例，而 GitHub 則留下所有工作狀態與因果關係。不只是 AI 幫你走完流程；流程走完後，每個決策、修改與 review 都成為可查詢、可整理、也能繼續交給 AI 使用的資料。

image

Part 4｜最後一棒：非技術 PM 的 AI 協作術——Hackday 90 秒上台的完整幕後

當天才知道的 90 秒

其實在活動開始之前就知道每組只有 90 秒上台，但一直不清楚時間到了之後會發生什麼事：會強制停止嗎？會有警示音嗎？這個不確定性讓「精準控時」這件事變得更重要。7 月 2 日早上確認了活動的進行方式後，這個疑問還是沒有答案，於是決定把時間控制這件事完全掌握在自己手裡。

與此同時，團隊當天下午都還在持續迭代產品，功能還沒完全固定下來。也就是說，上台的報告內容本身也是浮動的。

image

先做 Booth，再做上台

我把任務拆成兩條線：攤位展示影片（Booth Display）和上台報告影片，兩者的目標和限制完全不同。

image

策略是：先完成 Booth Display，在與團隊 review 接近尾聲時，才開始製作上台影片。這樣的順序讓我對產品的理解更深，也讓上台影片的內容選取更有把握。

 

完整的 AI 協作流程

整個製作過程幾乎是全程與 AI 協作完成的。以下是從零到完成的每一個步驟：

image

Step 1 — 餵 AI 讀懂這個產品

我先請 Claude Code 整理三份素材：產品的 codebase、初賽簡報、README.md，要它從中找出產品最核心的亮點。這一步很關鍵：不是讓 AI 憑空發揮，而是給它足夠的上下文，讓產出的內容真的貼近產品現況。

Step 2 — 討論 90 秒的 Rundown

有了產品亮點之後，我開始跟 Claude Code 討論 90 秒的 Rundown 應該怎麼跑。最終決定的結構大致如下：

image

每一頁的「標題」「文字內容」「時間長度」都由 AI 先生成一個草稿，我再調整。這樣不用從空白開始，速度快很多。

Step 3 — 生成口白稿

Rundown 確認後，Claude Code 依照每一頁的內容和對應的時間長度，生成每一段的口白稿。口白稿的原則是：資訊密度高但口語自然，並且在字數上要控制在對應秒數內念完。

Step 4 — 聲音克隆與音檔製作

這是整個流程裡技術選擇最多的一個環節。我評估過幾種方案：

image

所有音檔準備好之後，我請 Claude Code 將所有素材整合進一個可以自動播放的 HTML 檔案。每一頁音檔播完後自動切換到下一頁，並有進度條顯示整體時間進度。

在視覺設計上，讓 HTML 的配色盡量接近產品本身的設計語言：深色背景、Strava 橘作為主色調，並在每個頁面放上對應的關鍵資訊。

Step 6 — 字幕的決策

因為與會者大部分是非英語系母語的日本同事，我一開始同時生成了英文和日文字幕放在畫面上。但實際看起來畫面太過擁擠，資訊互相干擾。



Step 7 — 情境配圖

除了產品介紹頁面使用產品截圖與錄影之外，幾個需要情境圖的頁面（例如 hook 頁面的「等待跑者回家的人」），我使用 Gemini 下 prompt 生成初稿，再以圖改圖的方式調整到想要的效果。這個工作流比直接描述更精準，因為你可以看著圖繼續調。

image

最終完成的 HTML 簡報：開始畫面、技術架構頁、與 LINE × Strava × AI 整合頁。共 9 頁，總長度精確控制在 90 秒以內。

開發過程踩到的坑

製作過程中主要遇到兩個問題：瀏覽器自動播放造成音畫不同步，以及現場播放設備與 MacBook Air 不相容。以下整理問題發生的原因與解法：

image

這次使用的 AI 工具組合

Claude Code

主要的協作夥伴。討論報告結構、生成口白稿、撰寫與調整 HTML、Debug。

Voicebox

聲音克隆工具。用自己的聲音訓練模型，再生成每一頁的音檔（.m4a）。

Gemini

情境圖生成。下 prompt 生成初稿，再以「圖改圖」方式調整到目標樣式。

反思與給下次的建議

  1. 一頁一段音檔是對的選擇。在產品還在迭代時，任何一頁內容的修改只需要重新生成那一段音檔，成本極低。如果用整段錄音，任何一個地方修改就要整段重來。
  2. 先完成 Booth Display 再做上台影片。這個順序讓你對產品的理解更完整，上台影片的內容選取也更有把握。兩個影片目標不同，不要混在一起做。
  3. 字幕要選一種。英文和日文字幕同時出現，畫面太擠，反而沒有一個能被好好閱讀。確定主要觀眾再決定保留哪一種。
  4. 如果日本同事比例高，下次試試日文配音 + 英文字幕。讓日本同事在母語中聽，搭配英文字幕服務其他語言觀眾，接受度可能更好。
  5. 把成品放進 repo 管理。用 PR 的方式交接到隊友電腦這件事，意外地讓整個流程變得更清楚，每一次修改都有記錄，也方便多人協作。
  6. 先餵 AI 足夠的上下文，再請它發揮。直接請 AI 「寫一個 Hackday 簡報」產出品質很低。先讓它讀 codebase、README、舊簡報，理解產品之後，產出品質會有顯著差異。

對非技術 PM 來說，AI 協作的意義

在整個準備和競賽的過程中，因為有了 AI 協作，讓非技術背景的我可以更好地跟上技術夥伴的節奏。

我不是工程師，不具備獨立撰寫 HTML、訓練聲音模型與設計動畫的能力。但在這次 Hackday 裡，我仍然完成了這些工作：靠的是和 AI 的持續對話。

這不是說「AI 幫你做完所有事」。更準確的描述是：AI 把我的想法轉換成可執行的產出。我知道我想要什麼（90 秒、節奏精準、一頁可抽換）、我知道哪裡不對（字幕太擠、音檔不同步），而 AI 提供了把想法落地的路徑。

對非技術背景的 PM 來說，AI 協作最大的價值不是「速度」，而是降低了參與技術決策的門檻。你可以討論架構、討論取捨、實際跑出一個可以被人看到的成品，而不只是在旁邊看著隊友做。

Part 5｜抵達終點：配速結語

image

  1. 從「腦力激盪」到「多層驗證」，再到「gh CLI 一條龍」，這三個工程實踐本質上是同一件事：把 AI 該做的判斷、驗證、記錄提前變成明確的介面與規則，讓「做完了沒」不再靠感覺，而是靠 hook 強制測試、截圖目視驗證、issue/PR 交叉引用這些看得到的證據。
  2. 多層驗證（單元測試 hook、E2E、截圖、自然語言案例）與一頁一音檔是同一個原則的兩種實踐：把不可逆、高成本的整體改動拆成可獨立重做、可局部驗證的小單位，才能在時間壓力下持續迭代而不崩潰。
  3. 無論是前端經驗較少的工程師，還是不寫程式的 PM，AI 協作真正降低的不是「做出來的時間」，而是「參與決策與動手做的門檻」。這是這次 Hackday 四段記錄——腦力激盪、多層驗證、GitHub 工作流與簡報製作——共同指向的結論。 

 

這篇文章記錄的是一次讀懂程式碼、也讀懂身體的 Hackday。希望對同樣想跑進這個模式的你有幫助。