国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

AI 正在重塑軟件開發(fā)，從工具到基礎(chǔ)，從代碼到流程，這場變革如同從馬車到汽車的轉(zhuǎn)型，正顛覆傳統(tǒng)的版本控制、文檔等核心概念，開啟開發(fā)者與 AI agent 協(xié)作的新紀元。

你有沒有想過，編程這件事情可能徹底變了？開發(fā)者正在從單純使用AI工具，轉(zhuǎn)向?qū)I視為構(gòu)建軟件的全新基礎(chǔ)。這不是什么小調(diào)整，而是一場徹底的范式轉(zhuǎn)變。想想看，那些我們一直習(xí)以為常的核心概念——版本控制、模板、文檔，甚至”用戶”的概念——都在因為AI agent驅(qū)動的工作流而被重新定義。

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

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

這就像20世紀70年代個人電腦出現(xiàn)時，我們從主機終端轉(zhuǎn)向個人工作站。那時候，沒人能想象每個人都會有一臺電腦。現(xiàn)在，我們正面臨類似的轉(zhuǎn)折點：每個開發(fā)者都會有自己的AI agent團隊。

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

AI原生Git：為AI agent重塑版本控制

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

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

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

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

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

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

實際上，我們最終可能會將prompt+測試包作為本身可版本化的單元來跟蹤，Git被降級為跟蹤這些包，而不僅僅是原始源代碼。這就是我所說的”意圖驅(qū)動的版本控制”。我們不是在版本控制代碼，而是在版本控制意圖。

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

想想這個場景：你正在debug一個問題，你不是在查找”誰在什么時候改了這行代碼”，而是在問”哪個AI agent基于什么prompt做了這個決定，人類審核者在哪里簽字確認了？”這就是未來的代碼考古學(xué)。

儀表板演變：合成式的AI驅(qū)動動態(tài)界面

這是一個我覺得被嚴重低估的趨勢。多年來，儀表板一直是與復(fù)雜系統(tǒng)交互的主要界面，比如可觀測性堆棧、分析平臺、云控制臺（想想AWS）等等。但它們的設(shè)計常常遭受UX過載的困擾：太多的旋鈕、圖表和標簽頁，迫使用戶既要尋找信息，又要搞清楚如何處理它。

我有個朋友是運維工程師，他告訴我他花了一半時間在各種儀表板之間切換，試圖拼湊出系統(tǒng)到底出了什么問題。這完全是信息過載的問題，不是缺乏數(shù)據(jù)，而是數(shù)據(jù)太多了，不知道怎么整理。

尤其對于非高級用戶或者跨團隊使用，這些儀表板可能變得令人生畏或者效率低下。用戶知道他們想達成什么，但不知道該看哪里或者應(yīng)用哪些過濾器才能到達目的地。這就像在一個巨大的工具箱里找一個特定的螺絲刀，但所有工具都長得差不多。

最新一代的AI模型提供了一個潛在的轉(zhuǎn)變。我們可以在儀表板上添加搜索和交互功能，而不是把它們當作僵硬的畫布?，F(xiàn)在LLM可以幫助用戶找到正確的控制（”哪里可以調(diào)整這個API的限流設(shè)置？”）；將整屏數(shù)據(jù)合成為易于理解的洞察（”總結(jié)過去24小時內(nèi)預(yù)發(fā)布環(huán)境所有服務(wù)的錯誤趨勢”）；并浮現(xiàn)未知的未知(“基于你對我業(yè)務(wù)的了解，生成一個我這個季度應(yīng)該關(guān)注的指標列表”)。

這里有個很酷的概念，我稱之為”上下文化的數(shù)據(jù)展示”。傳統(tǒng)儀表板是靜態(tài)的：它們展示固定的指標，用固定的方式。但AI驅(qū)動的儀表板可以根據(jù)你當前的任務(wù)、你的角色、甚至你過去的行為模式來重新配置自己。

我們已經(jīng)看到像Assistant UI這樣的技術(shù)解決方案，使AI agent能夠?qū)eact組件用作工具。就像內(nèi)容變得動態(tài)和個性化一樣，UI本身也可以變得自適應(yīng)和對話式。在一個基于自然語言的界面面前，純粹的靜態(tài)儀表板可能很快顯得過時，這種界面會根據(jù)用戶意圖重新配置。

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

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

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

文檔正在成為工具、索引和交互式知識庫的混合體

這個轉(zhuǎn)變讓我興奮不已。開發(fā)者在文檔方面的行為正在發(fā)生轉(zhuǎn)變。與其閱讀目錄或從上往下掃描，用戶現(xiàn)在從一個問題開始。心理模式不再是”讓我研究這個規(guī)范”，而是”按照我喜歡的方式重新整理這些信息”。

