6位作者來自不同背景，比如有大廠工程師，也有獨立開發者，還有咨詢顧問。

但他們的共同之處，是過去一年里一直在大模型之上構建真實應用程序，而不只是炫酷的Demo演示，他們認為：

現在正是非機器學習工程師或科學家，也能把AI構建到產品中的時候。

在他們的一系列分享中，網友熱議的亮點包括但不限于：

-何時用長上下文、何時RAG、何時微調模型

多樣化輸出不止提高溫度，改變提示詞中示例的順序也影響結果
長上下文不會讓RAG過時
“實習生測試”：如果大學生能根據提示詞完成任務，說明比較完善了
每個大模型都有自己的偏好，Claude更喜歡XML格式，GPT系列更喜歡Markdown和JSON
如果靠提示詞已完成了90%的任務，微調可能就不值得投資
大模型當裁判評估結果可能起作用，但不是萬能的
……
總之，無論是大廠工程師、創業者還是參加個人開發者，都值得一看。

全程高能干貨分享
提示詞、RAG和微調都是改善大模型輸出結果的有效方法。

但是何時該用何種方法，還沒有定論。

作者們認為，需要根據具體的應用場景、任務需求、成本效益和性能目標來做出決策：

建議在開發新應用程序時從提示詞開始
需要大模型掌握新知識時優先使用RAG
當需要針對特定任務優化時再考慮微調
最后，他們還重點討論了對大模型應用的評估和監測，認為是應該貫穿開發全流程的重要環節。

提示詞篇
很多開發者都陷入了一個誤區：以為設計一個涵蓋一切的“終極提示詞”就能完美解決問題。

就像過去軟件開發中也有希望一個類或函數可以完成所有事情的誤區。

實際情況恰恰相反，隨著需求的復雜化，這樣的Prompt會越來越臃腫，性能反而每況愈下。

那么正確的做法是什么呢？提示詞也應該像代碼一樣保持簡潔，以會議記錄總結場景來說，可以分解為以下步驟：

將關鍵決策、待辦事項和執行者提取為結構化格式
檢查提取的詳細信息與原始會議記錄的一致性
從結構化詳情生成簡明摘要

通過拆分，每個提示詞都簡單、突出重點且易于理解，更重要的是接下來可以單獨迭代和評估每個提示詞。

比如思維鏈鼓勵AI在最終回答之前寫下思維過程，除了“一步一步思考”之外，還可以用一些技巧顯著降低幻覺。

還以會議記錄總結場景為例，迭代后的提示詞示例為：

- 首先，在草稿中列出關鍵決策、待辦事項和相關執行者。
- 然后，檢查草稿中的細節是否與文字記錄相符。
- 最后，根據要點合成簡潔的總結。

在提示詞方面，作者們還提出了更多具體經驗。

對于給大模型提供示例的上下文學習：

提示詞中的示例數量追求≥5（也不要害怕用上幾十個）。太少會讓模型過度遵循特定示例、損害泛化能力。
示例應該反映預期的輸入分布。比如做電影劇情總結，示例中不同類型電影的比例大致應與實踐中期望看到的相同。
不一定需要提供完整的輸入-輸出對。在許多情況下，只有輸出的示例就足夠了。
如果所用的大模型支持工具調用，則示例也應包含希望AI使用的工具。
對于結構化輸入輸出：

優化上下文結構，讓模型更容易理解和處理。單純打包一堆文件人類看著頭疼，AI看著也費勁。
只保留必要信息，像雕刻藝術家一樣剔除冗余、自相矛盾和格式化錯誤。
每個大模型都有自己的偏好，Claude更喜歡xml格式，GPT系列更喜歡Markdown和JSON。