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