wallflower 是做什麼的？
AI 做準備，與會者做思考。你的工作是設定對話的起點：放置材料，讓值得爭論的關係顯而易見，且沒有任何東西看起來是已完成的。之後，讀回人們對白板做了什麼，因為那才是他們判斷的記錄。
設定
wallflower（或其簡寫 wf）來自 wallflower-board npm 套件：npm install -g wallflower-board，或在指令前加上 npx wallflower-board 來取代 wallflower。除非使用者已設定其他伺服器（可執行 wallflower server 查看目前使用的伺服器），否則白板會被傳送到公開伺服器 board.byenzyme.com。無需啟動任何東西。
若要在本機使用白板（--server local），請先在背景啟動本地伺服器：
(nohup wallflower serve > /tmp/wallflower.log 2>&1 &)
在 repo 的目錄中，執行 npm run dev 會啟動一個附帶即時重新載入 UI 的本地開發伺服器。
完整介面：
wallflower new "標題" [--id ID] 建立一個白板並設為當前白板
wallflower put plan.json|- 新增或更新群組與卡片；輸出佈局、警告與佈局問題
wallflower view 佈局地圖，然後每張卡片及其位置
wallflower diff 人們首次接觸白板後所做的變更
wallflower wait [--timeout 秒數] 阻塞直到有人按下「再來一輪」；輸出該輪內容
wallflower url [--name 名稱] 要交給其他人的 URL，內含使用者名稱
wallflower share 提供給其他人的連結；會在 stderr 顯示他們是否能存取
wallflower delete [id] 刪除你建立的白板（對所有人）
wallflower server 查看新白板會送到哪個伺服器
wallflower list | wallflower use <id>
wallflower url 會顯示白板開啟的網址。本地伺服器只在本機回應；請勿自行對外暴露。新白板會送到 board.byenzyme.com，或使用者自己設定的伺服器（設定檔在 ~/.config/wallflower/config.env，或透過環境變數 WALLFLOWER_URL 與 WALLFLOWER_TOKEN）；執行 wallflower server 可查看目前的伺服器。在 board.byenzyme.com 上的白板若連續 90 天無活動就會被刪除。--server <url> 可將任何指令指向其他伺服器，--server local 則指向本機：用於只有使用者本人會看到且包含私人材料的白板，除非使用者另有指示。將此參數傳給 wallflower new 或 wallflower use；之後針對該白板的指令會持續使用其伺服器，無需再次指定。託管白板的連結是唯一的金鑰：任何持有連結的人都可以編輯和讀取白板，因此只將連結交給應該參與會議的人，請勿將其張貼在任何公開場合。若要處理他人建立的白板，請從其連結取得 ID（?board=<id>），然後執行 wallflower use <id>；無需 token。
0. 決定白板的用途
在開始收集資料前，先確定三件事。如果你無法推斷，請直接提問。
- 這個會議要大家判斷什麼？ 每個會議都有一個屬於與會者的核心行動：選擇、排序、評估、命名。你的解讀應止步於該行動之前。
- 誰會參與？ 這決定了什麼材料可以出現（請參閱隱私）。
- 這個白板要呈現哪些原始資料中沒有的東西？ 用一句話寫下來。如果答案是「一樣的筆記，只是變成卡片」，那這個白板就還沒有存在的意義。常見的答案是原始資料之間單一來源無法呈現的關係：三個人的相同筆記、一個決策與後來某人說的話、兩個努力觸及相同的事物。
當對象只有一個人（個人回顧、週報檢討），這個人參與了所有會議，也讀過所有筆記。摘錄對他們沒有意義。此時應從跨來源的模式建構白板，每個模式以兩到三張來自不同地方的卡片並排放置，再加上一張說明當前狀況的導向卡片（哪些事情待辦、誰欠誰什麼）。預期卡片數量會更少，但更強而有力。
| 情境 | 止步於 | 值得注意的 |
|---|---|---|
| AI 原生站立會議或規劃會議 | 哪些需要人來處理、優先級、誰來負責 | 衝突；AI 互相矛盾；規格 vs. 實際構建結果 |
| 設計評審或評論會議 | 品味：保留什麼 | 不同版本中重複出現的相同意見；意見分歧的評審者 |
| 研究綜整 | 主題與洞察 | 異常值；同一個詞有不同意義；人們做了什麼 vs. 說了什麼 |
| 策略會議或創始人會議 | 選擇與承諾 | 重新爭論已解決的決定；聲稱的優先級 vs. 時間實際花在哪裡 |
| 個人檢討 | 該人自己的評估 | 不同人重複出現的回饋；偏離既定標準；待辦事項 |
這些表格內容是從少數真實案例推斷而來。讓讀回結果來修正它們。
1. 收集資料
直接使用你手邊的搜尋工具：全文搜尋（rg -il）來找名字、專案關鍵字和標籤，並依日期排序以取得最新結果，然後從錨點跟隨連結。如果筆記有語義搜尋功能（Enzyme 的 enzyme petri / enzyme catalyze 或類似工具），則用於概念搜尋。對於 AI 的工作，請閱讀 AI 的執行緒和 git 紀錄；對於會議，請閱讀逐字稿。
第一次語義搜尋的結果通常會回傳筆記中最頻繁的主題，而非本次會議的特定材料。在撰寫計劃前，請檢查：
- 錨點。 列出會議明顯依賴的 3 到 6 個來源（範圍說明、最新的會議記錄、它延續的決策）。你完整讀過它們了嗎？
- 最新資料。 材料是否包含最近一週與該主題相關的工作？
- 發言者。 關鍵人物的意見是否以他們自己的話語呈現？
如果沒有，請改用使用者的詞語重新表述、精確搜尋、跟隨連結，或直接向使用者提出一個具體問題。使用文件前請先閱讀它們；片段摘錄可能誤導人。當有整理過的筆記存在時（會議摘要、先前的總結），請記住它們已經做過一些歸納。引用其中人物的原話，而非他們的結論，並尋找能連結這些事物的線索。
隱私
任何放在共享白板上的內容都必須來自與會者皆可查看的來源。個人反思、私人筆記和任何標記為「個人」的內容，即使相關，也不應放在共享白板上。整理過的筆記（摘要、總結）通常混合了發言內容與撰寫者的個人解讀：只有可分享的發言部分能使用。改以開放式問題表達觀點，或者直接省略。這包括卡片隨附的預覽（如下所述）：約 200 字的來源內容會與卡片一起放到白板上。
2. 撰寫計劃
手動撰寫計劃 JSON，存入檔案或透過 stdin 傳入，並一次性地放入：群組、卡片和它們的擺放位置一起處理。不要建立生成腳本，也不要撰寫驗證器：wallflower put 會進行佈局，截斷超出限制的內容，並檢查結果。
{
"title": "回顧發佈審查",
"groups": [
{ "id": "g1", "col": 0, "why": "兩位審查者都有的相同擔憂" },
{ "id": "next", "label": "帶入下週", "col": 2, "zone": true }
],
"cards": [
{ "id": "rosa", "kind": "quote", "title": "Rosa 對入門流程的看法", "body": "我看不懂它想要我做什麼",
"source": { "label": "發佈審查，3月4日", "file": "/…/notes/2026-03-04 review.md", "url": "obsidian://open?…", "author": "Rosa", "date": "3月4日" },
"place": { "in": "g1" }, "why": "與 Kim 對空白狀態的疑問類似" },
{ "id": "kim", "kind": "quote", "title": "Kim 問了兩次", "body": "我應該先做什麼？",
"source": { "author": "Kim", "date": "3月6日" }, "place": { "near": "rosa", "side": "right", "overlap": true } }
]
}
wallflower put plan.json
計劃可以是部分性的。再次放入相同的 id 可以編輯或移動卡片，而 { "id": "x", "delete": true } 則會移除它。任何可以使用 id 的地方，你也可以使用卡片的編號（"#17"），這是讀回結果和 wallflower view 顯示人們便利貼的方式。群組位於網格上（col、row）；你無需計算像素。群組應保持無標籤，因為命名它們是與會者的工作；why 字段是供讀回功能使用的，而非顯示在白板上。區域則是例外：為它們加上標籤（"已決定"、"帶入下週"），因為區域的名稱本身就是一種指示。
在有人實際觸碰白板之前，每次 put 都會根據你的擺放設定重新佈置整個白板，因此將群組移動到不同的 row 或將卡片移動到另一個群組是可行的。在那之後，任何人放置的任何東西都會留在原位：你的新卡片會圍繞它們擺放，只有你自己尚未被觸碰的群組會移動以騰出空間。
put 會以文字形式輸出佈局，接著進行檢查。layout check: no overlaps, every card in its group, no cut-off text 代表你已完成。否則，每一行 problem: 會列出有問題的卡片或群組的 id（群組重疊或太近、卡片看起來屬於錯誤的群組、卡片互相覆蓋、標題超過三行、瀏覽器回報文字被截斷）；修正計劃後再次執行 put。wallflower view 會在結尾列出相同的問題。由與會者造成的重疊是他們的問題，不會被回報。請不要截圖白板來檢查佈局。
放置
place | 用途 |
|---|---|
{ "in": "g1" } | 屬於同一類別的材料（群組會擴大） |
{ "near": "c1", "side": "right", "overlap": true } | 兩張卡片應被視為一體：不一致、偏移、跨人的重複意見 |
{ "around": "c1" } | 擴展一個鄰近區域：每張卡片會落在 c1（一張卡片或一個人的便利貼）周圍的鬆散環上，朝向不同方向，並位於其群組內 |
{ "near": "c1", "side": "below" } | 一張卡片放在另一張旁邊，但不重疊；它會留在夥伴卡片的群組中，該群組會擴大 |
{ "edge": "g1", "side": "right" } | 異常值，或你不確定是否屬於此處的內容 |
{ "at": { "x": 0, "y": -200 } } | 提示文字，以及罕見的手動設置點 |
卡片類型
寬度依類型固定，高度隨內容調整。
| kind | 用途 | 標題 | 內文 |
|---|---|---|---|
quote | 任何逐字引用的重點，無論是口語或書面；source.author = 誰說的 | 要旨，≤90 | 重點，≤200（目標低於 120） |
note | 一個物件（文件、工單、PR、工作階段），或一個執行下列任一工作的筆記 | ≤90 | ≤300 |
prompt | 白板上的標記文字：起始卡片、一個開放式問題 | ≤160 | ≤200 |
sticky | 人們新增的內容（你很少需要這麼做） | ≤140 | 無 |
當廣度很重要時，設定 people（一個名稱陣列，例如 ["Rosa", "Kim", "Lee"]）；它會顯示為「來自 3 人」。依賴少數一兩個意見的模式應該看起來很薄弱。僅在所有人都能開啟連結時才將連結放入 source.url（共用文件、工單、PR）；絕對不要放私人筆記的連結，這對他們沒用，還會洩漏你的檔案位置。對於檔案，請使用 source.file（如下），它會留在你的機器上。
來源預覽。 為每張來自檔案的卡片提供其 source.file（絕對路徑；file:// URL 也可以）。wallflower put 會在你的機器上讀取該檔案，並附上卡片引用內容前後約 200 字的文字。人們可以透過雙擊卡片或點擊其來源行來開啟預覽。引用內容對引用卡來說就是它的 body；對於筆記卡，請設定 source.quote 為檔案中的逐字詞句，否則預覽會是檔案的開頭。檔案本身永遠不會離開你的機器。永遠不要自己撰寫預覽：put 會忽略計劃中的任何 source.passage。對於非檔案的來源（電子郵件、工單），請使用 shell 重新導向儲存其原始文字（gog … > /tmp/src-1.md），並將 source.file 指向該檔案。如果 put 警告找不到引用，表示這句話不是逐字引用：請修正引用內容，而非警告。
撰寫卡片
白板是讓那些被吸引的人一掃而過就能讀懂的。大多數卡片應能在兩秒內讀完。
- 標題 = 要旨：這是什麼，用白話文說明，最多約 60 字。是描述，而非定論。
- 內文 = 重點：仍能抓住重點的最短逐字片段。偏好奇特、具體或生動的句子。逐字並不代表整段。
每個文字片段都必須回答一個問題：這能讓讀者注意到、記住或調查什麼？ 唯一功能是解釋你為何納入它的文字（例如說明它是什麼證據的卡片，或描述白板的筆記）是你自己在敘述你的準備工作。刪掉它。來源歸屬可以靜靜地放在下方。
一張筆記卡必須執行下列其中一項工作才有存在的必要，大致按對會議釐清情況的幫助程度排序：
- 將兩件事放在一起，以便可以調查、爭論或拆解它們之間的關係。
- 揭露缺失的片段：證據不足的地方（「客戶實際上看到你做了什麼決定？」）。
- 重建一個序列，單一引用無法涵蓋的順序。
- 提供一個對立解讀，針對某個太快被定調的事情。在私人白板上這項的順序會提前；在群組白板上，大部分留給與會者。
- 召回一個期望（原本計劃的）與實際發生的對比。
- 為演練創造空間，通常在與會者已經理解事情之後。
通常正確的筆記卡是一張都不需要：兩張擺放得當的卡片已經完成工作 1。帶有真實資訊的狀態筆記（哪些事待辦、誰欠誰什麼）是 ok 的；但解釋白板本身的筆記則不行。
問題僅用於一兩張執行工作 2 或 4 的筆記卡。一連串第二人稱疑問句的標題是在代替與會者提問，讀起來像機器寫的，就像它取代的那些自我辯解的文字一樣。標題保持為要旨。
在有意義的地方停下來。不要為群組命名，不要寫「這顯示了...」、「關鍵洞察」或「這裡的主題是...」，也不要為兩張卡片為何並排放置加上註解。擺放位置本身就說明了主張，而任何人可以透過移動卡片來質疑這個擺放。也不要在每張卡片上都加上保留條款：一個但書只應放在它影響的那一張卡片上。
| 避免這樣寫 | 改成這樣寫 |
|---|---|
| 標題「定價筆記，7月23日」，內文：一個 280 字的摘錄 | 要旨「分享連結帶來了不會停留的訪客」，重點「他們讀了一次就離開了」 |
| 標題「Kim，客服電話」，內文：一個關於匯出功能的完整句子 | 要旨「Kim 把所有東西都匯出到試算表」，重點「我只想要個…… |
(原始內容已截斷)