YC合夥人：今天的AI應用不行，不是AI的問題，而是產品設計能力不行

在AI時代，很多人都有一個問題，AI原生應用到底長什麼樣？

不久前，YC合夥人Pete Koomen提出了一個很有意思的看法：當下很多AI產品的困境並不在於模型能力不行，而是應用設計不行。

原因在於，這些產品仍然基於過去的產品邏輯來設計，而沒有充分考慮到用戶的實際需求。

比如，傳統的產品開發往往需要程序員預先設計好系統提示符，但這些早被設計好的提示詞在實際應用中，卻很難真正滿足用戶個性化的需求，甚至成為了大模型潛力釋放的最大阻礙。

這就像19世紀80年代的蒸汽馬車，人們只想著用發動機取代馬匹作為動力驅動，卻沒有考慮重新設計車輛以應對更高的速度。

在這篇文章里，Pete Koomen就用了自己的親身經歷，分享了他對AI原生應用的理解。

一、從Gmail新AI功能說起

比起大多數AI應用，我更喜歡自己用AI開發軟件。

當我用AI開發軟件時，我能很快創建自己想要的東西，但很多AI應用卻沒有這種感覺。它們的AI功能毫無用處，只是模仿過去開發軟件的方式。我認為，這種路徑依賴限制了AI產品真正的價值。

為了更好地說明我的意思，我就拿Gmail的人工智能助手來舉例說明：

不久前，Gmail團隊發佈了一項新功能，允許用戶使用Google的旗艦人工智能模型Gemini從頭開始生成電子郵件草稿。這就是它的樣子：

在界面上，我添加了一個提示，請求我給老闆寫一封郵件。我們來看看 Gemini 的返回結果：

正如你所見，Gemini 寫出了非常合理的草稿。但遺憾的是，它聽起來一點也不像我真正會寫的電子郵件。如果我自己寫這封郵件，它應該是這樣的：

語氣並不是這篇郵件唯一的問題。我還花了很多精力去寫提示詞，甚至寫提示詞的字數超過了我自己寫郵件的字數。

這意味著，我用Gemini寫稿件，遠遠不如我自己寫。

這很不科學。按理說，Gemini這麼強大的模型，完全有能力寫出一封優秀的電子郵件。但Gmail 團隊卻沒有做到。

二、更好的電子郵件助手

為了說明這一點，這裏有一個AI電子郵件助手的簡單演示，如果Gmail推出了這個助手，我可以節省很多時間：

這個演示是用AI閱讀電子郵件，而不是從頭開始撰寫。每封電子郵件都會被分類並按優先級排序，有些會自動存檔，有些則會收到自動生成的回覆草稿。

助手會根據自定義的「系統提示」逐個處理電子郵件，該提示會準確解釋我希望如何處理每封電子郵件。您可以通過編輯系統提示來嘗試自己的標籤邏輯。

這種方法顯然更加強大，那麼為什麼Gmail團隊不這樣做呢？為了回答這個問題，讓我們更深入地分析一下他們的設計中存在的問題。我們先從它的通用風格說起。

三、人工智能斜率

Gmail的AI助手生成的草稿冗長、正式得有些怪異，完全不像我的風格。

每個用過大模型寫作的人都有過這種經歷，以至於我們大多數人在寫作時都會不自覺地採取一些策略來避免這種情況。最簡單的策略就是寫一些更詳細的說明，引導AI朝著正確的方向發展，就像這樣：

但問題在於，每次我想寫新郵件的時候，我都得寫類似的內容。

有一個簡單的解決方案可以解決這個問題，但許多 AI 應用程序開發人員似乎都忽略了這一點：讓我編寫自己的「系統提示」。

四、系統提示和用戶提示

從外部來看，大型語言模型其實非常簡單。它們讀取一串單詞，即「提示」，然後開始一個接一個地預測接下來可能出現的單詞，即「響應」。

這裏需要注意的是，所有的輸入和輸出都是文本。大模型的用戶界面也是文本。

OpenAI和 Anthropic等大模型廠商都用了一種方式來簡化提示詞編寫。他們把提示分為兩個部分：系統提示和用戶提示。之所以這樣命名是因為在許多API應用程序中，應用程序開發人員編寫系統提示，而用戶編寫用戶提示。

系統提示向模型解釋了如何完成一組特定的任務，並被反復使用。用戶提示則描述了需要完成的具體任務。

