第 1 章／共 7 章
接到任務的第一分鐘
總機怎麼分流
AI 接到一件事，動手之前要先做四個判斷。這一章用一家餐廳來講：誰接單、照哪份食譜、什麼時候該問客人、什麼時候一定要停。
- 要不要走流程？
- 對到哪份劇本？
- 真的要問人嗎？
- 自己做，還是停？
開場為什麼需要規矩
AI 寫程式代理（agent，會自己讀檔、跑指令、改程式的 AI）有三個老毛病：
- i.跳步驟
- ii.沒驗證就說做完
- iii.寫得又長又囉嗦
pstack 像一家餐廳的主廚加一本食譜。主廚（poteto-mode）看了點單，決定照哪份食譜做。二廚是子代理。出餐前一定要獨立試菜員點頭。
- 點單你交代的任務
- 主廚poteto-mode
- 食譜劇本（playbook）
- 二廚子代理
- 試菜員獨立審查
主廚看點單、挑食譜，二廚動手，試菜員點頭才出餐。
pstack 用三道關卡壓住這三個毛病。
接到任務先判斷走哪條路
每類任務一份逐步照做的劇本（playbook）
沒有別人審過就不放行
原文與出處
README 的主張：告訴 poteto-mode 你的目標，它會挑對的工作流程，讓程式精簡、簡單、驗證過（README.md:7）。
Tell poteto-mode your goal and it will invoke the correct workflow for the task. It keeps your code concise, simple and verified.
第一個判斷這件事要不要走流程？
不是每件事都要開會。換燈泡直接換，改房子格局才要畫圖。
走流程的三個條件，命中任一條，就叫總機（poteto-mode）。
- 動到不只一個檔，或改了「別的檔案也在用」的介面。 介面在這裡指函式簽名，也就是一個功能要吃什麼、吐什麼的規格。 白話：牽一髮動全身。
- 牽涉設計或架構的選擇。 白話：要決定房子格局，不是換燈泡。
- 原因還不知道的 bug，或效能問題。 白話：病因不明，要先檢查再開藥。
小事直接做
- 單一檔案裡的小改，而且有明顯的測試
- 單純提問
- 一行修改
直接做也有條件：要在真的成品上驗證。
打開真的畫面、跑真的程式看，不能只說「應該好了」。
明確意圖已經很清楚
直接叫專門工具，不必再經過總機。
tdd先寫測試再寫程式architect先畫設計圖how看懂系統怎麼運作why查它為什麼長這樣arena比稿interrogate找多個模型來拷問設計原文與出處
- 三個條件：
plugins/pstack/hooks/session-start-context.md:4-8 - 小事直接做、在真的成品上驗證：
plugins/pstack/hooks/session-start-context.md:10 - 直接叫專門工具：
plugins/pstack/hooks/session-start-context.md:12 - 使用者指令優先：
plugins/pstack/hooks/session-start-context.md:14 - 這段規則每次開新對話、恢復、清空、壓縮時，自動塞進對話（
plugins/pstack/hooks/hooks.json:5）。
Invoke the pstack:poteto-mode skill and follow its instructions when a task meets any of these:
- it touches more than one file, or changes a signature other files call
- it involves a design or architecture choice
- it is a bug whose cause is not yet known, or a performance issue
It routes to the right pstack skill from there. For smaller tasks, such as a contained change to one file with an obvious test, a question, or a one-line edit, work directly and verify on the real artifact.
第二個判斷對到哪一份劇本？
總機手上有 23 份劇本（playbook）。像醫院掛號，先分科，再照那一科的流程看診。
常用的劇本分成四類。點一類，看裡面有哪幾份。
這裡只列常用的幾份，完整清單在原文。
PR（pull request）是把一批改動交給人審，通過後再合進主線的機制。
原文與出處
- 23 份劇本清單：
plugins/pstack/skills/poteto-mode/SKILL.md:134-156 - figure-it-out 與 Orchestrate 的分流：
plugins/pstack/skills/poteto-mode/SKILL.md:132 - 其他劇本都接 Opening a PR：
plugins/pstack/skills/poteto-mode/SKILL.md:156 - 唯讀調查不開 PR：
plugins/pstack/skills/poteto-mode/playbooks/investigation.md:5、:12
第三個判斷真的需要問人嗎？
想問廚師「這道菜鹹不鹹」，不如自己嚐一口。可是「客人喜歡偏甜還是偏鹹」，只能問客人。
AI 準備問「要用哪個做法」之前，先分類。
嚐一口跑一次就看得到
行為、速度、版面、輸出、效能。
不是人該回答的。先做原型，讓結果決定。
問客人沒有實驗能決定
產品方向、個人偏好。
這種才問人。
原型的做法（Prototype 劇本）
- 先講清楚這個原型要幫忙做哪個決定。沒有要做的決定，就不做原型。
- 方向還很開放時，先找參考，讓人挑方向。
- 放在隔離的草稿資料夾，用最輕的工具做，不寫測試、不做抽象。
- 要比較的幾個版本，放在同一個切換器後面，每版標好名字。
- 每一版都實際截圖看過、實際操作過。
- 交出幾個版本的比較、各自的取捨與推薦。原型用完就丟，正式版另外照 Feature 劇本做。
彩蛋
這份教材的 A、B、C 三個版本，就是照這條做的。三版放在同一個切換器後面，各自截圖驗過。挑哪一版是偏好題，沒有實驗能替你決定，所以留給你。原型用完就丟，你現在讀的這一頁，是挑完之後另外做的正式版。
原文與出處
- 問人前先分類：
plugins/pstack/skills/poteto-mode/SKILL.md:23 - 原型劇本六步：
plugins/pstack/skills/poteto-mode/playbooks/prototype.md:3-14 - 做 2 到 3 個競爭原型：
plugins/pstack/skills/principle-exhaust-the-design-space/SKILL.md:3
If the answer is a fact you could observe by running something (behavior, timing, layout, output, perf, even whether an eval separates), it is not the human's to answer. Sketch it via the Prototype playbook (playbooks/prototype.md) and let the result decide. … Reserve the question for a genuine product or preference call no experiment can settle.
第四個判斷可以自己做，還是一定要停？
鉛筆寫的直接寫，寫錯擦掉就好。原子筆簽合約，一定先停下來確認。
鉛筆可以反悔
寫程式、改筆記、拆任務。
直接做。做完把結果給人看，讓人事後修正。
卡著等人回覆，通常比做錯一次更貴。
原子筆不能反悔
- 強制覆蓋共用分支（force push）
- 部署上線
- 刪資料
- 對客戶發訊息
一定停下來問。
我們家呢？選讀
- 我們有更細的授權紅綠黃燈對照表，比 pstack 的三分法更嚴。
- pstack 認為團隊群組的訊息不用問；我們的規矩是對內訊息也先給魁哥過目。
原文與出處
- 自主權三分法：
plugins/pstack/skills/poteto-mode/SKILL.md:86-94 - 不要卡在人身上：
plugins/pstack/skills/principle-never-block-on-the-human/SKILL.md:9-15
練習總機上工：8 張任務卡
四個判斷合在一起用。你是總機，把每張任務卡分到一扇門，選完立刻看理由。8 張都分完，就會看到分數。