背景：從 DevOps 到 ContextOps
二〇〇九年，Patrick Debois 提出 DevOps 這個詞，核心想法很簡單：如果維運團隊能像開發團隊一樣思考，用工程方法管理基礎設施與部署流程，軟體交付會變得更可靠。十多年後，他觀察到 AI 程式設計代理（AI coding agent）大量進入軟體開發流程，團隊面對的新問題不再是「程式碼怎麼寫」，而是「怎麼讓 AI 寫出正確的程式碼」。他在 QCon London 2026 的演講「Context Is the New Code」中提出一個類比：如果我們把提供給 AI 的上下文（context）當作程式碼來管理，套用軟體開發生命週期中的測試、部署、套件管理與安全掃描，組織就能可靠地大規模使用 AI 代理，控制非確定性輸出，並累積長期知識。他把這套思維稱為 Context Development Life Cycle，與傳統的 Software Development Life Cycle 相對應，包含四個環節：生成、評估、分發、觀察。
生成：把上下文當作可管理產物
演講中，Debois 先區分了「上下文工程」（context engineering）與「上下文作為工件」（context as an artifact）。前者指的是代理執行時決定要把哪些內容放進 LLM 的上下文視窗，後者則是人類預先準備好的規則、說明、規範與知識文件。他強調自己要談的是後者。過去兩年，這類內容逐漸標準化：Anthropic 的 Claude 依賴 CLAUDE.md 檔案，而其他廠商也開始支援 AGENTS.md，這使得同一份上下文可以在不同工具之間重複使用。除了規則檔，還有另一類上下文來自程式庫與文件：例如 Context7 和 Ref 這類工具會掃描專案的相依套件，自動抓取對應版本的使用文件，讓代理在寫 Express 或其他函式庫的程式時有更好的參考。微服務團隊也可以發布「如何使用這個服務」的上下文，供其他團隊的代理取用。MCP（Model Context Protocol）連接器則能讓代理查詢 Slack、工單系統與內部 Wiki，找到人類工程師平常會翻閱的決策紀錄。此外，規格（spec）也成為一種新形態的上下文：不是 prompt，而是類似產品需求文件的任務描述。Kiro 把它視為任務規格，SpecKit 則把它當作長期維護的產品功能文件。Debois 的結論是，人類的角色從「寫程式的人」變成「策展上下文的人」：代理決定讀什麼，但人類要確保它讀到的東西是最新、正確且完整的。
評估：用測試思維衡量上下文品質
有了上下文之後，下一步是評估品質。傳統軟體開發用測試來衡量程式碼是否正確，那上下文的測試是什麼？Debois 提到 SWE-bench，這是一個由大量真實 GitHub issue 組成的基準測試集，用來衡量模型能否解決實際程式任務。但他提醒，多數團隊不是在訓練模型，而是在撰寫上下文，因此更務實的做法是自建評估（eval）。有些工具可以啟動 Docker 容器、執行代理、餵入任務輸入，再跑測試判斷成功或失敗。團隊可以比較「沒有上下文」「有舊上下文」「有新上下文」的結果差異。更輕量的做法是對上下文做 lint：檢查 YAML 格式、描述欄位長度、是否缺少必要欄位，就像檢查程式碼風格一樣。再進一層，可以用 LLM-as-a-judge 的方式，讓模型評斷上下文寫得是否清楚、是否冗長、是否符合目標模型的風格，Debois 戲稱這是「Grammarly for context」。真正的端對端測試則是在自己的 repository 中進行：從某個 commit 出發，給代理一個任務，跑完整流程，確認產出是否正確。Vercel 就是這種做法的實例，他們會測試不同模型在自己函式庫上的表現，並調整該提供什麼文件與最佳實踐給代理。Debois 也指出，代理輸出具有非確定性，同一測試跑五次可能五次結果不同，因此團隊需要接受「大部分時候通過」的標準，並像管理 error budget 一樣分配風險容忍度：某些關鍵功能必須嚴格通過，其他部分可以寬鬆一些。他強調，不要直接購買廠商提供的現成評估指標，因為乾淨環境的測試結果無法反映自家程式碼的真實狀況。
分發：套用套件管理與安全掃描
當上下文被驗證有效後，下一步是分發。最原始的做法是把檔案放上 GitHub，其他人 clone 專案就能取得，但跨專案共享時，Git submodule 的體驗很差，容易忘記更新。Debois 認為真正的解法是套件管理器：把上下文打包成 npm 或其他格式的套件，推送到 registry，其他人用一行指令就能安裝指定版本。團隊規則、前端開發指南、特定函式庫的使用說明都可以變成獨立套件。Skills 正在成為這個領域的標準格式，類似 Java 的 JAR 或 JavaScript 的 npm 套件，主要 AI 程式設計工具都開始支援，使得上下文可以跨工具交換。但 registry 本身不是萬靈丹：市面上有大量個人上傳的 skills，缺乏測試與維護，使用前必須仔細檢查。Debois 建議用檢視開源專案的標準來看待這些 skills——有文件、有測試、有維護紀錄的才值得信賴。安全也是分發環節的重要議題，因為 skills 包含可執行程式碼，可能夾帶惡意指令。OpenClaw 事件讓整個產業開始重視這個風險，Snyk 這類資安廠商也推出了 context scanner。Debois 進一步提出 AI Bill of Materials 的概念，類似軟體物料清單（SBOM），記錄上下文的建立者、建立時間與來源。Git blame 搭配 GitHub annotations 可以追蹤某行程式碼是人工撰寫還是 AI 生成，這種溯源能力不僅是稽核工具，本身也是一種上下文——代理可以閱讀這段歷史，理解某個決策為什麼發生。
觀察：從日誌與反饋中持續改進
最後一個環節是觀察。Debois 舉了幾個實際案例：Hugging Face 在自己的程式碼庫中讓代理執行任務後撰寫 retrospective，反思「這次做得好不好」，再把這些反思回饋給代理作為後續參考。Devin 也在建構類似的自我反思迴圈。另一個被忽略的反饋來源是 commit 與 Slack 討論：每次提交、每段對話都是上下文是否有效的證據。Hud 這家公司的做法是在生產環境中插樁，當錯誤發生時，記錄受影響的程式碼行，然後讓代理把這些資訊整理成 lesson learned，寫回上下文。Debois 也提到沙箱與安全觀察的重要性：代理可能讀取不該讀的環境變數、透過 DNS 外洩資料，或執行未預期的操作。他展示了一個概念驗證，用 eBPF（Linux 核心的動態追蹤技術）攔截檔案讀取呼叫，檢查代理到底讀了哪些檔案，類似「上下文防火牆」。他坦言這類規則的撰寫很繁瑣，但即使只是記錄而不阻擋，也能提供寶貴的反饋訊號。OpenAI 甚至會用 Codex 的應用日誌來關聯問題並訓練模型，顯示觀察資料不僅能改善當下執行，也能回饋到未來的模型與上下文設計。
角色轉變與成熟度
Debois 認為，工程師的角色正在從「寫程式的人」轉變為「代理的管理者」。他提出一個管理風格光譜：最底層是微觀管理者，逐行盯著代理的輸出，這無法規模化；往上是寫規格、做審查；再往上是讓代理互相批評，人類只在衝突時介入；最極端的是夜間自動執行，代理只在需要決策時呼叫人類。他強調，自主性不是最終目標，重點是知道什麼時候該用哪種管理風格——高風險場景就親自坐鎮，低風險場景就放手讓代理執行。有趣的是，這套流程也改變了工程師的工作動機：過去沒人喜歡寫測試，但現在代理寫程式碼，沒有測試就無法判斷好壞，所以工程師反而主動寫測試；過去沒人喜歡寫文件，但現在寫上下文能讓代理表現更好、減少審查負擔，所以工程師樂於撰寫。Debois 稱之為「自動對齊」：工程師為了自身利益，開始實踐過去被要求但不想做的良好工程紀律。他也提到成熟度模型：從手動建立上下文、持久化保存、自適應優化，到主動觀察與回饋，最後是組織層級的上下文治理——由特定團隊擁有某個上下文物件，就像擁有微服務或函式庫一樣。他預測，未來代理會從「專門寫程式」進化成「專門管理上下文」，而下載正確上下文、評估上下文品質也將成為代理的核心能力。
影響與限制
Debois 對這套方法的定位很務實。他承認上下文會漂移（context drift）：模型更新後，舊上下文可能失效；團隊成員使用不同版本的上下文，也可能造成不一致。這些都是尚未解決的問題。他也提出幾個開放問題：上下文的混沌工程長什麼樣？能否像 A/B 測試一樣，把新上下文推給兩個團隊實驗後再全面 rollout？誰會是「上下文領域的 GitHub 或 Kubernetes」？關於企業採用，與會者問到銀行、保險等傳統產業能否直接信任這套流程。Debois 的回答是：風險取決於測試與防護措施的完備程度，而不是單純的「能不能」。他認為，如果團隊有扎實的評估、適當的 guardrails 與明確的風險容忍度，某些場景確實可以讓代理直接上生產；但如果不願意承擔風險，就不要自動化。他的總結是：程式碼代理是引擎，上下文是燃料，燃料不對，引擎再強也跑不動。在 AI 生成程式碼越來越便宜的時代，真正的競爭優勢不在於寫程式的能力，而在於提供正確的上下文——關於產品、商業與使用者需求的深度理解，這才是組織最難被複製的護城河。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。