作者 | 寧晨然

前段時間我去 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 產品這么難做？

讓我們輕松的聊聊 AI 與產品

認知截止到 20250411

A Joke：先從一個笑話開始，你能看懂嗎？

如果你知道每一條背后的原因，那么恭喜你上道了！

所以為什么 AI 產品這么難做？

AI 時代的產品和傳統的產品不一樣的是什么？

基礎流程是什么？

所有流程可枚舉全部已知

流程的自動化的定義是什么，什么流程可以被 SOP 化，就可以做成產品。那 AI 產品，首先肯定是產品，其次它還會完成以前人類才能完成的某種任務。這個任務如果需要 AI 完成，那就發生了范式轉移

你得幫用戶做出來這個任務。

舉個例子，Cursor

Cursor 是我認為 2024 年最好的 AI 產品

它解決了三端關系。

Cursor Team 解決了如下問題：

• 任務分級：根據給 AI 的執行權限不同的不同可控顆粒度的任務

• 幫用戶完成了任務：每個任務 / 功能在用戶還沒來之前就已知該任務如何完成（Coding，且無論語言，無論項目）

• 交互方式：每個任務 / 功能與人協同的人機交互方式

提示詞工程被極大低估

認知一：Prompt 也是代碼，所以要測試。

尊重 prompt，同代碼享受同等權利，需要 git diff

需要對 prompt 單獨進行版本管理

Prompt 也是代碼，但有區別？

LLM 和函數很類似，它們都是實現某個“計算”的節點。

但它能提供比傳統函數能做的更多的事情，提供“智慧類型”計算。

它可以接受非結構化的數據，經過推理，輸出非結構化 / 結構化的數據。

Prompt 也是代碼，如何測試……？

函數，我們在運行前，通過 IDE 或者單測即可完成功能正確性校驗。

LLM 怎么測試呢？

如果你只是讓它完成傳統函數的任務，也很好測試，可以使用 function call 加上單測。

比如加法任務，只讓它輸出結果，可以做正確性校驗。

但大概率你讓 LLM 做的事情是非結構化的。

所以 Prompt 的好壞怎么測？

一、格式正確性

使用 function call / Json mode 確保輸出格式不出錯

任何 LLM 相關的調用，都使用 pydantic 嚴格校驗

二、功能 Baseline

輸出內容，通過 batch evaluation 進行校驗。

三、人工評測結果

模型的上限，還是取決于人對于結果的要求有多高。

Baseline 只是保證功能正常運行，上限在于“人”

四、放權

模型可能比你想象中的更強，不要限制它的思考方向，思考內容，knowhow，把 prompt 當成一種容器，你只是為模型提供必要的信息，而不是教它如何思考。

總結一下，Prompt 也是代碼，所以要測試。

認知二：AI 產品就是基于

“給模型提供上下文”出發開始的

首先，不要發現模型做不對任務，就覺得它有問題。接下來以 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 Engineer

“Flow Engineering” 是一個最近越來越受歡迎的術語。它第一次被提及作為術語是在 CodiumAI 關于 AlphaCodium 的論文中，他們在論文中使用流工程來產生關于編碼問題的最新結果。

推薦看一遍Langgraph的 ipynb examples

Flow 強調的是用整體系統設計去完成任務

多節點設計，每個節點去實現單一任務。

單一任務簡單可靠，一定在 LLM 可實現范圍之內。

當一個任務太難的時候，就拆成兩個任務去做。

好像有點像 Dify/Coze 的意思？

對，但不全對。不要忘了傳統代碼的能效。

你并不需要全部節點都是 LLM，你也可以組合 function 和 LLM。

所以推薦使用 Dify/Coze 驗證原型，寫代碼用 LangGraph 搭建實際應用。

當模型更新后，就合并任務。

在設計 Flow 的時候，不需要拘泥于優化一個節點的 LLM Prompt。

因為模型推理能力不夠，大概率三個月后就夠了。不需要過度設計。

用幾個小的 task 拆解后完成任務，等模型更新后把整個大任務交給新的模型。

總結一下，Prompt Engineer 的認知

AI 產品團隊如何構建

認知一，首先你得成為“創作者”

Cursor 很厲害，也最先落地：

懂 AI 的本來就是程序員。團隊懂 Coding。

團隊知道如何拆解任務，每一個任務如何寫 Prompt 的 knowhow，團隊很清楚。

模型 Coding 能力已經階躍（Claude3.5） 文本模態 Coding 任務是最擅長的。但還有如此多的業務場景，等著創造。

認知二，快速做出 Demo 最重要

AI 產品最后長成什么樣子，已經是無人定義清楚的事情了。

只有當把所有的要素及其，做出一個 demo，你才知道這是什么感覺的產品。

我做的大大小小的 demo

認知三，產品 / 開發的界限模糊

以前的開發模式，是產品、研發。現在可能變成了一個緊密的團隊一起調 prompt。

這是我在公司內部做的后臺，支持任何人追溯每次 LLM 調用，并且重新調試 prompt。

最好是產品 / 全棧能自己調試 prompt。

AI 產品需要緊密配合的團隊，一起設計架構。

Prompt 需要溝通能力，業務能力。代碼需要研發能力。

Prompt + 代碼是團隊之間才能做的事情。

一起創作。

我們正在見證新范式的出現，很幸運。

有了 AI，才有了年輕人的機會，所以我非常感激能在這個時代能有這么多有意思的事情。

謹小認知，僅供參考。

認知截止到 20250411