Prompt Engineering

TL;DR： 在裝任何框架之前，有一層治理是免費的：在專案根目錄放一個 AGENTS.md 或 CLAUDE.md，養成開口要求 evidence 的習慣，開始任務前先說清楚什麼不能動。這三件事不能替代跨 session 的狀態管理，但能擋掉大部分常見問題。這篇說的就是怎麼做、做到什麼程度、在哪裡會失效。 有一段時間我的 Claude Code 工作流裡沒有任何框架，只有對話和一堆臨時 prompt。某天我做了兩個改變：把專案的架構決策寫進一個 CLAUDE.md，還有在每次 AI 說「好了」的時候問一句「commit SHA 是什麼？」 一類問題幾乎消失了：AI 在新 session 裡對著不存在的設計模式寫程式碼的情況，以及我接受了「完成」卻發現什麼都沒變的情況。不是所有問題都解決了。但那兩件事的性價比，讓我後來開始認真想「在裝框架之前，這個層面的治理到底能做多少」。 這篇是AI 代理常見痛點與我們的嘗試的延伸。那篇列了五個反覆出現的問題，這篇專門回答：只靠 prompt 習慣和 skill 選擇，能解決多少？ 記憶檔案：解決跨 session 失憶的最低成本方案 AI 代理在每一個新對話都是空白狀態。它不記得上次的架構決策，不記得你說過不要用哪個 pattern，也不記得你已經有一個 utils/auth.ts，所以它再寫一個新的。這個問題在 IEEE Spectrum 的報導裡有量測數據：長 session 後期，AI 重複生成已存在函式、忽視早期建立的 coding convention 的頻率明顯上升。 三個工具在試圖解決同一個問題： AGENTS.md 是 OpenAI Codex 最初設計的慣例，後來被 Cursor、GitHub Copilot 和 Google Antigravity 等主流工具廣泛採納。它的設計邏輯是：在任何工具讀取它之前，先告訴工具「這個專案是怎麼運作的、你可以做什麼、不可以做什麼」。 CLAUDE.md 是 Anthropic 針對 Claude Code 的版本。Claude Code 在每個新 session 開始時自動注入這個檔案的內容，所以你放在這裡的東西就等於是每次都在對話開頭重新說一遍。 .cursor/rules 是 Cursor 的對應物。原理相同。 ...

TL;DR: A “Skill” in production AI is not a saved prompt — it’s a capability abstraction layer with a defined input schema, tool bindings, validation, and retry logic. This post explains why that distinction matters and how Skills fit between raw model calls and higher-level agent orchestration. This post is part of a series on building real AI systems. If you haven’t read the previous piece on moving beyond prompts, that’s a good place to start. ...

TL;DR： 只靠 Prompt 是在做手工藝，不是蓋系統。這篇文章拆解 Prompt → Skill → Workflow → Agent → System 五個層級，用「寫技術文章」的完整案例，說明每個層級解決什麼問題、為什麼上一層不夠用。 前言：別在 Prompt 的死胡同裡打轉 現在只要打開社群媒體，滿地都是「最強 Prompt 指令集」或「這 10 個指令讓 AI 變神級工具」。 剛接觸 AI 的時候，我也沉迷過這種「咒語」的力量。但實戰幾次後你會發現，如果你還在糾結如何微調 Prompt 的那幾個形容詞，那你其實還是在做「手工藝」。這種方式產出的結果不穩定、無法規模化，更重要的是，它非常耗神。 如果你有留意近一兩年的技術演進，你會發現真正的高手已經不再討論怎麼寫咒語了。大家在聊的是 Workflow（工作流）、Agent（代理人） 以及 System（系統）。 這篇文章我想從一個資深開發者與 PM 的視角，拿一個最簡單的任務——**「寫一篇高品質的技術文章」**做案例，帶你看這幾個層級的思維斷層在哪裡。 1. Prompt 層：一次性的「介面」溝通，也是體力活 這是最基礎的使用方式，你打開 ChatGPT，輸入一段話： 「請幫我寫一篇關於 AI Workflow 的技術文章，包含架構說明與範例。」 這就是 Prompt 層。雖然它很強大，但本質上它只是在「調用模型」。它的限制顯而易見： 抽盲盒效應： 成果好壞全看運氣。今天給你 80 分，明天可能只剩 60 分。 孤島式作業： AI 沒辦法讀取你電腦裡的其他資料，也不懂你的審美標準，它只活在那一次的對話框裡。 認知負荷高： 每次遇到新文章，你都要重新把需求、背景、限制條件再描述一遍。 老實說，Prompt 只是個「對話介面」，而非一個「系統」。 它適合處理小型、零碎、一次性的任務（像是修一個小 Bug 或翻譯短句）。但如果你想靠它穩定產出專業內容，那只是在用 AI 換另一種形式的「體力活」罷了。 2. Skill 層：把「手感」封裝成「能力模組」 當你對 AI 寫作有了點心得，你會發現有些要求是重疊的。這時候，你會開始定義一套固定的「寫作標準」。這在開發者眼中，就是所謂的封裝（Encapsulation）。 ...

TL;DR： LLM 只做一件事——預測下一個 token。這篇文章從這個核心概念出發，解析 Transformer 自注意力機制、四步驟訓練流程，以及為什麼「這麼簡單的事」能演變成看起來像魔法的語言能力。 前言 Introduction 如果你最近有用過 ChatGPT、Claude、Gemini，你已經在跟 LLM（Large Language Model）聊天了。這些模型看起來像懂很多、會推理、甚至比朋友還健談，但它們的核心動作其實無比樸實：預測下一個字。 聽起來太簡單？沒錯，但模型規模一大、資料一多、演算法一調整，這個「下一字遊戲」就能演變成看起來像魔法的語言能力。 這篇文章會用工程師看得順、初學者不會暈的方式，把 LLM 的概念、原理與常見應用一次講清楚。 LLM 是什麼？ LLM 的任務比你想像的還簡單 從理論上看，LLM 是一種深度學習模型，被訓練去完成一件事情： 在語境下，挑選「最可能出現的下一個 token」。 token 可以是中文字、英文單字的一部分、符號、甚至數字。 當模型知道怎麼選下一個 token，然後不停重複這件事，就能組出一整段看起來像人寫的句子。 為什麼它看起來「懂很多」？ 因為它被餵了大量內容：百科、文章、科技文、論壇討論…… 在海量語料裡找模式後，它自然會「講得像很懂」。 我們的感官上就感覺它懂很多、很能理解。 圖 1：LLM 下一字預測核心概念示意圖 LLM 是怎麼「學會」語言的？ LLM 的學習流程大致分成四個步驟，其實蠻務實的： 1. 收集大量文本（資料越多，模型越穩） 來源包含書籍、文章、程式碼、論壇、維基百科等。 資料不是越亂越好，但越多越有機會讀懂語言中的隱性規律。 2. 分詞（Tokenization） 模型不直接處理字，而是處理 token。 你可以把它想像成：「把一個蛋糕切成很多比較好吞的碎片」。 3. 預測下一個 token（核心任務） 模型會計算所有候選 token 的機率： 哪個最可能？ 哪個跟前文最適合？ 哪個不太會讓模型出糗？ 機率最高者 → 輸出。 4. 誤差反向調整（Backpropagation） 預測錯了？ → 重新調參 → 再預測 → 再調 → 重複幾十億次 ...