前段時間我去 QCon 北京全球軟體大會分享了一個專題：
AI 時代的新正規化：如何構建 AI 產品？
觀眾反響特別好，想著要不把分享的內容公開出來，所以整理了這篇文章。本篇內容是對我過去兩年時間，做了無數個 AI 產品 demo 的一個階段性的總結，主要聚焦這三個方面的經驗：
為什麼 AI 產品這麼難做？
提示詞工程被極大低估
AI 產品團隊如何構建
謹小認知，僅供參考。寫給所有 AI 路上的朋友們。
簡單自我介紹，我是 ONE2X AI 全棧工程師，AI 影片剪輯效果負責人。負責 ONE2X 的 Medeo（AI 影片剪輯工具）的影片自動化製作工作流全流程搭建、工具產品的設計及創新 AI 應用場景探索。
22 年 11 月 GPT 剛出後，就開始嘗試做各種各樣的 AI 產品，23 年年中畢設做的是 AI 情感陪伴、暑假在做企業知識庫 Chatbot 智慧客服、23 年年底到 24 年年中在大廠做低程式碼編排 AI 工具和智慧醫療、24 年年中到現在在 AI 創業工作做 AI 自動剪輯。途中還做過大大小小的 project，包括 AI 寫遺囑、AI Agent 做動畫等等……也算是積累了很多實操經驗了。
讓我們輕鬆的聊聊 AI 與產品
認知截止到 20250411
A Joke：先從一個笑話開始，你能看懂嗎？
如果你知道每一條背後的原因，那麼恭喜你上道了！
所以為什麼 AI 產品這麼難做？
AI 時代的產品和傳統的產品不一樣的是什麼？
基礎流程是什麼？
所有流程可列舉全部已知
流程的自動化的定義是什麼，什麼流程可以被 SOP 化，就可以做成產品。那 AI 產品，首先肯定是產品，其次它還會完成以前人類才能完成的某種任務。這個任務如果需要 AI 完成，那就發生了正規化轉移
你得幫使用者做出來這個任務。
舉個例子，Cursor
Cursor 是我認為 2024 年最好的 AI 產品
它解決了三端關係。
Cursor Team 解決了如下問題：
-
任務分級：根據給 AI 的執行許可權不同的不同可控顆粒度的任務
-
幫使用者完成了任務：每個任務 / 功能在使用者還沒來之前就已知該任務如何完成（Coding，且無論語言，無論專案）
-
互動方式：每個任務 / 功能與人協同的人機互動方式
尊重 prompt，同程式碼享受同等權利，需要 git diff
需要對 prompt 單獨進行版本管理
Prompt 也是程式碼，但有區別？
LLM 和函式很類似，它們都是實現某個“計算”的節點。
但它能提供比傳統函式能做的更多的事情，提供“智慧型別”計算。
它可以接受非結構化的資料，經過推理，輸出非結構化 / 結構化的資料。
Prompt 也是程式碼，如何測試……？
函式，我們在執行前，透過 IDE 或者單測即可完成功能正確性校驗。
LLM 怎麼測試呢？
如果你只是讓它完成傳統函式的任務，也很好測試，可以使用 function call 加上單測。
比如加法任務，只讓它輸出結果，可以做正確性校驗。
但大機率你讓 LLM 做的事情是非結構化的。
所以 Prompt 的好壞怎麼測？
使用 function call / Json mode 確保輸出格式不出錯
任何 LLM 相關的呼叫，都使用 pydantic 嚴格校驗
輸出內容，透過 batch evaluation 進行校驗。
模型的上限，還是取決於人對於結果的要求有多高。
Baseline 只是保證功能正常執行，上限在於“人”
模型可能比你想象中的更強，不要限制它的思考方向，思考內容，knowhow，把 prompt 當成一種容器，你只是為模型提供必要的資訊，而不是教它如何思考。
總結一下，Prompt 也是程式碼，所以要測試。
首先，不要發現模型做不對任務，就覺得它有問題。接下來以 Text2SQL 為例。
做產品的人需要知道這個任務完成本身需要什麼上下文，並且努力為模型提供出來。你並不需要那麼多 Prompt 技巧，而是努力為模型提供更多的“必要資訊”。
你會發現跟人很像。把它當成實習生，你也需要給實習生上下文。
對於大部分業務場景而言，你不需要“神級 Prompt”（如下圖），你需要的是對業務的熟悉程度。把業務 knowhow 沉澱成 Prompt。
一件事情上下文到底是啥？尋找 root 變數的過程。
Manus 畫的 AI Model Timeline
模型每天都在更新，我怎麼設計提示詞和架構？
模型更新之後，提示詞會不會失效了呢？
每個模型有什麼不同的脾性？
模型越來越智慧，未來還需要複雜的提示詞嗎？
……
Slow Down，別焦慮。
打不過就加入：用最好的模型的 API 建立應用。除非自己順手能訓練模型。
Flow Engineer：什麼時候拆分任務，什麼時候合併任務？
我的體感（純經驗，沒有資料支撐，knowledge 截至 20250321）
如果不知道用啥，就先試試 Claude
通用型別任務：Claude-3.5-Sonnet / Claude-3.7-Sonnet
強推理任務：Claude / Gemini 2.5 Pro
中文語言任務：DeepSeek
圖片多模態任務：Claude / Gemini / 階躍
影片多模態任務：Gemini
簡單任務：Gemini Flash （省錢）
中文 B 端本地任務：Qwen
可能的 Bad Case:
DeepSeek 指令遵循弱
Gemini flash 幻覺嚴重
……
當然 GPT4o 生圖很好！
“Flow Engineering” 是一個最近越來越受歡迎的術語。它第一次被提及作為術語是在 CodiumAI 關於 AlphaCodium 的論文中，他們在論文中使用流工程來產生關於編碼問題的最新結果。
推薦看一遍 Langgraph 的 ipynb examples
Flow 強調的是用整體系統設計去完成任務
多節點設計，每個節點去實現單一任務。
單一任務簡單可靠，一定在 LLM 可實現範圍之內。
當一個任務太難的時候，就拆成兩個任務去做。
好像有點像 Dify/Coze 的意思？
對，但不全對。不要忘了傳統程式碼的能效。
你並不需要全部節點都是 LLM，你也可以組合 function 和 LLM。
所以推薦使用 Dify/Coze 驗證原型，寫程式碼用 LangGraph 搭建實際應用。
當模型更新後，就合併任務。
在設計 Flow 的時候，不需要拘泥於最佳化一個節點的 LLM Prompt。
因為模型推理能力不夠，大機率三個月後就夠了。不需要過度設計。
用幾個小的 task 拆解後完成任務，等模型更新後把整個大任務交給新的模型。
總結一下，Prompt Engineer 的認知
Cursor 很厲害，也最先落地：
懂 AI 的本來就是程式設計師。團隊懂 Coding。
團隊知道如何拆解任務，每一個任務如何寫 Prompt 的 knowhow，團隊很清楚。
模型 Coding 能力已經階躍（Claude3.5） 文字模態 Coding 任務是最擅長的。但還有如此多的業務場景，等著創造。
AI 產品最後長成什麼樣子，已經是無人定義清楚的事情了。
只有當把所有的要素及其，做出一個 demo，你才知道這是什麼感覺的產品。
我做的大大小小的 demo
以前的開發模式，是產品、研發。現在可能變成了一個緊密的團隊一起調 prompt。
這是我在公司內部做的後臺，支援任何人追溯每次 LLM 呼叫，並且重新除錯 prompt。
最好是產品 / 全棧能自己除錯 prompt。
AI 產品需要緊密配合的團隊，一起設計架構。
Prompt 需要溝通能力，業務能力。程式碼需要研發能力。
Prompt + 程式碼是團隊之間才能做的事情。
一起創作。
我們正在見證新正規化的出現，很幸運。
有了 AI，才有了年輕人的機會，所以我非常感激能在這個時代能有這麼多有意思的事情。
謹小認知，僅供參考。
認知截止到 20250411
AICon 2025 強勢來襲，5 月上海站、6 月北京站，雙城聯動，全覽 AI 技術前沿和行業落地。大會聚焦技術與應用深度融合，匯聚 AI Agent、多模態、場景應用、大模型架構創新、智慧資料基建、AI 產品設計和出海策略等話題。即刻掃碼購票，一同探索 AI 應用邊界！