你有沒(méi)有想過(guò)，編程可能會(huì)發(fā)生翻天覆地的變化？開(kāi)發(fā)者們不再只是使用 AI 工具，而是開(kāi)始將 AI 視為構(gòu)建軟件的新基礎(chǔ)。這不是小修小補(bǔ)，而是一場(chǎng)徹底的變革。想想看，我們一直習(xí)慣的那些核心概念--版本控制、模板、文檔，甚至是“用戶”的概念--都在因?yàn)锳I Agent驅(qū)動(dòng)的工作流程而被重新定義。

這讓我想起了從馬車(chē)到汽車(chē)的轉(zhuǎn)變。一開(kāi)始，人們只是把汽車(chē)看作“不用馬拉的馬車(chē)”，但很快意識(shí)到，整個(gè)交通系統(tǒng)都需要重新思考。道路、法規(guī)、城市布局，全都變了?，F(xiàn)在我們正經(jīng)歷著類似的轉(zhuǎn)變。AI Agent 既是協(xié)作者又是消費(fèi)者，這意味著我們需要重新設(shè)計(jì)一切。

你會(huì)看到基礎(chǔ)開(kāi)發(fā)工具的重大轉(zhuǎn)變，比如：提示詞（Prompt）現(xiàn)在可以像源代碼一樣被處理，儀表板能夠進(jìn)行對(duì)話，文檔不僅為人類編寫(xiě)，也為機(jī)器編寫(xiě)。模型上下文協(xié)議（MCP）和 AI 原生 IDE 指向了開(kāi)發(fā)循環(huán)本身的深層重塑--我們不僅是在以不同的方式編程，還在為一個(gè) AI Agent 充分參與軟件循環(huán)的世界設(shè)計(jì)工具。

這就像20世紀(jì)70年代個(gè)人電腦出現(xiàn)時(shí)，我們從主機(jī)終端轉(zhuǎn)向個(gè)人工作站。那時(shí)候，沒(méi)人能想象每個(gè)人都會(huì)有一臺(tái)電腦?，F(xiàn)在，我們正面臨類似的轉(zhuǎn)折點(diǎn)：每個(gè)開(kāi)發(fā)者都會(huì)有自己的 AI Agent 團(tuán)隊(duì)。

今天我們來(lái)聊聊九個(gè)非常前瞻性的開(kāi)發(fā)者趨勢(shì)，雖然還處于早期階段，但它們都是基于真實(shí)的痛點(diǎn)，向我們展示了未來(lái)可能的樣子。這些趨勢(shì)包括重新思考 AI 生成代碼的版本控制，到大語(yǔ)言模型驅(qū)動(dòng)的用戶界面和文檔。

新范式一、AI 原生 Git：為 AI Agent 重塑版本控制

這個(gè)想法一開(kāi)始可能聽(tīng)起來(lái)很瘋狂，但聽(tīng)我說(shuō)完。現(xiàn)在 AI Agent 越來(lái)越多地編寫(xiě)或修改應(yīng)用程序代碼的大部分，開(kāi)發(fā)者關(guān)心的東西開(kāi)始發(fā)生變化。我們不再糾結(jié)于一行一行一行寫(xiě)了什么代碼，而是關(guān)心輸出是否按預(yù)期運(yùn)行。改動(dòng)通過(guò)測(cè)試了嗎？應(yīng)用還像預(yù)期那樣工作嗎？

這里有個(gè)很有趣的現(xiàn)象，我稱之為“真相的上移”。以前，源代碼就是真相?，F(xiàn)在，提示詞和測(cè)試組合才是真相。想想看，如果我告訴你“用 React 寫(xiě)一個(gè)待辦事項(xiàng)應(yīng)用”，然后 AI Agent 生成了1000行代碼，你真的在乎每一行代碼具體怎么寫(xiě)的嗎？還是更在乎它是不是真的能用？

這顛覆了一個(gè)長(zhǎng)期存在的思維模式。Git 被設(shè)計(jì)用來(lái)跟蹤手寫(xiě)代碼的精確歷史，但是有了編程 AI Agent，這種粒度變得不那么有意義了。開(kāi)發(fā)者通常不會(huì)審核每一個(gè)差異--尤其是當(dāng)改動(dòng)很大或者是自動(dòng)生成的--他們只是想知道新行為是否符合預(yù)期結(jié)果。

這讓我想起了軟件工程的一個(gè)基本原則：抽象。我們總是在尋找合適的抽象層。匯編語(yǔ)言太低級(jí)，所以我們有了高級(jí)語(yǔ)言。機(jī)器碼太難懂，所以我們有了編譯器?，F(xiàn)在，一行一行的代碼可能也太低級(jí)了，我們需要新的抽象。

結(jié)果是，Git SHA--曾經(jīng)是“代碼庫(kù)狀態(tài)”的標(biāo)準(zhǔn)參考--開(kāi)始失去一些語(yǔ)義價(jià)值。SHA 只是告訴你有東西改變了，但不告訴你為什么或者是否有效。在 AI 優(yōu)先的工作流中，更有用的真相單元可能是生成代碼的提示詞和驗(yàn)證其行為的測(cè)試的組合。

在這個(gè)世界里，你的應(yīng)用的“狀態(tài)”可能更好地由生成的輸入（提示詞、規(guī)范、約束）和一套通過(guò)的斷言來(lái)表示，而不是一個(gè)凍結(jié)的提交哈希。想象一下，未來(lái)的開(kāi)發(fā)者可能會(huì)說(shuō)：“給我看看提示詞v3.1的測(cè)試覆蓋率”，而不是“給我看看 commit SHA abc123 的 diff”。

