產(chǎn)品的未來

Something maybe wrong

昨天寫了一篇文章：

在那里面，我試圖去描繪一件事情：軟件提供的，是被封裝的做事能力，而其所包含的代碼、界面、開發(fā)流程都只是表象。而現(xiàn)在，軟件的載體在消失，能力在泛化

寫完之后，我意識到了一個問題：以往，我們認(rèn)為科技公司的產(chǎn)品就是軟件。那么，在 AI 普遍改變社會生產(chǎn)關(guān)系后，未來科技公司的產(chǎn)品還是軟件嗎？以及，產(chǎn)品的未來是怎樣的？

這個問題也讓我想了很久，本文制作當(dāng)下想法的記錄，或許在1年以后來看，我所言的都是錯的

→產(chǎn)品的主要使用者，正在從人轉(zhuǎn)向 Agent，人的角色從操作者變成委托者

→產(chǎn)品在給人用時，決定體驗的是交互，給 Agent 用時則是協(xié)議

→產(chǎn)品的基本單位從功能轉(zhuǎn)向任務(wù)，圍繞任務(wù)會長出一套全新的產(chǎn)品骨架

→做事方法可以被封裝成 Skill 直接分發(fā)，服務(wù)業(yè)的產(chǎn)品化從這里打開入口

→ 更遠(yuǎn)一步，連「該做什么」這個判斷也會由系統(tǒng)自己生成

用戶不再是人

一直以來，我們默認(rèn)產(chǎn)品是給人用的

人點按鈕、填表單、切頁面，一步步走完操作路徑。現(xiàn)在越來越多的產(chǎn)品在被 Agent 調(diào)用，Agent 讀 API、傳參數(shù)、拿結(jié)果、判斷要不要繼續(xù)下一步，它不需要看見界面

人的角色跟著變了。過去人親自做事，現(xiàn)在人表達(dá)目標(biāo)、檢查關(guān)鍵節(jié)點、承擔(dān)最終責(zé)任。從操作者變成了委托者，產(chǎn)品設(shè)計也要從幫助人操作轉(zhuǎn)向幫助人委托

用戶變了，產(chǎn)品的設(shè)計語言就要跟著變。以往，優(yōu)秀的產(chǎn)品要讓人看得懂、找得到、點得動。曾經(jīng)我還提過一個“瞇眼法則”：優(yōu)秀的產(chǎn)品，需要用戶在瞇著眼睛完全看不清的前提下，也能知道該怎么用

而如今，如果一個產(chǎn)品是給 Agent 設(shè)計的，那么它幾乎完全不用考慮配色、動態(tài)交互什么的，而是需要有需要清晰的能力描述、輸入輸出 schema、權(quán)限邊界、錯誤返回和上下文說明。Agent-readable 在變成和 user-friendly 同等重要的產(chǎn)品標(biāo)準(zhǔn)

你可能沒見過 Agent-readable 這個詞... 這是我剛編的，但我覺得很合理

在這個過程中，產(chǎn)品的界面也也應(yīng)該隨之改變。過去 UI 幫人一步步完成操作，未來 UI 幫人看見 Agent 做到哪一步了、哪里需要確認(rèn)、哪里可以回滾。界面從操作臺變成了監(jiān)控臺

API 的粒度也在變。傳統(tǒng) API 是動作級的，create_order，send_email，update_record，一個接口做一個動作。Agent 更需要任務(wù)級接口，prepare_customer_meeting，summarize_contract_risk，generate_weekly_report。一個接口完成一整件事

軟件給人用時體驗是路徑，給 Agent 用時體驗是協(xié)議。未來軟件的體驗設(shè)計，會有一部分轉(zhuǎn)化成協(xié)議設(shè)計

如果用戶只和通用 Agent 對話，Agent 在后臺替用戶挑選和調(diào)用各種其他工具、軟件、接口，那很多公司會失去直接的用戶關(guān)系。外賣平臺讓餐廳失去了一部分堂食關(guān)系，電商讓品牌失去了一部分門店關(guān)系。Agent 入口可能讓 SaaS 失去前臺關(guān)系

