版本 1.0 · 2026年10月22日
Weft 宣言
不只是把事做出來，更是為它做決定。
Kanban、Scrum、Shape Up 和 GTD 誕生時，稀缺的是「做出來」這件事，所以它們限制的都是做。如今工作已經不卡在那裡了。做的能力，就附帶在你早已付費的訂閱裡。依然稀缺的，是必須接受結果的那個人的注意力。
數字已經說明了這一點。在超過 810 萬個 pull request 中，AI 產生的被接受比例是 32.7%，手寫的則是 84.4%。比較每個組織 AI 採用程度低與高的時期，審查時間的中位數上升了 441.5%，完全未經審查就合併的 pull request 增加了 31.3%。檢查也要花實實在在的時間：在 GDPval 中，一份需要 404 分鐘完成的交付成果，專家平均要花 109 分鐘審查。1,2,3
核心
Kanban 教我們限制進行中的工作，Scrum 給了我們節奏，Shape Up 用「胃口」（願意投入的時間）取代估算，GTD 教我們為一週收尾。這些我們全都保留。在每天和 AI 一起工作的過程中，我們開始看重：
- 不只是限制進行中的工作，也要限制等你決定的事。
- 不只是當作一則訊息的「完成」，也要當作證據的「完成」。
- 不只是機器的檢查，也要人的接受。
- 不只是有人執行任務，也要有人為它負責 — 而負責人是一個人。
- 不只是計算做了什麼，也要計算接受了什麼。
- 不只是記住任務，也要記住決定。
也就是說，每一行的前半句我們保留，後半句我們視為必要。
一個數字：五
同一時間等你決定的已完成結果或待解問題，不超過五個；團隊共用看板時是十個。佇列滿了的時候，想開始新工作的代理人會被告知：先收尾、縮小範圍，或接手被退回的工作。收尾永遠不會被拒絕：完成的工作永遠不會被丟掉。
這個上限是刻意定得很小的。在 Kingman 的排隊公式中，等待時間隨 ρ/(1−ρ) 增長：在變異程度相同的情況下，一個 95% 時間都在忙的審查者，讓工作等待的時間是一個一半時間在忙的審查者的 19 倍。就像 Google SRE 把瑣務壓在工程師時間 50% 以下的目標，五是一個可以被打破的數字 — 而且打破了你看得見。7,8
七條原則
01工作不再稀缺。你的決定才稀缺。
把硬性上限放在做決定的人面前那條佇列上，而不是 Doing 欄位上。閒著的代理人是健康的代理人；它不會累，三個任務還是五十個任務對它都一樣。審查它工作的那個人，才是唯一會被一件一件消耗掉的資源。
02每一個「完成」，都說明它依據的是什麼。
代理人的回報是一份申請，不是證據。在單一控制方的 τ²-bench 領域中，虛假成功 — 代理人說完成了，環境卻顯示沒有 — 占失敗的 45–48%；而讀取代理人軌跡的 LLM 評審，沒有一個的 AUROC 超過 0.65，擲硬幣也有 0.5。所以最有力的「完成」要讀取外部世界：一個會回應的網頁、一個雜湊相符的檔案、一個確實存在的物件。不需要你做任何事的工作，可以憑代理人一句話關閉 — 但它會如實顯示為這樣，絕不會顯示為已檢查。4
03誰做的工作，誰就不能替它簽核。
已驗證和已接受是兩個不同的狀態。重新讀取外部世界的伺服器、確定性的檢查或一個人，可以把工作標記為已驗證；做這項工作的代理人不行。接受是第二個、獨立的簽名。對任何不可逆的事 — 金錢、發布、寄給客戶的訊息、任何法律相關的事 — Weft 會要求代理人停下來等你；這個暫停一旦設下，任何代理人都不能解除它，也不能把任務移到 Done。
04每個任務都有一位人類負責人。
你無法讓代理人承擔責任，只能把事情指派給它。所以一個任務剛好有一位負責人，而且是人；還有一個有名字的執行者：不是「AI」，而是 Claude Code、Cursor、ChatGPT 或 Codex。執行者要少。Anthropic 自己對代理人團隊的建議是從三到五個開始，因為「three focused teammates often outperform five scattered ones」（三個專注的隊友，往往勝過五個分心的）。5
05到了上限，就指路 — 絕不假造決定。
佇列滿了，系統會告訴你該做什麼，而不是丟出錯誤。代理人在任務中途沒了聲音，它的認領就會失效，任務回到看板上交給別人。而當你還沒決定時，工作就等著你：沉默不等於接受，所以不會有任何東西因為時間過去了就被標記為已接受。
06沒有什麼會被悄悄順延。
一週是規劃的單位：和平常的一天相比，人們在一週開始時承諾一個目標的可能性高出 62.9%，在一個月開始時高出 23.6%。一週的結束，是對每一個未完成的任務做出決定 — 帶著具體的下一步繼續、拆分、退回或放棄 — 而不是悄悄挪到下週。6
07決定比工作階段活得更久。
沒有哪個 AI 客戶端會把自己的記憶交給別人，這樣做是對的。所以工作階段結束後還留得下來的，是寫在它之外的東西：不是一份關於你的檔案，而是工作的歷程 — 任務怎麼結束、決定了什麼、為什麼。記憶也必須會遺忘：過時的筆記不再提供給代理人。
拿它檢驗你的看板
沒有量尺的宣言只是一張海報。這七個問題，拿去問任何一款任務管理工具，大約五分鐘就夠了。凡是 Weft 還沒為所有使用者做到的地方，畫的是一條橫線，而不是勾。
| 問題 | Weft |
|---|---|
| 等你決定的事有沒有硬性上限，而不只是 Doing 有上限？五個結果或問題，團隊是十個。到了上限，代理人會被告知先收尾，而不是開新工作。 | ✓ |
| 你能分辨經過檢查的「完成」和代理人只是自己回報的「完成」嗎？附有驗證計畫的任務由伺服器親自檢查。代理人憑自己一句話關閉的任務，會標為「代理人回報」。 | ✓ |
| 「已驗證」和「已接受」是否分開，而且代理人兩者都不能設定？代理人不能把工作標記為已驗證，也不能把需要你決定的任務移到 Done。 | ✓ |
| 每個任務是否都有一位人類負責人和一個有名字的執行者？負責人是資料庫強制要求的。每個任務都會記錄是哪個 AI 客戶端建立並執行了它。 | ✓ |
| 到了上限，或代理人沒了聲音時，工作是被導向別處，而不是遺失？佇列滿時會回傳下一步該做什麼；沉默的認領 20 分鐘後失效；收尾永遠不會被拒絕。 | ✓ |
| 一週結束時，每個未完成的任務是否都得到一個明確的決定？已經做好，但還沒對所有人開啟。 | — |
| 決定和經驗能否比產生它們的工作階段活得更久？決定和任務歷程在每個方案都有；代理人在工作階段之間帶著走的經驗屬於 Pro。 | ✓ |
✓ 現在可用 · — 部分可用，或尚未開啟 · ✗ 沒有
我們計算什麼，不計算什麼
速率、故事點、燃盡圖、使用率、建立的任務數和 AI 呼叫次數，都不在這個產品裡。它們衡量的是一種已經不再稀缺的資源，而且會獎勵雜訊。
覺得變快了，也不是測量。在 METR 針對使用 2025 年初工具的資深開源開發者所做的研究中，他們以為 AI 讓自己快了 20%；實際測量，他們慢了 19%。9
值得計算的有四件事：最久的那一項已經等了你多久；從「代理人準備好了」到「你做出決定」的時間；第一次就被接受的工作比例，按每個執行者分開計算；以及每個被接受的成果花了你多少分鐘的注意力。最後這一項，是檢驗 AI 是否划算唯一誠實的測試。Weft 會記錄每一項所需的資訊 — 每項工作是誰做的、何時準備好、你做了什麼決定 — 並顯示有多少事在等你。
這套方法在哪裡失效
有些工作沒有可執行的檢查。一封寫給投資人的信，或一段定位陳述，伺服器無法驗證；在那裡，這套方法老實地退回一般的看板：一位審查者，同一時間只有一個這樣的任務。承諾超出自己檢查能力的框架，恰恰會在有人依賴它的地方失效。
關於代理人做事時合適的上限，目前還沒有經過同儕審查的研究。五是我們的預設值，不是研究結論。我們一開始定的是三，在實際使用的頭幾週之後把它調高了：三分之一的拒絕發生在只有三、四項在等的時候，而這些都被一次性處理完了。審查也可能變便宜：GDPval 本身就指出，隨著專業人士熟悉工作，審查時間會下降。如果有一天檢查變得便宜又可靠，上限就應該提高 — 所以這裡的每一個門檻，都是我們預期會修改的預設值，而不是信念。3
這個產品只有一個隱喻，它來自織布。經線撐起布：它是你的目標和優先順序，只有你能定。緯線是從中橫越而過的工作。梭子帶著線來回穿梭，梭子要幾個都可以。經線繃得多緊，織出來的布就有多勻。
告訴你的 AI。看板由它來跑。決定權始終在你。
— Andrei Finogeev, Weft 創辦人
資料來源
- 2026 Software Engineering Benchmarks Report — LinearB, 2026
- The Acceleration Whiplash — Faros AI, 12 April 2026
- GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks — OpenAI, arXiv:2510.04374, 5 October 2025
- From Confident Closing to Silent Failure — arXiv:2606.09863, 1 June 2026
- Orchestrate teams of Claude Code sessions — Choose an appropriate team size — Anthropic, retrieved 22 October 2026
- The Fresh Start Effect: Temporal Landmarks Motivate Aspirational Behavior — Dai, Milkman, Riis — Management Science 60(10), 2014
- The single server queue in heavy traffic — J. F. C. Kingman — Proceedings of the Cambridge Philosophical Society, 1961
- Site Reliability Engineering, Chapter 5: Eliminating Toil — Google, 2016
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 10 July 2025