實(shí)際上，我們最終可能會(huì)將提示詞+測(cè)試包作為本身可版本化的單元來(lái)跟蹤，Git 被降級(jí)為跟蹤這些包，而不僅僅是原始源代碼。這就是我所說(shuō)的“意圖驅(qū)動(dòng)的版本控制”。我們不是在版本控制代碼，而是在版本控制意圖。

更進(jìn)一步說(shuō)，在 AI Agent 驅(qū)動(dòng)的工作流中，真相的來(lái)源可能會(huì)向上游轉(zhuǎn)移到提示詞、數(shù)據(jù)架構(gòu)、API 合約和架構(gòu)意圖。代碼成為這些輸入的副產(chǎn)品，更像編譯的工件而不是手動(dòng)編寫(xiě)的源碼。在這個(gè)世界里，Git 開(kāi)始更少地充當(dāng)工作區(qū)，更多地充當(dāng)工件日志--一個(gè)不僅跟蹤什么改變了，還跟蹤為什么改變以及由誰(shuí)改變的地方。

想想這個(gè)場(chǎng)景：你正在 Debug 一個(gè)問(wèn)題，你不是在查找“誰(shuí)在什么時(shí)候改了這行代碼”，而是在問(wèn)“哪個(gè) AI Agent 基于什么提示詞做了這個(gè)決定，人類審核者在哪里簽字確認(rèn)了？”這就是未來(lái)的代碼考古學(xué)。

新范式二、儀表板的革新：AI 驅(qū)動(dòng)的合成動(dòng)態(tài)界面

我認(rèn)為儀表板的演變是一個(gè)被嚴(yán)重低估的趨勢(shì)。多年來(lái)，儀表板一直是與復(fù)雜系統(tǒng)交互的主要界面，比如：可觀測(cè)性堆棧、分析平臺(tái)、云控制臺(tái)等。然而，它們的設(shè)計(jì)常常面臨用戶體驗(yàn)過(guò)載的問(wèn)題，界面充斥著眾多旋鈕、圖表和標(biāo)簽頁(yè)，這不僅讓用戶難以快速找到所需信息，還增加了理解信息的難度。

我的一位運(yùn)維工程師朋友向我抱怨，他花費(fèi)大量時(shí)間在不同儀表板之間切換，試圖拼湊出系統(tǒng)問(wèn)題所在，這完全是信息過(guò)載的表現(xiàn)，數(shù)據(jù)過(guò)多卻不知如何整理。對(duì)于非高級(jí)用戶或跨團(tuán)隊(duì)使用來(lái)說(shuō)，這些儀表板可能變得令人畏懼且效率低下。用戶清楚自己想要達(dá)成的目標(biāo)，但卻不知道該查看何處或應(yīng)用哪些過(guò)濾器來(lái)實(shí)現(xiàn)，這就好比在一個(gè)工具繁多卻外觀相似的巨大工具箱里尋找特定螺絲刀一樣困難。

如今，新一代的 AI 大模型為儀表板帶來(lái)了潛在的變革。我們可以在儀表板中融入搜索和交互功能，使其不再是一成不變的界面。大語(yǔ)言模型（LLM）能夠幫助用戶精準(zhǔn)找到正確的控制選項(xiàng)，比如：“哪里可以調(diào)整這個(gè) API 的限流設(shè)置？”；將滿屏數(shù)據(jù)整合為易于理解的洞察，像“總結(jié)過(guò)去24小時(shí)內(nèi)預(yù)發(fā)布環(huán)境所有服務(wù)的錯(cuò)誤趨勢(shì)”；還能挖掘出用戶尚未察覺(jué)的重要信息，比如：“基于你對(duì)我業(yè)務(wù)的了解，生成一個(gè)我這個(gè)季度應(yīng)該關(guān)注的指標(biāo)列表”。

一個(gè)很酷的概念——“上下文化的數(shù)據(jù)展示”。傳統(tǒng)儀表板是靜態(tài)的，展示固定的指標(biāo)和固定的方式。而 AI 驅(qū)動(dòng)的儀表板則可以根據(jù)用戶當(dāng)前的任務(wù)、角色，甚至過(guò)往的行為模式來(lái)自我重新配置。

我們已經(jīng)見(jiàn)證了像 Assistant UI 這樣的技術(shù)解決方案，讓 AI Agent 能夠?qū)?ReAct 組件作為工具使用。就像內(nèi)容可以變得動(dòng)態(tài)和個(gè)性化一樣，用戶界面本身也可以變得自適應(yīng)和對(duì)話式。在自然語(yǔ)言界面面前，純粹的靜態(tài)儀表板可能很快就會(huì)顯得過(guò)時(shí)，這種界面會(huì)根據(jù)用戶的意圖進(jìn)行重新配置。

比如：用戶可以說(shuō)“顯示上周末歐洲的異常情況”，儀表板就會(huì)重塑以展示該視圖，包括總結(jié)的趨勢(shì)和相關(guān)日志。更強(qiáng)大的是，用戶可以問(wèn)“為什么我們的 NPS評(píng)分上周下降了？”AI 可能會(huì)提取調(diào)查情緒，將其與產(chǎn)品部署相關(guān)聯(lián)，并生成一個(gè)簡(jiǎn)短的診斷敘述。

但這里還有一個(gè)更深層的轉(zhuǎn)變：儀表板不再只是為人類設(shè)計(jì)的，AI Agent 也需要“看”和“理解”系統(tǒng)狀態(tài)。這意味著我們可能需要雙模式界面：一個(gè)人類友好的，一個(gè) AI Agent 友好的。想象一下這個(gè)場(chǎng)景：一個(gè) AI Agent 正在監(jiān)控你的系統(tǒng)，它不需要漂亮的圖表，它需要結(jié)構(gòu)化的數(shù)據(jù)和可執(zhí)行的上下文。

