↩

《零基礎學 Vibe Coding》教師授課簡報

逐章逐節對照教材，含課堂演練與問答

Vista Cheng・《零基礎學 Vibe Coding》作者

關於作者與這本書

關於作者與這本書

Vista Cheng，企業顧問、專欄作家、講師，著有《零基礎學 Vibe Coding：用 AI 做出網站、App 與工作自動化工具》（碁峯，2026）。

  • 企業顧問長年協助團隊把 AI 用進真實的工作流程，不停在概念展示階段
  • 講師教過大量沒有工程背景的職場人士，用 AI 做出網站、App 與自動化工具
  • 本書定位不是程式語言教材，是一套「怎麼跟 AI 說清楚需求」的方法論

訂閱電子報，追蹤更多實作案例

📬

Vista 電子報

Vista 電子報 QR Code每週一封，AI 與 Vibe Coding 實作紀錄｜iamvista.substack.com

🛠️

builder.tw

builder.tw QR Code更多零基礎真人案例與方法文章｜builder.tw

🧭

這份簡報的定位

這不是要取代課本的懶人包，是一套課堂教學的骨架：每一頁都標註對應書中的章節與圖表，方便老師照表操課、隨時要求學生翻書對照。

學生仍需要人手一本《零基礎學 Vibe Coding》，這份簡報只負責把書「教出來」。

全書十三章的知識地圖

graph LR A[準備期<br/>第1-3章<br/>心態與工具] --> B[基本功<br/>第4-7章<br/>提示詞與除錯] B --> C[實戰作品<br/>第8-11章<br/>四個真實產品] C --> D[品質把關與推廣<br/>第12-13章<br/>風險管理與組織擴散]

對照全書目錄（第 1 至 13 章）整理，非書中原圖

第 1 至 5 章總覽

第1章 Vibe Coding 的時代

頁 1-2～1-18・建立正確心態與能力邊界

第2章 AI 助手完全攻略

頁 2-1～2-21・選對 AI 夥伴、學會問問題

第3章 工具箱

頁 3-2～3-35・四款主力工具的選擇邏輯

第4章 第一個 Vibe Coding 專案

頁 4-2～4-29・雙路線做出同一個 App

第5章 提示詞的藝術

頁 5-2～5-26・CLEAR 框架方法論

第 6 至 10 章總覽

第6章 看懂 AI 寫的程式

頁 6-2～6-18・讀懂而非撰寫程式碼

第7章 當程式出錯

頁 7-2～7-20・用 AI 修復 AI 的錯誤

第8章 從零打造你的網站

頁 8-2～8-31・vista.tw／solo.tw 案例

第9章 名單磁鐵工具

頁 9-2～9-25・自動化獲客系統

第10章 品牌銷售頁

頁 10-2～10-24・AIDA 與 FAB 的實戰應用

第 11 至 13 章總覽

第11章 數據分析儀表板

頁 11-2～11-40・從 Excel 到互動式儀表板

第12章 品質把關

頁 12-2～12-23・AI 程式碼的風險管理

第13章 從 Vibe Coder 到 Citizen Developer

頁 13-2～13-21・個人到組織的擴散

這份教材的設計理念：每章固定五段式結構

🗺️ 章節導讀 對照書中頁碼目標
🧩 內容拆解 核心概念視覺化，不整章條列
✍️ 課堂演練 優先沿用書中練習
❓ 隨堂問答 3 題快速問答
📌 重點回顧 濃縮成一句話

給老師的使用建議

☐
可依課程週數彈性抽換章節 第 5、8、9、10 章是方法論與實戰核心，時間有限時優先保留
☐
書中原有練習優先沿用 第 5、9、10 章的動手練習與挑戰皆為書中原文，不需要另外命題
☐
問答單元是課堂小測，不是正式考試 目的是確認學生跟上概念，建議用口頭或舉手方式進行，不計分
☐
標籤看法說明 標題結尾的（§X.Y）是對照書中章節，不是投影片頁碼，講課時可提示學生翻到對應頁

適用情境

🎓

大學選修課

12 週課程，完整走過十三章

🏢

企業內訓工作坊

1-2 天密集班，抽選第 1、5、8、9、10 章為核心

📚

自學讀書會帶領人

4 週讀書會，用問答單元帶討論，用演練單元帶共作

01

歡迎來到 Vibe Coding 的時代

書中頁碼 1-2～1-18・學習目標：說出 Vibe Coding 的定義、掌握核心工作流程循環，並用能力邊界四象限判斷任務是否合適

  1. §1.2 什麼是 Vibe Coding
  2. §1.4 為什麼現在是最好的時機
  3. §1.7 核心工作流程循環
  4. §1.10 Vibe Coding 的能力邊界
  5. §1.12 本章小結與行動計畫

Vibe Coding 的定義（§1.2）

  • 自然語言驅動

    用日常語言描述你要什麼，AI 負責把它變成能跑的程式

  • 不是不用思考

    你仍要想清楚需求，只是不用自己敲出每一行語法

  • 迭代式產出

    第一版通常不是最終版，透過對話持續修正才是常態

  • 門檻轉移

    從「會寫程式」變成「會描述需求」，這正是本書要教會你的核心能力（參考書中圖 1-3：Vibe Coding 核心概念——描述、生成、迭代）

Karpathy 的命名時刻與時間軸（§1.3）

2022

ChatGPT 問世

一般人第一次大規模體驗到 AI 生成程式碼的可能性

2023～2024

AI 開發工具陸續問世

愈來愈多工具讓 AI 直接生成完整的網站與應用程式

2025

Andrej Karpathy 發推

用「Vibe Coding」形容一種新的寫程式方式：不逐行檢查、靠感覺與對話推進

2025 之後

詞彙擴散

從工程師圈的說法，變成描述一般人用 AI 開發的通用詞彙（參考書中圖 1-5：Vibe Coding 誕生時間軸）

⏱️

為什麼現在是最好的時機（§1.4）

AI 模型的能力在最近幾年呈指數級成長，同時全球軟體需求遠遠超過開發人力供給，這個落差正是一般人能參與 Vibe Coding 的空間。

參考書中圖 1-7、1-9：AI 模型能力的指數級成長／全球軟體需求 vs. 開發人力缺口

傳統開發、No-Code、Vibe Coding 三方比較（§1.4）

傳統開發／No-Code

  • 傳統開發：彈性最高，但門檻也最高，需要學程式語言
  • No-Code：門檻低，但客製化空間有限，遇到特殊需求容易卡住

Vibe Coding

  • 用自然語言描述需求，AI 生成完整程式碼
  • 彈性接近傳統開發，門檻接近 No-Code
  • 代價是你要學會怎麼把需求說清楚（參考書中圖 1-11：傳統開發 vs. No-Code vs. Vibe Coding 三方比較）

Vibe Coding 不是什麼（§1.5）

  • 不是萬能鑰匙

    複雜的系統整合、高安全性需求的專案仍需要專業工程師把關

  • 不是不用檢查

    產出仍要驗收，尤其涉及金流、個資的功能

  • 不是取代思考

    AI 幫你打字，但需求分析、判斷取捨仍是你的工作

誰適合 Vibe Coding：能力邊界四象限（§1.6）

需求明確＋可驗收

最適合先做：待辦清單、內部小工具、單頁網站

需求明確＋大型系統

適合但要拆解：分階段做，逐步擴充功能

需求模糊＋小工具

需要先做需求訪談，把模糊想法變成具體規格

需求模糊＋大型系統

目前風險最高：建議先找專業工程師諮詢架構（參考書中圖 1-13：成功 Vibe Coding 的五項核心能力）

核心工作流程循環：描述→生成→迭代（§1.7）

graph LR A[描述<br/>用自然語言說清楚需求] --> B[生成<br/>AI 產出可執行的程式碼] B --> C[迭代<br/>檢查結果、提出修正] C --> A

參考書中圖 1-3、1-16：Vibe Coding 核心概念與迭代修正的祕訣

上路前你需要準備什麼（§1.8）

1

一個 AI 助手帳號

ChatGPT、Claude 或 Gemini 任一即可，免費方案已足夠入門

2

一個能上網的瀏覽器

大多數工具都是網頁版，不需要額外安裝

3

一個具體的小需求

從你真正想解決的小問題開始，不要一開始就挑戰大型專案

4

願意對話與修正的心態

Vibe Coding 是來回對話的過程，不是一次到位

能力光譜：你的需求落在哪裡（§1.10）

🟢 全自動生成 單頁網站、小工具，AI 幾乎全包
🟡 高度輔助 中型專案，AI 主導、你把關方向
🟠 部分輔助 需要你拆解需求、多輪對話修正
🔴 高度客製 複雜商業邏輯，建議工程師協作
⚫ 專業領域 高安全性、高併發系統，交給專業團隊（參考書中圖 1-23：Vibe Coding 的能力光譜）

本書的學習路線圖（§1.11）

  • 準備期（第1-3章）

    建立心態、認識 AI 助手與工具箱

  • 基本功（第4-7章）

    第一個專案、CLEAR 提示詞框架、看懂並除錯程式碼

  • 實戰作品（第8-11章）

    網站、名單磁鐵、銷售頁、數據儀表板，四個完整產品

  • 把關與推廣（第12-13章）

    品質風險管理、從個人擴散到組織（參考書中圖 1-25：本書的學習路線圖）

Vibe Coding vs. 傳統學習的成長曲線（§1.11）

傳統程式學習

  • ✓ 前期需要大量時間學語法，成果延後才出現
  • ✓ 成就感累積慢，容易在入門階段放棄

Vibe Coding 學習路徑

  • ✓ 第一週就能做出能用的小工具，成果立即可見
  • ✓ 成就感提早出現，帶動持續學習的動力（參考書中圖 1-26：Vibe Coding vs. 傳統學習的成長曲線）
✍️ Practice

課堂演練：五分鐘體驗 Vibe Coding（§1.9）

  1. 1 打開一個 AI 對話工具（ChatGPT、Claude 或 Gemini 任一）
  2. 2 用一句話描述一個你現在真的需要的小工具（例如：幫我做一個記錄每天喝水量的小網頁）
  3. 3 送出後仔細觀察 AI 的第一次回應：它問了你什麼？直接給了什麼？
  4. 4 針對 AI 的回應提出一個修正要求，觀察它怎麼調整
  5. 5 花 1 分鐘和旁邊同學分享：你的 AI 夥伴給了什麼意外的驚喜或問題
⏱ 10 分鐘 📎 每人一臺可上網裝置＋任一 AI 助手帳號

演練驗收標準（§1.9）

☐
成功用一句話描述出一個具體需求（不是抽象願望）
☐
AI 的回應有被實際執行，或至少產出可討論的初稿
☐
學生能講出至少一個「AI 回應和我想的不一樣」的地方
☐
學生能說出下一步會怎麼修正提示詞（參考書中圖 1-20：五分鐘體驗的完整步驟）

隨堂問答（第1章）

☐
Vibe Coding 的定義是什麼？
☐
核心工作流程循環的三個步驟依序是什麼？
☐
能力邊界四象限主要在區分哪兩個維度？

