版本 1.0 · 2026年10月22日
Weft 宣言
不只是把活干出来，更是对它做出决定。
Kanban、Scrum、Shape Up 和 GTD 诞生时，稀缺的是“做出来”这件事，所以它们限制的都是做。如今工作已经不卡在那里了。如今，做的能力就附带在你早已付费的订阅里。仍然稀缺的，是必须接受结果的那个人的注意力。
数字已经说明了这一点。在超过 810 万个拉取请求中，AI 生成的被接受的比例是 32.7%，而手写的是 84.4%。对比每个组织 AI 采用率低和高的时期，审查时间的中位数上升了 441.5%，完全未经审查就合并的拉取请求增加了 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