🌏 Read this article in English
作者：rajatim
摘要：我們頌揚「敏捷」與「快速失敗」，卻很少談論失敗的代價。本文將探討一個正在發生的產品開發範式轉移：從「假設驅動開發」，邁向一個由 DevOps、PM 與 AI 共同構成的「持續進化智慧」體。這不僅是流程的優化，更是技術人員自我價值的一場革命。
1. 引言：我們「快速失敗」了太多次
你是否也遇過這種情況？
產品經理 (PM) 拿著一份 50 頁的市場分析報告，在會議上宣告：「我們的下一個殺手級功能，是 AI 個人化推薦！」團隊熱血沸騰，投入了數週甚至數月的時間進行開發、測試與部署。功能上線後，所有人的目光都緊盯著後台儀表板，上面卻只有一條孤伶伶的曲線，標示著「總點擊率：0.5%」。
會議室裡一片沉寂。沒人知道下一步該怎麼辦。這個功能是成功還是失敗？我們應該繼續優化，還是承認失敗並轉向？我們又一次「快速失敗」了，但背後是團隊被消耗的精力與熱情。
我們擅長建造一艘能快速轉向的船（敏捷開發），卻依然在用古老的海圖和時常失準的直覺來導航（假設驅動）。
如果這艘船能自己發現新航線呢？
本文將探討一個正在發生的範式轉移：從我們熟悉的「假設驅動開發」(Hypothesis-Driven Development)，邁向一個由 DevOps、PM 與 AI 共同構成的、更令人興奮的未來——「持續進化智慧」(Continuously Evolving Intelligence)。
2. 舊世界：假設驅動開發的榮耀與困境
首先，我們得先肯定「假設驅動開發」的價值。敏捷開發、數據驅動、A/B 測試——這些方法論是我們擺脫「瀑布式開發」泥潭的偉大創舉。它們讓我們學會了用小步快跑的方式去探索未知，用數據來驗證我們的每一個猜想。這是一個巨大的進步。
但它的天花板也清晰可見：我們探索的邊界，取決於我們想像力的邊界。
我們永遠無法測試一個我們從未想過的假設。我們精心設計 A/B 測試來比較紅色按鈕和藍色按鈕的優劣，卻可能從未想過，也許用戶根本不需要那個按鈕。我們分析著儀表板上已知的指標，卻忽略了指標之外的海量資訊。
這是一個被動的、反應式的模型，我們仍在扮演上帝的角色，等待數據來「裁決」我們的想法。
3. 新世界：持續進化智慧的崛起
現在，想像一個新世界。在這個世界裡，產品本身不再是一個被動的、等待更新的軟體，而是一個活的、會學習、能與我們共同進化的「智慧體」。
這個智慧體的關鍵轉變，是從驗證已知 (Validating the Knowns) 到發現未知 (Discovering the Unknowns)。
讓我舉一個例子來凸顯其中的差異：
- 舊模式的 AI 會告訴你： 「根據你的 A/B 測試假設，紅色按鈕的點擊率確實比藍色高 5%。」—— 這是在回答你的問題。
- 新模式的 AI 會告訴你： 「數據顯示，那些在週二晚上用過『歷史訂單』功能，並在週五早上訪問過登入頁面的用戶，他們的 90 天留存率是其他用戶的 10 倍。這是一個我們從未定義過，但極具價值的用戶群體。」—— 這是 AI 在向你提出你從未想過的問題。
這就是「持續進化智慧」的力量。它不再只是驗證你的猜想，而是為你揭示隱藏在數據海洋深處、連你自己都不知道存在的「機會大陸」。
要建立這樣一個智慧體，需要從根本上重塑團隊中兩個核心角色的價值。
4. 角色的重塑 (一)：PM – 從「首席假設官」到「智慧策展人」
在新世界，PM 的角色得到解放與升華，他們成為「智慧策展人」(Intelligence Curator)：
- 策略引導者： PM 的工作不再是想出具體的 User Story，而是為 AI 設定探索的大方向。例如：「這個季度，我們的商業目標是提升用戶活躍度。請 AI 專注於探索『用戶行為』與『功能使用頻率』之間的非線性關聯。」
- 機會策展人： AI 會從數據中發掘出數十甚至數百個潛在機會。PM 的核心工作，是運用他們的商業頭腦和產品嗅覺，從中挑選出最具價值的機會，並將其轉化為下一階段的產品策略。
PM 不再是那個必須給出所有答案的人，而是那個懂得如何向一個更聰明的「智慧體」問問題、並解讀其答案的策略家。
5. 角色的重塑 (二)：DevOps – 從「功能的管道工」到「中樞神經系統的架構師」
在新世界，DevOps 工程師的角色變得前所未有的重要，他們成為產品的「中樞神經系統架構師」(Central Nervous System Architect)：
- 數據神經設計師： 他們設計和建造產品的「數字神經系統」。CI/CD Pipeline 不再只是傳送程式碼的管道，而是確保每一次用戶點擊、每一次 API 調用、每一次系統錯誤，都能化為高品質、結構化的「神經信號」（例如，JSON 格式的日誌、帶有豐富標籤的 Metrics），並可靠地傳遞給 AI 大腦。
- 智慧基建提供者： 他們提供並維護 AI 模型所需的運算與數據基礎設施。例如，將 Elasticsearch 從一個被動的日誌搜尋工具，升級為 AI 進行模式識別的「長期記憶體」；將 CI/CD Pipeline 從一個部署工具，升級為一個能自動觸發模型訓練與分析的「神經脈衝」。
DevOps 的工作不再是確保功能「上線」，而是確保產品「持續學習」。
6. 如何建造這個智慧體？(落地技術錨點)
這個宏大的願景並非遙遠的科幻，它完全可以由當今成熟的技術棧，像樂高一樣一塊塊組裝而成。
6.1 智慧體的「中樞神經系統」架構
要讓智慧體能夠感知和學習，我們首先需要為它打造一個數據中樞神經系統。這是一個簡化的參考架構圖：
graph TD
subgraph "應用程式 (感知層)"
A["服務 A - OpenTelemetry"]
B["服務 B - OpenTelemetry"]
C["服務 C - Log Files"]
end
subgraph "數據收集與傳輸"
D["Collector - Fluentd/Filebeat"]
E["數據流 - Kafka/Kinesis"]
end
subgraph "長期記憶與大腦"
F["時序數據庫 - Prometheus"]
G["日誌/事件數據庫 - Elasticsearch"]
H["AI 分析工作 (Spark/Python Job)"]
end
subgraph "反饋與行動"
I["告警 - Slack/PagerDuty"]
J["儀表板 - Grafana/Kibana"]
K["自動化行動 - JIRA Ticket"]
end
A -- Metrics/Traces --> D
B -- Metrics/Traces --> D
C -- Logs --> D
D --> E
E --> F
E --> G
F -- 數據源 --> H
G -- 數據源 --> H
H -- 洞察 --> I
H -- 洞察 --> J
H -- 洞察 --> K
K --> A
K --> B
- 感知層: 我們的服務透過
OpenTelemetry標準函式庫，主動產生結構化的指標 (Metrics) 和追蹤 (Traces)。對於舊系統，則由Filebeat等代理程式採集日誌檔案。 - 傳輸與記憶: 數據由
Fluentd收集後，推送到Kafka這樣的數據流平台，最終分別存入專門的數據庫，例如Prometheus存放指標，Elasticsearch存放日誌和事件。這就是智慧體的「長期記憶」。 - 大腦與反饋: AI 分析工作（例如一個定期的 Python 腳本）會從「長期記憶」中讀取數據，進行模式識別或異常偵測，並將結果（「洞察」）透過
Slack告警、更新Grafana儀表板，甚至自動建立一個JIRA任務來觸發行動。
6.2 大腦的核心：一個「平易近人」的異常偵測程式碼
「AI 分析」聽起來很昂貴，但它的起點可以非常簡單。以下是一個用 Python 和 scikit-learn 進行異常偵測的例子，它可能不到 30 行，卻威力強大。
假設我們有一個 api_latency.csv 檔案，記錄了 API 的回應時間：
timestamp,latency_ms
2025-11-20T10:00:00Z,120
2025-11-20T10:01:00Z,125
...
2025-11-20T10:30:00Z,950 # <-- Anomaly
...
2025-11-20T11:00:00Z,130我們的「AI 大腦」腳本可以這麼寫：
import pandas as pd
from sklearn.ensemble import IsolationForest
data = pd.read_csv('api_latency.csv')
latencies = data[['latency_ms']]
# 2. 建立一個簡單的 AI 模型
# IsolationForest 擅長發現「與眾不同」的數據點
model = IsolationForest(contamination=0.01) # 假設 1% 的數據是異常的
model.fit(latencies)
# 3. 找出異常點
data['anomaly_score'] = model.decision_function(latencies)
data['is_anomaly'] = model.predict(latencies)
anomalies = data[data['is_anomaly'] == -1]
# 4. 產生洞察 (觸發反饋)
if not anomalies.empty:
print("🚨 發現潛在的 API 延遲異常！")
print(anomalies)
# 在這裡，你可以加入發送到 Slack 或 PagerDuty 的程式碼這個例子完美地詮釋了我們的觀點：重點不在於演算法多麼高深，而在於我們建立了一個能自動『感知 -> 記憶 -> 思考 -> 反饋』的系統。 這個簡單的腳本，就是「持續進化智慧」這個宏大願景的一個真實、可觸摸的起點。
7. 你的第一步：種下智慧的種子
這個願景很宏大，但起點可以很微小。
今天就做一個改變： 要求你的團隊在提交每一個合併請求 (Merge Request) 時，不僅要描述「這個 MR 做了什麼」，更要回答一個問題：
「我們應該觀測哪些指標，來證明這個 MR 是成功的？」
把這個回答寫進 MR 的描述裡。恭喜，你已經種下了從「交付功能」轉向「交付可觀測性」的第一顆種子。這不是額外的工作，而是思考模式的轉變。它迫使我們在寫下第一行程式碼時，就開始思考如何讓我們的產品「可知、可測、可學習」。
這就是「持續進化智慧」的開端。
8. 結論：你的未來：選擇做工程師，還是架構師？
我們正處於一個軟體開發的十字路口。舊的模式讓我們成為了高效的「功能實現者」，日復一日地完成來自產品待辦清單的任務。
而新的範式提供了一個完全不同的可能性。
它邀請我們從單純的執行者，轉變為一個更具創造性和影響力的角色。PM 可以成為數據海洋中的策略領航員，DevOps 可以成為智慧系統的總設計師。
這不僅是開發流程的演進，更是技術人員自我價值的演進。
所以，你想繼續做一個高效的工程師，還是想成為一個能設計和建造「自我進化系統」的「數位世界的建築師」？
未來的贏家，將屬於那些能最快完成這個範式轉移，並圍繞「持續進化智慧」來重組團隊的組織。