长时间运行应用开发的运行框架设计

在智能体式编码前沿，运行框架设计是影响表现的关键。下面介绍我们如何在前端设计和长时间运行的自主软件工程中进一步推动 Claude。

来源：https://www.anthropic.com/engineering/harness-design-long-running-apps
发布日期：2026-03-24

作者 Prithvi Rajasekaran 是我们 Labs 团队成员。

过去几个月，我一直在研究两个相互关联的问题：让 Claude 产出高质量前端设计，以及让它在无人干预的情况下构建完整应用。这项工作源于我们早先在前端设计 skill 和长时间运行编码智能体运行框架上的努力；我和同事通过提示工程和运行框架设计，把 Claude 的表现提升到远高于基线的水平，但二者最终都撞上了上限。

为了突破这些上限，我寻找能够同时适用于两个相当不同领域的新型 AI 工程方法：一个领域由主观品味定义，另一个则由可验证正确性和可用性定义。受生成式对抗网络（GAN）的启发，我设计了一个包含生成器和评估器智能体的多智能体结构。要构建一个能够可靠且有品味地为输出评分的评估器，首先意味着要制定一组标准，把“这个设计好吗？”这样的主观判断转化为具体、可评分的术语。

随后，我将这些技术应用到长时间运行的自主编码中，并沿用了早期运行框架工作的两个经验：把构建拆成易处理的块，并使用结构化产物在会话之间交接上下文。最终结果是一个三智能体架构：规划器、生成器和评估器，它能在持续数小时的自主编码会话中产出丰富的全栈应用。

为什么朴素实现会不足

我们此前已经展示过，运行框架设计会显著影响长时间运行智能体式编码的效果。在早先的实验中，我们使用初始化智能体将产品规格拆解成任务列表，并使用编码智能体一次实现一个功能，然后交接产物以便在会话之间携带上下文。更广泛的开发者社区也收敛到类似洞见，例如 “Ralph Wiggum” 方法使用 hooks 或脚本，让智能体持续处于迭代循环中。

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

第一，随着上下文窗口填满，模型在长任务上往往会失去连贯性（参见我们关于上下文工程的文章）。一些模型还表现出“上下文焦虑”：当它们接近自己认为的上下文限制时，会开始过早收尾工作。上下文重置可以解决这两个问题：完全清空上下文窗口并启动一个新的智能体，同时通过结构化交接携带前一个智能体的状态和后续步骤。

这不同于压缩。压缩会在原地摘要对话早期部分，让同一个智能体基于缩短后的历史继续工作。压缩保留连续性，但不会给智能体一块干净画布，这意味着上下文焦虑仍可能存在。重置提供干净画布，代价是交接产物必须包含足够状态，让下一个智能体顺利接手。在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑非常明显，仅靠压缩不足以获得强长任务表现，因此上下文重置成为运行框架设计的关键。这解决了核心问题，但也为每次运行框架执行增加了编排复杂度、token 开销和延迟。

第二个我们之前没有处理的问题，是自我评估。当被要求评估自己产出的工作时，智能体往往会自信地称赞它，即使在人类观察者看来，质量显然平庸。这个问题在设计这类主观任务上尤其明显，因为没有类似可验证软件测试的二元检查。一个布局是精致还是普通，是一种判断；而智能体在给自己的作品评分时，可靠地偏向正面。

不过，即便在具有可验证结果的任务上，智能体有时仍会表现出糟糕判断，阻碍任务完成。把执行工作的智能体与评判工作的智能体分离，是解决这个问题的强杠杆。仅靠分离本身并不会立刻消除宽松倾向；评估器仍然是 LLM，也倾向于对 LLM 生成输出慷慨。但调优一个独立评估器，使其更怀疑，事实证明比让生成器批判自己的作品更容易。一旦有了外部反馈，生成器就有了可具体迭代的对象。

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

我从前端设计开始实验，因为自我评估问题在这里最明显。在没有任何干预时，Claude 通常会倾向于安全、可预测的布局，这些布局功能上可用，但视觉上乏善可陈。

