Q1：什麼是 AI Coding？

AI Coding 是使用大語言模型（LLM）協作開發的方法，包括 Vibe Coding、Spec Driven Development、ATPM 等實戰框架。透過 AI 輔助撰寫程式碼、測試、文檔，可顯著提升開發效率。

核心特點：

• 人類負責決策、審查、品質把關
• AI 負責生成程式碼草稿、重構、測試案例
• 需搭配完整的 PRD（產品需求文件）
• 實測可達 40% 開發時間加速

Q2：AI Coding 可以用在生產環境嗎？

可以。只要搭配完整的 PRD（產品需求文件）、測試流程與知識庫，AI Coding 已在多個生產專案中驗證，實測可達 40% 開發時間加速。

成功關鍵：

• 建立完整的 PRD 作為 Single Source of Truth
• 設計測試驗收機制（ATPM 框架的 Testing 階段）
• 人類審查所有 AI 生成的程式碼
• 建立專案知識庫供 AI 參考
• 明確的品質把關流程

Q3：如何開始學習 AI Coding？

建議從實際專案開始，使用 Cursor 或 Claude Code 等 AI IDE，搭配完整的 PRD 撰寫。先從小型功能開始練習，逐步建立 AI-人類協作的節奏感。

學習路徑：

1. 工具熟悉：安裝 Cursor 或 Claude Code，了解基本操作
2. PRD 撰寫：學習撰寫結構化的產品需求文件
3. 小專案實戰：從簡單功能開始（如 CRUD 操作）
4. 測試驗收：建立測試案例與驗收標準
5. 框架學習：深入 ATPM 框架的四個階段

Q4：AI Coding 會取代開發者嗎？

不會。AI Coding 是「輔助工具」而非「取代方案」。開發者的角色從「寫程式碼」轉變為「架構設計者、品質把關者、決策者」。

開發者的新角色：

• 系統架構設計與技術選型
• PRD 撰寫與需求分析
• 程式碼審查與品質把關
• 複雜邏輯的決策判斷
• 測試案例設計與驗收

Q5：什麼是 ATPM 框架？

ATPM（Assessment, Testing, Program, Management）是一套 AI Coding 生產流程，強調 PRD 為 Single Source of Truth、測試驗收機制、AI-人類協作模式，以及進度追蹤。已在實際專案中證明可加速 40% 開發時間。

四個階段：

• Assessment（評估）：PM 深入理解真實需求，撰寫詳細 PRD
• Testing（測試）：建立以 PRD 為依據的驗證機制
• Program（開發）：AI 生成草稿，人類審查決策
• Management（管理）：追蹤 PRD-程式碼-測試同步

Q6：PRD 為什麼這麼重要？

PRD（產品需求文件）是 ATPM 框架的核心，作為 Single Source of Truth。實際數據顯示，完整的 PRD 可讓 AI 程式碼生成準確度從 60% 提升到 85%。

PRD 的關鍵作用：

• 讓 AI 理解完整的業務邏輯與技術規格
• 作為測試案例設計的依據
• 團隊溝通的統一語言
• 減少需求變更與返工
• 實測：PRD:Code 比例約 1:1.4（9,211 行 PRD → 13,022 行程式碼）

Q7：ATPM 框架適合什麼樣的專案？

ATPM 框架特別適合「需求明確、流程清晰」的專案，不適合「快速試錯、需求模糊」的探索性專案。

適合的專案：

• 企業內部系統（ERP、CRM、後台管理）
• B2B SaaS 產品開發
• API 開發與整合
• 數據處理與自動化流程

不適合的專案：

• MVP 快速驗證（需求變動頻繁）
• 創新型產品（使用者需求未明）
• 高度創意性的前端設計

Q8：企業導入 AI Agent 常失敗的原因？

常見失敗原因包括：流程不清晰、資料混亂、落地場景選擇錯誤、缺乏 FDE（Forward Deployed Engineer）實作支援、過度期待自動化而忽略人的因素。