我記得剛開始編程的時候，我會花幾個小時閱讀API文檔，從頭到尾?，F(xiàn)在呢？我打開文檔，直接搜索我想要的東西，或者問AI”怎么用這個庫做X”。這不是懶惰，而是效率的進化。

這個微妙的轉(zhuǎn)變——從被動閱讀到主動查詢——正在改變文檔需要成為什么。它們不再只是靜態(tài)的HTML或markdown頁面，而是正在成為交互式知識系統(tǒng)，由索引、嵌入和工具感知的AI agent支撐。

因此，我們看到像Mintlify這樣的產(chǎn)品興起，它們不僅將文檔結(jié)構(gòu)化為語義可搜索的數(shù)據(jù)庫，還充當跨平臺編程AI agent的上下文源。Mintlify頁面現(xiàn)在經(jīng)常被AI編程agent引用——無論是在AI IDE、VS Code擴展，還是終端agent中——因為編程agent使用最新的文檔作為生成的基礎(chǔ)上下文。

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

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

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

從模板到生成：vibe coding取代create-react-app

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

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

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

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

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

但這里有個有趣的副作用，我稱之為”框架民主化”。以前，選擇框架是一個重大決定，因為切換成本很高。現(xiàn)在，框架選擇變得更像選擇今天穿什么衣服：可以隨時改變。

當然，這也帶來了新的挑戰(zhàn)。標準化有它的優(yōu)勢——團隊協(xié)作更容易，troubleshooting更簡單，知識傳播更快。但隨著AI agent能夠理解項目意圖并執(zhí)行大規(guī)模重構(gòu)，實驗的成本顯著降低。

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

超越.env：在AI agent驅(qū)動的世界中管理秘密

這是一個很多人忽視但極其重要的問題。幾十年來，.env文件一直是開發(fā)者在本地管理秘密（比如API密鑰、數(shù)據(jù)庫URL和服務(wù)令牌）的默認方式。它們簡單、便攜、對開發(fā)者友好。但在AI agent驅(qū)動的世界中，這個范式開始崩潰。

想想這個場景：你有一個AI agent在幫你寫代碼，它需要連接到你的數(shù)據(jù)庫。你真的要把數(shù)據(jù)庫密碼直接給它嗎？如果是這樣，誰對數(shù)據(jù)泄露負責(zé)？AI agent？你？還是AI agent的提供商？

當AI IDE或AI agent代表我們編寫代碼、部署服務(wù)和協(xié)調(diào)環(huán)境時，不再清楚誰擁有.env。更重要的是，傳統(tǒng)的”環(huán)境變量”概念本身可能已經(jīng)過時了。我們需要的是一種能夠給予精確權(quán)限、可審計、可撤銷的秘密管理系統(tǒng)。

我們看到了一些可能的樣子的跡象。例如，最新的MCP規(guī)范包括一個基于OAuth 2.1的授權(quán)框架，暗示著可能轉(zhuǎn)向給AI agent提供有范圍的、可撤銷的令牌，而不是原始秘密。我們可以想象這樣一個場景：AI agent不會得到你的實際AWS密鑰，而是獲得一個短期憑證或能力令牌，讓它執(zhí)行一個狹窄定義的操作。

這可能發(fā)展的另一種方式是通過本地秘密代理的興起——在你的機器上或與你的應(yīng)用一起運行的服務(wù)，充當AI agent和敏感憑證之間的中介。代理可以請求訪問一個能力（”部署到預(yù)發(fā)布”或”將日志發(fā)送到Sentry”），而代理決定是否授予它——實時，并且完全可審計。

我把這種趨勢稱為”能力導(dǎo)向的安全”。與其給AI agent鑰匙（秘密），我們給它們許可（能力）。這就像從”信任但驗證”轉(zhuǎn)向”零信任但啟用”。

未來的秘密管理可能看起來更像一個權(quán)限系統(tǒng)，每個操作都有明確的范圍，每個AI agent都有明確的角色，所有訪問都被記錄和審計。這不僅更安全，也更符合AI agent的工作方式：它們不需要知道所有東西，只需要知道完成任務(wù)所需的東西。

無障礙作為通用界面：通過LLM的眼睛看應(yīng)用

這個趨勢讓我想起了”意外的創(chuàng)新”理論。我們開始看到一類新的應(yīng)用（比如Granola和Highlight），它們請求訪問macOS上的無障礙設(shè)置，不是為了傳統(tǒng)的無障礙用例，而是為了讓AI agent能夠觀察和與界面交互。但這不是一個hack：這是一個更深層次轉(zhuǎn)變的預(yù)示。

