把成功案例餵給 Codex，可能比重新寫 Prompt 更有效
整理版優先睇
提供成功案例比寫靚Prompt更有效，AI Agent需要路徑而非目標
呢篇文章係由陳寶寫嘅，佢觀察到好多人用AI Agent嗰陣專注寫靚Prompt，但效果有限。佢透過一個網絡優化嘅真實案例指出，真正關鍵係將已經驗證成功嘅案例作為上下文餵俾AI，而唔係追求完美嘅Prompt。呢個觀點顛覆咗好多使用者嘅習慣，令人反思點樣先可以令Agent類AI發揮最大效用。
文章介紹咗一個具體案例：有人用Codex優化網絡速度，步驟包括運行speedtest-cli、檢查DNS、檢查MTU同丟包、清理網絡配置、限制佔用帶寬嘅後台進程、優化mDNS，最後做速度測試。呢個案例特別之處係，佢展示咗一種全新嘅使用方式——將一個已經跑通嘅操作過程直接變成AI嘅工作樣本。AI沿住呢條路徑執行，結果好理想，比起直接話「幫我優化網速」有效得多。
最後，作者總結咗呢種方法嘅適用場景——診斷、排查、修復、驗證呢類多步驟任務，並提供咗一個提問結構：先畀成功案例，再要求AI總結路徑，逐步檢查同記錄結果。核心訊息係：唔好只畀目標，要畀成功樣本。目標令AI知道想點去，成功樣本令AI知道點樣行。呢個先係更高級嘅提示技巧。
- 成功案例作為上下文比起寫靚Prompt更有效，因為案例提供路徑而目標只係方向。
- 方法係先揾一個同當前問題相似且成功解決嘅案例，連同自己嘅實際情況一齊交俾AI。
- 成功案例畀咗AI參考答案同優先級，唔使從頭猜，而係沿已驗證嘅診斷鏈路行。
- 對於診斷、排查、修復呢類多步驟任務，案例驅動提示可大幅提升AI執行質素。
- 使用結構化提問：提供案例、要求總結路徑、逐步檢查、記錄結果，方便日後複用，避免重複勞動。
案例驅動提示模板
下面係一個別人已經成功解決類似問題嘅案例。請你先總結呢個案例裏面嘅診斷路徑同關鍵動作。然後結合我當前嘅環境，逐步檢查係咪存在類似問題。每一步都先說明你要檢查乜嘢，再執行命令或者查看配置。唔好直接做高風險修改。修改前先解釋影響，修改後做驗證。如果係本地電腦、伺服器、項目倉庫呢類真實環境，可以加一句：請將每一步嘅檢查結果同最終改動記錄低，方便我以後複用。
一個真實案例：用Codex優化網絡速度
文章開頭引用咗一個具體例子：有人用Codex優化自己嘅網絡速度，過程好詳細。佢先運行speedtest-cli診斷問題，然後檢查DNS解析時間，再檢查MTU、丟包、Wi-Fi信號同幹擾。之後刪除過期嘅網絡位置同配置文件，終止或限制佔用帶寬嘅後台進程，優化mDNS，最後做前後速度測試同延遲檢查。呢個流程唔係隨便諗出嚟，而係來自一個已經成功解決類似問題嘅真實案例。
- 運行 speedtest-cli 診斷問題
- 檢查 DNS 解析時間
- 檢查 MTU、丟包、Wi-Fi 信號同幹擾
- 刪除過期嘅網絡位置同配置文件
- 終止或限制佔用帶寬嘅後台進程
- 優化 mDNS
- 做前後速度測試同延遲檢查
案例驅動提示嘅價值
好多人用AI Agent嗰陣，會將精力放喺寫一個更靚嘅Prompt上。但呢個案例顯示，真正起作用嘅係另一件事：將一個已經跑通嘅操作過程變成AI可以參考嘅工作樣本。原帖提到有用戶將別人優化網絡嘅完整帖子複製俾Codex，然後附上一段好直接嘅請求：「我朋友話佢提高咗網速，呢個係發生嘅過程。你能檢查嚇我哋屋企嘅網絡仲有冇可以改進嘅地方嗎？運營商話佢哋提供1.2Gbps，我而家得55Mbps，請幫我整好，唔好出錯。」
呢段話冇複雜技巧。佢真正有價值嘅部分係前面嗰份真實案例。案例畀咗AI一條路——先測乜嘢、再查乜嘢、邊啲配置可能影響結果、邊啲後台進程值得關注、最後點驗證。呢個比單純講句「幫我優化網速」更清楚，因為「優化網速」只係目標，而案例提供咗路徑。如果直接將任務掉俾Codex，佢可能會從常見網絡問題開始查，但常見問題太寬泛：DNS、MTU、Wi-Fi幹擾、後台進程、系統網絡位置、mDNS，每一項都可能相關或無關。當你將一個真實成功案例畀佢，佢就有咗優先級：先沿已驗證嘅診斷鏈路行，再結合當前機器實際情況調整。呢個就係案例驅動提示嘅價值。
適用場景同提問結構
呢個思路唔只適用於網絡優化。凡是帶有診斷、排查、修復、驗證嘅任務，都好適合用成功案例做上下文。例如電腦變慢、項目構建失敗、數據庫查詢慢、自動化腳本唔穩定、網站加載慢，全部可以揾一個類似嘅成功案例俾AI參考。
- 電腦變慢：俾佢一個完整嘅性能排查案例
- 項目構建失敗：俾佢一段類似項目嘅修復過程
- 數據庫查詢慢：俾佢一個成功優化SQL同索引嘅案例
- 自動化腳本唔穩定：俾佢一個從日誌到修復再到迴歸測試嘅完整樣本
- 網站加載慢：俾佢一次完整嘅Lighthouse優化記錄
作者提供咗一個可以直接套用嘅提問結構，仲建議喺真實環境加入記錄步驟，方便日後複用。呢個結構係：
下面係一個別人已經成功解決類似問題嘅案例。請你先總結呢個案例裏面嘅診斷路徑同關鍵動作。然後結合我當前嘅環境，逐步檢查係咪存在類似問題。每一步都先說明你要檢查乜嘢，再執行命令或者查看配置。唔好直接做高風險修改。修改前先解釋影響，修改後做驗證。
如果係本地電腦、伺服器、項目倉庫呢類真實環境，可以加一句：
請將每一步嘅檢查結果同最終改動記錄低，方便我以後複用。HI 我係陳寶，最近見到一個好有啟發嘅 Codex 用法。
有人用 Codex 優化自己嘅網絡速度，步驟好簡單：
- • 先執行
speedtest-cli診斷問題； - • 檢查 DNS 解析時間；
- • 檢查 MTU、丟包、Wi-Fi 訊號同幹擾；
- • 刪除過期嘅網絡位置同配置檔案；
- • 終止或限制佔用頻寬嘅後台進程；
- • 優化 mDNS；
- • 最後做前後速度測試同延遲檢查。
呢件事有趣嘅地方在於，佢展示咗一個更適合 Agent 類 AI 嘅使用方式：
將真實世界入面已經驗證成功嘅案例，直接作為上下文餵俾 AI。
關鍵唔係 Prompt 有幾靚
好多人用 AI Agent 嘅時候，會將精力放喺寫一個更靚嘅 Prompt 上面。
但係喺呢個案例入面，真正起作用嘅係另一件事：
將一個已經成功執行嘅操作過程，變成 AI 可以參考嘅工作樣本。
原帖入面提到，有用戶將人哋優化網絡嘅完整帖子複製俾 Codex，再附上一段非常直接嘅請求：
我朋友話佢提高咗網速，呢個係發生嘅過程。你可唔可以檢查嚇我哋屋企嘅網絡仲有冇可以改進嘅地方？運營商話佢哋提供嘅係 1.2Gbps，而家我得 55Mbps，請幫我整好，唔好出錯。
呢段話冇複雜技巧。
佢真正有價值嘅部分，係前面嗰份真實案例。
案例畀咗 AI 一條路
Agent 類 AI 擅長執行多步驟任務，但佢需要知道從邊度開始、點樣判斷問題、幾時驗證結果。
一個成功案例啱啱好提供咗呢啲嘢。
佢話俾 Codex 知：
- • 先測乜嘢；
- • 再查乜嘢；
- • 邊啲配置可能影響結果；
- • 邊啲後台進程值得關注；
- • 最後點樣驗證係咪真係變快。
呢個比單純講一句“幫我優化網速”更清楚。
因為“優化網速”只係目標，成功案例提供咗路徑。
等 Codex 參考經驗，而唔係憑空估
如果直接將任務掉俾 Codex，佢可能會從常見網絡問題開始查。
但常見問題太廣泛啦。
DNS、MTU、Wi-Fi 幹擾、後台進程、系統網絡位置、mDNS，每一項都有可能相關，都有可能無關。
當你將一個真實成功案例俾佢，佢就有咗優先級：
先沿住已驗證嘅診斷鏈路行，再結合當前機器嘅實際情況調整。
呢個就係案例驅動提示嘅價值。
佢令 AI 既有參考答案，又唔會機械式照抄。
呢類方法適合咩任務
呢個思路唔止適用於網絡優化。
凡是帶有“診斷、排查、修復、驗證”嘅任務，都好適合用成功案例做上下文。
比如：
- • 電腦變慢咗，等 Codex 參考一次完整嘅性能排查案例；
- • 項目構建失敗咗，畀佢一段類似項目嘅修復過程；
- • 數據庫查詢慢咗，畀佢一個成功優化 SQL 同索引嘅案例；
- • 自動化腳本唔穩定，畀佢一個從日誌到修復再到回歸測試嘅完整樣本；
- • 網站加載慢咗，畀佢一次完整嘅 Lighthouse 優化記錄。
核心動作好簡單：
先揾一個同當前問題相似、而且已經成功解決嘅案例。
然後將佢同自己嘅實際情況一齊交俾 Codex。
更好嘅提問方式
可以直接套用呢個結構：
下面是一個別人已經成功解決類似問題的案例。
請你先總結這個案例裏的診斷路徑和關鍵動作。
然後結合我當前的環境，逐步檢查是否存在類似問題。
每一步都先說明你要檢查什麼，再執行命令或查看配置。
不要直接做高風險修改。
修改前先解釋影響，修改後做驗證。如果係本地電腦、伺服器、項目倉庫呢類真實環境，仲可以加一句：
請把每一步的檢查結果和最終改動記錄下來，方便我以後複用。咁樣 Codex 就更容易由“聊天回答”進入“工程化執行”。
真正值得學嘅地方
唔好淨係畀 AI 一個目標，要畀佢一個成功樣本。
目標令 AI 知道你想去邊。
成功樣本令 AI 知道點樣行。
Agent 類 AI 越嚟越強之後，好多任務嘅關鍵唔再係寫神奇咒語。
關鍵係將真實世界入面有效嘅方法、流程、案例同驗證標準，整理成佢可以執行嘅上下文。
呢個先係更高級嘅提示技巧。
HI 我是陳寶，最近看到一個很有啓發的 Codex 用法。
有人用 Codex 優化自己的網絡速度，流程很簡單：
- • 先運行
speedtest-cli診斷問題； - • 檢查 DNS 解析時間；
- • 檢查 MTU、丟包、Wi-Fi 信號和干擾；
- • 刪除過期的網絡位置和配置文件；
- • 終止或限制佔用帶寬的後台進程；
- • 優化 mDNS；
- • 最後做前後速度測試和延遲檢查。
這件事有意思的地方在於，它展示了一個更適合 Agent 類 AI 的使用方式：
把真實世界裏已經驗證成功的案例，直接作為上下文餵給 AI。
關鍵不在 Prompt 多漂亮
很多人使用 AI Agent 時，會把精力放在寫一個更漂亮的 Prompt 上。
但在這個案例裏，真正起作用的是另一件事：
把一個已經跑通的操作過程，變成 AI 可以參考的工作樣本。
原帖裏提到，有用戶把別人優化網絡的完整帖子複製給 Codex，再附上一段非常直接的請求：
我的朋友說他提高了網速，這是發生的過程。你能檢查一下我們家的網絡還有沒有可以改進的地方嗎？運營商說他們提供的是 1.2Gbps，現在我只有 55Mbps，請幫我修好，別出錯。
這段話沒有複雜技巧。
它真正有價值的部分，是前面那份真實案例。
案例給了 AI 一條路
Agent 類 AI 擅長執行多步驟任務，但它需要知道從哪裏開始、如何判斷問題、什麼時候驗證結果。
一個成功案例剛好提供了這些東西。
它告訴 Codex：
- • 先測什麼；
- • 再查什麼；
- • 哪些配置可能影響結果；
- • 哪些後台進程值得關注；
- • 最後如何驗證是否真的變快。
這比單純說一句“幫我優化網速”更清楚。
因為“優化網速”只是目標，成功案例提供了路徑。
讓 Codex 參考經驗，而不是憑空猜
如果直接把任務丟給 Codex，它也許會從常見網絡問題開始查。
但常見問題太寬泛了。
DNS、MTU、Wi-Fi 干擾、後台進程、系統網絡位置、mDNS，每一項都可能相關，也可能無關。
當你把一個真實成功案例給它，它就有了優先級：
先沿着已驗證的診斷鏈路走，再結合當前機器的實際情況調整。
這就是案例驅動提示的價值。
它讓 AI 既有參考答案，又不會機械照抄。
這類方法適合哪些任務
這個思路不只適用於網絡優化。
凡是帶有“診斷、排查、修復、驗證”的任務，都很適合用成功案例做上下文。
比如：
- • 電腦變慢了，讓 Codex 參考一次完整的性能排查案例；
- • 項目構建失敗了，給它一段類似項目的修復過程；
- • 數據庫查詢慢了，給它一個成功優化 SQL 和索引的案例；
- • 自動化腳本不穩定了，給它一個從日誌到修復再到迴歸測試的完整樣本；
- • 網站加載慢了，給它一次完整的 Lighthouse 優化記錄。
核心動作很簡單：
先找一個和當前問題相似、並且已經成功解決的案例。
然後把它和自己的實際情況一起交給 Codex。
更好的提問方式
可以直接套用這個結構：
下面是一個別人已經成功解決類似問題的案例。
請你先總結這個案例裏的診斷路徑和關鍵動作。
然後結合我當前的環境，逐步檢查是否存在類似問題。
每一步都先說明你要檢查什麼，再執行命令或查看配置。
不要直接做高風險修改。
修改前先解釋影響，修改後做驗證。如果是本地電腦、服務器、項目倉庫這類真實環境，還可以加一句：
請把每一步的檢查結果和最終改動記錄下來，方便我以後複用。這樣 Codex 就更容易從“聊天回答”進入“工程化執行”。
真正值得學的點
不要只給 AI 一個目標，要給它一個成功樣本。
目標讓 AI 知道你想去哪。
成功樣本讓 AI 知道怎麼走。
Agent 類 AI 越來越強之後，很多任務的關鍵不再是寫神奇咒語。
關鍵是把真實世界裏有效的方法、流程、案例和驗證標準，整理成它可以執行的上下文。
這才是更高級的提示技巧。