Erik 說「明天早上九點，我帶你去看一座工廠」——然後你睜開眼睛。

窗外不是 2013 年的 Parts Unlimited，是 2026 年，你自己的辦公室。牆上掛著三個白板：「Data Team」、「Platform Team」、「AI Team」。

那天就像一場濃縮的夢：你以 Bill Palmer 的身份，走過看不見的工作、Brent 的瓶頸、救火與稽核，最後終於承認——問題從來不是人不夠努力，是系統壞了。

現在你醒了。困境卻一模一樣，只是換了戰場。

兩週前，你接下這家公司的技術總監職位。CEO 給了你一個任務：「要做 AI Transformation。半年內，我要看到一個能上線的 AI Agent 產品。」

Bill 的地圖還在你手裡。但這次，要走的是你自己路。

底下三個團隊——Data、Platform、AI——都已經動起來了，各自埋頭在資料清洗、K8s 部署、模型實驗上。每個團隊都說「我們很忙、進度正常」，每週會議上大家都有進度可呈報。

但你心裡很清楚：沒有人知道這三塊東西怎麼拼接起來。

你想起 Erik 在夢裡對 Bill 說的第一句話：「在動手之前，先看清楚整個系統。」

場景：三支部隊，零份地圖

第一週的全員會議上，你問了同一個問題：「能不能有人畫出來，從一個 AI 需求進來，到最後產品上線，中間會經過哪些步驟？」

沉默。

Data Lead 先開口：「嗯——我們這邊會拿到資料，做清洗、標註、特徵抽取，然後存進 Feature Store。」

Platform Lead 接著說：「我們負責模型的容器化、部署流程、監控告警，還有 A/B Testing 的基礎設施。」

AI Lead 補充：「我們會訓練模型、調參、做 Prompt Engineering，然後交給 Platform 部署。」

你追問：「那『交給』是怎麼交？Feature Store 的 Schema 誰定義？模型的輸入格式誰來對齊？如果線上模型出問題，誰負責回滾？資料漂移偵測是 Data 做還是 Platform 做？」

又是沉默。

最後 Data Lead 說了一句：「這些——我們之後再來討論吧。現在大家先把自己負責的部分做好。」

你突然明白了。

每個人都在衝刺，但沒有人看得見整條跑道。

這就是 Bill 在接手 Parts Unlimited 時看到的景象：大家都在忙，但沒有人知道整條價值流長什麼樣子。

你打開 Jira，三個團隊的 Board 各自獨立：

Data Team Board:

• ✓ 設計 Feature Store Schema
• ✓ 建立資料清洗 Pipeline
• → 製作特徵工程模組（In-Progress）
• → 設定資料版控（To Do）

Platform Team Board:

• ✓ 架設 K8s Cluster
• ✓ 設定 GitOps Workflow
• → 建立 Model Serving 環境（In Progress）
• → 製作金絲雀部署（To Do）

AI Team Board:

• ✓ 評估 5 個 Embedding Models
• ✓ 建立 RAG Prototype
• → 調整 Prompt Template（In Progress）
• → 整合外部 API（To Do）

三個看板，零個 Dependency。

每個團隊都說「進度正常」，你看不見它們會在哪裡碰撞、會在哪裡等待、會在哪裡互相卡死。

你想起夢裡 Erik 帶 Bill 去的那座工廠：零件從一端進去，成品從另一端出來，整條產線一目瞭然。你可以看見哪裡有庫存堆積、哪台機器是瓶頸、哪個交接點在等待。

但在你的組織裡，這條「產線」是隱形的。

兩難：立刻開幹？還是先畫地圖？

CEO 在走廊上攔住你：「怎麼樣？團隊準備好了嗎？董事會下個月要看 Demo，我希望至少能展示一個可以跑的 Prototype。」

你站在原地，腦中浮現兩條路：

如果是你，現在就要做決定。是立刻開工讓 CEO 看到進度，還是先停下來畫出整條價值流？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：先看見整條河，再決定在哪裡築壩

正確答案是 B。

但這是最反直覺的選擇。當 CEO 要進度、當團隊已經動起來、當每個人都說「我知道我要做什麼」的時候，你為什麼要叫大家停下來開會？

因為 《鳳凰專案》的 The First Way 就是 Systems Thinking（系統思考）：

「優化整體流動，而不是局部效率。」

Erik 帶 Bill 去工廠看的不是「哪台機器最快」，而是「整條產線的瓶頸在哪裡」。

切削機每分鐘切 100 片，但下一站打磨機只能磨 50 片，切削機再快也沒用——半成品只會堆在中間等待。最慢的那一站，決定整條產線的速度。

這就是限制理論（Theory of Constraints, TOC）的核心：找出瓶頸，讓其他步驟服從瓶頸。

在你的 AI 專案裡，情況一模一樣：Data 做再快的 Feature Engineering，如果 Schema 對不上就是白做；Platform 架再完整的部署流程，模型格式不符就無法上線；AI 調再好的模型，資料品質不穩就會天天出問題。

如果不先看清楚整條價值流，三個月後你會發現：每個人都完成了自己的部分，但整體接不起來。

這時候，你需要的是 Value Stream Mapping（價值流圖）。

畫出從「一個 AI 需求提出」到「產品上線並穩定運行」的每一個步驟：