我构建前端设计运行框架时，有两个洞见塑造了它。第一，虽然美学无法完全归约成分数，个人品味也总会有差异，但可以通过编码设计原则和偏好的评分标准来改善。“这个设计美吗？”很难一致回答，但“它是否遵循我们对优秀设计的原则？”为 Claude 提供了可具体评分的对象。第二，通过将前端生成和前端评分分离，我们可以创建一个反馈循环，推动生成器产出更强结果。

基于这一点，我写了四条评分标准，并在提示词中提供给生成器和评估器智能体：

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

我强调设计质量和原创性，高于工艺和功能性。Claude 默认已经在工艺和功能性上得分不错，因为所需技术能力通常是模型天然具备的。但在设计和原创性上，Claude 经常产出最多只能算平淡的结果。这些标准明确惩罚高度通用的 “AI slop” 模式，并通过更重地加权设计和原创性，推动模型承担更多审美风险。

我用包含详细分数拆解的 few-shot 示例校准评估器。这确保评估器判断与我的偏好一致，并减少迭代之间的分数漂移。

我基于 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 进行版本控制。

评估器： 早期运行框架构建出的应用往往看起来很惊艳，但实际使用时仍有真实 bug。为了捕捉这些问题，评估器使用 Playwright MCP 像用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态。随后，它根据发现的 bug，以及一组仿照前端实验并适配为覆盖产品深度、功能性、视觉设计和代码质量的标准，为每个 sprint 打分。每项标准都有硬阈值，如果任意一项低于阈值，该 sprint 就失败，生成器会获得关于问题所在的详细反馈。

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

通信通过文件完成：一个智能体写一个文件，另一个智能体读取它，并在该文件中回复或写一个新文件，让前一个智能体再读。随后生成器根据达成一致的 contract 构建，然后把工作交给 QA。这让工作忠于规格，同时避免过早过度指定实现。

运行该运行框架

对于这个运行框架的第一个版本，我使用 Claude Opus 4.5，并用同样的用户提示分别运行完整运行框架和单智能体系统进行比较。我使用 Opus 4.5，因为这是我开始这些实验时我们最好的编码模型。

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

Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.

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

运行框架	时长	成本
Solo	20 min	$9
Full harness	6 hr	$200

运行框架成本高出 20 倍以上，但输出质量差异立刻显现。

我预期的是一个界面，其中我可以构造关卡及其组成部分（sprite、entity、tile layout），然后点击 play 来实际游玩该关卡。我先打开 solo 运行的输出，初始应用似乎符合这些预期。

然而，随着我点击探索，问题开始出现。布局浪费空间，固定高度面板让大部分视口空着。工作流僵硬。尝试填充关卡时，它提示我先创建 sprites 和 entities，但 UI 中没有任何东西引导我进入这个顺序。更重要的是，实际游戏坏了。我的 entities 出现在屏幕上，但没有任何东西响应输入。深入代码后发现，entity 定义和游戏运行时之间的连接断了，界面上没有任何地方提示问题在哪里。

打开屏幕

Sprite 编辑器

游戏游玩

打开 solo 运行框架创建的应用时的初始屏幕。

在 solo 运行框架制作的 sprite 编辑器中创建 sprite

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

评估完 solo 运行后，我把注意力转向运行框架结果。这次运行从同一个一句话提示开始，但规划器步骤将该提示扩展为一个跨十个 sprint 的 16 功能规格。它远超 solo 运行尝试的范围。除了核心编辑器和游玩模式之外，规格还要求 sprite 动画系统、行为模板、音效和音乐、AI 辅助 sprite 生成器和关卡设计器，以及带可分享链接的游戏导出。我给规划器访问我们的前端设计 skill 的权限，它读取该 skill，并用它为应用创建视觉设计语言，作为规格的一部分。对于每个 sprint，生成器和评估器会协商 contract，定义该 sprint 的具体实现细节，以及将被测试以验证完成的可测试行为。

