LESSON-25 · 零基礎學生教材
頁面開發：服務、關於與聯絡頁
完成四頁可互相到達的網站；服務頁固定顯示三項服務，關於頁有一組內容區塊，聯絡頁有三個欄位與離線成功狀態。
先理解：這堂課解決什麼問題？
首頁外框已可導航；本堂先把頁面責任、三筆服務資料與離線表單狀態做成可觀察的前端成果。
本堂要完成：完成四頁可互相到達的網站；服務頁固定顯示三項服務，關於頁有一組內容區塊，聯絡頁有三個欄位與離線成功狀態。
學習邊界：先完成「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」，不提前引入尚未教過的框架或建置工具。
先備知識與操作環境
本堂先備：首頁外框已可導航；本堂先把頁面責任、三筆服務資料與離線表單狀態做成可觀察的前端成果。 需要的檔案是 index.html、services.html、about.html、contact.html、style.css、main.js。若尚未理解這些位置，先開啟 README 的最小實驗，再開始階段練習。
- 檔案位置：先找到
index.html、services.html、about.html、contact.html、style.css、main.js，再從本頁的最小實驗開始。 - 瀏覽器：開啟最小實驗與階段頁；每次修改後儲存並重新整理。
- DevTools：依本堂內容使用 Elements、Styles、Computed、Console 或 Network，記下第一個可觀察證據。
- 操作習慣：每次只修改一個檔案或一個責任，先預測、再操作、最後驗收。
先做最小實驗：先看見結果
這不是期末網站，而是一個可以直接看到本堂核心結果的最小實驗。先完成一次操作，再回到檔案和名詞卡對照。
- 入口：開啟
examples/minimal.html。 - 操作：開啟
examples/minimal.html，依序完成頁面導覽與離線 mock 操作，不連正式 endpoint。 - 預期：頁面責任、資料狀態或部署檢查結果可以用畫面、Console、Network 或清單證明。
- 重設：重新整理並清除表單；只使用 mock，不修改正式 Sheet。
學生練習流程
依序完成每一張卡；目前只聚焦一個步驟，先操作，再用可觀察證據確認結果。
-
1
最小實驗
先閱讀本頁的問題、檔案地圖、名詞卡與最小例子。 -
2
Step 2
自己回答互動問答 4 題，再展開解析。 -
3
最小實驗 2
開啟最小實驗，實際操作一次並記下證據。 -
4
Starter
把 Starter 複製到自己的工作資料夾，照 3 張微步驟卡逐一完成；每一步都要看到結果再繼續。 -
5
Checkpoint
前往 Checkpoint，只處理 1 個本堂核心缺口；先預測，再用指定證據驗收。 -
6
Solution
前往 Solution，先看逐檔差異與修改原因，再決定要不要把完整內容帶回自己的檔案。 -
7
變體驗收
完成情境變體與獨立挑戰，留下檔案位置、操作、結果與驗收證據，並閱讀下一堂銜接：下一堂再學：如何把已整理好的 payload 接到 Apps Script；本堂不建立 endpoint、fetch或 Sheet。
檔案地圖：每個位置負責什麼？
先不要急著背檔名；請把檔案位置和責任連起來。你在階段頁會看到同一份檔案的可執行版本。
index.html首頁入口：呈現商家第一印象與主要 CTA。services.html服務頁：集中說明方案、內容與比較資訊。about.html關於頁：建立品牌背景與訪客信任。contact.html聯絡頁：提供表單欄位與送出狀態。style.cssCSS 樣式檔：放置本堂「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」相關的版面規則。main.jsJavaScript 腳本：放置本堂「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」相關的互動邏輯。
先學會這些詞
先從名詞、英文與白話意思開始；每次只展開一張名詞卡，再對照正式定義、範例與驗收證據。專業術語、語法、檔案路徑會使用不同樣式。第一次遇到術語時，先回到這裡，不要靠猜。
需求與頁面
2 個詞需求requirement 白話意思：客戶真正需要網站完成的事情。 展開查看正式定義、範例與驗收證據
- 正式定義
- 描述使用者、情境、功能與驗收條件的可檢查規格。
- 什麼時候用
- 開始畫頁面或寫程式前。
- 最小範例
- 「訪客可以在 contact.html 填寫需求並看到送出狀態」是可驗收需求。
- 可觀察證據
- 需求表中的角色、行動、結果與證據。
- 容易混淆
- 和個人喜好混淆；需求要能說明誰要完成什麼。
頁面責任page responsibility 白話意思：每一頁有清楚的主要任務。 展開查看正式定義、範例與驗收證據
- 正式定義
- 以 URL、內容、互動與轉換目標定義頁面邊界的設計方式。
- 什麼時候用
- 多頁網站開始增加服務、關於、聯絡頁時。
- 最小範例
- services.html 說明方案，contact.html 收集諮詢，不把所有內容塞首頁。
- 可觀察證據
- 四頁網址、導覽、標題與主要 CTA 的對照表。
- 容易混淆
- 和把頁面複製四份混淆；頁面責任是內容分工，不是複製檔案。
資料流與服務
3 個詞資料流data flow 白話意思：資料從哪裡來、經過誰、最後到哪裡。 展開查看正式定義、範例與驗收證據
- 正式定義
- 描述輸入、轉換、傳送、儲存與回應之間方向與狀態的模型。
- 什麼時候用
- 表單要送到 Apps Script 或 Sheet 時。
- 最小範例
- contact form → fetch → Apps Script endpoint → Sheet → 成功回應。
- 可觀察證據
- Network payload、Apps Script 回應與 Sheet 新增列。
- 容易混淆
- 和畫面流程混淆；資料流追資料，畫面流程追使用者看到什麼。
endpointendpoint 白話意思：前端可以送資料或讀資料的網址。 展開查看正式定義、範例與驗收證據
- 正式定義
- 由 HTTP 方法、URL、輸入格式與回應格式定義的服務入口。
- 什麼時候用
- 網站要和 Apps Script Web App 溝通時。
- 最小範例
- POST 到部署後的 Apps Script Web App URL。
- 可觀察證據
- Network 的 Request URL、方法、payload 與 response。
- 容易混淆
- 和 Sheet 網址混淆；前端呼叫 endpoint，不直接把試算表當 API。
mockmock 白話意思：先用假資料模擬尚未接好的服務。 展開查看正式定義、範例與驗收證據
- 正式定義
- 在不連接正式外部系統時，模擬其輸入、延遲、成功與失敗回應的測試替身。
- 什麼時候用
- 課堂要先驗證畫面與狀態，又不能修改正式資料時。
- 最小範例
- 按送出後用 setTimeout 回傳 { ok: true }。
- 可觀察證據
- 畫面依序出現送出中、成功或失敗，且沒有正式 Network 寫入。
- 容易混淆
- 和正式 API 混淆；mock 的目的，是先驗證前端流程。
上線與驗收
2 個詞productionproduction 白話意思：真正給訪客使用的公開版本。 展開查看正式定義、範例與驗收證據
- 正式定義
- 部署後可由公開網址存取、需接受實際資源與環境限制的運行環境。
- 什麼時候用
- 部署到 Cloudflare Pages 後做最後驗收時。
- 最小範例
- 使用公開 URL 檢查四頁、CDN、表單、鍵盤與錯誤。
- 可觀察證據
- 公開網址、Network、Console、390px 與表單結果。
- 容易混淆
- 和本機預覽混淆；本機能跑不代表公開路徑、HTTPS 與設定都正確。
smoke testsmoke test 白話意思：用一小組關鍵操作確認版本沒有大問題。 展開查看正式定義、範例與驗收證據
- 正式定義
- 部署或整合後，快速驗證主要路徑、資源與核心功能的回歸測試。
- 什麼時候用
- 正式部署前後，時間有限但要先確保可交付時。
- 最小範例
- 依序開首頁、services、about、contact，送一次 mock 表單並查 Console。
- 可觀察證據
- 公開網址清單、每頁 HTTP 結果、表單回應與無 404 證據。
- 容易混淆
- 和完整測試混淆；smoke test 是第一輪快速門檻，不取代深入測試。
最小例子：先看懂，再複製
這段只保留本堂第一個微成果。先預測結果，再逐行讀；完整檔案請開啟下方最小實驗。
contact form → fetch / mock endpoint → Apps Script → Sheet
驗收：四頁可達、表單狀態可重現、部署前檢查有證據。Live Lab：逐段讀碼與驗證
每一步只回答五件事：為什麼做、改哪裡、會看到什麼、用什麼證據確認、卡住先查什麼。
-
Step 1
寫出需求與頁面責任
- 目的
- 先用一頁 brief 讓技術決策有目標。
- 修改位置
project-brief.md、index.html
列角色、頁面、主要 CTA 與驗收證據- 預期結果
- 每頁責任可以口頭說清楚。 本堂焦點是「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」。
- 驗收證據
- brief 與導覽
- 卡住先查
- 只檢查一件事：
project-brief.md、index.html是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
-
Step 2
建立多頁導覽
- 目的
- 把規劃轉成四頁可到達的檔案。
- 修改位置
index.html、services.html、about.html、contact.html
補齊共用導覽與每頁 h1- 預期結果
- 四頁 URL 與頁面責任一致。 本堂焦點是「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」。
- 驗收證據
- 網址列與檔案樹
- 卡住先查
- 只檢查一件事：
index.html、services.html、about.html、contact.html是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
-
Step 3
畫出資料流
- 目的
- 在不接正式服務前先定義輸入、回應與狀態。
- 修改位置
contact.html、main.js、Code.gs
建立 mock payload 與success/error狀態- 預期結果
- Network／Console 可看見可重現的資料流程。 本堂焦點是「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」。
- 驗收證據
- payload 與 response
- 卡住先查
- 只檢查一件事：
contact.html、main.js、Code.gs是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
-
Step 4
建立離線 mock
- 目的
- 以假回應驗證 loading、成功與失敗畫面。
- 修改位置
main.js、index.html
用按鈕切換 mock success 或 error- 預期結果
- 不修改正式資料也能驗收 UI。 本堂焦點是「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」。
- 驗收證據
- 狀態文字與 Network
- 卡住先查
- 只檢查一件事：
main.js、index.html是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
-
Step 5
加入部署前檢查
- 目的
- 把本機能跑轉成公開網址能驗收的清單。
- 修改位置
smoke-test.md、所有 HTML
列資源、路由、鍵盤、Console 與表單檢查- 預期結果
- 每一項有 URL、操作與證據。 本堂焦點是「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」。
- 驗收證據
- smoke test 清單
- 卡住先查
- 只檢查一件事：
smoke-test.md、所有 HTML 是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
-
Step 6
完成交付變體
- 目的
- 替另一商家重跑需求、資料流與公開驗收。
- 修改位置
- 本堂所有檔案
替換商家內容並保留技術邊界 - 預期結果
- 可說明變更與未變更的部分。 本堂焦點是「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」。
- 驗收證據
- 公開／本機對照
- 卡住先查
- 只檢查一件事：本堂所有檔案 是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
讀碼順序：先找入口，再找被引用的檔案，最後用畫面、DOM、Console、Network 或資料結果驗證。
互動問答
先回答目前這一題，再展開解析；完成後按下一題，讓每一次回答都回到檔案或瀏覽器完成驗證。
Q1概念理解 「需求（requirement）」在本堂要解決什麼問題？ 本題線索：需求；回到名詞卡與 需求表中的角色、行動、結果與證據。 展開解析收合解析
白話解析：
客戶真正需要網站完成的事情。 正式來說，描述使用者、情境、功能與驗收條件的可檢查規格。
對照位置：
回到名詞卡「需求」，再看 需求表中的角色、行動、結果與證據。
預期觀察：
你應該能用自己的話說出：開始畫頁面或寫程式前。
常見錯誤：
不要只回答「它是需求」；那是重複名詞，不是說明責任。
立即驗證：
開啟 examples/minimal.html，依序做「開啟 examples/minimal.html，依序完成頁面導覽與離線 mock 操作，不連正式 endpoint。」並記下畫面或工具證據。
Q2程式碼閱讀
修改指定規則後，你預測畫面會看到什麼？
本題線索：project-brief.md、index.html；要修改：列角色、頁面、主要 CTA 與驗收證據；觀察：brief 與導覽
展開解析收合解析
白話解析：
先看檔案責任，再預測結果。這一步的目的：先用一頁 brief 讓技術決策有目標。
對照位置：
對照 Live Lab Step 1，位置是 project-brief.md、index.html；範例內容：contact form → fetch / mock endpoint → Apps Script → Sheet
驗收：四頁可達、表單狀態可重現、部署前檢查有證據。
預期觀察：
每頁責任可以口頭說清楚。 本堂焦點是「用原生 HTML、CSS、JavaScript 完成服務、關於與聯絡三頁」。
常見錯誤：
如果只改了檔案但沒有結果，先不要重寫全部；只檢查一件事：project-brief.md、index.html 是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
立即驗證：
實際操作後檢查 brief 與導覽。
Q3概念比較
「需求」和「頁面責任」在本堂的責任有什麼不同？
本題線索：比較 需求 與 頁面責任；操作位置：index.html、services.html、about.html、contact.html
展開解析收合解析
白話解析：
需求：客戶真正需要網站完成的事情。；頁面責任：每一頁有清楚的主要任務。
對照位置：
對照兩張名詞卡的正式定義：描述使用者、情境、功能與驗收條件的可檢查規格。／以 URL、內容、互動與轉換目標定義頁面邊界的設計方式。
預期觀察：
你應該能指出兩者分別出現在哪個檔案或工具，以及哪一個結果會改變。
常見錯誤：
不要把「改變畫面」當成所有技術的責任；先說清楚誰負責結構、呈現、行為或驗收。
立即驗證：
在 index.html、services.html、about.html、contact.html 做「補齊共用導覽與每頁 h1」，再用 網址列與檔案樹 比較前後差異。
Q4除錯驗收 如果完成操作後結果不對，你會先從哪一個證據開始查？ 本題線索：本堂所有檔案；第一個檢查位置：公開／本機對照 展開解析收合解析
白話解析：
先描述症狀，再提出一個最小假設。本堂常見錯誤是：順手加入未教框架
對照位置：
對照最後一段 Live Lab：本堂所有檔案；檢查方式：只檢查一件事：本堂所有檔案 是否存在、檔名是否完全一致，以及瀏覽器目前是否開啟這個入口。
預期觀察：
你要能指出一個具體位置，而不是一次修改很多檔案。
常見錯誤：
不要先清快取、重裝工具或複製 Solution；先查看第一個可觀察錯誤。
立即驗證：
重新操作並留下「症狀、證據、假設、單一修正、結果」五項紀錄。
常見誤解
- 看到畫面沒有變化，不代表程式沒執行；先確認檔案、路徑、元素與狀態證據。
- 能複製 Solution 不代表理解；請先說出修改哪個檔案、預期哪個結果、用什麼證據確認。
- 本堂只使用既定的 HTML、CSS、JavaScript、Vue CDN、Apps Script mock 與 Cloudflare Pages 驗收範圍。
本堂任務與驗收
完成四頁可互相到達的網站；服務頁固定顯示三項服務，關於頁有一組內容區塊，聯絡頁有三個欄位與離線成功狀態。
- 能用 四頁可達 留下可重現證據。
- 能用 三張服務卡 留下可重現證據。
- 能用 單一關於內容區塊 留下可重現證據。
- 能用
name/email/message留下可重現證據。 - 能用 離線成功狀態 留下可重現證據。
- 能用 390px 無水平溢位與鍵盤 focus 留下可重現證據。
- Starter、Checkpoint、Solution 的入口都能開啟並知道三者差異。
- 遇到問題時能先寫出症狀，再檢查一個最小假設。