這就像為不同的感官設(shè)計(jì)：人類用眼睛看，AI Agent 用 API “感知”。未來(lái)的儀表板可能需要同時(shí)服務(wù)這兩種“物種”，這是一個(gè)全新的設(shè)計(jì)挑戰(zhàn)。

新范式三、文檔的轉(zhuǎn)型：成為工具、索引和交互式知識(shí)庫(kù)的融合體

這個(gè)轉(zhuǎn)變讓我感到非常興奮。開(kāi)發(fā)者在文檔方面的行為正在發(fā)生變化。過(guò)去，用戶會(huì)閱讀目錄或從上往下掃描文檔，而現(xiàn)在，用戶則是從一個(gè)問(wèn)題開(kāi)始。心理模式從“讓我研究這個(gè)規(guī)范”轉(zhuǎn)變?yōu)椤鞍凑瘴蚁矚g的方式重新整理這些信息”。

我記得剛開(kāi)始編程時(shí)，我會(huì)花費(fèi)幾個(gè)小時(shí)從頭到尾閱讀 API 文檔。而現(xiàn)在，我打開(kāi)文檔后會(huì)直接搜索我想要的內(nèi)容，或者詢問(wèn) AI “怎么用這個(gè)庫(kù)做 X”。這并非懶惰，而是效率的進(jìn)化。

這種從被動(dòng)閱讀到主動(dòng)查詢的微妙轉(zhuǎn)變，正在改變文檔應(yīng)有的形態(tài)。它們不再僅僅是靜態(tài)的 HTML 或 Markdown 頁(yè)面，而是正在演變?yōu)榻换ナ街R(shí)系統(tǒng)，由索引、嵌入和工具感知的 AI Agent 支撐。

因此，像 Mintlify 這樣的產(chǎn)品應(yīng)運(yùn)而生，它們不僅將文檔結(jié)構(gòu)化為語(yǔ)義可搜索的數(shù)據(jù)庫(kù)，還充當(dāng)跨平臺(tái)編程 AI Agent 的上下文源。Mintlify 頁(yè)面現(xiàn)在經(jīng)常被 AI 編程 Agent 引用，無(wú)論是在AI IDE、VS Code 擴(kuò)展，還是終端 AI Agent 中，因?yàn)榫幊?Agent 使用最新的文檔作為生成的基礎(chǔ)上下文。

這改變了文檔的目的：它們不再只是為人類讀者服務(wù)，也為 AI Agent 消費(fèi)者服務(wù)。在這種新的動(dòng)態(tài)中，文檔界面變成了一種 AI Agent 的指令。它不僅暴露原始內(nèi)容，還解釋如何正確使用一個(gè)系統(tǒng)。

這里有一個(gè)很有趣的趨勢(shì)，稱之為“文檔的雙重性格”。人類讀者需要上下文、例子和解釋，而 AI Agent 需要結(jié)構(gòu)化數(shù)據(jù)、明確的規(guī)則和可執(zhí)行的指令。好的文檔需要同時(shí)滿足這兩種需求。

未來(lái)的文檔可能會(huì)有三個(gè)層次：人類閱讀層（有故事性和解釋）、AI 消費(fèi)層（結(jié)構(gòu)化和精確）、交互層（允許詢問(wèn)和探索）。這就像為不同的學(xué)習(xí)風(fēng)格設(shè)計(jì)教材，但這次是為不同的“思維方式”設(shè)計(jì)。

新范式四、從模板到生成：vibe coding 取代 create-react-app

這個(gè)趨勢(shì)讓我想起了從工業(yè)革命到數(shù)字革命的轉(zhuǎn)變。過(guò)去，開(kāi)始一個(gè)項(xiàng)目意味著選擇一個(gè)靜態(tài)模板，比如：樣板 GitHub 倉(cāng)庫(kù)或者像 create-react-app、next init 或 rails new 這樣的 CLI。這些模板作為新應(yīng)用的腳手架，提供一致性但缺少定制性。

開(kāi)發(fā)者要么順應(yīng)框架提供的任何默認(rèn)值，要么冒著大量手動(dòng)重構(gòu)的風(fēng)險(xiǎn)。這就好比工業(yè)時(shí)代的標(biāo)準(zhǔn)化生產(chǎn)：你可以擁有任何顏色的汽車(chē)，只要它是黑色的。

現(xiàn)在，隨著像 Replit、Same.dev、Loveable、Convex 的 Chef 和 Bolt 這樣的文本到應(yīng)用平臺(tái)的出現(xiàn)，以及像 Cursor 這樣的 AI IDE，這種動(dòng)態(tài)正在發(fā)生變化。開(kāi)發(fā)者可以描述他們想要什么，比如“一個(gè)帶有 Supabase、Clerk 和 Stripe 的 TypeScript API 服務(wù)器”，并在幾秒鐘內(nèi)得到一個(gè)定制的項(xiàng)目腳手架。

結(jié)果是一個(gè)不是通用的，而是個(gè)性化和有目的的啟動(dòng)器，反映了開(kāi)發(fā)者的意圖和他們選擇的技術(shù)棧。這就好比從工業(yè)化生產(chǎn)轉(zhuǎn)向大規(guī)模定制化。每個(gè)項(xiàng)目都可以有獨(dú)特的起始點(diǎn)，而不是從相同的模板開(kāi)始。

這在生態(tài)系統(tǒng)中解鎖了一個(gè)新的分發(fā)模式。與其讓少數(shù)框架坐擁長(zhǎng)尾，我們可能會(huì)看到可組合的、特定于堆棧的生成更廣泛的分布，工具和架構(gòu)被動(dòng)態(tài)地混合和匹配。這更多的是描述一個(gè)結(jié)果，AI 可以圍繞它構(gòu)建一個(gè)堆棧，而不是選擇一個(gè)框架。