失敗原因分析：

• 流程不清晰：企業流程本身就混亂，AI 無法自動化
• 資料品質差：髒資料導致 AI 無法正確理解
• 場景選擇錯誤：選了過度複雜或不適合自動化的場景
• 缺乏 FDE 支援：沒有技術人員駐場協助落地
• 人的問題未解決：忽略組織變革與員工培訓

成功關鍵：「先把人的問題解決，再談技術落地」

Q9：什麼是 Multi-Agent 協作模式？

Multi-Agent 是指多個 AI Agent 分工合作完成複雜任務，每個 Agent 負責特定領域或功能，透過協作達成目標。

常見模式：

• Plan & Execute：規劃型 Agent + 執行型 Agent
• Interleaved Thinking：思考與執行交錯進行
• Supervisor Pattern：主管 Agent 協調多個工作 Agent
• Collaboration Pattern：平行協作，各司其職

Q10：如何選擇適合的 AI Agent 模式？

根據任務複雜度、確定性、資料可得性選擇：

• Workflow（工作流）：流程明確、步驟固定 → 適合標準作業流程
• ReAct（推理-行動）：需要動態判斷、多步推理 → 適合複雜問題解決
• Plan & Execute：大型任務需要事前規劃 → 適合專案管理
• Interleaved：需要靈活調整計畫 → 適合不確定性高的任務

Q10.5：為什麼 AI Agent 記不住上週的對話？

因為 LLM 的長期記憶永遠停在「出廠」那一刻。它跟你對話時用的是 context window（短期記憶），關掉視窗就沒了。這也是為什麼我們需要 RAG、CLAUDE.md 等 workaround。

LLM 記憶的本質：

• 長期記憶：訓練時學到的權重（出廠後不更新）
• 短期記憶：context window（關掉視窗就沒了）
• 擴大 context window：只是「用更大的短期記憶」解決問題

Google 的 Nested Learning 嘗試解決這個問題：讓模型像大腦一樣擁有多層記憶系統，自動判斷什麼值得寫入長期記憶。詳見 [Agent Part 8] Nested Learning 深度解析。

Q11：什麼是 FDE 模式？

FDE（Forward Deployed Engineer，駐場工程師）是一種「人肉深入客戶現場」的 AI 落地模式，強調透過人的理解與協作來建立 AI 系統，而非直接提供 SaaS 產品。

FDE 模式特點：

• 工程師駐點客戶現場，深入理解業務流程
• 客製化 AI 解決方案，而非標準化產品
• 持續優化與調整，建立長期合作關係
• 適合複雜、高價值的企業場景

適用場景：金融、醫療、製造業等高度客製化需求的產業

Q12：AI 如何幫助企業「把餅做大」而非只是降本？

AI 的價值不只是「降本增效」，更重要的是「Up-Sell 創收」。成功案例包括 AI 頭皮檢測系統、AI 推薦系統提升客單價等。

創收策略：

• Up-Sell：AI 分析提供升級建議（如美業 AI 頭皮檢測）
• 個人化推薦：提高轉換率與客單價
• 新服務開發：AI 驅動的新商業模式
• 效率提升：省下的時間用於更高價值的工作

Q13：企業 AI 轉型的第一步應該做什麼？

建議從「Quick Win」開始，選擇低風險、高可見度的場景快速驗證，累積信心與經驗。

Quick Win 場景範例：

• 會議記錄自動化：使用 Fireflies、Otter.ai
• 文件整理與知識庫：RAG 系統建立
• 客服 FAQ 自動回覆：簡單的 Chatbot
• 報表自動生成：數據分析自動化

避免：一開始就挑戰核心業務流程的全面改造

Q14：什麼是 Vibe Coding？

Vibe Coding 是一種「與 AI 協作的節奏感」開發方式，強調人類與 AI 之間的流暢互動，而非僵硬的指令式開發。

核心理念：

• 保持開發的「心流」狀態
• 快速迭代與即時回饋
• 人類專注於決策，AI 專注於執行
• 建立 AI-人類協作的默契

