GrokBot.twGrok Bot 實戰站

pstack 使用導讀（二）：監督比你聰明的代理人

場景

官方人員 @poteto 的 pstack Part 2：間接提問、/teach／/architect、用原型與驗證取代空泛計畫。

本頁目錄
  1. 來源
  2. Part 1 之後要解什麼
  3. 監督比你聰明的人
  4. 用它自己的話再說一次（間接提問）
  5. 用 /teach、/how、/why、/recall 建心智模型
  6. 從 README 往回推：技術寫作與 Diátaxis
  7. 量一百次、裁一次：原型 playbook 與 /control-app
  8. /architect：把大改動拆成紀律階段
  9. 若你真的要一份計畫文件
  10. 實務上怎麼跑（四個例子）
  11. 例子 1：研究含糊的 bug
  12. 例子 2：設計新的服務邊界
  13. 例子 3：多 PR 遷移
  14. 例子 4：修 Slack 上回報的問題
  15. 規劃這門手藝
  16. 本週可打勾清單
  17. 提醒你
  18. 延伸閱讀

來源

這篇是官方人員 @poteto（Lauren）撰寫的系列文導讀，連回原文，非整頁翻譯。作者在 Cursor／Grok Bot 團隊，把個人嚴謹工程技能包做成 pstack。

畫面、選單與權限以你當下環境為準。建議先讀完 Part 1，把驗證技能與 /control-app 打穩，再接這篇的研究、規劃與架構流程。

Part 1 之後要解什麼

Part 1 的核心是：代理人若不能自己驗自己的結果，你就永遠是瓶頸。驗證跑通之後，下一個問題變成：到底該做什麼、怎麼定規格、怎麼在不熟悉的程式庫上仍維持品質。

作者的做法是：用高品質脈絡把代理人「灌滿」，再用原型與驗證回答開放問題；長篇卻無實證的計畫，優先度反而最低。

監督比你聰明的人

以前改系統，你得先讀夠多程式，在腦裡建出心智模型。小改動可能只看局部；大重構則可能要數小時到數月。代理人把「能不能動到程式」這道門檻拿掉了：你提示一句，它就能改，不論你對那包 code 懂多少。

難的是品質與體驗。你若還不是領域專家，就不容易知道該盯什麼、該問什麼。作者常看到兩種失敗：

  1. 意圖沒講清楚：規格不足或講法含糊，代理人抓不住你真正要的。
  2. 脈絡不夠：它不知道正確做法需要哪些背景、慣例與歷史約束。

兩者其實是同一件事：代理人時代的產出品質，很大程度取決於你能不能把高品質脈絡放進上下文視窗。能寫出「能跑」的 code 不難；把品質拉高，靠的是事先給足它做事所需的一切。

用它自己的話再說一次（間接提問）

前沿模型寫 code 的能力已經很強。舊模型時代你可能會把每一步講死；現在比較好的平衡是：說清楚目標與驗收，留下空間讓它用你沒想到的方式解。

作者喜歡一種間接提問：先別把自己的假設塞進去，改請代理人用自己的話把問題壓縮出來。例如 Slack 有人回報問題時：

/poteto-mode read this slack thread. restate in your own words and in plain english what you think the underlying issue is

這樣做有三個好處：

  1. 把吵雜對話壓成結構化問題陳述。
  2. 誤解會立刻浮上來：它若咬住紅鯡魚，你可以在寫任何 code 前糾正。
  3. 你還沒用自己可能錯的假設，把搜尋空間縮死。

這就是「監督比你聰明的人」：在你沒寫過、也塞不進腦裡的大型程式庫上，先對齊問題，再動手。

用 /teach、/how、/why、/recall 建心智模型

請代理人用你聽得懂的方式重述，是跟「比你聰明的人」共事的關鍵。/teach 就是為此而生：它會往下呼叫 /how 與 /why，幫你把系統講到直覺上說得通。

