Wayfinder技能实测:AI规划大型项目的决策地图新范式

从「拷问我」到「Wayfinder」:AI规划的进化
几周前,一位B站UP主曾用Maple Clocks平台体验过热门技能「拷问我(Interrogate Me)」——那是一个通过在对话中向用户连续提问,帮助厘清需求的规划工具。而几乎在同一时期,知名开发者 Matt Pocock 发布了一款进阶技能 Wayfinder(寻路者)。
这里需要简要说明Maple Clocks平台的背景。Maple Clocks是一个AI技能(Skill)的分发与运行平台,类似于应用商店之于手机应用。每个「技能」本质上是一组精心设计的系统提示词、工作流定义和工具调用配置的打包体,用户可以一键安装后在兼容的AI代理客户端中运行。这种将复杂的AI工作流封装为可复用、可分享的模块化「技能」的做法,降低了普通用户构建高级AI工作流的门槛——你不需要自己编写几千字的系统提示词,只需安装别人已经打磨好的技能即可。「拷问我」和「Wayfinder」都是这个生态中的热门技能,它们的存在说明AI工具的价值不仅在于底层模型本身,更在于围绕模型构建的工作流设计。
顾名思义,Wayfinder 解决的是这样一类场景:你有一个大项目、一个模糊的想法,知道大概的目的地在哪,却对如何抵达一片迷雾。它的核心正是「找到方向」。
与「拷问我」直接在单一对话里连环提问不同,Wayfinder 的机制要复杂得多。它会把整个工作拆解到多个独立对话中,通过「决策工单(Decision Ticket)」的方式并行推进,最终将所有结论汇总到一起。Decision Ticket的概念借鉴了软件工程中的Issue Tracking系统(如Jira、Linear、GitHub Issues)。在传统敏捷开发中,一个复杂项目会被拆解为多个可独立追踪的工单,每个工单有明确的状态、负责人和验收标准。Wayfinder将这一工程实践移植到AI规划场景中,让每个待决策的问题成为一个独立的、可追踪的工作单元,而非淹没在一段冗长对话的上下文里。这种结构化方式还解决了LLM对话中常见的「上下文遗忘」问题——当对话过长时,模型容易丢失早期信息,而拆分为独立工单后每个对话的上下文窗口都保持精简。
这本质上仍是一个规划类技能,不实际写代码,而是先为项目绘制一张完整的「决策地图」。
实测项目:用AI规划一款解谜平台游戏
这位UP主在本次实测中,尝试构建一个暂定名为 Token Burn(代币燃烧) 的解谜横版跳跃游戏。核心创意颇具巧思:玩家身边有一个AI智能体角色,可以给它派任务、协作解谜、逐关推进;智能体拥有模型与技能,甚至能创建子智能体——但运行智能体需要消耗token,每关的token用完即止,这本身也成为解谜的一环。
这个设计将现实中AI开发的约束条件(API调用的token计费)转化为游戏内的资源管理机制,形成了一种「元叙事」——玩家在游戏中体验的资源焦虑,恰好映射了现实中开发者使用大语言模型时的成本考量。这种「打破第四面墙」的设计在独立游戏中越来越常见,如《Baba Is You》将游戏规则本身变成可操作的对象,《Inscryption》让存档文件成为解谜元素。
美术风格设定为「高画质像素风」,类似后期SFC洛克人或现代独立游戏。这一风格在技术上并非简单地使用低分辨率像素——它通常采用较高的像素密度(如单个角色精灵可能达到64×64甚至128×128像素,远超经典8位和16位时代的16×16或32×32),配合精心设计的次像素动画(sub-pixel animation)、丰富的光影层次和粒子效果。代表作品包括《Celeste》的流畅角色动画、《Dead Cells》的动态光照系统、《Owlboy》的多层视差滚动背景。这种风格的吸引力在于它兼具像素艺术的视觉辨识度与现代渲染技术的表现力,同时对独立开发者而言,美术资产的制作成本远低于全3D或手绘2D,这也是它成为独立游戏主流美术方向的重要原因。最终目标是在Steam等平台发布,早期版本则可基于浏览器。
实测采用 Hermes Agent 桌面应用,模型选择了 GPT-5.6 Terra。Hermes Agent是一款支持多模型、多工具调用的AI代理运行时客户端,提供桌面GUI和TUI(终端用户界面)两种交互模式。其桌面应用的核心优势在于可视化的多对话管理——每个对话以独立标签页或面板呈现,用户可以一目了然地看到所有并行对话的状态和进展。这对Wayfinder这类需要同时推进多个决策工单的技能尤为关键。相比之下,TUI模式虽然对开发者友好且资源占用更低,但在多对话并行场景下的切换和监控效率明显不足。
选Terra而非Soul的理由很关键:这不是一个纯编码项目,而是以研究和规划为主,Terra速度更快、对这类任务足够胜任;Soul虽擅长实际编码,但在此场景下偏慢。GPT-5.6系列中Terra和Soul代表了不同的优化方向——Terra定位为通用推理和研究型模型,在信息综合、方案比较、文档生成等任务上表现出色,且响应速度较快;Soul则针对代码生成和执行进行了深度优化,擅长处理复杂的编程逻辑、调试和重构任务,但由于其推理链更深,响应延迟也更高。这种分工反映了AI模型发展的一个重要趋势:从「一个模型做所有事」转向针对不同任务阶段选择最适合的专用模型,类似于芯片领域从通用CPU到GPU、TPU、NPU的专业化分化。