📥 需求提出 → 📊 資料收集 → 🏷️ 特徵工程 → ⚙️ 模型訓練 → 🧠 模型評估 → 🐳 容器化 → 🧪 部署到 Staging → 🔍 測試 → 🚀 部署到 Production → 📈 監控 → 🔄 迭代優化

然後標出每個步驟：

• 處理時間（真正在做事的時間）
• 等待時間（等上一步交付、等審查、等環境的時間）
• 負責人（哪個團隊／哪個角色）
• 交接點（資訊／產出在哪裡交接，用什麼格式）

當你把這條線畫出來，你會震撼地發現：大部分的時間花在等待，而不是做事。

這就是 Bill 在工廠看到的景象：每台機器前面都堆著半成品在等。

Systems Thinking 的第一步，就是讓價值流「可視化」。

你要看的是整條河，而不是河裡的每一塊石頭。

如果有 AI Agent：讓價值流從隱形變可見

問題是，要三個團隊的人坐下來開兩天工作坊「畫價值流」，會被罵死：

「我們已經很忙了，哪有時間開會？」

「這種東西畫出來也只是形式，不如直接做。」

這時候，AI Agent 可以幫你做一件事：從現有的工具紀錄裡，自動重建出「實際的價值流」。

graph TD
    A[Jira tickets] --> D[Agent 分析]
    B[Git commits] --> D
    C[CI/CD pipeline logs] --> D
    D --> E[重建需求流經的路徑]
    E --> F{標出瓶頸與等待}
    F --> G[Data+AI 交接卡 3 天]
    F --> H[AI->Platform 格式不符,<br/>返工 2 次]
    F --> I[部署審查平均等 5 天]
    G --> J[產出初版價值流圖]
    H --> J
    I --> J
    J --> K[團隊 review meeting:<br/>這才是真實狀況]

Agent 做的事很直接：抓取 Jira Tickets、Git Commits、CI/CD Logs，用 LLM 串起這些點，把「一個需求的完整旅程」畫出來，標註等待時間、交接點、瓶頸。

幾個小時後，Agent 產出一份報告：

過去 3 個月 AI 功能的實際價值流診斷報告

⏱️ 時程指標

• 平均 Lead Time：52 天
• 實際處理時間：14 天（27%）
• 無效等待時間：38 天（73%） 👈 高達七成時間處於閒置等待

⚠️ 關鍵瓶頸分析

1. Data → AI 交接等待：平均等待 8 天
   • 原因：Feature Schema 未事先對齊。AI Team 拿到資料後發現格式不符，需要反覆回頭修改。
2. 部署前審查等待：平均等待 5 天
   • 原因：需要 Data、AI、Platform 三方同時進行手動簽核，排隊等待人員回覆。
3. Production 環境設定：平均失敗 2.3 次才成功
   • 原因：環境 Config 仍採手動配置，極易遺漏關鍵參數。

💡 優化行動建議

• 建立 Feature Schema 的「設計先行」規範。
• 採用自動化檢查流水線取代人工手動審查。
• 將環境設定完全改為 GitOps（Infrastructure as Code, IaC）架構。

這就是 2026 年的做法：不是開兩天工作坊，而是讓 Agent 從現有數據裡挖出「實際發生了什麼」，幾小時就畫出價值流草圖。

然後團隊坐下來，看著這份報告，第一次意識到：「原來我們超過七成的時間都在等待。」

Systems Thinking 的第一步，就是讓隱形的流動變成可見的地圖。

現場推演：那個做好卻無法上線的模型

來看一個常見的情況（綜合改編，數字為示意）。

想像一個 15 人的 AI 團隊，分成 Data（5人）、Model（6人）、Infra（4人）三組。CEO 要他們半年內做出一個「智能客服 Agent」。

三個月後，每個組都說「完成了」：

• Data 組：清洗了 50 萬筆對話紀錄，建好了 Feature Pipeline，每天自動更新。
• Model 組：調出一個準確率 87% 的 RAG 模型，內部測試表現很好。
• Infra 組：架好了 K8s Cluster，設定了 CI/CD，部署流程跑得通。

但是，當他們要整合上線時，災難發生了：Data 的輸出格式是 JSON，Model 訓練用的是 Parquet；Model 需要呼叫外部 API，Infra 的 K8s 沒開外網權限；部署後 Latency 超標，但沒人知道 SLA；線上資料格式跟訓練時不同，模型直接崩潰。

團隊花了兩個月修補，錯過了產品發布窗口。

事後檢討時，Tech Lead 說：「如果我們在第一週就把完整流程畫出來，這些問題三天就能發現，而不是三個月後爆炸。」

Systems Thinking 最難的不是技術，而是承認「我們需要先停下來看清楚」。

今日金句

「先看見整條河，再決定在哪裡築壩。在看不見的系統裡優化，只是瞎子摸象。」

留給你的問題

你的專案，有沒有人能完整畫出「一個需求從想法到上線，經過的每一手」？

如果答案是「沒有」，那你就知道你是在優化整體，還是在做局部白工。

明天，我們會面對一個更殘酷的真相：你以為每個團隊「很有效率」，其實只是他們把自己那一段做快了——但整體交付還是慢，因為時間都花在「等待」上。

局部最佳化 ≠ 整體最佳化

這是 Systems Thinking 最反直覺的一課。

Day 12 見。