<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ROI on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/roi/</link><description>Recent content in ROI on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 08 Jun 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/roi/feed.xml" rel="self" type="application/rss+xml"/><item><title>FDE core topic - POC Scoring &amp; ROI：概念驗證評分矩陣與投資回報框架設計</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-24-poc-scoring-roi-zh/</link><pubDate>Mon, 08 Jun 2026 10:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-24-poc-scoring-roi-zh/</guid><description>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）未在開始前定義。當沒有客觀標準時，決策就退化為主觀印象與組織政治。技術團隊說「功能已完成」，業務方說「感覺還不夠」，雙方都無法用數字說服對方。</description></item><item><title>FDE 面試準備指南（二十九）：顧問實戰——AI 系統 TCO 估算與 ROI 說服框架</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part29-tco-roi-zh/</link><pubDate>Thu, 04 Jun 2026 20:30:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part29-tco-roi-zh/</guid><description>工程師說：「這個架構非常優雅。」
財務長說：「一個月要多少錢？」
FDE 說：「我來幫你們算。如果這個系統每個月省下 X 小時的人力，
以你們現在的薪資結構，大概幾個月可以回收建置成本。」
這個對話，決定了 POC 之後有沒有預算繼續做。
面試情境 面試官：「客戶問你：我們要在 Vertex AI 上部署一個 RAG-based 客服 Agent，每天大概 10,000 個 query，一個 query 平均 2,000 input token 和 500 output token。一個月的 API 成本是多少？如果我們加了一個 Embedding 服務和向量資料庫，總體的 TCO 是什麼？我要拿這個數字去說服 CFO。」
一、為什麼 FDE 必須會算成本 技術架構決定成本結構： 你選 Gemini 1.5 Pro vs Gemini 1.5 Flash → 成本差 5 倍 你選 Vertex AI Vector Search vs pgvector → 成本和維護方式不同 你選 Cloud Run vs GKE → Infra 成本和工程複雜度不同 如果 FDE 說不出成本，客戶只能靠自己估算。 自己估出來的數字通常是錯的（太高或太低）， 都可能導致預算批不下來，或者上線後超支被投訴。 FDE 的價值之一，就是幫客戶算出一個可信的數字， 並且告訴他怎麼優化。 二、AI 系統的 TCO 三個層次 Layer 1：LLM API 成本（最容易算） ├── Input token 成本 ├── Output token 成本 └── Embedding token 成本 Layer 2：Infra 成本（第二容易算） ├── Vector Database（託管服務 or 自建） ├── Compute（Cloud Run / GKE for orchestration） ├── Storage（GCS for documents） └── Network（Egress fees） Layer 3：人力成本（最容易被忽略） ├── 建置成本（Engineer 時間） ├── 維護成本（每月運維時間） └── Prompt 維護成本（調整和迭代） 三、實際試算：10,000 queries/day RAG Agent Step 1：LLM API 成本 Gemini 1.</description></item></channel></rss>