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

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

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

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

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

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

Founder Park 正在搭建開發者社群，邀請積極嘗試、測試新模型、新技術的開發者、創業者們加入，請掃碼詳細填寫你的產品/項目信息，通過審核后工作人員會拉你入群～

進群之后，你有機會得到：

• 高濃度的主流模型（如 DeepSeek 等）開發交流；

• 資源對接，與 API、云廠商、模型廠商直接交流反饋的機會；

• 好用、有趣的產品/案例，Founder Park 會主動做宣傳。

01

從 Gmail 的 AI 功能說起

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

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

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

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

▲Gmail 的 Gemini 電子郵件草稿生成功能

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

▲Gmail 的 Gemini 電子郵件草1稿生成功能回應

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

▲我會寫的電子郵件

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

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

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

02

更好的電子郵件助手

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

▲使用OpenAI的GPT-4O-mini實現的實用電子郵件助手演示

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

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

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

03

AI 垃圾（AI Slop）

Gmail的AI助手生成的草稿冗長、正式得有些怪異，完全不像我的風格。要是我的真的把它發給同事，他八成會誤以為這是某種釣魚攻擊。

這就是典型的 AI 垃圾（AI Slop）。

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

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

這是一個用來比較我的原始 prompt 和擴展后 prompt 的樣稿演示：

生成的草稿聽起來更好，但這顯然很蠢。新的提示詞比原來要珍藏，而且每次想寫新郵件時，我都得像這樣寫一大段話。

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

04

系統提示詞和用戶提示詞

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

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

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

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

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

▲使用 gpt-4o-mini 簡單演示系統/用戶提示關系

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

▲我原來的用戶提示

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

▲Gmail 的電子郵件草稿撰寫系統提示（大概）

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

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

▲Pete 系統提示詞

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

▲根據系統提示，gpt-4o-mini 對相同的用戶提示返回截然不同的響應

嘗試使用（設想的）Gmail系統提示詞生成草稿，然后使用上面的“Pete 系統提示詞”執行相同操作?！癙ete”版本會顯示如下內容：

▲使用 Pete System Prompt 生成的電子郵件草稿

太完美了！太簡單了！

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

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

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

▲個人電子郵件用戶提示詞

▲客戶支持請求用戶提示詞

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

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

05

沒馬的馬車

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

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

▲特里維西克 1803 年的倫敦蒸汽馬車

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

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

你可能會想：“我絕對不會選擇發動機而不是馬?！敝辽僭谄嚢l明之前，你是對的。

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

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

06

舊世界思維

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

1. 編寫一個程序

2. 使用其他人編寫的程序

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

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

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

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

在這種框架下，我們很自然地會認為編寫系統提示詞是開發人員的工作，編寫用戶提示詞是用戶的工作。這就是我們一直以來構建軟件的方式。

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

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

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

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

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

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

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

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

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

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

07

不寫提示詞，

開發者需要做什么？

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

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

大多數人可能不想從頭開始編寫每個提示，而優秀的代理構建器也不會強迫他們

這樣做。開發人員會提供模板和提示編寫Agent，幫助用戶創建自己的Agent。

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

開發人員還將構建Agent工具。

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

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

08

一個幫我閱讀郵件的 Agent

正如我上面提到的，一個更好的系統提示（System Prompt）仍然無法幫我在從零開始寫郵件時節省太多時間。

原因很簡單：我喜歡郵件盡可能簡潔，這也意味著任何用我語氣寫的郵件，其實和描述它的用戶提示（User Prompt）長度差不多。每次嘗試用大語言模型寫點東西時，我都有類似的體驗。令人驚訝的是，生成式 AI 模型其實并不那么擅長生成文本。

大語言模型真正擅長的是閱讀并轉換文本，這才是我希望用智能代理來做的事。我們來回顧一下之前的讀郵件Agent的演示：

想象一下這樣的讀郵件代理能幫我節省多少時間并不難。它似乎已經比 Gmail 自帶的垃圾郵件過濾器識別得更準確。它比我現在用的一堆復雜的過濾規則更強大，也更易維護。它可以在我認定為緊急的郵件到達時自動提醒我，并在我打開郵件時自動生成一封用我語氣寫好的草稿回復。它可以自動歸檔那些我不需要閱讀的郵件，并對重要郵件生成摘要。

甚至，只要再接入幾個額外的工具，它還能幫我退訂郵件列表、安排日程、甚至付賬單——全程無需我動手。

這才是我真正想從一個 AI 原生郵箱客戶端中得到的東西：把這些瑣碎工作自動化，讓我少花點時間在郵件上。

09

對于 AI-Native 應用的期待

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

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

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

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

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

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

轉載原創文章請添加微信：founderparker