產(chǎn)品的未來

Something maybe wrong

昨天寫了一篇文章：

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

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

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

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

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

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

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

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

用戶不再是人

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

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

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

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

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

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

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

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

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

如果用戶只和通用 Agent 對(duì)話，Agent 在后臺(tái)替用戶挑選和調(diào)用各種其他工具、軟件、接口，那很多公司會(huì)失去直接的用戶關(guān)系。外賣平臺(tái)讓餐廳失去了一部分堂食關(guān)系，電商讓品牌失去了一部分門店關(guān)系。Agent 入口可能讓 SaaS 失去前臺(tái)關(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)加一個(gè) AI 功能就行了，什么自動(dòng)幫你找符合你口味的外賣、自動(dòng)幫你比架機(jī)票，但其實(shí)遠(yuǎn)遠(yuǎn)不夠

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

方法的產(chǎn)品化

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

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

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

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

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

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

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

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

OPC？NPC！

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

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

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

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

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

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

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

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

最后

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

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