指令 在做什麼 範例
/how 追執行期機制；子系統跨多目錄／服務時，會用快速模型（例如 Grok）平行派探索代理人 /how is virtualization implemented?
/why 查動機與意圖：平行翻 Git／PR 評論、Linear、Notion、Slack、Datadog、Sentry、程式血統、分析倉事件等歷史證據 /why are we still stuck an old version of node.js?
/teach 明確要求它教你：為什麼這樣做、取捨是什麼 /teach me why you implemented it this way and not <other way>. what were the tradeoffs you made and why?
/recall 從近期對話紀錄撈脈絡，讓新開的代理人回到可用狀態 /recall the work i did yesterday on virtualization and then read this bug report on slack

/teach 的研究對人類與代理人都有用：它逼代理人用資料支撐自信主張，也逼它真的讀夠 code，建出可用的心智模型。/how、/why、/teach、/recall 一起用，能把維護者對程式庫的理解維持在最新、可壓縮、好記的狀態。

從 README 往回推：技術寫作與 Diátaxis

問題對齊之後，怎麼定解法？

多數 Plan Mode 會把實作細節寫過頭，卻把「使用者怎麼用、文件怎麼讀、怎樣算完成」講太少。作者半開玩笑說自己「不相信規劃」：真正的做法是用 code 來規劃。

對共用套件，作者推薦 README-driven development：先寫 README，用假設使用者的視角描述 API，再往回推實作與架構。自家桌面客戶端框架 Dune 的第一份產物，就是一篇「用它做 App 會是什麼感覺」的教學文。

/technical-writing 技能套用 Diátaxis 四種文件模式：

模式 給誰 作用
Tutorial（教學） 新手 照步驟做出看得見的東西，邊做邊學
How-to（操作指南） 有經驗的人 解特定真實問題的步驟
Reference（參考） 查詢者 乾淨、完整、權威的 API／設定說明
Explanation（說明） 想懂背景的人 設計選擇、取捨與脈絡

它也會搭配 /unslop，讓文件好讀。面向 code 的計畫，等於給代理人一個可對照的具體目標，也讓你自己看得懂「打算建什麼」。

複合提示範例：

  1. /recall my work fixing virtualization bugs and perf issues from the past 7 days. use /how and /why to understand how our current virtualization implementation works.
  2. then use /poteto-mode planning and /technical-writing to come up with a new virtualization engine that categorically eliminates flickering and jittering. let's start by writing a tutorial on how i would use this new package to virtualize a React app
  3. after you write the plan, /teach me and prove to me why this new approach is superior to our current engine

第一段撈脈絡；第二段對已知失敗設計；第三段要求用驗證技能提出證據，證明新做法更好。

量一百次、裁一次：原型 playbook 與 /control-app

規劃常見兩種失誤：

  • 直接收下代理人的第一版設計。
  • 把計畫煮過頭，卻沒有實證。

pstack 的解法是平行代理人加上原型 playbook。Playbook 是 /poteto-mode 內的參考檔，條件載入以省 token；到 pstack 0.15.0 約有 23 份。與技能不同，它們會被 /poteto-mode 自動套用。

常用提示：

/poteto-mode prototype a few options for the new dropdown menu

/poteto-mode fix this bug

/poteto-mode eval this skill change

/poteto-mode prototype a few options for 〈功能需求〉. use /control-app and take videos/screenshots for me to review and choose from

/control-app 就是 Part 1 做出來的驗證技能。原型讓代理人多試幾條路，並用證據說明哪條比較好。視覺變更時，它可在 App 或暫存目錄做丟棄式草圖、用簡單切換器擺出 UI 變體，再用 /control-app 驅動、截圖、量時間或版面。

一句話：原型就是用 code 規劃。 它讓代理人探索、端出你沒想到的選項，並用實證回答問題，減少你得先填滿每一個細節才能開工的等待。

/architect：把大改動拆成紀律階段

作者認為：在代理人時代，工程師該把時間花在架構、資料結構、系統怎麼接起來；實作細節交給代理人填。

