Matt Pocock 亲测/wayfinder，AI 编程动工前先给需求画张地图

Matt Pocock 在一场一个多小时的直播里，用一个真实需求演示了 Wayfinder 这个新技能。需求是他自建的内容创作平台要加一个 TikTok 竖屏发布功能。全程没有幻灯片，只有一张不断被填满的决策地图，和一堆被逐一敲定的问题。这篇文章把这条「先画地图、再动工」的路线拆开讲。

雾里的需求

Wayfinder 是 grill-me 的进化版。grill-me 是一次提问式会话，把模糊想法盘问清楚。Wayfinder 把这个过程升级成了编排器，一次可以管理好几场并行会话。Matt 在开场就说，这是用来一次搞清楚一大块工作的工具。

他今天要动的是自己的 Course Video Manager，一个集视频剪辑、缩略图、文案、选题库于一身的内容创作平台。他想给这个平台加一个 TikTok creator，能复用现有的普通视频，换一种竖屏播放器样式，还希望能直接发布到 TikTok。

这段口述很模糊。他自己也承认有大量雾气，不知道 TikTok 视频到底怎么定义、发布流程怎么走、和现有的 pitch 系统什么关系。而 Wayfinder 的价值，恰恰是穿过这团雾。

找路，不盖楼

Wayfinder 的核心动作，是画一张决策地图。它先钻进代码库看看有什么，摸清现状，随后开始提问。整个工具只负责从当前位置到目的地这一段，也就是 pre-spec 阶段。

这里有个关键确认，直播一开始工具就问 Matt 目的地是什么。答案是锁定一组决策、产出一份可以交给实现代理的 spec，而不是一段能跑的代码。Wayfinder 管的是把模糊需求收敛成明确决策，落代码是后面的事。

先探测，再提问

第一个实质问题是 TikTok 视频相对于现有视频是什么。Matt 翻开 schema.ts，发现 videos 表已经够用，TikTok 视频只是同一张表上一个不同的属性，一个 format 字段。他定下几条原则，创建要低摩擦、不强制关联 pitch、点个按钮就能开始。

这里有个次序很关键。工具先理解领域，再提问题，对着代码库的既有结构，问出一个个能被拍板的决策。

换模型之外的杠杆

直播中途有人问模型怎么选。Matt 顺手画了一张图，把一个 agent 拆成三层。中间是模型，比如 Opus 或 GPT。模型外面是 harness，Claude Code、Codex 这类执行外壳。再外面是 environment，文件系统、代码库、以及一切 agent 操作的对象。

他的判断是，人人都在换模型、升级模型，可模型只是画面的一小块。harness 和环境是可以免费改进的杠杆，价值各占一半。这个视角解释了他为什么把大量精力花在打磨 skills 和工作流上，而不是追逐最新的模型。

一张地图，九张票

探测完现状，Wayfinder 开始生成产物。它在 GitHub 上开了一个 issue 当主地图，下面挂九个决策子任务。地图本身很简洁，重活都委托给这些子任务。

九张票分三种类型。grilling 票靠对话敲定一个决策，prototype 票靠生成原型让长什么样看得见，research 票直接派 agent 去查证事实再回报。票之间有阻塞关系，地图会标出哪些能并行抓、哪些得等前面的决策落地。

research 票是省心的一类。四个 API 调研任务自动派出去，回来时直接落成文档页，挂在票下面当证据。

枚举比布尔更耐扩展

敲到这个视频是竖屏还是横屏时，工具建议用一个布尔值 isShort。Matt 拒绝了。他翻出仓库里已有的约定，pause type、silence length 用的都是 enum。

他的理由很朴素。布尔值会悄悄埋雷。今天只要区分横竖，加一个布尔就够了；哪天冒出第三种形态，就得再堆一个布尔，三个布尔能凑出六种状态组合。enum 只有三种状态，一个字段，干净利落。这是多年工程直觉在替未来做选择。

说不清，就上原型

到了 TikTok 列表页长什么样这种问题，光靠文字已经问不出来了。Matt 直接要求升一个原型。prototype 技能会在真实代码里搭出几个 A/B 变体，让他在浏览器里点着看。

他反复强调，这是提高讨论保真度的关键。文字描述一个竖屏播放器时，双方脑子里是两幅图。原型把抽象拉回具体，几秒就能看出哪个变体顺眼。Matt 的结论是，宁可烧掉大量上下文换一个能看的原型，也不要在字面上来回猜。

撞墙，就绕路

走到发布环节，一个障碍冒了出来。TikTok 要求每个帖子过一道审核门槛，成本高得离谱。Matt 没有硬啃，而是转身换了一条路，用 Buffer 这个排队发布服务来接。上传 Dropbox，Zapier 检测到文件，再推给 Buffer。

付一点 Buffer 的订阅费，换掉整套 TikTok 审核的麻烦。这笔账在他看来很划算。决策地图的作用在这里也体现出来，它让这里有个坑这件事被及时标记，而不是闷头实现到最后才发现。

把地图走完

一个多小时直播，九张票推进到了八张。地图上每个已敲定的决策都被记录在案，链接到对应的研究和文档。Matt 关掉直播时，地图已经变成一份足够详尽的决策记录。

他最后把完整流程串了一遍。Wayfinder 画地图、拆决策票，接着 to spec 把地图收敛成一份大规格，再 to tickets 拆成实现子任务，每个子任务在独立上下文里实现，最后 code review 和人工 review 收尾。决策票靠做出决策来关闭，实现票靠把决策写进代码来关闭，两者不能混为一谈。

三条能带走的原则

这场演示留了三条判断。其一，spec 先于实现，把模糊需求收敛成明确决策再动手，返工最少。其二，枚举优于布尔，凡是有可能长出第三种取值的字段，一开始就用 enum。其三，聚焦 harness，换模型不如打磨执行外壳和工作环境。这三条都不需要买什么新工具，是纯粹的工作方式改进。

附录 术语对照与来源说明

本文基于 Matt Pocock 的直播视频《The /wayfinder Demo》改写整理，观点与流程忠于原视频，结构与表述面向中文读者重新组织。

素材来源直播视频《The /wayfinder Demo》，作者 Matt Pocock

#AI编程 #Claude #ClaudeCode #需求分析 #AI工作流 #spec #提示词 #效率工具 #程序员 #开发流程