长时间运行应用开发的套件设计 | Anthropic

来源: https://www.anthropic.com/engineering/harness-design-long-running-apps 抓取时间: 2026-07-21 16:20:19

_作者：Prithvi Rajasekaran，我们 Labs 团队成员。

在过去的几个月里，我一直在研究两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在无需人工干预的情况下构建完整应用。这项工作源于我们早期在前端设计技能和长时间运行编码智能体套件方面的努力，在那里我和同事们能够通过提示工程和套件设计将 Claude 的性能提升到远超基线的水平——但两者最终都遇到了天花板。

为了突破，我寻求了在两个截然不同领域都有效的新型 AI 工程方法，一个由主观品味定义，另一个由可验证的正确性和可用性定义。从生成对抗网络（GANs）中汲取灵感，我设计了一个具有生成器和评估器智能体的多智能体结构。构建一个能够可靠地——并且带有品味地——对输出进行评分的评估器，意味着首先制定一套标准，可以将"这个设计好吗？"这样的主观判断转化为具体的、可评分的术语。

然后，我将这些技术应用于长时间运行的自主编码，从我们早期的套件工作中继承了两个教训：将构建分解为可处理的块，以及使用结构化工件在会话之间传递上下文。最终结果是一个三智能体架构——规划器、生成器和评估器——它在数小时的自主编码会话中生成了丰富的全栈应用。

为什么朴素实现会失败

我们之前已经表明，套件设计对长时间运行的智能体编码的有效性有重大影响。在早期的实验中，我们使用初始化器智能体将产品规格分解为任务列表，并使用编码智能体一次实现一个功能，然后移交工件以在会话之间传递上下文。更广泛的开发者社区已经达成了类似的见解，例如"Ralph Wiggum"方法，使用钩子或脚本使智能体保持在连续迭代周期中。

但是一些问题仍然持续存在。对于更复杂的任务，智能体仍然倾向于随着时间的推移偏离轨道。在分解这个问题时，我们观察到智能体执行这类任务时的两种常见失败模式。

首先，随着上下文窗口的填充，模型在冗长任务上往往失去连贯性（参见我们关于上下文工程的帖子）。一些模型还表现出"上下文焦虑"，当它们接近它们认为的上下文限制时，它们开始过早地结束工作。上下文重置——完全清除上下文窗口并启动新的智能体，结合携带前一个智能体状态和下一步的结构化移交——解决了这两个问题。

这与压缩不同，压缩是将对话的较早部分就地总结，以便同一个智能体可以在缩短的历史记录上继续工作。虽然压缩保持了连续性，但它没有给智能体一个干净的起点，这意味着上下文焦虑仍然可能持续存在。重置提供了一个干净的起点，但代价是移交工件必须有足够的状态，以便下一个智能体能够干净地接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出足够强烈的上下文焦虑，以至于仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为套件设计的关键。这解决了核心问题，但增加了编排复杂性、令牌开销和每次套件运行的延迟。

第二个问题——我们之前没有解决过的——是自我评估。当被要求评估它们自己生成的工作时，智能体倾向于自信地赞美工作——即使在人类观察者看来，质量明显平庸。对于像设计这样的主观任务，这个问题尤其突出，因为没有相当于可验证软件测试的二进制检查。布局感觉是精雕细琢还是千篇一律是一种判断，智能体在给自己的工作打分时一贯偏向积极。

然而，即使在确实有可验证结果的任务上，智能体有时仍然表现出糟糕的判断力，这在完成任务时阻碍了它们的表现。将做工作的智能体与评判工作的智能体分开被证明是解决这个问题的有力杠杆。这种分离本身并不能立即消除那种宽大处理；评估器仍然是一个 LLM，它倾向于对 LLM 生成的输出慷慨。但是，调整一个独立的评估器使其具有怀疑态度，结果证明比让生成器对自己的工作持批评态度要容易得多，并且一旦存在外部反馈，生成器就有具体的东西可以迭代改进。

前端设计：使主观质量可评分

我从前端设计开始实验，那里的自我评估问题最为明显。如果没有任何干预，Claude 通常会倾向于安全、可预测的布局，这些布局在技术上是功能性的，但在视觉上并不出众。

两个见解塑造了我为前端设计构建的套件。首先，虽然美学不能完全简化为分数——并且个人品味会始终变化——但它们可以通过编码设计原则和偏好的评分标准来改进。"这个设计漂亮吗？"很难一致地回答，但"这是否遵循我们的良好设计原则？"给了 Claude 一些具体的评分依据。其次，通过将前端生成与前端评分分开，我们可以创建一个反馈循环，驱动生成器朝向更强的输出。

