AI產品的需求文檔怎麼寫，與傳統產品的PRD有何異同
整理版優先睇
AI產品PRD需從「人」轉向「模型」敍事，嵌入型與Agent型各有專屬架構
呢篇文章由一位正在做AI產品嘅產品經理撰寫，佢發現市面上冇一個像樣嘅AI產品PRD模板，傳統PRD嘅敍事結構已經唔適合而家嘅AI產品。作者認為，傳統產品圍繞「人」嘅需求同旅程，但AI產品引入大模型後，交互變成用戶-模型-產品三元，最大不確定性由人轉為模型。整體結論係：AI產品PRD需要從「人」嘅敍事轉向「模型」嘅敍事，並且要按產品類型（嵌入型 vs Agent型）採用唔同嘅框架。
具體嚟講，嵌入型AI產品可以沿用傳統PRD，只要額外增加AI引入可行性分析、提示詞設計同評估測試標準三個板塊。而Agent型產品就需要新增模型故事、Agent工作流程同提示詞設計三個板塊，圍繞模型嘅感知、規劃、行動嚟寫。作者仲用字節開源嘅deer-flow產品反推，整咗一份4萬+字嘅PRD模板，示範點樣將呢個框架應用到真實產品。呢篇文章唔單止釐清概念，仲提供具體做法同模板連結，對做AI產品嘅人好有幫助。
- 傳統PRD圍繞「人」嘅需求同旅程，但AI產品引入大模型後，最大不確定性由人轉為模型，PRD需轉向「模型」敍事。
- 嵌入型AI產品（如AI客服）只需在傳統PRD上加三個板塊：AI引入可行性分析、提示詞設計、評估標準。
- Agent型產品需新增模型故事、Agent工作流程、提示詞設計三個板塊，重點描寫模型點樣感知、規劃、行動。
- 作者用deer-flow實例反推，整咗一份4萬+字PRD模板，證明呢個框架可以落地。
- 做AI產品PRD時，可以從可行性分析、提示詞設計、評估標準入手，逐步消滅模型嘅不確定性。
DeerFlow 產品需求文檔模板
4萬+字完整PRD模板，根據作者框架反推嘅模擬文檔
傳統PRD點解唔夠用？
傳統產品PRD圍繞「人」嘅需求、故事同旅程嚟寫，假設用戶係最大不確定性。但引入AI大模型之後，交互變成用戶-模型-產品三元，模型反而成為更大嘅不確定因素。
用戶-模型-產品三元交互
作者指出，如果仲用10年前嘅思維框架去寫而家嘅AI產品，就好似用舊地圖揾新路，根本唔夠用。
AI產品嘅新敍事：由人轉向模型
作者將AI產品分為兩類：嵌入型（AI係固定環節，好似查天氣API）同Agent型（模型自主感知、規劃、行動）。兩者嘅PRD重心好唔同。
模型故事
模型旅程
對於Agent型產品，傳統嘅「用戶故事」同「用戶旅程」要淡化，取而代之係「模型故事」同「模型旅程」——即係描述模型點樣感知、規劃、行動同反饋。
嵌入型AI產品：三個額外板塊就夠
嵌入型產品（例如AI客服、AI寫作）可以保留傳統PRD框架，只係需要額外加三個板塊。
AI引入可行性分析
提示詞設計邏輯
評估和測試標準
- 1 AI引入可行性分析：從輸入彈性、規則可語言化水平、示例可得性、輸出彈性、重複度、容錯空間等維度評估。
- 2 提示詞設計邏輯：包括模型角色、核心挑戰、設計策略、完整提示詞同輸出約束。
- 3 評估和測試標準：定義輸入輸出嘅可容納彈性、不可控節點、重點維度同測試數據集要求。
呢三個板塊幫助產品經理具體評估引入AI嘅可行性同風險，確保模型輸出符合預期。
Agent型產品：新增模型故事同工作流程
Agent型產品先係真正嘅AI產品革命，產品經理嘅責任係盡最大可能消滅模型嘅不確定性。
模型故事
Agent工作流程
提示詞設計板塊
需要新增嘅三個板塊係：模型故事（描述模型點樣思考、規劃、執行同驗證）、Agent工作流程（用流程圖同時序圖呈現任務消解同數據傳遞）、提示詞設計（每個Agent一組提示詞，包括角色、挑戰、策略、提示詞同輸出控制）。
- 流程圖係外部視角：理清任務點樣一步步被消解。
- 時序圖係內部視角：數據點樣傳遞同加工。
- 提示詞設計圍繞角色、挑戰、策略、提示詞同輸出控制五個部分。
此外，仲需要配套評估標準同測試數據集，針對每個模型交互節點嘅潛在風險。
用deer-flow示範PRD模板
作者以字節開源嘅deer-flow產品為例，反向思考，從源碼反推功能，再模擬一份完整PRD。呢份文檔有4萬+字，涵蓋需求背景、產品定位、用戶故事、模型故事、Agent工作流程、提示詞設計等。
4萬+字PRD模板
上下文構建策略
作者提到，模型上下文需求嘅論述同呈現係一個未完成嘅環節，雖然喺每個模型故事最後加咗「點解需要呢啲」，但應該有更充分嘅構造策略。
整體嚟講，呢份模板為AI產品經理提供咗一個具體可參考嘅框架，尤其適合Agent型產品立項後嘅實施推進。
我哋仲用緊 10 年前嘅思維框架，去形容 10 年後嘅產品形態
「AI產品革命」都差唔多三年喇，仲未有個似樣嘅 PRD 模板出嚟，真係唔係幾掂。
呢篇文章，或者可以「救命」：
1. 講下傳統產品同 AI 產品嘅 PRD 有咩分別 2. AI 產品尤其是 Agent 產品嘅 PRD 應該點樣寫 3. 一個 4 萬+字嘅 AI 產品 PRD 模板
我喺搜索引擎搜「AI產品 PRD」，結果除咗人人都是產品經理社區嘅一篇文章之外，其他結果一係就係點用 AI 寫 PRD、一係就係 AI 生成冇乜資訊量嘅水稿。
傳統產品嘅 PRD 敍事結構已經唔係好適合而家流行嘅 AI 產品喇。
新舊 PRD 嘅敍事差異
傳統產品 PRD 嘅敍事係圍繞「人」嘅需求、「人」嘅故事、「人」嘅旅程嚟展開嘅。
透過論述什麼人在什麼場景下為達成什麼目標所以需要什麼功能嚟完成成個產品設計思路嘅呈現同要求陳述。
過去是用戶-產品呢種二元交互：我哋設計好一個產品，用戶同產品交互，攞到自己想要嘅結果。
所以我哋設計產品嘅時候，要諗用戶嘅各種可能性：
• 用戶唔㩒呢個掣嘅話，有冇其他選項？ • 用戶會唔會喺度輸入古靈精怪嘅內容？ • 呢個功能係咪用戶想要嘅嘢，定係偽需求？ • ……
所以傳統產品嘅 PRD 要先寫需求背景，再寫用戶故事，然後係用戶旅程，之後先係功能清單、說明。
「人」係成個產品設計過程中最大嘅不確定性，一切都係圍繞將「人」嘅行為抽樣出嚟。
但係產品引入 AI 大模型之後，「人」就唔再係唯一嘅不確定性喇，成個交互變成咗用戶-模型-產品三元。
要理解呢個新嘅「三元」，需要對產品拆解一下。
而家主流的 AI 產品都係模型嵌入型，即係大模型同傳統嘅第三方技術差唔多，當做一個 API 或者功能嵌入嚟，同查天氣差唔多。
但係，隨住模型越嚟越強，交互形態會越嚟越傾向「人同模型交互」，然後「模型同『產品』交互全程由代理人完成需求」嘅三元交互形態。
所以，傳統 PRD 裏面花好多筆墨描寫嘅「用戶故事」同「用戶旅程」可以淡化，取而代之嘅應該係「模型故事」同「模型旅程」：
• 模型故事用嚟形容大模型以 什麼角色，在什麼場景之下，為咗完成用戶的什麼目標，需要調用哪些程序獲取上下文；• 模型旅程用嚟形容大模型喺成個任務完成過程中點樣 感知、規劃、行動和反饋嘅一系列動作旅程。
成個產品裏面，唔確定因素同所有程式嘅主要服務對象變咗做大模型。
換句話講，對於 Agent 型產品，我哋 PRD 嘅主敍事需要變成「我哋點樣為模型提供服務，令佢可以更好咁服務用戶」。
新 PRD 嘅結構
嵌入型 AI 產品嘅 PRD
對於「嵌入型 AI 產品」，佢哋無非係以下兩種情況：
1. 老樹開新花：原本就可以正常運行嘅產品，而家將裏面某啲環節換成 AI 大模型嚟實現，希望有更好嘅交互體驗。典型好似「AI客服」呢類賦能型產品。 2. 久旱逢甘霖：由嚟已久嘅需求，傳統技術解決唔到，而家終於可以用 AI 大模型技術產品化解決。典型好似「AI寫作」呢類創作生成產品。
喺呢兩類產品裏面，AI 係產品實現邏輯中一個「寫死」嘅環節：佢接收一個固定嘅輸入、按要求畀出一個預期嘅輸出。
冇感知、冇決策、冇手腳，同查天氣嘅 API 接口冇任何分別。
呢種情況嘅產品設計中，PRD 完全可以採用傳統嘅敍事邏輯，只需要額外增加三個板塊就得：
1. AI引入可行性分析：點解要引入AI（輸入彈性定規則彈性）、AI 嘅可控性論述(規則語言化同上下文可得性同能力邊界) 2. 提示詞設計邏輯：模型角色、核心挑戰、設計策略嘅可行性分析、完整提示詞、輸出約束 3. 評估同測試標準：輸入輸出嘅可容納彈性空間、不可控節點、重點關注維度、評估測試數據集要求
關於“AI引入可行性分析」，我通常從輸入彈性、規則可語言化水平、示例可得性、輸出彈性、重複度、容錯空間幾個維度拆解。
頭兩個同 AI 最相關嘅兩個維度，決定咗可唔可以引入 AI，後面 4 個主要用嚟評估引入價值。
關於“提示詞設計」部分，「嵌入型」產品裏面大模型本質上同常規通過 API 調用第三方工具冇乜大分別，唔涉及模型嘅「自主性」，相對簡單。
呢個板塊，可以論述一下上下游情景、處理邏輯同模型嘅不可控風險：
1. 上下游情景，對應到大模型需要嘅輸入（上下文構建）同輸出（需唔需要結構化、格式） 2. 處理邏輯，即大模型扮演嘅角色同完成任務嘅方式 3. 不可控風險，例如模型有可能輸出非結構化，或者輸出 JSON 係帶住```json標識符號
實際上，一個優秀嘅提示詞，本身已經係當前節點嘅 PRD 喇。
提示詞貼出嚟大家就知呢度做緊乜、有咩風險，因為相同嘅資訊，你都應該透過提示詞話畀大模型知。
評估同測試標準，喺 Agent 類產品嘅 PRD 模版度有，呢度唔多講住。
Agent 型產品嘅 PRD
Agent 型產品先至撐得起真正嘅「AI 產品革命」，佢嘅底層思維係相信大模型可以，就算佢有數唔清嘅不確定性。
產品經理嘅職責就係盡最大可能消滅呢啲不確定性，釋放大模型嘅能量。
正如之前所講，我哋要好似過去梳理人嘅不確定性一樣，從模型需求、模型故事、模型作業流程等維度抽絲剝繭咁將所有潛在嘅問題揾出嚟。
逐個澄清，透過傳統技術同一輪一輪嘅提示詞優化，解決佢哋。
所以，返到 Agent 型產品嘅 PRD，我建議專門增加三個板塊：模型故事、Agent工作流程同 Agent 嘅提示詞設計。
跟住，我以字節開源嘅 deer-flow 產品做例子，逆向思考，返到產品立項嘅起點，用我哋以上嘅框架模擬一下呢款產品嘅 PRD。
Agent 產品 PRD 模版
先講明：
份文檔係根據 deer-flow 嘅開源代碼反推產品功能同交互，再喺呢個基礎上推演咗產品嘅目標用戶同需求痛點，然後再根據呢啲推演咗用戶故事同用戶旅程，進一步設計咗各項功能。
所以，文檔冇涵蓋原始產品嘅所有功能。當中嘅提示詞設計思路都係從功能需求反推嘅。完整提示詞係原始提示詞嘅中文翻譯。
如有雷同，請發offer。
文檔包含咗常規 PRD 嘅需求背景、產品定位、用戶故事，但冇整原型圖（畢竟人哋產品已經發布咗，再畫原型圖真係冇意思）。
就算係模擬嘅 PRD，都有 4 萬+字，冇辦法貼喺文章裏面，完整文檔嘅連結喺文末。
之前針對點解要增加新板塊嘅論述已經比較清楚，呢度唔再重複。
簡單串一下每個板塊嘅寫作思路：
• 模型故事板塊：形容模型喺收到用戶需求之後，點樣思考、規劃、執行同驗證嘅過程。 • Agent 工作流程設計板塊：形容單 Agent 執行任務或多 Agent 分工協作嘅過程，核心係任務目標點樣喺流程中被執行、各流程節點點樣傳遞數據。用流程圖同時序圖呈現： • 流程圖係外部視角：理清任務點樣一步步被解決 • 時序圖係內部視角：數據點樣傳遞、點樣加工 • 提示詞設計板塊：圍繞系統中嘅 Agent 設計，每個 Agent 一組提示詞，以角色、挑戰、策略、提示詞同輸出控制 5 個板塊呈現。 • 評估標準同測試數據集板塊：圍繞成個流程中所有已經 list 出嚟嘅模型不確定性組織物料，規則同測試數據對應每個 Agent 或模型交互節點中潛在嘅風險。
一啲缺陷：
• 模型上下文需求嘅論述同呈現：任何一個同模型交互嘅節點，都應該有充足嘅模型上下文構建策略論述，但我暫時仲未諗好將佢放喺 PRD 文檔嘅邊個板塊。我喺模型故事板塊每個模型故事最後加咗一個「點解需要呢啲」，初衷係解釋當前模型對 上下文嘅需求，但佢明顯應該有更充分嘅論述同構造策略。• 一個產品從構思到上線過程中一定會遇到大量被卡住嘅問題，其中大部分係邊做、邊發現、邊迭代嘅。但呢個 PRD 係從完全體倒推嘅，繞唔開「上帝視角」問題。我喺拆解嘅過程一旦完成咗「呢個實現太巧妙啦」嘅驚歎，就好難再扮呢個問題冇被發現、冇被解決，所以文檔中有好多「用 XX 工具處理」呢類表述。 • 呢份模擬 PRD 文檔更適合做立項後項目實施推進，立項前嘅場景引入 AI 可行性分析同引入價值分析冇寫。
組個局
咁冗長密集嘅文字，睇到呢度，我估你應該正在創造真正嘅 AI 產品。
我正計劃組織一個純 AI 產品嘅交流羣，如果你有以下共識，歡迎揾我：
希望一齊建立呢種交流氛圍
▪ 討論真正嘅工程問題（提示詞、上下文、工具…），而唔係「邊個 AI 可以畫原型圖」
▪ 大模型能力同邊界（幻覺、推理、上下文壓縮…），而唔係「仲未知 9.8 同 9.11 邊個大啊」
▪ 創新模型交互同體驗，而唔係「咪又係個 AI 瀏覽器」或者「爆裂啦」
為咗確保質量，需要你：
▪ 喺做 AI 大模型產品（可以獨立開發），而唔係只係使用、愛好、想學習
▪ 願意而且能夠交流、討論 AI 嘅應用經驗同心得，而唔係只係圍觀
▪ 理解大模型嘅基本原理同獨特價值，而唔係爆裂或垃圾嘅二元對立
▪ 唔捧殺唔貶低，理性咁基於工程同真實經驗 battle 具體問題
我可以提供：
▪ 每週固定分享一個 AI 項目嘅拆解
▪ 相對前沿同及時嘅 AI 行業資訊同產品體驗心得
▪ 仲算唔錯嘅工程經驗同提示詞功底
▪ 投入一定精力維護呢個羣
有興趣嘅朋友，帶一段簡單嘅介紹私我：zhangjiawxid
DeerFlow 產品需求文檔模板地址：https://bytesmore.feishu.cn/wiki/KP5ywyaKyiLmQrk3atrcIG2tnrz
我們仍在用 10 年前的思維框架，描述10年後的產品形態
“AI產品革命”都快三年了，還沒個像樣的 PRD 模板出來，實在不像樣。
這篇文章，或許可以“救命”：
1. 論述傳統產品與 AI 產品的 PRD 有何不同 2. AI 產品尤其是 Agent 產品的 PRD 應該怎麼寫 3. 一個 4 萬+字的 AI 產品 PRD 模板
我在搜索引擎搜索「AI產品 PRD」，結果中除了人人都是產品經理社區的一篇文章外，其他結果要麼是怎麼用 AI 寫 PRD 的、要麼是 AI 生成的沒有信息量的水稿。
傳統產品的 PRD 敍事結構已經不太適配當下熱門的 AI 產品了。
新舊 PRD 的敍事差異
傳統產品 PRD 的敍事是圍繞「人」的需求、「人」的故事、「人」的旅程展開的。
通過論述什麼人在什麼場景下為達成什麼目標所以需要什麼功能來完成整個產品設計思路的呈現和要求陳述。
過去是用戶-產品這樣的二元交互：我們設計好一個產品，用戶與產品交互，獲取自己想要的結果。
所以我們在設計產品的時候，要考慮用戶的種種可能性：
• 用戶不點這個按鈕的話，有其他選項麼？ • 用戶會不會在這裏輸入奇奇怪怪的內容？ • 這個功能是用戶想要的東西麼，偽需求？ • ……
所以傳統產品的 PRD 要先寫需求背景，再寫用戶故事，然後是用戶旅程，之後才是功能清單、說明。
「人」是整個產品設計過程中最大的不確定性，一切都圍繞把「人」的行為抽象出來。
但是產品引入 AI 大模型後，「人」不再是唯一的不確定性了，整個交互變成了用戶-模型-產品三元。
要理解這個新的“三元”，需要對產品進行一下拆解。
目前主流的 AI 產品都是模型嵌入型，即大模型與傳統的三方技術相當，作為一個 API 或者功能嵌入進來，跟查天氣差不多。
但是，隨着模型變得越來越強，交互形態會越來越傾向於“人與模型交互”，然後“模型與「產品」交互全程代理人完成需求”的三元交互形態。
所以，傳統 PRD 裏花大量筆墨描寫的“用戶故事”和“用戶旅程”可以淡化了，取而代之的應該是“模型故事”和“模型旅程”：
• 模型故事用來描述大模型以 什麼角色，在什麼場景下，為了完成用戶的什麼目標，需要調用哪些程序獲取上下文；• 模型旅程用來描述大模型在整個任務完成過程中如何 感知、規劃、行動和反饋的一系列動作旅程。
整個產品中，不確定因素和所有程序的主要服務對象變成了大模型。
換句話說，對於 Agent 型產品，我們 PRD 的主敍事需要變成“我們如何為模型提供服務，讓它能更好的服務用戶”。
新 PRD 的結構
嵌入型 AI 產品的 PRD
對於“嵌入型 AI 產品”，它們無非以下兩種情況：
1. 老樹開新花：原本就可以正常運行的產品，現在把其中的某些環節替換成 AI 大模型來實現，以期有更好的交互體驗。典型如“AI客服”類賦能型產品。 2. 久旱逢甘霖：由來已久的需求，傳統技術解決不了，現在終於可以用 AI 大模型技術產品化解決了。典型如“AI寫作”類創作生成產品。
在這兩類產品裏，AI 是產品實現邏輯中一個“寫死”的環節：它接收一個固定的輸入、按要求給出一個預期的輸出。
沒有感知、沒有決策、沒有手腳，跟查天氣的 API 接口沒有任何區別。
這種情況的產品設計中，PRD 完全可以採用傳統的敍事邏輯，只需要額外增加三個板塊即可：
1. AI引入可行性分析：為什麼引入AI（輸入彈性or規則彈性）、AI 的可控性論述(規則語言化&上下文可得性&能力邊界) 2. 提示詞設計邏輯：模型角色、核心挑戰、設計策略的可行性分析、完整提示詞、輸出約束 3. 評估和測試標準：輸入輸出的可容納彈性空間、不可控節點、重點關注維度、評估測試數據集要求
關於“AI引入可行性分析”，我一般從輸入彈性、規則可語言化水平、示例可得性、輸出彈性、重複度、容錯空間幾個維度拆解。
前兩個與 AI 最相關的兩個維度，決定了能不能引入 AI，後面 4 個主要用來評估引入價值。
關於“提示詞設計”部分，“嵌入型”產品裏大模型本質上跟常規通過 API 調用三方工具沒啥太大區別，不涉及到模型的“自主性”，相對簡單。
這個板塊，可以論述一下上下游情景、處理邏輯和模型的不可控風險：
1. 上下游情景，對應到大模型需要的輸入（上下文構建）和輸出（是否需要結構化、格式） 2. 處理邏輯，即大模型扮演的角色和完成任務的方式 3. 不可控風險，比如模型有可能輸出非結構化，或者輸出 JSON 是帶着```json標識符號
實際上，一個優秀的提示詞，本身已經是當前節點的 PRD 了。
提示詞貼出來大家也就知道這裏在幹嘛、有啥風險了，因為相同的信息，你也應該通過提示詞告知大模型。
評估和測試標準，在 Agent 類產品的 PRD 模版裏有，這先不贅述。
Agent 型產品的 PRD
Agent 型產品才能撐起真正的“AI 產品革命”，它的底層思維是相信大模型可以，即便它有數不清的不確定性。
產品經理的職責就是盡最大可能消滅這些不確定性，釋放大模型的能量。
如前所述，我們要像過去梳理人的不確定性一樣，從模型需求、模型故事、模型作業流程等維度抽絲剝繭的把所有潛在的問題找出來。
逐個澄清，通過傳統技術和一輪一輪的提示詞優化，解決它們。
所以，回到 Agent 型產品的 PRD，我建議專門增加三個板塊：模型故事、Agent工作流程和 Agent 的提示詞設計。
接下來，我以字節開源的 deer-flow 產品為例，反向思考，回到產品立項的起點，用我們以上的框架模擬一下這款產品的 PRD。
Agent 產品 PRD 模版
先說明：
文檔是根據 deer-flow 的開源代碼反推產品功能和交互，在此基礎上推演了產品的目標用戶和需求痛點，然後再基於此推演了用戶故事和用戶旅程，進一步設計了各項功能。
因此，文檔並沒有涵蓋原始產品的所有功能。其中的提示詞設計思路也是從功能需求反推的。完整提示詞為原始提示詞的中文翻譯。
如有雷同，請發offer。
文檔包含了常規 PRD 的需求背景、產品定位、用戶故事，但沒搞原型圖（畢竟人家產品都發布了，再畫原型圖實在沒意義）。
即便是模擬的 PRD，也有 4 萬+字，沒法貼在文章裏，完整文檔的連結在文末。
前面針對為什麼要增加新的板塊的論述已經比較清楚了，這裏就不再贅述了。
簡單串一下每一個板塊的撰寫思路：
• 模型故事板塊：描述模型在接收到用戶需求後，如何思考、規劃、執行和驗證的過程。 • Agent 工作流程設計板塊：描述單 Agent 執行任務或多 Agent 分工協作的過程，核心是任務目標如何在流程中被執行、各流程節點如何傳遞數據。使用流程圖和時序圖呈現： • 流程圖是外部視角：理清任務如何一步步被消解掉 • 時序圖是內部視角：數據如何傳遞、如何加工 • 提示詞設計板塊：圍繞系統中的 Agent 設計，每個 Agent 一個/一組提示詞，以角色、挑戰、策略、提示詞和輸出控制 5 個板塊呈現。 • 評估標準和測試數據集板塊：圍繞整個流程中所有已經 list 出來的模型不確定性組織物料，規則和測試數據對應每個 Agent 或模型交互節點中潛在的風險。
一些缺陷：
• 模型上下文需求的論述和呈現：任何一個與模型交互的節點，都應該有充足的模型上下文構建策略論述，但是我暫時還沒想好把它放在 PRD 文檔的哪個板塊。我在模型故事板塊每個模型故事最後增加了一個“為什麼需要這些”，初衷是解釋當前模型對 上下文的需求，但它顯然應該有更充分的論述和構造策略。• 一個產品從構思到上線過程中一定會遇到大量被卡主的問題，其中大部分是邊做、邊發現、邊迭代的。但是這個 PRD 是從完全體倒推的，繞不開“上帝視角”問題。我在拆解的過程一旦完成了“這個實現太巧妙了”的驚歎，就很難再假裝這個問題沒有被發現、被解決了，所以文檔中有很多“使用 XX 工具處理”這樣的表述。 • 這份模擬 PRD 文檔更適合作為立項後項目實施推進，立項前的場景引入 AI 可行性分析和引入價值分析沒寫。
組個局
這麼冗長密集的文字，能看到這裏，我猜你應該正在創造真正的 AI 產品。
我正在計劃組織一個純 AI 產品的交流羣，如果你有以下共識，歡迎建聯：
希望一起構建這樣的交流氛圍
▪ 討論真正的工程問題（提示詞、上下文、工具…），而不是“哪個 AI 可以畫原型圖”
▪ 大模型能力和邊界（幻覺、推理、上下文壓縮…），而不是“還是不知道 9.8 和 9.11 誰大啊”
▪ 創新模型交互和體驗，而不是“不就是個 AI 瀏覽器麼”或者“炸裂了”
為了確保質量，需要你：
▪ 在做 AI 大模型產品（可以獨立開發），而不只是使用、愛好、想學習
▪ 願意且能夠交流、討論 AI 的應用經驗和心得，而不只是圍觀
▪ 理解大模型的基本原理和獨特價值，而不是炸裂或垃圾的二元對立
▪ 不捧殺不貶低，理性的基於工程和真實經驗 battle 具體問題
我可以提供：
▪ 每週固定分享一個 AI 項目的拆解
▪ 相對前沿和及時的 AI 行業資訊和產品體驗心得
▪ 還算不錯的工程經驗和提示詞功底
▪ 投入一定精力維護這個羣
感興趣的夥伴，帶一段簡單的介紹私我：zhangjiawxid
DeerFlow 產品需求文檔模板地址：https://bytesmore.feishu.cn/wiki/KP5ywyaKyiLmQrk3atrcIG2tnrz