提示詞工程 on KnightLi的博客

Prompt Optimizer：開源提示詞優化、測試與 MCP 工具

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer 是一個開源的提示詞優化工具，目標很直接：幫助你把一段粗糙的提示詞改得更清楚、更穩定，也更容易被大型語言模型執行。

它不只是一個「幫我潤飾 prompt」的頁面。專案同時提供提示詞優化、結果測試、對比評估、多模型接入、圖像生成提示詞處理，以及 MCP 整合。對經常寫系統提示詞、使用者提示詞、AI 工作流模板的人來說，它更像一個專門用來打磨提示詞的工作台。

它解決什麼問題

很多人使用 AI 時都會遇到類似問題：

提示詞越寫越長，但模型輸出沒有明顯變好
同一個需求換個模型就表現不穩定
系統提示詞和使用者提示詞混在一起，很難拆開除錯
改了一版 prompt，不知道是不是真的比上一版更好
想複用變數模板，但每次都要手動替換和測試
想把提示詞優化能力接入其他 AI 工具，卻缺少標準介面

Prompt Optimizer 主要圍繞這些問題設計。它把「寫 prompt」拆成優化、測試、評估、對比、迭代幾個環節，讓提示詞不再只靠感覺調整。

主要功能

1. 優化系統提示詞和使用者提示詞

提示詞並不只有一種。

系統提示詞通常負責定義角色、目標、邊界、輸出規範和工作方法；使用者提示詞則更接近一次具體任務的輸入。兩者混在一起時，模型容易抓不住重點，後續複用也困難。

Prompt Optimizer 支援系統提示詞優化和使用者提示詞優化。你可以分別處理長期複用的角色設定，也可以處理某次具體任務的輸入表達。

這對下面幾類場景比較有用：

寫 AI 編程助手的工作規則
寫客服、審稿、翻譯、分析類角色提示詞
優化文生圖提示詞
把臨時需求整理成可複用模板
為不同模型準備不同風格的 prompt

2. 測試和對比輸出

只優化提示詞還不夠，關鍵是要知道優化後有沒有變好。

專案支援分析、單結果評估、多結果對比評估。也就是說，你可以把原始提示詞和優化後的提示詞放到同一個任務裡跑，看模型輸出是否更準確、更穩定、更符合目標。

這比單純「看起來更專業」的 prompt 更實用。因為很多提示詞表面上寫得完整，實際輸出卻可能更囉嗦、更僵硬，甚至把模型引向錯誤方向。對比測試能幫助你盡早發現這種問題。

3. 支援多模型

README 中提到專案支援 OpenAI、Gemini、DeepSeek、智譜 AI、SiliconFlow 等模型服務，也支援自訂 OpenAI 相容介面。

這點很重要。提示詞效果和模型強相關，同一段 prompt 在不同模型上的表現可能差別很大。多模型測試可以幫助你判斷：

是提示詞本身寫得不好
還是某個模型不適合這個任務
是否需要為不同模型準備不同版本
小模型能否透過更清楚的提示詞接近可用效果

如果你在本地使用 Ollama，或者公司內部有相容 OpenAI 介面的模型服務，也可以透過自訂介面接入。

4. 高級測試模式

專案提供上下文變數管理、多輪會話測試和 Function Calling 支援。

變數管理適合模板化任務。比如你有一套二手交易回覆、商品描述、郵件回覆、程式碼審查或文件生成提示詞，只需要替換商品、價格、語氣、目標使用者等變數，就能快速測試不同輸入下的表現。

多輪會話測試適合驗證長期對話能力。很多 prompt 在單輪問答裡看起來不錯，一旦進入多輪追問，就會忘記約束、偏離角色或重複解釋。多輪測試可以更接近真實使用場景。

Function Calling 支援則適合更工程化的 AI 應用。它能幫助你驗證模型在工具呼叫、參數生成和結構化輸出上的表現。

5. 圖像生成提示詞

Prompt Optimizer 也支援文生圖和圖生圖相關能力，README 中提到整合 Gemini、Seedream 等圖像模型。

文生圖提示詞的優化重點和文字任務不同。它更關注主體、構圖、空間關係、風格、材質、光線、情緒和限制條件。把一句很模糊的想法拆成更可控的視覺描述，通常比單純加長提示詞更有價值。

如果你經常需要生成產品圖、封面、插畫、主視覺或風格參考圖，這類優化會比較實用。