舊的默認(rèn)姿態(tài)是人使用系統(tǒng)、AI 輔助人。新的默認(rèn)姿態(tài)是 Agent 駕駛系統(tǒng)、人監(jiān)督 Agent。當(dāng)然，現(xiàn)如今很多公司以為給現(xiàn)有系統(tǒng)加一個 AI 功能就行了，什么自動幫你找符合你口味的外賣、自動幫你比架機(jī)票，但其實遠(yuǎn)遠(yuǎn)不夠

新的一代產(chǎn)品，應(yīng)該建立在新的地基之上

開發(fā)，不再圍繞功能

我的本職是產(chǎn)品經(jīng)理，以前做產(chǎn)品設(shè)計的時候，絕大多數(shù)時間是在「加功能」。核心工作是給成型產(chǎn)品增加各種 Feature，篩選功能、導(dǎo)出功能、報表功能，然后規(guī)劃排期交付開發(fā)

而現(xiàn)在用 AI 進(jìn)行開發(fā)的時候，我需要做的是定義任務(wù)節(jié)點。比如什么時候要調(diào)用哪些工具，什么時候算是交付完成，等等...

寫到這里的時候我停下來想了一下：這期間發(fā)生了什么？以往的開發(fā)要圍繞功能進(jìn)行，這是軟件行業(yè)找到的最小可計量交付單位，能估出一個工時，能輔助排期，能在上線后打勾驗收

這里再說一個題外話：很多大型項目，也是按功能點和頁面數(shù)量算錢的，有專門的計算方法。畢竟智力勞動很難直接定價，那就數(shù)頁面、數(shù)按鈕、數(shù)字段，把不可量化的工作折算成可計量的交付物。這也是為什么你打開很多大型軟件，會看到密密麻麻的二級菜單，每個菜單項背后都對應(yīng)一個工作量、一筆款、一次驗收

這時候不難發(fā)現(xiàn)，基于功能點開發(fā)能反應(yīng)「系統(tǒng)能做什么」，而基于任務(wù)的開發(fā)則是回應(yīng)「要完成什么」。完成一次客戶會前準(zhǔn)備，可能涉及日歷查詢、郵件檢索、CRM 數(shù)據(jù)拉取、摘要生成、文檔排版，跨了好幾個傳統(tǒng)功能模塊。Agent 產(chǎn)品必須圍繞任務(wù)來組織能力

Skill 會成為流程的最小可復(fù)用單元。過去復(fù)用代碼，SaaS 復(fù)用流程模板，Agent 時代復(fù)用 Skill。一個 Skill 是一段可遷移的做事方法，可能比某個功能更接近業(yè)務(wù)價值本身。在我看來，Agent 產(chǎn)品價值更會在于什么時候調(diào)用、調(diào)用后怎么判斷、失敗后怎么辦、結(jié)果怎么驗收等等..

Memory 會成為長期差異化的來源。功能可以復(fù)制，界面可以模仿，模型可以替換，但一個系統(tǒng)長期積累的用戶上下文、項目歷史、組織規(guī)則、失敗案例，很難瞬間搬走。留住用戶的關(guān)鍵，是系統(tǒng)越來越懂你怎么做事

Eval 同時承擔(dān)兩個角色：測試系統(tǒng)和進(jìn)化引擎。沒有 Eval，Agent 的進(jìn)步無法被證明。沒有 Eval，Skill 的升級沒有方向。沒有 Eval，企業(yè)不敢把核心流程交出去

Permission 會成為 Agent 產(chǎn)品體驗的核心。用戶最關(guān)心的不只是 Agent 能做什么，還有它會不會越界。能讀什么、能改什么、能發(fā)什么、能刪什么、哪些地方必須問人，這些邊界要讓用戶看得見

傳統(tǒng)軟件的交互節(jié)點是按鈕，Agent 軟件的交互節(jié)點是確認(rèn)。用戶不需要每一步都參與，但關(guān)鍵判斷必須可審查。哪些步驟自動執(zhí)行、哪些步驟必須用戶確認(rèn)，這條分界線的設(shè)計是新課題

