前端開發 on KnightLi的博客

Prompt-Vault：一個適合測試 AI 程式設計能力的 Prompt 規格庫

Fri, 15 May 2026 09:00:52 +0800

w512/Prompt-Vault 是一個很小但有用的 prompt 倉庫。它不是收集“萬能咒語”，而是把一組可執行的 coding prompt 按難度整理成規格文件，用來測試 LLM 或 coding agent 能不能真正完成一個小專案。

專案地址：https://github.com/w512/Prompt-Vault

截至寫作時，這個倉庫只有少量檔案和提交，但結構很清楚：Easy、Medium、Hard 三個目錄，每個 Markdown 檔案都是一個獨立任務。README 裡也寫得很直接：這些 prompt 適合測試大語言模型，或者給開發者當練手專案。

它不是 prompt 收藏夾

很多 prompt 倉庫的問題，是內容看起來很多，但很難判斷質量。標題很吸引人，真正拿去用時卻缺少驗收標準。

Prompt-Vault 更像一個小型規格庫。每個任務都儘量寫清楚：

要做什麼應用
必須有哪些功能
UI 應該是什麼風格
技術約束是什麼
是否必須單檔案執行
是否允許外部依賴
資料是否需要持久化

這種結構比“請幫我做一個好看的看板”更適合測試模型。因為它能看出模型是否真的理解需求，而不是隻生成一份看似完整的頁面。

Easy：測試基礎互動

Easy 目錄裡有兩個任務。

第一個是 Bubble_Sort_Visualizer.md，要求做一個單檔案 index.html，用柱狀條實時展示氣泡排序。它要求有開始按鈕、重置按鈕、速度滑塊、比較次數統計和深色主題。

這個任務適合測試模型的基礎前端能力：

能不能把演算法狀態對映到 UI
能不能做動畫節奏控制
能不能正確處理重置和執行狀態
能不能保持程式碼簡單可讀

第二個是 ToDo_List.md，從靜態 HTML 開始，一步步增加新增任務、完成狀態、刪除按鈕、計數器、Active / Completed 統計和 localStorage 持久化。

這個任務看起來普通，但很適合測試模型是否會按步驟演進，而不是一口氣堆出一份混亂程式碼。

Medium：測試複雜狀態和動畫

Medium/Sorting_Visualization.md 把排序視覺化升級了一檔。

它要求同一個頁面支援 6 種排序演算法：

Bubble Sort
Insertion Sort
Selection Sort
Merge Sort
Quick Sort
Heap Sort

同時還要有演算法選擇、速度滑塊、陣列大小滑塊、重置按鈕、開始 / 暫停切換，以及實時統計面板。

這個任務能測出不少問題。很多模型可以寫出一個氣泡排序動畫，但一旦要支援多個演算法、暫停恢復、統計比較次數和交換次數，就容易出現狀態混亂。

如果用它做評測，可以重點看這些點：

每種演算法是否真的按預期排序
動畫是否和演算法步驟一致
暫停後能否繼續
重置是否會停止舊動畫
陣列大小變化是否會破壞狀態
統計資料是否可信

這類 prompt 很適合作為前端 coding agent 的中等難度 smoke test。

Hard：測試完整產品感

Hard 目錄目前有兩個任務。

一個是 Kanban_Board.md。它要求做一個完整的看板應用：預設四列、可新增列、雙擊重新命名、空列刪除、卡片標題和描述、優先順序、截止日期、拖拽、搜尋、優先順序過濾、localStorage 持久化、底部統計欄、深色玻璃擬態風格和響應式橫向滾動。

這個 prompt 的價值在於它不是隻測單點能力，而是測“產品完整度”：

原生 Drag & Drop 是否可靠
新增列和卡片後狀態是否持久化
搜尋和過濾是否影響佈局
overdue 邏輯是否正確
Done 列是否觸發視覺狀態變化
刪除、重新命名、取消、儲存這些邊界是否完整

另一個是 Markdown_Editor_Desktop.md，要求用 Tauri 2 做跨平臺 Markdown 編輯器。它包含分欄編輯與預覽、同步滾動、實時渲染、預覽模式、專注模式、開啟檔案、儲存、另存為、視窗標題未儲存標記、格式化工具欄、快捷鍵、主題、字型設定、Vue 3、Pinia、marked.js、prism.js 和 Tauri 外掛。

這已經不是普通網頁 prompt，而是一個能測試桌面應用工程能力的規格。模型需要理解前端狀態、Tauri 外掛、檔案系統許可權、IPC 邊界和跨平臺打包。

為什麼這種倉庫有價值

Prompt-Vault 的價值不在於任務數量，而在於它給了可複用的評測樣本。

如果你在比較不同模型或 coding agent，可以用同一個 prompt 反覆測試：