Q15：Cursor 和 Claude Code 有什麼差別？

兩者都是 AI IDE，但定位不同：

Cursor：

• 基於 VS Code，介面熟悉
• 強調程式碼生成與補全
• 適合日常開發工作
• 支援多種 LLM（GPT-4、Claude）

Claude Code：

• Claude 官方 CLI 工具
• 強調 Agent 模式的自主任務完成
• 適合複雜的多步驟任務
• 內建 TodoWrite、Task 等任務管理工具

Q16：AI Coding 在前端和後端有什麼差異？

AI Coding 在前端和後端的適用場景與挑戰不同：

前端：

• 適合：CRUD 操作、表單處理、API 串接
• 挑戰：UI/UX 創意設計、複雜動畫效果
• 建議：提供完整的設計稿與互動規格

後端：

• 適合：API 開發、資料庫操作、業務邏輯
• 挑戰：複雜的分散式系統、效能優化
• 建議：提供清晰的架構圖與資料流程

Q19：AI 做簡報跟人手刻有什麼差別？

用 AI 做簡報追求的不是「加速」，而是「千人千色」的客製化。透過 NotebookLM + Gemini，可以針對每個客戶的企業色調、用字遣詞做客製化簡報。

實際流程：

• Step 1：用 ChatGPT Atlas 抓取客戶官網主色調與企業價值
• Step 2：產出簡報用的風格與敘事提示詞
• Step 3：把大綱與提示詞丟進 NotebookLM 產生簡報
• Step 4：用 Canva 調整字體與細節

關鍵：當色調、用字遣詞都符合客戶的企業語言，這才是真正的 Customer First。

Q20：NotebookLM 跟一般 AI 工具有什麼不同？

NotebookLM 的核心價值是「知識保真度」(Knowledge Fidelity)。一個專案 = 一個 NotebookLM，所有需求、文件、會議紀錄都累積在同一處。

使用場景：

• 把所有專案知識（Google Docs、會議錄音）丟進同一個 NotebookLM
• 用「生成簡報」功能產出知識保真度極高的摘要
• 不是 Gamma.app 快速生簡報，而是「專業商業顧問」幫你提供 insight

作者觀點：這三年真正改變生活軌跡的 AI 工具：網頁 ChatGPT、語音模式、Claude Code，現在 NotebookLM 加入這個名單。

Q21：ChatGPT Atlas 可以用來做什麼？

Atlas 最強的功能是「直接操作瀏覽器介面」，特別適合「曾經會但現在生疏」的技能喚醒。

實戰案例：Grafana Debug

• 以前：翻文件、點介面、試錯 → 30 分鐘
• 用 Atlas：它直接操作 Grafana 介面找問題 → 1 分鐘
• 額外收穫：Atlas 主動發現 3 個潛在問題
• 加速倍數：30 倍

適用場景：曾經熟悉但久未接觸的工具操作、系統 Debug、設定檢查。

Q22：為什麼說學術界正被算力餓死？

美國頂尖名校 AI 學生的「人均 GPU」只有 0.1 張，而 OpenAI、Google 用十萬到百萬張訓練模型。

具體數據：

• 普林斯頓：0.8 張
• 史丹佛：0.14 張
• MIT / Berkeley：不到 0.1 張

結構性問題：學界從「創新引擎」變成「idea 供應商」——沒有算力驗證想法，idea 只能停留在論文裡，等業界有興趣才會被實現。這不是個別學校能改變的。

Q23：AI Agent 的四個必要條件是什麼？

科技業比較認同的定義，Agent 需要四個條件：

1. 智能
2. 記憶（context）
3. 調用工具的能力
4. 除錯的能力（關鍵！）

關鍵洞察：第四點是分水嶺。很多東西只是「工作流」——一條線下去，中間有錯無法糾錯。真正的 Agent 像 Claude Code，遇到問題會說「我發現有問題，我試著解決掉」，每次用不同方式解決。