飛機(jī)自動執(zhí)行高風(fēng)險過程所以需要黑匣子，Agent 自動執(zhí)行復(fù)雜任務(wù)同樣需要。Trace 記錄的不只是動作，還有上下文、判斷依據(jù)、工具調(diào)用和結(jié)果。沒有 Trace，Agent 進(jìn)不了嚴(yán)肅業(yè)務(wù)場景

當(dāng)然，在開發(fā)的過程中，很多東西也在發(fā)生顯著的變化

比如，前文提到過的，以前規(guī)劃產(chǎn)品是在加功能，而后續(xù)的產(chǎn)品開發(fā)可能是在加能力。舉個例子，對于辦公軟件迭代的時候，是圍繞著「上傳」、「下載」、「創(chuàng)建副本」這種按鈕去開發(fā)；而對于 Agent 產(chǎn)品，則是添加能力，比如「生成圖片的能力」、「剪輯音頻的能力」。產(chǎn)品進(jìn)化，從功能增加變成能力增長，產(chǎn)品規(guī)劃，從 Feature Roadmap 到 Capability Roadmap

于此同時，驗證產(chǎn)品是否有用的方式。以前是通過構(gòu)建 MVP 最小可執(zhí)行版本，來驗證一個產(chǎn)品能不能用。而接下來則是應(yīng)該驗證一個真實任務(wù)能不能閉環(huán)。如果起一個名次的話，我覺得可以叫可以叫 MVT，Minimum Viable Task。用戶給出意圖后 Agent 能否完成，結(jié)果是否可接受，過程是否可追蹤，失敗是否可恢復(fù)

方法的產(chǎn)品化

這里得說一下，Skill 和提示詞是不同的：提示詞通常是一段文本，告訴模型怎么回答問題，Skill 則是一個打包的 .zip，里面可以包含多種素材（比如包含能直接運(yùn)行的 .py 文件），以及一份說明書告訴 Agent 怎么完成一類任務(wù)，讓 Agent 穩(wěn)定完成某類事

一個好的 Skill 包含任務(wù)邊界、執(zhí)行步驟、工具說明、輸入輸出格式、示例、腳本、模板、錯誤處理和質(zhì)量標(biāo)準(zhǔn)。它是流程、知識、工具、模板和評估標(biāo)準(zhǔn)的混合體，更像一個輕量級的安裝包，中心從代碼換成了方法

通過 Skill，方法本身可以產(chǎn)品化了。咨詢公司的方法論、律師的審查框架、編輯的改稿流程、運(yùn)營的復(fù)盤模板，都可以變成 Skill 直接分發(fā)。過去各種工具，只能封裝高度標(biāo)準(zhǔn)化的流程，現(xiàn)在連需要判斷力的方法也可以封裝。

以前是 SaaS，Software as a Service；現(xiàn)在則是 SaaS，Service as a Software，服務(wù)業(yè)的軟件化，從這里打開了新入口。在這里，Skill 是一次性軟件和長期軟件之間的中間形態(tài)，但每次執(zhí)行都可以生成不同的過程和結(jié)果。換句話說：Skill 可復(fù)用的過程生成器

我自己的公眾號排版，本身也是一套 Skill 流水線，封裝了我之前收工排版、程序排版的經(jīng)驗，以及我在公眾號排版里遇到的各種 Bug 和我的處理辦法，這樣每次 AI 就能一次性的把我的內(nèi)容進(jìn)行正確的、一致的進(jìn)行排版

Skill 加上 Memory 才能從通用能力變成個人能力。還是以排版這個事兒為例，你看到的各種加粗，都是排版期自主決定的...我的 AI 知道我的創(chuàng)作偏好、歷史風(fēng)格，甚至各種奇怪的惡趣味，然后不斷內(nèi)化成了自己的風(fēng)格。還有，以上這些還得再加上 Eval 才能持續(xù)進(jìn)化。結(jié)果是否符合格式、是否遺漏關(guān)鍵信息、是否減少人工修改，這些都應(yīng)該進(jìn)入評估，這是一種穩(wěn)健的工程化，你也可以把它叫做 Harness