哪個模型更能遵守約束
哪個模型更少漏功能
哪個模型更會處理邊界狀態
哪個模型生成的程式碼更容易維護
哪個模型更擅長 UI 細節
哪個模型在單檔案約束下更穩定

這比“我感覺這個模型更聰明”可靠得多。

尤其是前端任務，很多失敗不是語法錯誤，而是體驗細節缺失。比如按鈕能不能禁用、動畫是否卡住、重新整理後資料是否還在、拖拽目標是否高亮、統計是否同步更新。這些都需要具體 prompt 才能測出來。

可以怎麼擴充套件

如果要把 Prompt-Vault 變成更完整的評測庫，可以繼續補幾類任務。

第一類是驗收清單。每個 prompt 後面加一組 checklist，比如“重新整理後任務仍存在”“刪除空列成功，非空列不能刪除”“暫停排序後陣列狀態不變”。這樣人和 agent 都更容易驗收。

第二類是失敗用例。比如給排序視覺化任務補充“快速連續點選 Start / Reset 不應產生多個動畫迴圈”。這能測出狀態管理是否紮實。

第三類是評分維度。可以按功能完整度、程式碼可維護性、UI 質量、可訪問性、效能、邊界處理打分。

第四類是參考實現。不是為了讓模型抄答案，而是給評測者一個基準，方便判斷輸出是不是合理。

第五類是跨模型記錄。把不同模型在同一 prompt 下的結果、失敗點和 token 成本記錄下來，就能形成真正的 coding benchmark。

使用建議

如果你想用這個倉庫測試 AI 程式設計工具，建議不要只看“能不能生成頁面”。

更好的做法是：

選一個 prompt，原樣交給模型。
不做額外提示，看第一次輸出能完成多少。
開啟生成結果，按功能逐項驗收。
記錄漏掉的功能和明顯 bug。
再給一次修復機會。
比較總耗時、token 成本和最終程式碼質量。

這樣測出來的結果更接近真實開發。因為真正的 coding agent 不只是生成程式碼，還要理解規格、處理反饋、修復缺陷，並保持程式碼可維護。

小結

Prompt-Vault 是一個輕量級 prompt 規格庫。它適合拿來做 AI 程式設計測試，也適合前端開發者練習小專案。

它提醒我們：好的 prompt 不只是描述願望，而是寫清需求、約束、互動、狀態、驗收和執行方式。越是想測試模型能力，越不能只給一句模糊指令。

如果你正在比較 Codex、Claude Code、Cursor、Gemini CLI 或其他 coding agent，這類分級 prompt 很值得收藏。它們能幫你把“感覺好用”變成“具體哪裡做對了，哪裡漏了，修一次能不能補回來”。

DeepSeek V4 Pro 對比 GPT-5.5：前端、寫作、程式實測後，差距比想像更大

Sat, 25 Apr 2026 11:12:00 +0800

DeepSeek V4 Pro 和 GPT-5.5 這種對比，最近越來越容易引發討論。因為它已經不是「誰能不能用」的問題，而是：當任務落到前端、寫作、程式這三類高頻場景時，誰更適合當主力？

很多人做這類比較時，習慣先問一句：哪個更強。
但更有價值的問題通常不是這個，而是：在具體任務裡，哪個更穩、哪個更省溝通成本、哪個更容易產出能直接繼續推進的結果。

如果先給一個簡化版結論，可以大致這樣理解：

需要更均衡、產品化體驗更完整的綜合輸出時，很多人還是會先看 GPT-5.5
需要中文語境下高頻迭代、對成本更敏感、追求回應效率時，DeepSeek V4 Pro 會更容易進入候選名單
真正決定體驗的，往往不是模型名字本身，而是任務類型、提示方式，以及你後續還要不要繼續改

下面按三個最常見的比較場景展開。

1. 前端任務：比的不是「會不會寫頁面」，而是能不能繼續接著改

前端任務看起來很適合拿來做模型對比，因為結果很直觀：
頁面能不能跑、樣式好不好看、結構清不清楚，一眼就能看到。

但真正拉開差距的，往往不是第一版能不能寫出來，而是後續這些問題：

結構是不是夠清晰
元件拆分是否自然
改一處時會不會連帶改壞別的地方
能不能在多輪指令下繼續保持同一套實作思路

這也是為什麼很多「首輪效果驚艷」的前端演示，放進真實工作流後未必依然佔優。

如果你的任務是：

快速生成一個可執行的頁面原型
先把一個落地頁思路寫出來
按要求補齊樣式、按鈕、卡片、表單等基礎元素

那兩類模型通常都能完成得八九不離十，差別更多體現在輸出風格。

而如果你的任務變成：

持續多輪改 UI
一邊讀現有程式碼一邊接著改
同時兼顧元件結構、樣式一致性和可維護性
從靜態頁面逐步推進到真實專案程式碼