務實觀點：「對我來說，能解決問題，老闆覺得這是 agent，那對老闆報告我就覺得這是 agent。」

Q24：為什麼全端能力是 AI 時代的基本要求？

AI 時代，勞資雙方都要專注在「全端能力」這件事情。這不是要成為樣樣精通的超人，而是具備串聯不同領域的視野與實作能力。

對技術人才：

• 從「單點工」變身「全能多棲」
• 目標是「獨立交付」一個 Feature 的全流程
• 不需要每個領域頂級，但要達到 60%~70% 水準並完成交付

對 PM/AM：

• 不能再當傳聲筒，要能看懂 API 文件、資料庫結構
• 用 AI 快速做 POC 驗證想法，不需等工程資源

對資方：全端團隊像特種部隊，業務重點改變時內部就能快速重新組隊。

Q25：Storm 是什麼？跟一般 AI 寫作有什麼不同？

Storm 是 Stanford 開發的 Agent 模型，核心概念是「把 AI 變成多人開會 + 人類當總編輯」。

與傳統 AI 寫作的差異：

• 傳統 ChatGPT：一條龍，講什麼就寫什麼 → 文章平淡無趣、各打 50 大板
• Storm：多位人格分工的 AI 一起研究，人類做最後裁決

秘密香料：AI 寫作缺乏個性，是因為沒有加入「你的偏見」。Storm 讓你站在總編輯的位置，AI 負責提供所有可能的觀點，你負責做最後的選擇與方向決定。

Q26：AI 可以在人狀況不好時幫忙嗎？

這不只是「增加生產力」的議題，而是 AI 可以輔佐人在狀況不佳時，還能產出一定程度的成品。

實戰案例：感冒沒睡好，早上 10:00 發現團隊問題需要教育訓練

• 11:30：用 ChatGPT 語音模式 5 分鐘對話，產出 A4 大綱
• 11:46：丟進 NotebookLM 按下簡報模式，去休息 10 分鐘
• 11:55：拿到有條有理的簡報（含圖表）
• 12:00：線上與 10 個不同地點的人進行交流

關鍵洞察：AI 永遠不會累，永遠 100% 全神貫注服務。一年前根據那天的精神狀況，根本不可能搞經驗分享。

Q27：AI Agent 時代有哪些資安盲點？

傳統 WAF/APM 完全看不到 AI Agent 的資安風險。94.4% 的 Agent 容易受攻擊。

兩個真實案例：

• Salesforce ForcedLeak：攻擊者在 Web 表單填入隱藏指令，Agent 自動將 CRM 客戶名單外傳給攻擊者。HTTP Status 200、無錯誤日誌。
• Microsoft 365 Copilot EchoLeak：郵件中的隱藏文字（白色字體）讓 Copilot 自動外洩機密資料。零點擊攻擊。

遊戲規則改變：攻擊者不需要駭進系統，只需要填一張表單或發一封郵件，然後等 AI 自己把資料送上門。

Q28：2025 年 AI 前沿模型格局有什麼變化？

OpenAI 自 2024 年 5 月的 GPT-4o 以來，似乎再也沒有成功完成一個 Full-scale Frontier Model 的訓練。

「大腦流失」時間線：

• Ilya Sutskever（共同創辦人）→ 自行創業
• Jan Leike（Superalignment 負責人）→ Anthropic
• John Schulman（共同創辦人）→ Anthropic
• Mira Murati（CTO）→ 離職
• 7 位核心人物，5 個月內離開

關鍵洞察：真正的護城河是「人」，不是算力。Jan Leike 離職時說：「安全文化讓位於華麗的產品」(Safety culture took a backseat to shiny products)。

Q31：AI 提升生產力最有效的方式是什麼？

填補短板，不是強化專長。讓 AI 做你不擅長的事（SEO、前端、寫作），你可以一瞬間在各方面都到 60 分。

專家在專業領域還是比 AI 強，但 AI 能把你的 20 分項目拉到 60 分。這是木桶效應的最佳應用。

