《AI工程：大模型應用開發實戰》讀書筆記
整理版優先睇
AI 工程唔係調模型，而係建立評估、數據、架構、成本同反饋閉環嘅系統工程
呢篇文章係一位獨立開發者——《JingNote》《DueSight》《ShotZen》嘅作者——讀完《AI工程：大模型應用開發實戰》之後嘅讀書筆記。佢面對嘅問題係：模型能力進步咁快，點樣先可以建立一套唔會被工具淘汰嘅 AI 應用開發方法？佢唔係想追住「今日邊個模型最強」，而係想答幾個更現實嘅問題：呢個功能係咪真係需要 AI？AI 錯咗，用戶接唔接受？呢個能力係 demo 定係可以穩定交付？成本、延遲、私隱、評估點處理？大公司做到嘅時候，我憑咩仲可以生存？
佢嘅整體結論係：AI 產品最難嘅位唔係由 0 做到 60，而係由 60 做到 95。Demo 好容易，產品就好難。真正決定產品上唔上到線、穩唔穩定、賺唔到錢嘅，係評估、數據、架構、成本、延遲、反饋閉環同分發能力，而唔係模型本身。呢本書最值錢嘅地方係將 AI 應用開發由「玩模型」拉返去「做系統」，強調工具會過時，但底層問題——點解模型會幻覺、點解評估咁難、點解 demo 易產品難——唔會變。
作者將呢套方法論具體套用落自己嘅產品，提出咗五個重點：建立評估系統先過信模型、認清 demo 同產品嘅距離、AI 越核心容錯率越低、數據比 prompt 更接近長期資產、同埋提示工程只係起點。佢仲分享咗幾個反直覺嘅細節，例如最先進嘅模型唔一定最適合自己產品、AI 幻覺係生成機制嘅一部分而唔係 bug、同埋完全自動化唔應該係起點而係結果。
- 建立評估系統係先決條件：冇評估集，每次換 prompt 或模型都係主觀賭博，應該用 30 條真實樣本嘅小型評估集做 baseline。
- Demo 同產品嘅差距好大：一個月做到 80%，但由 80% 到 95% 可能要再花幾個月，真正消耗時間嘅係邊角問題、幻覺、延遲同異常輸入。
- AI 功能越核心，容錯率越低：早期產品應該將 AI 放喺「增強體驗」嘅位置，而唔係放喺核心路徑，等用戶信任建立先再考慮自動化。
- 數據比 prompt 更接近長期資產：Prompt 同 UI 都可以複製，但用戶數據、反饋數據同場景數據係真正可以沉澱落嚟嘅護城河。
- 提示工程只係起點，生產級 AI 應用仲需要評估、統計、工程、數據集管理同實驗追蹤，要將 prompt 放喺工程系統入面管理。
AI 工程係系統工程，唔係調模型
呢本書最大嘅價值係將 AI 應用開發由「玩模型」拉返去「做系統」。作者認為 AI 工程唔係訓練模型，而係利用已有嘅基礎模型嚟構建應用，就好似「用現成發動機造車」咁樣。你唔一定要識得鑄造每個零件，但一定要知道發動機嘅邊界、油耗、故障模式，同埋點樣同成個系統協作。
- 輸入：用戶要解決嘅問題
- 模型：完成某個具體任務
- 上下文：用戶數據、文檔、歷史記錄
- 評估：輸出係咪滿足要求
- 反饋：用戶係咪接受結果
- 成本：每次調用係咪可持續
- 監控：上線後係咪變差
傳統 ML 工程圍繞「開發 ML 模型」，AI 工程圍繞「利用已有模型」構建應用。呢個轉變好關鍵：你唔需要由頭訓練模型，但要更清楚模型嘅限制同風險。
評估同 RAG：最容易被低估嘅核心
喺 AI 工程入面，評估係最容易被低估、但最關鍵嘅部分。傳統軟件入面，函數輸出錯咗，測試可以發現。但 AI 輸出可能「睇落啱」，但事實錯、格式錯、語氣錯、成本高、延遲長、唔可以重現。所以評估唔係「呢個模型好唔好」，而係「呢個模型喺我嘅產品場景夠唔夠用」。
每個 AI 功能都應該寫 3 個核心評估標準：質量、成本、延遲，仲要建立一個 30 條真實樣本嘅小型評估集。
- 1 為每個 AI 功能寫 3 個核心評估標準：質量、成本、延遲。
- 2 建一個 30 條真實樣本嘅小型評估集。
- 3 每次改 prompt 或換模型，都跑一遍。
- 4 輸出結果分為：可用、需人工確認、不可用。
- 5 上線後收集用戶修改、撤銷、跳過行為，作為真實反饋。
RAG 嘅重點唔係「向量數據庫」，而係「揾唔揾得啱材料」。先收集 50 條真實問答，用 BM25 做 baseline，再試 embedding 係咪真係更好。
人在迴路同護城河：產品成熟度管理
作者認為「人在迴路」唔係保守，而係產品成熟度管理。正確路徑應該係：先輔助人，再部分自動化，最後先俾 AI 直接面對用戶。早期所有 AI 輸出應該默認可編輯、可撤銷，記錄用戶接受率，接受率夠高先考慮自動化。
唔好一開始就諗全自動化。AI 產品越關鍵，容錯率越低。例如《ShotZen》唔應該一開始就自動刪除截圖，而係推薦「可刪除截圖組」，俾用戶確認。
- 1 所有 AI 輸出默認可編輯、可撤銷。
- 2 記錄用戶係咪接受 AI 建議。
- 3 接受率低過 80%，繼續人工確認。
- 4 接受率超過 95%，考慮自動化部分低風險任務。
- 5 高風險動作保留最終確認，例如刪除、發送、扣費。
護城河通常來自三類：技術、數據同分發。獨立開發者更應該重視數據同垂直場景，避免只做「模型 wrapper」。
對我產品嘅 5 個啟示
- 建立評估系統先過信模型：俾《JingNote》嘅 AI 校正建立固定測試集，每次改 prompt 都跑一遍。
- Demo 容易，產品難：新功能唔好只做 happy path，要測試異常輸入、空數據、長文本、網絡失敗、模型失敗。
- AI 功能越核心，容錯率越低：將 AI 放喺「增強體驗」位置，等用戶信任建立先自動化。
- 數據比 prompt 更接近長期資產：記錄用戶修改 AI 輸出嘅地方，形成小型偏好數據集。
- 提示工程只係起點：prompt 要版本化，改動要有評估記錄，唔同模型要有對照實驗。
以後做 AI 產品，唔可以只問「模型做唔做到」，而要問「呢個能力能唔能夠被評估、被控制、被交付、俾用戶長期信任」。
經驗、反直覺點同被忽略嘅細節
最先進嘅模型唔一定最適合自己產品。模型選擇要睇成本、延遲、私隱、功能、控制權，而唔係排行榜第一。AI 幻覺唔係 bug，而係生成機制嘅一部分——模型本質上係概率生成，只要錯誤輸出概率唔係零，就有可能出現。
公開基準測試只能參考，唔可以迷信。數據污染會令模型喺 benchmark 表現好好，但實際能力未必強。自己產品嘅場景先係最終測試集。
成本同延遲唔係後期優化，而係產品設計嘅一部分。從第一天就要諗：邊啲請求可以緩存、邊啲任務可以異步、邊啲輸出可以降級。
完全自動化唔應該係起點，而係結果。早期產品應該做 AI 建議 → 人類確認 → 記錄反饋 → 逐步自動化。
呢本書對我嚟講最大嘅價值，唔係話畀我知又有啲乜嘢新工具出現，而係將 AI 應用開發由「玩模型」拉返去「做系統」。
AI 工程並唔係 set 幾個 prompt，亦都唔係接一個模型 API。佢更加似傳統軟件工程、ML 工程同產品工程嘅交叉地帶：模型只係核心組件之一，真正決定產品可唔可以上線、穩唔穩定、賺唔賺到錢嘅，係評估、數據、架構、成本、延遲、反饋閉環同分發能力。本書不斷強調：工具會過時，但底層問題唔會，好似點解模型會產生幻覺、點解評估咁難、點解 demo 容易但產品難、點解應用越關鍵就越需要人喺迴路。
一、呢本書真正想解決啲乜嘢問題
表面上，呢本書講嘅係點樣基於基礎模型構建 AI 應用。
但佢真正想解決嘅問題係：喺模型能力快速變化嘅時代，工程師要點樣建立一套唔會被工具淘汰嘅 AI 應用開發方法論。
呢樣嘢同我而家好有關係。因為我做 JingNote、DueSight、ShotZen，本質上唔係喺度追「今日邊個模型最強」，而係要回答幾個更現實嘅問題：
- • 呢個功能係咪真係需要 AI？
- • AI 錯咗，用戶接唔接受？
- • 呢個能力係 demo，定係可以穩定交付？
- • 成本、延遲、私隱、評估點樣處理？
- • 大公司都做到嘅時候，我憑乜嘢仲可以生存？
如果只帶走一個判斷：AI 產品嘅難點唔係由 0 到 60，而係由 60 到 95。demo 好易，產品好難。
二、核心概念
1. AI 工程
呢個係乜嘢
AI 工程唔係訓練模型，而係利用現有基礎模型嚟構建應用。
傳統 ML 工程更加似「造引擎」，AI 工程更加似「用現成引擎造車」。你唔一定要知道每個零件點樣鑄造，但你一定要知道引擎嘅邊界、油耗、故障模式，同埋佢點樣同成架車嘅系統合作。
本書講得好清楚：傳統 ML 工程圍繞「開發 ML 模型」，AI 工程圍繞「利用現有模型」嚟構建應用。
用喺咩場景
適合：
- • 快速將模型能力接入產品
- • 做 AI 寫作、語音轉文字、圖片理解、知識問答、程式碼生成
- • 基於 API 或開源模型做產品驗證
- • 獨立開發者快速構建可用工具
唔適合：
- • 業務本身冇 AI 必要，只係為咗蹭熱點
- • 冇明確用戶問題，只係想「加個 AI」
- • 對穩定性要求極高，但冇評估同人工兜底
- • 成本結構唔清楚，叫得越多蝕得越多
怎麼用
我應該將 AI 工程睇成一套產品系統，而唔係一個模型調用。
最小系統應該包括：
- • 輸入：用戶要解決嘅問題
- • 模型：完成某個具體任務
- • 上下文：用戶數據、文檔、歷史記錄
- • 評估：輸出係咪符合要求
- • 反饋：用戶接唔接受結果
- • 成本：每次調用可唔可持續
- • 監控：上線之後會唔會變差
實踐步驟
- 1. 畀每個 AI 功能寫一句話定義：佢幫用戶完成啲乜嘢動作。
- 2. 寫低失敗場景：模型錯咗會點樣。
- 3. 為功能設計 10 條測試樣本。
- 4. 記錄每次輸出嘅質量、耗時、成本。
- 5. 上線前先判斷：呢個係產品能力，定係只係演示效果。
2. 評估
呢個係乜嘢
評估係 AI 工程裏面最容易被低估、但最關鍵嘅部分。
傳統軟件入面，函數輸出錯咗，測試可以發現。AI 應用入面，輸出可能「睇落啱」，但事實錯、格式錯、語氣錯、成本高、延遲長、冇得重現。
所以評估唔係「模型好唔好」，而係「呢個模型喺我嘅產品場景裏面夠唔夠用」。
本書強調，評估用嚟選擇模型、做基準測試、判斷係咪可以部署，並喺生產環境中持續發現問題。
用喺咩場景
適合：
- • 選擇 GPT、Claude、Gemini、開源模型
- • 比較唔同 prompt
- • 判斷 RAG 輸出係咪忠實於資料
- • 判斷 AI 寫作助手係咪符合風格
- • 判斷語音轉文字後嘅 AI 校正係咪真係改善咗質量
唔適合：
- • 只睇公開排行榜
- • 只憑幾次主觀體驗判斷模型
- • 冇業務指標，只評「感覺唔錯」
- • 測試集太少，只覆蓋理想輸入
怎麼用
對我嘅產品嚟講，評估應該由「用戶係咪得到更好結果」出發，而唔係由「模型分數高唔高」出發。
例如 JingNote 嘅 AI 校正，唔應該只睇文本係咪更通順，仲要睇：
- • 有冇刪除原意
- • 有冇錯誤補全
- • 有冇將口語整理成可讀筆記
- • 處理速度係咪夠快
- • 免費額度下成本係咪可控
ShotZen 如果做 AI 圖片分類，都唔可以只睇分類準確率，仲要睇：
- • 係咪減少用戶整理截圖嘅時間
- • 係咪誤刪重要截圖
- • 係咪令用戶信任推薦結果
實踐步驟
- 1. 為每個 AI 功能寫 3 個核心評估標準：質量、成本、延遲。
- 2. 建立一個有 30 條真實樣本嘅小型評估集。
- 3. 每次改 prompt 或換模型，都跑一次。
- 4. 輸出結果分為：可用、需要人工確認、不可用。
- 5. 上線後收集用戶修改、撤銷、跳過嘅行為，作為真實反饋。
3. RAG
呢個係乜嘢
RAG 係畀模型外加記憶。
模型本身好似一個讀過好多書但唔一定記得最新內容嘅人。RAG 嘅作用係：先從外部資料庫裏面揾到相關內容，再叫模型根據呢啲內容回答。
佢解決兩個問題：
- • 模型知識過時
- • 模型容易亂講嘢
本書提到，RAG 最初係為咗解決上下文長度限制，後來被廣泛用嚟提升資訊利用效率、回應質量並降低成本。RAG 嘅成敗好大程度上取決於檢索器嘅質量。
用喺咩場景
適合：
- • 知識庫問答
- • 讀書筆記系統
- • 個人資料庫助手
- • App 內說明文檔問答
- • 技術文檔查詢
- • 用戶歷史內容總結
唔適合：
- • 問題本身唔依賴外部資料
- • 數據質量差、冇結構化
- • 用戶需要強推理而唔係查資料
- • 檢索結果本身唔可靠
怎麼用
RAG 嘅重點唔係「向量數據庫」，而係「可唔可以揾啱材料」。
對我嚟講更加實際嘅用法：
- • JingNote：用戶歷史語音筆記可以做成長期記憶
- • 讀書筆記：將 Kindle / 微信讀書嘅筆記變成個人知識庫
- • 技術 Blog：檢索我過去嘅文章，生成統一風格嘅新內容
- • App 客服：根據私隱政策、訂閲說明、FAQ 自動回答
實踐步驟
- 1. 先收集 50 條真實問答，而唔係先揀向量數據庫。
- 2. 將資料按場景拆成細塊：功能說明、錯誤處理、用戶案例、FAQ。
- 3. 用 BM25 / 簡單關鍵詞檢索先做 baseline。
- 4. 再測試 embedding 檢索係咪真係更好。
- 5. 每次回答都保留引用來源，避免模型自由發揮。
4. 人喺迴路
呢個係乜嘢
人喺迴路唔係保守，而係產品成熟度管理。
AI 唔係一開始就應該完全自動化。正確路徑應該係：先輔助人，再部分自動化，最後先畀 AI 直接面對用戶。
本書提到「爬行-行路-奔跑」：早期一定要有人參與；中期 AI 可以服務內部員工；成熟之後先提高自動化程度，甚至直接服務外部用戶。
用喺咩場景
適合：
- • 輸出錯誤會帶嚟損失
- • 用戶信任仲未建立
- • AI 能力唔穩定
- • 產品啱啱上線，缺少真實數據
- • 需要逐步積累評估樣本
唔適合：
- • 低風險、可以撤銷嘅任務
- • 用戶只係想要靈感、草稿、建議
- • 人工審核成本高過錯誤成本
怎麼用
對我啲 App 嚟講，最現實嘅路徑係：
- • 先叫 AI 生成建議
- • 用戶確認之後先執行
- • 記錄用戶接受率
- • 接受率夠高之後，再考慮自動化
例如 ShotZen 唔應該一開始就自動刪除截圖，而係先推薦「可以刪除嘅截圖組」，等用戶確認。JingNote 唔應該直接改寫用戶嘅筆記，而係提供「原文 + AI 整理版」，等用戶自己揀。
實踐步驟
- 1. 所有 AI 輸出預設係可以編輯、可以撤銷。
- 2. 記錄用戶係咪接受 AI 建議。
- 3. 接受率低過 80%，繼續用人工確認。
- 4. 接受率超過 95%，先考慮自動化部分低風險任務。
- 5. 高風險動作保留最終確認，例如刪除、發送、扣費。
5. 護城河：技術、數據、分發
呢個係乜嘢
AI 產品越嚟越易做，亦都越嚟越易被複製。
如果一個產品只係「調用模型 + 套殼 UI」，佢好快會變成大公司嘅一個功能。本書提到，AI 領域嘅競爭優勢通常嚟自三類：技術、數據同分發。基礎模型時代，大多數公司嘅核心技術相似，大公司嘅分發優勢更加強，所以獨立開發者更加應該重視數據同垂直場景。
用喺咩場景
適合用嚟判斷：
- • 呢個 App 值唔值得做
- • 做完之後係咪容易被複製
- • 有冇長期積累
- • 可唔可以形成數據反饋閉環
- • 有冇渠道接觸用戶
唔適合：
- • 早期過度追求「護城河」
- • 仲未驗證需求，就設計複雜壁壘
- • 用技術複雜度冒充競爭力
怎麼用
我而家做產品，要避免只做「model wrapper」。
更好嘅方向係：
- • 用 AI 提升核心體驗，但唔好將 AI 當成唯一賣點
- • 透過用戶數據同使用習慣持續優化產品
- • 用寫作、Twitter、Reddit、App Store ASO 建立分發
- • 做夠窄嘅場景，令大公司唔願意優先做
ShotZen 嘅護城河唔應該係「AI 清理截圖」，而係：
- • 對截圖場景理解更深
- • 刪除決策更可信
- • App Store 截圖、設計、增長閉環更強
- • 用戶整理行為數據不斷優化推薦
實踐步驟
- 1. 每個 App 寫一句「如果蘋果聽日做咗類似功能，我仲剩低啲乜」
- 2. 揾出一個大公司忽略嘅小場景。
- 3. 將用戶每次選擇、跳過、刪除嘅行為記錄成產品反饋。
- 4. 建立內容分發渠道，而唔係淨係依賴 App Store 搜索。
- 5. 每星期檢查：我係喺度積累資產，定係只係喺度堆功能。
三、對我真正有用嘅 5 個點
1. 唔好迷信模型，先建立評估系統
Insight
模型更新得好快，但我嘅產品唔可以靠「覺得呢個模型聰明啲」嚟迭代。冇評估集，每次換 prompt、換模型、換供應商，都係主觀賭博。
我嘅理解
我以前好易將 AI 能力當成一個黑盒：試幾次效果唔錯，就覺得可以上線。但真正嘅產品唔係一次輸出好，而係一百次、一千次都穩定喺可接受範圍內。
點樣用喺我身上
開發工作：
- • 幫 JingNote 嘅 AI 校正建立固定測試集
- • 幫 ShotZen 嘅圖片分類建立真實截圖樣本集
- • 每次修改 prompt 都跑一次小評估
副業：
- • App 嘅 AI 功能唔可以只寫「powered by AI」
- • 要能夠證明：用咗 AI 之後，用戶更快、更省心、更願意俾錢
生活：
- • 以後判斷一個工具，唔只問「強唔強」，仲要問「佢喺我嘅場景入面穩唔穩定」
2. Demo 易，產品難
Insight
AI 最吸引人嘅地方係 demo 效果令人驚艷。最危險嘅地方都係 demo 效果令人驚艷。
本書提到，好多團隊一個月做到 80%，但由 80% 到 95% 又花咗幾個月。真正消耗時間嘅，係邊角問題、幻覺、延遲、成本、異常輸入。
我嘅理解
呢句話對獨立開發者尤其重要。因為我最易俾一個靚 demo 推住走，以為「呢個方向做得過」。但用戶唔會為 demo 俾錢，用戶係為穩定解決問題俾錢。
點樣用喺我身上
開發工作：
- • 新功能先做 happy path，但唔可以停喺嗰度
- • 最少要測試異常輸入、空數據、長文本、網絡失敗、模型失敗
- • 做 App 嗰陣，發佈前要問：呢個功能俾真實用戶亂用時仲識唔識做
- • 唔好將「我本地 run 得通」當成「可以賺錢」
生活：
- • 降低對短期興奮感嘅信任
- • 每個想法先問：維護成本係啲乜
3. AI 功能越核心，容錯率越低
Insight
如果 AI 只係輔助，用戶可以容忍小錯誤。如果 AI 係核心功能，用戶就會要求更高嘅準確性同可靠性。本書用 Face ID 呢類例子說明：AI 越關鍵，用戶對錯誤越敏感。
我嘅理解
呢樣嘢對產品設計好重要。唔係所有 AI 功能都應該放喺核心路徑入面。早期產品更加適合將 AI 放喺「增強體驗」嘅位置，而唔係令成個產品嘅成敗都依賴模型一次輸出。
點樣用喺我身上
開發工作：
- • JingNote 嘅核心價值係快速記錄，AI 校正係增強
- • DueSight 唔一定要夾硬加 AI，除非可以明顯減少用戶操作
- • ShotZen 嘅核心價值係整理截圖，AI 推薦係輔助
副業：
- • 營銷文案可以講 AI，但產品結構唔可以完全押注 AI
- • 先做用戶可控嘅 AI，再做自動化 AI
生活：
- • 做決策嗰陣，將不可控因素放喺輔助位，唔好放喺主路徑
4. 數據比 prompt 更接近長期資產
Insight
Prompt 可以複製，UI 可以複製，模型 API 都可以複製。真正可能沉澱落嚟嘅，係用戶數據、反饋數據、場景數據同分發渠道。
我嘅理解
我做獨立 App，唔可以只追求「呢個 prompt 寫得好強」。更加重要嘅係產品每運行一日，係咪可以積累一啲人哋冇嘅嘢。
點樣用喺我身上
開發工作：
- • 記錄用戶修改 AI 輸出嘅地方
- • 記錄用戶接受 / 拒絕 AI 建議嘅行為
- • 形成小型偏好數據集
副業：
- • 寫作都係數據資產
- • 推文、Blog、用戶反饋、App Store 評論，都應該入到產品迭代系統
生活：
- • 任何長期系統，都要留低可以覆盤嘅數據
- • 冇記錄，就冇複利效應
5. 提示工程有用，但只識提示工程唔夠
Insight
提示工程係最容易開始嘅模型適配方式，唔需要改變模型權重。但本書都提醒：問題唔係提示工程冇用，而係只識提示工程唔夠。生產級 AI 應用仲需要評估、統計、工程、數據集管理同實驗追蹤。
我嘅理解
呢句話對而家嘅 AI 熱潮好有價值。好多人將 prompt 當成全部，但真正做到產品嘅人，會將 prompt 放入工程系統裏面管理。
點樣用喺我身上
開發工作：
- • prompt 要版本化
- • prompt 改動要有評估記錄
- • 唔同模型要有對照實驗
副業：
- • 可以將自己嘅 prompt 系統變成內容資產
- • 但唔可以將產品只建立喺 prompt 上面
生活：
- • 唔好停喺「識用工具」
- • 要將工具變成流程，將流程變成系統
四、經驗、反直覺點同被忽略嘅細節
1. 最先進嘅模型，唔一定最適合我嘅產品
模型選擇唔係排行榜第一就搞掂。真實產品仲要睇成本、延遲、私隱、功能、控制權、裝置端部署。本書提到，模型選擇需要先剔除硬屬性唔符合需求嘅模型，再根據公開資訊收窄範圍，最後用自己嘅評估 pipeline 測試。
對我嚟講，JingNote 如果強調私隱同低成本，可能本地模型、細模型、混合架構比最強 API 更加適合。
2. AI 幻覺唔係 bug，而係生成機制嘅一部分
語言模型本質上係概率生成。只要某啲錯誤輸出嘅概率唔係零，佢就有可能出現。更加麻煩嘅係，模型一旦做錯假設，後面可能會繼續作嘢嚟圓返個錯誤。
呢樣嘢代表我唔可以只靠「叫模型認真啲」嚟解決幻覺。產品上一定要做引用、檢索、約束輸出、人工確認、失敗兜底。
3. 公開基準測試只能參考，唔可以迷信
數據污染會令模型喺基準測試上表現好好，但實際能力唔一定強。一個模型考試高分，可能只係訓練嗰陣見過類似題目。
呢樣嘢對我揀模型好有提醒：唔好直接將榜單成績當成產品決策依據。我嘅 App 場景先至係最終測試集。
4. 成本同延遲唔係後期優化，而係產品設計嘅一部分
TTFT、TPOT、總延遲呢啲指標睇落似工程嘢，但其實直接影響用戶體驗。用戶開 App 等 5 秒，可能就走咗。
AI 產品由第一日就要考慮：
- • 邊啲請求可以 cache
- • 邊啲任務可以異步
- • 邊啲場景一定要快
- • 邊啲輸出可以降級
- • 邊啲模型可以用細模型代替
5. 「AI 自動化」唔係越自動越好
獨立開發者好容易想像一個全自動系統，但用戶真正需要嘅係可信、可控、可以撤銷。
早期產品更加應該做：
- • AI 建議
- • 人類確認
- • 記錄反饋
- • 再逐步自動化
完全自動化應該係結果，唔應該係起點。
五、一句話總結
呢本書真正改變我嘅地方係：以後做 AI 產品，我唔可以只問「模型做唔做到」，而係要問「呢個能力可唔可以被評估、被控制、被交付、被用戶長期信任」。
2026.05.05 10:39
滬·趙巷
📌 聲明：本文由 AI 輔助完成
這本書對我最大的價值，不是告訴我又出現了哪些新工具，而是把 AI 應用開發從“玩模型”拉回到“做系統”。
AI 工程不是調幾個 prompt，也不是接一個模型 API。它更像傳統軟件工程、ML 工程、產品工程的交叉地帶：模型只是核心組件之一，真正決定產品能不能上線、能不能穩定、能不能賺錢的，是評估、數據、架構、成本、延遲、反饋閉環和分發能力。書裏反覆強調：工具會過時，但底層問題不會，比如模型為什麼會幻覺、為什麼評估困難、為什麼 demo 容易產品難、為什麼應用越關鍵越需要人在迴路。
一、這本書真正想解決什麼問題
表面上，這本書講的是如何基於基礎模型構建 AI 應用。
但它真正想解決的問題是：在模型能力快速變化的時代，工程師如何建立一套不被工具淘汰的 AI 應用開發方法論。
這和我現在很有關。因為我做 JingNote、DueSight、ShotZen，本質上不是在追逐“今天哪個模型最強”，而是在回答幾個更現實的問題：
- • 這個功能是否真的需要 AI？
- • AI 錯了，用戶能不能接受？
- • 這個能力是 demo，還是可以穩定交付？
- • 成本、延遲、隱私、評估怎麼處理？
- • 大公司也能做時，我憑什麼還能活下來？
如果只帶走一個判斷：AI 產品的難點不在 0 到 60，而在 60 到 95。demo 很容易，產品很難。
二、核心概念
1. AI 工程
這是什麼
AI 工程不是訓練模型，而是利用已有基礎模型構建應用。
傳統 ML 工程更像“造發動機”，AI 工程更像“用現成發動機造車”。你不一定需要知道每個零件怎麼鑄造，但你必須知道發動機的邊界、油耗、故障模式，以及它和整車系統如何協作。
書中說得很清楚：傳統 ML 工程圍繞“開發 ML 模型”，AI 工程圍繞“利用已有模型”構建應用。
用在什麼場景
適合：
- • 快速把模型能力接入產品
- • 做 AI 寫作、語音轉文字、圖片理解、知識問答、代碼生成
- • 基於 API 或開源模型做產品驗證
- • 獨立開發者快速構建可用工具
不適合：
- • 業務本身沒有 AI 必要，只是為了蹭熱點
- • 沒有明確用戶問題，只想“加個 AI”
- • 對穩定性要求極高，但沒有評估和人工兜底
- • 成本結構不清楚，調用越多虧越多
怎麼用
我應該把 AI 工程看成一套產品系統，而不是一個模型調用。
最小系統應該包括：
- • 輸入：用戶要解決的問題
- • 模型：完成某個具體任務
- • 上下文：用戶數據、文檔、歷史記錄
- • 評估：輸出是否滿足要求
- • 反饋：用戶是否接受結果
- • 成本：每次調用是否可持續
- • 監控：上線後是否變差
實踐步驟
- 1. 給每個 AI 功能寫一句話定義：它幫用戶完成什麼動作。
- 2. 寫出失敗場景：模型錯了會怎樣。
- 3. 為功能設計 10 條測試樣本。
- 4. 記錄每次輸出質量、耗時、成本。
- 5. 上線前先判斷：這是產品能力，還是隻是演示效果。
2. 評估
這是什麼
評估是 AI 工程裏最容易被低估、但最關鍵的部分。
傳統軟件裏，函數輸出錯了，測試能發現。AI 應用裏，輸出可能“看起來對”，但事實錯、格式錯、語氣錯、成本高、延遲長、不可復現。
所以評估不是“模型好不好”，而是“這個模型在我的產品場景裏夠不夠用”。
書中強調，評估用於選擇模型、做基準測試、判斷是否能部署，並在生產環境中持續發現問題。
用在什麼場景
適合：
- • 選擇 GPT、Claude、Gemini、開源模型
- • 比較不同 prompt
- • 判斷 RAG 輸出是否忠實於資料
- • 判斷 AI 寫作助手是否符合風格
- • 判斷語音轉文字後的 AI 校正是否真的改善了質量
不適合：
- • 只看公開排行榜
- • 只憑幾次主觀體驗判斷模型
- • 沒有業務指標，只評“感覺不錯”
- • 測試集太少，只覆蓋理想輸入
怎麼用
對我的產品，評估應該從“用戶是否得到更好結果”出發，而不是從“模型分數高不高”出發。
比如 JingNote 的 AI 校正，不應該只看文本是否更通順，還要看：
- • 有沒有刪除原意
- • 有沒有錯誤補全
- • 有沒有把口語整理成可讀筆記
- • 處理速度是否足夠快
- • 免費額度下成本是否可控
ShotZen 如果做 AI 圖片分類，也不能只看分類準確率，還要看：
- • 是否減少用戶整理截圖的時間
- • 是否誤刪重要截圖
- • 是否能讓用戶信任推薦結果
實踐步驟
- 1. 為每個 AI 功能寫 3 個核心評估標準：質量、成本、延遲。
- 2. 建一個 30 條真實樣本的小型評估集。
- 3. 每次改 prompt 或換模型，都跑一遍。
- 4. 輸出結果分為：可用、需人工確認、不可用。
- 5. 上線後收集用戶修改、撤銷、跳過行為，作為真實反饋。
3. RAG
這是什麼
RAG 是給模型外接記憶。
模型本身像一個讀過很多書但不一定記得最新內容的人。RAG 的作用是：先從外部資料庫裏找到相關內容，再讓模型基於這些內容回答。
它解決兩個問題：
- • 模型知識過時
- • 模型容易胡說
書中提到，RAG 最初是為了解決上下文長度限制，後來被廣泛用於提升信息利用效率、響應質量並降低成本。RAG 的成敗很大程度取決於檢索器質量。
用在什麼場景
適合：
- • 知識庫問答
- • 讀書筆記系統
- • 個人資料庫助手
- • App 內幫助文檔問答
- • 技術文檔查詢
- • 用戶歷史內容總結
不適合：
- • 問題本身不依賴外部資料
- • 數據質量差、沒有結構化
- • 用戶需要強推理而不是查資料
- • 檢索結果本身不可靠
怎麼用
RAG 的重點不是“向量數據庫”，而是“能不能找對材料”。
對我更實際的用法：
- • JingNote：用戶歷史語音筆記可以作為長期記憶
- • 讀書筆記：把 Kindle / 微信讀書筆記變成個人知識庫
- • 技術博客：檢索我過去文章，生成統一風格的新內容
- • App 客服：基於隱私政策、訂閲說明、FAQ 自動回答
實踐步驟
- 1. 先收集 50 條真實問答，而不是先選向量數據庫。
- 2. 把資料按場景拆塊：功能說明、錯誤處理、用戶案例、FAQ。
- 3. 用 BM25 / 簡單關鍵詞檢索先做 baseline。
- 4. 再測試 embedding 檢索是否真的更好。
- 5. 每次回答都保留引用來源，避免模型自由發揮。
4. 人在迴路
這是什麼
人在迴路不是保守，而是產品成熟度管理。
AI 不是一開始就應該完全自動化。正確路徑應該是：先輔助人，再部分自動化，最後才讓 AI 直接面對用戶。
書中提到“爬行-行走-奔跑”：早期必須有人蔘與；中期 AI 可以服務內部員工；成熟後才提高自動化程度，甚至直接服務外部用戶。
用在什麼場景
適合：
- • 輸出錯誤會帶來損失
- • 用戶信任還沒建立
- • AI 能力不穩定
- • 產品剛上線，缺少真實數據
- • 需要逐步積累評估樣本
不適合：
- • 低風險、可撤銷的任務
- • 用戶只是要靈感、草稿、建議
- • 人工審核成本高於錯誤成本
怎麼用
對我的 App，最現實的路徑是：
- • 先讓 AI 生成建議
- • 用戶確認後執行
- • 記錄用戶接受率
- • 接受率足夠高後，再考慮自動化
比如 ShotZen 不應該一開始就自動刪除截圖，而是先推薦“可刪除截圖組”，讓用戶確認。JingNote 不應該直接重寫用戶筆記，而是提供“原文 + AI 整理版”，讓用戶選擇。
實踐步驟
- 1. 所有 AI 輸出默認可編輯、可撤銷。
- 2. 記錄用戶是否接受 AI 建議。
- 3. 接受率低於 80%，繼續人工確認。
- 4. 接受率超過 95%，考慮自動化部分低風險任務。
- 5. 對高風險動作保留最終確認，比如刪除、發送、扣費。
5. 護城河：技術、數據、分發
這是什麼
AI 產品越來越容易做，也越來越容易被複制。
如果一個產品只是“調用模型 + 套殼 UI”，它很快會變成大公司的一個功能。書中提到，AI 領域的競爭優勢通常來自三類：技術、數據和分發。基礎模型時代，大多數公司的核心技術相似，大公司的分發優勢更強，因此獨立開發者更應該重視數據和垂直場景。
用在什麼場景
適合用來判斷：
- • 這個 App 值不值得做
- • 做完後是否容易被複制
- • 是否有長期積累
- • 是否能形成數據反饋閉環
- • 是否有渠道觸達用戶
不適合：
- • 早期過度追求“護城河”
- • 還沒驗證需求，就設計複雜壁壘
- • 用技術複雜度冒充競爭力
怎麼用
我現在做產品，要避免只做“模型 wrapper”。
更好的方向是：
- • 用 AI 提升核心體驗，但不把 AI 當唯一賣點
- • 通過用戶數據和使用習慣持續優化產品
- • 用寫作、Twitter、Reddit、App Store ASO 建立分發
- • 做足夠窄的場景，讓大公司不願意優先做
ShotZen 的護城河不應該是“AI 清理截圖”，而是：
- • 對截圖場景理解更深
- • 刪除決策更可信
- • App Store 截圖、設計、增長閉環更強
- • 用戶整理行為數據不斷優化推薦
實踐步驟
- 1. 每個 App 寫一句“如果蘋果明天做了類似功能，我還剩什麼”。
- 2. 找出一個大公司忽略的小場景。
- 3. 把用戶每次選擇、跳過、刪除行為記錄成產品反饋。
- 4. 建立內容分發渠道，而不是隻依賴 App Store 搜索。
- 5. 每週檢查：我是在積累資產，還是隻是在堆功能。
三、對我真正有用的 5 個點
1. 不要迷信模型，先建立評估系統
Insight
模型更新很快，但我的產品不能靠“感覺這個模型更聰明”來迭代。沒有評估集，每次換 prompt、換模型、換供應商，都是主觀賭博。
我的理解
我以前容易把 AI 能力當成一個黑盒：試幾次效果不錯，就覺得可以上線。但真正的產品不是一次輸出好，而是一百次、一千次都穩定在可接受範圍內。
如何用在我身上
開發工作：
- • 給 JingNote 的 AI 校正建立固定測試集
- • 給 ShotZen 的圖片分類建立真實截圖樣本集
- • 每次修改 prompt 都跑一遍小評估
副業：
- • App 的 AI 功能不能只寫“powered by AI”
- • 要能證明：用了 AI 後，用戶更快、更省心、更願意付費
生活：
- • 以後判斷一個工具，不只問“強不強”，還要問“它在我的場景裏穩定嗎”
2. Demo 容易，產品難
Insight
AI 最迷人的地方是 demo 效果驚豔。最危險的地方也是 demo 效果驚豔。
書裏提到，很多團隊一個月做到 80%，但從 80% 到 95% 又花了幾個月。真正消耗時間的，是邊角問題、幻覺、延遲、成本、異常輸入。
我的理解
這句話對獨立開發者尤其重要。因為我最容易被一個漂亮 demo 推着走，以為“這個方向能做”。但用戶不會為 demo 付費，用戶為穩定解決問題付費。
如何用在我身上
開發工作：
- • 新功能先做 happy path，但不能停在那裏
- • 至少測試異常輸入、空數據、長文本、網絡失敗、模型失敗
- • 做 App 時，發佈前要問：這個功能在真實用戶亂用時還能不能工作
- • 不要把“我本地跑通了”當成“可以賺錢了”
生活：
- • 降低對短期興奮感的信任
- • 每個想法先問：維護成本是什麼
3. AI 功能越核心，容錯率越低
Insight
如果 AI 只是輔助，用戶可以容忍小錯誤。如果 AI 是核心功能，用戶就會要求更高的準確性和可靠性。書裏用 Face ID 這類例子說明：AI 越關鍵，用戶對錯誤越敏感。
我的理解
這對產品設計很重要。不是所有 AI 功能都應該放在核心路徑裏。早期產品更適合把 AI 放在“增強體驗”的位置，而不是讓整個產品成敗都依賴模型一次輸出。
如何用在我身上
開發工作：
- • JingNote 的核心價值是快速記錄，AI 校正是增強
- • DueSight 不一定要強行加 AI，除非能明顯減少用戶操作
- • ShotZen 的核心價值是整理截圖，AI 推薦是輔助
副業：
- • 營銷文案可以說 AI，但產品結構不能完全押注 AI
- • 先做用戶可控的 AI，再做自動化 AI
生活：
- • 做決策時，把不可控因素放在輔助位，不要放在主路徑
4. 數據比 prompt 更接近長期資產
Insight
Prompt 可以複製，UI 可以複製，模型 API 也可以複製。真正可能沉澱下來的，是用戶數據、反饋數據、場景數據和分發渠道。
我的理解
我做獨立 App，不能只追求“這個 prompt 寫得很強”。更重要的是產品每運行一天，是否能積累一點別人沒有的東西。
如何用在我身上
開發工作：
- • 記錄用戶修改 AI 輸出的地方
- • 記錄用戶接受 / 拒絕 AI 建議的行為
- • 形成小型偏好數據集
副業：
- • 寫作也是數據資產
- • 推文、博客、用戶反饋、App Store 評論，都應該進入產品迭代系統
生活：
- • 任何長期系統，都要留下可覆盤的數據
- • 沒有記錄，就沒有複利
5. 提示工程有用，但只會提示工程不夠
Insight
提示工程是最容易開始的模型適配方式，不需要改變模型權重。但書裏也提醒：問題不是提示工程沒用，而是隻懂提示工程不夠。生產級 AI 應用還需要評估、統計、工程、數據集管理和實驗追蹤。
我的理解
這句話對現在的 AI 熱潮很有價值。很多人把 prompt 當成全部，但真正能做出產品的人，會把 prompt 放進工程系統裏管理。
如何用在我身上
開發工作：
- • prompt 要版本化
- • prompt 改動要有評估記錄
- • 不同模型要有對照實驗
副業：
- • 可以把自己的 prompt 系統變成內容資產
- • 但不能把產品只建立在 prompt 上
生活：
- • 不要停在“會用工具”
- • 要把工具變成流程，把流程變成系統
四、經驗、反直覺點和被忽略的細節
1. 最先進的模型，不一定最適合我的產品
模型選擇不是排行榜第一就完事。真實產品還要看成本、延遲、隱私、功能、控制權、設備端部署。書中提到，模型選擇需要先剔除硬屬性不符合需求的模型，再基於公開信息縮小範圍，最後用自己的評估流水線測試。
對我來說，JingNote 如果強調隱私和低成本，可能本地模型、小模型、混合架構比最強 API 更適合。
2. AI 幻覺不是 bug，而是生成機制的一部分
語言模型本質上是概率生成。只要某些錯誤輸出概率不為零，它就可能出現。更麻煩的是，模型一旦做出錯誤假設，後面可能繼續編造內容來圓這個錯誤。
這意味着我不能只靠“讓模型認真一點”解決幻覺。產品上必須做引用、檢索、約束輸出、人工確認、失敗兜底。
3. 公開基準測試只能參考，不能迷信
數據污染會讓模型在基準測試上表現很好，但實際能力不一定強。一個模型考試高分，可能只是訓練時見過類似題。
這對我選擇模型很有提醒：不要直接把榜單成績當成產品決策依據。我的 App 場景才是最終測試集。
4. 成本和延遲不是後期優化，而是產品設計的一部分
TTFT、TPOT、總延遲這些指標看起來偏工程，但其實直接影響用戶體驗。用戶打開 App 等 5 秒，可能就走了。
AI 產品從第一天就要考慮：
- • 哪些請求可以緩存
- • 哪些任務可以異步
- • 哪些場景必須快
- • 哪些輸出可以降級
- • 哪些模型可以用小模型替代
5. “AI 自動化”不是越自動越好
獨立開發者容易想象一個全自動系統，但用戶真正需要的是可信、可控、可撤銷。
早期產品更應該做：
- • AI 建議
- • 人類確認
- • 記錄反饋
- • 再逐步自動化
完全自動化應該是結果，不應該是起點。
五、一句話總結
這本書真正改變我的地方是：以後做 AI 產品，我不能只問“模型能不能做到”，而要問“這個能力能不能被評估、被控制、被交付、被用戶長期信任”。
2026.05.05 10:39
滬·趙巷
📌 聲明：本文由 AI 輔助完成