这个应用立刻显示出比 solo 运行更高的精致度和平滑度。canvas 使用完整视口，面板尺寸合理，界面有一致的视觉身份，并遵循规格中的设计方向。solo 运行中看到的一些笨拙之处仍然存在：工作流仍然没有清楚说明应先构建 sprites 和 entities 再尝试填充关卡，我不得不通过摸索弄清楚。这更像是基础模型产品直觉上的缺口，而不是该运行框架设计要解决的问题，不过它确实指出了一个可以在运行框架内部通过针对性迭代进一步提升输出质量的位置。

随着我浏览这些编辑器，新运行相对于 solo 的优势更加明显。sprite 编辑器更丰富、功能更完整，有更干净的工具面板、更好的颜色选择器，以及更可用的缩放控件。

由于我要求规划器把 AI 功能编织进规格中，该应用还自带 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加快了工作流。

打开屏幕

Sprite 编辑器

AI 游戏设计

AI 游戏设计

游戏游玩

初始屏幕：在完整运行框架构建的应用中创建新游戏

sprite 编辑器感觉更干净、更容易使用

使用内置 AI 功能生成关卡

使用内置 AI 功能生成关卡

游玩我生成的游戏

最大的差异在游玩模式。我确实能够移动 entity 并游玩游戏。物理系统有一些粗糙边缘，我的角色跳到平台上后却与平台重叠，这在直觉上不对，但核心功能可以工作，而 solo 运行没有做到。稍微移动之后，我确实遇到了一些 AI 关卡构建的限制。有一堵大墙我无法跳过去，因此被卡住了。这表明运行框架还可以处理一些常识改进和边界情况，以进一步打磨应用。

阅读日志时，很明显评估器让实现保持在规格轨道上。每个 sprint 中，它都会逐项检查 sprint contract 的测试标准，并通过 Playwright 操作运行中的应用，对任何偏离预期行为的内容提交 bug。contract 非常细粒度，仅 Sprint 3 就有 27 条覆盖关卡编辑器的标准，评估器的发现足够具体，无需额外调查即可采取行动。下表展示了评估器识别出的一些问题示例：

Contract 标准	评估器发现
Rectangle fill tool allows click-drag to fill a rectangular area with selected tile	FAIL — 工具只在拖拽起点/终点放置 tiles，而不是填充区域。fillRectangle 函数存在，但在 mouseUp 时没有正确触发。
User can select and delete placed entity spawn points	FAIL — LevelEditor.tsx:892 的 Delete key handler 要求同时设置 selection 和 selectedEntityId，但点击 entity 只会设置 selectedEntityId。条件应为 selection || (selectedEntityId && activeLayer === 'entity')。
User can reorder animation frames via API	FAIL — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 'reorder' 匹配为 frame_id integer，并返回 422："unable to parse string as an integer."

让评估器达到这个水平花了不少功夫。开箱即用时，Claude 是一个糟糕的 QA 智能体。在早期运行中，我看到它识别出真实问题，然后说服自己认为它们不是什么大事，并仍然批准工作。它也倾向于浅层测试，而不是探测边界情况，因此更细微的 bug 常常漏掉。调优循环是阅读评估器日志，找出其判断与我不一致的例子，然后更新 QA 提示来解决这些问题。这个开发循环进行了几轮后，评估器才以我认为合理的方式评分。即便如此，运行框架输出仍显示出模型 QA 能力的限制：小布局问题、某些地方感觉不直观的交互，以及评估器没有彻底测试到的更深层嵌套功能中的未发现 bug。显然，进一步调优仍有更多验证提升空间。但相比 solo 运行中应用核心功能根本无法工作，提升非常明显。

迭代运行框架

第一组运行框架结果令人鼓舞，但它也庞大、缓慢且昂贵。合理的下一步，是寻找在不降低表现的情况下简化运行框架的方法。这一部分来自常识，一部分来自更一般的原则：运行框架中的每个组件都编码了一个关于模型无法自行完成什么的假设，而这些假设值得压力测试，因为它们可能不正确，也因为随着模型改进，它们很快会过时。我们的博客文章《Building Effective Agents》将底层思想表述为“找到可行的最简单方案，只在需要时增加复杂性”，这也是维护智能体运行框架的人会反复遇到的模式。