參考答案（第1章）

  • Q1 定義

    用自然語言描述需求，讓 AI 生成並持續迭代出可用的程式碼

  • Q2 三步驟

    描述→生成→迭代，三者反覆循環直到成果符合需求

  • Q3 兩個維度

    需求是否明確、專案規模與風險高低，用來判斷任務是否適合先自己動手

本章小結與行動計畫（§1.12）

  • 先建立正確心態

    Vibe Coding 是新能力，不是取代思考的捷徑

  • 30 天行動計畫預告

    書中提供逐週安排，帶你從五分鐘體驗走到第一個完整作品（參考書中圖 1-28：30 天 Vibe Coding 行動計畫）

  • 下一步

    認識三大 AI 助手，選出最適合自己的第一個夥伴

本章重點回顧（第1章）

01

定義先行

Vibe Coding＝自然語言描述＋AI 生成＋持續迭代

02

循環是核心

描述→生成→迭代，貫穿全書所有實戰章節

03

先看邊界再動手

用四象限判斷任務難度，避免一開始就挑戰高風險專案

04

心態比技巧重要

願意對話與修正，比記住任何工具操作都重要

02

AI 助手完全攻略

書中頁碼 2-1～2-21・學習目標：能比較三大 AI 助手的差異、選對模型，並用結構化方式問出好問題

  1. §2.2 三大主流 AI 助手比較
  2. §2.5 模型選擇指南
  3. §2.7 對話的藝術
  4. §2.8 上下文管理
  5. §2.10 三個進階技巧

認識你的 AI 夥伴（§2.1）

  • 不是搜尋引擎

    AI 助手是能理解上下文、持續對話的夥伴，不是關鍵字比對工具

  • 擅長生成與解釋

    寫程式碼、寫文案、解釋概念都是它的強項

  • 需要你把關

    它會很有自信地講錯話，驗證仍是你的責任

  • 多輪對話才是常態

    把它當成一起工作的夥伴，而不是一次許願的許願池

三大主流 AI 助手比較（§2.2）

💬

ChatGPT

生態系最大、外掛與應用最多，適合新手第一個帳號

🧠

Claude

長文與程式碼理解力強，是 Vibe Coding 場景常見首選

✨

Gemini

與 Google 服務深度整合，適合已重度使用 Google 生態系的人

註冊與第一次對話（§2.3）

1

前往官方網站註冊

用 Email 或既有帳號（Google／Apple）快速建立帳號

2

完成身分驗證

大多數服務會要求驗證信箱或手機號碼

3

開啟第一個對話

從一個簡單的問題開始，熟悉輸入框與送出方式

4

觀察回應風格

感受它的語氣與詳細程度，作為之後調整提示詞的依據

對話介面完全圖解（§2.4）

  • 輸入框

    打字或貼上你的提示詞，多數支援換行與附加檔案

  • 對話歷史

    左側或上方通常有歷史紀錄，方便回頭找之前的對話

  • 模型選單

    部分工具可切換不同模型版本，影響能力與速度

  • 附件與工具按鈕

    上傳圖片、檔案，或啟用搜尋、程式碼執行等擴充功能

模型選擇指南（§2.5）

  • 一般日常任務

    選預設的輕量模型即可，速度快、成本低

  • 複雜推理或長文

    切換到旗艦模型，換取更好的邏輯與品質

  • 程式碼相關任務

    優先選對程式碼理解與生成表現較強的模型

  • 不確定時

    先用預設模型試一次，效果不理想再升級模型或改寫提示詞

免費 vs. 付費方案（§2.6）

免費方案

  • ✓ 足夠日常學習與五分鐘體驗使用
  • ✓ 訊息則數、使用時段可能受限，尖峰時段容易卡住

付費方案

  • ✗ 訊息額度更高，能使用旗艦模型與進階功能
  • ✗ 適合把 Vibe Coding 用進正式工作流程的人

問出好問題的藝術（§2.7）

🎯 具體背景 說清楚你在做什麼、為什麼要做
👤 設定對象 告訴 AI 這個結果最後要給誰看
📋 舉例說明 附上範例，更容易命中你要的風格
✅ 講清楚格式 要清單、表格或一段話，直接說明

上下文管理：對話如何累積記憶（§2.8）

graph LR A[第一輪對話<br/>建立背景資訊] --> B[AI 記住脈絡<br/>同一個對話串內] B --> C[後續提問<br/>不用重複交代背景] C --> D[對話拉太長<br/>適時開新對話重新聚焦]

參考書中圖 2-19～2-21：上下文管理相關示意

三個事半功倍的進階技巧（§2.10）

善用系統提示或自訂指令

一次設定語氣與身分，每次對話都套用

善用範例檔案

上傳一份範例，AI 產出風格更貼近需求

分段拆解大任務

把大需求拆成幾個小步驟，逐輪確認推進

實戰案例：AI 能幫你做什麼（§2.9）

  • 寫作與編修

    草稿生成、語氣調整、多語言翻譯

  • 資料整理

    把雜亂的筆記整理成表格或摘要

  • 程式碼協作

    從零生成小工具，或解釋一段看不懂的程式碼

  • 流程規劃

    把模糊的任務拆解成具體的執行步驟

常見問題與排除（§2.11）

☐
回應牛頭不對馬嘴 通常是背景資訊不足，補上更多脈絡再試一次
☐
訊息額度用完 免費方案有每日或每時段限制，可以稍後再試或考慮升級
☐
產出的內容過時 對時效性資訊，明確要求 AI 使用搜尋功能或標註查證日期
☐
AI 態度很肯定但答案是錯的 這是常態，重要資訊一律自己動手驗證
✍️ Practice

課堂演練：閒聊式提問 vs. 結構化提問（§2.7）

  1. 1 想一個工作或生活上的真實需求（例如：寫一封請假信）
  2. 2 第一次用最隨性的一句話問 AI（例如：幫我寫請假信）
  3. 3 第二次補上背景、對象、語氣、格式等細節，重新問一次
  4. 4 比較兩次回覆：哪裡不一樣？哪一版你改得比較少？
⏱ 10 分鐘 📎 每人一臺可上網裝置＋任一 AI 助手

隨堂問答（第2章）

☐
目前三大主流 AI 助手分別是什麼？
☐
什麼是上下文管理？為什麼對話拉太長需要注意它？
☐
免費方案與付費方案的其中一項差異是什麼？

參考答案（第2章）

  • Q1 三大助手

    ChatGPT、Claude、Gemini

  • Q2 上下文管理

    AI 在同一對話串內記住先前脈絡，避免每輪都重講背景；對話太長會稀釋重點，適時開新對話

  • Q3 方案差異

    訊息額度、可用模型等級、尖峰時段穩定度，付費方案通常更高

本章重點回顧（第2章）

01

先選一個夥伴

三大助手各有強項，新手先選一個上手，不用同時學三套

02

問題品質決定回答品質

具體背景＋設定對象＋範例＋格式要求，缺一效果就打折

03

善用上下文

同一對話串內不用重複交代背景，但拉太長要適時重開

04

免費方案先試水溫

額度用完再考慮升級，不用一開始就付費

03

工具箱——你的 Vibe Coding 兵器庫

書中頁碼 3-2～3-35・學習目標：認識四款主力工具的特色差異，並能依需求選出合適的工具

  1. §3.2 Cursor
  2. §3.3 Antigravity
  3. §3.4 Lovable
  4. §3.5 Claude Code
  5. §3.7 工具選擇指南
🧰

為什麼需要專門的開發工具（§3.1）

一般的聊天視窗適合問答，但要做出完整的網站或 App，需要能管理檔案、執行程式、串接部署的專門工具。

工具的差異不在「強不強」，在「適不適合你現在的任務」。

四大工具一覽（§3.2～3.5）

🖱️

Cursor

專業級 AI 程式編輯器，適合想貼近傳統開發流程的人

🌐

Antigravity

Google 的全端開發環境，適合從構想直接做出完整應用

💜

Lovable

讓 AI 打造完整應用，介面親切、上手快

👑

Claude Code

Vibe Coding 領域的王者，指令列操作、彈性最高

Cursor：專業級 AI 程式編輯器（§3.2）

  • 定位

    以程式編輯器為基礎，內建 AI 協作能力

  • 適合誰

    想貼近真實開發流程、之後可能學程式的人

  • 優勢

    檔案管理與版本控制介面完整，AI 建議可逐行檢視再採用

  • 要留意

    介面比純聊天工具複雜，初次上手需要一點時間熟悉

Antigravity：Google 的全端開發環境（§3.3）

  • 定位

    Google 推出的全端開發環境，強調從構想直接到可執行的應用

  • 適合誰

    想要一站式體驗、不想切換多個工具的人

  • 優勢

    與 Google 生態系整合度高，部署流程相對簡化

  • 要留意

    客製化彈性不如純程式編輯器高

Lovable：讓 AI 打造完整應用（§3.4）

  • 定位

    主打用對話直接生成完整可用的應用程式

  • 適合誰

    完全不想碰程式碼、想要最短路徑做出成品的人

  • 優勢

    介面直覺，適合快速做出可展示的原型

  • 要留意

    深度客製化時，仍建議搭配其他工具微調細節

Claude Code：Vibe Coding 領域的王者（§3.5）

  • 定位

    指令列（終端機）操作的 AI 開發夥伴，本書多次示範使用

  • 適合誰

    想要最高彈性、願意學一點基本操作的人

  • 優勢

    能直接讀寫整個專案的檔案結構，處理複雜任務的能力最強

  • 要留意

    入門門檻略高於純圖形介面工具，但學習曲線很快能跨過

其他值得認識的工具（§3.6）

🧩 Bolt 瀏覽器內直接生成與預覽網頁應用
🎨 v0 生成介面與元件
⚡ Replit 線上開發環境，適合協作與分享成果

工具選擇決策樹（§3.7）

graph TD A{完全不想碰程式碼?} -->|是| B[Lovable / Antigravity] A -->|否，願意學一點| C{需要最高彈性?} C -->|是| D[Claude Code] C -->|否，偏好圖形介面| E[Cursor]

參考書中圖 3-13～3-15：工具選擇指南與決策樹

同一個需求，四種工具怎麼做（§3.8）

Cursor 的做法

在編輯器內逐步生成程式碼，人工檢視每一步變更

Antigravity 的做法

一站式描述需求，環境直接產出可執行的完整專案

Lovable 的做法

用對話快速生成可預覽的成品，先求有再求好

Claude Code 的做法

在終端機下指令，讓它自主規劃並完成多檔案的變更

工具組合策略：聰明人都這樣用（§3.9）

1

先用 Lovable 或 Antigravity 快速驗證構想

花最少時間確認方向對不對

2

方向確定後轉 Cursor 或 Claude Code 深化

需要更細緻的客製化時再換工具

3

固定用同一套當主力

減少來回切換的學習成本，除非任務明顯不合適

✍️ Practice

課堂演練：情境選工具（§3.7～3.8）

  1. 1 情境一：要做一個給客戶展示的完整 App，時間充裕——選哪個工具？為什麼？
  2. 2 情境二：只是想改改現有網頁的一段文案——選哪個工具？為什麼？
  3. 3 情境三：完全沒碰過程式碼，想在今天內做出一個小工具——選哪個工具？為什麼？
  4. 4 情境四：需要跟工程團隊交接、之後會持續維護——選哪個工具？為什麼？