考虑到这一点，我写了四个评分标准，我在它们的提示中同时给了生成器和评估器智能体：

• 设计质量： 这个设计感觉像是一个连贯的整体，而不是各个部分的集合吗？这里的出色工作意味着颜色、排版、布局、图像和其他细节结合起来创造出独特的氛围和身份。
• 原创性： 是否有自定义决策的证据，还是这只是模板布局、库默认值和 AI 生成的模式？人类设计师应该识别出刻意的创意选择。未修改的库存组件——或者像白色卡片上的紫色渐变这样的 AI 生成的明显迹象——在这一项上会失败。
• 工艺： 技术执行：排版层次结构、间距一致性、色彩和谐、对比度。这是能力检查而不是创造力检查。大多数合理的实现默认在这一项上表现良好；失败意味着基本原理被破坏了。
• 功能性： 独立于美学的可用性。用户能理解界面做什么，找到主要操作，并在无需猜测的情况下完成任务吗？

我强调设计质量和原创性胜过工艺和功能性。默认情况下，Claude 在工艺和功能性上已经得分很高，因为所需的技术能力往往是模型天生具备的。但在设计和原创性上，Claude 往往产生充其量是平淡无奇的输出。这些标准明确惩罚了高度通用的"AI 垃圾"模式，通过更重视设计和原创性，它推动模型承担更多的美学风险。

我使用带有详细分数分解的少样本示例来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了迭代之间的分数漂移。

我在 Claude Agent SDK 上构建了循环，这使得编排变得简单明了。生成器智能体首先根据用户提示创建一个 HTML/CSS/JS 前端。我给了评估器 Playwright MCP，这让它可以直接与实时页面交互，然后对每个标准进行评分并写出详细的评论。在实践中，评估器会自己导航页面，截图并仔细研究实现，然后生成评估。该反馈作为下一次迭代的输入流回生成器。每次生成我运行 5 到 15 次迭代，每次迭代通常都会推动生成器朝着更独特的方向发展，因为它响应了评估器的批评。因为评估器是主动导航页面而不是对静态截图评分，所以每个周期都需要实际的时钟时间。完整运行长达四个小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好，则改进当前方向；如果方法不起作用，则转向完全不同的美学。

在所有运行中，评估器的评估在迭代后有所改善，然后趋于平稳，仍然有提升空间。一些生成是渐进式改进的。其他的在迭代之间采取了尖锐的美学转向。

标准的措辞以我没有完全预料到的方式引导了生成器。包括像"最好的设计是博物馆级的"这样的短语，将设计推向了特定的视觉趋同，这表明与标准相关的提示直接塑造了输出的特征。

虽然分数通常在迭代中提高，但模式并不总是完全线性的。后来的实现整体上往往更好，但我经常看到我更喜欢中间迭代而不是最后一个的情况。实现复杂性也往往在各轮中增加，生成器响应评估器的反馈而寻求更雄心勃勃的解决方案。即使在第一次迭代中，输出也明显优于根本没有提示的基线，这表明标准和相关语言本身就在任何评估器反馈导致进一步改进之前，引导模型远离通用默认值。

在一个值得注意的例子中，我提示模型为荷兰艺术博物馆创建一个网站。到第九次迭代时，它已经为一个虚构的博物馆生成了一个干净的深色主题登录页面。这个页面在视觉上很精致，但基本上符合我的预期。然后，在第十个周期，它完全放弃了这种方法，将网站重新想象为空间体验：一个 CSS 透视渲染的带有方格地板的 3D 房间，艺术品以自由形式的位置挂在墙上，以及基于门道的画廊房间导航，而不是滚动或点击。这是我以前从单次生成中没有见过的那种创造性飞跃。

扩展到全栈编码

有了这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和 QA 扮演着与设计评估器相同的结构角色。

架构

在我们早期的长时间运行套件中，我们通过初始化器智能体、一次处理一个功能的编码智能体以及会话之间的上下文重置，解决了连贯的多会话编码问题。上下文重置是一个关键的解锁：该套件使用 Sonnet 4.5，它表现出前面提到的"上下文焦虑"倾向。创建一个在上下文重置中运行良好的套件是保持模型专注于任务的关键。Opus 4.5 基本上消除了这种行为，所以我能够从这个套件中完全删除上下文重置。智能体作为一个连续会话在整个构建过程中运行，Claude Agent SDK的自动压缩处理了上下文的增长。

