把計畫寫在票上 — 用標記協定串起 Plan / Forge / Review

2026-06-25 · 9 min read

說明： 本文由 AI（Claude）根據我的初始筆記與想法完成。

最近我在整理自己跑 AI agent 的方式，發現一個一直被我忽略的問題：agent 的狀態到底存在哪裡？

大部分時候，它存在聊天視窗裡。你在桌面 app 開一個對話，跟它討論一個功能，它幫你規劃、寫程式、改 bug——整段過程的脈絡，全都活在那條捲動的訊息流裡。聽起來很自然，但這條訊息流其實非常脆弱。

聊天視窗是 RAM，不是硬碟

桌面聊天有三個先天的限制：

• 它是揮發性的。 計畫一旦被新的訊息往上推走，就很難再翻回來。關掉視窗、清掉脈絡，剛剛談好的東西就煙消雲散。
• 它是單一 session 的。 我換一台電腦、或明天開一個新對話，它對昨天談過什麼一無所知。每個 session 都是一座孤島。
• 它是單人的。 我的隊友看不到我跟 agent 聊了什麼。那段討論只屬於我，沒有第二雙眼睛能審。

換句話說，聊天視窗是 RAM——快、好用、但斷電就沒了。我們卻把整個工作流程的狀態都放在 RAM 上，沒有一個真正能落地、能被別人讀到、能跨越 session 存活的家。

把狀態抬到 issue tracker 上

我的解法說穿了很簡單：別把 agent 的狀態留在聊天裡，把它抬到 issue tracker 的留言串上。

每一份計畫、每一個提問、每一個裁決，都是票上的一則留言。我給自己的這套 Claude Code 設定（叫 skadi）定了一句話：「留言串就是紀錄。沒有旁路。」聊天視窗是你跟 agent 講話的地方；票，才是狀態真正存放的地方。

YouTrack 也好、Jira 也好，你的團隊本來就信任這個地方——它有歷史、有權限、有通知、人人看得到。把 agent 的工作流綁在這上面，等於免費換來了持久化、可審計、跨 session、多人協作。

接下來是三個階段：規劃、鍛造、審查。每個階段都用一個小小的標記（marker）當作彼此之間、也當作人與機器之間的契約。

規劃 — 計畫先寫成留言

第一步是規劃。我跑 /council，它派出一個 subagent（我叫它 Erestor），讀完整張票之後，草擬一份計畫，直接貼成一則留言，開頭標上 [PLAN]。

然後它就停下來，等我裁決。我看過之後，回一則 [APPROVE]（核准、放行）或 [REJECT]（打回）。

這裡的關鍵是：核准這個動作本身，是一則留言，不是一句聊天。 我可以今天讓它草擬計畫，明天才回去按核准。Erestor 只負責「讀、擬、問」，從不替我做決定——用 skadi 裡的話說，「Erestor 出謀，Elrond 定奪」。每一個放行的閘門都握在人手上，而那個閘門被寫進了票裡，不會隨對話飄走。

鍛造 — 讓 PR 自己回到票上

計畫核准了，第二步是鍛造。我跑 /celebrimbor，它做的第一件事，是回去讀那條留言串——找到 [PLAN] 加上 [APPROVE]，確認這份計畫有人草擬、也有人放行。

然後它照著計畫實作，開一個 draft PR/MR，再把 PR 的網址貼回票上，標成 [FORGED]。

我覺得這一步最能說明整套設計的意義：鍛造階段的輸入，是它自己從留言串讀到的，它從來不需要當初規劃時的那段聊天。 規劃和鍛造可以是兩個完全不同的 session、甚至兩個不同的人。skadi 裡是這麼寫的：「留言串依舊是紀錄。PR 的網址會以 [FORGED] 回到票上，好讓謀議與鍛造始終同步。」

審查 — 一樣串在票上

第三步是審查。我有兩把工具：

• /mithrandir 跑一份多軸的評斷——穩定性、效能、風格、可維護性、正確性——最後收斂成一個結論：Merge、Hold，還是 Refuse。
• /narvi 則負責回覆 PR 上的留言，一則留言對一個 commit，逐條把意見落實成程式碼。

這些一樣串在票與 PR 上。審查不是某個人腦袋裡的判斷，而是一筆可以被讀到、被回溯的紀錄。

標記，其實是一台用留言寫成的狀態機

把這幾個標記排在一起看，會發現它們就是一台狀態機：

[PLAN]  →  [APPROVE]  →  [FORGED]  →  [METTA]
 計畫草擬      人放行       PR 已開       已合併

（中間還有些小標記：[REJECT] 打回、[SKELETON] 先搭骨架、[BASE: branch] 指定基底分支。）

標記本身用的是平實的字眼；至於 /council、/celebrimbor 這些指令名，才是借了托爾金《魔戒》裡瑞文戴爾議會的典故——是調味，不是主菜。重點是：任何一個 session、任何一個階段，都能靠著讀那條留言串，重建出「現在這件事走到哪了」。 狀態不在誰的腦袋裡，也不在哪個關掉就消失的視窗裡，而在票上，白紙黑字。

抬上去之後，解鎖了什麼

一旦狀態落在團隊本就信任的基底上，原本卡在聊天視窗裡的東西就鬆開了：非同步（今天規劃、明天核准、後天鍛造）、跨 session（換台電腦、開個新對話都接得上）、多人（隊友讀得到、審得了）、可審計（每一步都留痕）。甚至可以有掃描器（skadi 裡叫 /glorfindel、/rhovanion）定時掃過所有票，從標記接著往下推——因為要接手的所有資訊，都已經在票上了。

一個誠實的但書

得先說清楚：這套做法我目前只在小任務上驗證過——範圍清楚、一兩個檔案就能收掉的那種。換到大任務上，摩擦就明顯變多：計畫本身的精確度不夠，鍛造階段照著做就會走偏。要讓大任務也吃這套，還缺一塊東西——某種能把計畫內容打磨得更精準的機制。那是下一步，現在還沒到。

一句話收尾

所以這就是我現在的做法：不把 agent 的狀態留在聊天裡，而是抬到團隊本來就信任的那個基底上——issue tracker——再用一套小小的標記協定，當作階段與階段之間、人與機器之間的契約。聊天是 RAM，票是硬碟。把計畫寫在票上，狀態就有了一個能落地、能被讀到、能跨 session 存活的家。