选择桌面应用而非纯TUI界面的原因也很实际:Wayfinder会开启多个对话,桌面端能同时看到所有对话的进展,管理起来更直观。
决策工单与「战争迷雾」机制详解
Wayfinder 的运作流程颇具工程感。安装技能后,用户先用一段自然语言描述项目愿景,系统随即进入类似「拷问我」的提问环节。
分主题拆分的提问环节
实测中,Wayfinder 首先确认了流程的最终目标:产出一份「可交付的完整纵切规格说明与实施路线图」,且明确在规划阶段不实际做游戏。随后它开始提问,涉及目标玩家体验、操控方式、技术交付路径、token经济模型、垂直切片内容量等关键决策。
你可能没注意到几个规划取舍:
- 玩家体验:在动作平台跳跃与AI好奇玩家之间选择「平衡混合」
- 交互界面:采用精选指令的「提示词构建器」,而非完整聊天框
- 技术路径:桌面优先,浏览器版本随后,不使用Unity/Godot等大型引擎(因游戏不涉及3D)
- token经济:按关卡固定预算,重试时可重置
在交互界面的选择上,「提示词构建器」与「完整聊天框」代表了游戏内AI交互设计的两种截然不同的哲学。完整聊天框给予玩家最大的自由度,可以用自然语言任意表达意图,但这带来了两个问题:一是解析玩家意图的不确定性增加,可能导致AI伙伴执行错误操作从而破坏游戏体验;二是自由输入通常需要更长的提示词,消耗更多token,这与「Token Burn」的核心资源管理机制直接冲突。而「提示词构建器」通过预设的指令组件(如动作类型、目标对象、执行条件等可组合模块),让玩家在有限选项中构建指令,既保证了AI伙伴行为的可预测性,又天然约束了每次交互的token消耗量,使得token预算管理成为一个可精确设计的策略维度。
技术路径的选择值得展开说明。对于2D横版游戏而言,Unity和Godot虽然功能强大,但引入了大量不必要的复杂性——3D渲染管线、物理引擎的三维开销、庞大的编辑器依赖等。相比之下,基于Web技术栈(如Phaser.js、PixiJS)或轻量级2D框架的方案,不仅编译部署更简便,还天然支持浏览器分发,后续迁移到桌面端(通过Electron或Tauri打包)也有成熟路径。这种「选择最小必要工具」的哲学,与Wayfinder强调的垂直切片聚焦思想高度一致。

