https://yennj12.js.org/yennj12_blog_V4/tags/discovery/Recent content in Discovery on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-21-discovery-to-constraints-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-21-discovery-to-constraints-zh/核心定義：Discovery to Constraints 是將「我們想要 AI」這類模糊客戶陳述，透過結構化探索問法，轉化為可驅動架構決策的精確技術約束清單的顧問工程能力。 大多數工程師聽到客戶說「我們需要 AI」就開始畫系統架構圖。成熟的 FDE 聽到同樣的話，先問五個問題——這五個問題決定了接下來五週的工作方向是否正確。 一、為什麼面試官問這個 面試官真正在評估的，不是候選人對技術的熟悉程度，而是候選人在資訊不完整的情況下是否能有效降低架構風險。建立在錯誤假設上的系統設計，輕則白板畫了兩小時、重則客戶 PoC 做到一半才發現方向錯了，損失 5–10 週工程時間。 測試顧問判斷力：FDE 的核心價值在於「問對問題」而非「給快答案」。面試官想看你是否知道在動手設計之前必須先挖掘約束。一個資深 FDE 能在 30 分鐘的 Discovery 會議中確認 10 個關鍵問題，節省客戶 4–6 週的返工成本。 區分資淺與資深候選人：弱答案是立刻開始畫系統架構圖，預設客戶規模、合規要求、延遲需求都是「一般水準」。強答案是先提出 SCALE 框架，依序詢問規模、合規、現有架構、延遲、經濟性，再用約束矩陣對比方案，最後才推薦架構。 測試風險意識：面試官會觀察候選人是否知道「推薦多區域主動-主動架構給每天只有 1,000 用戶的客戶」是一種顧問失誤，不是技術成就。過度設計浪費客戶預算；設計不足導致上線後系統崩潰。兩者都是 FDE 失職。 弱答案長什麼樣：「我會幫您建一個 RAG pipeline，用 Vertex AI Search 加上 Gemini，支援 HTTPS 加密，部署在 Kubernetes 上，具備自動擴展能力。」（沒問任何約束就給方案，而且可能嚴重過度設計） 強答案長什麼樣：「在我提出架構之前，我需要了解五個維度：規模、合規、現有系統、延遲 SLA、預算。讓我從最高風險的開始問——您的資料有跨境限制嗎？法務是否要求資料必須留在特定區域？這個答案會直接排除幾種架構選項。」 二、核心原理與技術深度 Discovery 問法的本質是約束空間收斂。客戶的初始陳述定義了一個龐大的可能解空間，每一個精準問題都在削減這個空間，直到剩下 1–3 個可行架構選項。 客戶陳述的模糊解空間 ┌──────────────────────────────────────────────────────────────┐ │ "我們想要 AI 來處理客戶查詢" │ │ │ │ 規模維度：10 用戶 ───────────────────────────── 10M 用戶 │ │ 合規維度：無限制 ─────────────── HIPAA + PDPA + FSC │ │ 部署維度：公有雲 ──────── 混合雲 ──────── On-premise only │ │ 延遲維度：批次（分鐘）──────────────────── 即時（< 500ms） │ │ 預算維度：$1,000/月 ─────────────────── $100,000/月 │ │ │ │ 可能架構數量：> 200 種組合 │ └──────────────────────────────────────────────────────────────┘ │ 每個 SCALE 問題削減 60–80% 的解空間 │ ▼ SCALE 探索後的精確解空間 ┌──────────────────────────────────────────────────────────────┐ │ 已確認約束： │ │ S: 5K DAU，峰值 50 QPS，12 個月成長 3x │ │ C: 需要 PDPA，資料不出 asia-east1，不需要 CMEK │ │ A: 現有 SAP ERP，REST API，無 On-premise GPU │ │ L: TTFT < 2 秒，可接受串流，批次報表可接受 30 秒 │ │ E: 月預算 $8,000，目標每查詢 < $0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part27-poc-scoping-zh/Thu, 04 Jun 2026 19:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part27-poc-scoping-zh/客戶說：「我想用 AI 讓客服更好。」 工程師說：「好的，你們的資料在哪裡？」 FDE 說：「我想先了解，你說的『更好』，是指回答速度、準確率，還是人工成本降低？然後我們來看三週能做到什麼。」 這個差距，就是 FDE 面試在測的東西。 面試情境 面試官：「你剛到客戶現場，客戶的 VP of Engineering 說：『我們想用 AI Agent 改造我們的客服流程，你能幫我們做嗎？』你有 45 分鐘的會議時間。你怎麼引導這個對話，讓它結束時有一個可執行的 POC 計畫？」 一、為什麼 Scoping 是 FDE 最核心的顧問技能 沒有 Scoping 的後果： 客戶說「改造客服」 ↓ 你直接開始設計 架構圖越來越大 ↓ 工程師開始做 ↓ 三週後客戶說「這不是我要的」 ↓ FDE 被認為不理解業務需求 → 影響客戶關係 有 Scoping 的流程： 45 分鐘 Discovery → 明確的 POC Scope → 雙方簽字確認 ↓ 工程師做對的事 ↓ 三週後 Demo 符合預期 ↓ FDE 建立信任 → 後續擴大合作 二、45 分鐘 Discovery 會議的完整流程 時間分配： 0:00 - 0:05 開場 + 議程設定（5 分鐘） 0:05 - 0:20 業務現狀 Discovery（15 分鐘） 0:20 - 0:35 技術現狀 Discovery（15 分鐘） 0:35 - 0:42 POC Scope 提案（7 分鐘） 0:42 - 0:45 確認 Next Step（3 分鐘） 三、業務現狀 Discovery：你要問的 5 個問題 這 5 個問題的目的，是找出一個最小的、有明確價值的切入點。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part42-consulting-discovery-zh/Mon, 08 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part42-consulting-discovery-zh/客戶說：「我們想要 AI。」 這不是需求，這是一個方向。 優秀的 FDE 不直接問「你要什麼功能」， 而是問：「你現在的哪個問題，讓你睡不著覺？」 面試情境 面試官：「一家製造業客戶的 CTO 打電話說：『我們想用 AI 改善營運效率。我看到競爭對手都在做 AI，我們不能落後。』你和他約了第一次 30 分鐘電話。你會怎麼進行？你想挖掘什麼資訊？電話結束時你的目標是什麼？後續步驟是什麼？」 一、為什麼「要 AI」不是需求 「要 AI」的三種真正動機（不同動機 → 完全不同的 POC 策略）： 動機 A：競爭壓力（Follow the Market） 信號：「競爭對手都在做，我們不能落後」「我在新聞上看到 AI 可以做到 X」 真實需求：快速可見的成果，能對外展示 → POC 策略：優先「Demo 效果最好」的場景，速度第一，3 週出 Demo → 陷阱：如果做了一個「很強大但看不見」的 AI，客戶會說失敗 動機 B：內部痛點（Pain-Driven） 信號：「我們的人都在做重複的事」「某個流程效率很低，浪費很多時間」 真實需求：降低運營成本，解放員工時間 → POC 策略：先量化痛點（N 個人 × M 小時），POC 做完計算節省比例 → 重點：ROI 對話，不是功能展示 動機 C：技術探索（Innovation-Driven） 信號：「我想了解 AI 能幫我們做什麼」「我們有個想法想驗證」 真實需求：教育和探索，不是立刻部署 → POC 策略：選一個工程師能理解和參與的場景，目標是建立 AI 直接體感 → 重點：過程比結果更重要（讓客戶團隊學到東西） FDE 的工作： 第 1 步：判斷客戶是哪種動機 第 2 步：用對應的語言和框架和客戶對話 第 3 步：設計對應類型的 POC 錯誤做法： 無論客戶是哪種動機，都給同一個 POC 方案 → 動機 A 的客戶看到「技術很強但 Demo 要等 3 個月」→ 失望 → 動機 B 的客戶看到「Demo 很漂亮但沒有 ROI 數字」→ 無法簽約 二、三個顧問參與階段 ╔══════════════════════════════════════════════════════════════╗ ║ Phase 1：Discovery（第一次接觸 → 初步提議） ║ ║ 目標：了解真實需求和限制條件，提議一個合理的 POC 起點 ║ ╚══════════════════════════════════════════════════════════════╝ 時間：1-2 次電話，共 60-90 分鐘 主要活動： ├── 30 分鐘 Discovery 電話（五個核心問題） ├── Stakeholder Mapping（找出誰是誰） └── 初步 POC 範圍提議（電話結束前） 輸出文件： └── 1 頁 Discovery 摘要（痛點、量化數字、限制條件、初步建議場景） 成功標準： ├── 客戶確認一個具體的業務場景 ├── 了解資料可用性（能快速評估可行性） └── 客戶願意安排下一步（Technical Assessment） ╔══════════════════════════════════════════════════════════════╗ ║ Phase 2：Technical Assessment（技術可行性評估） ║ ║ 目標：確認架構可行、資料可用、整合複雜度，精確化 POC 範圍 ║ ╚══════════════════════════════════════════════════════════════╝ 時間：1-2 週 主要活動： ├── 資料評估（看資料品質、量、格式、存取方式） ├── 技術架構評估（整合現有系統的複雜度） ├── 與 Technical Gatekeeper 對話（確認 IT 政策、安全要求） └── POC 範圍精確化（從「維修手冊 AI 助手」到「針對 3 台機器，3 週，2 位工程師驗收」） 輸出文件： └── Technical Assessment Report（資料可行性、架構方案、POC 詳細範圍、風險清單） 成功標準： ├── 確認資料可以在 POC 期間取用 ├── IT Gatekeeper 在技術方案上達成共識 └── POC 範圍精確到「誰做什麼、什麼時候完成、怎麼驗收」 ╔══════════════════════════════════════════════════════════════╗ ║ Phase 3：POC Proposal（POC 提案） ║ ║ 目標：獲得 Economic Buyer 的預算批准和資源承諾 ║ ╚══════════════════════════════════════════════════════════════╝ 時間：1-2 次會議 主要活動： ├── Value Story 呈現（ROI 估算，見第七節） ├── POC 成功標準定義（量化驗收標準） ├── 資源和時間承諾確認（客戶提供什麼、你提供什麼） └── 風險和緩解策略說明 輸出文件： └── POC Proposal（目標、範圍、驗收標準、時間線、雙方承諾、費用） 成功標準： └── Economic Buyer 批准預算，雙方簽署 POC Agreement 三、Discovery 對話的三個層次 三個層次的深度和目的： ┌──────────────────────────────────────────────────────────────┐ │ 層次 1：業務目標（Business Goal） │ │ │ │ 問：「6 個月後，什麼指標改善了，你會說這個 AI 專案成功了？」 │ │ │ │ 目的：讓客戶定義「成功」，把模糊的「AI 改善效率」 │ │ 轉化為可量化的指標 │ │ │ │ 不好的答案（模糊）： │ │ 「提升效率」「改善品質」「讓員工更開心」 │ │ │ │ 好的答案（可量化）： │ │ 「品管員的人工複查時間，從每件 4 小時降到 1 小時」 │ │ 「供應商異常的平均反應時間，從 48 小時縮到 8 小時」 │ │ │ │ 引導技巧： │ │ 「如果你要向你的 CEO 展示這個 AI 專案成功了， │ │ 你會說哪一個數字改善了多少？」 │ └──────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ 層次 2：現在的痛點（Current Pain） │ │ │ │ 問：「能否描述一個具體的場景，讓我了解今天的問題 │ │ 是怎麼發生的？一週大概發生幾次？需要幾個人？」 │ │ │ │ 目的：讓客戶說出一個真實的工作流程故事（有具體的人、動作、頻率）│ │ 同時把痛點量化（為後續 ROI 計算準備數字） │ │ │ │ 追問量化數字： │ │ 「這個問題大概影響多少人？」→「20 個品管員」 │ │ 「每人每天花多少時間？」→「4 小時」 │ │ 計算：20 × 4h × 250 天 = 20,000 人時/年 │ │ 這個數字後來出現在 Value Story 的 ROI 計算裡。 │ └──────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ 層次 3：限制條件（Constraints）— 找隱藏地雷 │ │ │ │ 問：「資料在哪裡？IT 對雲端有什麼限制？ │ │ 最終用戶是誰？他們的技術能力如何？」 │ │ │ │ 常見隱藏地雷和對應問題： │ │ │ │ 地雷 問題 高風險信號 │ │ ────────────────────────────────────────────────────────── │ │ 資料不可用 「資料在哪裡存？格式？」 「紙本」「各地 Excel」│ │ IT 封鎖雲端 「IT 對雲端有限制嗎？」 「我們很保守」 │ │ 最終用戶抵制 「用戶知道這個專案嗎？」 「我還沒跟他們說」 │ │ 預算不在 Champion 「誰批准這個預算？」 「我來想辦法」 │ │ Legal/合規障礙 「有資料使用的法規限制？」「有個資保護法」 │ └──────────────────────────────────────────────────────────────┘ 四、利害關係人影響力地圖 四個關鍵角色及其影響力： ┌─────────────────────────────────────────────────────────────┐ │ 影響力地圖 │ │ │ │ 高決策影響力 │ │ ↑ │ │ │ Economic Buyer │ │ │ （有預算，決定投資） Champion │ │ │ → 需要看 ROI 數字 （推動者，有熱情） │ │ │ → 不一定有 AI 背景 → 我們的主要聯絡人 │ │ │ → 不一定有預算 │ │ │ │ │ │ │ │ │ Technical Gatekeeper End User │ │ │ （IT/架構師，評估技術） （實際使用者） │ │ │ → 可能是阻力也可能是盟友 → 決定採用率 │ │ │ → 必須早期納入 → 最常被遺漏 │ │ │ │ │ ↓ │ │ 低決策影響力 │ │ ←────────────────────────────────────────────────────→│ │ 反對 AI 支持 AI │ └─────────────────────────────────────────────────────────────┘ 每個角色的核心關注和你需要做的事： 角色 核心關注 你需要做的 ────────────────────────────────────────────────────────────── Champion 希望 AI 在組織內成功 讓他成為你的盟友； 自己的 KPI 提供他「向上推銷」的彈藥（ROI、案例） ────────────────────────────────────────────────────────────── Economic Buyer ROI、風險管控 先讓 Champion 安排見面機會； 投資回報 用業務語言（不是技術語言）說話 ────────────────────────────────────────────────────────────── Technical 安全、整合可行性 早期納入，讓他成為方案的「共同設計者」； Gatekeeper 現有架構不被打亂 不要最後才讓他評估（他會找一堆問題否決） ────────────────────────────────────────────────────────────── End User 工作有沒有變輕鬆 Demo 必須讓他們試用； 不想被 AI 取代 強調「AI 幫你做你不喜歡的部分」 ────────────────────────────────────────────────────────────── 常見的 Stakeholder 失敗模式： 失敗模式 1：Champion 有熱情，但 Economic Buyer 不知道這個專案 → POC 完成，預算沒批，專案在等待中死亡 → 預防：第一次電話後就問「誰批准預算？我需要和他談嗎？」 失敗模式 2：Technical Gatekeeper 最後才被納入 → 技術方案設計完成後，IT 說「這不符合我們的安全政策」 → 預防：Phase 2 Technical Assessment 時必須和他深談 失敗模式 3：End User 從未被問過需求 → Demo 很成功，但真正的用戶說「這個流程我們用不了」 → 預防：POC 期間讓 End User 試用，收集真實反饋 五、需求挖掘的五個核心問題 30 分鐘電話的五個問題框架： 問題 1（業務痛點，5 分鐘）： 「能否描述一個具體的場景，讓我了解今天的問題是怎麼發生的？」 追問： └── 「這個問題多久發生一次？」 └── 「每次大概影響多少人，需要多少時間處理？」 成功標準：客戶說出一個有具體細節的故事 不成功：客戶只說「流程很低效」（抽象，無法推進） ───────────────────────────────────────────────────────────── 問題 2（量化影響，3 分鐘）： 「這個問題影響多少人？每週或每年大概花多少時間或多少成本？」 引導技巧（客戶沒有數字時）： └── 「你估計大概是這個量級嗎？每人每天超過 1 小時？超過 3 小時？」 → 讓客戶確認範圍，比讓他從零想更容易 成功標準：有一個可以用於 ROI 計算的數字 示例：「20 個品管員，每人每天 4 小時」 → 後來成為：「如果 AI 減少 75%，每年節省 15,000 人時， 折算人力成本約 $450,000」 ───────────────────────────────────────────────────────────── 問題 3（資料可行性，3 分鐘）： 「這個問題涉及的資料，現在存在哪裡？是什麼格式？大概有多少量？」 高風險信號（需要更多評估時間）： ├── 「資料在各地工廠的 Excel，每個廠格式不一樣」 ├── 「大部分是紙本，需要掃描」 └── 「在老舊的 ERP 系統裡，沒有 API，需要 DBA 配合」 低風險信號（POC 可能 3 週完成）： └── 「維修手冊是 PDF，都在 SharePoint 上，大概 500 份」 ───────────────────────────────────────────────────────────── 問題 4（成功定義，3 分鐘）： 「3 個月後，你怎麼判斷這個 AI 系統是成功的？」 目的：逼客戶把成功定義量化，不能只說「感覺更好」 不好的答案：「用戶說這個系統很好用」 好的答案：「品管員的複查時間從 4 小時降到 1 小時，且準確率不低於現在」 這個答案後來成為 POC 的驗收標準，避免 POC 結束後的爭議。 ───────────────────────────────────────────────────────────── 問題 5（資源承諾，3 分鐘）： 「你希望什麼時候看到第一個可以展示的成果？ 你們這邊能投入哪些資源配合（領域專家、IT、測試用戶）？」 最低資源要求（必須確認）： └── 2 位領域專家，配合 3 週（提供資料、驗收答案品質） 高風險信號： └── 「你們主導，我們配合」（沒有具體承諾） → 後果：POC 期間找不到人驗收答案品質，無法推進 → 預防：明確說「領域專家每週需要投入約 4 小時配合我們， 這是 POC 成功的必要條件，不只是 nice to have」 六、POC 場景評分矩陣 五個維度的評分（1-5 分），選總分最高的場景： 維度 說明 ────────────────────────────────────────────────────────────── 業務影響力 客戶有多在乎這個問題？解決後對業務有多重要？ 資料可用性 資料是否數位化、可取用、格式可解析、量足夠？ 技術可行性 用現有 AI 技術在 3-4 週內能做出有說服力的 Demo？ Demo 效果 5 分鐘內，非技術 Stakeholder 能看到價值嗎？ 擴展路徑 POC 成功後，能以合理代價擴展到全公司嗎？ ────────────────────────────────────────────────────────────── 製造業客戶評分示例： 場景 業務影響 資料可用 技術可行 Demo效果 擴展路徑 總分 ────────────────────────────────────────────────────────────────────── 維修手冊 AI 助手 4 5 5 5 4 23 ✅ 視覺品質檢測自動化 5 3 4 4 5 21 供應鏈異常預警 5 3 3 3 5 19 生產排程優化 4 3 2 2 4 15 ❌ 選擇維修手冊 AI 助手（23 分）的具體理由： 為什麼技術可行性 5 分： └── 文字 PDF + RAG 是最成熟的 AI 技術，不需要自訓練，3 週可完成 為什麼資料可用性 5 分： └── 維修手冊是 PDF，已數位化，在 SharePoint，取用簡單，500 份夠用 為什麼 Demo 效果 5 分： └── 維修工程師在手機上問問題，AI 立刻找到相關手冊段落並解釋 非技術的 CTO 一眼看到「這和我現在用 PDF 的差距」 為什麼不選生產排程優化（15 分）： └── 排程優化是複雜的組合優化問題，需要收集生產線實時數據 3-4 週根本做不出有說服力的 Demo POC 範圍縮小的原則（越窄越好）： ❌ 過寬（失敗風險高）： 「所有工廠所有機型的維修手冊，支援中英文，整合 SAP 工單系統」 ✅ 正確（聚焦、可完成）： 「A 工廠最常出問題的 3 台機器的中文維修手冊， 能回答工程師的故障排查問題， 3 週完成 Demo， 由 2 位資深維修工程師驗收答案品質（準確率 > 80%）」 縮小範圍的對話技巧： └── 「我知道理想狀態是涵蓋所有機型， 但為了在 3 週內給你一個可以信任的 Demo， 我建議先從你們最頭痛的 3 台機器開始—— 成功之後，擴展到其他機型只是重複相同的工作，不是重新設計。」 七、Value Story 框架（如何呈現 ROI） Value Story 的結構（呈現給 Economic Buyer）： ┌──────────────────────────────────────────────────────────────┐ │ 1.