Claude挑战循环真相：Wayfinder技能修复AI一次构建应用

挑战循环：从单一提示构建完整应用

最近在X和YouTube上被大肆炒作的"挑战循环"（Challenge Loop），让人们能用极简的提示词一次性构建大型应用和高质量游戏。它的走红始于Matt Schumer发布的一个演示——Claude用单一提示构建了一个第一人称射击游戏，且没有使用任何现有资源。这超出了大众对模型能力的预期，帖子随即爆火。

要理解挑战循环，需要先理解什么是"循环"（Loop）。在循环出现之前，你用Claude构建东西时扮演的是"检查者"角色：发送提示、查看结果、指出错误、反复迭代直到正确。循环则打破了这种来回——你给代理设定目标和标准，它会不断检查自己的工作直到达标，你只在最后看到结果。

挑战循环是一种新型循环。它的关键创新在于：不是让代理自己判断"好不好"，而是给它一个真实存在的产品作为衡量基准。Schumer给游戏代理设定的基准是"最新使命召唤级别的3A质量"，让代理有明确的对标对象。OpenAI创始成员之一Andrej Karpathy也评价这类结果很重要——因为以前这种高质量的工作"不值得做"，而模型正在打破这一限制。

三行提示背后的运作机制

令人意外的是，Schumer公开的提示只有三行，却能构建整个游戏。每一行处理构建的不同部分，简单到你可以为任何项目照搬。

第一行定义构建什么：Schumer写的是构建第一人称射击游戏，后半部分定义质量标准——要求3A级质量，从纹理到物理都完美无缺。

第二行定义如何构建：告诉主代理将目标分解成更小的部分，把每个部分交给独立的子代理。子代理是主代理启动的独立代理，每个在自己的内存中处理小任务，看不到其他代理的工作。关键在于，提示要求为每个代理附加一个审查子代理，称为"评论家"（Critic）。评论家唯一的工作就是检查——不够好就送回给构建代理修正，直到合格。评论家从不自己构建，且没有之前的记忆，只提供残酷而诚实的评价。

第三行定义最终质量水平：告诉评论家何时可以停止。指示是让评论家"盲目比较"两者——它不知道哪个是Claude做的、哪个是产品，只选出更好的那个。

提示末尾还有一个关键词"Ultrathink"（视频中称Ultra Code），这是Claude Code中同时运行大量子代理的功能。当大量子代理并行循环时，就形成了一张"图"（Graph）——挑战循环绘制的是一个菱形图：顶部一个任务分成并行子代理，再汇聚回一个代理整合成最终答案。

子代理与多代理编排是理解这套机制的关键底层概念。在传统单轮对话中，一个模型实例顺序处理所有任务；而在多代理架构中，一个"主代理"（Orchestrator）可以动态实例化多个"子代理"（Subagent），每个子代理拥有独立的上下文窗口，只接收与自身任务相关的信息。这样做有两个好处：其一，并行执行大幅缩短总耗时；其二，隔离上下文避免不同任务的信息互相污染，减少"注意力稀释"导致的质量下降。评论家（Critic）代理之所以被设计成"无历史记忆"，正是为了避免它因积累偏见而对低质量工作产生容忍——每次评审都从零开始，确保评判标准的一致性。Ultrathink/Ultra Code是Claude Code中触发大规模并行子代理的调度指令，本质上是在告诉运行时：为这个任务分配更多并发计算资源。

被忽视的两个致命问题

尽管很多人用挑战循环一次性完成整个项目，但它存在两个关键问题，正是这些问题决定了它适合做游戏却难以用于真实项目。

问题一：主代理完全自我管理。主代理负责如何启动评论家、编写指令，你无法控制它如何将判断标准传递给评论家。检查本应有更具体的外部设置，而不是让代理自己验证一切。在小规模上它有效，但长期来看你无法找出问题的真正原因。

问题二：质量基准依赖现有产品。提示中的质量基准是一个现成的产品（如使命召唤），评论家有真实的东西可以对比。构建游戏、着陆页或3D世界时这没问题，因为总有东西可以参照。但当你构建全新的东西时——比如自己业务运行的计费规则——没有现成应用可以交给评论家检查，评论家就会编造标准并据此通过工作。等你意识到它假设的方向不对时，已经浪费了大量时间和令牌。

换句话说，挑战循环在有"足够接近的东西可复制"时有效，一旦没有参照物就会崩溃。

这两个问题在AI系统设计中分别对应两个经典难题。主代理自我管理的问题属于"自我参照验证"（Self-referential Validation）困境：用同一套逻辑生成内容并验证内容，无法发现系统性偏差，类似于让学生自己出题、自己评分。质量基准依赖现成产品的问题则对应"分布外泛化"（Out-of-Distribution Generalization）失败——模型在训练数据覆盖的领域（主流游戏、常见应用）表现稳健，但面对训练集中罕见的业务逻辑（如特定公司的计费规则），无法从已知模式中可靠推断，只能通过"幻觉"（Hallucination）填补空白。这解释了为什么挑战循环在"有大量参照物的通用领域"有效，而在"高度定制化的原创需求"面前系统性失效。

