弄一下工作室
課程專屬講義
請輸入課程密碼
生成式AI職訓實務應用班
CH 5.2 · Part 5
返回課程總覽
Part 5 · 前端與部署實戰
CH 5-2 · 3h
課堂 3h · 自學 2h

與 AI 協作改頁面,而不是盲貼程式碼

「它把我精心設計的 Hero 區塊也一起重構了。」——這是學員崩潰的爆雷現場。要讓 AI 只動你要它動的地方,指令必須拆成「位置 + 意圖 + 限制」三要素:少哪一個,它都會自作主張地順手動別處。

學習成果 · OUTCOMES
能將頁面改版需求拆解成具體、可執行的 AI 指令,包含位置、意圖與限制三個要素
知道如何對 AI 指定修改範圍,避免它「改過頭」動到不該動的區塊
能用結構化方式描述 bug,讓 AI 快速定位問題並提出可用的修復方案
了解 Cursor、GitHub Copilot、Claude Code 各自的使用場景,知道什麼時候選哪個工具
RECAP · 上一節帶走的
能讀懂 HTML / CSS / JS 讓你有判斷 AI 生成程式碼品質的基本能力——看得懂,才知道哪裡不對。
PREVIEW · 這節解決什麼
讓 AI 只改你要改的地方很難。這節教你把改版需求拆成精準指令,不再改了這裡壞了那裡,每次修改都有效。
(01) · Decompose

拆解需求:從「我想要...」
AI 能執行的指令

「幫我讓這個頁面更好看」——這是最容易讓你崩潰的 AI 改版指令。它會順便動字型、換顏色、調整體排版,然後你發現它把你精心設計的 Hero 區塊也一起重構了,三十分鐘的設計工作五秒鐘被改沒。

問題不在 AI,而在指令。AI 沒有你腦子裡的那個頁面樣貌——它只能根據你給的描述推斷你的意圖。描述越模糊,AI 的「自由發揮」空間越大。

好的 AI 改版指令有三個要素:位置意圖限制。缺一不可。
01
位置
指定要改的是哪個元素、哪個區塊。用 CSS class、HTML 標籤或描述性的結構名稱都行。
02
意圖
說清楚你要達到什麼視覺或功能效果。「更大」「更明顯」不夠——要說「從 16px 改到 20px」或「讓按鈕在頁面上更突出」。
03
限制
說明什麼地方不能動。這是最常被省略卻最重要的部分——它幫 AI 設定邊界,防止過度修改。

把這三個要素組合起來,就能寫出有效的改版指令:

模糊指令(容易出錯)
「幫我改一下這個頁面的設計」
「讓按鈕更好看」
「把顏色調整一下」
「標題字體改大一點」
精準指令(位置+意圖+限制)
「只修改 .hero 區塊,把標題從 32px 改成 40px,其他不動」
「.submit-btn 的背景色從 #999 改成 #2a7a5a,只改這一個按鈕」
「nav 連結的顏色統一改成 #333,保持原有 hover 效果不變」
「.card-title 的 font-size 從 1rem 改成 1.15rem,不改其他 card 樣式」
從視覺到語言的轉譯練習:看到頁面上某個你不滿意的地方,試著用「位置+意圖+限制」三要素描述它。這個練習做幾次之後會變成直覺——你會越來越快地把視覺感受翻譯成可執行的文字指令。

迷你練習 1 約 10 分鐘
把一句模糊需求改寫成 AI 能執行的指令

「幫我改一下」是命令 AI 最糟的方式。練習用「目標 + 位置 + 範圍 + 驗收」四段式改寫一個你當下想改的需求。

