停止修正AI程式碼：構建智慧體所需的系統

如果軟體工程師不再編寫程式碼，那他們在做什麼？這是數百萬人心中的疑問。AI工具如今已被開發者廣泛使用，但裁員恐懼依然存在。然而，編碼只是軟體工程的一部分。這為工程師提供了貼近業務和了解其角色在組織與行業中的目的的機會。Tessl的技術人員、DevOps一詞的創造者、DevOpsDays全球活動系列的創始人Patrick Debois表示：“我喜歡用類比思考。2009年，我在想，如果運維更像開發會怎樣？”他在今年夏天的倫敦PlatformCon會議上發表了上述言論。他告訴聽眾，隨著上下文——AI用於任務的特定知識——取代人類程式碼，“軟體開發生命週期變成了上下文開發生命週期。”這一生命週期已從單一的CI/CD反饋迴圈擴充套件為圍繞生成、透過測試驅動開發評估、將上下文作為包分發以及觀察的一系列同心圓。這種增長由個人開發者、團隊和整個組織思維方式的轉變所推動，併為平臺工程團隊開闢了全新的機遇。Debois告訴The New Stack：“我主張的開發人員思維轉變是：如果智慧體沒有按你的意願行事，停止修正程式碼。改進系統，而不是提示。這種轉變是從‘我將與智慧體一起做’轉向‘我將幫助智慧體做得更好’。”Debois認為這是從確定性到非確定性和機率性系統及工作流程的必要轉變。它涉及工作方式和技術本身的諸多變化，但不能僅由單個工程師或團隊層面完成。就像DevOps一樣，這種變化只能在規模上實現。

如何成為上下文驅動的組織？可能感覺我們好像按下了開關，每家公司都“AI優先”。實際上，就像之前的DevOps、微服務和雲轉型一樣，AI正在向可預見的未來持續過渡。那麼，你的工程組織如何走上正確的上下文驅動之路？在團隊層面，Debois表示，一個好的問題是：智慧體工作需要多少次接觸？不同團隊的工程師會輸入不同的上下文點，包括程式碼庫、規範、事後分析、文件、Slack訊息、架構決策記錄、程式碼示例、用例和合規指南。要使上下文以及智慧體規模化，你需要了解個人和團隊正在生產哪些智慧體及其輸出。Debois解釋說：“當你在最佳化A，我們在最佳化B時，我們要確保提供的整個上下文是針對整個團隊最佳化的。”包括：“如果你在為你的筆記型電腦最佳化系統，我們能否為團隊工作流程最佳化它？然後你只需擴充套件，比如，我們能否在平臺層面做到這一點？或者跨多個團隊？”Debois告訴The New Stack：“這不是你刻意追求的東西。也許他們可以加速它，但你會看到這樣的跡象：‘哦，我有上下文，你也有上下文。當然，它就在Slack上。如果它放在倉庫裡，我可以重複使用呢？’這遵循了技術中任何趨勢從單個愛好者擴充套件到熱情團隊、再到幾個團隊，最終構建到平臺中的模式。像所有工具驅動的變革一樣，AI既關乎人和流程，也關乎技術。但他認為，工具為行為改變開啟了可能性。他繼續說：“根本性的變化是系統，而不是提示。然後尋找協作方向，從單打獨鬥到共享事物，現在作為團隊一起構建上下文。”

上下文工程演變為配套工程。組織可能認為上下文只需一次性或每年幾次在規則變更時輸入智慧體系統，但Debois警告說，這不應是瀑布式。它是迭代的。如果上下文不是迭代的，那麼工程師就會重新陷入改寫提示或直接修復程式碼本身的壞習慣。僅依賴傳統反饋迴圈意味著你的AI智慧體艦隊無法帶來投資回報。Debois告訴PlatformCon聽眾：“行業內有一種說法：如果AI有問題，我們就使用更多AI。”他舉例說明一個大語言模型或AI代理如何生成程式碼。“我們要求LLM評估這段程式碼，它幾乎就像呼叫單元測試一樣。它沒有執行程式碼，只是檢視程式碼。”這有一定價值，可能在於強制API端點或其他二進位制質量門控，但他說這還不夠。相反，如果你在上下文中指定了需求，那麼這就會驅動智慧體如何執行和評估程式碼。但不應止步於此。他認為，AI智慧體成熟度的下一階段在於配套和迴圈。配套工程專注於構建圍繞LLM的基礎設施、護欄和工具，以支援可靠、自主的智慧體開發。Debois將智慧體的內部配套定義為查詢API背後的日誌、指標和跟蹤，“這樣編碼智慧體就能看到後果並改進”，所有這些都反饋到生成、評估、分發和觀察的活迴圈中。透過這種模式，智慧體“自動知道出了問題，無需你不斷告訴它們”，他說，因為“它擁有感測器，知道什麼失敗了，什麼改進了，然後可以回去改進這些邊界”，即使工程師在硬編碼某些東西。同樣，配套不應孤立地為單個開發者或團隊構建。Debois說：“他們正在為整個世界構建配套，所以想象一下，在如何做測試、如何進行驗證以及當前所有不同團隊的知識方面達成共識。人們開始基於相同的管道進行構建。”現實是大多陣列織最終會有多個管道，但這些迴圈成為每個組織反饋迴圈的下一步演進。因此，為AI協調而構建會帶來更好的組織協作。