由于没有配置GitHub等issue追踪系统,Wayfinder自动启用了本地markdown备用方案,在wayfinder目录下用一组markdown文件记录所有决策工单。这意味着即便脱离云端追踪器,工具也能本地运行。这种「优雅降级」的设计理念在软件工程中很常见——系统在最优环境下使用最佳方案(如云端Issue Tracker的协作功能),在受限环境下自动切换到功能略弱但依然可用的替代方案,确保核心流程不中断。
多对话并行推进与工单类型
Wayfinder 会绘制一张「决策地图」,并为不同问题创建工单。实测中出现了几类工单类型:
- 调研(Research):如「选择浏览器优先引擎」「Steam迁移架构」「美术制作」
- 原型设计(Prototype):如「教程到毕业设计的阶段推进」
- 拷问(Interrogate):如「定义玩家移动」「定义伙伴能力阶梯」
- 任务(Task):需人工亲自完成的工作,如注册API等
系统会并行启动AFK(无人值守)研究工单自动完成调研,而拷问类工单则需用户在独立对话中回答。AFK研究工单代表了一种新兴的人机异步协作模式。传统的AI对话是同步的——用户提问、等待回答、再提问。而Wayfinder允许AI代理在用户不参与的情况下自主执行调研任务(如比较不同游戏引擎的优劣、调查Steam发布流程的技术要求、搜索像素美术工具链的最佳实践),将结果写入本地文件。这类似于现实中项目经理给下属布置调研任务后去处理其他事务,极大提升了人类时间的利用效率。这种模式的兴起与AI Agent架构的成熟密切相关——Agent不再是被动的问答系统,而是具备目标分解、工具调用和自主执行能力的主动行为者。
这里的体验亮点在于:用户可以在多个对话间来回切换——在A对话回答问题的同时,B对话正在处理并生成下一批问题,大幅节省了干等的时间。

不过提问量依然可观。实测中一个伙伴能力工单问了64个问题,整个流程累计超过30个问题(相比之下「拷问我」曾一次问出70多个)。每完成一个工单,其决策会被记录进markdown文件,并回链到主地图上更新。
战争迷雾:判断何时该开工单的核心逻辑
Wayfinder 引入了一个颇有启发的概念——战争迷雾(Fog of War)。它用来区分地图上哪些区域已经明确、哪些仍需决策。
战争迷雾原本是即时战略游戏(如《星际争霸》《帝国时代》)中的经典机制:地图上未探索的区域被黑暗覆盖,玩家只能看到己方单位视野范围内的信息。将这一概念应用于项目规划具有深刻的认知意义——它承认了一个现实:在项目早期,大量问题处于「未知的未知」状态,强行为这些模糊区域做决策不仅浪费精力,还可能产生误导性的伪确定性。这与敏捷开发中的「Last Responsible Moment」原则一脉相承:推迟决策到信息最充分的时刻再做,而非在项目启动时就试图预见一切。在认知科学中,这也对应了Daniel Kahneman所说的「计划谬误」——人们天生倾向于低估不确定性,而战争迷雾机制通过视觉化的方式强制承认未知的存在。
其判断逻辑很清晰:只有当问题足够明确、可以清楚表述时,才值得开一张工单。如果连问题本身都还没想清楚、无法准确描述,那就说明「时机未到」,应留在迷雾中暂不处理。

