pstack 實戰：3 個案例，5 個讓 agent 更好用的技巧

快速摘要

這篇用三個案例介紹 pstack：用 prototypes 比較網站設計，避免太早選定方向；用 baseline 和 trace 找出 app 的效能瓶頸；和利用程式與歷史對話找回先前的決策脈絡。

另外整理五個實用技巧：用 /in-your-own-words 確認 agent 理解了問題、用 /teach 理解設計取捨、用 /technical-writing 和 /unslop 把文件寫清楚、用 /reflect 回顧合作並提出 skill 改善建議，以及寫清楚成功條件。

Agent 很快就能開始寫程式，但有些問題得先弄清楚：這個介面是對的方向嗎？App 慢在哪裡？上次為什麼選了這種做法？

這篇是 pstack 系列的最後一篇。我要用三個案例，把前面介紹的工具放進實際工作，再談五個能直接用在下一次對話裡的技巧。

案例一：設計網站前端，先看幾個不同方向

假設你要做一個介紹自己作品的網站，請 agent 設計首頁。第一版出來後，你開始調整配色、字體和間距，改了幾輪，整個網站的方向也跟著定下來了。

但第一版只是其中一種可能。太早選定它，後面就容易一直在同一個版型裡修改，等到發現作品不好瀏覽、重要內容被埋在下面，才得重新調整整體設計。

可以先請 agent 用同一份內容，做出幾種不同的 frontend prototype。例如，一版用大圖呈現代表作品，一版用卡片方便瀏覽多個專案，另一版則像文章一樣，帶讀者依序了解你的背景與作品。

把它們放進瀏覽器，你就能比較首頁先看到什麼、往下捲動時內容如何展開，以及手機上的閱讀感受。這些差異看過實際頁面後，比只說「我想要簡潔一點」更容易討論。

Lauren 在 Part 2 用「Measure a hundred times, cut once」來形容這個做法：量一百次，再下刀。她提醒，常見的問題是直接接受 agent 的第一個設計，或在沒有實際證據的情況下，不斷把計畫寫得更細。

透過平行 agents 試出不同方案，再用實際結果選擇方向，比一直修改第一版更有機會找到原本沒想到的設計。

/poteto-mode
幫我的作品集網站做三種不同方向的 frontend prototype，使用相同的自我介紹與作品內容。
先用提供的內容與本機資料完成頁面，等我選定設計方向後，再接後端與其他功能。

看完後，你可以直接指出喜歡哪一版的內容安排、哪一版的視覺風格，再請 agent 整合。

案例二：App 載入很慢，先找出卡在哪裡

「幫我把 app 變快」給了 agent 一個目標，卻沒有告訴它問題在哪裡。它可以改出一份看似合理的優化，但修改的地方不一定是使用者正在等的地方。

Lauren 的 Part 1 用改善初始載入示範這個流程：先取得 trace，找改善的機會，修改後再確認效果。

Baseline 是修改前的基準；profiling 則是量測程式執行時的情況。Trace 把記錄到的工作放在時間軸上，幫助你追查等待發生在哪個環節。

例如，畫面遲遲不能操作，可能和載入資料有關，也可能是處理資料或畫面更新花了時間。先量測，才能決定接下來該追哪一段。

/poteto-mode
改善這個 app 從啟動到主要畫面可操作的時間。
先取得 baseline trace，找出值得優先處理的瓶頸，再做針對性修改。用相同條件重複量測前後結果，並使用專案的 verification skill 確認主要操作仍然正常。

比較時要留意 cache 和執行條件。第二次開啟本來就可能因為 cache 而更快；比較時要分開看 cold cache 和 warm cache，也就是尚未建立快取與已有快取的情況。

根據前後量測的結果，保留有效的修改，撤回沒有改善效能、卻增加複雜度的改動。

案例三：換了 chat，找回藏在程式和對話裡的決定

做了一半的專案，隔幾天再打開新 chat，有時候會忘記爲什麼之前做這樣的改動決定。

