企业官网建设流程全解析

这次我们来看一个很有意思的方向：用 wayfinder 这类 skill 思路，让 AI 在跨会话场景下继续执行同一份工作计划。标题里带“实战教程”“任意规模工作”，还有一个关键人物 Matt Pocock，长期做 TypeScript 教学和技术实战内容，熟悉前端工具链的同学应该不陌生。

skill 是当前 AI 编程工具里非常热的关键词，从 Claude Code、Codex 到各类开源 Agent 框架，都在强调 skill 机制。你可以在热词列表里看到大量相关问题：skill 是什么、skill 和 agent 的区别、skill 是不是高级 prompt、怎么编写 skill、skill 和 tool 怎么选。这说明大家已经不只是追概念，而是真的想把它用进日常开发。这篇博客会围绕 wayfinder 这个跨会话规划类 skill，把 skill 的基本理解、跨会话规划的价值、学习路径、自建模板和测试流程一次讲清楚。

先说结论：如果你经常遇到“AI 聊天窗口一关，上下文就全没了”，或者“同一个项目要分好几天做，每次都要给 AI 重新交代背景”，那么跨会话规划类 skill 值得投入时间研究。wayfinder 的核心思路，是用一份持久化的规划文档把工作目标、任务拆分、当前进度和下一步动作固定下来，让 AI 在每次新会话里都能快速恢复上下文，继续推进而不是从头开始。

1. 核心能力速览

说明一下，wayfinder 的具体实现细节会因为教程版本和所在平台而不同，所以上面这张表是按“跨会话规划类 skill”的通用能力整理的。真实部署时，要以你安装的 skill 版本和宿主工具的实际文档为准。

2. 为什么“跨会话规划”是 AI 编程里绕不开的问题

当前主流 AI 编程助手普遍存在一个限制：上下文窗口再大，也不可能无限保存。你开一个新会话，AI 就只知道你这次粘贴进去的内容。对于写一个函数、改一个样式这种小任务，问题不大；但遇到“给整个项目加上权限系统”“把旧接口迁移到新服务”“重构一个大型模块”这种需要多天完成的工作，问题就很明显了。

典型场景是这样的：第一天，你让 AI 分析项目结构，产出了一份重构方案，AI 明确了要改哪几个文件、先做哪一步、后做哪一步。第二天你继续打开编辑器新会话，想让它开始实施第一步，结果 AI 完全不知道昨天聊了什么。你又得把项目背景、技术栈、目标、约束条件重新讲一遍，讲完可能对话轮次也差不多了，根本没干多少活。

跨会话规划就是来解决这个问题的。它不再把上下文寄托在聊天记录里，而是把关键信息外置成一份文件。每次新会话开始时，AI 先读取这份文件，恢复“我在哪里、要去哪里、已经走到哪里、下一步做什么”，然后继续执行。这么做的好处很直接：不依赖单次会话长度，不依赖聊天记录保存，多个会话之间可以接力。

从项目管理的角度看，这其实就是把“需求文档 + 任务拆解 + 进度追踪”沉淀成了 AI 可读的格式。人需要项目文档，代码需要 README，AI 的跨会话工作也需要一份自己的“状态文件”。

3. 理解 skill：它不是高级 prompt，而是一套可复用工作流

热词里很多人在问“skill 是不是就是高级版的 prompt”。应该说，skill 确实包含 prompt，但远不止是 prompt。

一个普通的 prompt 是“你是一个前端工程师，请帮我优化下面这段代码”。它一次性使用，依赖用户每次把上下文讲清楚。而一个 skill 是一套完整的可复用流程，通常包含几个组成部分：

所以 skill 相当于给 AI 装了一个“工作方法包”。你告诉 AI“用这套流程来处理任务”，它就不再是自由发挥，而是按照固定步骤，把结果存成固定格式。这种方式的好处是：可复用、可调试、可分享。你写了一个好 skill，换一个项目也能用，团队里其他人也能用。

3.1 skill 和 agent 的区别