使用方式

專案提供多種入口：

線上版本
Vercel 自部署
桌面應用
Chrome 擴充功能
Docker 部署
Docker Compose 部署
MCP Server

線上版本適合快速體驗。專案說明中提到它是純前端應用，資料儲存在瀏覽器本地，並直接與 AI 服務商互動。

桌面應用適合需要直接連接各種模型 API 的使用者。瀏覽器環境容易遇到跨域限制，桌面應用可以繞過這類問題，尤其適合連接本地 Ollama 或一些跨域策略嚴格的商業 API。

Docker 部署適合放在自己的伺服器或內網環境裡使用。README 給出的基礎命令如下：

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

如果要配置 API 金鑰和存取密碼，可以透過環境變數傳入：

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

國內存取 Docker Hub 較慢時，專案也提供了阿里雲映像地址，可按 README 中的說明替換映像名稱。

MCP 能做什麼

Prompt Optimizer 支援 Model Context Protocol，也就是 MCP。

透過 Docker 執行時，MCP 服務可以和 Web 應用一起啟動，並透過 /mcp 路徑存取。這樣它就不只是一個網頁工具，而是可以被 Claude Desktop 等支援 MCP 的應用呼叫。

README 中列出的 MCP 工具包括：

optimize-user-prompt：優化使用者提示詞
optimize-system-prompt：優化系統提示詞
iterate-prompt：對已有提示詞做定向迭代

這類介面很適合放進 AI 工作流裡。比如你在寫複雜任務提示詞時，可以讓支援 MCP 的客戶端直接呼叫提示詞優化能力，而不必每次打開網頁手動複製。

和普通聊天工具有什麼區別

普通聊天工具當然也能幫你改 prompt，但它通常缺少幾個環節：

不方便保存和對比多個版本
不方便同時測試多個模型
不方便把變數模板化
不方便做多輪會話驗證
不方便接入 MCP 或部署到自己的環境

Prompt Optimizer 的價值在於把提示詞優化做成一個可重複的流程。它不只是給你一版「看起來更完整」的文字，而是讓你圍繞實際輸出持續調整。

適合誰使用

如果你符合下面幾種情況，可以重點關注這個專案：

經常寫系統提示詞
經常為 AI 應用設計角色和輸出格式
需要比較不同模型的輸出效果
想把 prompt 做成可複用模板
需要測試多輪對話或工具呼叫
想把提示詞優化能力接入 MCP 工作流
希望在本地或內網部署提示詞工具

如果你只是偶爾問 AI 一個簡單問題，用普通聊天頁面就夠了。這個工具更適合那些把提示詞當成可維護資產的人。

使用時要注意什麼

第一，不要把優化結果當成絕對正確。

提示詞優化工具可以提高表達品質，但不能保證模型一定不會誤解。重要任務仍然需要測試樣例、人工檢查和版本對比。

第二，不要只追求更長。

好的 prompt 不一定更長。它應該更清楚地表達目標、邊界、輸入輸出格式和判斷標準。無意義的規則堆疊反而會讓模型抓不住重點。

第三，要按模型調 prompt。

不同模型對角色設定、格式約束、推理步驟和範例的敏感度不同。一個在大模型上表現很好的提示詞，不一定適合小模型。多模型測試正是這個工具值得使用的原因之一。

第四，部署時要考慮金鑰和存取控制。

如果你把它部署到公網，應該配置存取密碼，並謹慎處理 API key。專案支援透過環境變數配置存取控制，不要把敏感配置直接寫到公開倉庫裡。

參考

linshenkx/prompt-optimizer

最後一句

Prompt Optimizer 適合用來把提示詞從「臨時手寫的一段話」整理成「可以測試、可以比較、可以迭代的工作資產」。

當你開始在多個模型、多個場景、多個版本之間維護 prompt 時，這類工具會比普通聊天視窗更順手。

Karpathy 的 65 行 CLAUDE.md：讓 AI 編程少犯三類錯誤

Sun, 19 Apr 2026 18:27:23 +0800

最近 GitHub 上有一個圍繞 AI 編程的專案很火，核心其實只是一個大約 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因為技術實作複雜，而是因為它抓住了很多人使用 AI 寫程式時反覆遇到的問題。