有些決定留在另一段對話，有些只在 commit 裡提過，有些已經變成程式的一部分。新的 agent 如果只看眼前的需求，就可能重新嘗試已經放棄的方案，或刪掉一段其實有原因的處理。

這是 context recovery 要解決的問題：找回先前的脈絡，再確認現在的專案是否仍然符合那些決定。

pstack 的 /recall、/how 和 /why 分別提供找回工作脈絡、理解目前運作方式、追查設計理由的入口。Lauren 在 Part 2 用跨聊天處理 Cursor 問題的經驗說明這件事。

以開發一個批量文章轉 IG 卡片的工具為例：如果預覽和匯出各有一套處理流程，先查它們為什麼分開。這可能是為了處理某項限制，也可能只是開發過程留下來的寫法。程式碼能說明現在怎麼運作，當初為什麼這樣選，還得從歷史紀錄裡找依據。

/poteto-mode
接續這個卡片工具的工作。先用 /recall 找回可讀取的相關對話，再用 /how 和 /why 查清楚預覽與匯出目前怎麼運作、為什麼分開。
整理已做的決定、試過的方案和未解問題，附上依據。

Agent 能查到哪些聊天紀錄，取決於使用的工具與存取權限；缺少的對話可以另外提供。舊紀錄也要和目前的程式對照，因為後來的修改可能已經改變原本的前提。

五個可以帶進下一次對話的 Skill

1. /in-your-own-words：先確認 agent 理解了問題

使用者說「卡片編輯起來很卡」，可能是在說反應慢，也可能是在說操作步驟太多。Agent 若理解錯誤，後續做得再完整，也解決不了原本的困擾。

這就是 intent alignment：先確認雙方在處理同一件事。貼上原始回饋後，用 /in-your-own-words 請 agent 重述它理解的目標與問題。

你也可以補一句：「把觀察到的現象和推測的原因分開說明。」先別把原因定為 rendering 問題，讓 agent 查清楚使用者說的「卡」是什麼意思。

這就是 intent alignment。檢查重述的內容時，也要留意 agent 是否把推測當成事實，或漏掉你在意的限制。

2. /teach：理解選擇背後的 tradeoffs

要判斷 agent 提出的設計，你需要知道程式如何運作、有哪些選擇，以及每種做法的代價。

/teach 結合 /how 與 /why，解釋程式的運作方式和設計理由，幫你建立 mental model。說明應以程式碼和歷史紀錄為依據，並區分已知的理由與推測。

3. /technical-writing 和 /unslop：把文件寫清楚

操作步驟、設計理由和參數說明混在一起，會讓讀者難以找到需要的資訊。/technical-writing 先用 Diátaxis 區分文件用途，再安排內容與結構。

Tutorial 帶新手動手做，how-to 協助完成特定任務，reference 提供查閱，explanation 解釋原理。確定用途後，再檢查步驟、預期結果與說明是否符合讀者的需求。

/unslop 則檢查句子，刪改 AI 的空話、重複總結、刻意對比和難讀的長句。修改時保留事實、限制與必要的技術細節。

4. /reflect：回顧這次合作，整理 skill 的改善建議

一段工作告一段落後，可以回頭檢查哪些錯誤重複出現、哪些做法值得保留。/reflect 會檢視目前的對話，從判斷、工具使用與其他可能做法，找出能改善後續工作的經驗。

其中一項檢查是：哪些資訊其實可以由 agent 自己取得，卻一直需要你手動提供？它會根據對話中的具體紀錄，把改善建議對應到負責這段流程的 skill。

它的重點是把這次合作中值得沿用的經驗整理進 skills。/reflect 會先提出建議，經你確認後才修改 skill，讓之後的任務能沿用這次的修正。

5. 把成功條件寫清楚，實作方法留有空間

目標太模糊，很難判斷工作是否完成；一開始就指定每個實作細節，又可能排除其他合適的做法。

Acceptance criteria 是用來驗收的條件。先說清楚要達成的行為、必須保留的限制，以及如何確認結果，再讓 agent 提出實作方案。