在本次实测中,一些超出「最小垂直切片」范围的内容(如战役变现、Steam发布细节)被明确标记为「切片之后的素材」,不再开新工单——因为当前只聚焦演示版本。垂直切片(Vertical Slice)是游戏开发行业的核心方法论之一:与「水平切片」(先把所有系统做到50%完成度)不同,垂直切片要求选取游戏的一个小截面,将其从美术、程序、设计、音效到交互打磨到接近最终品质。这种方法能最早暴露技术和设计风险,为团队提供一个可触摸的品质标杆,同时也是向投资人或发行商展示项目潜力的最佳载体。历史上许多知名游戏的立项都依赖于一个精心打磨的垂直切片——《死亡搁浅》在E3展示的演示、《空洞骑士》早期的Kickstarter Demo都属于此类。Wayfinder通过明确锁定垂直切片范围、将其他内容标记为「切片之后」,有效避免了规划无限扩张——这正是「范围蠕变(Scope Creep)」这一项目管理经典难题的技术性解法。
最终交付:编码代理可直接消费的交接文档
当地图上所有关键决策都被解决、迷雾散尽后,Wayfinder 进入收尾阶段。它会在一个全新对话中,加载「Wayfinder写作计划」技能,读取所有markdown决策文件与原型,生成一份实施交接文档。
这份文档才是整个流程价值的集中体现:
- 明确的目的与范围、超范围锁定项
- 所有反复提问与调研得出的契约(约定)
- 建议的项目结构
- 采用测试驱动开发(TDD)、增量执行的实施路线图
测试驱动开发在AI辅助编码场景中具有额外的战略意义。当编码代理(如Cursor、Claude Code)根据规划文档自动生成代码时,预先定义好的测试用例提供了明确的验收标准——代理可以自动运行测试来验证自己的输出是否正确,形成一个「生成-测试-修复」的自动循环。没有TDD的AI编码往往需要人工逐行审查,而有了测试套件后,很多验证工作可以自动化完成。这也解释了为什么Wayfinder的交接文档特别强调TDD路线:它不仅是好的工程实践,更是让后续AI编码代理能够自主验证输出正确性的关键基础设施。从更宏观的角度看,TDD在AI编码流水线中扮演的角色类似于编译器的类型检查——它提供了一道自动化的正确性防线,使得「AI写代码、AI验证代码」的全自动循环成为可能,人类开发者则退到更高层次的架构决策和测试设计中。
其意义在于:编码智能体可以直接照此执行,无需再做任何调研,所有决策都已敲定,理论上「基本一次就能搞定」。当路线图完全满足地图目的地时,Wayfinder的工作即宣告终结,后续则交由编码代理实际构建。
这种「规划与执行彻底分离」的工作流,实际上暗合了软件架构中「关注点分离(Separation of Concerns)」的核心原则。规划阶段的产出物——交接文档——本质上是一份精确的「契约」,它定义了What和Why,而编码代理只需关注How。这种明确的边界划分降低了每个阶段的认知复杂度,也使得不同阶段可以由最适合的模型或人类角色来完成。
使用体验评价与适用场景
作为首次尝试,这位UP主对Wayfinder给出了相当正面的评价。相比在单一对话里进行漫长的「拷问」,Wayfinder的优势明显:
- 结构更清晰:将不同话题拆到独立对话,避免一个超长会话的混乱
- 调度智能:能自动识别该问的问题、派出子代理做调研、构建决策地图
- 媒介丰富:不仅能生成图表报告,还能创建原型等不同交付物
- 适配大型模糊项目:当你有大致想法但尚不清晰时,Wayfinder能帮你逐步找到通往目的地的路径
值得注意的是,Wayfinder的工作模式体现了AI辅助工具从「对话式助手」向「项目协作者」的范式转变。传统的ChatGPT式交互是单轮或多轮对话,本质上是问答;Cursor等编码工具是实时的「结对编程」伙伴;而Wayfinder则更接近一个具有项目管理能力的「虚拟团队成员」——它不仅回答问题,还主动识别需要回答的问题、分配任务优先级、追踪决策状态。这种从被动到主动、从单点到系统的进化,可能预示着AI开发工具的下一个主要发展方向。
UP主坦言自己「可能没有像别人那样用得那么充分」,但对其「先规划、再分阶段逐个工单处理」的方式印象深刻。他还预告,接下来会尝试用 Grok 4.5(或即将发布的4.6) 在Hermes代理中真正构建这款游戏,并录制实况开发视频。
对于任何需要从一个模糊构想出发、系统性推进大型项目的开发者而言,Wayfinder 提供了一种值得借鉴的AI辅助规划范式:把「不确定」显式化为战争迷雾,只在问题清晰时才落地为可执行工单,最终收敛为一份编码代理可直接消费的交接文档。
核心要点
核心要点
核心要点
相关推荐

谷歌搜索为何错失AI先机:从BERT到Transformer团队集体出走
谷歌发明了Transformer和BERT,却未能率先将其应用于搜索产品。本文复盘谷歌AI人才流失始末,解析大公司创新者困境,探讨技术领先为何不等于市场领先的深层原因。

梦见AI垃圾内容:认知被Slop侵蚀的隐忧与应对
当AI生成的低质量内容(Slop)充斥信息环境,我们的认知和思维模式正被悄然重塑。从"用日语做梦"到"梦见AI垃圾",本文剖析认知同质化风险,并提供守护信息卫生的实用策略。

AI Slop机器的恶性循环:低质内容如何自我喂养、自我强化
深度解析AI生成垃圾内容(Slop)的恶性循环机制:从批量内容生产到模型崩溃,揭示Slop机器如何通过流量激励和训练数据污染实现自我强化,以及打破循环的可行路径。