您可以將系統提示視為一個函數，將用戶提示視為其輸入，將模型的響應視為其輸出：

在我原來的例子中，用戶提示是：

Google對系統提示符保密，但根據輸出我們可以猜出它是什麼樣子：

這事的問題不僅僅在於Gmail團隊編寫了一個糟糕的系統提示。更重要的是，我還不能修改它。

如果 Gmail 不強迫我使用他們千篇一律的系統提示，而是讓我自己編寫，它看起來會像這樣：

直觀地看，你就能明白是怎麼回事：當我編寫自己的系統提示時，我正在教大模型按照我的方式寫電子郵件。這樣行得通嗎？我們試試看吧。

嘗試使用（設想的）Gmail系統提示符生成草稿，然後使用上面的「Pete 系統提示符」執行相同操作。「Pete」版本會顯示如下內容：

太完美了！太簡單了！

不僅這次草稿的輸出效果更好，而且由於系統提示會反復使用，以後的每一稿都會更好。不用再費勁地向Gemini解釋如何像我一樣寫作了！

花幾分鐘思考一下你是如何寫電子郵件的。試著寫一個「你的系統提示」，看看會發生什麼。如果輸出看起來不對，試著想像一下你在解釋中遺漏了什麼，然後再試一次。重覆幾次，直到你覺得輸出結果對了為止。

更好的辦法是，嘗試一些其他的用戶提示。例如，看看你能不能讓大模型用你的聲音寫這些郵件：

教大模型用你的方法解決問題，並看著他們成功，這感覺很神奇。令人驚訝的是，這實際上比教人更容易，因為與人不同，大模型會即時、誠實地反饋你的解釋是否足夠好。如果你收到滿意的電子郵件草稿，那麼你的解釋就足夠了。如果你沒有收到，那麼就不夠。

通過公開系統提示並使其可編輯，我們創造了一種可以產生更好結果並且實際上很有趣的產品體驗。截至現在，大多數AI靜態應用不會（故意）暴露其系統提示。為什麼呢？

五、無馬馬車

每當一項新技術被發明出來，第一批基於該技術構建的工具必然會失敗，因為它們往往照搬了舊有的運作方式，就像無馬馬車。

「無馬馬車」指的是早期的汽車設計，它大量借鑒了之前的馬車。以下是我在域奇百科上找到的一張1803年蒸汽馬車設計圖：

這種設計的缺陷在當時是無人察覺的，但事後卻顯而易見。

想像一下，生活在1806年，第一次乘坐這樣的車。即使木製車架足夠堅固，能讓你到達目的地，但木製座椅和缺乏懸掛的懸掛系統也會讓過程變得難以忍受。

你可能會想：「我絕對不會選擇發動機而不是馬。」至少在汽車發明之前，你是對的。

我懷疑我們正經歷著類似的人工智能應用時代。其中許多應用就像Gmail的Gemini集成一樣，毫無用處。

最初的無馬馬車誕生於「舊世界思維」，其核心是用發動機取代馬匹，而沒有重新設計車輛以應對更高的速度。究竟是什麼舊世界思維限制了這些人工智能應用呢？

六、舊世界思維

現在，你想讓計算機做一件事，可以有兩種選擇來實現它：

• 編寫一個程序

• 使用其他人編寫的程序

編程很難，所以我們大多數人都會選擇第二種方案。這就是為什麼我寧願花幾美元買一個現成的應用，也不願自己開發；也是為什麼大公司寧願花數百萬美元請Salesforce，也不願自己開發 CRM。

現代軟件行業建立在這樣一個假設之上：我們需要開發人員充當我們與計算機之間的中間人。他們將我們的願望轉化為代碼，並將其抽像到我們能夠理解的簡單、通用的界面背後。

分工很明確：開發人員決定軟件在一般情況下的行為，用戶提供輸入來確定軟件在特定情況下的行為。

通過將提示符拆分為系統提示詞和用戶提示詞，我們創建了與這些舊領域完全對應的類似物。系統提示符控制LLM在一般情況下的行為，而用戶提示符則是決定LLM在特定情況下行為的輸入。

在這種框架下，我們很自然地會認為編寫系統提示詞是開發人員的工作，編寫用戶提示詞是用戶的工作。