⏱ 10 分鐘 📎 無需上機，紙筆討論即可

演練提示：決策依據回顧（§3.7）

☐
任務規模：一次性小改動 vs. 完整新專案
☐
客製化需求：標準化夠用 vs. 需要精細調整
☐
接手者背景：只有自己用 vs. 之後要交接給工程團隊
☐
時間壓力：今天要看到成果 vs. 可以花時間打磨

隨堂問答（第3章）

☐
如果完全不想碰程式碼、想最短時間看到成品，比較適合哪一款工具？
☐
Claude Code 的操作方式與其他三款工具最大的不同是什麼？
☐
「工具組合策略」建議的操作順序大致是什麼？

參考答案（第3章）

  • Q1

    Lovable（或 Antigravity），主打對話直接生成完整可用的應用

  • Q2

    Claude Code 是指令列操作，其他三款以圖形介面或瀏覽器操作為主

  • Q3

    先用 Lovable／Antigravity 快速驗證構想，方向確定後再轉 Cursor／Claude Code 深化

本章重點回顧（第3章）

01

沒有最好，只有最適合

四款工具的差異在定位，不是強弱

02

先驗證再深化

快速做出原型確認方向，再換工具打磨細節

03

決策看三個變數

任務規模、客製化需求、接手者背景

04

固定一套當主力

減少切換成本，除非任務明顯不合適

04

你的第一個 Vibe Coding 專案

書中頁碼 4-2～4-29・學習目標：走過從構想到成品的完整流程，並比較 Antigravity 與 Claude Code 兩條實作路線

  1. §4.2 暖身練習
  2. §4.3 構想拆解
  3. §4.4 Antigravity 路線
  4. §4.5 Claude Code 路線
  5. §4.8 反思與學習

準備出發：你需要什麼（§4.1）

☐
一個 AI 助手帳號（第2章已完成）
☐
一款主力開發工具（第3章已選定）
☐
一個具體的小專案構想：待辦清單 App
☐
大約一小時不受打擾的時間

暖身練習：用 ChatGPT 寫你的第一段程式碼（§4.2）

  • 目標

    不求做出完整應用，只求體驗「描述需求→拿到程式碼」的過程

  • 做法

    請 AI 寫一段簡單的網頁片段，例如一個按鈕點下去會變色

  • 觀察重點

    AI 給的不只是程式碼，通常還附上簡短說明，先讀懂說明再看程式碼

  • 心態提醒

    看不懂程式碼細節沒關係，先確認結果符不符合你的需求

構想你的待辦清單 App（§4.3）

  • 核心功能

    新增任務、標記完成、刪除任務，三個功能就足夠

  • 先寫需求清單

    把想要的功能用白話文條列出來，愈具體愈好

  • 不要一開始就想介面美觀

    先求功能能動，再談外觀

  • 這就是你的第一份提示詞草稿

    待會兩條路線都會用它當起點

Antigravity 路線 vs. Claude Code 路線總覽（§4.4～4.5）

Antigravity 路線

  • 圖形介面操作，一站式描述需求即可產出
  • 適合想快速看到完整成品的人

Claude Code 路線

  • 指令列操作，逐步下指令、逐步檢視變更
  • 適合想更貼近開發流程、日後想深化技能的人（參考書中圖 4-13：待辦清單 App 從構想到上線全流程步驟圖）

Antigravity 路線：五個步驟（§4.4）

1

開啟新專案

在 Antigravity 建立一個新的應用專案

2

貼上需求描述

把 §4.3 寫好的功能清單交給 AI

3

檢視自動產出的畫面

確認新增、標記完成、刪除三個功能都在

4

提出修正要求

例如調整版面順序或按鈕文字

5

預覽並確認可用

在瀏覽器內實際點一次每個功能

Claude Code 路線：五個步驟（§4.5）

1

開啟終端機並啟動 Claude Code

進入一個空的專案資料夾

2

下達第一個指令

描述待辦清單 App 的需求，請它建立基本檔案結構

3

檢視它規劃的步驟

Claude Code 通常會先列出打算怎麼做，再動手

4

在本機瀏覽器預覽

確認畫面與功能是否符合需求

5

逐輪提出修正

針對不滿意的地方，一次只講一個重點修正

從構想到成品的完整流程（§4.6）

graph LR A[寫需求清單] --> B[交給 AI 產出第一版] B --> C[實際操作測試] C --> D[提出修正要求] D --> C C --> E[確認可用<br/>完成第一個專案]

參考書中圖 4-1、4-25～4-28：從構想到成品的完整流程

讓你的作品更好：迭代最佳化（§4.7）

  • 一次只改一個重點

    同時要求太多修正，AI 容易顧此失彼

  • 具體描述問題

    不要只說「怪怪的」，說清楚哪裡怪、你期待的樣子

  • 保留堪用的版本

    每次大改動前，先確認上一版能正常運作

  • 適可而止

    功能滿足需求就可以先上線，不必追求一次到位

迭代前 vs. 迭代後（§4.7）

第一版（堪用）

  • ✓ 三個核心功能都能動，但介面陽春
  • ✓ 偶爾有小地方跟預期不完全一樣

迭代兩三輪之後

  • ✓ 介面更順手、文字更貼近使用情境
  • ✓ 你也更清楚下次怎麼把需求描述得更精確

第一個專案的反思與學習（§4.8）

  • 哪一條路線的體驗讓你更有感？

    沒有標準答案，記錄下你的直覺反應

  • 如果重做一次，你會怎麼調整提示詞？

    通常會更具體、更早給範例

  • 卡關發生在哪一步？

    多數人卡在「描述不夠具體」，這是正常的學習曲線

  • 這是引導反思，不是有標準答案的測驗

    重點是讓學生誠實記錄自己的學習歷程

✍️ Practice

課堂實作：待辦清單 App 雙路線體驗（簡化版）（§4.4～4.5）

  1. 1 用 §4.3 的功能清單，先完成新增與標記完成兩個功能即可（刪除功能列為加分項）
  2. 2 時間允許的話，用第二種工具再做一次，感受兩條路線的差異
  3. 3 記錄下你在哪一步卡關、怎麼描述才解決問題
  4. 4 完成後與旁邊同學互相操作對方的成品，給一句回饋
⏱ 25 分鐘 📎 每人一臺可上網裝置＋已選定的主力工具

驗收標準（教師新增）（§4.6）

☐
能新增一筆待辦事項並顯示在畫面上
☐
能將一筆待辦事項標記為已完成（視覺上要有差異）
☐
重新整理頁面後，資料不一定要保留（本次練習不強制要求儲存機制）
☐
學生能口頭說出自己走過的完整流程：需求→產出→測試→修正

隨堂問答（第4章）

☐
Antigravity 路線與 Claude Code 路線，操作方式最大的差異是什麼？
☐
迭代最佳化時，為什麼建議「一次只改一個重點」？
☐
你在這次實作中，哪一步花的時間最久？原因通常是什麼？

參考答案（第4章）

  • Q1

    Antigravity 是圖形介面一站式操作，Claude Code 是指令列逐步下指令

  • Q2

    同時塞太多修正要求，AI 容易顧此失彼，拆成單一重點更容易命中

  • Q3（開放式）

    多數人卡在「描述不夠具體」，這是正常的學習曲線，鼓勵誠實分享

本章重點回顧（第4章）

01

流程比工具重要

需求→產出→測試→修正，這個循環在任何工具上都通用

02

先求堪用再求完美

第一版能動就先驗收，別卡在完美主義

03

具體的提示詞來自具體的反思

每次卡關都是下次寫得更好的素材

04

兩條路線沒有優劣

選你更有感的那條，持續深化下去

05

提示詞的藝術——如何跟 AI 說話

書中頁碼 5-2～5-26・學習目標：熟練 CLEAR 框架五個要素，並學會用角色設定與思維鏈提問處理複雜任務

  1. §5.3 CLEAR 框架五個字母
  2. §5.4 從模糊到精確的三步驟
  3. §5.5 十個職場場景範本
  4. §5.6 角色設定與思維鏈提問（CoT）
  5. §5.6 五個常見陷阱
🔑

為什麼提示詞這麼重要（§5.1）

提示詞品質決定 AI 回覆品質。同一個 AI，換一種問法，產出的結果可能天差地遠。

這是全書最核心的方法論章節，值得花時間熟練。

好的提示詞 vs. 不好的提示詞（§5.2）

Before

不好的提示詞

  • 「幫我寫一封信」
  • 沒有背景、沒有對象、沒有格式要求
After

好的提示詞

  • 「幫我寫一封請假信給主管，語氣正式，說明因家人住院需請假三天，附上聯絡方式」
  • 背景、對象、語氣、格式一次到位（參考書中圖 5-3：好 vs. 壞提示詞實例對比）

CLEAR 框架總覽（§5.3）

  • C・Context 背景

    說清楚這件事的來龍去脈

  • L・Language 語言風格

    指定語氣：正式、活潑、專業都可以

  • E・Examples 範例

    附上一兩個範例，AI 更容易命中你的期待

  • A・Audience 對象

    說明結果最後要給誰看

  • R・Requirements 要求

    明確列出格式、字數、限制等具體要求（參考書中圖 5-6：CLEAR 五要素逐項拆解圖）

C

Context

背景：先讓 AI 知道來龍去脈

說明這件事發生在什麼情境、目的是什麼

背景愈完整，AI 愈不會答非所問

範例：「我們公司下週要辦新品發表會」

L

Language

語言風格：指定你要的語氣

正式、活潑、專業、親切，先講清楚

沒指定時 AI 會用預設中性語氣，未必符合場合

範例：「用輕鬆但不失專業的語氣」

E

Examples

範例：給一兩個具體樣本

一段參考文字、一張截圖，都能大幅提升命中率

沒有範例時，AI 只能用它自己猜測的標準

範例：附上一封過去寫得不錯的信當參考

A

Audience

對象：說明結果要給誰看

給客戶看、給主管看、給小學生看，寫法完全不同

對象不明，AI 只能用最保守的中性寫法

範例：「這是要給非技術背景的主管看的報告」

R

Requirements

要求：明確列出具體限制

字數、格式、必須包含或不能出現的內容

愈明確的要求，愈能避免來回修改

範例：「不超過 300 字，用條列式，附一個結論句」

從模糊需求到精確指令：三步驟（§5.4）

Before

模糊需求

  • 「幫我弄一份簡報大綱」
After

精確指令（拆解需求→補充細節→結構化輸出）

  • 「幫我做一份給新進員工用的教育訓練簡報大綱，共 8 頁，語氣親切、每頁附一個重點句」（參考書中圖 5-18：從模糊需求到精確指令的轉譯技巧）

十個職場場景提示詞範本一覽（§5.5）

場景一：電子郵件

請假信、催收信、道歉信皆可套用

場景二：簡報大綱

快速產出結構化的簡報骨架

場景四：會議紀錄

把零散的口語紀錄整理成條列重點

場景三：數據分析

請 AI 協助解讀一份數據並歸納重點

場景九：程式開發

描述功能需求，請 AI 產出對應程式碼

其餘五個場景

客服回覆、社群貼文、產品文案、專案規劃、學習計畫（參考書中圖 5-22～5-29：十個職場場景提示詞範本）

範本示範一：電子郵件（§5.5）

