如果你已经试过用 AI 编程工具做小任务比如修一个 bug、写一个函数你大概率会觉得体验已经相当不错。但当你需要把一个真正的中型项目拆成若干阶段、跨多天完成时问题就会突然冒出来同一个对话窗口里AI 记得上下文一旦你关闭窗口或者临时从“写登录模块”切到“调一下接口”之前规划好的路线图、里程碑、当前做到哪一步几乎全部归零。你不得不一遍遍把背景资料重新粘进去让模型重新理解项目再重新生成计划。这不是模型能力不够而是整个工作流缺少一个关键组件跨会话的规划机制。wayfinder 正是针对这个缺口出现的 Skill。Matt Pocock 在他的实战教程中详细演示了如何用 wayfinder 组织“任意规模”的项目工作——先建立一份可读、可更新、结构化的工作计划再让 AI 在多个会话之间持续读取、更新这份计划从而把一次性的对话延展成可持续推进的工程过程。我的判断是跨会话规划会成为 AI 编程工具从“问答助手”走向“开发协作者”的分水岭而 wayfinder 是这条路径上一个非常值得研究的样本。这篇文章不会停留在复述视频内容。我会依次讲清四个问题Skill 到底是什么跨会话规划为什么难wayfinder 是怎么解决的以及你在自己项目里应该怎么用。读完你能立即在自己的命令行工具里跑通一套最小可用的跨会话规划流程也能避开最常见的误用方式。1. 这篇文章真正要解决的问题如果你只是让 AI 写一个函数、修复一个报错、生成一段单元测试现在的工具表现已经足够好。因为这些问题通常可以在一个会话里闭环上下文短目标单一完成后收工。可一旦任务变成“实现一个带用户系统的中后台前端项目”或者“重构这个模块并把相关测试补齐”你面对的就是一个跨越几十次对话、持续数天的高复杂度工作。此时单会话的局限会非常刺眼。大部分 AI 编程工具在底层做了会话隔离设计。每次新开的对话默认不会自动带上之前会话的完整记忆它能看到的只是你重新粘贴进去的内容、当前打开的工作区文件以及它自己重新扫描出来的项目结构。也就是说你作为开发者成了一个“上下文搬运工”上下文窗口不够就删旧贴新AI 忘掉规划就重新粘贴需求文档项目一复杂大量精力都花在了“让 AI 重新想起来我们当初要做什么”上。wayfinder 的核心思路是别让 AI 去“回忆”而是让 AI 去“读取”。它把工作规划变成一份生活在项目仓库里的结构化文件谁在什么时间之前完成什么目标当前做到哪一步下一步是什么。每个新会话开始时AI 只需要读这份文件就能准确恢复方向。这就是“跨会话规划”四个字的真正含义。读完这篇文章你可以得到三样实实在在的东西第一一套对 Skill 机制的清晰认知知道它和 Agent、Prompt 的边界第二一份 wayfinder 的实践流程能自己复现跨会话规划第三一组在真实项目中不容易踩到的坑和规避方式。2. Skill 是什么它和 Agent、Prompt 到底有什么区别在 AI 编程生态里Skill技能是一个经常和 Prompt、Agent 混用的词。很多开发者看到“wayfinder skill”第一反应是“这不就是一套写好的提示词吗”看到“Agent”又会觉得“这是不是就是能自动动手的 Skill”。要理解 wayfinder必须先把这个生态位的概念分清。Prompt 是一次性的输入。你把一段指令发给模型模型根据这段指令给出回答。Prompt 的特点是一次性、线性、不打包它不会自带“怎么调用文件”“怎么维护计划”这套方法也不会被其他会话复用。可以说Prompt 是对话的原材料而不是可组合的能力单元。Skill 是打包好的可复用能力。一个 Skill 通常包含一段明确的任务描述、一组执行步骤、若干示例、可能还有配套的脚本或文件模板。当 AI 编程工具检测到当前任务符合某个 Skill 的触发条件时它会加载这个 Skill 的完整定义按照其中约定好的流程执行。换句话说Skill 把“怎么做一件事”的方法论固化成了文件让模型每次遇到同类任务都能保持稳定水平而不是每次都在自由发挥。Agent 则是执行者。Agent 是一个具备“感知、决策、行动”能力的运行时角色它可以读取文件、执行命令、调用工具、决定下一步做什么。Agent 会使用 Skill但 Agent 不等于 Skill。可以把 Agent 理解为“通用机器人”Skill 理解为“机器人加载的专项技能包”。维度PromptSkillAgent本质一次性文本指令可复用的能力定义包自主决策的执行主体是否打包否是是是否有文件依赖通常没有通常包含方法和模板需要运行环境与工具链能否跨会话复用需要手动复制可以直接加载需要会话或记忆机制典型例子“帮我写一个排序函数”“项目规划技能”Claude Code、Codex CLI所以wayfinder 是一个 Skill不是 Agent也不是普通 Prompt。它不直接替你把功能写完而是给 AI也就是 Agent一套做规划的“作业流程”先了解项目目标再拆解里程碑最后把计划落成文件并在每次执行后更新文件。这里还要补充一个常见的误解Skill 并不是“高级版 Prompt”。Prompt 的终点是让模型“说出一段正确的话”Skill 的终点是让模型“按一套稳定流程做完一件事”。两者在复杂度和可维护性上差别很大。一个 Skill 可以包含多个 Prompt、多段示例、多个文件模板甚至还可以唤起其他脚本。这也是为什么社区里对 Skill 的讨论会如此火热它把不可控的“聊天能力”变成了可控的“工程能力”。3. wayfinder 的跨会话规划原理理解了 Skill 的定义之后我们再来看 wayfinder 到底解决了一个什么样的深层问题。AI 会话本质上是无状态的。用浏览器、用命令行工具每次会话打开的瞬间模型看到的内容基本只有两部分系统提示词、以及当前工作区里的可见文件。它并不会天然记住“上一次我们聊到哪里了”。如果没有外部机制辅助长项目的推进就会退化成一个循环你把需求再说一遍AI 重新理解一遍做一点然后你再说一遍。目前业界解决“跨会话记忆”的方案大致有三类。第一类是会话摘要。在每次会话结束时让 AI 把刚才的讨论总结成一段摘要下次开会话时把摘要粘进去。优点是实现成本低缺点是摘要会丢失大量细节而且非常依赖开发者手动维护项目一长就容易变成“摘要套摘要”信息衰减严重。第二类是长期记忆库。Agent 把关键事实写入向量数据库或记忆文件在后续任务中自动检索。优点是自动化程度高缺点是记忆内容不可控AI 可能记住一些无关紧要的细节却把真正重要的架构决策漏掉而且排错时你很难看出它到底“记得什么”。第三类就是 wayfinder 采用的规划文件方案。把任务目标、里程碑、当前进度、下一步动作写进一个结构化文件这个文件放在项目目录里跟随项目走。每个新会话启动后AI 必须先读取这个文件才能开始工作每次完成一个阶段后AI 再更新这个文件。于是文件系统成了 AI 的“持久化记忆”。这个方案最核心的价值不是“计划写得漂亮”而是“计划文件与项目执行的强一致”。因为计划文件放在项目里它天然享受版本管理因为 AI 每次开工前都读它它天然成为会话的“开场上下文”因为文件内容是结构化的 Markdown开发者也能随时打开检查、修改、评审。换句话说wayfinder 把 AI 的思维状态从黑盒变成了白盒。从更宏观的视角看这也解释了为什么 wayfinder 声称可以规划“任意规模”的工作。小任务不必跨会话一个会话就能搞定大任务之所以难难在对“进度”的追踪。只要“进度”被持久化到了一个可读文件里规模本身就不再是瓶颈瓶颈会转移到你对任务拆解的清晰度上。4. 环境准备与前置条件在动手尝试 wayfinder 之前需要先确认你的环境满足条件。wayfinder 不是一个独立的桌面软件它依赖支持 Skill 机制的 AI 编程工具来运行所以环境准备的核心是准备好“宿主工具”。当前比较常见且支持 Skill 机制的工具包括 Claude Code、Codex CLI、opencode 等。这类工具的共同特点是可以直接在命令行启动能够读写项目目录下的文件并且具备加载 Skill 的能力。如果你的主要工作环境还是网页版聊天界面读写项目文件会很麻烦跨会话规划效果也会大打折扣建议先切换到命令行工具。操作系统的选择上macOS 和 Linux 会顺滑一些Windows 用户建议使用 WSL 或兼容的 shell 环境否则文件路径和权限问题容易成为障碍。下面先检查你本机的基础环境。node -v npm -v # 检查是否已经安装了支持 Skill 的 CLI 工具 claude --version codex --version如果提示command not found说明对应工具还没有安装。请到工具的官方文档获取最新的安装命令版本号以官方为准。本文的重点是通用实践不会绑定某一个工具的特定版本。确认基础工具就位后还需要一个空白项目目录。建议不要直接在已有的大型生产项目里做第一次实验先建一个简单的测试目录流程跑通后再迁移到真实项目。mkdir wayfinder-demo cd wayfinder-demo接下来是获取 wayfinder 这个 Skill。具体安装方式取决于你使用的工具和它的生态常见有两种一是从 GitHub 仓库克隆或下载到本地的 skills 目录二是通过工具内置的插件安装命令进行安装。下面的实战示例统一使用“目录复制”的方式因为它不依赖某个特定平台通用性最强。5. wayfinder 实战跨会话规划一个项目这一节我们用最小可行流程跑通从“创建计划”到“在新会话中继续推进”的完整闭环。示例项目是一个简单的待办事项 Web 应用任务拆成三个里程碑涉及前端页面、后端 API、以及联调测试。规模不大但足够展示跨会话机制的价值。5.1 初始化项目并加载 skill进入项目目录后先确认 tools 能识别到 wayfinder。以 Claude Code 的目录约定为例Skill 通常会放在.claude/skills下面你也可以参考自己工具的文档调整目录。wayfinder-demo/ ├── src/ ├── package.json └── .claude/ └── skills/ └── wayfinder/ ├── SKILL.md └── examples/创建完目录后在命令行启动工具并让 AI 确认是否已经加载了 wayfinder。claude请在当前会话中检查 .claude/skills 目录确认 wayfinder skill 是否存在。如果 AI 能正确读出 SKILL.md 的位置说明加载成功。如果它表示没有找到就要检查目录路径是否正确或者当前工具是否支持自定义 skills 目录。这一步是排错成本最低的阶段不要急着往后走。5.2 创建第一份计划确认 Skill 可用后向 AI 描述项目目标和预期规模并明确要求它使用 wayfinder 的流程创建计划。这里的关键是“目标要完整拆分交给 AI”。请使用 wayfinder 为这个项目创建一份跨会话行动计划。 项目目标开发一个简单的待办事项 Web 应用。 功能范围支持任务的增删改查数据保存在本地 JSON 文件前端使用一个极简页面完成交互。 工期要求希望拆成 3 个里程碑每个里程碑可以独立验证。AI 应当生成一份结构化的计划文件。这份文件会作为跨会话的核心记忆内容大致如下实际文件名以 wayfinder 的约定为准。# 项目计划待办事项 Web 应用 ## 目标 开发一个支持增删改查的待办事项 Web 应用数据保存在本地 JSON 文件。 ## 里程碑 - [ ] M1搭建项目骨架完成本地 JSON 数据读写模块 - [ ] M2实现后端 API提供增删改查接口 - [ ] M3实现前端页面并完成联调 ## 当前进度 - 最后更新时间2025-01-01 - 当前里程碑M1 - 当前任务搭建项目骨架 - 下一步创建 package.json 和入口文件 ## 注意事项 - 数据文件使用 data/todos.json - 不引入数据库保持轻量创建计划后先检查这个文件是不是真的出现在项目目录里。这里真正容易踩坑的地方是AI 嘴上说“已创建计划”但实际只是把内容放在了对话里没有写入文件。你应当用文件管理器或命令行确认文件真实存在。ls -la cat 计划文件路径从这一步开始计划文件就成了你和 AI 之间的“共同工作台面”。5.3 跨会话恢复并推进现在模拟最典型的场景你做了一部分工作然后关闭了会话第二天重新开会话继续。很多 AI 编程工具在新会话里默认不会自动加载上一次的讨论内容但 plan 文件躺在项目目录里你只需要让 AI 去读它。claude请先读取项目中的 wayfinder 计划文件确认当前进度然后继续执行下一步。如果一切正常AI 会告诉你“当前计划中M1 进度为 X下一步是 Y我现在开始做。”这就是跨会话规划最直观的效果你不需要重新粘贴需求文档不需要重新讲解项目背景只需要指向那份文件。5.4 更新计划与完成追踪跨会话方案要真正发挥作用有一个纪律必须遵守每次阶段性工作完成后要求 AI 同步更新计划文件。比如完成 M1 后把里程碑复选框从[ ]改成[x]更新“当前进度”和“下一步”。M1 已经完成并验证通过。请更新 wayfinder 计划文件把 M1 标记为完成并把当前进度推进到 M2。这样做的原因很直接计划文件是 AI 恢复状态的数据源。如果文件不更新下次会话看到的还是旧状态跨会话规划就退化成了一份“一次性计划”。在实际项目中我建议把“更新计划文件”和 Git 提交绑定在一起每次计划文件变化就提交一次形成可追溯的项目推进记录。6. 运行结果与效果验证跨会话规划的效果验证和普通功能开发的验证方式不太一样。这里我们要验证的不是“代码能不能跑”而是“AI 能不能在全新会话中准确恢复项目状态”。建议按下面三步检查。第一步检查计划文件本身。文件必须真实存在于项目目录内容包含目标、里程碑、当前进度且没有出现明显的重复或矛盾。如果计划文件内容混乱后续所有会话都会基于错误上下文工作。第二步在新会话中询问当前状态。这是最关键的验证动作。关闭当前会话重新打开一个全新对话然后只输入一句话“根据 wayfinder 计划我现在应该做什么”预期 AI 能准确地报出当前里程碑、当前任务、下一步动作。如果它回答“我不知道”或者需要你重新提供背景说明计划文件的加载链路有问题。第三步让 AI 继续执行一个最小任务。比如计划里写着“下一步创建 package.json”你就让 AI 直接完成这一步。检查它是否写入了正确的文件、是否符合计划中的注意事项。这一步能验证 AI 不仅“读得到”计划还能按计划行动。如果失败先按这个顺序排查是不是没有把计划写入文件是不是新会话的工作目录和计划文件所在目录不一致是不是 Skill 没有被正确加载前两个原因占了实际操作失败场景的绝大多数。7. 常见问题与排查思路问题现象可能原因排查方式解决方案AI 在新会话中不读取计划文件新会话没有明确要求读取计划或工具不会自动扫描检查对话开头是否提示 AI 读取计划文件在项目根目录用固定提示词打开会话例如“先读 wayfinder 计划”计划文件不存在或内容为空AI 只在对话中输出了计划没有写入文件系统用ls检查文件是否真实存在要求 AI 使用文件写入工具明确写出文件路径AI 执行的步骤和计划严重不一致计划文件内容模糊或当前进度字段没有更新查看计划文件的“当前进度”是否和实际一致定期要求 AI 更新计划文件保持“计划”与“执行”同步Skill 无法被识别目录结构不对或工具版本不支持自定义 Skill检查 skills 目录路径、SKILL.md 是否存在参考工具官方文档调整目录位置或升级工具版本写入计划文件时权限报错项目目录受系统保护或文件只读查看报错信息确认进程对目录有写权限调整目录权限或把项目移到用户目录下再运行这五个问题基本覆盖了跨会话规划实践里的高频故障。可以看到大多数问题不是模型能力问题而是“文件是否真实存在”“路径是否正确”“是否及时更新”这类工程纪律问题。这也再次说明 wayfinder 是一个工程组件而不只是一个提示词技巧。8. 最佳实践与工程建议如果 wayfinder 的跨会话规划在你的项目里稳定跑通可以进一步按照工程化标准来约束使用方式。以下是几条经过实践检验的建议。第一控制计划粒度。计划的粒度不要细化到“第几行代码做什么”也不要粗到“做一个项目”。比较好的粒度是“里程碑 任务”。每个里程碑要能独立验证每个任务要在一次或两次会话内可以完成。这样计划文件既有指导意义又不会因为过于琐碎而频繁更新。第二把计划文件纳入版本控制。计划文件是项目的一部分应该跟着代码一起提交。当项目回滚到某个历史版本时计划文件也回到当时的推进状态这对排查“当时为什么这么设计”非常有用。建议在提交信息里标注计划的变化例如chore: update wayfinder plan for M2。第三建立“每次会话结束前更新计划”的纪律。这个纪律比任何工具都重要。会话结束时让 AI 总结当前进度、已完成的里程碑、下一步动作并写入计划文件。如果不做这一步跨会话机制就会失效。你可以把这句话固化成自己的固定结束语也可以写进项目的开发约定文档。第四合理看待多 Agent 协作场景。如果你的团队有多个 Agent 同时工作计划文件还能起到“工作看板”的作用每个 Agent 通过更新计划文件来声明自己的进度其他 Agent 通过读取计划文件来避免重复工作。这比各自维护一套记忆更可靠。第五注意安全与权限边界。跨会话规划让 AI 获得了“跨时间”的项目控制能力这同时意味着更严格的权限要求。不要让 AI 在没有提醒的情况下修改计划文件之外的重要文档也不要让它把敏感信息写入计划文件。团队协作场景中最好由指定的负责人审核计划文件的变更。第六不要用计划文件替代所有记忆机制。wayfinder 擅长的是“任务规划”不是“知识图谱”也不是“代码索引”。如果某个项目需要大量领域知识支撑仍然需要配合检索机制或文档库。正确的方式是计划文件负责“接下来做什么”其他机制负责“具体怎么做”两者协同而不是互相取代。9. 总结与后续学习方向wayfinder 让我印象最深的不是它生成了多么精美的计划而是它把“规划”这件事从模型的黑盒里拿到了文件系统里。这个设计选择带来的连锁反应是巨大的开发者可以审阅、修改、回滚计划AI 可以在任意新会话中恢复状态团队可以用同一份文件协作。它确实让 AI 编程从“聊天式问答”往“工程化协作”迈进了一步。如果你想继续深入建议按下面这条路径实践。第一步用这篇教程里的最小示例跑通一次完整的“创建计划、关会话、开新会话、恢复推进”流程。第二步把你手头一个真实的中型项目接进来重点观察计划文件在 3 到 5 次会话之后是否还能保持整洁、准确。第三步结合你使用的工具学习一下 Skill 的编写规范尝试把团队里重复性最高的流程沉淀成自己的 Skill。到这一步你就已经不再只是一个“会用 AI 编程的人”而是“会为 AI 设计工作方式的人”。如果你愿意看视频也可以去搜一下 Matt Pocock 的原始教程社区里已经有中英字幕版本跟着过一遍会比自己摸索更快。建议看之前先把手头的一个小项目准备好边看边复现效果比纯看视频好得多。这篇文章建议收藏备用尤其是第 5 节和第 7 节动手遇到问题的时候回来查一下能省不少时间。