在第一次简化尝试中，我大幅削减运行框架，并尝试了一些有创意的新想法，但没能复现原始表现。也因此，很难判断运行框架设计中哪些部分是真正承重的，以及以何种方式承重。基于这次经验，我转向更有方法的做法：一次移除一个组件，并审查它对最终结果的影响。

在我进行这些迭代周期时，我们也发布了 Opus 4.6，这进一步促使我降低运行框架复杂度。有充分理由预期 4.6 比 4.5 需要更少脚手架。来自我们的发布博客：“[Opus 4.6] plans more carefully, sustains agentic tasks for longer, can operate more reliably in larger codebases, and has better code review and debugging skills to catch its own mistakes.” 它在长上下文检索上也显著改进。这些都是该运行框架原本被设计来补充的能力。

移除 sprint 构造

我从完全移除 sprint 构造开始。sprint 结构曾帮助把工作拆解成块，让模型能连贯处理。考虑到 Opus 4.6 的改进，有充分理由相信模型可以原生处理工作，而不需要这种分解。

我保留了规划器和评估器，因为二者仍然提供明显价值。没有规划器时，生成器会低估范围：给定原始提示后，它会在没有先规划工作的情况下开始构建，最终创建出比规划器产物功能更少的应用。

移除 sprint 构造后，我把评估器改为在运行结束时单次通过，而不是每个 sprint 评分。由于模型能力更强，这改变了评估器在某些运行中的承重程度，其有用性取决于任务相对于模型独立可靠完成能力的位置。在 4.5 上，这条边界很近：我们的构建处在生成器 solo 能做好事情的边缘，评估器能在整个构建中捕捉有意义的问题。在 4.6 上，模型原始能力提高，因此边界向外移动。过去需要评估器检查才能连贯实现的任务，如今往往已在生成器能自行处理的范围内；对于边界以内的任务，评估器变成不必要开销。但对于仍处在生成器能力边缘的构建部分，评估器继续带来真实提升。

实际含义是，是否使用评估器并不是固定的是/否决策。当任务超出当前模型可可靠 solo 完成的范围时，它值得付出成本。

在结构简化的同时，我还加入了提示，以改善运行框架如何把 AI 功能构建进每个应用，具体而言，是让生成器构建一个合适的智能体，通过工具驱动应用自身功能。这需要真实迭代，因为相关知识足够新，Claude 训练数据覆盖较薄。但经过足够调优后，生成器能够正确构建智能体。

更新后运行框架的结果

为了测试更新后的运行框架，我使用以下提示生成一个 Digital Audio Workstation（DAW），也就是用于作曲、录音和混音的音乐制作程序：

Build a fully featured DAW in the browser using the Web Audio API.

这次运行仍然很长且昂贵，约 4 小时，token 成本为 124 美元。

大部分时间用于 builder，它在没有 Opus 4.5 所需 sprint 分解的情况下，连贯运行了两个多小时。

智能体与阶段	时长	成本
Planner	4.7 min	$0.46
Build (Round 1)	2 hr 7 min	$71.08
QA (Round 1)	8.8 min	$3.24
Build (Round 2)	1 hr 2 min	$36.89
QA (Round 2)	6.8 min	$3.09
Build (Round 3)	10.9 min	$5.88
QA (Round 3)	9.6 min	$4.06
Total V2 Harness	3 hr 50 min	$124.70

和此前的运行框架一样，规划器将一行提示扩展为完整规格。从日志中，我可以看到生成器模型很好地规划了应用和智能体设计，把智能体连接起来，并在交给 QA 前进行了测试。

话虽如此，QA 智能体仍然捕捉到了真实缺口。在第一轮反馈中，它指出：

This is a strong app with excellent design fidelity, solid AI agent, and good backend. The main failure point is Feature Completeness — while the app looks impressive and the AI integration works well, several core DAW features are display-only without interactive depth: clips can't be dragged/moved on the timeline, there are no instrument UI panels (synth knobs, drum pads), and no visual effect editors (EQ curves, compressor meters). These aren't edge cases — they're the core interactions that make a DAW usable, and the spec explicitly calls for them.