這個專案的背景，要從 Andrej Karpathy 對 AI 編程的觀察說起。Karpathy 是 AI 領域很有影響力的教育者和工程師：史丹佛博士，參與過 OpenAI 早期工作，也曾在 Tesla 負責 Autopilot 視覺系統。後來他持續分享對大模型、教育和 AI 工具的理解，所以他對編程方式變化的判斷，總會引起很多開發者關注。

他在一次分享中提到，自己使用 Claude Code 幾週後，編程方式發生了明顯變化：過去大概是 80% 手寫程式、20% AI 輔助，現在更接近 80% 讓 AI 寫程式，自己做 20% 修改。他形容這像是「用英語編程」，透過自然語言告訴 LLM 要寫什麼。

但他也指出了 AI 編程的幾個典型問題。

01 錯誤假設

第一個問題是模型很容易替使用者做假設，然後沿著這個假設一路寫下去。它不一定會主動管理自己的困惑，也不一定會在需求含糊時停下來追問。

比如使用者只說「新增使用者匯出功能」，模型可能會預設匯出全部使用者，預設輸出 JSON，預設寫成本地文件，預設權限和欄位都不需要再確認。等程式寫完，使用者才發現它理解的需求和真實場景並不一致。

更好的做法應該是先把不確定點列出來：匯出全部使用者還是篩選結果？是瀏覽器下載還是後台任務？需要哪些欄位？資料量大不大？是否有權限限制？這些問題不問清楚，後面寫得越快，偏得也越遠。

02 過度複雜化

第二個問題是模型很容易把簡單問題寫複雜。一個函式能解決的問題，它可能加上抽象類、策略模式、工廠模式、配置層和一堆「未來可能有用」的擴充點。

這類程式看起來很工程化，實際卻增加了維護負擔。AI 尤其擅長快速生成大量結構，但並不總能判斷這些結構是否真的必要。結果就是一百行能解決的任務，被膨脹成一千行。

判斷標準其實很直接：一個資深工程師看到這段改動，會不會覺得它過度設計？如果答案是會，就應該刪掉多餘層次，用最少的程式碼解決當前問題。

03 附帶傷害

第三個問題是模型有時會修改或刪除自己沒有充分理解的程式碼。它可能在修一個小 bug 的時候順手改註釋、重排格式、清理看似無用的 import，甚至動到和當前任務無關的邏輯。

這類「順手優化」很危險，因為它擴大了變更範圍，也讓 review 變得更困難。使用者本來只想修復一個空 email 導致驗證器崩潰的問題，結果模型順便增強了 email 驗證、加了使用者名稱校驗、改了文件字串，最後很難判斷到底哪一行影響了行為。

更穩妥的原則是：只動必須動的程式碼，只清理自己造成的問題。原本就存在的死程式碼、格式問題或歷史包袱，除非任務明確要求處理，否則最多提醒一句，不要直接改。

04 把吐槽變成 CLAUDE.md

在 Karpathy 的觀點被大量傳播後，開發者 Forrest Cheung 做了一件很聰明的事：他把這些吐槽整理成可以執行的行為準則，寫進一個 CLAUDE.md 文件。

這個專案沒有複雜程式碼，關鍵就是把 AI 編程中最容易出問題的地方，轉成明確的工作規則。大致可以概括為四條。

第一條是先想再寫。不要默默假設，不要隱藏困惑；如果需求有多種理解，就把它們列出來；如果存在更簡單的方案，也要說出來；該追問時追問，該反駁時反駁。

第二條是簡單優先。不新增沒被要求的功能，不為一次性程式碼做抽象，不加入多餘配置，也不為極小機率場景寫大量防禦程式碼。如果 50 行能解決，就不要寫成 200 行。

第三條是精準修改。每一行改動都應該能直接追溯到使用者請求。不要順手改善鄰近程式碼，不要重構沒壞的東西，盡量匹配專案既有風格。

第四條是目標驅動。不要只給模型一個模糊指令，而是給它可驗證的成功標準。比如「修復 bug」可以變成「先寫一個能復現 bug 的測試，再讓測試通過」；「新增校驗」可以變成「寫無效輸入測試並通過」。成功標準越清楚，模型越容易自己循環到完成。

05 為什麼它會火

這個專案能火，不是因為內容很玄，而是因為它足夠貼近真實開發。