來源：AI 生產力實戰：從填補短板到一邊超慢跑一邊寫 Code

Q32：一邊超慢跑一邊寫 Code 是怎麼做到的？

用 Claude Code 配聽寫輸入。在跑步機上看著它幫我寫 code，中間用語音給它指令。健康和生產力同時提升。

等 Claude iOS 版出來，連去健身房都能繼續。這是真正的「健康 × 生產力」雙贏。

來源：AI 生產力實戰

Q33：為什麼是「人 + Agent」而不是「一人配很多 Agent」？

因為 Agent 還是有除不了錯的時候。人的角色是導正和除錯。

一群年輕有衝勁的人，每人配 Agent，效率奇高——Agent 做 70-80%，人補 20%。這是目前最 practical 的配置。

來源：AI 生產力實戰

Q34：AI 工具怎麼選？

專注 1-2 個工具，不要追新。AI 能力差不多，但你對工具的熟悉度會讓效果差距很大。

• GPT：人性化最高，適合日常對話
• Claude Code：積極主動，適合寫程式
• Gemini：整合 Google 服務，便宜

來源：AI 生產力實戰

Q35：API 費用怎麼控制？

初學者：選儲值制或月費制（吃到飽），用完就停不會爆帳單。

進階使用：要串 API 時，先搞懂計費方式，上 production 前做好 alert 機制。GCP 那次爆單事件就是沒做好這一點。

來源：AI 生產力實戰

Q36：台灣軟體公司的機會在哪？

AI 時代，以前的劣勢（市場小、拼不過 996）都被打平了。

台灣優勢：經商環境偏美國但華語原生、理工人才多。做垂直領域 Agent 或軟硬整合，小團隊配 AI 有機會。

來源：AI 生產力實戰

Q37：GPT-5.2 的官方基準測試有什麼問題？

網友發現它用了 140,000 tokens 才刷出高分，而 Gemini 3 Pro 只用了 60,000 tokens 就達到差不多的分數。

在第三方評測（野榜）中，GPT-5.2 幾乎全面落敗：SimpleBench 排第 17、SWE-Bench 輸給 Claude Opus 4.5。

來源：GPT-5.2 基準測試爭議

Q38：為什麼說 GPT-5.2 的「無聊」可能是故意的？

OpenAI 可能正在從 toC 轉向 toB。5.2 優化了指令遵循、長對話穩定性、抗幻覺能力——這些對企業客戶很重要，但對日常聊天用戶來說就是「變無聊」。

Banana Test：GPT-5.1 在 47 分鐘後破功，GPT-5.2 撐了 62 分鐘還沒破。

來源：GPT-5.2 基準測試爭議

Q39：OpenAI 為什麼要做這樣的戰略轉向？

三個原因：

1. Gemini 3 太強，Google 的 toC 渠道優勢明顯
2. 核心人才大量流失（Ilya、Jan Leike、Mira Murati 等）
3. 與 Microsoft 重新聚焦企業辦公賽道

走向 Anthropic 一直走的 toB 路線：安全、可靠、可預測。

來源：GPT-5.2 基準測試爭議

Q40：n8n 不就是 low-code 自動化工具嗎？

表面上看是，但底層是 DAG + 狀態機架構。這讓它原生支援 Retry、Error handling、長時間非同步任務。

當你要做企業級部署時，這些特性比 UI 更重要。

來源：n8n 雲地混合架構

Q41：為什麼 scale n8n 只需要 scale Worker？

因為 Core 只負責調度（決定誰可以跑、維護 DAG 狀態），工作量很小。真正吃資源的是 Worker（跑 API、LLM、資料處理）。

結果：Core 一台就夠，Worker 可以根據負載動態擴展到 10 台、20 台。

來源：n8n 雲地混合架構

Q42：什麼是雲地混合架構？為什麼 n8n 適合？

雲地混合是讓彈性服務放雲端、敏感資料留地端。n8n 因為 Core/Worker 分離，天生適合：