但這里有一個(gè)有趣的副作用，稱之為“框架民主化”。以前，選擇框架是一個(gè)重大決定，因?yàn)榍袚Q成本很高?，F(xiàn)在，框架選擇變得更像選擇今天穿什么衣服：可以隨時(shí)改變。

當(dāng)然，這也帶來(lái)了新的挑戰(zhàn)。標(biāo)準(zhǔn)化有它的優(yōu)勢(shì)--團(tuán)隊(duì)協(xié)作更容易，故障排除更簡(jiǎn)單，知識(shí)傳播更快。但隨著 AI Agent 能夠理解項(xiàng)目意圖并執(zhí)行大規(guī)模重構(gòu)，實(shí)驗(yàn)的成本顯著降低。

這意味著我們可能會(huì)看到一個(gè)更加流動(dòng)的技術(shù)棧生態(tài)系統(tǒng)，其中選擇不再是永久性的決定，而是演化的起點(diǎn)。

新范式五、超越.env：在 AI Agent 驅(qū)動(dòng)的世界中管理秘密

在當(dāng)今的開(kāi)發(fā)實(shí)踐中，有一個(gè)被廣泛忽視卻極為關(guān)鍵的問(wèn)題，那就是秘密管理。多年來(lái)，.env 文件一直是開(kāi)發(fā)者在本地管理秘密（比如：API 密鑰、數(shù)據(jù)庫(kù) URL 和服務(wù)令牌）的首選方式。這種方式簡(jiǎn)單、便攜，且對(duì)開(kāi)發(fā)者友好。然而，隨著 AI Agent 時(shí)代的到來(lái)，這種傳統(tǒng)的秘密管理方式正面臨著前所未有的挑戰(zhàn)。

設(shè)想一下這樣的場(chǎng)景：你正在使用一個(gè) AI Agent 來(lái)協(xié)助編寫(xiě)代碼，而這個(gè) AI Agent 需要連接到你的數(shù)據(jù)庫(kù)。在這種情況下，你真的愿意將數(shù)據(jù)庫(kù)密碼直接交給 AI Agent 嗎？如果發(fā)生數(shù)據(jù)泄露，責(zé)任該由誰(shuí)來(lái)承擔(dān)？是 AI Agent、你自己，還是 AI Agent 的提供商？

當(dāng) AI IDE 或 AI Agent 開(kāi)始代表我們編寫(xiě)代碼、部署服務(wù)以及協(xié)調(diào)環(huán)境時(shí)，.env 文件的所有權(quán)歸屬變得模糊不清。更重要的是，傳統(tǒng)的“環(huán)境變量”概念可能已經(jīng)不再適用。我們迫切需要一種新的秘密管理系統(tǒng)，它能夠提供精確的權(quán)限控制、可審計(jì)性以及可撤銷(xiāo)性。

我們已經(jīng)看到了一些可能的發(fā)展方向。比如：最新的 MCP 規(guī)范引入了一個(gè)基于 OAuth 2.1 的授權(quán)框架，這表明未來(lái)可能會(huì)向 AI Agent 提供有范圍限制且可撤銷(xiāo)的令牌，而不是直接提供原始秘密。我們可以設(shè)想這樣一個(gè)場(chǎng)景：AI Agent 不會(huì)獲得你的實(shí)際 AWS 密鑰，而是得到一個(gè)短期憑證或能力令牌，僅允許其執(zhí)行明確定義的操作。

另一種可能的發(fā)展方向是本地秘密代理的興起。這些代理服務(wù)可以在你的機(jī)器上或與你的應(yīng)用一起運(yùn)行，作為 AI Agent 和敏感憑證之間的中介。代理可以實(shí)時(shí)請(qǐng)求訪問(wèn)特定的能力（比如：“部署到預(yù)發(fā)布環(huán)境”或“將日志發(fā)送到 Sentry”），并根據(jù)預(yù)設(shè)規(guī)則決定是否授予訪問(wèn)權(quán)限，同時(shí)確保所有操作都是可審計(jì)的。

我將這種趨勢(shì)稱為“能力導(dǎo)向的安全”。與其給 AI Agent 提供“鑰匙”（即秘密），不如賦予它們“許可”（即能力）。這就好比從“信任但驗(yàn)證”的模式轉(zhuǎn)向“零信任但啟用”的模式。

未來(lái)的秘密管理將更像一個(gè)權(quán)限系統(tǒng)，每個(gè)操作都有明確的范圍，每個(gè) AI Agent 都有明確的角色，所有訪問(wèn)行為都將被記錄和審計(jì)。這種新的管理方式不僅更加安全，也更符合 AI Agent 的工作模式：它們不需要知道一切，只需要知道完成任務(wù)所必需的信息。

新范式六、無(wú)障礙作為通用界面：通過(guò) LLM 的眼睛看應(yīng)用

這一現(xiàn)象讓我聯(lián)想到“意外創(chuàng)新”的概念。目前，我們正目睹一類新型應(yīng)用的興起，比如：Granola 和 Highlight，它們請(qǐng)求訪問(wèn) macOS 的無(wú)障礙設(shè)置。不過(guò)，它們的意圖并非傳統(tǒng)的無(wú)障礙用途，而是為了讓 AI Agent 能夠觀察并交互界面。這并非權(quán)宜之計(jì)，而是預(yù)示著更深層次變革的征兆。