热词里也有人问“skill 和 agent 的区别”。一个更直观的理解方式：agent 是执行者，skill 是执行者手里的方法包。

Agent 负责感知环境、做出决策、调用工具、执行动作。Skill 则是 agent 可以调用的能力模块。同一个 agent 可以挂载多个 skill，比如一个负责代码生成，一个负责代码审查，一个负责跨会话规划。Skill 不决定 agent 的整体行为逻辑，它只提供某个特定任务的执行流程。

举个例子：agent 接到任务“给项目增加登录功能”，它先调用项目规划 skill 分析任务，再调用数据库设计 skill 建表，再调用代码生成 skill 写接口，最后调用测试 skill 补用例。每个 skill 负责一个环节，agent 负责调度。

3.2 skill 和 tool 的边界

另一个常见问题：用知识库到底应该用 skill 还是 tool。Tool 更偏向“单项工具能力”，比如执行 Shell 命令、读写文件、调用搜索引擎、调用外部 API。Skill 则偏向“多步骤工作流程”，内部可能组合多个 tool。你可以在 skill 里定义“先读文件，再分析代码结构，最后写规划文档”，每一步都是 tool 调用，但串起来就成了 skill。

判断标准很简单：如果任务是单一动作，用 tool；如果任务是“按固定流程完成一件事”，用 skill。跨会话规划明显属于后者。

4. 从标题推演 wayfinder skill 的定位与工作方式

从“wayfinder”这个名字来看，它在英文里是“寻路者”的意思。结合“跨会话规划任意规模的工作”这个描述，可以合理推断：它的定位是充当 AI 的工作路径导航器。导航不是一次性给你一个答案，而是持续告诉你下一步往哪走。

更稳妥的判断是，wayfinder 的典型工作方式大概包含这样几个环节：

• 初始化：用户向 AI 描述最终目标，AI 把它拆解成可执行的任务清单，写入规划文件。
• 持续跟踪：每次会话中，AI 读取当前进度，执行计划中的下一个任务。
• 状态更新：完成一个任务后，AI 更新规划文件，把状态从“待处理”改为“已完成”，并记录产出。
• 复盘与重规划：遇到阻塞或需求变化，AI 根据新信息调整任务顺序和优先级。
• 跨会话恢复：新会话里，AI 通过读取规划文件快速恢复上下文。

这套机制的好处是，任务的规模可以从一个很小的 bug 修复，扩展到多模块重构、版本迁移、新功能开发。小任务只需要几步，大任务则需要把规划文件里塞进更多任务节点。

实际效果如何，需要你在本地跑一遍教程里的示例才能确认。但从设计思路上看，这种“以文件为状态中枢”的跨会话方案，比依赖聊天窗口翻历史纪要可靠得多。

5. 跟着教程落地的学习路径

《Matt Pocock 实战教程：用 wayfinder skill 跨会话规划任意规模的工作》是一个偏实战的教程，而且标注了中英字幕。这意味着它的受众不只是英文流利的开发者，中文开发者同样可以跟学。我的建议是不要直接从头到尾看一遍就完事，而是按下面的路径走。

5.1 第一遍：先看演示，建立整体认知

第一遍可以快速浏览，重点看作者在演示时处理了哪几个阶段。一般实战教程会演示一个完整流程：从创建任务、初始化规划，到逐步执行，再到新会话恢复。

你要记录的是：

• 作者在哪个工具里使用 wayfinder。
• 作者用什么命令或自然语言触发 skill。
• 规划文件被存在哪里。
• 每个阶段 AI 做了什么、输出了什么。
• 如果中途出错，作者怎么处理。

这里不需要记代码细节，只需要知道整个工作流长什么样。

5.2 第二遍：跟着操作，逐行复现

第二遍要停下来跟着敲。准备好一个测试项目，最好是一个你熟悉的小项目，这样你能判断 AI 生成的规划是否合理。如果教程里给了完整的 skill 文件或配置，就原样复制到本地，先跑通再谈优化。