但在Gmail的案例中，這就行不通了。AI助手應該是代表我，用我的方式來寫郵件，而不是由Google產品經理和律師組成的委員會設計的千篇一律的聲音。

在以前，我只能接受通用的產品，因為我很難去編寫自己的程序。但到了AI時代，不需要通過程序員告訴計算機應該做什麼，任何人都可以編寫自己的系統提示詞。

這就是我想說的：當AI代理代表我做事的時候，我應該被允許通過編輯系統提示來教它如何做到這一點。

這不意味著我需要自己從頭開始編寫自己的系統提示。Gemini應該能夠使用我的電子郵件作為參考示例，為我編寫草稿提示。

那麼，像人工智能會計代理或人工智能法律代理這樣不那麼個性化的代理呢？對於軟件開發人員來說，聘請專業的會計師或律師來編寫通用的系統提示，不是更合理嗎？

如果我是用戶，這或許說得通。執行X操作的系統提示應該由X領域的專家編寫，而我並非會計或法律專家。不過，我猜大多數會計師和律師也想自己編寫系統提示，因為他們的專業知識是與具體情況相關的。

例如，YC的會計團隊就以YC獨有的方式運作。他們使用內部軟件和現成軟件的特定組合。他們使用YC特有的慣例，只有其他YC員工才能理解。他們管理的資金結構也是YC獨有的。一個千篇一律的會計代理人對我們團隊的幫助，就好比一個對YC一無所知的專業會計師：完全沒用。

我工作過的每家公司，每個會計團隊都是如此。這就是為什麼這麼多財務部門仍然使用Excel：它是一個通用工具，可以處理無數特定用例。

在大多數人工智能應用中，系統提示應該由用戶編寫和維護，而不是軟件開發人員，甚至是開發人員聘請的領域專家。

大多數人工智能應用程序應該是代理構建器，而不是代理。

七、不寫提示詞，開發者需要做什麼？

如果開發人員不寫提示，他們需要做什麼？

首先，他們將創建用於在特定領域運行的構建代理（例如電子郵件收件箱或總賬）的 UI。

大多數人可能不想從頭開始編寫每個提示，而優秀的代理構建器也不會強迫他們這樣做。開發人員會提供模板和提示編寫代理，幫助用戶創建自己的代理。

用戶還需要一個界面來查看代理的工作並迭代他們的提示，類似於我上面提到的小型虛擬電子郵件代理構建器。這個界面為他們提供了一個快速的反饋循環，用於訓練代理可靠地執行任務。

開發人員還將構建代理工具。

工具是代理人與外界互動的機制。我的郵件代寫代理人需要一個工具來提交草稿供我審閱。它可能會使用另一個工具發送一封未經我審閱的郵件，或者搜索我的收件箱，查找某個郵箱地址之前發來的郵件，或者查看YC的創始人名錄，看看郵件是否來自YC的創始人。

工具為代理提供了安全層。代理能否執行特定操作取決於其可以訪問的工具。使用代碼編寫的工具強製執行邊界比使用文本在系統提示和用戶提示之間強製執行邊界要容易得多。

八、AI原生應用的期待

對於我們許多人來說，人工智能的「殺手級應用」就是這個樣子：教計算機做我們不喜歡做的事情，這樣我們就可以把時間花在自己喜歡的事情上。

在大多數情況下，大模型已經足夠好了。阻礙我們實現AI更廣泛應用的，不是AI能力不行，而是應用程序設計。

就像Gmail團隊打造了一輛沒有馬的馬車，因為他們著手將人工智能添加到他們現有的電子郵件客戶端中，而不是思考如果從頭開始設計一個包含人工智能的電子郵件客戶端會是什麼樣子。

他們的應用是將人工智能塞進一個為日常人工勞動設計的界面中，而不是一個為自動化日常勞動設計的界面中。

AI原生軟件應該最大限度地提升用戶在特定領域的影響力。AI原生電子郵件客戶端應該最大限度地減少我花在電子郵件上的時間。AI原生會計軟件應該最大限度地減少會計人員記賬的時間。

這正是我對人工智能未來充滿期待的原因。在那個世界里，我無需花時間去做那些枯燥乏味的工作，因為代理會幫我處理。我只需專注於我認為重要的事情，因為代理會處理其他所有事情。我熱愛的工作也能更高效，因為代理會幫我完成。

本文來自微信公眾號：烏鴉智能說，作者：智能烏鴉