在第二轮反馈中，它再次捕捉到几个功能缺口：

Remaining gaps:

• Audio recording is still stub-only (button toggles but no mic capture)

• Clip resize by edge drag and clip split not implemented

• Effect visualizations are numeric sliders, not graphical (no EQ curve)

生成器在无人看管时仍然容易遗漏细节或写出 stub 功能，而 QA 仍然能在捕捉这些最后一公里问题并让生成器修复方面提供价值。

基于提示，我预期的是一个程序：我可以创建旋律、和声和鼓点，把它们编排成歌曲，并在过程中获得集成智能体帮助。下面的视频展示了结果。

这个应用远称不上专业音乐制作程序，智能体的作曲能力显然也还有很大提升空间。此外，Claude 实际上听不到声音，这让 QA 反馈循环在音乐品味方面效果较弱。

但最终应用具备一个功能性音乐制作程序的所有核心部分：可在浏览器中运行的编排视图、混音器和播放控制。不止如此，我还能够完全通过提示拼出一小段歌曲片段：智能体设置速度和调性，铺设旋律，构建鼓轨，调整混音电平，并添加混响。歌曲创作的核心原语都存在，智能体也能自主驱动它们，使用工具端到端创建一个简单作品。你可以说它还不够音准完美，但已经在路上了。

接下来是什么

随着模型继续改进，我们大致可以预期它们能够工作更久，并处理更复杂的任务。在某些情况下，这意味着围绕模型的 scaffold 随时间会变得不那么重要，开发者可以等待下一代模型，看某些问题自行解决。另一方面，模型越强，就越有空间开发能够完成超出模型基线能力复杂任务的运行框架。

考虑到这一点，这项工作中有几条经验值得带走。针对你正在构建的模型进行实验、阅读它在真实问题上的 trace，并调优其表现以达成期望结果，始终是好的实践。在处理更复杂任务时，有时可以通过拆解任务并对问题各方面应用专门智能体来获得提升空间。当新模型发布时，通常也应重新审视运行框架，移除不再对表现承重的部分，并添加新的部分，以实现此前不可能的更强能力。

这项工作让我确信，随着模型改进，有趣运行框架组合的空间不会缩小。相反，它会移动，而 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 是一个基于 Web 的创意工作室，用于设计和构建 2D 复古风格电子游戏。它将经典 8-bit 和 16-bit 游戏美学的怀旧魅力，与现代、直观的编辑工具结合起来，让从业余创作者到独立开发者的任何人都能无需编写传统代码，把游戏想法变成现实。

该平台提供四个集成创意模块：用于设计游戏世界的基于 tile 的关卡编辑器、用于制作视觉资产的像素艺术 Sprite 编辑器、用于定义游戏逻辑的可视化 Entity Behavior 系统，以及用于实时游戏测试的即时 Playable Test Mode。通过贯穿其中的 AI 辅助（由 Claude 提供支持），RetroForge 加速创意流程，帮助用户通过自然语言交互生成 sprites、设计关卡并配置行为。

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

功能
1. 项目仪表盘与管理
Project Dashboard 是 RetroForge 中所有创意工作的主页。用户需要一种清晰、有组织的方式来管理游戏项目：创建新项目、回到进行中的作品，并一眼理解每个项目包含什么。

用户故事：作为用户，我希望：

- 创建带名称和描述的新游戏项目，这样我可以开始设计游戏
- 看到所有现有项目以视觉卡片形式展示，显示项目名称、最后修改日期和缩略预览，这样我可以快速找到并继续工作
- 打开任意项目进入完整游戏编辑器工作区，这样我可以处理自己的游戏
- 删除不再需要的项目，并通过确认对话框防止误操作，这样我可以保持工作区有序
- 复制现有项目作为新游戏起点，这样我可以复用此前工作

项目数据模型：每个项目包含：

项目元数据（名称、描述、创建/修改时间戳）
画布设置（分辨率：例如 256x224、320x240 或 160x144）
Tile 尺寸配置（8x8、16x16 或 32x32 像素）
调色板选择
所有关联的 sprites、tilesets、levels 和 entity definitions

...