描述
內容簡介
|
作者簡介
| 吳睿誠（Ray貓）
自學成才的軟體設計工程師，專精於 AI 應用開發前端視覺開發。 在技術社群擁有廣泛影響力，在 Threads 平台上有著破萬的追蹤者，累積超過 500 篇技術分享文章。曾受邀於JSDC（台灣最大 JavaScript 年會）以及參與過 COSCUP（台灣最大開源軟體活動）皆擔任講者，分享 AI 與未來開發的深度洞察。 曾任台灣大學課程網全端工程師，目前是熊熊幹大事股份有限公司的工程師，同時也是現為新創 Redia 創辦人，致力於用生成式 AI 重新定義學習體驗。
擅長將複雜的概念用簡單的文字、生活化的譬喻讓任何的人都能理解。
GitHub: https://github.com/sr0725 個人網站：https://www.ray-realms.com/ Email: ray@ray-realms.com |
目錄
| 第1 章 從理論到實作的第一步
1.1 什麼是 AI 和 LLM ？ 1.1.1 什麼是 AI ？ 1.1.2 大型語言模型：自動選字的超級進化版 1.1.3 LLM 的運作原理：從預測到推理 1.1.4 AI 開發的兩個世界：訓練 vs 應用 1.2 Token：AI 理解世界的基本單位 1.2.1 如何讓 AI 理解人類語言？ 1.2.2 從食材評分到文字編碼 1.2.3 AI 是怎麼建立一套評分標準，來理解與量化所有文字的？ 1.2.4 Token 切分的藝術與經濟學 1.2.5 「Strawberry」有幾個「r」？ AI ：兩個！ 1.3 旅程的起點，環境搭建 1.3.1 搭建 AI 開發環境 1.3.2 Node.js 環境安裝與專案初始化 1.3.3 為什麼選擇 JavaScript 而非 Python ？ 1.4 打造第一個 AI 對話介面：Discord Bot 1.4.1 你獲得到一個新的任務！建立與 AI 對話窗口 1.4.2 Discord Bot 申請與設定流程 1.4.3 寫一個簡單的 Hello World 1.4.4 範例程式碼 1.4.5 程式碼講解 1.5 環境安全與最佳實踐 1.5.1 你獲得到了一個新的任務！保護敏感資訊 1.5.2 環境變數的使用與管理 1.5.3 範例程式碼 1.5.4 設定 .gitignore 1.6 整合 ChatGPT：為 Bot 注入智慧 1.6.1 你獲得到一個新的任務！讓機器人真正理解對話 1.6.2 OpenAI API 申請與整合 1.6.3 範例程式碼 1.7 多輪對話機制的實現 1.7.1 替我們的機器人加上多輪對話 1.7.2 範例程式碼 1.8 ChatGPT API 進階調校 1.8.1 你獲得到一個新的任務！突破 Token 限制 1.8.2 簡單的字數過濾方案 1.8.3 更精確的 Token 計算 1.8.4 範例程式碼 1.9 控制 AI 的「創意程度」 1.9.1 溫度（Temperature）：從保守到冒險 1.9.2 Top-p：篩選答案的「品質門檻」 1.9.3 Temperature vs Top-p：該用哪個？ 1.10 章節重點觀念整理
第2 章 Prompt Engineering 提示詞工程 2.1 什麼是 Prompt（提示詞） 2.2 什麼是 Prompt Engineering（提示詞工程） 2.3 把 LLM 當成實習生 2.4 你獲得到一個新的任務！ 2.5 第一步，定義你的成功標準 2.5.1 開放式問題 vs 封閉式問題 2.5.2 封閉式問題的成功標準 2.5.3 開放式問題的成功標準 2.6 最簡單但重要的提示詞，零樣本提示（Zero-shot） 2.6.1 什麼是零樣本提示？ 2.6.2 實戰對比：模糊 vs 精確 2.6.3 實際程式碼 2.6.4 根據情緒判斷結果，調整模型 2.6.5 範例程式碼 2.6.6 進階技巧：加入判斷標準 2.7 LLM 應用開發技巧：判斷必須具備容錯 2.8 任務拆解， Workflow 的基礎 2.8.1 你獲得到一個新的任務！ 2.8.2 為什麼要拆解任務？ 2.8.3 任務拆解的三大原則 2.9 少樣本提示（Few-shot）—— 用範例教會 AI 2.9.1 你獲得到一個新的任務！ 2.9.2 什麼是少樣本提示？ 2.9.3 實戰對比：沒有範例 vs 有範例 2.9.4 Discord Bot 實作：加入少樣本提示 2.9.5 進階技巧：動態範例選擇 2.9.6 少樣本提示的最佳實踐 2.10 格式化提示：Markdown 和 XML 2.11 理解 LLM，成為 LLM 2.12 角色提示（Role Prompting）—— 讓 AI 從特定視角思考 2.13 思維鏈提示（Chain of Thought）—— 讓 AI 展現推理過程 2.14 AI 安全性 —— 當 AI 被「駭」了怎麼辦？ 2.14.1 從一個有趣的遊戲說起 2.14.2 設計「猜病名」遊戲 2.14.3 範例程式碼 2.14.4 遊戲開始了... 但玩家不按牌理出牌！ 2.14.5 什麼是 Prompt Injection ？ 2.14.6 攻防大戰：一攻一防的過程 2.14.7 為什麼防不勝防？ 2.14.8 Prompt Injection 的真實危害 2.14.9 如何保護你的 AI 應用？ 2.14.10 記住：安全是持續的過程 2.15 讓 AI 穩定輸出：格式化輸出 2.15.1 什麼是 Zod ？ 2.15.2 為什麼LLM 需要使用 Zod ？ 2.15.3 實戰：改造我們的情緒判斷系統 2.15.4 使用 Zod 改寫情緒判斷函數 2.15.5 更新 Discord Bot 使用新的情緒分析 2.15.6 範例程式碼 2.15.7 格式化輸出的注意事項 2.15.8 小結 2.16 章節重點觀念整理 2.17 章節自我檢測
第3 章 工具調用（Tool Calling）：讓 AI 從出一張嘴到真正做事 3.1 被 AI 奴役的人類 3.2 遊戲指令的啟發 3.2.1 遠古時代，我是怎麼讓 LLM 長出手腳的 . 3.2.2 設計思路與實現 3.2.3 模擬對話範例 3.2.4 早期方案的侷限性 3.3 官方 Function Calling：現代化的解決方案 3.3.1 Function Calling 的誕生背景 3.3.2 從土炮到正規軍：理解 Tool Calling 流程 3.3.3 第一步，告訴 AI 工具該在何時使用、該怎麼使用 3.3.4 深入理解 JSON Schema：定義工具參數的語法 3.3.5 實作：為 Discord Bot 加入筆記功能 3.3.6 實作 Tool 執行函數 3.3.7 讓我們的程式可以解析 AI 使用了哪些工具 3.3.8 執行對應內容 3.3.9 把執行結果回傳給 AI 3.3.10 測試我們的筆記機器人 3.3.11 範例程式碼 3.3.12 進階技巧：優化 Tool Description 3.3.13 Tool Calling 的最佳實踐 3.4 多輪工具調用：讓 AI 學會「連續技」 3.4.1 單次調用的侷限 3.4.2 多輪調用的原理 3.4.3 實作多輪調用 3.4.4 理解 maxToolCalls 參數 3.4.5 改進後的 Discord Bot 3.4.6 範例程式碼 3.4.7 實際範例：多步驟任務 3.4.8 優化技巧：提前終止 3.4.9 調試技巧：追蹤工具調用 3.5 OpenAI 官方工具：讓 AI 接入真實世界 3.5.1 從手工打造到官方支援 3.5.2 組織驗證 3.5.3 Web Search：讓 AI 不再活在過去 3.5.4 實作：為 Discord Bot 加入搜尋功能 3.5.5 測試網路搜尋功能 3.5.6 Web Search 的進階設定 3.5.7 處理搜尋結果的引用 3.5.8 Image Generation：讓 AI 畫圖 3.5.10 測試圖片生成 3.5.11 範例程式碼 3.5.12 圖片生成的進階技巧 3.5.13 結合多個工具：打造全能助手 3.5.14 使用官方工具的注意事項 3.5.15 小結 3.6 AI Agent：從工具使用者到自主助手 3.6.1 什麼是 AI Agent ？ 3.6.2 Agent 的四大核心能力 3.6.3 設計我們的第一個 Agent 3.6.4 實作記憶功能 3.6.5 將記憶主動送給 AI 3.6.6 整合 Agent 到 Discord Bot 3.6.7 範例程式碼 3.6.8 Agent 的自主行為示例 3.6.9 讓 Agent 具備反思能力 3.6.10 MCP：工具調用的標準化未來 3.7 章節重點觀念整理
第4 章 Workflow 與 Agent：從單打獨鬥到團隊協作 4.1 為什麼你需要 Workflow ？ 4.1.1 快速回顧：什麼是 Agent ？ 4.1.2 從 Agent 到 Workflow 4.1.3 Workflow 的核心價值 4.1.4 實際案例：從簡單查詢到深度研究 4.1.5 Workflow 與 Agent 的完美結合 4.1.6 設計原則：從簡單開始 4.1.7 本章預告 4.2 協調者- 工作者模式：打造 AI 研究團隊 4.2.1 從單兵作戰到團隊協作 4.2.2 協調者- 工作者模式介紹 4.2.3 實作協調者：任務分解專家 4.2.4 實作工作者：專業研究員 4.2.5 並行處理：讓團隊同時工作 4.2.6 實作統合者：品質把關 4.2.7 整合到 Discord Bot 4.2.8 範例程式碼 4.2.9 小結 4.3 評估者- 優化者模式：讓 AI 學會精益求精 4.3.1 從「完成」到「完美」 4.3.2 模式原理：持續改進循環 4.3.3 實作評估者：嚴格的品質把關 4.3.4 實作優化者：精準改進 4.3.5 實作迭代優化循環 4.3.6 整合品質控制到研究流程 4.3.7 更新 Discord Bot 工具 4.3.8 進階技巧：多維度評估 4.3.9 範例程式碼 4.3.10 小結 4.4 章節重點觀念整理 4.5 章節自我檢測
第5 章 RAG (Retrieval-Augmented Generation)：讓 AI 博覽群書 5.1 從 Token 限制到智慧搜尋 5.1.1 你獲得到一個新的任務！ 5.1.2 撞上天花板：Token 限制的殘酷現實 5.1.3 RAG 的誕生：聰明的解決方案 5.1.4 RAG 的工作流程 5.1.5 怎麼樣才能好的搜尋資料呢？ 5.1.6 RAG 如何利用向量找答案 5.1.7 實際運作的完整流程 5.1.8 為什麼 RAG 這麼聰明？ 5.1.9 RAG 的優勢總結 5.1.10 接下來... 5.2 使用 OpenAI 官方 RAG：最簡單的開始 5.2.1 從一本中二小說開始 5.2.2 OpenAI 的 RAG 功能：懶人救星 5.3 使用 OpenAI 官方 RAG：建立索引資料庫 5.3.1 第一步：上傳我們的中二小說 5.3.2 第二步：建立向量資料庫（Vector Store） 5.3.3 第三步：把檔案加入向量資料庫 5.3.4 範例程式碼 5.4 使用 OpenAI 官方 RAG：整合搜尋功能 5.4.1 範例程式碼 5.4.2 測試時間！讓我們問問諸神議會 5.5 深入 RAG：自訂搜尋與優化 5.5.1 控制搜尋結果數量 5.5.2 多檔案搜尋：建立完整知識庫 5.5.3 檔案屬性：讓搜尋更精準 5.5.4 屬性過濾：只搜尋特定檔案 5.5.5 複雜過濾：組合多個條件 5.6 RAG 最佳實踐與除錯技巧 5.6.1 常見問題與解決方案 5.6.2 向量資料庫的生命週期管理 5.7 進階 RAG 技術：當基礎搜尋不夠用時 5.7.1 你又獲得到一個新的任務！ 5.7.2 為什麼需要更進階的 RAG ？ 5.7.3 GraphRAG：讓 AI 理解關係網絡 5.7.5 如何選擇合適的 RAG 技術？ 5.7.6 其他有趣的 RAG 技術 5.8 章節重點觀念整理 5.9 章節自我檢測
第6 章 LLM 應用開發框架介紹 6.1 為什麼需要框架？ 6.1.1 永遠先用最簡單的方案！ 6.1.2 注意事項 6.2 AI SDK：統一的 LLM 介面 6.2.1 核心價值 6.2.2 基本使用 6.2.3 結構化輸出 6.2.4 適用場景 6.3 LlamaIndex：專業的 RAG 框架 6.3.1 核心價值 6.3.2 文檔處理與索引 6.3.3 多種檢索策略 6.3.4 適用場景 6.4 LangChain：靈活的工作流程框架 6.4.1 核心價值 6.4.2 基本鏈式調用 6.4.3 Agent：自主決策的 AI 6.4.4 適用場景 6.5 LangGraph：精確的狀態機控制 6.5.1 核心價值 6.5.2 定義狀態圖 6.5.3 適用場景 6.6 LangSmith：監控與除錯平台 6.6.1 核心價值 6.6.2 整合追蹤 6.6.3 主要功能 6.6.4 適用場景 6.7 框架選擇指南 快速決策樹組合使用 6.8 章節重點觀念整理
第7 章 Vibe Coding：用 AI 建構 AI 的全新開發範式 7.1 Vibe Coding 的基礎概念 7.2 什麼是 Vibe Coding ？ 7.2.1 從 Andrej Karpathy 的推文說起 7.2.2 Vibe Coding 的核心特徵 7.2.3 Vibe Coding 與本書的關係 7.3 設計有效的提示詞：與 AI 溝通的藝術 7.3.1 如何讓 Vibe Coding 更加高效？ 7.3.2 提示詞的基本結構 7.3.3 漸進式提示詞技巧 7.4 Claude Code：優秀的 Vibe Coding 工具 7.4.1 一個優秀的 Vibe Coding 工具 7.4.2 Claude Code 安裝與設定 7.5 掌握Claude Code：從基礎到進階的操作技巧 7.5.1 深入了解 Claude Code 的核心功能 7.5.2 建立 CLAUDE.md：讓 AI 更了解你的專案 7.5.3 與 IDE 無縫整合：提升開發效率 7.5.4 常見工作流程：從理論到實踐 7.5.5 進階技巧：讓 Claude Code 發揮最大效能 7.5.6 小結：Vibe Coding 的心法 7.6 Vibe Coding 的優勢與挑戰 7.6.1 顯著的開發優勢 7.6.2 需要注意的挑戰 7.7 章節重點觀念整理 7.8 結語：從 Vibe Coding 到未來 |
序
| 嗨，我是 Ray 貓，本名吳睿誠。是一個熱愛分享的軟體工程師，我幾乎所有的經驗都是依靠自學與反覆試錯而來，目前有經營個人社群大約有一萬位的追蹤者，也很常出沒在各種技術社群的小聚、大聚上擔任議程講者。
為什麼要寫這本書？ 當 ChatGPT 在 2022 年底橫空出世時，我和所有人一樣震撼於這個「彷彿有人類智慧般的 AI」。但作為一個每天爆肝的工程師，我更好奇的是：如何讓這個聰明的助手真正為我的系統工作，讓我每天少一點工作？ 距離 LLM 技術普及至今不過短短兩三年，整個產業還在快速演進中。我發現市面上雖然有不少 Python 相關的 AI 開發教學，但在 Node.js 領域卻相對稀少。身為一個 JavaScript 開發者，我知道有許多優秀的網頁工程師想要擁抱 AI 浪潮，卻找不到適合的學習資源。 於是我決定寫下這本書，希望用最熟悉的技術棧、最簡單的譬喻，帶領所有網頁工程師學會將 AI 融入自己的系統中。不論你是要開發企業級應用，還是想做個人的有趣專案，我都希望這本書能成為你的得力助手。 而且這本書的大部分概念並不會受到時間、空間影響，因為我希望能站在技術的基礎原理上去理解一個技術。
寫書路上的波折與收穫 說起這本書的誕生，真的可以說是一波三折。 故事要從 2024 年的 iThome 鐵人賽說起。當時我滿懷熱情地開始撰寫「從零開始開發 AI 應用」系列文章，每天花費很多時間寫程式碼、整理教學內容，眼看就要完成 30 天的挑戰⋯⋯結果某天因為忘記按下「發佈」按鈕，導致發文中斷，鐵人賽就這樣功虧一簣。 那時候真的很沮喪，覺得這麼多心血就這樣白費了。但現在回想起來，那次的「失敗」反而是個轉機。因為沒有了比賽的時間壓力，我有更多空間去思考、去實驗、去打磨內容。 這段期間我經歷了很多事情：開始了現在的創業項目 Redia，加入熊熊幹大事股份有限公司擔任設計工程師，參與了各種有趣的專案。每一段經歷都讓我對 AI 應用開發有了更深的理解，也讓這本書的內容變得更加豐富和實用。 這本書是我在能力所及內，盡我所可能所撰寫的一本書，這段時間同時要與專案的死線競速、創業、維持個人社群的活絡，另外還有與自己情緒的相處。
感謝的話 首先要感謝深智數位股份有限公司給了我這個珍貴的機會，讓我能夠將這些知識整理成書，分享給更多的開發者。 感謝我的爸爸，這段時間的支持與鼓勵。 感謝我的創業夥伴 Chris，在 Redia 的創業路上，我們一起探索 AI 在學習上的無限可能，這些經驗都成為了這本書珍貴的素材。 感謝所有在技術社群支持我的朋友們，你們的每一個按讚、每一次分享、每一個問題，都是我持續創作的動力。 最後，感謝正在閱讀這本書的你。希望這本書能幫助你在 AI 的世界裡找到屬於自己的道路，也希望你能和我一樣，享受用技術解決問題、創造價值的快樂。 讓我們一起踏上這場 AI 應用開發的精彩旅程吧！
Ray 2025 年於台北 |