無障礙API最初是為了幫助有視力或運動障礙的用戶導(dǎo)航數(shù)字系統(tǒng)而建立的?，F(xiàn)在，這些相同的API正在成為AI agent理解和控制數(shù)字環(huán)境的通用語言。這就像盲文意外地成為了機器人讀取世界的方式。

想想這個：無障礙API已經(jīng)解決了”如何讓機器理解人類界面”的問題。它們提供了語義化的元素描述：這是一個按鈕，這是輸入框，這是鏈接。對于AI agent來說，這就是完美的數(shù)據(jù)結(jié)構(gòu)。

這里有個很深刻的洞察：我們一直在尋找如何讓AI agent與人類世界交互，但答案可能就在我們面前。無障礙技術(shù)已經(jīng)標準化了，已經(jīng)在所有主流操作系統(tǒng)中實現(xiàn)，已經(jīng)經(jīng)過了十幾年的實戰(zhàn)檢驗。

如果經(jīng)過深思熟慮的擴展，這可能成為AI agent的通用界面層。AI agent可以像輔助技術(shù)那樣語義地觀察應(yīng)用程序，而不是點擊像素位置或抓取DOM。無障礙樹已經(jīng)暴露了結(jié)構(gòu)化元素，如按鈕、標題和輸入框。如果用元數(shù)據(jù)（如意圖、角色和功能）進行擴展，這可能成為AI agent的第一類接口，讓它們有目的和精確地感知和操作應(yīng)用。

實際上，這個方向有幾個可能的發(fā)展路徑：

第一個是上下文提取，我們需要一種標準方式，讓使用無障礙或語義API的LLM agent能夠查詢屏幕上有什么，它可以與什么交互，以及用戶正在做什么。想象一下，AI agent可以說”告訴我這個屏幕上所有可點擊的元素”或”用戶現(xiàn)在在什么位置”，并立即得到結(jié)構(gòu)化的答案。

第二個是意圖式執(zhí)行，與其期望AI agent手動串聯(lián)多個API調(diào)用，不如暴露一個高層端點，讓它聲明目標（”將物品添加到購物車，選擇最快配送”），然后讓后端計算出具體步驟。這就像告訴司機”帶我去機場”，而不是給出每一個轉(zhuǎn)彎指令。

第三個是LLM的備用UI，無障礙功能為LLM提供了一個備用UI。任何暴露屏幕的應(yīng)用都變得對AI agent可用，即使它沒有公開API。對開發(fā)者來說，這暗示了一個新的”渲染層”——不僅是視覺或DOM層，而是AI agent可訪問的上下文，可能通過結(jié)構(gòu)化注釋或無障礙優(yōu)先的組件來定義。

這三個方向共同指向一個未來：應(yīng)用程序不再只為人眼設(shè)計，也為AI”眼”設(shè)計。每個界面元素都攜帶豐富的語義信息，不僅描述它看起來是什么，還描述它能做什么，以及如何使用它。

這引出了一個有趣的想法：如果我們把無障礙設(shè)計作為”機器可讀性”的標準呢？每個新的UI元素，每個新的交互模式，都從一開始就考慮機器理解。這不僅讓殘障人士受益，也讓AI agent受益。

未來，我們可能會看到一種”雙重設(shè)計”的趨勢：不僅為人類設(shè)計，也為AI agent設(shè)計。而無障礙原則可能成為這兩者的橋梁。這就像為多文化世界設(shè)計語言：不僅考慮母語者，也考慮學(xué)習(xí)者和翻譯者。

異步AI agent工作的興起

這個趨勢反映了工作方式的根本轉(zhuǎn)變。隨著開發(fā)者開始更流暢地與編程AI agent一起工作，我們看到了向異步工作流的自然轉(zhuǎn)變，AI agent在后臺運行，追求并行的工作線程，并在取得進展時報告回來。

這讓我想起了從同步編程到異步編程的轉(zhuǎn)變。一開始，程序都是同步的：做完一件事，再做下一件事。然后我們發(fā)現(xiàn)，等待是浪費時間，并發(fā)才是王道?，F(xiàn)在，我們在人機協(xié)作的層面經(jīng)歷同樣的轉(zhuǎn)變。

這種交互模式開始看起來不太像結(jié)對編程，更像任務(wù)編排：你委派一個目標，讓AI agent運行，稍后檢查。這就像你有了一個非常能干的實習(xí)生，你可以給他一個項目，讓他去做，然后你專注于其他事情。

