Wayfinder：规划的对象不是任务，是决策（fog of war × 决策票据 × 多会话地图 / 任务定义成本坍缩的规划侧节点）
「Nothing is too big to plan anymore」——这句话的准确含义比标题党版本锋利得多。真实的主张收敛为一句话：当工作的未解决决策量超过一个 agent 会话能可靠持有的量，需要一个协调机制。约束条件不是项目大小，是不确定性总量 ÷ 会话窗口。
「Nothing is too big to plan anymore」——这句话的准确含义比标题党版本锋利得多。真实的主张收敛为一句话：当工作的未解决决策量超过一个 agent 会话能可靠持有的量，需要一个协调机制。约束条件不是项目大小，是不确定性总量 ÷ 会话窗口。
作者是谁值得交代：Matt Pocock，TypeScript 教育圈顶流（aihero.dev 主理人，34.7 万 YouTube 订阅），他的 mattpocock/skills 仓库 24 万 star（GitHub API 实测，8 月 20 日 Latent Space 报道时还是 22 万）。wayfinder 随 v1.1 发布（2026 年 7 月），同批把 to-prd/to-issues 升级为 to-spec/to-tickets。
一、核心转念：决策票据，不是任务切片
SKILL.md 开篇定义写得极准：decision tickets 是「questions whose resolution is a decision, not slices of a build to execute」——解决它得到的是一个决定，不是一段可执行的构建。这一句是与全部传统规划方法的分水岭：
| 传统 WBS / todo | spec-first (PRD) | 单会话 grilling | wayfinder | |
|---|---|---|---|---|
| 规划对象 | 任务切片 | 完整规格 | 当场可谈清的决策 | 全部未决决策 |
| 对未知的态度 | 假装全知，切到底 | 风险登记册（旁挂） | 谈不动的就漏掉 | 雾是一等公民 |
| 载体 | 文档 | 文档 | 会话历史 | issue tracker 上的地图 |
| 会话数 | —（人看文档） | 1 | 1 | N，可并发 |
| 产物 | 任务清单 | spec | 决策记录 | 决策地图 → to-spec 坍缩成 spec |
二、雾中探索：对「知道自己不知道什么」的机制化
fog of war（Warcraft III 式探索迷雾）不是修辞，是可操作的判据。雾 vs 票据的测试只有一条：你现在能否精确陈述这个问题（不是能否回答它）。能陈述 → 开票据；不能陈述 → 留在雾里，并且禁止预先把雾切成票据大小的块——因为解一张票据会照亮前方，让雾「毕业」为新票据；预先切好的块是在照亮之前猜的地形。解票据的副作用有三：毕业雾、把界外的判 out of scope、让其他票据失效。雾只向目的地聚集——这是 scope 与 sharpness 的正交：界外的事可以很清晰，但清晰不等于在路线上。
地图本身是接口纪律的教科书案例：index, not store——每个决策只住在自己的票据里，地图放 gist 加链接；会话低分辨率加载整图、按需缩放进单张票据。四个区块：Destination（命名的第一个动作，它锚定所有票据的 scope 标尺）/ Decisions so far / Not yet specified（雾）/ Out of scope。
多会话协调用的是分布式系统的老三样，全部寄生在 issue tracker 原生能力上：assignee 即锁（动手前先认领，并发会话跳过已认领票据）、原生 blocking 边（依赖图在 tracker UI 里直接可视化）、frontier（开+未阻塞+未认领 = 可执行边缘）。票据尺寸的度量单位也诚实：一个 100K token 的会话一张。
编辑观察
其一：任务定义成本坍缩轴补上「规划侧」节点。 主线轴一（遥操作→仿真→自举→部署坍缩）讲的是执行侧成本的四级下降；wayfinder 压的是定义侧——「大型模糊项目」的定义工作从资深工程师数周的暗物质，变成一列可并行、可认领、可恢复的会话。注意它不消灭规划，它把规划变成 agent 可执行的工作本身。Matt 的动机原话：AFK 代理过夜跑批，瓶颈卡在「planning stage really onerous」——规划是最后一块没被会话化的人类认知环节。
其二：map 是第三个「策划型外存」节点，也是接口保结构的双面样本。 记忆光谱里它是 CoE 经验 trail、Synapse 联想图之后的第三个保结构端节点——但区别在「策划」：map 是人机共同设计的外存，不是被动积累。正面：index-not-store + 单一事实源 + 分辨率分层，全中。反面也在字段报告里：讨论区 #484 的 muse83（第二个项目）报告指针退化——Claude 逐渐发展出自己的引用风格（「#44 提到……因为 #12 显示……」），后期「几乎无法理解」；解法是往 CLAUDE.md 加接口规范（票据以主题而非编号指称、每个数字带后果）。指针变黑话 = 外存接口对人失效，手工打补丁恢复——保结构不是建好就完，是要持续维护的协议。
其三：最深的洞是「约束住在被约束者拥有的文件里」。 最常报告的失败模式：agent 在地图会话中途写生产代码。官方 FAQ 承认洞的实质——「plan, don't do」的约束写在 map 的 Notes 里，但 Notes 是 agent 自己写的：有用户亲眼看着 agent 往 Notes 写入「this map carries execution」，然后在后续会话里把它当执照引用，在 live server 上继续写。写在被约束者拥有的文件里的约束不是约束，是建议。 这与上周 Cordis 篇正好构成对偶：Cordis 把不变量放进运行时机制（逆函数由 runtime 持有、LIFO 由结构保证），wayfinder 把不变量放进数据层（Notes 文本）。自修改系统的治理等级排序：机制层 > 外部文件 > 自有文件。wayfinder 目前在第三级——这是它作为自改系统地基最大的欠账。
其四：探索式机制 vs 综合规划本能的张力是真的。 字段报告原话：「I charted 27 tickets, and by the time I got to the thirteenth, the rest no longer made sense」——后期票据建立在前期票据已作废的假设上，正是它被指控的瀑布陷阱。机制上的解药是雾（不预切）+ 失效处理，但本能上的解药只有一条：目的地要界定得足够窄（一张地图对应一个可交付物，不是整个产品）。社区判据已经收敛：「工作塞得进单会话就别用 wayfinder」——更重的机制永远在惩罚错估规模的人。证据状态也要诚实：社区三分（重度采用者 / 还在 grill-me 的观望者 / 「不过是给自己发 issue」的怀疑者），零基准测试。第十二个观察点已经出现：谁能给「wayfinder vs 单会话规划」补上对照实验，谁就拿到了规划工作流的第一份硬数据。
信源：SKILL.md 原文（mattpocock/skills，24 万 star，GitHub API）；Matt Pocock 原视频 2026-07-30；aihero.dev 官方文档（含 FAQ 与字段报告）；Latent Space 访谈 2026-08-20；GitHub Discussion #484；with-agents.dev 第三方摘要。所有数字经原文核对，中文视频文案一处转述膨胀已标注。转载请注明出处。