Something maybe wrong

昨天寫了一篇文章：

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

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

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

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

→產品在給人用時，決定體驗的是交互，給 Agent 用時則是協議

→產品的基本單位從功能轉向任務，圍繞任務會長出一套全新的產品骨架

→做事方法可以被封裝成 Skill 直接分發，服務業的產品化從這里打開入口

→ 更遠一步，連「該做什么」這個判斷也會由系統自己生成

用戶不再是人

一直以來，我們默認產品是給人用的

人點按鈕、填表單、切頁面，一步步走完操作路徑。現在越來越多的產品在被 Agent 調用，Agent 讀 API、傳參數、拿結果、判斷要不要繼續下一步，它不需要看見界面

人的角色跟著變了。過去人親自做事，現在人表達目標、檢查關鍵節點、承擔最終責任。從操作者變成了委托者，產品設計也要從幫助人操作轉向幫助人委托

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

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

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

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

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

軟件給人用時體驗是路徑，給 Agent 用時體驗是協議。未來軟件的體驗設計，會有一部分轉化成協議設計

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

舊的默認姿態是人使用系統、AI 輔助人。新的默認姿態是 Agent 駕駛系統、人監督 Agent。當然，現如今很多公司以為給現有系統加一個 AI 功能就行了，什么自動幫你找符合你口味的外賣、自動幫你比架機票，但其實遠遠不夠

新的一代產品，應該建立在新的地基之上

開發，不再圍繞功能

我的本職是產品經理，以前做產品設計的時候，絕大多數時間是在「加功能」。核心工作是給成型產品增加各種 Feature，篩選功能、導出功能、報表功能，然后規劃排期交付開發

而現在用 AI 進行開發的時候，我需要做的是定義任務節點。比如什么時候要調用哪些工具，什么時候算是交付完成，等等...

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

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

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

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

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

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

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

傳統軟件的交互節點是按鈕，Agent 軟件的交互節點是確認。用戶不需要每一步都參與，但關鍵判斷必須可審查。哪些步驟自動執行、哪些步驟必須用戶確認，這條分界線的設計是新課題

飛機自動執行高風險過程所以需要黑匣子，Agent 自動執行復雜任務同樣需要。Trace 記錄的不只是動作，還有上下文、判斷依據、工具調用和結果。沒有 Trace，Agent 進不了嚴肅業務場景

當然，在開發的過程中，很多東西也在發生顯著的變化

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

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

方法的產品化

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

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

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

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

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

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

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

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

OPC？NPC！

前段時間各地都出臺了 OPC（一人公司）的相關政策：一個人通過各種 AI 工具，能夠產生匹敵一個團隊的生產力，在這里：人提出目標，Agent 去執行。本質上，還是自動化的增強版

那么，下一代產品會從復雜系統轉向簡單的委托關系。信任會成為比功能更重要的體驗

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

再往遠看一步，如果 OPC 是 ok 的，那么為什么不做 NPC（零人公司），在這里，意圖本身也可能由系統生成。庫存數據異常，系統自己發起補貨任務。客戶流失風險升高，系統自己發起挽回動作。項目延期概率上升，系統自己調整資源。沒有人下達指令，系統根據數據、環境和目標函數自己判斷該做什么

到那個階段，Agent 的驅動力來自更高層的目標函數：增長目標、成本目標、風險目標、效率目標、服務質量目標。Agent 網絡圍繞這些目標持續生成任務、分配資源、執行動作、評估反饋。Agent 不再圍繞用戶請求運行，開始圍繞目標狀態運行

如果未來是一個人管理一群 Agent，那么他自然也可以是 Agent 之間自己發現問題、提出任務、互相調用、互相審計。人只在少數高風險、高責任的節點進入，定義系統為什么存在、什么不能做、什么代價不可接受

這時候權限問題會變得更尖銳。過去管的是 Agent 能不能發郵件、能不能改文件。未來還要管它能不能主動發現目標、主動創建任務、主動影響資源分配。Agent 治理，從執行權限升級到意圖權限

最終形態，可能是一個會自我生成任務的 Agent 執行網絡，用戶看不見頁面，甚至看不見任務提出的過程，看到的只是一個組織持續運行后的狀態變化

最后

寫到這里的時候，發現今天是 5月4號，青年節，的確是一個值得奮斗的時候

過去十五年，互聯網和軟件，在一個個行業的吞下，接下來被吞掉的，則是自己的舊形態