關(guān)鍵是，這不僅僅是卸載努力；它還壓縮了協(xié)調(diào)。與其聯(lián)系另一個團隊更新配置文件、分類錯誤或重構(gòu)組件，開發(fā)者越來越能夠直接將這個任務(wù)分配給一個根據(jù)他們的意圖行動并在后臺執(zhí)行的AI agent。

這種變化有個深層次的含義：我們正在從同步協(xié)作轉(zhuǎn)向異步交響。傳統(tǒng)的軟件開發(fā)像是一場面對面的會議：所有人同時在場，實時討論。新的模式更像是一場分布式的樂團演奏：每個演奏者（AI agent）根據(jù)總譜（規(guī)范）獨立演奏，指揮（開發(fā)者）協(xié)調(diào)整體。

AI agent交互的界面也在擴展。除了總是通過IDE或CLI提示，開發(fā)者可以開始通過以下方式與AI agent互動：

• 向Slack發(fā)送消息
• 在Figma模擬圖上評論
• 在代碼差異或PR上創(chuàng)建內(nèi)聯(lián)注釋
• 基于部署的應(yīng)用預(yù)覽添加反饋
• 以及利用語音或基于通話的界面
• 開發(fā)者可以口頭描述更改

這創(chuàng)建了一個模型，其中AI agent貫穿開發(fā)的整個生命周期。它們不僅編寫代碼，還解釋設(shè)計、響應(yīng)反饋、并在平臺間分類錯誤。開發(fā)者成為決定追求、丟棄或合并哪個線程的協(xié)調(diào)者。

也許最有趣的是，這種異步模式可能會改變我們對”分支”的理解。傳統(tǒng)的Git分支是代碼的分叉。未來的”分支”可能是意圖的分叉，每個分支由不同的AI agent以不同的方式探索。開發(fā)者不再是合并代碼，而是評估和選擇不同的解決方案路徑。

MCP距離成為通用標準更近了一步

MCP（模型上下文協(xié)議）是最近最令人興奮的協(xié)議創(chuàng)新之一。我們最近發(fā)布了一份關(guān)于MCP的深度分析。從那以后，勢頭加速了：OpenAI公開采用了MCP，該規(guī)范的幾個新功能被合并，工具制造商開始聚合在它周圍，將其作為AI agent和現(xiàn)實世界之間的默認接口。

這讓我想起了HTTP在90年代的角色。HTTP不是第一個網(wǎng)絡(luò)協(xié)議，也不是最復(fù)雜的，但它簡單、足夠好，得到了廣泛支持?，F(xiàn)在MCP可能正走在類似的道路上。

在其核心，MCP解決了兩個大問題：它為LLM提供了完成可能從未見過的任務(wù)的正確上下文集；它用一個干凈的、模塊化的模型取代了N×M定制集成，在這個模型中，工具暴露標準接口（服務(wù)器），可由任何AI agent（客戶端）使用。

這里有個深刻的洞察：我們正在見證”能力標準化”的誕生。就像USB標準化了設(shè)備連接，MCP正在標準化AI agent能力。任何工具都可以暴露自己的功能，任何AI agent都可以使用這些功能，不需要定制集成。

我們預(yù)計隨著遠程MCP和事實上的注冊表上線，會看到更廣泛的采用。隨著時間的推移，應(yīng)用可能開始默認附帶MCP界面。想想API如何讓SaaS產(chǎn)品相互插入并跨工具組合工作流。MCP可以通過將獨立工具轉(zhuǎn)化為可互操作的構(gòu)建塊，為AI agent做同樣的事情。

這引出了一個有趣的想法：”能力市場”的出現(xiàn)。想象一下，未來有一個龐大的能力注冊表，AI agent可以發(fā)現(xiàn)和使用新能力，就像開發(fā)者現(xiàn)在使用npm或PyPI一樣。需要發(fā)送郵件？有個MCP服務(wù)器。需要圖像處理？有個MCP服務(wù)器。需要自定義業(yè)務(wù)邏輯？有個MCP服務(wù)器。

這不僅僅是技術(shù)標準，它是一種新的商業(yè)模式：能力即服務(wù)（Capabilities as a Service）。任何人都可以創(chuàng)建一個MCP服務(wù)器，暴露一個有用的能力，然后讓所有AI agent使用它。這就像云計算的下一個階段：不僅計算資源商品化了，連能力本身也商品化了。

抽象原語：每個AI agent都需要認證、計費和持久存儲

這個趨勢反映了一個基本的進化規(guī)律：抽象層次不斷提升。隨著vibe coding AI agent變得更強大，有一件事變得清楚：AI agent可以生成大量代碼，但它們?nèi)匀恍枰恍﹫詫嵉臇|西來插入。

