DigiHouse
繁體中文

TECH ARTICLE · 5 MIN READ

Blog / DigiHouse

W9|期中 Pitch、Demo 與修正計畫

W9 完整三小時成果活動:依 12+6 分鐘節奏發表、收集可行動回饋,當天轉成下一階段修正計畫。

本週完成成果

你會完成期中 Pitch 與 Live Demo,也會練習當場記錄評審回饋、分辨事實與建議,並把回饋轉成有負責人與期限的修正計畫。

完成標準|每組依 12 分鐘 Pitch+6 分鐘 Demo/問答完成;midterm_feedback.md 包含原話摘要、分類、採納判斷、行動與負責人。

課前準備

步驟 1|上台前:由計時員確認簡報 PDF、Demo、備援與 Repo README 都能從同一台設備開啟。

預期結果|不需登入私人帳號或臨時尋找檔案。

步驟 2|小組:開啟 midterm_feedback.md 範本,指定一人只負責記錄,不邊辯解邊漏記。

markdown
# W9 期中回饋

| 回饋摘要 | 類型 | 我們的判斷 | 下一步 | 負責人/期限 |
|---|---|---|---|---|

預期結果|表格可在發表後立即填寫。

步驟 3|全班:確認評分與提問規則,回饋聚焦問題、證據與改進,不評論個人特質。

預期結果|每位同學知道可提問範圍與時間。

完整三小時|成果活動與回饋

故事開始|Demo 結束後,評審說「使用者可能不願意每天輸入這麼多資料」。有人立刻回答「不會啦」。但這句話其實是一份免費的測試題:到底要輸入多少?使用者願不願意?下一階段可以驗證。

老師先問|評審說的都要照做嗎?不一定。先分辨它是觀察、疑問、建議還是新需求,再看是否符合本組目標與證據。

生活比喻|回饋像醫生檢查報告,不是成績單上的人格評價;我們要找症狀、證據與下一個檢查,而不是只收下「很好」或「不好」。

先看全程地圖|先看懂資料與決策怎麼移動,再開始操作。圖中的箭頭代表下一步,不代表可以跳過人工確認。

text
┌──────────┐ → ┌──────────┐ → ┌──────────┐
│ 12 分鐘 Pitch│  │ 6 分鐘 Demo│   │ 評審提問  │
└──────────┘   └──────────┘   └────┬─────┘
                                    ↓
┌──────────┐ ← ┌──────────┐ ← ┌──────────┐
│ 修正計畫  │   │ 採納判斷  │   │ 原話摘要  │
└──────────┘   └──────────┘   └──────────┘

步驟 4|發表:主講依故事線進行,計時員在剩餘 3 分鐘與 1 分鐘時提示。

預期結果|12 分鐘內完成核心論點,不挪用 Demo 時間。

步驟 5|Demo/問答:先說要證明的事,再操作;失敗時依備援說明,不隱瞞。

預期結果|觀眾知道預期、實際與限制三者。

步驟 6|下台後十分鐘:記錄員與團隊對照筆記,把回饋標為問題證據、產品建議、技術風險、商業假設或表達方式。

markdown
- [ ] 問題證據
- [ ] 產品建議
- [ ] 技術風險
- [ ] 商業假設
- [ ] 表達方式

預期結果|每則回饋只有主要分類,仍保留原意。

步驟 7|小組決策:為每則回饋選擇採納、先驗證、延後或不採納,並寫一句理由。

預期結果|不採納也有依據,不把不同意者刪除。

課堂收束|每組只挑三個下一步:一個本週能改、一個要找使用者驗證、一個屬長期風險。修正計畫不是把所有意見塞進下一版。

指定閱讀與課後作業

指定閱讀|本週為完整三小時期中成果活動,課綱未另列技術指定閱讀;請回看評審紀錄與本組 GitHub 證據。

課後作業方向|完成 midterm_feedback.md,讓未到場的組員也能看懂發生什麼、為何採納,以及第二階段誰在何時做什麼。

步驟 8|小組:把三個最高優先行動寫成可驗收句子,補上 owner 與期限。

預期結果|避免「優化 UI」;改寫成「週五前讓三位同學完成核心流程並記錄卡住步驟」。

步驟 9|小組:提交回饋檔並在 commit 訊息標明 second-stage plan。

bash
git add midterm_feedback.md
git commit -m 'W9: record feedback and second-stage plan'
git push

預期結果|GitHub 有完整回饋與下一步,但不包含評審私人聯絡資料。

驗收方式

bash
test -s midterm_feedback.md
rg -n "負責人|期限|採納|驗證" midterm_feedback.md
git log -1 --oneline

通過條件|回饋有分類與原意;至少三項行動具負責人、期限與驗收方式;最新 commit 可追蹤。

應提交的 Repo 檔案

必交|midterm_feedback.md。只提交課綱指定成果與重現所需說明;不得提交 API key、個資、私人對話、未授權資料或大型模型檔。

常見問題與排除

問題 1|只記「很棒」或「要加強」:追問具體是哪一頁、哪個流程或哪項證據。

問題 2|團隊急著辯解:先完整記錄,確認理解後再說明背景。

問題 3|行動太多:依影響與驗證成本排序,只承諾下一階段真的做得到的項目。

引用資料

國立中央大學授課課綱/劉書銘老師,《劉書銘老師課程大綱_基礎模型與生成式人工智慧-更新版.pdf》;教師提供附件。用途:W1–W16 時段、實作主題、評量與交付物。

GitHub Docs,《Quickstart for reviewing pull requests》;https://docs.github.com/en/pull-requests/get-started/reviewing-pull-requests-quickstart;查閱日期:2026-08-04。用途:W3 Code Review 留言、建議、核准與要求修改。