Wayfinder：用规格文件填补规划迷雾

修复方案分两部分：第一部分是验证你计划好要检查什么，而不是让代理发明标准；第二部分是给循环具体需求，让它不偏离目标。这正是由软件开发者Matt Pocock制作的技能——Wayfinder的用武之地。

Wayfinder是Pocock发布的一套技能中的"密集规划技能"，基于他在AI出现前作为开发者学到的规划方法，完全不依赖编码。它针对的核心痛点是：代理从不告诉你它"处于迷雾中"，而是用自己的假设填补空白继续规划，导致你得到一个看起来完整、但中间有虚构部分的计划。

Wayfinder的做法是构建一张"地图"，把每个需要做出的决定作为问题放在地图上。这些问题分成两组：一组现在就能解决（依赖项已确定），另一组仍在迷雾中（被未调查的东西阻碍）。当遇到迷雾时，Wayfinder不猜测，而是派代理去清除迷雾——通过研究、构建粗略原型来查看，或做现实工作（如注册服务来评估）。每个问题单独处理，解决后答案回到地图解锁下一步，直到没有迷雾。

最终Wayfinder将所有决定转化为一份"规格"（Spec）——描述构建什么和为什么的文档。这份规格正是挑战循环缺失的那一块：就像使命召唤作为游戏基准一样，规格成为验证完成标准的坚实依据。里面每个决定都被实际解决而非假设，评论家因此有了可靠的对标对象。

"规划迷雾"（Fog of Planning）这一概念源于软件工程中的需求不确定性问题，与军事术语"战争迷雾"（Fog of War）类比。在传统软件开发中，需求模糊是项目返工的首要原因——开发者会在缺乏信息时依赖假设推进，直到集成测试阶段才暴露矛盾。AI代理面临同样问题，但更隐蔽：模型不会报错停止，而是用看似合理的内容填满空白，输出一个"表面完整、内核虚构"的计划。规格文件（Spec）在软件工程中有悠久传统，从RFC（请求评论文档）到敏捷开发中的用户故事，本质都是在编码前用自然语言或结构化文档对齐所有利益相关方的预期。Wayfinder将这一传统工程实践适配为AI可执行的工作流，让规格文件既是规划产出，也成为后续评论家代理的验证锚点。

实战：用改造版Wayfinder构建HR系统

视频以一个HR系统为例（支持申请休假、提交投诉等）演示了完整流程。原始Wayfinder可从GitHub安装，但它有个问题：规划过于详尽，会一路带你到完整规格。而这里只需要"获得清晰度"的规划部分。

于是他们让Claude修改技能：不写多个单独文件，而是将决定转化为单一答案文件供代理自我检查。改造后的版本只写两个文件——地图和答案文件，并精简了对Pocock其他技能的依赖，最终只需三个技能（其中提问环节用到了Grimm技能）。

运行时，代理针对HR系统提出了34个问题：应用面向谁、必须包含什么、不包含什么、完成后应该是什么样、用户可能遇到什么问题。这场漫长的来回结束后，它在".wayfinder"文件夹中写出两个文件——地图（记录每个决定及原因）和答案文件（每行返回通过或失败的检查项）。

接着复制Matt发布的原始挑战循环提示交给Claude，让它为HR系统重写。唯一改变的是衡量标准：不再是游戏，而是让".wayfinder"文件夹作为"真相来源"，所有东西按里面的内容检查——正如原始版本中使命召唤的作用。明确告诉它没有捷径、没有"足够接近"的替代品。

Claude先规划构建内容、需安装的工具、基础工作，然后同时启动多个代理分别负责系统的不同部分。整个构建耗时1小时33分钟，用掉了约40%的绘画（用量）限制。如果在API上运行，同样的构建约花费116美元。成本不低，但产出是一个按计划构建、每个功能都正常工作的应用——虽有小问题，但整体接近需求。

总结：让AI构建真实项目的关键

挑战循环的爆火揭示了AI代理并行协作的巨大潜力，但"自我评判"和"依赖现成基准"这两个缺陷让它难以直接用于原创项目。Wayfinder的价值在于用严谨的规划流程产出一份可验证的规格文件，把"评论家凭空发明标准"变成"评论家依据坚实规格检查"。

这套组合的核心思路对开发者有普遍启示：AI代理的可靠性不取决于提示词有多花哨，而取决于你是否为它提供了明确、可验证的成功标准。当没有现成产品可对标时，先把"规划迷雾"清理干净，再让循环跑起来。