PROMPT 
你是一位專業的行政助理。請幫我寫一封請假信給主管王經理，語氣正式有禮：
背景：家人明天要住院開刀，需要照顧
要求：說明請假三天（明天起）、已安排代理人、附上緊急聯絡方式
字數：150 字以內
OUTPUT
王經理您好：
因家人明日將住院開刀，需在旁照顧，特此申請請假三天（自明日起）。期間工作已安排代理人接手，如有緊急事項可透過手機聯繫我。造成不便，敬請見諒，謝謝您的體諒。

範本示範二：會議紀錄（§5.5）

PROMPT 
你是一位會議紀錄整理員。以下是零散的口語紀錄，請整理成條列式重點，並標出待辦事項與負責人：
（貼上逐字稿片段）
要求：分成「討論重點」與「待辦事項」兩區塊
OUTPUT
討論重點：
・確定下季主打產品線為 A 方案
・行銷預算維持不變

待辦事項：
・完成競品分析（負責人：小林，期限：下週三）
・產出初版文案（負責人：小陳，期限：下週五）

進階技巧一：角色設定（§5.6）

  • 是什麼

    在提示詞裡先請 AI 扮演一個具體角色，例如「你是一位有十年經驗的財務主管」

  • 為什麼有效

    角色設定能收斂回答的專業深度與風格，減少空泛的通用建議

  • 實際寫法

    「你是一位資深行銷顧問，請用你的專業角度分析這份文案」

  • 搭配 CLEAR

    角色設定常常同時補足了 Audience（對象）與 Language（語言風格）兩個維度

進階技巧二：思維鏈式提問 CoT（§5.6）

  • 核心概念

    不要求 AI 一次跳到答案，而是引導它把推理過程拆成一步一步的中間步驟

  • 理論依據

    出自 Google Brain 團隊 2022 年 NeurIPS 論文〈Chain-of-Thought Prompting Elicits Reasoning in Large Language Models〉（arXiv:2201.11903）

  • 使用時機

    適合複雜、需要多步驟推理的任務，例如財務試算、多條件的排程規劃

  • 實際寫法

    在提示詞加上「請先一步一步列出你的推理過程，再給出最終答案」

五個常見陷阱（§5.6）

☐
陷阱一：一次塞太多需求 拆成多輪對話，一次只交代一個重點
☐
陷阱二：指令互相矛盾 送出前自己讀一遍，確認前後要求沒有衝突
☐
陷阱三：過度依賴 AI 的第一次回覆 把第一版當草稿，養成追問與修正的習慣
☐
陷阱四：忘記提供範例 附上一兩個範例，能大幅降低 AI 誤解的機率
☐
陷阱五：不驗證 AI 的回覆 尤其是數字、法規、專有名詞，一定要自己核對
✍️ Practice

課堂演練：動手練習（沿用書中§5.6原文，任選其一）（§5.6）

  1. 1 知識要用了才是你的，請從以下三個練習中，至少選一個試試看：
  2. 2 ① 改造練習：找一個你最近給 AI 的提示詞，用 CLEAR 框架改寫，比較前後的回覆品質差異
  3. 3 ② 場景練習：從十個範本中挑選一個你工作中最常遇到的場景，填入你自己的實際情境，試跑一次
  4. 4 ③ 鏈式提問練習：選一個複雜的工作任務，試著用四輪對話的方式，逐步引導 AI 完成
⏱ 15 分鐘 📎 每人一份最近使用過的提示詞紀錄（或現場即興出題）

隨堂問答（第5章）

☐
CLEAR 框架的五個字母分別代表什麼？
☐
好的提示詞具備哪五個特徵？
☐
思維鏈式提問（CoT）的核心概念是什麼？
☐
五個常見陷阱中，你覺得哪一個在職場上最容易踩到？為什麼？

參考答案（第5章）

  • Q1 CLEAR

    Context（背景）、Language（語言風格）、Examples（範例）、Audience（對象）、Requirements（要求）

  • Q2 五個特徵

    具體明確、提供背景、設定限制、一次一重點、附上範例

  • Q3 CoT

    引導 AI 把推理過程拆成一步一步的中間步驟，再給出最終答案，能提升複雜任務的正確率

  • Q4（開放式）

    無標準答案，可請學生舉例說明，並用書中方法自我檢查

本章重點回顧（第5章）

01

提示詞品質決定回覆品質

五個特徵：具體明確、提供背景、設定限制、一次一重點、附上範例

02

CLEAR 框架

Context、Language、Examples、Audience、Requirements

03

從模糊到精確三步驟

拆解需求→補充細節→結構化輸出

04

進階技巧與五大陷阱

角色設定與 CoT 讓 AI 更懂你，但務必養成驗證回覆的習慣

06

看懂 AI 寫的程式——你真的不用會寫

書中頁碼 6-2～6-18・學習目標：用白話理解程式碼的基本邏輯，學會閱讀而非撰寫、找出關鍵修改點

  1. §6.1 程式碼的基本邏輯結構
  2. §6.2 如何閱讀，而非撰寫
  3. §6.3 找出關鍵修改點的技巧
  4. §6.4 用 AI 解釋 AI 寫的程式碼

程式碼的基本邏輯結構：白話文解釋（§6.1）

  • 程式碼不是外星語

    本質上就是一連串「先做什麼、再做什麼」的指令

  • 三種基本積木

    依序執行、條件判斷、重複迴圈，幾乎所有邏輯都是這三種的組合

  • 變數是容器

    用來暫時存放資料，例如一個人的姓名或一筆金額

  • 你的目標不是背語法

    而是看懂「這段在做什麼」，足夠應付大部分場景

三個基本邏輯積木（§6.1）

➡️ 依序執行 一行一行由上往下做，像照食譜做菜
🔀 條件判斷 符合某個情況才做某件事，像「如果下雨就帶傘」
🔁 重複迴圈 同一件事重複做很多次，像「把每筆訂單都檢查一遍」

如何閱讀，而非撰寫程式碼（§6.2）

1

先看整體結構

掃過檔案，抓出大致分成哪幾個區塊

2

找關鍵字辨認邏輯積木

看到「如果」「否則」判斷條件判斷，看到「每一個」判斷迴圈

3

對照畫面找對應程式碼

在畫面上點一個功能，回頭找是哪一段程式碼在處理它

4

帶著問題讀

不求全懂，先確認這段是不是你要改的地方

示範片段：一段簡單的條件判斷（§6.2）

// 示範用：判斷會員等級是否可享折扣
if (購買金額 >= 1000) {
  折扣 = "享有九折優惠"
} else {
  折扣 = "未達優惠門檻"
}

// 白話解釋：
// 如果購買金額大於等於 1000，就給九折
// 否則就顯示還沒達到門檻

找出關鍵修改點的技巧（§6.3）

  • 先鎖定畫面上的文字或數字

    用搜尋功能找出程式碼裡對應的那一行

  • 留意「魔法數字」

    像折扣門檻 1000 這種寫死的數值，通常就是你要調整的地方

  • 小幅改動、立即測試

    改一行就重新整理畫面確認，不要一次改一大段

  • 不確定時先問 AI

    「這一行的用途是什麼？改了會影響哪裡？」

用 AI 解釋 AI 寫的程式碼（§6.4）

PROMPT 
請用白話文解釋以下這段程式碼在做什麼，不要用專業術語，就像跟完全沒學過程式的人解釋一樣：
（貼上你看不懂的那段程式碼）
OUTPUT
這段程式碼在做的事情是：先檢查顧客這次買了多少錢，如果超過 1000 元，系統就會自動給他打九折；如果沒有超過，就照原價計算，不會有任何折扣。

本章小結（§6.5）

  • 你不需要會寫，只需要看得懂

    這是本章唯一也是最重要的訊息

  • 三個積木就能理解大部分邏輯

    依序執行、條件判斷、重複迴圈

  • 善用 AI 當你的翻譯員

    看不懂的地方，直接請 AI 用白話解釋

✍️ Practice

課堂演練：三步驟閱讀法（§6.2～6.3）

  1. 1 掃過整段程式碼，圈出你覺得是「條件判斷」的那一行
  2. 2 找出裡面的「魔法數字」（本例是 1000），猜猜看它代表什麼意思
  3. 3 寫下一句話：如果要把優惠門檻改成 2000 元，你會怎麼跟 AI 描述這個修改需求
  4. 4 兩人一組互相檢查對方寫的修改描述夠不夠具體
⏱ 10 分鐘 📎 講義附上一段示範用程式碼片段（如上頁的折扣判斷範例）

隨堂問答（第6章）

☐
程式碼的三個基本邏輯積木是什麼？
☐
閱讀程式碼時，「找關鍵字辨認邏輯積木」具體是在找什麼？
☐
示範片段裡的「1000」這個數字代表什麼？如果要改，你會怎麼描述？

參考答案（第6章，含簡短邏輯說明）

  • Q1

    依序執行、條件判斷、重複迴圈

  • Q2

    找像「如果」「否則」這類代表條件判斷、「每一個」這類代表迴圈的關鍵字

  • Q3

    1000 是購買金額達到九折優惠的門檻（魔法數字）；描述修改可以說「請把優惠門檻從 1000 元改成 2000 元」

本章重點回顧（第6章）

01

看懂比寫出來重要

這是 Vibe Coding 對一般人最友善的地方

02

三個積木走天下

依序執行、條件判斷、重複迴圈

03

魔法數字是你的切入點

寫死的數值通常就是最容易修改的地方

04

AI 是你的翻譯員

看不懂就直接請它用白話解釋

07

當程式出錯——用 AI 修復 AI 的錯誤

書中頁碼 7-2～7-20・學習目標：建立除錯的正確心態、看懂錯誤訊息，並學會用正確方式請 AI 修復問題

  1. §7.2 Debug 的基本概念
  2. §7.3 錯誤訊息是你的朋友
  3. §7.4 讓 AI 幫你修 Bug 的正確對話方式
  4. §7.5 預防勝於治療
  5. §7.6 實戰演練：從錯誤到修復
🛠️

別怕！程式出錯是正常的（§7.1）

就連專業工程師每天都在面對錯誤訊息，出錯不代表你做錯了什麼，只是流程中必經的一步。

重點不是避免出錯，是學會怎麼快速修復。

Debug 的基本概念：三步驟（§7.2）

1

重現問題

確認錯誤在什麼情況下會發生，愈具體愈好

2

定位問題

找出是哪一段程式碼、哪一個步驟出了狀況

3

修復並驗證

請 AI 修正後，重新走一次剛才會出錯的步驟確認

錯誤訊息是你的朋友：如何解讀（§7.3）

  • 錯誤訊息不是懲罰，是線索

    它通常會告訴你問題發生在哪一行、大概是什麼類型的錯誤

  • 不用完全看懂

    複製整段錯誤訊息給 AI，通常比自己硬猜更有效率

  • 留意訊息裡的檔名與行號

    這能幫助你快速定位問題發生的位置

  • 一次只處理一個錯誤

    有時候修好一個，其他錯誤訊息就會跟著消失

🚦

錯誤訊息面板的顏色代表什麼急迫度（§7.3）

紅色：必須立即處理
橘黃色：建議儘快處理
藍灰色：僅供參考，可稍後再看