实操时重点关注：

• skill 文件放在哪个目录。
• 需要在配置里注册什么。
• 首次运行是否有依赖下载。
• 你的工具版本和作者是否一致。
• 中文字段和英文字段混用会不会导致解析问题。

5.3 第三遍：把 demo 改造成自己的流程

跑通之后，把示例里的规划字段改成适合自己的。比如你的项目需要“接口清单”“数据库变更记录”“测试计划”这些额外信息，就在规划文档模板里加上对应段落。

这一步才是真正把教程变成你自己的技能。

6. 自建跨会话规划 skill 的通用模板

如果你跟着教程跑完后，想自己写一套类似的 skill，下面这个通用模板可以当作起点。它不是 wayfinder 的官方实现，而是一个结构示例，你需要按实际工具平台的 skill 规范调整。

6.1 skill 元信息配置

name: cross-session-planner description: 跨会话任务规划器，用于将大型开发任务拆解为可追踪的步骤，并在多次会话之间保持进度一致。 version: 0.1.0 trigger: - "开始新任务" - "读取当前计划" - "更新进度" inputs: - name: goal description: 任务目标描述 required: true - name: project_dir description: 项目目录路径 required: true - name: scope description: 任务规模，可选 small / medium / large required: false default: medium outputs: - name: plan_file description: 规划文档路径 path: .wayfinder/PLAN.md steps: - init_plan - execute_next - update_progress - restore_context

6.2 规划文档模板

# 项目规划 ## 目标 描述最终要达成的结果。 ## 全局约束 - 技术栈 - 不允许改动的模块 - 性能指标 ## 任务列表 ### [ ] 任务 1：任务名称 - 状态：待处理 / 进行中 / 已完成 - 前置条件： - 具体步骤： 1. 2. - 产出物： - 阻塞项： ### [ ] 任务 2：任务名称 - 状态：待处理 - 依赖任务：任务 1 ## 当前进度 - 上次会话结束位置： - 下一步动作： - 风险与决定记录：

6.3 最小可执行流程示意

import os import json PLAN_PATH = ".wayfinder/PLAN.md" def load_plan(project_dir): plan_file = os.path.join(project_dir, PLAN_PATH) if not os.path.exists(plan_file): return None with open(plan_file, "r", encoding="utf-8") as f: return f.read() def init_plan(project_dir, goal): os.makedirs(os.path.join(project_dir, ".wayfinder"), exist_ok=True) plan = f"""# 项目规划 ## 目标 {goal} ## 任务列表 （待 AI 拆解后填充） ## 当前进度 - 刚刚创建规划。 """ with open(os.path.join(project_dir, PLAN_PATH), "w", encoding="utf-8") as f: f.write(plan) print("规划文档已创建")

这个脚本只演示了“读取规划”和“初始化规划”两个动作。真实 skill 里，AI 还需要按任务列表逐个执行、标记状态、生成小结。

6.4 测试自建 skill 的检查清单

7. 跨会话规划工作流的工程化实现

看教程的时候，不能只停留在“AI 能读计划”这个层面。真正要落地，还要把规划文件当成项目里的一等公民来管理。

7.1 把规划文件纳入版本管理

规划文件不只是给 AI 看的，也是给人看的。把它纳入 Git 之后，团队成员都能看到当前任务进展，Review 时也更有依据。规划文件变更时，应该和代码变更一并提交，这样以后回溯“这个功能为什么这么做”就有据可查。

7.2 用目录结构隔离任务上下文

如果项目同时推进多个独立任务，可以在 .wayfinder 下按任务分目录，避免多个任务互相污染。

.wayfinder/ current/ PLAN.md archive/ task-2024-01-15-auth-system.md tasks/ auth-system.md api-migration.md

每个任务有自己的规划文档，完成后归档。current 始终指向当前正在推进的任务，AI 新会话只需要读取 current 下的文件，不会读到一堆过期上下文。

7.3 定义清晰的会话交接动作