/architect 把設計收成幾個階段：

  1. Ground（落地問題）：對受影響系統跑 /how、/why，弄清所有權與約束。
  2. Sketch（草圖）：進入架構競技場；平行派出獨立候選 runner（常跨不同模型家族）。每個拿到落地簡報後，產出完整設計包：呼叫端用法草圖、核心型別、公開函式簽名、理由。並評估介面深度、弱模型失敗模式、設計紅旗。
  3. Cross-judge（交叉評審與綜合）：換成另一個模型當裁判，依嚴格評分表評候選。
  4. Implement against the sketch（依草圖實作）：把占位實作換成真邏輯；若實作需要意外參數或狀態，主動浮出落差。
  5. Scrap when wrong（錯了就丟掉）：實證顯示草圖錯了，就整包丟棄重來。

跨無關呼叫點反覆出現同一套 workaround，或型別需要 any、強行轉型這類逃生艙，都是「架構錯了」的實證訊號。

/architect this new 〈功能需求〉

重點：用 /poteto-mode 原型與 /architect 規劃，少去對抗式審一長串抽象計畫。開放問題交給原型與驗證回答；別太早發明理論上的邊角案例。

若你真的要一份計畫文件

pstack 沒有獨立的 planning skill，但有多階段 planning playbook，把已接受的設計轉成戰術執行計畫：

/poteto-mode turn this design into a plan

每個任務都圍繞證明與驗證：單有測試不夠，code 必須真的能跑、能驗。自動化腳本會檢查計畫結構與格式。核准後逐項執行，每個 PR 保持小、自足、可審。

跨一週的工作，可暫時把計畫 commit 進 repo，讓其他代理人看得見進度；完成後再刪，避免留下令人困惑的殘留狀態。

實務上怎麼跑（四個例子）

例子 1：研究含糊的 bug

/poteto-mode investigate why background workers periodically fail with timeout errors. give me a breakdown of what we know, what data you used, and your best hypotheses.

代理人會平行探程式、指標與歷史 commit，再交回證據與最佳假設。

例子 2：設計新的服務邊界

/poteto-mode we need to add rate limiting for external webhooks. /architect this first, and answer any open questions with prototypes. let me review before proceeding.

它會先落地現有 webhook 架構，跨模型跑競爭設計，用丟棄式原型量測，再交出乾淨、已驗證的介面。

例子 3：多 PR 遷移

/poteto-mode create a plan to migrate our entire UI library to StyleX. break the migration into small, verifiable PRs. each PR must have its visual regression tests and live verification steps. i want the final result to be 100% identical compared to the original - bugs included

產出可獨立驗證的步驟、可稽核清單，以及可安全落地的小單位。

例子 4：修 Slack 上回報的問題

執行緒脈絡已經夠時：

/poteto-mode do it

需要重現與證明時：

/poteto-mode repro this with /control-app. if it repros on main, fix it and show me a video as proof

許多技能會被 /poteto-mode 自動帶上，所以預設常常就是直接用它。

規劃這門手藝

Plan Mode 容易變成「說服自己代理人會做對」的儀式。抽象長計畫看起來很有進度，可能其實沒有實質內容。

pstack 把徹底調查、實證與嚴格驗證綁在一起，讓代理人時代的工程變得可預期、可重複。

本週可打勾清單

  • 已讀完 Part 1 導讀，驗證技能與 /control-app 可用
  • 會用間接提問：先請代理人用自己的話重述問題，再動手
  • 試過 /how、/why、/teach、/recall 建心智模型
  • 共用套件先寫 README／教學，再用 /technical-writing（Diátaxis）定文件模式
  • 大功能先 /poteto-mode prototype，並用 /control-app 截圖或錄影比較選項
  • 架構級改動走 /architect 五階段，錯了敢 scrap
  • 設計定案後才 /poteto-mode turn this design into a plan；PR 維持小且可驗
  • 合併進正式分支仍走人工核可；提示與技能裡不貼密鑰、token、OTP

提醒你

  • 排程與例行任務時區用 Asia/Taipei，避免被 UTC 半夜通知洗版。
  • 不要把密碼、金鑰、OTP 貼進提示或技能檔；憑證走產品支援的安全交接。
  • 自動重現與自動修可以開，合併與發版先停在你核可。
  • 先別把代理人第一版抽象設計當定案；先用原型與驗證回答開放問題。

延伸閱讀