为了这项工作，我在原始套件的基础上构建了一个三智能体系统，每个智能体解决我在之前运行中观察到的特定差距。该系统包含以下智能体角色：

规划器： 我们之前的长时间运行套件要求用户预先提供详细的规格。我想自动化该步骤，所以我创建了一个规划器智能体，它接受一个简单的 1-4 句子提示并将其扩展为完整的产品规格。我提示它在范围上要有雄心，并专注于产品上下文和高级技术设计，而不是详细的技术实现。这种强调是因为担心如果规划器试图预先指定细粒度的技术细节并且出错，规格中的错误会级联到下游实现中。约束智能体在要生成的交付物上，然后让它们在工作时弄清楚路径，似乎更明智。我还要求规划器找到将 AI 功能融入产品规格的机会。（参见底部附录中的示例。）

生成器： 早期套件的一次一个功能的方法在范围管理方面效果很好。我在这里应用了类似的模型，指示生成器以 sprint 方式工作，从规格中一次挑选一个功能。每个 sprint 使用 React、Vite、FastAPI 和 SQLite（后来的 PostgreSQL）技术栈实现应用，并且生成器被指示在每个 sprint 结束时自我评估其工作，然后移交给 QA。它还有 Git 用于版本控制。

评估器： 早期套件的应用程序看起来往往令人印象深刻，但当你实际尝试使用它们时，仍然存在真正的错误。为了捕捉这些，评估器使用 Playwright MCP 像用户一样点击运行中的应用程序，测试 UI 功能、API 端点和数据库状态。然后，它根据发现的错误和一套模仿前端实验的标准对每个 sprint 进行评分，这些标准在这里被调整为涵盖产品深度、功能性、视觉设计和代码质量。每个标准都有一个硬阈值，如果任何一个低于阈值，sprint 就失败，生成器会得到关于哪里出错的详细反馈。

在每个 sprint 之前，生成器和评估器会协商一个 sprint 合同：在编写任何代码之前，就该块工作的"完成"是什么样的达成一致。这是因为产品规格有意是高级的，我想要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案以确保生成器正在构建正确的东西。两者迭代直到达成一致。

通信通过文件处理：一个智能体会写一个文件，另一个智能体会阅读它并在该文件内回应或用一个新文件回应，然后前一个智能体会依次阅读。生成器然后按照商定的合同进行构建，然后将工作移交给 QA。这使工作忠实于规格，而不会过早地过度指定实现。

运行套件

对于该套件的第一个版本，我使用了 Claude Opus 4.5，针对完整套件和单智能体系统运行用户提示以进行比较。我使用 Opus 4.5 是因为当我开始这些实验时，这是我们最好的编码模型。

我写了以下提示来生成一个复古视频游戏制作器：

创建一个 2D 复古游戏制作器，具有关卡编辑器、精灵编辑器、实体行为和可玩测试模式等功能。

下表显示了套件类型、运行时长和总成本。

套件的成本超过 20 倍，但输出质量的差异立即显现出来。

我期待一个界面，我可以在其中构建一个关卡及其组成部分（精灵、实体、瓦片布局），然后点击播放实际玩关卡。我首先打开了单智能体运行的输出，初始应用程序似乎符合这些期望。

然而，当我点击浏览时，问题开始出现。布局浪费空间，固定高度的面板让大部分视口为空。工作流程是僵化的。尝试填充关卡会提示我先创建精灵和实体，但 UI 中没有任何东西引导我走向那个序列。更重要的是，实际的游戏坏了。我的实体出现在屏幕上，但没有任何东西对输入做出响应。深入代码发现，实体定义和游戏运行时之间的连接已经断开，表面上没有迹象表明在哪里。

打开屏幕 精灵编辑器 游戏玩法

打开单智能体套件创建的应用程序时的初始屏幕。

在单智能体套件制作的精灵编辑器中创建精灵

尝试玩我创建的关卡但未成功

评估完单智能体运行后，我将注意力转向了套件运行。这次运行从同一个单句提示开始，但规划器步骤将该提示扩展到了十个 sprint 中的 16 个功能规格。它远远超出了单智能体运行所尝试的范围。除了核心编辑器和播放模式外，规格还要求精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及带有可共享链接的游戏导出。我让规划器可以访问我们的前端设计技能，它阅读并使用该技能为应用创建视觉设计语言作为规格的一部分。对于每个 sprint，生成器和评估器协商一个合同，定义 sprint 的具体实现细节，以及将被测试以验证完成的可测试行为。

