@mattpocockuk: 对于使用 /wayfinder 的用户，有一点需要澄清：大型工作的流程应该是：/wayfinder -> /to-spec -> /to-tickets ->…

X AI KOLs Following 工具
developer-tools workflow coding prototyping spec implementation

摘要

Matt Pocock 澄清了 /wayfinder 的预期工作流程，强调编码项目的流程应从 /wayfinder 到 /to-spec 再到 /to-tickets 再到 /implement，并指出 v1.2 正在开发中。

对于使用 /wayfinder 的用户，有一点需要澄清： 大型工作的流程应该是： /wayfinder -> /to-spec -> /to-tickets -> /implement 一旦 /wayfinder 地图完成，你就将其转化为一份规范。 有些用户将 /wayfinder 用作整个流程——从需求调研到原型设计再到工作交付 当然，可以这样用——我在非编码工作（如课程制作）中就是这样做的。 但对于编码工作，我更喜欢先创建一份规范，然后将实现过程交给一个 AFK 代理。这样，在我处理其他事情的时候，它就能在后台运行。 我将在接下来的教程中介绍所有这些内容。感谢大家为 v1.1 提供的宝贵反馈。v1.2 正在开发中，看起来效果不错。
查看原文
查看缓存全文

缓存时间: 2026/07/11 09:25

给使用 /wayfinder 的朋友们一个说明：

大型工作的流程应该是：

/wayfinder -> /to-spec -> /to-tickets -> /implement

一旦 /wayfinder 的地图完成，就把它转化为一份规范。

有些人在用 /wayfinder 覆盖整个流程——从推敲到原型设计再到交付工作。

当然也可以这样用——我在非编码类工作（比如课程创建）中就是这么做的。

但对于编码，我更喜欢先创建一份规范，然后把实现任务交给一个 AFK agent。这意味着我可以一边让它运行，一边去忙别的事情。

我会在即将发布的教程里详细介绍这些内容。感谢大家对 v1.1 版的大量反馈。v1.2 正在开发中，看起来不错。

相似文章