每次会话结束时，给 AI 一个固定指令：更新当前进度，明确下一步。比如：

请总结本次会话完成的内容，更新当前规划中的“当前进度”段落，并说明下一次会话应该从哪个任务继续。

这个动作看起来简单，但非常重要。它是跨会话规划能持续跑起来的关键闭环。没有这个闭环，规划文档会在第一会话之后逐渐失真。

7.4 允许人工干预重规划

AI 的规划可能考虑不周。遇到需求变化，人应该直接修改规划文档，而不是让 AI 继续按旧计划执行。规划文档是“人机协作的协议”，不是 AI 的单方面输出。

8. 常见问题与排查方法

这些排查思路不只适用于 wayfinder，也适用于任何跨会话规划类 skill。核心原则是：先看文件有没有写对，再看 AI 有没有读到，最后看执行是否按流程推进。

9. 最佳实践与合规建议

跨会话规划 skill 用起来，有几个工程化习惯值得提前养成。

第一，第一次使用先在测试项目里跑通。不要上来就拿生产环境的大型仓库做实验。先在小项目里验证 skill 的触发、规划文件读写、跨会话恢复这三个核心环节都正常，再逐渐增加任务规模。

第二，规划文件里不要写入敏感信息。如果你在规划文档里记录了数据库密码、API Key、内网地址，而项目仓库又被同步到远端，就会造成信息泄露。规划文件可以提交到仓库，但内容必须经过脱敏。密码和密钥放到环境变量或密钥管理服务里，而不是写进给 AI 看的文档。

第三，AI 生成的代码要人工审查。跨会话规划可以帮助 AI 更连贯地完成代码生成，但不要让它在没有 review 的情况下自动合入主干。尤其是涉及权限、支付、用户数据的模块，必须有人工复核步骤。

第四，版权和授权意识。如果你的项目使用了第三方组件或模型，确保它们的许可证允许你当前的使用方式。若是公司项目，还要遵循公司对 AI 辅助编码的合规要求，不要随意把私有代码发送到未授权的外部服务。

第五，规划文档不是越细越好。任务拆到这个会话能完成、下一个会话能接上即可。拆得过细会增加维护成本，AI 更新状态的时间甚至可能超过实际写代码的时间。

第六，定期人工 review 规划文件。AI 的状态更新有时会失真，比如它认为自己完成了，但实际上代码并没有提交。每隔几天检查一次规划文件与代码仓库的实际差异，避免“文档很漂亮，代码很混乱”的情况。

10. 总结与下一步

这次围绕 wayfinder 跨会话规划 skill 和大家聊完了技能背景、核心概念、学习路径、自建模板和排查方法。最值得动手做的一件事，是把跨会话规划的思路落实到自己的 AI 工作流里，哪怕不用 wayfinder，只用一份 Markdown 规划文件加固定的收尾指令，也能明显改善“新会话丢上下文”的问题。

建议的第一步验证也很简单：新建一个测试项目，让 AI 写一个包含 5 到 8 个小任务的实施计划，然后第一次会话只执行前 1 到 2 个任务，更新状态后关掉会话；重新打开新会话，尝试让 AI 读取规划并继续。如果这次它能准确说出“当前完成了什么、下一步做什么”，那么这个方向就值得深入。

最容易踩的坑是：规划文件写了，但没做状态更新闭环。记住，跨会话规划靠的是文件状态，不是聊天记录。每天晚上或每个任务节点，花一分钟让 AI 同步进度，后续会省下大量重复沟通的时间。

后续可以扩展的方向也很多：把规划结果接入 CI、用脚本自动生成进度报告、让多个 AI Agent 各负责一个子任务并共享同一份规划、把成功项目的规划文档沉淀为模板库。这个领域的工具迭代很快，但核心方法论是稳定的：让 AI 的工作状态可以被持久化、可恢复、可追踪。这不只是一项操作技巧，更是一种把 AI 从“问答工具”升级为“长期协作者”的思维方式。