就像人類開發(fā)者依賴Stripe進行支付、Clerk進行認證或Supabase進行數(shù)據(jù)庫能力一樣，AI agent需要同樣干凈和可組合的服務(wù)原語來搭建可靠的應(yīng)用程序。這里有個有趣的觀察：AI agent不是要取代基礎(chǔ)設(shè)施，而是要更好地利用它。

在很多方面，這些服務(wù)——具有清晰邊界、符合人體工程學(xué)的SDK和減少失敗機會的合理默認值的API——越來越多地充當AI agent的運行時接口。

想想這個場景：你告訴AI agent”創(chuàng)建一個帶有用戶認證和訂閱管理的SaaS應(yīng)用”。AI agent需要什么？它需要一個認證系統(tǒng)（Clerk），一個支付系統(tǒng)（Stripe），一個數(shù)據(jù)庫（Supabase），可能還需要郵件服務(wù)、文件存儲等等。

這引出了一個深刻的洞察：AI agent重塑了”框架”的概念。傳統(tǒng)框架給你一個結(jié)構(gòu)，你在里面填充邏輯。AI agent框架給你一套原語，AI agent可以組合成任何結(jié)構(gòu)。

隨著這種模式的成熟，我們可能開始看到服務(wù)通過不僅暴露API，還有架構(gòu)、能力元數(shù)據(jù)和幫助AI agent更可靠地集成它們的示例流程來為AI agent消費進行優(yōu)化。

這就像從”自底向上”變成”自頂向下”。以前，你從基礎(chǔ)設(shè)施開始，逐層向上構(gòu)建?，F(xiàn)在，你從意圖開始，AI agent幫你找到合適的構(gòu)建塊。這不是反向工程，而是正向設(shè)計。

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

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

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

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

這就像建筑行業(yè)的標準化組件。你不需要每次都從零開始設(shè)計電氣系統(tǒng)，你使用標準的開關(guān)、插座和配線方法。AI agent也不需要每次都從零開始實現(xiàn)認證，它們使用經(jīng)過驗證的、標準化的服務(wù)。

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

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

這九個趨勢指向一個更廣泛的轉(zhuǎn)變，新的開發(fā)者行為正在與更強大的基礎(chǔ)模型一起出現(xiàn)。作為回應(yīng)，我們看到新的工具鏈和像MCP這樣的協(xié)議形成。這不僅僅是將AI疊加在舊工作流上，而是對如何在核心由AI agent、上下文和意圖構(gòu)建軟件的重新定義。

我想強調(diào)的是，這些趨勢不是獨立的。它們互相強化，共同構(gòu)成了一個新的開發(fā)者生態(tài)系統(tǒng)。AI原生的版本控制系統(tǒng)依賴于標準化的能力接口；合成式界面受益于語義化的無障礙API；異步協(xié)作模式需要強大的秘密管理系統(tǒng)。

這讓我想起了每一個技術(shù)革命的規(guī)律：開始時，新技術(shù)模仿舊模式；然后，我們開始探索新技術(shù)的獨特可能性；最后，我們重塑整個系統(tǒng)以充分利用新能力。我們正在經(jīng)歷第二到第三階段的轉(zhuǎn)變。

許多開發(fā)者工具層正在發(fā)生根本性轉(zhuǎn)變，這不僅是技術(shù)的進步，更是思維方式的革命。我們正在從”編程”轉(zhuǎn)向”意圖表達”，從”版本控制”轉(zhuǎn)向”意圖追蹤”，從”文檔”轉(zhuǎn)向”知識神經(jīng)網(wǎng)絡(luò)”。

也許最重要的是，這些趨勢預(yù)示著軟件開發(fā)角色的根本變化。未來的開發(fā)者可能更像交響樂指揮，協(xié)調(diào)不同AI agent的工作，而不是像現(xiàn)在這樣，更像獨立的器樂演奏者。

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

我們很興奮構(gòu)建和投資下一代工具，不僅是為了更高效地編程，而是為了解決以前無法解決的問題，創(chuàng)造以前無法想象的可能性。這就是技術(shù)進步的真正意義：不僅是做得更快，而是做得更多，做得更好。

結(jié)尾

最后交個朋友，我自己是一個連續(xù)創(chuàng)業(yè)者，并在過去兩年擔(dān)任了25+產(chǎn)品的海外增長顧問，現(xiàn)在準備全職All-In入場創(chuàng)業(yè)，我給自己定位是COO的角色，希望能夠找到合適的CEO和CTO

?