Software-3.0
一句話定義
Karpathy 對 LLM 時代軟體範式的命名：程式設計從直接寫 function，轉向寫 prompt、管理 context window、配置工具與指揮 AI 助理完成任務。
核心要點
三代軟體分工
| 版本 | 誰寫規則 | 核心材料 | 代表工作 |
|---|---|---|---|
| Software 1.0 | 人類工程師 | 程式碼 / 明確規則 | 寫 function、資料結構、控制流程 |
| Software 2.0 | 訓練流程 | 資料集 / 目標函數 / 模型參數 | 設計資料、loss、訓練與評估 |
| Software 3.0 | 人 + LLM agent | prompt / context / tool / eval | 寫 spec、管理上下文、讓 agent 生成與操作 |
本概念不是說傳統程式碼消失，而是說「人直接指定每一步」不再是唯一入口。很多任務會從「寫一個 app」轉成「把原始輸入交給前沿模型，讓模型直接理解、轉換、生成或操作」。
產品存在性測試
2026-05-18-Karpathy-Software-3-Agentic-Engineering 用 MenuGen 菜單 app 案例說明：若使用者把菜單照片直接丟給 Gemini 等多模態模型就能得到翻譯、圖片與建議，那原本為此包 API / UI 的 app 可能不該存在。
可用測試：
- 使用者是否能把原始輸入直接交給通用模型？
- 三句話內是否能拿到你 app 的主要輸出？
- 你的產品是否有模型本身沒有的資料、流程、權限、分發、信任或垂直驗證能力？
若答案偏否，產品可能只是薄封裝；若答案偏是，Software 3.0 反而讓以前成本太高的垂直工作流變得可行。
從 code 到 spec / context / verification
Software 3.0 下，工程師的價值不只在記 API 或手寫 boilerplate，而是：
- 判斷這件事是否值得做，以及是否需要獨立產品形態。
- 把模糊需求寫成 prompt、spec 與可操作任務。
- 用 Context-Engineering 提供 agent 正確的背景、程式碼、資料與限制。
- 用 LLM-Evaluation / 測試 / trace 驗證結果，而不是只看輸出像不像。
- 在高風險區域保留人的理解與決策責任。
與其他概念的關係
- 與 Prompt-Engineering：Software 3.0 把 prompting 提升為 programming 的一部分，但 prompt 只是起點，仍需要 context、tools 與 eval。
- 與 Context-Engineering：當 programming 轉向管理模型輸入，context window 的內容選擇就變成軟體設計的一部分。
- 與 Agentic-Workflow：agentic workflow 是 Software 3.0 的產品 / 系統落地形態之一。
- 與 Agentic-Engineering：Software 3.0 描述範式轉換；Agentic Engineering 描述專業工程師如何在此範式中設計可驗證、可回滾、可維護的工作環境。
- 與 Vibe-Coding：Vibe coding 是 Software 3.0 的低門檻入口；它拉高下限，但不保證工程品質。
- 與 行動引擎：當使用者用自然語言直接完成任務，很多 app 的 UI / workflow 可能被 action engine 或通用 agent 吃掉。
相關來源
- 2026-05-18-Karpathy-Software-3-Agentic-Engineering — Karpathy 訪談解析；提供 Software 1.0 / 2.0 / 3.0 分法、MenuGen 案例與產品存在性測試。
備註
本頁目前以二手訪談解析為主。若後續取得 Karpathy 原訪談或原始文章，應校準 Software 3.0 的正式定義與 MenuGen 案例原句。