常見錯誤訊息急救包（§7.3）

  • 找不到某個檔案或模組

    通常是檔名打錯或忘記安裝，把訊息貼給 AI 請它確認

  • 畫面空白或功能沒反應

    請 AI 檢查瀏覽器主控臺的錯誤紀錄，通常有更明確的線索

  • 資料沒有正確顯示

    確認資料來源本身是否正確，再確認顯示邏輯是否對應

  • 修好一個又冒出新的

    正常現象，代表你正在逐層解決問題，繼續走三步驟即可

讓 AI 幫你修 Bug 的正確對話方式（§7.4）

PROMPT 
我的待辦清單 App 出現問題：點擊「新增」按鈕沒有反應。
以下是完整錯誤訊息：（貼上錯誤訊息全文）
以下是相關程式碼：（貼上該功能的程式碼）
我預期的結果是：點擊後應該要新增一筆待辦事項到清單最上方
OUTPUT
已找到問題：新增按鈕的點擊事件沒有正確綁定到對應的函式。已修正綁定關係，現在點擊「新增」應該能正常運作，請重新整理頁面測試看看。

預防勝於治療：降低出錯率的最佳實踐（§7.5）

☐
每次只請 AI 做一個小改動，方便定位問題來源
☐
重要功能改完後，立即實際操作測試一次
☐
保留能正常運作的版本，方便出狀況時回頭比對
☐
請 AI 在修改前先說明它打算怎麼做，避免出乎意料的大改動

實戰演練：從錯誤到修復的完整流程（§7.6）

graph LR A[操作時發現異常] --> B[複製完整錯誤訊息] B --> C[連同相關程式碼交給 AI] C --> D[AI 提出修正] D --> E[重新測試] E -->|仍有問題| B E -->|正常運作| F[確認修復完成]

參考書中§7.6：待辦清單 App 從出錯到修復的完整過程

✍️ Practice

課堂實作：向 AI 回報 Bug 的模板演練（§7.6）

  1. 1 情境：你的待辦清單 App 標記完成後，項目的樣式沒有改變（例如沒有畫上刪除線）
  2. 2 練習寫出一段完整的回報：問題描述＋預期結果＋（若手邊有）錯誤訊息或相關程式碼
  3. 3 如果有實機操作，實際交給 AI 修復並驗證結果
  4. 4 沒有實機時，交換你寫的回報，請同學評估「這樣的描述夠不夠讓 AI 抓到重點」
⏱ 15 分鐘 📎 每人一份第4章做出的待辦清單 App（或講義提供的示範情境）

演練提示：回報模板檢核（§7.4）

☐
有沒有具體描述「發生了什麼」而不是只說「壞掉了」？
☐
有沒有附上錯誤訊息全文（如果有的話）？
☐
有沒有說明「你預期應該要發生什麼」？
☐
有沒有附上相關的程式碼片段？

隨堂問答（第7章）

☐
Debug 的三個步驟依序是什麼？
☐
看到錯誤訊息時，最有效率的做法是什麼？
☐
錯誤訊息面板的顏色，紅色代表什麼急迫度？

參考答案（第7章）

  • Q1

    重現問題→定位問題→修復並驗證

  • Q2

    複製整段錯誤訊息連同相關程式碼交給 AI，比自己硬猜更有效率

  • Q3

    紅色代表程式無法執行，必須立即處理

本章重點回顧（第7章）

01

出錯是正常的

連專業工程師都天天面對錯誤訊息

02

錯誤訊息是線索不是懲罰

完整複製給 AI 比自己硬猜有效率

03

三步驟走天下

重現→定位→修復並驗證

04

一次只改一件事

方便定位問題，也方便回頭比對

08

從零打造你的網站——以 vista.tw 與 solo.tw 為例

書中頁碼 8-2～8-31・學習目標：分辨內容型與互動型網站策略，並掌握 SEO／AEO 對策與上線注意事項

  1. §8.3 兩種網站，兩種策略
  2. §8.6 Vibe Coding 的對話循環
  3. §8.9 vista.tw 的 SEO 與 AEO 對策
  4. §8.11 架設網站的注意事項清單
  5. §8.12 本章小結與行動計畫
🌐

為什麼社群時代還需要自己的網站（§8.1）

社群平臺的觸及會被演算法左右，自己的網站是唯一完全由你掌控的據點，內容與名單都不會因為平臺改規則而消失。

參考書中對應圖示

架設網站的三種路線：為什麼不用 WordPress（§8.2）

🧱

WordPress 等 CMS

功能完整但外掛與維運負擔重，容易愈用愈慢、愈用愈難改

🎛️

無程式碼建站工具

上手快，但客製與效能調整空間有限

✨

Vibe Coding 直接生成

從一開始就照你的需求量身打造，沒有用不到的多餘功能

內容型網站 vs. 互動型應用（§8.3）

內容型網站（如 vista.tw）

  • ✓ 以文章、知識內容為主，重視 SEO 與長期累積
  • ✓ 目標是被搜尋到、建立專業信任感

互動型應用（如 solo.tw）

  • ✓ 有使用者輸入、資料儲存、互動邏輯
  • ✓ 目標是解決一個具體任務或提供一項服務（參考書中對應圖示）

打造內容型網站：vista.tw 的誕生（§8.4）

  • 起點

    從一個明確的內容定位出發，先想清楚要為誰解決什麼問題

  • 技術選擇

    靜態網站生成＋雲端平臺託管，兼顧速度與維運簡便

  • 內容架構

    文章分類、標籤系統，方便日後擴充與交叉引用

  • 持續迭代

    上線只是開始，內容與版面都會依數據持續調整

打造互動型應用：solo.tw 的實作（§8.5）

  • 起點

    從一個具體的使用者任務出發：讓使用者能完成某個操作

  • 技術選擇

    需要後端邏輯與資料庫，處理使用者輸入與儲存

  • 介面設計

    互動型應用更重視操作流程是否順手，而非文章排版

  • 安全性

    涉及使用者資料時，權限與驗證機制不能省略

vista.tw 與 solo.tw 的技術架構對照（§8.4～8.5）

graph TD A[vista.tw<br/>內容型] --> A1[靜態頁面生成] A --> A2[雲端平臺託管] B[solo.tw<br/>互動型] --> B1[前端介面] B --> B2[後端邏輯與資料庫] B --> B3[使用者驗證與權限]

參考書中對應圖示

Vibe Coding 的對話循環（§8.6）

graph LR A[描述這一步要做什麼] --> B[AI 產出對應程式碼] B --> C[實際瀏覽確認效果] C --> D[提出下一步修正或新功能] D --> A

參考書中對應圖示

迭代與最佳化：讓網站愈來愈好（§8.7）

1

上線後持續觀察

哪些頁面被看得多、哪些功能被用得少

2

小幅度調整版面

每次改一個區塊，方便觀察效果

3

蒐集真實回饋

請身邊的人實際操作一次，記錄卡關的地方

4

定期回顧內容

過時的資訊要更新，沒有人看的內容可以下架

部署上線：讓全世界看到你的作品（§8.8）

1

準備一個網域名稱

可用現成網域，或先用平臺提供的免費子網域測試

2

選擇雲端託管平臺

多數提供免費方案，適合個人與小型專案起步

3

連接程式碼倉庫

設定好之後，之後每次更新都能自動部署

4

正式上線前檢查

確認手機版顯示正常、連結沒有壞掉

傳統 SEO vs. AEO（§8.9）

傳統 SEO

  • ✓ 目標是在搜尋引擎結果頁被點擊
  • ✓ 關鍵字、內鏈、頁面速度是主要優化重點

AEO（AI 引擎優化）

  • ✓ 目標是被 AI 助手直接引用或摘要回答
  • ✓ 結構化資料、清楚的問答式內容格式更重要（參考書中對應圖示）

Topic Cluster 內容架構（§8.9）

graph TD A[核心主題頁<br/>Pillar Page] --> B[子主題文章一] A --> C[子主題文章二] A --> D[子主題文章三] B -.互相連結.-> C C -.互相連結.-> D

參考書中對應圖示

Schema.org 結構化資料（§8.9）

  • 是什麼

    在網頁中加上機器看得懂的標記，說明「這是一篇文章」「這是一個常見問答」

  • 為什麼重要

    幫助搜尋引擎與 AI 助手更精準理解頁面內容的性質

  • 常見型別

    文章、常見問答、課程、產品，各有對應的標記格式

  • 實作方式

    請 AI 直接依你的頁面內容產生對應的結構化資料標記

E-E-A-T：AI 如何評估內容可信度（§8.9）

🧪 Experience 經驗 內容展現出真實的第一手經驗
🎓 Expertise 專業 展現對主題有足夠的專業深度
🏛️ Authoritativeness 權威：在該領域有可辨識的信譽
🔒 Trustworthiness 可信：資訊正確、來源透明、安全
🔍

AEO 實際成效：搜尋出現「AI 感」案例（§8.9）

當內容結構清楚、問答式段落明確時，AI 助手在回答使用者問題時，會直接摘要並附上你的網站作為來源。

參考書中對應圖示

五步驟 SEO／AEO 實作流程（§8.9～8.10）

graph LR A[選定核心主題] --> B[規劃 Topic Cluster] B --> C[產出結構化內容] C --> D[加上 Schema 標記] D --> E[追蹤數據並迭代]

參考書中對應圖示

內容行銷漏斗（§8.10）

觸及 透過搜尋與分享被看見
閱讀 停留並讀完內容
信任 持續回訪、訂閱電子報
行動 諮詢、購買或推薦給他人

品質 vs. 數量策略（§8.10）

深耕品質

  • ✓ 少量但深入的內容，建立專業信任
  • ✓ 適合專業領域、需要長期口碑的定位

擴大數量

  • ✓ 大量涵蓋長尾關鍵字，擴大觸及面
  • ✓ 適合資源充足、需要快速覆蓋主題的階段

ClusterCTA 元件設計（§8.10）

  • 是什麼

    在內容頁面適當位置嵌入的行動呼籲元件，串連到相關主題或名單磁鐵

  • 放置時機

    讀者讀完一段有共鳴的內容後，是最適合出現的時機

  • 設計原則

    不打斷閱讀節奏，但要清楚可見、一鍵可點

  • 與內容行銷漏斗呼應

    把「閱讀」階段的讀者，順勢帶往「信任」與「行動」階段

架設網站的注意事項清單：網域與 DNS（§8.11）

☐
網域名稱是否好記、與品牌一致
☐
DNS 設定是否正確指向託管平臺
☐
是否啟用 HTTPS 安全連線
☐
網域到期日是否設定自動續約提醒

架設網站的注意事項清單：效能、安全性與維運（§8.11）

☐
圖片是否壓縮，避免拖慢載入速度
☐
是否有基本的表單防濫用機制
☐
是否設定備份，避免資料遺失求助無門
☐
是否有簡單的監控機制，網站掛掉能第一時間知道

本章小結與行動計畫（§8.12）

  • 今天就決定你的第一個網站要做什麼

    內容型還是互動型，先選一個方向

  • 先求上線，再求完美

    一個簡單但能運作的網站，勝過永遠沒上線的完美構想

  • SEO／AEO 是長期工程

    不會一夜之間看到成效，但持續累積會有複利效果

  • 把上線注意事項清單存起來

    每次上線新網站前都拿出來對照一次

