<!-- grokbot.tw · 非 SpaceXAI／xAI 官方文件 · 步驟以你畫面為準 · 來源：https://grokbot.tw/workflows/pstack-guide-pt2-zh/ -->

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

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

## 來源

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

- 宣告貼文：[I'm writing a guide to pstack! Here's part two.](https://x.com/poteto/status/2097732320606507506)
- 原文長文：[The Complete Guide to pstack Pt. 2](https://x.com/i/article/2094940651607715840)
- 上一篇導讀：[pstack 使用導讀（一）：驗證技能是基礎建設](https://grokbot.tw/workflows/pstack-guide-pt1-zh/)
- Grok Bot 外掛：[pstack plugin](https://x.ai/bot/plugin/9717366)

畫面、選單與權限以你當下環境為準。建議先讀完 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](https://diataxis.fr/) 四種文件模式：

| 模式 | 給誰 | 作用 |
| --- | --- | --- |
| **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 導讀](https://grokbot.tw/workflows/pstack-guide-pt1-zh/)，驗證技能與 `/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 貼進提示或技能檔；憑證走產品支援的安全交接。
- 自動重現與自動修可以開，**合併與發版先停在你核可**。
- 先別把代理人第一版抽象設計當定案；先用原型與驗證回答開放問題。

## 延伸閱讀

- 原文系列：[pstack Pt. 2](https://x.com/i/article/2094940651607715840)
- [pstack 使用導讀（一）：驗證技能是基礎建設](https://grokbot.tw/workflows/pstack-guide-pt1-zh/)
- [官方文件導讀：技能、例行任務與自動化](https://grokbot.tw/workflows/docs-skills-routines-zh/)
- [工程艦隊縮小版：用 Grok Bot 管雲端代理人](https://grokbot.tw/guides/official-engineering-zh/)
- Diátaxis 框架：[diataxis.fr](https://diataxis.fr/)

## 來源
- 本頁：https://grokbot.tw/workflows/pstack-guide-pt2-zh/
- 原文／公告：https://x.com/poteto/status/2097732320606507506