• 雲端：Core 負責彈性擴充、PostgreSQL、Redis
• 地端：Worker 處理敏感任務、ERP、Local LLM
• 中間層：VPN / Private Link 連接

來源：n8n 雲地混合架構

Q43：n8n 跟 Zapier、Make 比，優勢在哪？

Zapier、Make 的 UI 更友善，但 n8n 可以：

• ✅ 完全 self-host
• ✅ Core/Worker 分離部署
• ✅ 原生支援 Hybrid 架構
• ✅ 開源可審計

對有資安合規需求的企業，這些比節點數量重要。

來源：n8n 雲地混合架構

Q44：為什麼說「年輕人不是被取代，是還沒被給機會」？

很多公司看到 AI 能做基礎工作，就減少招聘 junior。但實際上年輕人對 AI 工具的熟悉度最高，給他們機會配合 AI 工具，往往能超出預期。

SignalFire 數據：2024 年大型科技公司新鮮人招聘比例從 25% 驟降到 7%。

來源：AI 不會取代年輕人

Q45：AWS 執行長為什麼說取代初階員工是「最愚蠢的想法」？

Matt Garman 的三個理由：

1. 初階員工對 AI 工具最熟悉：他們最能發揮這些工具的價值
2. 財務邏輯不通：砍低薪員工留高薪資深員工
3. 企業需要人才梯隊：最好的想法往往來自這些人

來源：AI 不會取代年輕人

Q46：FDE 團隊的成員背景是什麼？

幾乎沒有資訊工程出身。來自不同學校、不同科系（從台大到南台），但都很自然地用 AI 來學習和解決問題。

結果：累積的能力往往比傳統教育體系給得更多。一位上了護國神山，一位上了蝦皮。

來源：AI 不會取代年輕人

Q47：未來開發者的工作會變成什麼？

Garman 預測：不是寫 Java code，而是：

• 拆解問題
• 決定要做什麼
• 協調 AI Agent
• 審查產出的 code 並給回饋

來源：AI 不會取代年輕人

Q48：NotebookLM 最適合用在什麼場景？

複雜專案的知識庫管理。把會議紀錄、錄影檔全部丟進去，它能做出高保真度的摘要。

用法：一個專案 = 一個 NotebookLM，用簡報功能產出專案簡介，新人 onboarding 或專案交接特別有用。

來源：週報 Vlog 總結（12/12 - 12/21）

Q49：GPT-5.2 跟之前版本差在哪？

變得更省話、更精簡，像是往 toB 方向調整。創意發想和對話靈動感明顯下降，但工程化和抗幻覺能力提升。

如果你是日常聊天用途，可能會不習慣。作者已經切回 5.1。

來源：週報 Vlog 總結

Q50：LATS 和 Storm 這兩個 Agent 架構有什麼不同？

• LATS：用蒙地卡羅樹搜尋，適合需要深度推演的場景，像下圍棋一樣思考
• Storm：像編輯室模式，多個 Agent 收集觀點後收斂，適合內容創作，方便人類在各節點介入決策

來源：週報 Vlog 總結

Q51：AI 真的不會取代年輕人嗎？

我的實際觀察是：年輕人對 AI 工具的熟悉度和使用意願遠超資深員工。AWS 執行長也說過，用 AI 取代初階員工是最愚蠢的想法。

關鍵：給他們機會。AI 含量的差距會拉開公司與公司之間的巨大差距。

來源：週報 Vlog 總結

Q52：如何聯絡作者或提問？

歡迎透過以下方式聯絡：

• LinkedIn：https://www.linkedin.com/in/wisely-chen-38033a5b/
• 個人網站：https://www.wiselychen.com/#contact
• GitHub：https://github.com/thegiive

Q53：網站內容可以轉載或引用嗎？

可以，但請：

• 註明出處與作者（Wisely Chen）
• 提供原文連結
• 不做商業用途（如需商業授權請聯絡）
• 保持內容完整性，不斷章取義