很多人用 AI 編程時都經歷過類似場景：模型自信地誤解需求，程式越寫越複雜，或者在不該動的地方動手。CLAUDE.md 的價值，是把這些經驗變成可以放進專案裡的協作規則。

它的門檻也很低：一個文件就能開始生效，不需要複雜接入。再加上 Karpathy 本人的影響力，以及專案裡有實戰對比案例，它很自然會在 Claude Code 使用者和 AI 編程社群裡傳播開來。

更重要的是，這類規則不是只適用於 Claude Code。無論使用哪種 AI 編程工具，本質問題都很相似：模型需要知道什麼時候該問、什麼時候該簡化、什麼時候該停手、怎樣判斷任務已經完成。

06 對普通開發者的啟發

這件事給普通開發者的啟發很簡單：AI 編程不是把一句需求丟給模型，然後等待奇蹟發生。真正有效的方式，是給模型建立邊界。

需求不清楚時，讓它先暴露假設。實作方案變複雜時，讓它主動回到最小可行解。修改程式碼時，讓它只圍繞任務目標行動。完成任務時，用測試、命令或明確檢查點來驗證結果。

AI 寫程式的能力已經很強，但它仍然需要好的協作約束。一個短小的 CLAUDE.md 能獲得大量關注，說明開發者真正需要的並不只是更聰明的模型，也包括更可靠的工作方式。

簡單總結：

先想再寫，減少錯誤假設。
簡單優先，避免過度設計。
精準修改，控制變更範圍。
目標驅動，用可驗證標準推動完成。

這四條並不複雜，卻很實用。AI 編程真正提升效率的前提，不是讓模型寫得更多，而是讓它寫得更準、更少、更可控。

什麼是 Agent Skills：從設計理念到上下文優化

Sat, 28 Mar 2026 00:00:00 +0000

Agent Skills 是一種將程序性知識標準化封裝的方式。簡而言之，它解決的不是「有沒有工具」，而是「如何把工具用對、用好」。

1. 核心設計理念

Agent Skills 的核心價值在於沉澱「方法論」：

提供領域知識，指導智能體在具體場景下如何組合與調用工具。
約束執行路徑，降低試錯成本，提升任務完成的一致性。
讓複雜流程可重用、可迭代，逐步形成穩定 SOP。

如果把工具能力比作「硬體介面」，那麼 Skills 更像「操作說明書」與「最佳實踐集合」，定義的是「該怎麼做」。

2. 漸進式揭露：破解上下文困境

Agent Skills 最核心的創新是漸進式揭露（Progressive Disclosure）：按需載入資訊，避免一次性把大量內容塞進上下文視窗。

2.1 第一層：元資料（Metadata）

每個技能通常位於獨立資料夾中，核心檔案是 SKILL.md。該檔案以 YAML Frontmatter 開頭，定義技能基礎資訊。

智能體啟動時，只讀取所有技能的 Frontmatter 並注入系統提示詞。根據實務經驗：

單個技能元資料消耗約 100 tokens
50 個技能約消耗 5,000 tokens

2.2 第二層：技能主體（Instructions）

當某個技能被判斷為與當前任務高度相關時，智能體才會讀取完整 SKILL.md，載入詳細指令、注意事項和範例。

這部分 token 消耗通常與技能複雜度相關，常見範圍為：

1,000 到 5,000 tokens

2.3 第三層：附加資源（Scripts & References）

複雜技能可在 SKILL.md 中引用腳本、設定檔和參考文件，僅在需要時載入。

示例目錄結構：

skills/pdf-processing/
├── SKILL.md                 # 主技能檔案
├── parse_pdf.py             # PDF 解析腳本
├── forms.md                 # 表單填寫指南（僅在填表任務時載入）
└── templates/
    ├── invoice.pdf
    └── report.pdf

典型調用方式：

需要解析 PDF 時，執行 parse_pdf.py
遇到填表任務時，再載入 forms.md
模板檔案僅在輸出特定格式文件時訪問

3. 為什麼這種設計有效

3.1 可擴展的知識容量

透過「腳本 + 外部檔案」，技能可攜帶遠超上下文視窗容量的知識。例如，一個數據分析技能可以附帶 1GB 數據檔案和查詢腳本，智能體透過執行腳本訪問數據，而不是把整份數據集直接塞進上下文。

3.2 更強的確定性

將複雜計算、數據轉換、格式解析交給程式碼執行，可以顯著降低 LLM 在純文字生成中的不確定性與幻覺風險。