無(wú)障礙 API 最初是為了協(xié)助視覺(jué)或行動(dòng)障礙用戶在數(shù)字系統(tǒng)中導(dǎo)航而開(kāi)發(fā)的。如今，這些 API 卻成了 AI Agent 理解并掌控?cái)?shù)字環(huán)境的通用語(yǔ)言，就如同盲文意外地成為機(jī)器人解讀世界的方式一般。

無(wú)障礙 API 已然攻克了“如何讓機(jī)器理解人類界面”這一難題。它們提供了語(yǔ)義化的元素描述，諸如“這是一個(gè)按鈕”“這是一個(gè)輸入框”“這是一個(gè)鏈接”，而這正是 AI Agent 所渴求的完美數(shù)據(jù)結(jié)構(gòu)。

這里有一個(gè)深刻的洞見(jiàn)：我們一直在探尋 AI Agent 與人類世界交互的方法，而答案或許就擺在眼前。無(wú)障礙技術(shù)已經(jīng)標(biāo)準(zhǔn)化，被所有主流操作系統(tǒng)所接納，并且歷經(jīng)了十幾年的實(shí)戰(zhàn)檢驗(yàn)。

若經(jīng)過(guò)深思熟慮的拓展，這有望成為 AI Agent 的通用界面層。AI Agent 可以像輔助技術(shù)一樣，語(yǔ)義化地觀察應(yīng)用程序，而非單純點(diǎn)擊像素位置或抓取 DOM。無(wú)障礙樹(shù)已然暴露了諸如按鈕、標(biāo)題和輸入框等結(jié)構(gòu)化元素。若再輔以元數(shù)據(jù)（比如：意圖、角色和功能）進(jìn)行拓展，這或許能成為 AI Agent 的首類接口，使其能夠有目的、精準(zhǔn)地感知并操作應(yīng)用。

實(shí)際上，這一方向有幾條潛在的發(fā)展路徑：

首先是上下文提取，我們需要一種標(biāo)準(zhǔn)化的方法，讓運(yùn)用無(wú)障礙或語(yǔ)義 API 的 LLM Agent 能夠查詢屏幕上呈現(xiàn)的內(nèi)容、可交互的對(duì)象以及用戶正在進(jìn)行的操作。試想一下，AI Agent 能夠說(shuō)出“告訴我這個(gè)屏幕上所有可點(diǎn)擊的元素”或“用戶現(xiàn)在處于什么位置”，并即時(shí)獲得結(jié)構(gòu)化的答復(fù)。

其次是意圖式執(zhí)行，與其要求 AI Agent 手動(dòng)串聯(lián)多個(gè) API 調(diào)用，不如暴露一個(gè)高層端點(diǎn)，讓其聲明目標(biāo)，比如：“將物品添加到購(gòu)物車(chē)，并選擇最快配送”，隨后由后端計(jì)算出具體步驟。這就好比告訴司機(jī)“帶我去機(jī)場(chǎng)”，而非逐一給出轉(zhuǎn)彎指令。

再者是 LLM 的備用 UI，無(wú)障礙功能為 LLM 提供了一個(gè)備用用戶界面。任何展示屏幕的應(yīng)用都對(duì) AI Agent 開(kāi)放，即便它未公開(kāi) API。對(duì)開(kāi)發(fā)者而言，這暗示了一個(gè)新的“渲染層”的出現(xiàn)--這不僅關(guān)乎視覺(jué)或 DOM 層面，更是 AI Agent 可訪問(wèn)的上下文，或許可通過(guò)結(jié)構(gòu)化注釋或無(wú)障礙優(yōu)先的組件來(lái)定義。

這三個(gè)方向共同指向一個(gè)未來(lái)：應(yīng)用程序不再僅僅為人眼設(shè)計(jì)，也將為 AI 的“眼睛”設(shè)計(jì)。每個(gè)界面元素都將攜帶豐富的語(yǔ)義信息，不僅描述其外觀，還涵蓋其功能以及使用方式。

這引出了一個(gè)有趣的想法：倘若我們將無(wú)障礙設(shè)計(jì)視作“機(jī)器可讀性”的標(biāo)準(zhǔn)，那會(huì)怎樣？每一個(gè)新的 UI 元素、每一種新的交互模式，從一開(kāi)始就考慮機(jī)器的理解能力。這不僅利于殘障人士，也將惠及 AI Agent。

展望未來(lái)，我們可能會(huì)見(jiàn)證一種“雙重設(shè)計(jì)”的趨勢(shì)：既為人類設(shè)計(jì)，也為 AI Agent 設(shè)計(jì)。而無(wú)障礙原則有望成為連接這兩者的橋梁，這就好比為多文化世界設(shè)計(jì)語(yǔ)言，既要考慮母語(yǔ)者，也要顧及學(xué)習(xí)者和翻譯者。

新范式七、異步 AI Agent 工作的興起

這一趨勢(shì)揭示了工作模式的深刻變革。隨著開(kāi)發(fā)者與編程 AI Agent 的協(xié)作日益順暢，我們正逐步邁向異步工作流，AI Agent 在后臺(tái)默默運(yùn)行，開(kāi)辟并行任務(wù)線程，并在取得關(guān)鍵進(jìn)展時(shí)及時(shí)反饋。

這讓我想起了從同步編程邁向異步編程的歷史性轉(zhuǎn)變。曾經(jīng)，程序都是同步執(zhí)行的：完成一項(xiàng)任務(wù)后，才能著手下一項(xiàng)。然而，我們逐漸意識(shí)到，等待是低效的，而并發(fā)執(zhí)行才是提升效率的關(guān)鍵。如今，這種轉(zhuǎn)變正在人機(jī)協(xié)作領(lǐng)域上演。