✍️ Practice

課堂演練：內容型 vs. 互動型判斷（§8.3）

  1. 1 用一句話描述你自己想做的一個小型網站
  2. 2 對照書中「兩種網站，兩種策略」的判斷標準，決定它比較接近內容型還是互動型
  3. 3 寫下一個理由：為什麼你這樣判斷
  4. 4 與旁邊同學互相分享，看看別人是否有不同的判斷角度
⏱ 10 分鐘 📎 無需上機，紙筆討論即可

隨堂問答（第8章）

☐
SEO 與 AEO 的差異是什麼？
☐
免費方案架站可能會遇到哪些限制？
☐
部署上線的基本步驟大致有哪些？

參考答案（第8章）

  • Q1

    SEO 讓網頁在搜尋結果被點擊，AEO 讓內容被 AI 助手直接引用或摘要回答，兩者都需要結構清楚的內容

  • Q2

    流量、儲存空間、自訂網域或進階功能可能受限，尖峰時段效能也可能打折

  • Q3

    準備網域名稱、選擇雲端託管平臺、連接程式碼倉庫、正式上線前檢查

本章重點回顧（第8章）

01

先分清內容型還是互動型

兩種網站的技術選擇與設計重點完全不同

02

對話循環貫穿全程

描述→產出→確認→修正，反覆進行到上線

03

SEO 與 AEO 要一起顧

結構清楚的內容，同時對人與 AI 都友善

04

上線前查一次注意事項清單

網域、效能、安全性、維運監控缺一不可

09

名單磁鐵工具——打造你的自動化獲客系統

書中頁碼 9-2～9-25・學習目標：理解名單磁鐵的價值與六階段開發流程，並認識基本的安全性設計

  1. §9.1 什麼是名單磁鐵
  2. §9.3 從需求訪談到上線的完整流程
  3. §9.4 用 Vibe Coding 打造名單磁鐵系統
  4. §9.5 客製化與迭代最佳化技巧
  5. §9.6 實戰成果與本章回顧

社群觸及下降 vs. Email 直達優勢（§9.1）

社群平臺觸及

  • ✓ 受演算法左右，觸及率逐年下降
  • ✓ 廣告成本持續上升，觸及成本愈來愈高

Email 名單

  • ✓ 一旦取得，直接送達不受平臺演算法影響
  • ✓ 是你真正「擁有」的資產（參考書中圖 9-2）

什麼是名單磁鐵：數位行銷核心概念（§9.1）

  • 定義

    用一項免費且有價值的資源，換取潛在客戶的聯絡方式

  • 核心邏輯

    對方先體驗到價值，才願意留下 Email 等聯絡資訊

  • 常見形式

    電子書、範本、清單、免費課程試看

  • 最終目的

    建立一份能持續溝通的潛在客戶名單（參考書中圖 9-3、9-4：名單磁鐵運作流程與好的名單磁鐵的特徵）

常見名單磁鐵類型（§9.1）

📘 電子書／指南 解決一個具體問題
📋 範本／清單 直接可用，降低對方的行動門檻
🎁 免費試用 免費試看或試用
📊 診斷工具 互動式自我檢測，換取聯絡方式（參考書中圖 9-5）

小型團隊與自由工作者的行銷需求（§9.2）

  • 資源有限

    沒有大團隊，需要能自己一手包辦的解決方案

  • 需要自動化

    沒有人力隨時手動回覆，系統要能自動運作

  • 重視轉換品質

    名單數量不是重點，能不能轉換成客戶才是關鍵

  • 成本敏感

    Vibe Coding 讓自架系統的成本大幅降低

從需求到上線的六階段流程（§9.3）

graph LR A[Phase1<br/>需求訪談] --> B[Phase2<br/>規劃頁面與流程] B --> C[Phase3<br/>開發表單與後端] C --> D[Phase4<br/>串接自動寄信] D --> E[Phase5<br/>測試驗收] E --> F[Phase6<br/>部署上線]

參考書中圖 9-11：從需求到上線的完整流程（六階段 Phase）

名單磁鐵系統架構一覽（§9.4）

graph TD A[前端表單<br/>Landing Page] --> B[API 端點] B --> C[資料庫<br/>儲存名單] B --> D[自動寄信服務] D --> E[歡迎信與後續序列]

參考書中圖 9-9：系統架構一覽

安全性設計三機制（§9.4）

☐
Honeypot 防垃圾機制 設一個對真人隱藏的欄位，機器人填了就判定為垃圾送出
☐
Rate Limiting 速率限制 限制同一來源短時間內的送出次數，防止濫用
☐
Token 時效性 驗證連結加上時間限制，過期就要求重新申請

轉換漏斗分析（§9.5）

造訪頁面 看到名單磁鐵的宣傳
點擊 對內容產生興趣，點進 Landing Page
填寫表單 留下 Email 等聯絡資訊
完成訂閱 確認信箱並成功加入名單

自動 Email 序列與 PDCA 最佳化（§9.5）

graph LR A[Day 0<br/>歡迎信] --> B[Day 2<br/>價值內容] B --> C[Day 5<br/>案例分享] C --> D[Day 7<br/>行動呼籲] D -.PDCA 持續最佳化.-> A

參考書中圖 9-27、9-28：自動 Email 序列與持續最佳化的循環（PDCA）

✍️ Practice

課堂演練：動手練習（沿用書中§9.6原文）

  1. 1 想一想你的目標客群是誰？他們有什麼痛點？
  2. 2 你能提供什麼免費資源來解決這個痛點？
  3. 3 試著用本章學到的提示詞結構，向 AI 描述你的名單磁鐵需求
  4. 4 從 Landing Page 開始，一步一步做出你自己的名單磁鐵系統！
⏱ 15 分鐘 📎 紙筆或線上文件，分組討論

隨堂問答（第9章）

☐
名單磁鐵的定義是什麼？
☐
從需求到上線的六階段流程，依序是什麼？
☐
安全性設計的三項機制分別是什麼？

參考答案（第9章）

  • Q1

    用一項免費且有價值的資源，換取潛在客戶的聯絡方式，藉此建立可持續溝通的名單

  • Q2

    需求訪談→規劃頁面與流程→開發表單與後端→串接自動寄信→測試驗收→部署上線

  • Q3

    Honeypot 防垃圾機制、Rate Limiting 速率限制、Token 時效性

本章重點回顧（第9章）

01

名單磁鐵是數位行銷的基礎

用免費價值換取潛在客戶名單，Email 名單是你擁有的資產

02

零成本也能打造完整系統

Vibe Coding 讓自架系統門檻大幅降低

03

六階段流程清楚可循

需求訪談、分階段開發、測試與部署上線

04

上線只是開始

持續用 A/B 測試與轉換漏斗分析最佳化

10

品牌銷售頁

書中頁碼 10-2～10-24・學習目標：熟悉 AIDA 模型與 FAB 法則，並能結合設計思維打造一頁銷售頁

  1. §10.1 什麼是銷售頁
  2. §10.3 設計思維結合 AI 開發的方法論
  3. §10.4 用 Vibe Coding 打造銷售頁
  4. §10.5 A/B 測試與持續最佳化
  5. §10.6 實戰成果與本章回顧

銷售頁 vs. 一般網頁（§10.1）

一般網頁

  • ✓ 提供多元資訊，訪客可以自由瀏覽多個方向
  • ✓ 目標比較分散，不強求單一行動

銷售頁

  • ✓ 為了讓訪客採取特定行動而設計的獨立頁面
  • ✓ 整頁內容都指向同一個目標行動（參考書中圖 10-1：銷售頁 vs 一般網頁）

AIDA 模型（§10.1）

graph LR A[Attention<br/>注意力] --> I[Interest<br/>興趣] I --> D[Desire<br/>渴望] D --> Ac[Action<br/>行動]

參考書中圖 10-2：AIDA 模型

銷售頁七層核心結構與 AIDA 對應（§10.1）

  • Hero 區塊

    對應 Attention，一眼抓住注意力

  • 痛點與價值主張

    對應 Interest，講出對方的處境

  • 功能與見證

    對應 Desire，堆疊渴望與信任

  • 定價與 FAQ

    對應 Desire 到 Action 的過渡，消除疑慮

  • 最終 CTA

    對應 Action，明確的行動呼籲（參考書中圖 10-3：銷售頁七層核心結構與 AIDA 對應）

FAB 法則（§10.1）

🔧

Feature 特徵

這個產品或服務「是什麼」

⬆️

Advantage 優勢

它「比別的方案好在哪裡」

🎯

Benefit 利益

對方能得到什麼，說服力遞增

✍️ Practice

課堂暖身：文案小練習（沿用書中§10.1原文）

  1. 1 拿出你的產品或服務，試著用 FAB 法則寫出三個版本的介紹
  2. 2 先寫 Feature，再加上 Advantage，最後寫出 Benefit
  3. 3 你會發現，每一層的說服力都在持續遞增
⏱ 8 分鐘 📎 每人一個自己的產品或服務構想

場景：新產品上市的銷售頁需求（§10.2）

  • 典型情境

    產品準備好了，需要一個能收單、能說服人的頁面

  • 常見痛點

    不知道怎麼把功能講成利益，文案寫得像規格表

  • 時間壓力

    通常希望能在很短時間內看到成品上線

  • Vibe Coding 的角色

    把設計思維與 AIDA/FAB 的方法論，快速落地成一個真實頁面

設計思維五步驟結合 AI 開發（§10.3）

1

同理

理解目標客群真正的處境與痛點

2

定義

用一句話定義這個銷售頁要解決的核心問題

3

發想

列出可能的文案角度與版面配置

4

原型

請 AI 快速產出可預覽的第一版頁面

5

測試

找真實使用者操作，蒐集回饋再修正

用 Vibe Coding 打造銷售頁的六個關鍵細節（§10.4）

三欄定價的心理學

中間或右側選項用視覺強調，善用錨定效應

社會證明

見證、案例、數字，讓別人幫你說話

色彩與排版層次

重點資訊用對比色，視覺動線引導閱讀順序

無障礙與效能

在提示詞中直接列出對比度與速度規範

動畫效果

滑入、懸停、展開收合，適度使用

FAQ 手風琴

消除購買前的最後疑慮

A/B 測試與持續最佳化（§10.5）

版本 A

  • ✓ 維持現行文案與版面
  • ✓ 作為對照基準

版本 B

  • ✓ 調整一項變數，例如 CTA 文字或定價呈現方式
  • ✓ 比較轉換率，用數據決定保留哪一版
🏆 Practice

章末挑戰（沿用書中§10.6原文，當分組實作或期末專案題）

  1. 1 選擇你自己的一個產品或服務，用本章學到的方法打造一個銷售頁
  2. 2 先用 AIDA ＋ FAB 寫好文案
  3. 3 再用文案健檢工具分析一次
  4. 4 然後用 Vibe Coding 把它變成一個真正的網頁
  5. 5 你會驚訝於自己能做出如此專業的成果
⏱ 視課程安排（建議一週以上） 📎 每人一個自己的產品或服務

隨堂問答（第10章）

☐
AIDA 模型的四個階段依序是什麼？
☐
FAB 法則的三個字母分別代表什麼？
☐
銷售頁與一般網頁最根本的差異是什麼？

