技能 llm-app-patterns
📦

llm-app-patterns

安全

建構生產級 LLM 應用程式

建構 LLM 應用程式需要應對複雜的架構決策。此技能提供經過實戰驗證的模式,適用於 RAG 流程、代理系統和生產營運。

支援: Claude Codex Code(CC)
🥉 73 青銅
1

下載技能 ZIP

2

在 Claude 中上傳

前往 設定 → 功能 → 技能 → 上傳技能

3

開啟並開始使用

測試它

正在使用「llm-app-patterns」。 使用者詢問:公司的退款政策是什麼?

預期結果:

  • 從向量資料庫中檢索相關政策文件
  • 基於檢索的上下文生成答案,並附上來源引用
  • 回傳包含信心分數和文件參考的回應

正在使用「llm-app-patterns」。 使用者詢問:規劃一個關於氣候變遷影響的研究專案

預期結果:

  • 建立包含以下步驟的計畫:收集資料、分析趨勢、識別來源、起草報告
  • 透過工具呼叫依序執行每個步驟
  • 將研究結果整合成綜合性的研究大綱

安全審計

安全
v1 • 2/25/2026

This skill is a documentation file containing educational content about LLM application patterns. All static analysis findings are false positives caused by markdown formatting. The backticks flagged are code block delimiters and ASCII art borders, not shell command execution. URLs are documentation references, not active network calls. Code examples like hashlib.sha256 are illustrative and use secure algorithms. No executable code or security risks detected.

1
已掃描檔案
763
分析行數
0
發現項
1
審計總數
未發現安全問題
審計者: claude

品質評分

38
架構
100
可維護性
87
內容
50
社群
100
安全
83
規範符合性

你能建構什麼

RAG 知識庫

使用混合搜尋和上下文壓縮,建構基於文件內容的問答系統。

代理任務自動化

建立多步驟代理,使用 ReAct 或 Plan-and-Execute 模式進行搜尋、計算和資訊整合。

LLM 生產監控

實作 LLM 應用程式的可觀測性,包含指標追蹤、分散式追蹤和評估框架。

試試這些提示

基本 RAG 提示
Answer the user's question based ONLY on the following context. If the context doesn't contain enough information, say you don't have enough information.

Context:
{context}

Question: {question}

Answer:
ReAct 代理提示
You are an AI assistant that can use tools to answer questions.

Available tools:
{tools_description}

Use this format:
Thought: [your reasoning about what to do next]
Action: [tool_name(arguments)]
Observation: [tool result]
... (repeat as needed)
Thought: I have enough information to answer
Final Answer: [your response]

Question: {question}
具備範例的 Few-Shot 提示
Input: {example1_input}
Output: {example1_output}

Input: {example2_input}
Output: {example2_output}

Input: {user_input}
Output:
研究用的提示鏈
Step 1 (Research): Research the topic: {input}
Step 2 (Analyze): Analyze these findings: {research}
Step 3 (Summarize): Summarize this analysis in 3 bullet points: {analysis}

最佳實務

  • 使用結合語意和關鍵字匹配的混合搜尋,以提升檢索準確性
  • 針對確定性提示實作快取,以降低延遲和成本
  • 追蹤關鍵指標如延遲、Token 使用量和使用者滿意度,以持續改進

避免

  • 使用固定大小分塊而不考慮文件結構,這會破壞上下文
  • 跳過評估和監控,導致無法偵測品質下降
  • 當主要 LLM 供應商發生中斷時,未實作備援策略

常見問題

RAG 和微調之間有什麼區別?
RAG 在查詢時檢索相關文件並將其作為上下文提供,使模型能夠存取最新資訊而無需重新訓練。微調在訓練資料上調整模型權重,更適合學習風格或格式,但無法在訓練後新增新知識。
如何在不同的代理架構之間做選擇?
對於需要工具使用的互動式多步驟推理,使用 ReAct。對於結構化 API 整合,使用函式呼叫。對於需要預先規劃的複雜任務,使用 Plan-and-Execute。當不同子任務需要專業知識時,使用多代理系統。
我應該為生產環境選擇什麼向量資料庫?
對於大規模的受管服務,使用 Pinecone。對於具備 GraphQL 的自託管方案,使用 Weaviate。對於現有的 PostgreSQL 基礎設施,使用 pgvector。對於原型開發,為了簡單性使用 ChromaDB。
我如何降低 LLM API 成本?
針對類似查詢實作語意快取,對簡單任務使用較小的模型,優化提示長度,設定適當的溫度(對於可快取回應設為 0),並在主要模型受到速率限制時使用備援模型。
我應該為 LLM 應用程式追蹤哪些指標?
追蹤效能指標(延遲、每秒 Token 數)、品質指標(使用者滿意度、任務完成率)、成本指標(每次請求成本、快取命中率)和可靠性指標(錯誤率、超時率)。
我如何在 RAG 系統中處理幻覺?
當上下文不足時,指示模型說「我不知道」,在評估中使用真實性評分,實作檢索品質檢查,並考慮新增驗證步驟,讓模型為其主張引用來源。

開發者詳情

檔案結構

📄 SKILL.md