纯干货！零基础小白怎么开始做 FDE？拆解观猹课程（附简历 面试 作品集技巧）

原始來源與檔名：2026-08-18T095446+0800-纯干货！零基础小白怎么开始做 FDE？拆解观猹课程（附简历 面试 作品集技巧）.md

SOURCE | 資訊源評估

• 準確性: 高 - 詳細拆解了 FDE 的職責、專案交付流程以及架構落地的具體環節，具有極高的實操指導意義。
• 易理解性: 高 - 使用豐富的類比（如將 API/MCP/CLI 比喻為辦事窗口與通訊錄）與真實場景（如物流超長件退換貨），對小白極度友善。
• 閱讀策略建議: 準備轉行或正在從事 AI 落地交付的讀者，應仔細閱讀「系統串接 (API/MCP/CLI)」與「EDD 評測驅動開發」這兩個最具工程價值的段落。

NAPKIN | 餐巾紙

餐巾紙公式

FDE 交付價值 = 需求收斂 (Scoping) + 系統串接 (API/MCP/CLI/UI) + 評測驅動開發 (EDD) + 知識沉澱 (Skill/Hook) FDE 不是寫個 Prompt 的駐場外包，而是在混沌的客戶現場，透過工程手段將 AI 模型變成一段穩定運作的業務流程。

一句話

全面解析 AI 時代的新興高薪職位 FDE（前線部署工程師），從定義、分類、專案交付細節、系統整合策略，到求職面試準備的保姆級實戰指南。

餐巾紙草圖

The FDE End-to-End Workflow
+----------------+      +-------------------+      +------------------+
| 1. Scoping     | ---> | 2. MVP & Spec     | ---> | 3. Integration   |
| - Talk to users|      | - Define limits   |      | - API / MCP      |
| - Find pain    |      | - SOW & Demo      |      | - CLI / UI Auto  |
+----------------+      +-------------------+      +------------------+
                                                            |
                                                            v
+----------------+      +-------------------+      +------------------+
| 6. Handoff     | <--- | 5. Accumulation   | <--- | 4. EDD Testing   |
| - Real metrics |      | - Skills & SOPs   |      | - MVP Contract   |
| - UI/UX Docs   |      | - Subagents/Hooks |      | - LLM Judge + Q/A|
+----------------+      +-------------------+      +------------------+

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

• 核心問題: AI 模型很強大，但在真實企業環境中往往水土不服。如何將 AI 真正落地解決客戶的業務問題？FDE（前線部署工程師）這個崗位具體做什麼？
• 核心答案: FDE 需要深入客戶一線，理解業務邏輯，制定 MVP 邊界，選擇合適的系統介面（API/MCP/CLI）接入，透過 EDD（評測驅動開發）不斷優化，最終沉澱出可複用的技能 (Skill)。
• 論證結構: 職位定義 -> 崗位分類 -> 專案啟動方法 -> 交付與合約細節 (SOW/Spec) -> 工程架構 (Skill/MCP) -> 系統接入 (API) -> 測試方法 (EDD) -> 求職與面試技巧。

章節骨架

1. FDE 職責定義: 深入真實環境，對業務結果端到端負責。
2. FDE 分類: 依據背景分為商務型 (Echo)、產品型、工程型 (Delta)。
3. 首個專案策略: 從熟悉的中小企業切入，從小範圍、可人工複核的任務開始。
4. 專案管理文件: 釐清 SOW（合約）、Spec（規格）、Demo、MVP 之間的差異與重要性。
5. 能力沉澱: 利用 Skill (SOP)、CLI、Subagent、Hook 讓 Agent 從會聊天變成能做事。
6. 企業系統接入: 解析 API (直連)、MCP (工具選單)、CLI (命令)、UI 自动化 (兜底) 的適用場景。
7. EDD 評測驅動開發: 傳統測試不適用於隨機性高的 Agent，需遵循六步循環。
8. 求職指南: 辨別真假崗位、履歷撰寫公式、作品集準備、行為面試與 Scoping 測試。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

論證鏈

Agent 的產出具有黑盒與隨機性 --> 傳統的自動化測試（單元測試）無法保證 Agent 在邊界情況下不犯錯 --> 必須採用 EDD（評測驅動開發），準備包含邊界與錯誤的評測集，利用 LLM Judge 初篩並進行迴歸測試。

