AI Engineer onepage/ Factory FDE
Eno Reyes, Factory · 約 20:04
這支影片在講：Forward Deployed Engineering 不是客製支援，而是產品的感測器
Factory 把 FDE 放到客戶環境最前線：把真實工作訊號變成計畫、驗證與已交付結果，再回流到 Droid 的產品與自主性設計。關鍵不是派人「救火」，而是設計一套能在客戶內部持續變好的軟體工廠。
Published: 2026-07-28Video ID: wpOA-UXynoM
01 / 問題
客戶訊號常死在專案裡
若每次部署只完成一次性客製，產品團隊看不到重複出現的摩擦，也無法把現場知識複利回產品。
02 / 反轉
把部署視為軟體工廠
外部訊號進來，變成可執行計畫，經過驗證關卡後產出結果；FDE 是讓這條管線保持流動的人。
03 / 解法
以受限自主性逐步放權
先量 codebase 是否 agent-ready、能否 lint／type check／驗證，再讓 Droid 在客戶擁有的 harness 內擴大可完成的工作。
Watch for this
影片最值得抓的四個訊號
Customer ownership
Own it
model-independent harness 由客戶持有，trace 與資料不必離開環境。
Deployment mode
Air-gapped
Droid 可以在客戶環境隔離執行；企業採用的邊界不是事後補上的功能。
Migration scale
30–50M
影片以銀行大型 equities 系統遷移為例，說明自主性需要系統準備度。
Maturity test
Verify
不只問 agent 能寫多少，而是能否完成、跑檢查並驗證成果。
Core story
FDE 要避免的三個誤解
誤解 1
以為 FDE 是待在客戶端的支援工程師
0:00–5:03 的重點是「tip of the product」：FDE 不只是解當前問題，而是把客戶的真實需求、失敗模式與需求優先順序帶回產品，讓下一次部署更容易。
誤解 2
把 agent harness 當成供應商黑盒子
5:03–10:08 強調由客戶擁有、model-independent 的 harness。這既保留 trace 與資料主權，也讓隔離部署、治理與替換模型成為企業能接受的架構前提。
誤解 3
以為更高自主性永遠更好
10:08–20:04 提出 autonomy maturity model：先提升 codebase 的可檢查、可驗證程度，再擴大 agent 權限。走得過快會成為「未來城市的主題樂園」——漂亮但沒人真正使用。
Decision map
把客戶現場變成產品能力的迴路
1. 收集訊號，而不只接 ticket記錄工作如何實際發生、哪個環節卡住、什麼樣的需求反覆出現；這是產品決策的原料。
2. 轉成可驗證的計畫將需求交給 agent 前，先定義可檢查的環境與完成條件，避免只追求「看起來寫完了」。
3. 在客戶邊界內執行harness、trace 與資料由客戶控制；需要時可 air-gap，讓導入不必先交換最敏感的資產。
4. 用交付結果回饋產品把可重複的障礙和成功路徑回灌到 Droid，讓每次 FDE engagement 都降低下一次的風險與成本。
Use this checklist
若你在推 enterprise agent，先問這五題
客戶現場的訊號，是否能回到產品 roadmap？若部署知識只留在個人或專案簡報，FDE 就無法形成產品複利。
客戶是否掌握資料、trace 與 agent harness？先把資料主權與模型可替換性做成架構，而非把治理當採購後的補丁。
你的 codebase 有哪些機器可驗證的安全欄杆？lint、type check、測試與明確驗收，決定 agent 能在何處可靠地自己完成工作。
自主性提升是否對應到真正的業務價值？先找高槓桿任務，再決定放權幅度；不要因為能自動化就把所有流程交出去。
FDE 是否同時具備工程與商業判斷？影片的收束是：越靠近客戶，越需要理解取捨與採用節奏，而不只是能把程式寫出來。
Source video