https://yennj12.js.org/yennj12_blog_V4/tags/poc/Recent content in POC on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-24-poc-scoring-roi-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-24-poc-scoring-roi-zh/POC 的真正目的不是展示技術可行性——而是用三週時間產出一個可供商業決策的數字，讓「繼續投入」或「止損離場」都能有據可查，而不是靠政治談判決定。 一、為什麼面試官問這個 面試官問 POC Scoring 與 ROI 框架，真正在測試的是以下三件事： 你能否在客戶端建立客觀的決策流程。 弱答案：「我們做完 POC 再看結果好不好。」——這暴露了沒有預先定義成功標準，最終結果是技術人員和業務主管各說各話，POC 無法收斂。強答案：「POC 開始前，我們與客戶簽核一張成功指標矩陣，列出每個指標的基準值、目標值、量測方法，以及 Go/No-Go 門檻。」 你能否把技術產出轉換成財務語言。 弱答案只說「系統會變快」；強答案給出具體的 ROI 公式：節省的 FTE 時數 × 時薪 × 工作天數，加上 CSAT 提升帶來的 ARR 留存效益，並說出回收期是多少個月。 你是否理解 POC 的時間盒邊界與組織動力學。 弱答案讓 POC 無限期延伸；強答案說明為什麼超過三週邊際效益遞減，沉沒成本如何使 No-Go 決策在政治上變得幾乎不可能執行，以及如何用加權閘設計移除主觀因素。 二、核心原理與技術深度 POC 的根本問題：未定義出口條件 企業 AI 專案中最常見的失敗模式不是技術失敗，而是「評估困境」（Evaluation Deadlock）：雙方都認為自己是對的，但沒有共同接受的量測標準作為仲裁者。 開放式 POC 生命週期（典型失敗路徑） 第 0 週 第 3 週 第 6 週 第 10 週 第 14 週 │ │ │ │ │ 啟動 Demo 追加 「還需 預算凍結 POC 展示 需求 要更多 專案中止 ──▶ 擴大 工作」 ◀──────── 印象 範圍 ←政治 虛耗 14 週 良好 ──▶ 辯論 工程資源 根本原因：出口條件（Exit Criteria）未在開始前定義。當沒有客觀標準時，決策就退化為主觀印象與組織政治。技術團隊說「功能已完成」，業務方說「感覺還不夠」，雙方都無法用數字說服對方。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-part38-prototype-to-production-zh/Fri, 05 Jun 2026 16:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part38-prototype-to-production-zh/同一個 Agent，Demo 時跑得很好。 上了生產後成本是預估的 8 倍、偶爾 15 秒、有時候對話記憶消失。 「能 Demo」和「可以讓 1,000 個用戶每天用」之間的距離， 就是生產化工程的價值。 面試情境 面試官：「你幫客戶做了一個 3 週的 RAG + Agent POC，Demo 很成功。客戶的 CTO 說：太好了，下個月上線。你說：先等一下，我們需要做幾件事。你會說什麼？」 一、POC 和 Production 的假設差距 POC 的隱性假設： 假設 1：只有你在用（實際：100 個並發） 假設 2：測試資料乾淨（實際：用戶會貼整份合約進來） 假設 3：成本不計較（實際：月底看帳單） 假設 4：出錯了就 debug（實際：1 小時內要給客戶答覆） 假設 5：你挑了最好的 Demo 例子（實際：Murphy's Law） 五個 POC 到 Production 的差距： 差距 1：Token Budget → 成本是預估的 8 倍 差距 2：延遲 SLA → Cold Start 讓 P95 超過 SLA 差距 3：Session State → 重啟後對話記憶消失 差距 4：錯誤處理 → 外部 API Timeout 讓 Agent crash 差距 5：Rollback → Prompt 改錯了沒辦法快速回頭 以下逐一拆解每個差距的成因和設計。 二、差距 1：Token Budget 失控 失控路徑： POC 測試：平均 2,000 input tokens，成本可接受。 ↓ Production 現實： 情況 A：用戶貼了整份合約 input_tokens = 20,000（是預估的 10 倍） 情況 B：Multi-turn 對話 history 累積 第 1 輪：2,000 tokens 第 5 輪：2,000 + (4輪 × 800) = 5,200 tokens 第 15 輪：2,000 + (14輪 × 800) = 13,200 tokens 情況 C：ReAct loop 多跑幾輪 正常：2 輪 Tool Call = 2,000 × 2 = 4,000 tokens 異常：6 輪 Tool Call（遇到困難問題）= 2,000 × 6 = 12,000 tokens Token Budget 設計： ┌─────────────────────────────────────────────────────────────┐ │ 總 Budget：8,000 tokens（可配置） │ │ │ │ ├── System Prompt（固定）：-1,200 tokens │ │ │ （如果 > 1,000 tokens，考慮 Context Caching） │ │ │ │ │ ├── User Query：-actual tokens（優先保留） │ │ │ │ │ ├── Conversation History（最多 30% 剩餘 budget） │ │ │ 超過部分：從最舊的輪次開始截斷 │ │ │ 如果整體 > 10 輪：先壓縮成 Summary │ │ │ │ │ └── Retrieved Context（剩餘 budget） │ │ 按相關性排序，直到 budget 用完 │ └─────────────────────────────────────────────────────────────┘ 成本效益： 無 Budget 管理：預估 $0.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.