← 返回課程總覽
與 AI 協作改頁面,而不是盲貼程式碼
「它把我精心設計的 Hero 區塊也一起重構了。」——這是學員崩潰的爆雷現場。要讓 AI 只動你要它動的地方,指令必須拆成「位置 + 意圖 + 限制」三要素:少哪一個,它都會自作主張地順手動別處。
學習成果 · OUTCOMES
能將頁面改版需求拆解成具體、可執行的 AI 指令,包含位置、意圖與限制三個要素
知道如何對 AI 指定修改範圍,避免它「改過頭」動到不該動的區塊
能用結構化方式描述 bug,讓 AI 快速定位問題並提出可用的修復方案
了解 Cursor、GitHub Copilot、Claude Code 各自的使用場景,知道什麼時候選哪個工具
(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(哪一個離你想要的更近)。
自我檢核
結構化版有明確指出「改哪、不動哪」
寫出至少一條驗收條件(例如「手機版也要正常」)
能說出模糊版失敗的原因
REFLECTION · 你的答案
你在 AI 協作開發中,最常被忽略的一個需求細節是什麼?(例如:沒說手機版、沒說顏色代碼、沒說要保留哪段原本的程式碼)
(02) · Scope Control
範圍控制:只改這裡 ,不動其他地方
即使你的指令有位置、意圖、限制,AI 有時仍會「改過頭」——特別是當你把整份程式碼貼給它時。AI 看到的是完整的 context,它的訓練讓它傾向於「提供全面改善」,而不只是點對點修改。
三個技巧可以有效控制修改範圍:
技巧一:只貼你要改的那段程式碼
貼出 .hero 的 CSS,而不是整份 style
AI 看不到其他部分,自然無法「順手改掉」。當你提問時,從 DevTools 或檔案裡複製對應的片段貼入即可。
技巧二:明確聲明不動的範圍
「除了我列出的部分,其他 CSS 保持原樣,不要重構」
在指令結尾加上這句話,相當於給 AI 設置一道防護欄。不需要每次都精確列出所有不能動的地方,一句「其他保持原樣」就夠了。
技巧三:要求 AI 只回傳差異,不回傳全文
「只給我要修改的那幾行,不要貼出完整檔案」
這讓你更容易辨認 AI 改了什麼,也避免你在複製貼上時不小心覆蓋掉你自己的其他修改。
實際操作的情境:你想改頁面上的一個按鈕顏色,但不想動按鈕的大小、圓角和 hover 效果。以下是典型的指令示範:
我想修改這個 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 解決問題的成功率會大幅提升:
點擊 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 對它的第一次回應(存下來之後當模板用)。
自我檢核
報告裡有「具體操作步驟」而不是「我點一點就壞了」
寫了預期 vs 實際的差異
附上 Console 錯誤訊息或截圖
(04) · Tools
工具選擇:Cursor / Copilot / Claude Code 各自適合什麼
AI 協作開發工具不只一種,而且每種工具的設計哲學不同。了解它們的差異,能幫你選到最適合當下任務的工具,而不是用同一個工具做所有事。
🔑
選擇原則: 不要同時用多個工具,先選一個熟。大多數人從 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(使用時機)」;貼在常用的工作筆記最上方。
自我檢核
主力工具選擇有考慮你「常改的東西類型」
切換規則是具體情境而非「感覺」
兩套工具都開過帳號、實際用過一次
SOLO · 自我演練
把你剛寫的需求描述(請 AI 改哪裡)放在手邊;開新對話請 LLM 扮「龜毛的資深 PM」,把每個「好一點」「更好看」「比較順」這類模糊字眼挑出來,要求你給可量測的替代版本(顏色 hex / 間距 px / 行高比例)。修出 v2 需求描述。
12 分鐘(演練 8 分 + 修 v2 需求 4 分)
我已跑過 LLM 角色扮演
進階選配 · 不計入課程時數(給想加練的學員) 把 LLM 對話截圖存到學習資料夾,或貼到工作群組/社群求 review。這些痕跡在轉職投履歷時可作為作品集素材。
RESULT COMPARE · 三模型對打:AI 協作開發需求描述誰理解最準?
把以下需求描述分別貼給 ChatGPT、Claude、Gemini,
請它們直接生成對應的 HTML/CSS 程式碼:
請幫我寫一個簡單的倒數計時器網頁,需求如下:
- 使用者可以輸入分鐘數(1-60)
- 按「開始」後開始倒數,畫面顯示剩餘時間(MM:SS 格式)
- 時間到時播放一聲提示音(用 Web Audio API,不要用外部音效檔)
- 按「重設」回到初始狀態
- 手機和電腦都要好看(響應式設計)
- 整體風格:簡潔、深色背景、白色文字
只輸出完整的單一 HTML 檔案(含 CSS 和 JS),不要解釋。
ChatGPT 輸出
Claude 輸出
Gemini 輸出
課堂即時作業 · 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:UX 稽核 v1 + 列 bug 清單 (5 min)— 對 CH5-1 你的 v1 做 7 項 UX 稽核(沿用 CH4-2 的)+ 列 3-5 個 bug 或可改進處
核心 2:寫結構化 bug 報告 (10 min · mini-prac 2)— 挑 1 個最重要的 bug,套用上方模板寫完整 bug 報告(觸發步驟具體 + 預期 vs 實際清楚 + 修復建議)
核心 3:用 AI 加 1 個互動功能 (10 min · mini-prac 1)— 從 4 個互動候選選 1,寫 prompt(含明確範圍控制句 )給 AI,跑出 v2。驗收 :互動功能能跑 + v1 的 4 個區塊內容完全沒變
進階路線 A :Cursor / Copilot / Claude Code 三家實測同一需求,比較哪家「範圍控制最準」「修 bug 最快」
進階路線 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 只放在 `