參考答案（第10章）

  • Q1

    Attention（注意力）→ Interest（興趣）→ Desire（渴望）→ Action（行動）

  • Q2

    Feature（特徵）、Advantage（優勢）、Benefit（利益）

  • Q3

    銷售頁是為了讓訪客採取特定行動而設計的獨立頁面，一般網頁的目標較分散

本章重點回顧（第10章）

01

銷售頁的本質

為了讓訪客採取特定行動而設計的獨立頁面，七層結構各司其職

02

AIDA 是心理學基礎

每個區塊都對應模型中的某個階段

03

設計思維是系統化方法

同理→定義→發想→原型→測試

04

四步驟打造＋科學化最佳化

寫 Prompt→AI 生成→多輪最佳化→部署上線，再用 A/B 測試持續提升

11

數據分析儀表板

書中頁碼 11-2～11-40・學習目標：理解資料視覺化的三個層次，並走過從 Excel 到互動式儀表板的六步驟

  1. §11.2 作者現身說法：流量分析儀表板
  2. §11.4 臺灣中小企業的數據可視化需求
  3. §11.5 從 Excel 到互動式儀表板
  4. §11.6 用 Vibe Coding 打造儀表板
  5. §11.7 數據驅動決策的思維建立

儀表板 vs. Excel 報表（§11.1）

Excel 報表

  • ✓ 適合單次分析與精細運算
  • ✓ 要看趨勢通常要手動重新整理

互動式儀表板

  • ✓ 資料即時更新，一眼看到最新狀態
  • ✓ 可篩選、可下鑽，適合持續追蹤（參考書中圖 11-2：儀表板 vs Excel 報表）

資料視覺化的三個層次（§11.1）

看得到

資料被畫成圖表，而不是埋在一堆數字裡

看得懂

圖表選型正確，一眼就能理解在講什麼

看得準

資料本身正確、更新即時，能拿來做決策（參考書中圖 11-5）

Vista.tw 網站後臺技術架構（§11.2）

graph TD A[Cloudflare Pages<br/>網站前臺] --> B[Cloudflare Workers<br/>後端邏輯] B --> C[D1 資料庫] B --> D[KV 儲存]

參考書中圖 11-6：Vista.tw 網站後臺技術架構

作者現身說法：流量儀表板與名單管理系統（§11.2～11.3）

  • 流量分析儀表板

    整合網站流量數據，用 KPI 卡與圖表呈現每日趨勢

  • KPI 卡的色彩語意

    用顏色直覺傳達數字是好轉還是惡化，不用細讀才懂

  • 名單管理系統

    整合訂閱名單，用轉換漏斗分析掌握每個環節的表現

  • 共同心法

    兩個系統都是先有真實需求，才決定要做哪些圖表

五個臺灣中小企業場景（§11.4）

☕ 咖啡連鎖 追蹤各門市的每日營收與熱銷品項
🛍️ 電商 掌握轉換率與客單價的變化趨勢
📚 補習班 追蹤招生與續報率
🎨 設計工作室 掌握專案與工時
🍜 餐飲業 追蹤尖離峰來客數

從 Excel 到互動式儀表板：六步驟（§11.5）

1

整理 Excel 資料結構並轉成標準格式

確保欄位一致、沒有雜亂的合併儲存格，常見是轉成 CSV 或 JSON

2

選定圖表類型

依資料性質選折線、長條或圓餅圖

3

請 AI 產出第一版儀表板

描述資料結構與想看到的圖表

4

加上篩選與互動功能

依日期、分店等維度篩選檢視

5

部署分享

讓相關同事都能即時查看最新數據

常見圖表類型選擇指南（§11.5）

  • 折線圖

    適合呈現一段時間內的趨勢變化

  • 長條圖

    適合比較不同類別之間的數量差異

  • 圓餅圖

    適合呈現整體中各部分的佔比（類別不宜過多）

  • 漏斗圖

    適合呈現多階段流程的轉換情形

第一個儀表板的 Prompt 示範（§11.6）

PROMPT 
我有一份咖啡店的每週營收 Excel（欄位：日期、門市、營收、來客數）。
請幫我做一個網頁儀表板：
1. 上方顯示本週總營收、總來客數兩張 KPI 卡
2. 下方用折線圖呈現每日營收趨勢
3. 加上門市篩選功能
OUTPUT
已完成第一版儀表板：頁面上方顯示「本週總營收」與「總來客數」兩張 KPI 卡，下方是每日營收趨勢折線圖，並提供門市下拉選單可篩選檢視個別門市的數據。

儀表板的部署方式比較（§11.6）

雲端平臺託管

  • ✓ 設定簡單，免費方案即可起步
  • ✓ 適合個人與小型團隊

自架伺服器

  • ✓ 掌控度更高，適合有特殊資安需求的情境
  • ✓ 維運成本與技術門檻也更高

數據驅動決策框架：五階段循環（§11.7）

graph LR A[蒐集數據] --> B[視覺化呈現] B --> C[發現洞察] C --> D[做出決策] D --> E[追蹤成效] E --> A

參考書中圖 11-35：數據驅動決策框架（5 階段循環）

SMART KPI 設定原則（§11.7）

S Specific 目標要具體明確
M Measurable 要能被量化衡量
A Achievable 要是努力可達成的
R Relevant 要與整體目標相關
T Time-bound 要有明確的時間期限（參考書中圖 11-37：KPI 設定方法）

建立團隊的數據文化（§11.7）

  • 讓數據人人可見

    不是只有主管才看得到儀表板

  • 固定回顧節奏

    每週或每月固定花時間一起看數據、討論行動

  • 鼓勵提出假設

    看到異常時鼓勵團隊提出可能原因並驗證

  • 把數據跟決策綁在一起

    避免有數據卻依然憑感覺做決定

五個案例的實戰成果總覽（§11.8）

  • 咖啡連鎖

    掌握各門市表現，快速找出需要支援的分店

  • 電商與補習班

    轉換率與續報率的變化能更快被發現並回應

  • 設計工作室與餐飲業

    工時與尖峰時段的掌握，讓排班與排程更有依據

  • 共同成果

    從「憑印象猜測」轉變為「用數據支持決策」

✍️ Practice

課堂演練：套用六步驟寫出圖表提示詞（§11.5～11.6）

  1. 1 情境（示範用）：一家小吃店記錄了本週每天的營業額與來客數
  2. 2 依照六步驟，先想清楚要看哪些圖表（例如每日營業額趨勢、平均客單價）
  3. 3 寫出一段完整的提示詞，請 AI 依這份資料做出一個簡單的儀表板
  4. 4 與同學互相檢查：提示詞裡有沒有講清楚資料結構、想看的圖表、篩選需求
⏱ 15 分鐘 📎 講義附上示範用資料情境（某小吃店一週營業額，僅供練習使用）

隨堂問答（第11章）

☐
資料視覺化的三個層次是什麼？
☐
SMART KPI 設定原則的五個字母分別代表什麼？
☐
從 Excel 到互動式儀表板的六步驟，第一步是什麼？

參考答案（第11章）

  • Q1

    看得到、看得懂、看得準

  • Q2

    Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（相關）、Time-bound（有期限）

  • Q3

    整理 Excel 資料結構，確保欄位一致、沒有雜亂的合併儲存格

本章重點回顧（第11章）

01

三個層次缺一不可

看得到、看得懂、看得準

02

六步驟從 Excel 到儀表板

整理資料→轉格式→選圖表→請AI產出→加互動→部署分享

03

SMART 讓 KPI 有意義

具體、可衡量、可達成、相關、有期限

04

數據文化比工具更重要

固定回顧節奏、把決策跟數據綁在一起

12

品質把關——Vibe Coding 的風險管理

書中頁碼 12-2～12-23・學習目標：認識 AI 生成程式碼的常見品質問題，並學會用非技術版檢查清單把關

  1. §12.1 AI 程式碼真的可靠嗎
  2. §12.3 AI 生成程式碼的常見品質問題
  3. §12.4 安全性檢查清單（非技術版）
  4. §12.5 效能與可維護性的基本概念
  5. §12.6 什麼時候該尋求專業工程師的協助

AI 程式碼信任光譜（§12.1）

  • 不要完全不信任

    AI 生成的程式碼絕大多數情況下是可用的，不用逢生成必疑

  • 也不要盲目信任

    重要功能、涉及金流或個資的部分，一定要驗證

  • 信任程度隨風險調整

    個人小工具可以寬鬆一點，對外服務就要嚴謹一點

  • 本章的目標

    幫你建立判斷「這段該不該多檢查一次」的直覺

四個真實案例：安全性／效能／正確性／可維護性（§12.2）

安全性案例

表單沒有防護機制，遭到惡意大量灌水

效能案例

圖片沒有壓縮，網站載入速度過慢流失訪客

正確性案例

折扣邏輯有漏洞，導致優惠被重複疊加

可維護性案例

程式碼缺乏註解，之後接手的人難以理解修改

AI 生成程式碼五大品質問題（§12.3）

👻 幻覺程式碼 引用了根本不存在的功能或套件
📦 過時套件引用 使用已棄用或有疑慮的舊套件
⚠️ 缺少錯誤處理 沒有考慮到異常情況會怎麼發生
🔢 寫死的數值 把可調整的數字寫死在程式碼中
🕳️ 邏輯漏洞 例如折扣可以被重複疊加領取

10x

十倍法則

問題發現時機 vs. 修復成本

愈晚發現問題，修復成本呈倍數增加

設計階段就發現，成本最低

上線後才發現，成本可能高出十倍以上

安全性檢查清單（非技術版）（§12.4）

☐
重要功能是否要求使用者登入或驗證身分
☐
表單是否有防止機器人濫用的機制
☐
是否使用 HTTPS 安全連線
☐
密碼、金鑰等敏感資訊是否避免直接寫在程式碼裡
☐
使用者輸入的內容是否有做基本檢查，避免惡意輸入

效能的基本概念：三步驟自我檢測（§12.5）

  • 測試載入速度

    用免費線上工具檢測網頁開啟需要多久

  • 檢查圖片大小

    過大的圖片檔案是最常見的效能殺手

  • 觀察操作流暢度

    實際點擊每個功能，感受有沒有明顯卡頓

技術債：可維護 vs. 難維護的程式碼（§12.5）

可維護的程式碼

  • ✓ 結構清楚、有適當註解
  • ✓ 之後接手的人（甚至是自己）能快速看懂

難維護的程式碼

  • ✓ 為了求快堆疊出來，缺乏結構與註解
  • ✓ 像信用卡債一樣，愈晚處理利息愈高

自己處理 vs. 找工程師？決策樹（§12.6）

graph TD A{涉及金流或個資?} -->|是| B[建議找專業工程師] A -->|否| C{規模是否持續擴大?} C -->|是| D[考慮尋求協助做架構檢視] C -->|否| E[可自行用檢查清單把關]

參考書中圖 12-27：自己處理 vs 找工程師？決策樹

找工程師的管道與費用參考（§12.6）

  • 接案平臺

    適合單次、範圍明確的需求

  • 自由工作者社群

    適合需要長期合作、逐步累積信任的關係

  • 費用區間因案而異

    建議先取得需求範圍再詢價，避免範圍不清造成爭議

  • 找對人比找便宜更重要

    尤其是涉及資安與架構的工作