那你更應該觀察的就不是「第一輪誰更像樣」，而是「誰在第五輪以後還不容易跑偏」。

所以前端對比真正該看的，不是模型能不能生成頁面，而是它能不能在你連續追加限制之後，依舊保持結構穩定、命名一致、修改成本可控。

2. 寫作任務：比的不是字多不多，而是風格穩不穩、重寫順不順

寫作是另一類特別容易出現誤判的場景。

因為很多時候，模型第一次輸出看起來都不差：
結構完整、段落齊全、語氣順滑，乍看之下很容易覺得「差不多」。

但只要你把任務往前推一步，差異就會冒出來：

能不能準確理解你要的受眾
能不能在同一主題下切換不同口吻
重寫時會不會丟掉原文重點
壓縮、擴寫、改標題、換結構時是否穩定

寫作任務裡最怕的不是「寫不出來」，而是「看起來寫出來了，但你還得重改很多遍」。

所以在 DeepSeek V4 Pro 和 GPT-5.5 之間，更實用的比較方式通常不是讓它們各寫一篇，而是連續做這幾輪：

先寫初稿
再換一個語氣重寫
再壓縮成更短版本
再改成更適合標題黨或搜尋分發的寫法

如果一個模型在這幾輪裡仍然能保持重點不散、表達不飄、結構不亂，那它在真實寫作工作流裡的價值才會更高。

也就是說，寫作任務真正比的不是「文采」，而是改稿能力、服從度和連續協作感。

3. 程式任務：真正拉開差距的是長鏈路穩定性

程式任務比前端任務更容易暴露模型真實水平，因為它不只是要「輸出」，還要「對接現實」。

你很快就會遇到這些問題：

它能不能理解既有專案結構
能不能同時修改多個檔案
改完以後有沒有引入新的問題
出錯時會不會順著日誌繼續往下查
多輪之後還記不記得前面已經做過什麼

這類任務裡，使用者最在意的通常不是某一段程式碼漂不漂亮，而是：能不能幫我持續往前推進，而不是讓我來收拾殘局。

所以比較 DeepSeek V4 Pro 和 GPT-5.5 時，最值得看的往往不是單點題，而是這種更接近真實工作的過程：

讀一個既有倉庫
找到一個 bug
改多個相關檔案
根據報錯繼續修
最後把結果整理清楚

只要任務進入這種連續推進模式，模型的上下文保持能力、執行習慣、解釋品質和返工率，都會比「單輪答題效果」更重要。

這也是為什麼很多使用者在程式場景裡，最後形成的不是「永遠只用一個模型」，而是按任務階段切換主力。

4. 真正值得比較的，不是輸贏，而是「哪類任務交給誰更划算」

把 DeepSeek V4 Pro 和 GPT-5.5 放在一起時，如果目標只是爭一個總冠軍，最後往往會得到一個很空的結論。

因為現實任務不是統一題目：

有的是一次性生成
有的是多輪協作
有的是中文寫作
有的是工程改動
有的是強調速度
有的是強調穩定性
有的是強調成本

所以更接近真實使用的方法，通常是按任務目標分：

想要更完整的綜合體驗、更成熟的互動和更穩定的通用輸出，可以優先試 GPT-5.5
想要在中文環境裡高頻試錯、快速迭代，並且更關注投入產出比，DeepSeek V4 Pro 值得重點放進工作流裡
如果任務本身是長鏈路、多輪修正、多人協作，那就不要只看第一輪結果，要看五輪以後誰還更穩

換句話說，真正該問的不是「誰絕對更強」，而是：
前端、寫作、程式這三類任務裡，哪一個模型更像你當前階段最順手的工具。

5. 怎麼做一次更像樣的模型對比

如果你自己也準備測 DeepSeek V4 Pro 和 GPT-5.5，一個更可靠的做法通常不是只跑一輪，而是這樣測：

給兩邊同一份初始需求
保持相同限制條件
連續追問三到五輪
記錄改動品質、跑偏次數和返工量
最後再看速度、成本和最終可用度

這樣測出來的結果，會比「誰第一輪更驚艷」更接近真實工作。

尤其在前端、寫作、程式這三類任務裡，很多時候真正決定體驗的不是起跑線，而是誰能陪你把事情做完。

6. 可以先這樣記

如果只想先記一個夠用的版本，可以先這麼理解：

GPT-5.5：更像綜合型、產品化、預設可用的主流工作台
DeepSeek V4 Pro：更像在中文環境和高頻試錯裡更值得納入日常工作流的競爭者
真正的比較重點：不是首輪炫技，而是多輪修改之後誰更穩、誰更省事

所以這類對比裡，真正重要的從來都不是「誰贏了」，而是：
你的前端、寫作、程式任務，交給誰之後最容易持續推進、最少返工、最能穩定產出。