客戶需求往往極度發散（「我要一個萬能客服」）--> 直接開發會導致規則無限膨脹且無法上線 --> FDE 必須在前期進行 Scoping，約定 SOW 和 MVP 契约，收斂出一個極小但能跑通的閉環。

關鍵證據

1. 滑雪板客服案例: 完美展示了為什麼單純的「知識庫 AI」會失敗，因為真實業務充滿了「超長件運費」等隱性規則，需要 FDE 來梳理。
2. 系統接入的優先級: 作者明確給出 API > MCP > CLI > UI 自动化 的決策樹，這是極具工程實戰經驗的總結。
3. EDD 的六步循環: 點出了 Agent 開發中最痛的「迴歸測試」問題——「修好一個新問題，舊問題不能回來」。

隱形假設與邊界

• 隱形假設:
  • 企業願意向 FDE 開放真實資料、業務流程與一線員工訪談。
  • 底層的 LLM 模型能力已達到基本門檻，問題出在「工程封裝」與「業務對齊」。
• 邊界條件: UI 自动化僅作為「沒有 API 且無法二開」時的兜底方案，不能作為 Agent 系統的常態。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 作者盲點: 文章側重於 2B 企業級交付，對於 2C 產品或純開源專案中 FDE 如何發揮作用著墨較少。此外，對於「客戶不願意提供私有資料」的 Trust Issue 解決方案較為簡略。
• 知識連接:
  • FDE 的 Echo/Delta 分工源自 Palantir。
  • MCP (Model Context Protocol) 正在成為各大模型串接本地工具的標準協議。
• 行動觸發: 若在準備 AI 相關履歷，請立即將經歷改寫為公式：「有責任感的動詞 + 你構建的東西 + 業務場景 + 可驗證結果（如：減少人工介入比例）」。

留白提問 (Guided Reflection)

• 提問：為什麼文章強調 FDE 要學會對客戶說「不」？
  • 架構師視角 (引導思路)：因為 AI 的邊界極其模糊。客戶容易陷入「科幻想像」，把 AI 當成人類員工。FDE 說「不」是為了框定 MVP，將「不可預測的通用 AI」降級為「可驗測的自動化 Agent」。
• 提問：在建立 Skill 時，為什麼要包含「什麼情況必須找人 (Human-in-the-loop)」？
  • 架構師視角 (引導思路)：這是高風險業務的護欄。LLM 存在幻覺，設計 Agent 時，最重要的一步是定義「信心閥值」，當不確定性過高或涉及金流時，強制轉移給人工 (Fallback機制)。

跨域映射

• 在 傳統軟體工程，這叫 技術顧問 (Technical Account Manager) + 解決方案架構師 (Solution Architect) 的結合體。

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

1. 六、API、MCP、CLI 和 UI 自动化：企业系统到底怎么接？
   • 「API 是系统本身的接口，MCP 和 CLI 是 Agent 调用这些能力的不同方式，UI 自动化则是在没有接口时的备用方案…」
   • 推薦理由: 將抽象的系統接入協議，用「辦事窗口、通訊錄、命令終端」進行神級類比，秒懂 Agent 的底層互動邏輯。
2. 七、传统测试不适合agent：EDD循环六步走
   • 「黑盒、随机性、耦合性、隐性标准、分布漂移… 新问题好了，旧问题也可能被改坏。修好一个新问题，旧问题不能回来。」
   • 推薦理由: 這是傳統軟體工程師轉型 AI 開發最容易踩的坑。深刻理解 Agent 測試為什麼不能只看最終答案，而必須看「運行軌跡」。

STRUCTURE MAP | 全書結構圖

FDE Playbook
+-- 1. What is FDE?
|   +-- End-to-end responsibility in real environments
|   +-- Echo (Business/Product) vs. Delta (Engineering)
+-- 2. Project Initiation
|   +-- Start small (friends, familiar industries)
|   +-- Observe real workflows & edge cases
+-- 3. Delivery Mechanics
|   +-- SOW (Contract/Scope)
|   +-- Spec (Development Guide)
|   +-- Demo (Proof of Concept)
|   +-- MVP (Usable workflow)
+-- 4. Agent Architecture
|   +-- Skill (SOP & rules)
|   +-- CLI / MCP (Tool access)
|   +-- Subagents (Task division)
|   +-- Hooks (Automated triggers)
+-- 5. System Integration Hierarchy
|   +-- 1. API (Direct stable link)
|   +-- 2. MCP (Standardized tool menu)
|   +-- 3. CLI (Local/Batch commands)
|   +-- 4. UI Automation (Last resort)
+-- 6. Evaluation-Driven Dev (EDD)
|   +-- LLM Judge
|   +-- Edge cases & Regressions
+-- 7. Career & Interviews
    +-- Resume formula
    +-- Portfolio storytelling
    +-- Scoping during interviews

