命題一 · 互聯網
連接
資訊匹配、改變生產關係；索引與分發流量；機器給人資料，由人決策。
→
命題一 · AI
計算
智能供給、改變生產力；獲取、訓練與生成資料；人給機器目標與資料，由機器決策／執行。
Agent 產品范式創新的
十個命題
李建忠｜奇點智能研究院／CSDN。這不是一張「如何加上 AI 功能」的清單，而是一套從產品底層邏輯、工程方法、互動入口，到指標、護城河與商業模式的全棧重寫。
01→10
主線可以濃縮成一句：當智能從「功能」變成可持續工作的勞動系統，產品經理設計的對象就不再只是介面與流程，而是任務、環境、能力與結果。
The map
十個命題，其實是四層系統
前五題重寫「產品是什麼」，六到八題重寫「價值如何被衡量與交易」，九、十題則追問 Agent 的能力上限與智能本質。以下卡片依命題編號重建，串起產品、工程、價值與能力邊界。
01連接 → 計算底層邏輯02工具 → 結果產品價值03流程 → 任務產品設計04App → Agent人機入口05軟體 → 光譜產品形態06時長 → 完成指標體系07網絡 → 能力產品護城河08許可 → 結果商業模式09模型 → AgentScaling10推理 ↔ 匹配智能本質
十題不是彼此獨立的趨勢預測，而是一條因果鏈：底層從連接轉向計算 → 價值從工具轉向結果 → 設計單位變成任務 → Agent 成為入口 → 指標、護城河與收費方式自然跟著改寫。
Layer 1 · Product logic
產品的第一個斷裂：從分發資訊，變成供給智能
互聯網的核心問題是「誰與誰、什麼與什麼可以被連接」；AI 的核心問題則是「什麼活動可以被計算」。這個差異決定了產品價值不能只停在更好的工具。
Proposition 02
不要再只交付「能做事的工具」，而要交付做完的結果。
提供工具
IDE 不會寫代碼、Office 不會寫文檔、Photoshop 不會修圖、CRM 不會銷售；完成責任仍落在人身上。
→
交付結果
AI Coding 寫代碼、AI Office 產文檔、AI Photoshop 完成修圖、AI CRM 找到與轉化客戶。
AI 時代的產品經理不是單純的功能設計者，而是「智能勞動系統」的設計者。
這會把 PM 的問題從「使用者怎麼點」改成「系統怎麼對結果負責、失敗時怎麼恢復、何時需要人接手」。
這會把 PM 的問題從「使用者怎麼點」改成「系統怎麼對結果負責、失敗時怎麼恢復、何時需要人接手」。
Layer 2 · Agent engineering
設計單位從頁面流程，轉成可駕馭的任務系統
當產品承諾結果，介面順不順只是其中一層。真正的設計對象是：任務如何被拆解、上下文如何被供給、工具如何被限制、反饋如何進入下一輪。
P
Prompt Engineering
把需求說清楚；定義角色、目標、輸出與約束。
C
Context Engineering
管理 Agent 在當下真正「看見」的資訊。投影片把核心定義為注意力：不是資料越多越好，而是需要的資料在需要的時刻進入。
H
Harness Engineering
用知識、行動、反饋三個迴圈駕馭 Agent；工具、技能、評估與協作共同形成運行邊界。
L
Loop Engineering
設定目標 → 規劃任務 → 執行行動 → 驗證任務 → 交付成果，使一次回答升級為可持續閉環。
Proposition 04
Agent 會成為第一入口，App 退到下游
互動重構
從「人找功能」到「目標找能力」
傳統軟體把功能裝進菜單與頁面；Agent 接住自然語言目標，再調度下游工具與服務。
UI 重構
從固定界面到生成式 UI
應用服務化、App 不再孤立、無需預先定義所有結構化 UI；介面可以隨任務生成。
01
工具 Tools
Agent 能安全呼叫的 API、資料與系統能力。
02
技能 Skills
可重用的程序、SOP、策略與專業操作。
03
環境 Environment
權限、狀態、資源與可觀測性共同構成工作空間。
Proposition 05
傳統軟體不會瞬間消失，而會走向一條新光譜
傳統軟體
確定性計算、固定資料與預設流程，適合穩定且可規格化的任務。
柔性軟體
核心仍有確定架構，但可由模型理解意圖、生成內容與調整路徑。
即時軟體
由 Agent 或大眾以自然語言即時「黑盒創造」，追求大規模、個性化與低成本。
「App 會不會消失」不是二選一。高風險、強合規、低變動的核心交易仍需要確定性軟體；需求長尾、個人化、低頻但高價值的工作，更可能被 Agent 與即時軟體吃掉。
Layer 3 · Value & economy
當產品交付結果，衡量、護城河與收費都要一起換
仍用 DAU、停留時長或功能採用率衡量 Agent，很可能獎勵錯誤行為：好的 Agent 也許讓人更少停留，但更快完成高價值任務。
Token / FLOPs
產品消耗多少智能計算，而不只是承接多少流量。
單任務價值
完成一次任務，替使用者創造或節省多少價值。
完成任務數
從「使用多久」改看「真正做完多少」。
指標體系要從用戶時長轉向任務完成。
實務上還應把完成率與品質、重試成本、人工接管率、時間節省及風險事件綁在一起，避免模型用「看似完成」換取漂亮數字。
實務上還應把完成率與品質、重試成本、人工接管率、時間節省及風險事件綁在一起，避免模型用「看似完成」換取漂亮數字。
Proposition 07
護城河不只來自網絡效應，而是能力飛輪
記憶
技能
工具
評估
反饋
每次任務不只產生結果，也應留下可被下一次利用的狀態：更準確的使用者記憶、更成熟的 Skill、更合適的工具選擇、更可靠的評估器與可操作反饋。
真正的護城河不是「接了哪個模型」，而是專有任務資料、評估基準、使用者信任、工作流嵌入深度，以及能否把回饋變成可驗證的能力改善。
Proposition 08
商業模式從廣告／許可，走向結果／訂閱
互聯網與傳統軟體
- 廣告
- 功能許可 License
- 交易佣金
Agent
- 結果付費
- Token／用量訂閱
- 交易佣金
講者指出「內容被 AI 免費抓取／訓練」不可持續，AI 需要為內容付費；這代表 Agent 經濟也必須解決資料與內容供給者的價值分配。
Layer 4 · Capability frontier
最後兩題：Agent 的上限，與「智能」到底是什麼
前八題談如何做產品，九、十題則提醒：能力曲線還沒定型，而且「能產生正確答案」不等於我們已經知道系統用什麼機制得到它。
× N
協作數量
串行廣度：從單一 Agent 到多 Agent 協作。
min→mo
運行時長
時間廣度：從數分鐘任務延伸到天、月級持續工作。
× D
迭代深度
反饋優化：透過多輪驗證與修正提升結果。
Scaling 不是免費午餐。協作者越多，協調成本與責任歸屬越複雜；時間越長，狀態漂移與權限風險越大；迭代越深，也更需要可靠評估器來阻止錯誤自我強化。
Proposition 10
Agent 是真的在邏輯推理，還是做了極其有效的模式匹配？
投影片提出的觀察
自然語言不只是簡單概率；模型能跨語言泛化、把語言映射到抽象概念，也呈現並非純記憶式的推理能力。
講者的務實落點
「邏輯推理」與「模式匹配」可以視為不同需求；即使機制不是人類式推理，只要模式匹配足夠有效，仍可能產生巨大產品價值。
對產品經理而言，最安全的做法不是替模型做哲學定性，而是把可接受的行為邊界、證據、評估、失敗恢復與人類監督做成產品的一部分。
Karen's review checklist
把十個命題落到下一次產品評審
如果要把這場演講轉成實際決策，可以在每個 Agent 產品提案上依序問以下問題。
先定義「可計算」的工作
不要從聊天框或模型功能出發；先找出原本由人判斷、轉換、搜尋、規劃或操作，現在能被智能供給改寫的工作。
把價值寫成可驗收的結果
使用者付費買到的是什麼完成狀態？什麼算失敗、部分完成、需要接管？
補齊 Context、Harness 與 Loop
資料是否在正確時刻可用？工具權限是否最小化？是否有評估、重試、回滾與人工介入？
用任務經濟取代流量經濟
同時追蹤完成品質、時間節省、單任務價值、智能成本與風險，而不是只看 DAU／時長。
設計能累積的能力飛輪
每次任務留下什麼記憶、Skill、評估資料或工作流資產？這些資產能否被驗證地改善下一次？
最後才決定形態與定價
它應該是確定性軟體、柔性軟體還是即時軟體？適合功能訂閱、用量、結果付費或佣金？
資料邊界：本頁已逐張核對 38 張現場簡報照片。所附 28:24 錄音亦已完整轉錄，但內容實際是另一場 Agent 度量／實習生框架演講，並非本場；為避免錯誤嫁接，本頁沒有引用該錄音。正式講題與署名依封面投影片確認，未替講者臆造未出現在素材中的職稱。投影片提到的 Cloudflare「未來 Agent 流量可能超過今天互聯網 1000 倍」屬投影片轉述的趨勢判斷，因此未當成已驗證事實使用。
Audio deep dive
Podcast｜從十個命題到產品決策
NotebookLM 繁體中文深度對談
雙人對談串起產品、工程、指標、護城河、定價與 Agent 能力邊界。
雙人對談 · 繁體中文 · 20:30