https://yennj12.js.org/yennj12_blog_V4/tags/prompt-engineering/Recent content in Prompt-Engineering on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part1-zh/Tue, 26 May 2026 16:53:54 +0900https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part1-zh/前言 AI Forward Deployed Engineer (FDE) 是連接前沿 AI 技術與生產環境的關鍵角色。不同於傳統的顧問職位，FDE 需要深入客戶環境，從快速原型開發到生產級系統部署，實現可量化的商業價值。本系列文章將深入解析成為優秀 AI FDE 所需的核心技能。 1. Python 生態系統精通 核心語言特性 必須掌握的概念： 1# 生成器與迭代器 - 記憶體效率處理大型數據集 2def data_generator(file_path): 3 with open(file_path, 'r') as f: 4 for line in f: 5 yield process_line(line) 6 7# 異步程式設計 - 提升 I/O 密集型操作效率 8import asyncio 9import aiohttp 10 11async def fetch_embeddings(texts): 12 async with aiohttp.ClientSession() as session: 13 tasks = [get_embedding(session, text) for text in texts] 14 return await asyncio.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part9-llm-core-zh/Sun, 31 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part9-llm-core-zh/這篇是 FDE 面試系列的最後一篇基礎知識篇。 LLM 的這三塊——Token、Prompt Engineering、Embedding—— 是你每天都在用的工具，但能說清楚的人比你想像中少。 說得清楚，就是專業的訊號。 面試情境 面試官：「你的 RAG 系統的 context budget 怎麼設計的？如果你要讓 LLM 做複雜推理，你用什麼 Prompting 技法？為什麼選 text-embedding-004 而不是 OpenAI 的 embedding？」 這三個問題把 Token、Prompt Engineering、Embedding 串在一起問，測的是你有沒有把這些工具整合進系統設計的意識。 一、Token：不是字，是 LLM 的計量單位 面試官問： 「Context Window 是什麼？對你的系統設計有什麼影響？」 Token 是什麼 LLM 不是以字元或單詞為單位處理文字，而是以 Token 為單位。 Token 是 Tokenizer 切出來的文字片段，大小不固定： "Hello world" → ["Hello", " world"] → 2 tokens "LLM" → ["L", "LM"] → 2 tokens（或 1 token，取決於 tokenizer） "不可思議" → ["不", "可", "思", "議"] → 4 tokens（中文通常 1 字 = 1 token） 粗略換算（GPT/Gemini 系列）：https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part3-llm-security-zh/Mon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part3-llm-security-zh/一份有三個真實 MEDIUM 漏洞的報告， 比一份有三十個「潛在可能理論上存在風險」的報告有用十倍。 安全報告的公信力一旦失去，工程師會停止閱讀它。 一、為什麼 LLM Agent 特別容易產生廢話安全報告 LLM 有一個普遍的傾向：它會試圖看起來有幫助。 在安全稽核的場景，這個傾向帶來的問題是： 工程師期待的 LLM 行為： 如果沒找到漏洞 → 說「我沒找到漏洞，這個部分看起來安全」 LLM 實際的行為： 如果沒找到確定的漏洞 → 說「這裡可能存在潛在的風險...」 「雖然沒有明確的漏洞，但理論上...」 「建議加強這部分的防護，因為...」 這就是「廢話型安全報告」的根源——它讓 LLM 看起來有在做事，但對工程師毫無價值。 Cloudflare 的 security-audit-skill 明確列出了這個問題的解法，也列出了最常見的反模式。本篇把這些反模式系統化整理，並從 agent pipeline 設計的角度說明如何從根源消除。 二、反模式地圖 十個反模式的分類： ┌─────────────────────────────────────────────────────────────┐ │ 類型 A：「看起來嚴格，實際上沒用」的 finding │ │ 反模式 1：OWASP checklist 當 bug list │ │ 反模式 2：用模糊語言掩蓋不確定性 │ │ 反模式 3：Defense-in-depth 缺失膨脹成漏洞 │ │ 反模式 4：部署情境視而不見 │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 類型 B：「用量充數」的報告結構問題 │ │ 反模式 5：用 LOW 充厚度 │ │ 反模式 6：只說壞處，不說好處 │ │ 反模式 7：不提歷史漏洞基準 │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 類型 C：「懶惰的調查」導致的誤判 │ │ 反模式 8：太快放棄 │ │ 反模式 9：不驗證 parser/runtime 行為假設 │ │ 反模式 10：不做根本原因分析就重複報告 │ └─────────────────────────────────────────────────────────────┘ 三、類型 A：「看起來嚴格，實際上沒用」的 Finding 反模式 1：把 OWASP 偏離當成 Bug 症狀：https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/Thu, 12 Mar 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/多 Agent Token 優化系列總覽：深入解析 Token 用量優化策略，涵蓋 Prompt Caching、Context 壓縮、Agent 專責化、模型分層、選擇性 Context 傳遞等方法，幫助你建構高效且低成本的多 Agent 系統。