✍️ Practice

課堂演練：套用檢查清單逐項檢查（示範用程式碼片段）

  1. 1 講義提供一段示範用的表單處理程式碼片段
  2. 2 對照本章「安全性檢查清單（非技術版）」逐項檢查，圈出可能有疑慮的地方
  3. 3 寫下一句話：如果要請 AI 修正，你會怎麼描述這個問題
  4. 4 與同學互相比對，看看有沒有漏掉的檢查項目
⏱ 15 分鐘 📎 講義附上一段標明「示範用」的簡短程式碼片段

隨堂問答（第12章）

☐
AI 生成程式碼的五大品質問題，請舉出其中兩項？
☐
「十倍法則」在講什麼？
☐
什麼情況下應該考慮找專業工程師協助？

參考答案（第12章）

  • Q1

    幻覺程式碼、過時套件引用、缺少錯誤處理、寫死的數值、邏輯漏洞（任舉兩項即可）

  • Q2

    愈晚發現問題，修復成本愈高，可能高出設計階段十倍以上

  • Q3

    涉及金流或個資、系統規模持續擴大、超出自己判斷把關能力的情況

本章重點回顧（第12章）

01

信任要有分寸

不完全不信任，也不盲目信任

02

五大品質問題要留意

幻覺程式碼、過時套件、缺錯誤處理、寫死數值、邏輯漏洞

03

愈早檢查愈划算

十倍法則提醒我們，問題拖到上線後成本更高

04

知道何時該找專業協助

涉及金流、個資或規模擴大時，別硬撐

13

從 Vibe Coder 到 Citizen Developer

書中頁碼 13-2～13-21・學習目標：認識 Citizen Developer 的定義與學習階段，並了解組織推廣的策略與跟 IT 部門的協作模式

  1. §13.1 持續學習路線圖與推薦資源
  2. §13.2 建立個人的 Vibe Coding 工作流程
  3. §13.4 在組織內推廣 Vibe Coding 的策略
  4. §13.5 與 IT 部門建立協作模式

Citizen Developer 的定義與三大核心特質（§13.1）

  • 定義

    不具備專業工程背景，但能用低程式碼或 AI 工具自行開發解決方案的人

  • 特質一：解決問題導向

    從真實的工作痛點出發，而不是為了學技術而學

  • 特質二：願意持續迭代

    不追求一次到位，習慣用小步快跑的方式修正

  • 特質三：懂得判斷邊界

    知道什麼該自己做、什麼該尋求專業協助

學習的三個階段：探索、成長、成熟（§13.1）

1

探索期

嘗試各種小工具與練習，建立基本信心

2

成長期

開始把 Vibe Coding 用在真實的工作任務上

3

成熟期

能獨立規劃並完成中大型專案，甚至開始帶動身邊的人

建立個人工作流程與 Prompt 範本庫（§13.2）

  • 固定的工具組合

    不用每次都重新選擇，減少決策成本

  • 建立個人 Prompt 範本庫

    把好用的提示詞存起來，下次直接套用微調

  • 定期回顧與更新

    隨著經驗累積，範本也要跟著優化

  • 分享出去

    範本庫也是最好的入門教材，能幫助身邊的人

三個臺灣中小企業推廣案例（§13.3）

案例一

從一位員工自發使用，到主管注意到效率提升，逐步擴大應用範圍

案例二

老闆帶頭示範，帶動全團隊採用意願

案例三

從單一部門工具，擴散成跨部門標準流程

組織推廣 Vibe Coding 的四個階段（§13.4）

graph LR A[個人試用<br/>累積小型成功案例] --> B[部門擴散<br/>分享成果與範本] B --> C[跨部門推廣<br/>建立共同規範] C --> D[制度化<br/>納入正式工作流程]

參考書中圖 13-13：組織推廣 Vibe Coding 的四個階段

克服推廣阻力的實用策略（§13.4）

☐
先累積一兩個小而具體的成功案例，用實績說服比用理論說服有效
☐
主動分享自己踩過的坑，降低其他人嘗試的心理門檻
☐
找到願意帶頭示範的關鍵人物（愈高階愈好）
☐
不強迫所有人一次到位，允許不同步調並存

Vibe Coder 與 IT 部門的協作模式（§13.5）

Vibe Coder 的角色

  • 負責快速回應部門內的具體需求
  • 熟悉業務場景，知道真正的痛點在哪裡

IT 部門的角色

  • 把關系統安全性、資料治理與整體架構
  • 提供標準與工具，避免各自為政造成混亂
✍️ Practice

課堂演練：向主管申請學習時間的提示詞（§13.4）

  1. 1 想像你要向主管爭取一些時間學習 Vibe Coding
  2. 2 參考書中臺灣案例的說服角度，寫一段給 AI 的提示詞，請它幫你草擬一份簡短的申請說明
  3. 3 提示詞裡至少要包含：預期效益、需要的時間、可能的風險與因應方式
  4. 4 與旁邊同學互相交換，給對方一句具體的修改建議
⏱ 10 分鐘 📎 無需上機，紙筆討論即可

隨堂問答（第13章）

☐
Citizen Developer 的三大核心特質是什麼？
☐
組織推廣 Vibe Coding 的四個階段依序是什麼？
☐
Vibe Coder 與 IT 部門的協作，各自的角色重點是什麼？

參考答案（第13章）

  • Q1

    解決問題導向、願意持續迭代、懂得判斷邊界

  • Q2

    個人試用→部門擴散→跨部門推廣→制度化

  • Q3

    Vibe Coder 熟悉業務痛點、快速回應需求；IT 部門把關安全性與整體架構、提供標準與工具

本章重點回顧（第13章）

01

Citizen Developer 不是頭銜是能力

解決問題導向、願意迭代、懂得判斷邊界

02

個人成長有階段性

探索期、成長期、成熟期，不用急著跳級

03

推廣靠實績不靠理論

一兩個具體成功案例勝過長篇說明

04

與 IT 部門是協作不是對立

角色分工清楚，才能又快又安全

十三章知識地圖總覽：貫穿全書的方法論框架

graph LR A[CLEAR<br/>第5章：提示詞框架] --> B[AIDA／FAB<br/>第10章：銷售頁文案] A --> C[PDCA<br/>第9、11章：持續最佳化] C --> D[SMART<br/>第11章：KPI設定] A --> E[十倍法則<br/>第12章：品質把關] A --> F[Vibe Coder三階段<br/>第13章：個人成長]

整理自第 5、9、10、11、12、13 章重複出現的方法論框架，非書中原圖

貫穿全書的六大框架一覽卡

CLEAR（§5.3）

Context、Language、Examples、Audience、Requirements，寫出好提示詞的五個字母

AIDA（§10.1）

Attention→Interest→Desire→Action，銷售頁文案的心理學基礎

FAB（§10.1）

Feature、Advantage、Benefit，說服力層層遞增的介紹法

PDCA（§9.5、§11.7）

Plan-Do-Check-Act，名單磁鐵與數據儀表板持續最佳化的共同邏輯

SMART（§11.7）

Specific、Measurable、Achievable、Relevant、Time-bound，設定有意義的 KPI

Vibe Coder 三階段（§13.1）

探索期→成長期→成熟期，個人成長路徑

期末總複習問答（1）：第 1-7 章

第 1-4 章

  • 第1章：核心工作流程循環是哪三個步驟？
  • 第2章：三大主流 AI 助手是哪三個？
  • 第3章：不想碰程式碼，適合用哪款工具？
  • 第4章：迭代最佳化的核心邏輯是什麼？

第 5-7 章

  • 第5章：CLEAR 框架的五個字母代表什麼？
  • 第6章：程式碼的三個基本邏輯積木是什麼？
  • 第7章：Debug 的三個步驟依序是什麼？

期末總複習問答（2）：第 8-13 章

第 8-10 章

  • 第8章：SEO 與 AEO 的差異是什麼？
  • 第9章：名單磁鐵的定義是什麼？
  • 第10章：AIDA 模型的四個階段依序是什麼？

第 11-13 章

  • 第11章：SMART 五個字母代表什麼？
  • 第12章：五大品質問題，請舉兩項？
  • 第13章：Citizen Developer 三大特質？

參考答案（對應前兩頁）

第 1-7 章答案

  • 1. 描述→生成→迭代
  • 2. ChatGPT、Claude、Gemini
  • 3. Lovable（或 Antigravity）
  • 4. 需求→產出→測試→修正，反覆循環
  • 5. Context、Language、Examples、Audience、Requirements
  • 6. 依序執行、條件判斷、重複迴圈
  • 7. 重現問題→定位問題→修復並驗證

第 8-13 章答案

  • 8. SEO 讓網頁被搜尋點擊，AEO 讓內容被 AI 助手引用回答
  • 9. 用免費價值換取潛在客戶的聯絡方式
  • 10. Attention→Interest→Desire→Action
  • 11. Specific、Measurable、Achievable、Relevant、Time-bound
  • 12. 幻覺程式碼、過時套件引用、缺少錯誤處理、寫死的數值、邏輯漏洞（任舉兩項）
  • 13. 解決問題導向、願意持續迭代、懂得判斷邊界

依課程長度的排課建議

1

12 週大學課程

每週約 1 章，第2-3、6-7章可合併，期末週留給第10章分組發表

2

1-2 天企業工作坊

濃縮抽選第 1、5、8、9、10 章為核心，其餘章節列為課後自學教材

3

4 週自學讀書會

每週 3-4 章，用問答單元帶討論、用演練單元帶共作，第5章建議獨立安排一週

給老師的課程總複習建議：上完這門課，學生應該能做到的三件事

☐
能用 CLEAR 框架寫出一段清楚的提示詞 不管做什麼任務，先把需求說清楚
☐
能獨立走完一次「描述→生成→迭代→驗收」的流程 從構想到能用的成品，不再需要手把手帶
☐
能用非技術版檢查清單，判斷一段 AI 產出的程式碼能不能放心使用 知道什麼該自己把關、什麼該找專業協助

這堂課結束後，老師可以怎麼延續

  • 建立班級共用的 Prompt 範本庫

    把課堂上出現的好提示詞整理成共用文件，讓學生持續累積

  • 安排定期分享會

    每隔幾週讓學生分享自己做出的新工具，互相學習

  • 設計進階挑戰清單

    從待辦清單 App 畢業後，鼓勵學生挑戰名單磁鐵或銷售頁等更完整的專案

  • 鼓勵組成學習社群

    同儕之間互相除錯、互相檢查提示詞，效果往往比一個人自學更好

給老師的教學提醒與延伸資源

☐
常見學生卡關點 多數卡在「描述不夠具體」，可回頭參考第5章 CLEAR 框架帶討論
☐
時間分配建議 第 5、8、9、10 章方法論與實戰份量重，建議分配較多堂數
☐
如何處理程度落差 讓先完成的學生協助卡關的同學，比老師逐一排除更有效率
☐
書中提示詞範本索引 第5章十個職場場景範本、第9章名單磁鐵動手練習、第10章文案小練習與章末挑戰，皆可直接取用

謝謝

Vista Cheng

《零基礎學 Vibe Coding：用 AI 做出網站、App 與工作自動化工具》

vista.tw

vista.im/vibecoding