從 Vibe 浮濫到 Context Engineering：AI 時代的敏捷再思考
最近我有一種既熟悉又陌生的感覺——我們好像在重新快速走一遍軟體工程開發史，但這次是「反著走」。一切先從大 Vibe 時代談起，AI 讓我們可以極快地驗證創意、做出原型（POC）。但過於依賴靈感驅動與即時生成，也讓過程容易浮濫、缺乏工程上的紮實基礎。於是我在各處看到兩派不同的聲音開始碰撞。
POC 與 Operation 的視角差
在 AI 驅動的快速原型（POC）時代，老闆與 PM 往往希望「先做出來、先 demo、先驗證市場」。而資深工程師則會思考「這東西能不能穩定上線運行？架構是否可靠？可維護性與長期成本如何？」
AI 雖然可以幫忙快速產出原型，但同時：
- AI 可能生成品質不穩定的程式碼
- 需要更多 review 與設計確認時間
- 有時候資深工程師自己寫反而更快、更準確
而從 Engineering Manager 的角度我也看到新問題的產生，團隊協作的問題，團隊和 AI 協作的問題，開發環境一致性的問題…等，此外我覺得現實更殘酷：真正頂尖的工程師不多，的確高手工程師一定能做得比 AI 更好更扎實，他可能不需要 Vibe & Agent，他只需要 copilot 就夠，但其實市場上更多數團隊成員是中階或初階，如何在「速度」與「品質」之間找到平衡，成為新的管理課題。
Mini Waterfall + Context Engineering 會是新的方向嗎?
先聊聊什麼是 Context Engineering （上下文工程）是指在開發 AI 應用時，動態設計和管理 LLM（大型語言模型）所需的所有上下文資訊和工具，讓模型能更合理、更可控地完成任務。
它超越了單一的 Prompt Engineering，而是系統性地構建一個動態上下文系統，包括系統指令、用戶輸入、對話歷史、長期記憶、外部檢索資料、可用工具與結構化輸出等，並靈活調整哪些資訊在何時進入上下文視窗。
四種核心策略：
- 寫入 Context：保存資訊形成長期記憶
- 選擇 Context：動態挑選相關內容塞入上下文
- 壓縮 Context：濃縮與修剪資訊以節省容量
- 隔離 Context：在多代理系統中拆分上下文
沒錯！簡單來說就是寫文件，更具體的說就是怎麼利用文件跟 LLM 更好的溝通，讓他更可控，到頭來就有點像跑 mini waterfall 把軟體工程的每個流程都正確地跑一遍，確保需求、設計、開發、測試到交付都有清晰的驗證與交接。
我的 Context Engineering 實踐
一開始我聽到要使用 memory bank ，我也依樣畫葫蘆的儲存以下文件：
- projectVrief.md
- systemPatterns.md
- techContext.md
- activeContext.md
- productContext.md
- progress.md
但是文件只會越來越臃腫，每次要消耗的 token 越來越多，而且變更會越來越困難，就需要切分，所以我逐漸摸索演進，現在的玩法是一開始跟 AI 創意發想請他產生 PKD (Product kick off document)和初步的 WBS，然後開始逐步用架構的拆分文件類型放在 docs 目錄，產生更多 features 的目錄，在每個 feature 切分出 user story，每個 user story 裡面都有包含 DoD 和 AC 和你認為需要加進去的 rule，在 feature 目錄也會有 learning & changelog 文件，讓我事後可以 review 看未來需要修改和增加哪些 rule。
沒錯，就是更多的文件，更多的規劃，更多的 review，但是在以前的 waterfall 這可能要好幾個月，但是現在可能只需要幾個小時？那waterfall 又如何？所以我覺得很有趣，AI 時代讓許多人以為敏捷會全面取代瀑布，但現在反而讓 waterfall 又重新產生新的可能性——當 AI 能在每個階段快速產出與驗證成果時，短周期的 mini waterfall 不再是遲緩的代名詞，而可能成為快速交付高品質產品的可靠方式。
🚀 從《敏捷宣言》到《Modern Agile》，再到 Vibe & Context Programming
2001 年的《敏捷軟體開發宣言》（Manifesto for Agile Software Development）讓開發從僵化的瀑布式流程轉向快速回應變化、以人為本。
之後的《Modern Agile》強調安全、持續交付、快速學習與實驗，讓敏捷更貼近現實。
但如今，我們正進入 Vibe Programming 與 Context Programming 時代，開發流程與團隊協作的衝擊，比當年敏捷革命還劇烈。我在想新的 AI 敏捷宣言會不會變得因為太敏捷了，要穩定一下..XD
敏捷宣言逐條回顧，加入 AI 與新時代挑戰
👉 個人與互動 勝過 流程與工具
當年想解決：擺脫過度依賴工具與文件，重視團隊溝通。
AI 時代變化：AI 可協助生成說明、整合資訊，降低溝通成本。
新風險：AI 摘要取代真實對話，導致假共識與理解斷層。
👉 可運作的軟體 勝過 完整文件
當年想解決：避免花過多時間在文件，而產品卻沒法跑。
AI 時代變化：AI 生成的原型速度驚人，可快速驗證想法。
新風險：原型 ≠ 可營運系統；AI 產物常需大量重構才能上線。
👉 與客戶合作 勝過 合同談判
當年想解決：讓開發更貼近用戶需求，而不是被條款綁死。
AI 時代變化：AI 可分析用戶行為，快速生成 persona 與建議。
新風險：過度依賴數據模型，忽略真實情境與隱性需求。
👉 回應變化 勝過 遵循計劃
當年想解決：接受需求變動，而非固守原計劃。
AI 時代變化：AI 監測市場與需求變化的速度極快。
新風險：反應快不代表決策對，尤其當團隊缺乏深度分析能力。
AI + Agile：新的平衡點
對老闆與 PM：AI 讓 POC 成本低，但也必須理解「可上線運行」與「能 demo」之間的落差。AI 時代敏捷宣言（草案）
我們更重視：
有批判思維的協作 勝過 AI 提供的表面一致
可運行且可維護的系統 勝過 華麗但不可營運的 POC
清楚定義與驗證需求 勝過 全自動化的數據推論
團隊持續學習與成長 勝過 盲目追求交付速度
這不只是新工具的使用，而是價值觀的再平衡，這也不只是開發流程的轉折，也是角色之間價值觀的再協商。AI 讓我們更快，但工程品質、可持續運行能力，以及團隊能力分佈，才是決定成敗的根本。
沒有留言 :
張貼留言