4. 實際效果：從 16k 到 500 Token

社群實踐顯示，漸進式揭露能顯著降低初始上下文開銷：

傳統 MCP 方式：直接連接包含大量工具定義的 MCP 服務，初始化約 16,000 tokens
Skills 包裝後：先用輕量 Skill 作為「閘道」，僅透過 Frontmatter 描述能力，初始化約 500 tokens

當任務真正需要時，再按需載入詳細指令與附加資源。這樣既降低了初始成本，也讓對話過程中的上下文管理更精準。

總結

Agent Skills 的關鍵意義在於：把「工具可用」升級為「能力可重用」。透過漸進式揭露，系統可以在保持能力深度的同時，顯著優化 token 成本與執行穩定性。

普通人如何指揮 AI 幹活：從圖片中提取圖形與數學公式（實戰示例）

Thu, 26 Mar 2026 00:00:00 +0000

前提條件

安裝 VS Code，並安裝 Codex 外掛，可參考這篇文章。
使用這些工具並不要求你有程式設計經驗。VS Code 在這裡主要用於整理檔案；你只需提出需求，AI 就會自動編寫程式並執行。
本文記錄完整操作過程，目的是拋磚引玉，探索更多 AI 的實用方法，讓更多普通人受益。

任務目標

準備一張同時包含數學公式與示意圖形的圖片：

我們希望實現三件事：

將圖形切分成乾淨的小圖。
識別公式並轉換為 LaTeX，方便後續修改。
將圖形與對應公式建立關聯。

過程

先識別圖片，生成 Markdown 文件，並將公式轉換為 LaTeX

轉換結果：

# 1.png 識別結果

## 幾何公式（LaTeX）

1. 三角形面積（邊長與外接圓半徑）：

$$
S = \frac{abc}{4R}
$$

2. 三角形面積（內切圓半徑與半周長）：

$$
S = pr
$$

3. 圓台體積：

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

4. 圓台側面積：

$$
S = \pi a(R + r)
$$

5. 圓柱體積：

$$
V = \pi r^2 h
$$

6. 圓柱側面積：

$$
S = 2\pi rh
$$

7. 球體積：

$$
V = \frac{4}{3}\pi R^3
$$

8. 球表面積：

$$
S = 4\pi R^2
$$

9. 正弦定理：

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

10. 餘弦定理：

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

公式都被識別出來了，AI 還自動補充了公式名稱，效果很好；但此時還沒有完成小圖裁剪。

嘗試讓 AI 裁剪圖片

# 1.png 識別結果（圖文並排，精修裁圖）

<table>
  <tr>
    <td>![](crops/01_triangle_circum.png)</td>
    <td>

$$
S = \frac{abc}{4R}
$$

</td>
  </tr>
  <tr>
    <td>![](crops/02_triangle_incircle.png)</td>
    <td>

$$
S = pr
$$

</td>
  </tr>
  <tr>
    <td>![](crops/03_frustum.png)</td>
    <td>

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

$$
S = \pi a(R + r)
$$

</td>
  </tr>
  <tr>
    <td>![](crops/04_cylinder.png)</td>
    <td>

$$
V = \pi r^2 h
$$

$$
S = 2\pi rh
$$

</td>
  </tr>
  <tr>
    <td>![](crops/05_sphere.png)</td>
    <td>

$$
V = \frac{4}{3}\pi R^3
$$

$$
S = 4\pi R^2
$$

</td>
  </tr>
  <tr>
    <td>![](crops/06_laws.png)</td>
    <td>

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

</td>
  </tr>
</table>

結果：圖片已經裁剪並放到了對應位置，但仍有干擾區域，裁剪邊緣不夠乾淨。

修正「裁切過度」問題：先盡量保留完整圖形，再手工去除多餘部分
這一步的效果還不穩定，目前不確定是提示詞問題，還是模型在視覺定位上的波動。

總結

使用 Codex 和直接在 chatgpt.com 對話，體驗明顯不同。
在 chatgpt.com 中，更像是 AI 在引導你完成工作；而在 Codex 中，更像是 AI 按照你的要求去執行工作。
當你提出需求後，AI 會生成程式、執行程式並完成任務，你會更明顯地感受到「自己在指揮 AI 幹活」。
整個流程對程式設計基礎要求並不高，普通人也可以逐步上手並產出成果。