這種交互模式不再像傳統(tǒng)的結(jié)對(duì)編程，更像是精心編排的任務(wù)調(diào)度：你只需向 AI Agent 下達(dá)目標(biāo)指令，讓它自主運(yùn)行，稍后再進(jìn)行檢查。這就好比你擁有一位極為能干的實(shí)習(xí)生，你可以將一個(gè)項(xiàng)目交給他，讓他全權(quán)負(fù)責(zé)，而你則可以將精力集中在其他重要事務(wù)上。

關(guān)鍵在于，這不僅僅是將任務(wù)外包那么簡(jiǎn)單，它還極大地簡(jiǎn)化了協(xié)調(diào)工作。以往，開(kāi)發(fā)者需要與其他團(tuán)隊(duì)頻繁溝通，以更新配置文件、分類錯(cuò)誤或重構(gòu)組件。如今，開(kāi)發(fā)者可以將這些任務(wù)直接分配給 AI Agent，它會(huì)根據(jù)開(kāi)發(fā)者的意圖在后臺(tái)高效執(zhí)行。

這種變化背后有著更深遠(yuǎn)的意義：我們正從同步協(xié)作邁向異步交響。傳統(tǒng)的軟件開(kāi)發(fā)模式就像一場(chǎng)面對(duì)面的會(huì)議，所有參與者必須同時(shí)在場(chǎng)，實(shí)時(shí)交流。而新的模式則更像一場(chǎng)分布式的交響樂(lè)演奏：每個(gè)演奏者（AI Agent）依據(jù)樂(lè)譜（規(guī)范）獨(dú)立演奏，而指揮（開(kāi)發(fā)者）則負(fù)責(zé)整體的協(xié)調(diào)工作。

AI Agent 的交互界面也在不斷拓展。除了傳統(tǒng)的 IDE 或 CLI 提示，開(kāi)發(fā)者如今可以通過(guò)多種方式與 AI Agent 互動(dòng)，比如：

• 在 Slack 上發(fā)送消息
• 在 Figma 的原型圖上進(jìn)行評(píng)論
• 在代碼差異或 PR 上添加內(nèi)聯(lián)注釋
• 基于已部署應(yīng)用的預(yù)覽版本提供反饋
• 利用語(yǔ)音或通話界面，直接口頭描述變更需求

在這種模式下，AI Agent 貫穿開(kāi)發(fā)的整個(gè)生命周期。它們不僅負(fù)責(zé)編寫(xiě)代碼，還能解釋設(shè)計(jì)思路、響應(yīng)反饋，并在不同平臺(tái)間對(duì)錯(cuò)誤進(jìn)行分類處理。開(kāi)發(fā)者則轉(zhuǎn)變?yōu)閰f(xié)調(diào)者，負(fù)責(zé)決定哪些線程值得深入探索、哪些需要放棄，以及哪些可以合并。

也許最引人注目的變化是，這種異步模式可能會(huì)徹底改變我們對(duì)“分支”的理解。在傳統(tǒng)的 Git 分支中，分支代表著代碼的分叉。而在未來(lái)，分支可能代表著意圖的分叉，每個(gè)分支都由不同的 AI Agent 以獨(dú)特的方式進(jìn)行探索。開(kāi)發(fā)者不再需要親自合并代碼，而是通過(guò)評(píng)估和選擇不同的解決方案路徑來(lái)推進(jìn)項(xiàng)目。

新范式八、MCP 距離成為通用標(biāo)準(zhǔn)更近了一步

MCP（模型上下文協(xié)議）無(wú)疑是近期最令人矚目的協(xié)議創(chuàng)新成果之一。就在不久之前，我們還發(fā)布了一份深入剖析 MCP 的詳盡報(bào)告。自那以后，MCP 的發(fā)展勢(shì)頭一路高歌猛進(jìn)：OpenAI 高調(diào)宣布正式采用 MCP，該規(guī)范接連整合了多項(xiàng)全新功能，眾多工具開(kāi)發(fā)商也紛紛向其靠攏，將其奉為 AI Agent 與現(xiàn)實(shí)世界交互的默認(rèn)接口。

這一發(fā)展態(tài)勢(shì)不禁讓我聯(lián)想起90年代 HTTP 協(xié)議所扮演的關(guān)鍵角色。彼時(shí)，HTTP 并非首個(gè)網(wǎng)絡(luò)協(xié)議，也絕非最為復(fù)雜的存在，但憑借其簡(jiǎn)潔性、足夠出色的性能以及廣泛的適用性，它迅速贏得了大眾的青睞。如今，MCP 似乎正沿著相似的軌跡穩(wěn)步前行。

深入探究其核心價(jià)值，MCP 一舉攻克了兩大關(guān)鍵難題：一方面，它為大語(yǔ)言模型（LLM）精準(zhǔn)提供了完成那些可能前所未見(jiàn)任務(wù)所需的恰當(dāng)上下文集合；另一方面，它以一種清晰、模塊化的架構(gòu)取代了以往繁雜的 N×M 定制化集成模式。在新的架構(gòu)下，各類工具只需暴露標(biāo)準(zhǔn)化接口（扮演服務(wù)器角色），便可供任意 AI Agent（作為客戶端）靈活調(diào)用。

這其中蘊(yùn)含著一個(gè)極具前瞻性的洞察：我們正親眼目睹“能力標(biāo)準(zhǔn)化”這一全新概念的誕生。恰似 USB 接口成功標(biāo)準(zhǔn)化了設(shè)備之間的連接方式，MCP 如今正在 AI Agent 能力領(lǐng)域掀起一場(chǎng)標(biāo)準(zhǔn)化的浪潮。任何工具都能毫無(wú)障礙地展示自身功能，任何 AI Agent 都能輕松使用這些功能，無(wú)需再為定制化集成耗費(fèi)大量精力。