1挑一個你真的想改的頁面(自己課程筆記、履歷、Notion 導出),寫下「模糊版」需求一句
2用四段式改寫:① 我想達成什麼 ② 改哪個區塊(class/id/位置) ③ 不要動到什麼 ④ 成功長怎樣
3把兩版都丟給同一個 AI,比較產出差異
範本素材 先用這組現成的「模糊版 vs 結構化版」跑一次 AI,感受差異後再換成你的情境
原始素材 · 某活動頁片段(約 170 字)貼進 Prompt 最下方
<section class="hero-event"> <h1 class="event-title">2026 春季開放日</h1> <p class="event-date">4 月 26 日(日) 14:00 – 17:00</p> <p class="event-loc">台北市大安區某活動空間</p> <a class="btn-signup" href="#form">立即報名</a> </section> <style> .hero-event{background:#fff;padding:48px 32px;text-align:center} .event-title{font-size:1.8rem;font-weight:700;margin-bottom:16px} .event-date,.event-loc{font-size:.95rem;color:#7a766d;margin-bottom:8px} .btn-signup{display:inline-block;margin-top:20px;background:#6b7fa3;color:#fff;padding:12px 28px;border-radius:4px;text-decoration:none} </style>
範例 Prompt · 四段式結構化指令可直接貼 ChatGPT / Claude
你是資深前端工程師,對「最小改動達成目標」有堅持,不會順手重構其他東西。 溝通風格:只回增補的 CSS 片段,不貼整段 HTML、不改不相干的類別、不引入任何 framework。 任務:用「目標 + 位置 + 範圍 + 驗收」四段式指令,改下方活動頁的「立即報名」按鈕樣式。 目標:把「立即報名」按鈕視覺權重拉到最顯眼,引導點擊,同時保留既有主色系不偏離品牌 位置限定:只能改 .btn-signup 與它的 :hover、:focus-visible 以及 @media 內相關宣告 禁止動到: 1. .hero-event 的 background 與 padding 2. .event-title 的字級與字重 3. 主色 #6b7fa3(可加深、可做 hover 變體,但不得換色系) 4. HTML 結構(不新增元素、不改 class 名稱) 驗收條件(每條都要自己驗過): 1. 桌機版按鈕視覺面積約現在的 1.3 倍,但寬度不超出 .hero-event 的內距邊界 2. hover 有明顯反饋:背景加深或加 outline,transition ≤ 0.2s 3. 鍵盤 tab focus 時有 focus-visible outline(無障礙必備) 4. 行動版(max-width:480px)不可超出螢幕、不可被截斷 輸出限制: - 只回傳修改後的 CSS 片段(≤ 10 行) - 最後附 1 句改動說明,講「為什麼這樣改」不是「你改了什麼」 - 不解釋 CSS 基礎、不貼整段 HTML --- 【任務素材】 原始素材(貼在這一行下方):
預期輸出片段(供對照)
.btn-signup{padding:16px 40px;font-size:1.05rem;font-weight:500;transition:background .18s}
.btn-signup:hover{background:#5a6d8f}
@media(max-width:480px){.btn-signup{padding:14px 28px;font-size:1rem}}
改動說明:只放大按鈕內距與字級、加 hover 深色、手機版限制尺寸。
成果產出
一組對照:「模糊版 vs 結構化版」指令文字,以及 AI 兩次產出的 diff(哪一個離你想要的更近)。
自我檢核
RUBRIC · 自評檢核(4 點全勾才算過關)
REFLECTION · 你的答案
你在 AI 協作開發中,最常被忽略的一個需求細節是什麼?(例如:沒說手機版、沒說顏色代碼、沒說要保留哪段原本的程式碼)
(02) · Scope Control

範圍控制:只改這裡,不動其他地方

即使你的指令有位置、意圖、限制,AI 有時仍會「改過頭」——特別是當你把整份程式碼貼給它時。AI 看到的是完整的 context,它的訓練讓它傾向於「提供全面改善」,而不只是點對點修改。

三個技巧可以有效控制修改範圍:

技巧一:只貼你要改的那段程式碼
貼出 .hero 的 CSS,而不是整份 style
AI 看不到其他部分,自然無法「順手改掉」。當你提問時,從 DevTools 或檔案裡複製對應的片段貼入即可。
技巧二:明確聲明不動的範圍
「除了我列出的部分,其他 CSS 保持原樣,不要重構」
在指令結尾加上這句話,相當於給 AI 設置一道防護欄。不需要每次都精確列出所有不能動的地方,一句「其他保持原樣」就夠了。
技巧三:要求 AI 只回傳差異,不回傳全文
「只給我要修改的那幾行,不要貼出完整檔案」
這讓你更容易辨認 AI 改了什麼,也避免你在複製貼上時不小心覆蓋掉你自己的其他修改。

實際操作的情境:你想改頁面上的一個按鈕顏色,但不想動按鈕的大小、圓角和 hover 效果。以下是典型的指令示範:

PROMPT 精準範圍指令範例
我想修改這個 CSS 片段中 .btn-primary 的背景顏色,
從 #6b7fa3 改成 #5a7a5a。

只改 background 這一個屬性。
border-radius、padding、font-size、hover 效果都不要動。
只回傳修改後的 .btn-primary 規則,不要貼出其他 CSS。

---
.btn-primary {
  background: #6b7fa3;
  color: #fff;
  border: none;
  border-radius: 6px;
  padding: 10px 20px;
  font-size: .9rem;
  cursor: pointer;
}
.btn-primary:hover {
  background: #5a6d8f;
}
核心原則:你給 AI 的上下文決定了它能「看到」什麼、能影響什麼。控制你貼進去的內容,就是控制 AI 的修改邊界。這不是技巧,是工作習慣。

(03) · Debug

Bug 修復:用結構化語言讓 AI 找到問題

「這個按鈕點了沒有反應」——這是最常見的 bug 回報方式,也是讓 AI 最難幫你的方式。AI 需要知道:它哪裡沒反應?你期待它做什麼?什麼情況下才會沒反應?

一個有效的 bug 描述由三個部分組成:

現象
你實際觀察到的行為。盡可能具體:「點了沒有反應」「點擊 #submit-btn 後頁面沒有任何變化,沒有顯示結果,也沒有錯誤提示」
預期
你期待應該發生什麼。「應該要在 #output 區塊顯示使用者輸入的文字」
觸發條件
什麼時候、什麼情況下會發生這個問題。「每次點擊都這樣,不是偶發」或「只有在輸入框為空時才會這樣」

把這三個要素組合成一段問題描述,再附上相關的程式碼片段,AI 解決問題的成功率會大幅提升:

PROMPT 結構化 bug 描述範例
現象:點擊 id="submit-btn" 的按鈕之後,頁面完全沒有反應。
預期:應該要把 id="user-input" 的輸入值顯示在 id="output" 的段落裡。
觸發條件:不論輸入框有沒有內容,每次點擊都沒有反應。

以下是我的 JavaScript,請找出問題並告訴我哪裡出錯,
然後只修改有問題的地方:

document.getElementById('submit-btn').onclick = function() {
  let value = document.getElementById('user-input').val();
  document.getElementById('output').textContent = value;
};
善用 Console 錯誤訊息:打開瀏覽器的開發者工具(F12),點 Console 標籤,然後重現 bug。如果有紅色錯誤訊息,直接複製貼進你的 AI 問題裡。Console 錯誤通常包含檔案名稱、行號和錯誤類型,是 AI 定位問題最快的線索。

進階技巧:當你不確定 bug 的原因,可以先請 AI 解釋邏輯,不要急著要它修改。「請逐行說明這段 JavaScript 在做什麼」——這讓你先理解程式流程,再判斷哪裡和你的預期不符,最後才針對性地要求修復。

1
讓 AI 解釋「請逐行說明這段程式碼在做什麼」——先建立你對程式流程的理解
2
定位差異「這裡的邏輯和我的預期不符」——找到問題所在的步驟
3
針對性修復「只修改第 3 步的部分,其他保持不變」——精準修復,不引入新問題
避免「修了又壞」的循環:不要直接貼整份程式碼讓 AI「全面修復 bug」。這容易讓 AI 為了解決一個問題而修改了其他正常的部分,結果修了一個 bug 又引入兩個新問題。保持「最小範圍修改」的原則。

迷你練習 2 約 12 分鐘
寫一份「會讓 AI 找到問題」的 bug 報告

大部分人 debug 失敗不是 AI 不行,是描述太糊。練一次「重現步驟 + 預期 + 實際 + 環境 + 控制台訊息」的完整回報格式。

1找一個你過去遇過、沒解掉的 bug(任何軟體都可以)
2用 5 段式寫:① 我做了什麼步驟 ② 我預期發生什麼 ③ 實際發生什麼 ④ 用什麼瀏覽器/作業系統 ⑤ 控制台有什麼紅字
3丟給 AI,觀察它會不會先反問還是直接跳到答案
4如果 AI 沒反問就直接猜,代表你的描述夠清楚
範本素材 沒有自己的 bug?先用這段會壞的 JS 練一次,完整走完流程
原始素材 · 含 bug 的 JS 與 Console 紅字(約 230 字)貼進 Prompt 最下方
// HTML 結構 <input id="user-input" placeholder="輸入文字"> <button id="submit-btn">送出</button> <p id="output"></p> // JS(按下送出後什麼都不會出現) document.getElementById('submit-btn').onclick = function () { let value = document.getElementById('user-input').val(); document.getElementById('output').textContent = value; }; // Console 訊息 Uncaught TypeError: document.getElementById(...).val is not a function at HTMLButtonElement.onclick (index.html:42:52)
範例 Prompt · 五段式 bug 報告可直接貼 ChatGPT / Claude
你是資深前端 debug 夥伴,專長是從簡短的 Console 錯誤訊息定位到最小修改點,拒絕重寫一堆不相關的程式碼。 溝通風格:先給結論(錯在哪),再給最小 diff,不貼整段、不加額外功能、不順手重構。 任務:我要回報一個 bug,請根據下方五段式資訊判斷原因,並給可直接貼的最小修改。 ① 重現步驟:在輸入框打「測試」,點「送出」按鈕 ② 預期:<p id="output"> 顯示「測試」兩個字 ③ 實際:畫面完全沒變化,output 仍是空的 ④ 環境:Chrome 135 on macOS 15,純靜態 HTML(無任何 framework、無 jQuery) ⑤ Console:紅字 TypeError: ... .val is not a function(行號 42) 步驟: 1. 用 1 句話說「錯在哪」(要點出是哪個 API 不存在,不要只說「有錯」) 2. 給最小 diff(`- 刪除行 / + 新增行` 格式,只動問題那一行) 3. 檢查有沒有第二個潛在問題(例:空字串、race condition),有就分開列出並給建議修改 輸出限制: - 不要教 DOM 基礎、不要推薦用 jQuery(故意不用) - 不要貼整段 HTML 或整段 JS,只貼要改的那幾行 - 不要加 try / catch 包整段(小修就好) - 用 Markdown 編號回答、diff 放在 code block --- 【任務素材】 原始素材(貼在這一行下方):
預期輸出片段(供對照)
錯在哪:.val() 是 jQuery 的 API,原生 DOM 的 input 元素要用 .value 屬性(沒有括號)。Console 的 TypeError 就是在說「這個物件上沒有 val 這個 function」。
最小修改(diff):
- let value = document.getElementById('user-input').val();
+ let value = document.getElementById('user-input').value;
第二個潛在問題(不 crash 但體驗差):
沒處理空字串,建議改為
const raw = document.getElementById('user-input').value.trim();
if (!raw) return; // 空字串就不輸出

對照重點
1. 看 TypeError 要先找「X is not a function」前面那個物件是什麼(這裡是 input 元素)——這是定位 bug 的關鍵動作
2. 不要看到 jQuery 寫法就整個改成 jQuery,原生 DOM 改回 .value 就好、不新增依賴
3. 空字串檢查要用 .trim() 後再判斷,否則只有空白字元會被誤判為有效輸入
成果產出
一份 5 段式 bug 報告範本,加上 AI 對它的第一次回應(存下來之後當模板用)。
自我檢核
RUBRIC · 自評檢核(4 點全勾才算過關)
(04) · Tools

工具選擇:Cursor / Copilot / Claude Code
各自適合什麼

AI 協作開發工具不只一種,而且每種工具的設計哲學不同。了解它們的差異,能幫你選到最適合當下任務的工具,而不是用同一個工具做所有事。

工具 互動方式 最適合的場景 限制
Cursor 編輯器內嵌 你已有一個專案,需要在編輯器裡直接修改程式碼。AI 能看到完整的專案結構和多個檔案,適合跨檔案的修改與重構。 需要安裝桌面應用程式;對初次使用者有一定的設定成本。
GitHub Copilot 打字補全 你邊寫邊想,需要即時的程式碼補全建議。適合有基礎但需要加速的開發者,在 VS Code 或 JetBrains 裡直接運作。 是補全工具而非對話工具;不適合「解釋這段程式碼」這類需求。
Claude Code 對話式 你不想打開編輯器,或需要大量解釋說明。適合用自然語言描述需求、一次性修改特定檔案、或需要 AI 說明程式邏輯。 需要透過指令介面操作;對習慣 GUI 的使用者有學習曲線。
選擇原則:不要同時用多個工具,先選一個熟。大多數人從 Claude Code 入門最順——對話介面直接,不需要安裝設定,而且本課程的其他單元也都在這個環境裡操作。等你對「怎麼跟 AI 說話」有了感覺,再考慮是否切換到 Cursor 或 Copilot。

工具本身不是瓶頸,你描述需求的能力才是。這節課的位置、意圖、限制三要素,以及範圍控制和 bug 描述的方法,在任何 AI 工具上都通用。學好這些方法,換工具只是換介面,不是換技能。

「盲貼程式碼」是把 AI 當成黑盒子;「協作改頁面」是把 AI 當成你的執行夥伴——你負責判斷和決策,它負責實作。

掌握了這節課的方法,你已經能夠有效地讓 AI 幫你修改現有頁面。接下來的 CH5-3 和 CH5-4,我們要解決另一個問題:改到壞掉了怎麼辦、改好了放到哪裡讓別人看到?

📦
CH 5.3 · 下一節
Git 與版本保存——改錯了也能回到上一步
🚀
CH 5.4 · 之後
含後端服務的完整部署——讓你的頁面有個公開網址
迷你練習 3 約 10 分鐘
為自己選一套「主力 + 次要」AI 編碼工具組合

Cursor、Copilot、Claude Code、ChatGPT Canvas 各有適合的情境。做一次明確選擇,之後遇到需求不再猶豫用哪個。

1列出你未來 1 個月最常會改的東西(課程網頁?Notion 嵌入?小腳本?)
2對照本節表格,挑一套「主力工具」(每天用)+「次要工具」(特殊情境才開)
3寫下「什麼情境我會切換到次要工具」的判斷規則 2-3 條
範本素材 先用這份「使用者畫像」讓 AI 推薦一組,再對照你自己的狀況微調
原始素材 · 使用者情境描述(約 210 字)貼進 Prompt 最下方
身份:課程講師 + 內容工作者 技術底:會改 HTML/CSS,不太會寫 JS 現有工具:平常用 VS Code 開 markdown、很少打開專案資料夾 未來 1 個月預計常改: - 課程網頁 4-5 個單元(靜態 HTML 單檔) - Notion 嵌入用的小 HTML widget - 給學員的一頁式報名頁 偏好:介面越簡單越好、能對話說需求就不要裝外掛 預算:ChatGPT Plus 已訂、可考慮再加一個 痛點:改一個小地方經常被 AI 重寫整份,不知道怎麼框範圍
範例 Prompt · 推薦主力 + 次要工具可直接貼 ChatGPT / Claude
你是資深 AI 編碼工具顧問,服務對象是「不寫程式但經常需要請 AI 改程式」的知識工作者(課程講師、內容創作者、行銷人員)。 溝通風格:推薦帶決定性,不說「看情況」「都可以試試」這種模糊話;拒絕推薦最流行的,優先推薦「最適合這個人今年會用到的」。 任務:根據下方使用者描述,在 Cursor / GitHub Copilot / Claude Code / ChatGPT Canvas 四個選項中,推薦「主力 1 個 + 次要 1 個」的工具組合。 步驟: 1. 先用一句話總結這個使用者的關鍵特徵(技術底、任務型態、最痛的點) 2. 主力工具:名稱 + 3 點理由(對應到他的具體任務)+ 1 點限制 3. 次要工具:名稱 + 3 點理由 + 1 點限制 4. 寫 2-3 條「什麼情境我會切到次要工具」的判斷規則,要具體到可直接執行(例:「單檔超過 300 行時」),不要寫「感覺不順時」這種主觀詞 5. 最後給 1 句收尾:主力工具的第一週該做 1 件什麼事熟悉它(具體到動作) 輸出限制: - 格式:Markdown 條列 + 粗體工具名 - 不要把 4 個工具全部分析一遍,只推 2 個 - 不要寫「可能」「或許」「建議試試看」,要果斷 - 總字數 ≤ 350 字 --- 【任務素材】 原始素材(貼在這一行下方):
預期輸出片段(供對照)
關鍵:單檔靜態 HTML 為主、怕被 AI 重寫整份、不想裝編輯器外掛
主力:Claude Code|對話介面、可以只貼片段、能嚴格指定「只改這段」
次要:ChatGPT Canvas|適合 Notion widget 這種一次性短片段
切換規則:
1. 需要跨 3 個檔案以上的修改 → 切 Cursor 試用
2. 單檔但超過 300 行 → 切 Claude Code 分段改
3. 只想產 20 行以內片段 → 留在 Canvas
成果產出
一段筆記:「主力=X(理由)|次要=Y(使用時機)」;貼在常用的工作筆記最上方。
自我檢核
RUBRIC · 自評檢核(4 點全勾才算過關)
SOLO · 自我演練
把你剛寫的需求描述(請 AI 改哪裡)放在手邊;開新對話請 LLM 扮「龜毛的資深 PM」,把每個「好一點」「更好看」「比較順」這類模糊字眼挑出來,要求你給可量測的替代版本(顏色 hex / 間距 px / 行高比例)。修出 v2 需求描述。
12 分鐘(演練 8 分 + 修 v2 需求 4 分)
進階選配 · 不計入課程時數(給想加練的學員)
把 LLM 對話截圖存到學習資料夾,或貼到工作群組/社群求 review。這些痕跡在轉職投履歷時可作為作品集素材。
RESULT COMPARE · 三模型對打:AI 協作開發需求描述誰理解最準?
把以下需求描述分別貼給 ChatGPT、Claude、Gemini, 請它們直接生成對應的 HTML/CSS 程式碼: 請幫我寫一個簡單的倒數計時器網頁,需求如下: - 使用者可以輸入分鐘數(1-60) - 按「開始」後開始倒數,畫面顯示剩餘時間(MM:SS 格式) - 時間到時播放一聲提示音(用 Web Audio API,不要用外部音效檔) - 按「重設」回到初始狀態 - 手機和電腦都要好看(響應式設計) - 整體風格:簡潔、深色背景、白色文字 只輸出完整的單一 HTML 檔案(含 CSS 和 JS),不要解釋。

課堂即時作業 · Assignment · Part 5 跨章 v2 ⏱ 核心 25 min + 進階 15 min

用 AI 把作品集 v1 升級成 v2(bug fix + 互動 + 範圍控制)

延續 CH5-1 — 你做了個人作品集 v1(純 HTML/CSS)。今天升級成 v2:用 AI 修 bug + 加互動,但不能改過頭動到不該動的地方。這是 AI 協作開發的核心:範圍控制

本作業拆解
核心 25 min(必做):對 v1 跑 UX 稽核 + 列 bug 清單(5 min)+ 寫結構化 bug 報告(10 min · mini-prac 2)+ 用 AI 加 1 個互動功能(10 min · mini-prac 1 範圍控制)
進階 15 min(可選 · 二選一):路線 A — Cursor / Copilot / Claude Code 三家工具實測(同一需求各跑一遍對比)|路線 B — 寫「v2 → v3 上線清單」給 CH5-3 用

v1 升級 v2 規格 · Materials
v2 必加的 1 個互動功能(從以下選 1): 1. Smooth scroll navbar:點 nav 連結滑順捲到對應 section 2. Project filter:作品區用 tag 過濾(前端 / 設計 / 行銷) 3. Dark mode toggle:右上角按鈕切換深淺色 4. Scroll reveal animation:section 進入視窗時 fade-up 結構化 bug 報告模板(mini-prac 2 學的): ``` 【Bug 標題】(1 句話描述:什麼 + 哪裡 + 預期 vs 實際) 【觸發步驟】 1. ... 2. ... 3. (第幾步看到 bug) 【預期行為】(應該怎樣) 【實際行為】(現在怎樣,含 console error 訊息如有) 【影響範圍】(只此頁?跨頁?跨瀏覽器?) 【修復建議】(如有想法) ``` 範圍控制要求(mini-prac 1 學的): 對 AI 下指令時要明示「只改 X,不要動 Y」,例如: - 「請只在 `<section id="projects">` 內加 filter 功能,不要動 hero 與 about 兩個 section 的任何 HTML 與 CSS」 - 「請只新增 JS 與 CSS,不要修改既有的 HTML 結構
交付清單 · Tasks
  1. 核心 1:UX 稽核 v1 + 列 bug 清單(5 min)— 對 CH5-1 你的 v1 做 7 項 UX 稽核(沿用 CH4-2 的)+ 列 3-5 個 bug 或可改進處
  2. 核心 2:寫結構化 bug 報告(10 min · mini-prac 2)— 挑 1 個最重要的 bug,套用上方模板寫完整 bug 報告(觸發步驟具體 + 預期 vs 實際清楚 + 修復建議)
  3. 核心 3:用 AI 加 1 個互動功能(10 min · mini-prac 1)— 從 4 個互動候選選 1,寫 prompt(含明確範圍控制句)給 AI,跑出 v2。驗收:互動功能能跑 + v1 的 4 個區塊內容完全沒變
  4. 進階路線 A:Cursor / Copilot / Claude Code 三家實測同一需求,比較哪家「範圍控制最準」「修 bug 最快」
  5. 進階路線 B:寫「v2 → v3 上線清單」(5-8 條)— 包含上線前要修的 bug、要加的 README 內容、Git commit 策略,CH5-3 會用
評分標準 · Rubric(基本 4 條)
  • bug 報告含 5 要素:標題 / 觸發步驟 / 預期 / 實際 / 影響範圍,缺一不可
  • 觸發步驟可重現:別人照著步驟做能看到一樣的 bug,不能寫「網站怪怪的」
  • 範圍控制有效:v2 加的互動功能在指定 section 內運作,v1 內容沒被改
  • v2 真的能跑:互動功能可實際操作(不是只在 console.log 看到)
📖 展開參考解答(以「Project filter」為例)
核心 2 · bug 報告範例 ``` 【Bug 標題】手機版 hero 區塊 CTA 按鈕被導覽列遮住 50% 【觸發步驟】 1. 用 iPhone 14 Pro 開瀏覽器(Safari) 2. 訪問 v1 網址 3. Hero 區塊載入時,CTA 按鈕「看作品」上半部被 sticky navbar 遮住 【預期行為】CTA 按鈕應完整顯示在 navbar 下方 【實際行為】CTA 按鈕被遮住約 24px(navbar 高度),按下時要往下捲一點才能準確點到 【影響範圍】所有 < 768px 的行動裝置;桌面版正常 【修復建議】Hero 的 padding-top 加上 navbar 高度(約 60px),或用 scroll-margin-top: 60px ``` 核心 3 · 範圍控制 prompt 範例 ``` 請在我的個人作品集網站加一個 Project Filter 功能: 【範圍控制 — 重要】 - 只在 `
` 內加 filter UI 與 JS 邏輯 - 不要動 hero、about、contact 三個 section 的任何 HTML 與 CSS - 不要修改 navbar 或 footer - 新增的 CSS 只放在 `