Skill 的競爭，是隱性經(jīng)驗的結(jié)構(gòu)化能力。什么時候該這樣做、什么時候絕對不能這樣做、異常怎么判斷、優(yōu)先級怎么排、什么結(jié)果看起來對但其實有隱患。這些判斷長在做了十年這件事的人的直覺里

這時候會發(fā)現(xiàn)，一個 Skill 改了就可能影響大量 Agent 任務(wù)。Skill 需要版本管理、回滾、灰度、測試和審計。所以未來想必也會出現(xiàn) SkillOps，和今天的 DevOps、MLOps 一個邏輯

OPC？NPC！

前段時間各地都出臺了 OPC（一人公司）的相關(guān)政策：一個人通過各種 AI 工具，能夠產(chǎn)生匹敵一個團(tuán)隊的生產(chǎn)力，在這里：人提出目標(biāo)，Agent 去執(zhí)行。本質(zhì)上，還是自動化的增強(qiáng)版

那么，下一代產(chǎn)品會從復(fù)雜系統(tǒng)轉(zhuǎn)向簡單的委托關(guān)系。信任會成為比功能更重要的體驗

商業(yè)模式也跟著變。如果 Agent 真正交付任務(wù)結(jié)果，按賬號收費(fèi)就太粗糙了。按完成任務(wù)數(shù)、節(jié)省時間、處理量、成功結(jié)果、自動化比例來計費(fèi)，這些方式在慢慢出現(xiàn)。賣的東西越來越接近結(jié)果本身

再往遠(yuǎn)看一步，如果 OPC 是 ok 的，那么為什么不做 NPC（零人公司），在這里，意圖本身也可能由系統(tǒng)生成。庫存數(shù)據(jù)異常，系統(tǒng)自己發(fā)起補(bǔ)貨任務(wù)。客戶流失風(fēng)險升高，系統(tǒng)自己發(fā)起挽回動作。項目延期概率上升，系統(tǒng)自己調(diào)整資源。沒有人下達(dá)指令，系統(tǒng)根據(jù)數(shù)據(jù)、環(huán)境和目標(biāo)函數(shù)自己判斷該做什么

到那個階段，Agent 的驅(qū)動力來自更高層的目標(biāo)函數(shù)：增長目標(biāo)、成本目標(biāo)、風(fēng)險目標(biāo)、效率目標(biāo)、服務(wù)質(zhì)量目標(biāo)。Agent 網(wǎng)絡(luò)圍繞這些目標(biāo)持續(xù)生成任務(wù)、分配資源、執(zhí)行動作、評估反饋。Agent 不再圍繞用戶請求運(yùn)行，開始圍繞目標(biāo)狀態(tài)運(yùn)行

如果未來是一個人管理一群 Agent，那么他自然也可以是 Agent 之間自己發(fā)現(xiàn)問題、提出任務(wù)、互相調(diào)用、互相審計。人只在少數(shù)高風(fēng)險、高責(zé)任的節(jié)點進(jìn)入，定義系統(tǒng)為什么存在、什么不能做、什么代價不可接受

這時候權(quán)限問題會變得更尖銳。過去管的是 Agent 能不能發(fā)郵件、能不能改文件。未來還要管它能不能主動發(fā)現(xiàn)目標(biāo)、主動創(chuàng)建任務(wù)、主動影響資源分配。Agent 治理，從執(zhí)行權(quán)限升級到意圖權(quán)限

最終形態(tài)，可能是一個會自我生成任務(wù)的 Agent 執(zhí)行網(wǎng)絡(luò)，用戶看不見頁面，甚至看不見任務(wù)提出的過程，看到的只是一個組織持續(xù)運(yùn)行后的狀態(tài)變化

最后

寫到這里的時候，發(fā)現(xiàn)今天是 5月4號，青年節(jié)，的確是一個值得奮斗的時候

過去十五年，互聯(lián)網(wǎng)和軟件，在一個個行業(yè)的吞下，接下來被吞掉的，則是自己的舊形態(tài)

點個“愛心”，再走 吧