展望未來(lái)，隨著遠(yuǎn)程 MCP 服務(wù)以及事實(shí)上的注冊(cè)表相繼上線，我們有充分的理由相信，MCP 將迎來(lái)更為廣泛、深入的普及應(yīng)用。假以時(shí)日，應(yīng)用程序或許會(huì)默認(rèn)配備 MCP 界面。不妨回想一下，API 是如何讓 SaaS 產(chǎn)品之間實(shí)現(xiàn)相互嵌套、跨工具組合工作流的。MCP 同樣能夠發(fā)揮類似作用，將一個(gè)個(gè)獨(dú)立的工具轉(zhuǎn)變?yōu)榭苫ゲ僮鞯臉?gòu)建模塊，為 AI Agent 量身打造高效協(xié)作生態(tài)。

這一趨勢(shì)自然而然地引出了一個(gè)極具創(chuàng)意的概念--“能力市場(chǎng)”的崛起。試想一下，在不遠(yuǎn)的將來(lái)，一個(gè)規(guī)模龐大、功能豐富的能力注冊(cè)表橫空出世，AI Agent 可以像如今的開(kāi)發(fā)者使用 npm 或 PyPI 一樣，輕松地在其中發(fā)現(xiàn)并調(diào)用各種新能力。無(wú)論是發(fā)送郵件、處理圖像，還是實(shí)現(xiàn)特定的業(yè)務(wù)邏輯，都能在 MCP 服務(wù)器的龐大陣營(yíng)中找到相應(yīng)的解決方案。

這絕非僅僅是一項(xiàng)技術(shù)標(biāo)準(zhǔn)的演進(jìn)，它更是一種全新商業(yè)模式的誕生——能力即服務(wù)（Capabilities as a Service）。任何有能力的個(gè)體或團(tuán)隊(duì)都可以創(chuàng)建一個(gè) MCP 服務(wù)器，將自身獨(dú)特的功能能力公之于眾，供所有 AI Agent 自由使用。這就好比云計(jì)算領(lǐng)域邁向了新的發(fā)展階段：不僅計(jì)算資源實(shí)現(xiàn)了商品化，就連各種能力本身也步入了商品化的新時(shí)代。

新范式九、抽象原語(yǔ)：每個(gè) AI Agent 都需要認(rèn)證、計(jì)費(fèi)和持久存儲(chǔ)

這一趨勢(shì)揭示了一個(gè)基礎(chǔ)性的進(jìn)化規(guī)律：隨著抽象層次的不斷提升，AI Agent 正逐漸成為開(kāi)發(fā)流程中的核心力量。如今，AI Agent 已經(jīng)能夠生成大量代碼，但它們?nèi)孕枰恍﹫?jiān)實(shí)的基礎(chǔ)服務(wù)來(lái)構(gòu)建可靠的應(yīng)用程序。

就像人類開(kāi)發(fā)者依賴 Stripe 進(jìn)行支付、Clerk 進(jìn)行認(rèn)證或 Supabase 進(jìn)行數(shù)據(jù)庫(kù)管理一樣，AI Agent 也需要同樣清晰、可組合的服務(wù)原語(yǔ)。一個(gè)有趣的觀察是：AI Agent 并不是要取代現(xiàn)有的基礎(chǔ)設(shè)施，而是要更好地利用它們。

這些服務(wù)--具有清晰邊界、符合人體工程學(xué)的 SDK 和合理默認(rèn)值的 API--越來(lái)越多地成為 AI Agent 的運(yùn)行時(shí)接口。例如，當(dāng)你告訴 AI Agent“創(chuàng)建一個(gè)帶有用戶認(rèn)證和訂閱管理的 SaaS 應(yīng)用”時(shí)，它需要一個(gè)認(rèn)證系統(tǒng)（如 Clerk）、一個(gè)支付系統(tǒng)（如 Stripe）、一個(gè)數(shù)據(jù)庫(kù)（如 Supabase），以及可能的郵件服務(wù)和文件存儲(chǔ)等。

這引出了一個(gè)深刻的洞察：AI Agent 正在重塑“框架”的概念。傳統(tǒng)框架提供一個(gè)結(jié)構(gòu)，讓開(kāi)發(fā)者在其中填充邏輯；而 AI Agent 框架則提供一套原語(yǔ)，AI Agent 可以根據(jù)需要組合成任何結(jié)構(gòu)。

隨著這種模式的成熟，我們可能會(huì)看到服務(wù)不僅暴露 API，還會(huì)提供架構(gòu)、能力元數(shù)據(jù)和示例流程，以幫助 AI Agent 更可靠地集成它們。這就好比從“自底向上”的開(kāi)發(fā)模式轉(zhuǎn)變?yōu)椤白皂斚蛳隆钡脑O(shè)計(jì)方式。過(guò)去，開(kāi)發(fā)者從基礎(chǔ)設(shè)施開(kāi)始，逐層向上構(gòu)建；現(xiàn)在，開(kāi)發(fā)者從意圖出發(fā)，讓 AI Agent 找到合適的構(gòu)建塊，這是一種正向設(shè)計(jì)。

一些服務(wù)甚至可能開(kāi)始默認(rèn)附帶 MCP 服務(wù)器，將每個(gè)核心原語(yǔ)轉(zhuǎn)化為 AI Agent 可以安全、開(kāi)箱即用地推理和使用的東西。例如，Clerk 可以暴露一個(gè) MCP 服務(wù)器，讓 AI Agent 能夠查詢可用產(chǎn)品、創(chuàng)建新的計(jì)費(fèi)計(jì)劃或更新客戶訂閱，所有這些操作都預(yù)先定義了權(quán)限范圍和約束。