该应用程序立即显示出比单智能体运行更多的润色和流畅性。Canvas 使用了整个视口，面板大小合理，界面具有一致的视觉身份，遵循规格中的设计方向。我在单智能体运行中看到的一些笨拙确实仍然存在——工作流程仍然没有明确表示你应该在尝试填充关卡之前构建精灵和实体，我必须通过四处摸索来弄清楚这一点。这被解读为基础模型的产品直觉的差距，而不是套件设计用来解决的问题，尽管它确实表明套件内部的有针对性迭代可以帮助进一步提高输出质量。

通过编辑器工作，新运行相对于单智能体的优势变得更加明显。精灵编辑器更丰富、功能更全，工具面板更干净，颜色选择器更好，缩放控件更可用。

因为我要求规划器在其规格中融入 AI 功能，所以该应用程序还带有内置的 Claude 集成，让我可以通过提示生成游戏的不同部分。这大大加快了工作流程。

打开屏幕 精灵编辑器 AI 游戏设计 AI 游戏设计 游戏玩法

初始屏幕：在使用完整套件构建的应用程序中创建新游戏

精灵编辑器感觉更干净、更易用

使用内置 AI 功能生成关卡

使用内置 AI 功能生成关卡

玩我生成的游戏

最大的区别是在播放模式。我实际上能够移动我的实体并玩游戏。物理有一些粗糙的边缘——我的角色跳到一个平台上，但最终与它重叠，这在直觉上感觉不对——但核心功能有效，这是单智能体运行没有做到的。四处移动后，我确实遇到了 AI 游戏关卡构建的一些限制。有一堵大墙我无法跳过去，所以我被困住了。这表明有一些常识性的改进和边缘情况，套件可以处理以进一步完善应用程序。

通读日志，很明显评估器使实现符合规格。每个 sprint，它都会遍历 sprint 合同的测试标准，并通过 Playwright 测试运行中的应用程序，对任何偏离预期行为的地方提交错误。合同是细粒度的——仅 Sprint 3 就有 27 个标准覆盖关卡编辑器——评估器的发现足够具体，无需额外调查就可以采取行动。下表显示了我们的评估器发现的几个问题示例：

让评估器达到这个水平的表现需要工作。开箱即用，Claude 是一个糟糕的 QA 智能体。在早期的运行中，我看着它发现了合法的问题，然后说服自己这些问题不是什么大问题，无论如何都批准了工作。它也倾向于表面测试，而不是探索边缘情况，所以更微妙的错误往往会漏过。调整循环是阅读评估器的日志，找到它的判断与我的判断不同的例子，并更新 QA 的提示来解决这些问题。经过几轮这样的开发循环，评估器才以我认为合理的方式进行评分。即使在那时，套件输出也显示了模型 QA 能力的局限性：小的布局问题、在某些地方感觉不直观的交互，以及评估器没有彻底测试的更深度嵌套功能中未发现的错误。显然，通过进一步调整还有更多的验证空间可以利用。但与单智能体运行相比，单智能体运行中应用程序的核心功能根本不起作用，这种提升是显而易见的。

迭代套件

第一组套件结果令人鼓舞，但它也很笨重、缓慢且昂贵。合乎逻辑的下一步是找到简化套件而不降低其性能的方法。这部分是常识，部分是一个更普遍原则的函数：套件中的每个组件都编码了一个关于模型本身不能做什么的假设，这些假设值得压力测试，既是因为它们可能不正确，也是因为它们可能会随着模型的改进而迅速过时。我们的博客文章构建有效的智能体将基本思想框架为"找到最简单的解决方案，并且只在需要时增加复杂性"，这是任何维护智能体套件的人都会持续看到的模式。

在我第一次尝试简化时，我大幅削减了套件并尝试了一些创造性的新想法，但我无法复制原始性能。也很难看出套件设计的哪些部分实际上是承载负载的，以及是以什么方式承载的。基于那次经验，我转向了更有条理的方法，一次移除一个组件并审查它对最终结果的影响。

在我经历这些迭代周期的同时，我们还发布了 Opus 4.6，这为减少套件复杂性提供了进一步的动力。有充分的理由期望 4.6 需要比 4.5 更少的脚手架。从我们的发布博客："[Opus 4.6]计划更仔细，维持智能体任务更长时间，可以在更大的代码库中更可靠地操作，并且有更好的代码审查和调试技能来捕捉自己的错误。"它在长上下文检索方面也有显著改进。这些都是套件原本旨在补充的所有能力。