纯干货！零基础小白怎么开始做 FDE？拆解观猹课程（附简历 面试 作品集技巧） (Architectural Deep Dive)

前言/背景

FDE (Forward Deployed Engineer，前線部署工程師) 是 AI 時代極具含金量的新興崗位。由於模型能力與客戶真實業務之間存在巨大鴻溝，FDE 的角色應運而生。本文深度拆解了 FDE 的實戰技能，不僅適合想入行的零基礎小白，也是一本極佳的 AI Agent 企業級落地手冊。

章節詳細總結

1. FDE 的本質與分類

FDE 不是躲在後端寫 Prompt 的外包，而是要進入客戶的真實環境，對「可衡量的業務結果」端到端負責。根據 Palantir 的分工，FDE 可分為：

• Echo (商務/產品型)：聽懂客戶業務，將模糊需求轉化為可執行的方案，並確認驗收標準。
• Delta (工程型)：快速製作原型，處理數據接入系統，保證 Agent 在生產環境穩定運行。

2. 專案啟動與範圍界定 (Scoping)

第一次做專案不要找大公司，從熟悉的行業與人切入。

• 防坑指南：不要客戶說一句就開始開發。必須先撰寫 SOW (工作說明書) 確定商業邊界，再撰寫 Spec (開發說明書) 確定技術細節。
• MVP 契约：先用 Demo 證明方向，再做出只跑通一條核心流程的 MVP。學會對客戶不切實際的需求說「不」。

3. 架構沉澱：Skill、MCP、CLI 與 Hook

一個能做事的 Agent 需要以下元件組合：

• Skill: Agent 的崗位 SOP（包含業務規則、步驟、邊界條件）。
• CLI / MCP: Agent 操作系統的工具箱。
• Subagent: 分工小組，避免單一 Agent 負載過重。
• Hook: 流程中的自動化開關與警報器。 專案結束後，FDE 必須將這些元件沉澱下來，以便下一個客戶能直接複用。

4. 系統接入決策樹 (Integration)

面對企業系統，Agent 有四種接入方式，具有嚴格的優先順序：

1. API: 系統原生穩定介面，最適合大量資料讀寫。
2. MCP (Model Context Protocol): Agent 的標準化「工具選單」，適合封裝多個工具供 Agent 動態呼叫。
3. CLI: 命令列工具，適合將複雜流程打包成一條命令，明確知道成功或失敗。
4. UI 自动化 (RPA): 讓 Agent 透過視覺點擊按鈕。因為極易出錯，僅在沒有 API 接口時作為兜底方案。

5. 評測驅動開發 (EDD)

Agent 具備黑盒與隨機性，傳統測試無效。必須採用 EDD：

• 真實評測集: 包含資訊不全、規則衝突、邊界情況的真實問題。
• LLM Judge: 利用強模型進行初步關聯性篩選。
• 分析軌跡: 不要只看答案對錯，要看 Agent 調用了什麼工具、看了什麼資料。
• 迴歸測試: 修好一個 Prompt 後，必須重跑所有歷史題目，防止「修好新問題，改壞舊問題」。

6. 求職、履歷與面試

• 履歷公式: 「有責任感的動詞 + 你構建的東西 + 業務場景 + 可驗證結果」。(例如：為零售場景負責數據管道部署，將準備週期從數週壓縮到數天)。
• 作品集: 不要只給一個 Demo 連結。要寫成一段「交付故事」：從模糊的需求開始，到你如何作取舍、設計測試、直到最後的結果。
• 面試核心: 當面試官給出一個龐大且模糊的需求時，他們想看的不是你技術多牛，而是你**「會不會先釐清使用者是誰、痛點是什麼、邊界在哪裡 (Scoping)，把大問題切成小閉環」**。

總結與結論

FDE 最終交付的不是一個「看起來很酷的 Agent 模型」，而是一段「已經跑起來、有人願意持續使用並能解決痛點的業務流程」。這個崗位要求極強的溝通力、工程能力與業務嗅覺，是銜接 AI 技術與商業價值最關鍵的橋樑。