获取开发者通讯
产品更新、操作指南、社区聚焦等更多内容。每月发送至您的收件箱。
作者：Prithvi Rajasekaran，我们 Labs 团队的成员。
在过去的几个月里，我一直在研究两个相互关联的问题：让 Claude 产出高质量的前端设计，以及让它无需人工干预即可构建完整的应用程序。这项工作源于此前在前端设计技能和长时间运行的编码智能体框架上的努力，我和同事通过提示工程和框架设计，将 Claude 的表现提升到远超基线的水平——但两者最终都遇到了瓶颈。
为了突破瓶颈，我寻找了新颖的 AI 工程方法，这些方法需在两个截然不同的领域中都成立：一个由主观品味定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GAN）的启发，我设计了一种包含生成器和评估器智能体的多智能体结构。构建一个能够可靠且有品味地给输出评分的评估器，意味着首先要开发一套标准，将“这个设计好吗？”这类主观判断转化为具体、可评分的术语。
随后，我将这些技术应用于长时间运行的自主编码，并沿用了此前框架工作中的两条经验：将构建过程分解为可处理的块，以及使用结构化产物在会话之间传递上下文。最终结果是一个三智能体架构——规划器、生成器和评估器——它能在数小时的自主编码会话中产出丰富的全栈应用程序。
我们此前已经表明，框架设计对长时间运行的智能体编码的有效性有重大影响。在早前的一项实验中，我们使用一个初始化智能体将产品规格分解为任务列表，并使用一个编码智能体一次实现一个功能，然后交接产物以跨会话传递上下文。更广泛的开发者社区也得出了类似的见解，诸如“Ralph Wiggum”方法使用钩子或脚本让智能体保持持续的迭代循环。
但一些问题仍然存在。对于更复杂的任务，智能体仍倾向于随着时间推移而偏离轨道。在分解这一问题时，我们观察到智能体执行这类任务时有两种常见的失败模式。
首先，随着上下文窗口被填满，模型往往会在冗长任务中失去连贯性（参见我们关于上下文工程的文章）。一些模型还会表现出“上下文焦虑”，即当它们接近自认为的上下文限制时，会过早地开始收尾工作。上下文重置——完全清空上下文窗口并启动一个全新的智能体，结合携带前一个智能体状态和后续步骤的结构化交接——可以解决这两个问题。
这与压缩（compaction）不同，压缩是将对话的较早部分就地总结，以便同一个智能体能够继续在缩短的历史记录上工作。虽然压缩保持了连续性，但它并没有给智能体一个全新的开始，这意味着上下文焦虑仍然可能存在。重置提供了一个全新的开始，代价是交接产物需要包含足够的状态，以便下一个智能体能够干净地接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出的上下文焦虑足够强烈，以至于仅靠压缩不足以实现强大的长任务性能，因此上下文重置对于 harness 设计变得至关重要。这解决了核心问题，但增加了编排复杂性、token 开销以及每次 harness 运行的延迟。
第二个问题，我们之前尚未解决，是自我评估。当被要求评估自己产出的工作时，智能体倾向于自信地赞扬工作——即使对人类观察者来说，质量明显平庸。这个问题在诸如设计等主观任务上尤为突出，因为不存在等同于可验证软件测试的二元检查。一个布局是感觉精致还是普通是一种主观判断，而智能体在给自己的作品打分时可靠地偏向正面。
然而，即使在那些确实有可验证结果的任务上，智能体有时也会表现出糟糕的判断力，从而阻碍其在完成任务时的表现。将执行工作的智能体与评判工作的智能体分开，被证明是解决这一问题的有力杠杆。这种分离本身并不会立即消除那种宽容；评估者仍然是一个 LLM，倾向于对 LLM 生成的输出慷慨。但调整一个独立的评估者使其持怀疑态度，远比让生成者对自己的工作持批判态度要容易得多，而且一旦存在这种外部反馈，生成者就有了具体的依据来进行迭代。
我从前端设计开始实验，因为自我评估问题在那里最为明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局，这些布局在技术上可行但视觉上平平无奇。
两个见解塑造了我为前端设计构建的 harness。首先，虽然美学不能完全简化为一个分数——个人品味总是会有所不同——但可以通过编码设计原则和偏好的评分标准来改进。“这个设计美吗？”很难一致地回答，但“这遵循了我们良好设计的原则吗？”给了 Claude 一些具体的评分依据。其次，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，推动生成器产生更强的输出。
考虑到这一点，我写了四条评分标准，并在提示中同时提供给了生成器和评估器智能体：
我强调设计质量和原创性，而非工艺和功能性。Claude 在默认情况下已经在工艺和功能性上得分很高，因为所需的技术能力往往对模型来说很自然。但在设计和原创性上，Claude 经常产生充其量只是平淡无奇的输出。这些标准明确惩罚了高度通用的“AI 垃圾”模式，并通过更重地加权设计和原创性，推动模型进行更多的美学冒险。
我使用带有详细评分细项的少样本示例来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了迭代过程中的分数漂移。
我在 Claude Agent SDK 上构建了这个循环，这使得编排保持简单直接。一个生成器代理首先根据用户提示创建 HTML/CSS/JS 前端。我给评估器配备了 Playwright MCP，使其能够在为每个标准评分并撰写详细评论之前直接与实时页面交互。在实践中，评估器会自行浏览页面，截图并仔细研究实现，然后给出评估。这些反馈作为下一次迭代的输入流回生成器。每次生成我运行 5 到 15 次迭代，每次迭代通常会在生成器回应评估器评论时将其推向更具特色的方向。由于评估器是在主动浏览页面而不是对静态截图评分，每个周期都耗费了真实的实际时间。完整运行时间长达四小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好，就完善当前方向；如果方法不奏效，就转向完全不同的美学风格。
在多次运行中，评估器的评估随着迭代而改善，然后趋于平稳，仍有提升空间。有些生成是渐进式改进。另一些则在迭代之间发生了急剧的美学转变。
标准的措辞以我未曾完全预料到的方式引导了生成器。包含诸如“最好的设计是博物馆级别的”这样的短语，将设计推向特定的视觉趋同，这表明与标准相关的提示直接塑造了输出的特征。
虽然分数总体上随着迭代而提高，但模式并不总是清晰的线性。后期的实现整体上往往更好，但我经常看到我更喜欢中间某次迭代而非最后一次的情况。实现复杂度也倾向于逐轮增加，生成器会响应评估器的反馈而寻求更宏大的解决方案。即使在第一次迭代中，输出也明显优于完全没有提示的基线，这表明在任何评估器反馈导致进一步改进之前，标准及相关语言本身就已经引导模型远离了通用默认值。
在一个显著的例子中，我提示模型为一个荷兰艺术博物馆创建一个网站。到第九次迭代时，它已经为一个虚构的博物馆生成了一个干净、深色主题的着陆页。页面视觉上很精致，但基本符合我的预期。然后，在第十个周期，它完全抛弃了这种方法，将网站重新构想为一种空间体验：一个用 CSS 透视渲染的带有棋盘格地板的 3D 房间，艺术品以自由形式的位置挂在墙上，并且通过门道在画廊房间之间导航，而不是滚动或点击。这是那种我在单次生成中从未见过的创造性飞跃。
有了这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和 QA 与设计评估器承担相同的结构性角色。
在我们早先的长时间运行的 harness中，我们通过一个初始化 agent、一个一次只处理一个功能的编码 agent，以及会话之间的上下文重置，解决了连贯的多会话编码问题。上下文重置是一个关键的突破点：该 harness 使用的是 Sonnet 4.5，它表现出了前面提到的“上下文焦虑”倾向。创建一个能在上下文重置之间良好运作的 harness，是让模型保持任务专注的关键。Opus 4.5 在很大程度上自行消除了这种行为，因此我能够从这个 harness 中完全去掉上下文重置。这些 agent 在整个构建过程中作为一个连续会话运行，由 Claude Agent SDK 的自动压缩来处理过程中不断增长的上下文。
在这项工作中，我在原始 harness 的基础上构建了一个三 agent 系统，每个 agent 都针对我在先前运行中观察到的一个具体缺口。该系统包含以下 agent 角色：
Planner（规划者）： 我们之前的长时间运行 harness 要求用户预先提供详细规格说明。我想自动化这一步，因此创建了一个 planner agent，它接收一个简单的 1-4 句话的提示，并将其扩展为完整的产品规格。我提示它要在范围上雄心勃勃，并专注于产品上下文和高层技术设计，而不是详细的技术实现。这种强调是因为担心如果 planner 试图预先指定细粒度的技术细节并弄错了某些东西，规格中的错误会级联到下游实现中。更聪明的做法似乎是约束 agent 要交付的成果，让它们在工作过程中自行找出路径。我还要求 planner 寻找机会将 AI 功能融入产品规格中。（参见底部附录中的示例。）
Generator（生成者）： 早先 harness 中一次只处理一个功能的方法在范围管理方面效果很好。我在这里应用了类似的模式，指示 generator 以冲刺的方式工作，一次从规格中选取一个功能。每个冲刺都使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）技术栈来实现应用，并且指示 generator 在每个冲刺结束时、交接给 QA 之前先自我评估其工作。它还有 git 用于版本控制。
Evaluator（评估者）： 早先 harness 生成的应用往往看起来令人印象深刻，但当你真正尝试使用时仍然存在真实缺陷。为了捕捉这些问题，evaluator 使用 Playwright MCP 像用户一样点击浏览正在运行的应用，测试 UI 功能、API 端点和数据库状态。然后它根据发现的缺陷以及一套仿照前端实验建模的标准来给每个冲刺评分，这些标准在此经过调整，以涵盖产品深度、功能、视觉设计和代码质量。每个标准都有一个硬性阈值，如果任何一项低于该阈值，该冲刺即告失败，generator 会收到关于哪里出错的详细反馈。
在每个冲刺（sprint）开始之前，生成器和评估器会协商一份冲刺契约：在编写任何代码之前，就先就这部分工作的“完成”标准达成一致。之所以这样做，是因为产品规格说明有意保持在高层次，我希望有一个步骤来弥合用户故事与可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器则审查该提案，以确保生成器构建的是正确的东西。两者反复迭代，直到达成一致。
沟通通过文件进行：一个智能体写入一个文件，另一个智能体读取它，并在该文件中回复，或者用一个新文件回复，而前一个智能体随后会读取这个新文件。生成器随后按照商定的契约进行构建，然后再将工作交给 QA。这使工作忠实于规格说明，同时又不会过早地对实现过度细化。
对于这个测试框架的第一个版本，我使用了 Claude Opus 4.5，将用户提示词分别针对完整测试框架和单智能体系统运行，以进行比较。我使用 Opus 4.5，是因为在我开始这些实验时，它是我们最好的编码模型。
我编写了以下提示词来生成一个复古电子游戏制作器：
创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。
下表显示了测试框架类型、运行时长和总成本。
| 测试框架 | 时长 | 成本 |
|---|---|---|
| 单智能体 | 20 分钟 | $9 |
| 完整测试框架 | 6 小时 | $200 |
该测试框架的成本高出 20 倍以上，但输出质量的差异立刻显而易见。
我原本期待的是一个界面，在其中我可以构建一个关卡及其组成部分（精灵、实体、瓦片布局），然后点击播放来实际游玩该关卡。我先打开了单智能体运行的输出，初始应用看起来符合这些预期。
然而，当我继续点击时，问题开始出现。布局浪费空间，固定高度的面板让视口的大部分区域空着。工作流程很僵化。尝试填充关卡时，系统提示我先创建精灵和实体，但 UI 中没有任何内容引导我按这个顺序操作。更关键的是，实际游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入代码后发现，实体定义与游戏运行时之间的连接是坏的，而且表面上没有任何迹象表明问题出在哪里。
在评估完单智能体运行后，我把注意力转向了测试框架运行。这次运行从同一个一句话提示词开始，但规划器步骤将该提示词扩展为一份包含 16 项功能的规格说明，分布在十个冲刺中。它远远超出了单智能体运行所尝试的范围。除了核心编辑器和游玩模式外，规格说明还要求一个精灵动画系统、行为模板、音效和音乐、一个 AI 辅助的精灵生成器和关卡设计器，以及带有可分享链接的游戏导出功能。我让规划器访问了我们的前端设计技能，它阅读了该技能，并用其为应用创建了一套视觉设计语言，作为规格说明的一部分。对于每个冲刺，生成器和评估器都会协商一份契约，定义该冲刺的具体实现细节，以及为验证完成情况而将测试的可测试行为。
该应用立即显得比单独运行更精致、更流畅。画布使用了整个视口，面板尺寸合理，界面具有一致的视觉识别，遵循了规格中的设计方向。单独运行中看到的一些笨拙之处仍然存在——工作流程仍然没有明确说明应该先构建精灵和实体，然后再尝试填充关卡，我不得不通过摸索来弄清楚这一点。这看起来是基础模型产品直觉上的缺口，而不是测试框架旨在解决的问题，尽管它确实表明了一个可以通过在测试框架内进行针对性迭代来进一步提高输出质量的领域。
在使用编辑器时，新运行相对于单独运行的优势变得更加明显。精灵编辑器更丰富、功能更全面，工具面板更清晰，颜色选择器更好，缩放控制更可用。
因为我要求规划器将 AI 功能融入其规格中，所以该应用还内置了 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加快了工作流程。
最大的区别在于游戏模式。我实际上能够移动我的实体并玩游戏。物理效果有一些粗糙之处——我的角色跳到一个平台上，但最终与平台重叠，这感觉上不对——但核心功能是有效的，而单独运行未能做到这一点。在移动了一会儿后，我确实遇到了 AI 游戏关卡构建的一些限制。有一堵大墙我无法跳过，所以我卡住了。这表明测试框架可以处理一些常识性改进和边缘情况，以进一步优化应用。
阅读日志后，很明显评估器使实现与规格保持一致。每个冲刺，它都会遍历冲刺合同的测试标准，并通过 Playwright 运行应用程序，对任何偏离预期行为的地方提交错误。合同非常细致——仅冲刺 3 就有 27 条标准涵盖关卡编辑器——评估器的发现足够具体，无需额外调查即可采取行动。下表显示了我们的评估器识别出的几个问题示例：
| 合同标准 | 评估器发现 |
|---|---|
| 矩形填充工具允许点击拖动以用选定的图块填充矩形区域 | 失败——工具只在拖动起点/终点放置图块，而不是填充区域。fillRectangle 函数存在，但在 mouseUp 时未正确触发。 |
| 用户可以选择并删除放置的实体生成点 | 失败——LevelEditor.tsx:892 处的删除键处理程序要求同时设置 selection 和 selectedEntityId，但点击实体只设置 selectedEntityId。条件应为 `selection |
| 用户可以通过 API 重新排序动画帧 | 失败——PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 'reorder' 匹配为 frame_id 整数并返回 422：“无法将字符串解析为整数。” |
让评估器达到这种水平需要付出努力。开箱即用时，Claude 是一个糟糕的 QA 代理。在早期运行中，我观察到它能识别出合理的问题，然后说服自己这些问题没什么大不了，最终还是批准了工作。它还倾向于进行表面测试，而不是深入探究边缘情况，因此更细微的 bug 常常被漏掉。调优循环就是阅读评估器的日志，找出其判断与我的判断不一致的例子，并更新 QA 的提示词来解决这些问题。经过几轮这样的开发循环，评估器的评分方式才让我觉得合理。即便如此，测试框架的输出也显示了模型 QA 能力的局限：小的布局问题、某些地方感觉不直观的交互，以及评估器没有彻底检验的更深层嵌套功能中未被发现的 bug。显然，通过进一步调优还有更多的验证空间可以挖掘。但与单独运行相比——当时应用程序的核心功能根本无法工作——提升是显而易见的。
第一组测试框架结果令人鼓舞，但它也庞大、缓慢且昂贵。合乎逻辑的下一步是找到简化测试框架而不降低其性能的方法。这既是常识，也源于一个更普遍的原则：测试框架中的每个组件都编码了一个关于模型自身无法完成什么的假设，这些假设值得进行压力测试，因为它们可能不正确，也可能随着模型的改进而迅速过时。我们的博客文章构建有效代理将这一基本思想概括为“找到最简单的解决方案，只在需要时增加复杂性”，这是一个任何维护代理测试框架的人都会反复看到的模式。
在我第一次尝试简化时，我大幅削减了测试框架，并尝试了一些有创意的新想法，但我无法复制原始版本的性能。而且，很难判断测试框架设计中哪些部分是真正承重的，以及以何种方式承重。基于那次经验，我转向了一种更有条理的方法：一次移除一个组件，并审视它对最终结果的影响。
在我进行这些迭代循环时，我们还发布了 Opus 4.6，这为降低测试框架复杂性提供了进一步动力。有充分理由预期 4.6 比 4.5 需要更少的脚手架。从我们的发布博客：“[Opus 4.6] 规划更仔细，能更长时间地维持代理任务，在更大的代码库中更可靠地运行，并具有更好的代码审查和调试技能来发现自己的错误。”它在长上下文检索方面也有显著改进。这些都是测试框架原本为补充而构建的能力。
我从完全移除冲刺构造开始。冲刺结构曾有助于将工作分解成块，以便模型连贯地工作。鉴于 Opus 4.6 的改进，有充分理由相信模型可以原生处理这项工作，而无需这种分解。
我保留了规划器和评估器，因为二者都持续带来明显的价值。没有规划器时，生成器的范围界定不足：给定原始提示，它会在没有先规划工作的情况下就开始构建，最终创建出的应用功能不如有规划器时丰富。
移除冲刺结构后，我把评估器改为在运行结束时进行一次评估，而不是每个冲刺都评分。由于模型能力大幅提升，评估器在某些运行中的关键程度发生了变化，其有用性取决于任务相对于模型能独立可靠完成的范围处于什么位置。在 4.5 上，这个边界很近：我们的构建处于生成器单独能做好范围的边缘，评估器在整个构建过程中发现了有意义的问题。在 4.6 上，模型的原始能力提升了，因此边界向外移动。过去需要评估器检查才能连贯实现的任务，现在往往已在生成器单独能处理好的范围内，对于该边界内的任务，评估器变成了不必要的开销。但对于构建中仍处于生成器能力边缘的部分，评估器继续带来真正的提升。
实际含义是，评估器不是一个固定的“是或否”决策。当任务超出当前模型能可靠单独完成的范围时，它就值得付出成本。
除了结构简化，我还添加了提示词，以改进测试框架如何将 AI 功能构建到每个应用中，具体是让生成器构建一个合适的智能体，能够通过工具驱动应用自身的功能。这需要真正的迭代，因为相关知识足够新，Claude 的训练数据对其覆盖很薄。但经过足够的调优，生成器能够正确地构建智能体。
为了测试更新后的测试框架，我使用以下提示词生成一个数字音频工作站（DAW），一个用于作曲、录音和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。
这次运行仍然耗时且昂贵，大约 4 小时，token 成本 124 美元。
大部分时间花在构建器上，它连贯运行了超过两小时，不需要 Opus 4.5 所需的冲刺分解。
智能体与阶段 | 时长 | 成本 |
规划器 | 4.7 分钟 | $0.46 |
构建（第 1 轮） | 2 小时 7 分钟 | $71.08 |
QA（第 1 轮） | 8.8 分钟 | $3.24 |
构建（第 2 轮） | 1 小时 2 分钟 | $36.89 |
QA（第 2 轮） | 6.8 分钟 | $3.09 |
构建（第 3 轮） | 10.9 分钟 | $5.88 |
QA（第 3 轮） | 9.6 分钟 | $4.06 |
V2 测试框架总计 | 3 小时 50 分钟 | $124.70 |
与之前的测试框架一样，规划器将一行提示词扩展为完整规格。从日志中，我可以看到生成器模型在规划应用和智能体设计、连接智能体以及在移交给 QA 之前进行测试方面做得很好。
话虽如此，QA 智能体仍然发现了真正的缺口。在其第一轮反馈中，它指出：
这是一款出色的应用，设计还原度极高，AI 代理扎实，后端也很不错。主要的不足之处在于功能完整性——虽然应用看起来令人印象深刻，AI 集成也运行良好，但几个核心 DAW 功能仅停留在展示层面，缺乏交互深度：片段无法在时间轴上拖拽/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（EQ 曲线、压缩器电平表）。这些并非边缘情况——它们是让 DAW 可用的核心交互，而规格说明中明确要求了这些功能。
在第二轮反馈中，它再次发现了几个功能缺口：
剩余缺口：
音频录制仍仅为存根（按钮可切换但无麦克风采集）
通过边缘拖拽调整片段大小和片段分割未实现
效果可视化是数字滑块，而非图形化（无 EQ 曲线）
当任由生成器自行其是时，它仍然容易遗漏细节或仅实现存根功能，而 QA 在捕捉这些最后一英里问题以供生成器修复方面仍然具有价值。
根据提示词，我期望的是一个可以创建旋律、和声和鼓点模式，将它们编排成一首歌曲，并在过程中获得集成代理帮助的程序。下面的视频展示了结果。
这款应用远非专业音乐制作程序，代理的歌曲创作能力显然还有很大提升空间。此外，Claude 实际上无法听到声音，这使得 QA 反馈循环在音乐品味方面效果不佳。
但最终的应用具备了功能性音乐制作程序的所有核心部分：在浏览器中运行的编曲视图、混音器和走带控制。除此之外，我能够完全通过提示词拼凑出一段简短的歌曲片段：代理设置了速度和调性，铺设了旋律，构建了鼓轨，调整了混音器电平，并添加了混响。歌曲创作的核心原语已经具备，代理可以自主驱动它们，使用工具端到端地完成一个简单的制作。可以说它还不是完美音准——但它正在接近。
随着模型不断改进，我们可以大致预期它们能够工作更长时间，处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随时间推移变得不那么重要，开发者可以等待下一个模型，让某些问题自行解决。另一方面，模型越好，就有越大的空间来开发能够完成模型基线能力之外的复杂任务的测试框架。
考虑到这一点，这项工作中有几个值得延续的经验教训。始终好的做法是针对你正在构建的模型进行实验，阅读其在现实问题上的轨迹，并调整其性能以实现你期望的结果。在处理更复杂的任务时，有时通过分解任务并为问题的每个方面应用专门的代理，可以获得提升空间。当新模型出现时，通常好的做法是重新审视测试框架，剥离不再对性能起关键作用的部分，并添加新的部分以实现以前可能无法达到的更强能力。
从这项工作中，我坚信随着模型改进，有趣测试框架组合的空间不会缩小。相反，它会移动，而 AI 工程师的有趣工作就是不断寻找下一个新颖的组合。
特别感谢 Mike Krieger、Michael Agaby、Justin Young、Jeremy Hadfield、David Hershey、Julius Tarng、Xiaoyi Zhang、Barry Zhang、Orowa Sidker、Michael Tingley、Ibrahim Madha、Martina Long 和 Canyon Robbins 对这项工作的贡献。
同样感谢 Jake Eaton、Alyssa Leonard 和 Stef Sequeira 帮助完善这篇文章。
由规划智能体生成的示例计划。
RetroForge - 2D 复古游戏制作器
概述
RetroForge 是一个基于网页的创意工作室，用于设计和构建 2D 复古风格电子游戏。它将经典 8 位和 16 位游戏美学的怀旧魅力与现代、直观的编辑工具相结合——让从业余爱好者创作者到独立开发者的任何人都能在不编写传统代码的情况下将自己的游戏创意变为现实。
该平台提供四个集成的创意模块：用于设计游戏世界的基于瓦片（tile）的关卡编辑器、用于制作视觉资产的像素艺术精灵编辑器、用于定义游戏逻辑的可视化实体行为系统，以及用于实时游戏测试的即时可玩测试模式。通过将 AI 辅助贯穿其中（由 Claude 提供支持），RetroForge 加速了创作过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。
RetroForge 面向喜爱复古游戏美学但希望获得现代便利的创作者。无论是重现童年时代的平台游戏、RPG 或动作游戏，还是在复古限制下创造全新的体验，用户都可以快速制作原型、以可视化方式迭代，并与他人分享自己的作品。
功能
1. 项目仪表板与管理
项目仪表板是 RetroForge 中所有创作工作的主基地。用户需要一种清晰、有条理的方式来管理他们的游戏项目——创建新项目、返回进行中的作品，并一目了然地了解每个项目包含的内容。
用户故事：作为用户，我希望：
- 创建一个带有名称和描述的新游戏项目，以便我可以开始设计我的游戏
- 看到我所有现有项目以可视化卡片形式显示，展示项目名称、最后修改日期和缩略图预览，以便我可以快速找到并继续我的工作
- 打开任何项目以进入完整的游戏编辑器工作区，以便我可以处理我的游戏
- 删除我不再需要的项目，并带有确认对话框以防止意外，以便我可以保持工作区井然有序
- 复制现有项目作为新游戏的起点，以便我可以复用之前的作品
项目数据模型：每个项目包含：
项目元数据（名称、描述、创建/修改时间戳）
画布设置（分辨率：例如 256x224、320x240 或 160x144）
瓦片尺寸配置（8x8、16x16 或 32x32 像素）
调色板选择
所有关联的精灵、瓦片集、关卡和实体定义
...
产品更新、操作指南、社区聚焦等更多内容。每月发送至您的收件箱。