移除 sprint 结构

我首先完全移除了 sprint 结构。sprint 结构帮助将工作分解为块，以便模型连贯地工作。考虑到 Opus 4.6 的改进，有充分的理由相信模型可以在没有这种分解的情况下本地处理这项工作。

我保留了规划器和评估器，因为每个都继续增加明显的价值。没有规划器，生成器会缩小范围：给定原始提示，它会在没有首先规划其工作的情况下开始构建，最终创建的应用程序功能比规划器做的要少。

随着 sprint 结构的移除，我将评估器移到运行结束时的单次通过，而不是每个 sprint 评分。由于模型能力大大提高，它改变了评估器对某些运行承载负载的方式，其有用性取决于任务相对于模型可以自己可靠完成的位置。在 4.5 上，这个边界很近：我们的构建处于生成器单独可以做好的边缘，评估器在整个构建过程中捕捉到了有意义的问题。在 4.6 上，模型的原始能力增加了，所以边界向外移动了。过去需要评估器检查才能连贯实现的任务现在通常在生成器自己可以很好处理的范围内，对于在该边界内的任务，评估器变成了不必要的开销。但对于仍处于生成器能力边缘的构建部分，评估器继续提供真正的提升。

实际含义是，评估器不是一个固定的是或否的决定。当任务超出当前模型可以单独可靠完成的范围时，值得付出代价。

除了结构简化外，我还添加了提示来改进套件如何将 AI 功能构建到每个应用程序中，特别是让生成器构建一个适当的智能体，该智能体可以通过工具驱动应用程序自己的功能。这需要真正的迭代，因为相关知识足够新，Claude 的训练数据对其覆盖很薄。但经过足够的调整，生成器正确地构建了智能体。

更新套件的结果

为了测试更新后的套件，我使用以下提示生成了一个数字音频工作站（DAW），这是一个用于作曲、录制和混音歌曲的音乐制作程序：

使用 Web Audio API 在浏览器中构建功能齐全的 DAW。

运行仍然冗长且昂贵，大约 4 小时，令牌成本为 124 美元。

大部分时间花在了构建器上，它在没有 Opus 4.5 所需的 sprint 分解的情况下连贯运行了两个多小时。

与之前的套件一样，规划器将单行提示扩展为完整规格。从日志中，我可以看到生成器模型在规划应用程序和智能体设计、连接智能体以及在移交给 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 位游戏美学的怀旧魅力与现代、直观的编辑工具相结合——使从业余创作者到独立开发者的任何人都无需编写传统代码即可将他们的游戏想法变为现实。

该平台提供四个集成的创意模块：用于设计游戏世界的基于瓦片的关卡编辑器，用于制作视觉资产的像素艺术精灵编辑器，用于定义游戏逻辑的可视化实体行为系统，以及用于实时游戏测试的即时可玩测试模式。通过在整个过程中编织 AI 辅助（由 Claude 提供支持），RetroForge 加速了创意过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。

RetroForge 面向喜欢复古游戏美学但想要现代便利的创作者。无论是重现童年时代的平台游戏、RPG 还是动作游戏，还是在复古约束内发明全新的体验，用户都可以快速原型化、可视化迭代，并与他人分享他们的创作。

功能
1. 项目仪表板和管理
项目仪表板是 RetroForge 所有创意工作的大本营。用户需要一种清晰、有组织的方式来管理他们的游戏项目——创建新项目，返回进行中的作品，并一目了然地了解每个项目包含的内容。

用户故事：作为用户，我想要：
- 创建一个带有名称和描述的新游戏项目，以便我可以开始设计我的游戏
- 查看所有现有项目显示为带有项目名称、最后修改日期和缩略图预览的可视化卡片，以便我可以快速找到并继续我的工作
- 打开任何项目进入完整的游戏编辑器工作区，以便我可以在我的游戏上工作
- 删除我不再需要的项目，并带有确认对话框以防止意外，以便我可以保持我的工作井井有条
- 复制现有项目作为新游戏的起点，以便我可以重用我以前的工作

项目数据模型：每个项目包含：
- 项目元数据（名称、描述、创建/修改时间戳）
- 画布设置（分辨率：例如，256x224、320x240 或 160x144）
- 瓦片大小配置（8x8、16x16 或 32x32 像素）
- 调色板选择
- 所有关联的精灵、瓦片集、关卡和实体定义

...