AI Agent 不再需要手動(dòng)編寫(xiě) API 調(diào)用或在文檔中搜索，它可以直接聲明需求，如“為產(chǎn)品X創(chuàng)建一個(gè)月費(fèi)49美元的專業(yè)版計(jì)劃，支持基于使用量的超額收費(fèi)”。Clerk 的 MCP 服務(wù)器會(huì)暴露這個(gè)能力，驗(yàn)證參數(shù)，并安全地處理編排。

這帶來(lái)了一個(gè)有趣的現(xiàn)象，我稱之為“聲明式基礎(chǔ)設(shè)施”。AI Agent 不需要知道如何實(shí)現(xiàn)用戶認(rèn)證，它只需要聲明“這個(gè)應(yīng)用需要用戶認(rèn)證”，然后讓合適的原生服務(wù)處理具體實(shí)現(xiàn)。

更深層次的影響是，這可能會(huì)導(dǎo)致“即時(shí)最佳實(shí)踐”的出現(xiàn)。這些服務(wù)不僅提供功能，還編碼了最佳實(shí)踐。當(dāng) AI Agent 使用 Stripe 集成時(shí)，它自動(dòng)獲得了處理訂閱、管理失敗付款、處理退款等的最佳實(shí)踐。

這就好比建筑行業(yè)的標(biāo)準(zhǔn)化組件。你不需要每次都從零開(kāi)始設(shè)計(jì)電氣系統(tǒng)，而是使用標(biāo)準(zhǔn)的開(kāi)關(guān)、插座和配線方法。AI Agent 也不需要每次都從零開(kāi)始實(shí)現(xiàn)認(rèn)證，而是使用經(jīng)過(guò)驗(yàn)證的、標(biāo)準(zhǔn)化的服務(wù)。

最有趣的是，這可能會(huì)創(chuàng)造一個(gè)“能力生態(tài)系統(tǒng)”。隨著越來(lái)越多的服務(wù)變得對(duì) AI Agent 友好，我們可能會(huì)看到一個(gè)新的市場(chǎng)出現(xiàn)：專門(mén)為 AI Agent 設(shè)計(jì)的原語(yǔ)服務(wù)。這些服務(wù)的 SDK 不再針對(duì)人類開(kāi)發(fā)者，而是針對(duì) AI Agent，用簡(jiǎn)單的接口和明確的約束來(lái)暴露強(qiáng)大的能力。

結(jié)語(yǔ)：軟件開(kāi)發(fā)的下一章

這九大趨勢(shì)背后，是一場(chǎng)更為宏大的變革。隨著基礎(chǔ)模型的不斷進(jìn)化，開(kāi)發(fā)者的日常行為也在悄然改變。新的工具鏈和協(xié)議，比如：MCP，應(yīng)運(yùn)而生。這并非簡(jiǎn)單地將 AI 嵌入舊有流程，而是一次從核心出發(fā)，圍繞 AI Agent、上下文與意圖重構(gòu)軟件開(kāi)發(fā)的深刻變革。

需要著重指出的是，這些趨勢(shì)并非孤立存在，它們相互作用、相互強(qiáng)化，共同塑造了一個(gè)全新的開(kāi)發(fā)者生態(tài)系統(tǒng)。AI 原生的版本控制系統(tǒng)，依賴于標(biāo)準(zhǔn)化的能力接口；合成式界面，得益于語(yǔ)義化的無(wú)障礙 API；而異步協(xié)作模式，則呼喚強(qiáng)大的秘密管理系統(tǒng)。

這讓我想起了技術(shù)革命的三部曲：最初，新技術(shù)模仿舊模式；隨后，我們開(kāi)始探索新技術(shù)的獨(dú)特潛力；最終，我們重塑整個(gè)系統(tǒng)，以充分發(fā)揮新技術(shù)的威力。如今，我們正從第二階段邁向第三階段。

在開(kāi)發(fā)者工具層面，一場(chǎng)根本性的變革正在發(fā)生。這不僅僅是技術(shù)的升級(jí)，更是思維方式的徹底轉(zhuǎn)變。我們正從“編程”轉(zhuǎn)向“意圖表達(dá)”，從“版本控制”轉(zhuǎn)向“意圖追蹤”，從“文檔”轉(zhuǎn)向“知識(shí)神經(jīng)網(wǎng)絡(luò)”。

也許最為關(guān)鍵的是，這些趨勢(shì)預(yù)示著軟件開(kāi)發(fā)角色的深刻變化。未來(lái)的開(kāi)發(fā)者，可能不再像如今這般獨(dú)自?shī)^戰(zhàn)，更像是交響樂(lè)指揮，負(fù)責(zé)協(xié)調(diào)不同 AI Agent 的工作。

這一轉(zhuǎn)變既令人興奮，又略帶不安。我們正踏入一片未知領(lǐng)域，新的規(guī)則還在不斷形成。但歷史經(jīng)驗(yàn)告訴我們，每一次技術(shù)革命都創(chuàng)造了比它摧毀的更多機(jī)會(huì)。關(guān)鍵在于保持開(kāi)放心態(tài)，適應(yīng)變化，同時(shí)堅(jiān)守那些讓我們成為優(yōu)秀開(kāi)發(fā)者的核心價(jià)值：解決問(wèn)題、創(chuàng)造價(jià)值、服務(wù)用戶。

我們滿懷熱情地投身于下一代工具的構(gòu)建與投資。這不僅是為了更高效地編程，更是為了攻克那些曾經(jīng)無(wú)解的難題，創(chuàng)造那些曾經(jīng)難以想象的可能性。這，才是技術(shù)進(jìn)步的真正意義：不是更快，而是更多、更好。

本文轉(zhuǎn)載自??玄姐聊AGI?  作者：玄姐