面向长期应用开发的支架设计

Anthropic 工程团队

发布于 2026 年 3 月 24 日

在代理编码的前沿，harness 设计是性能的关键。以下是我们如何在前端设计和长时间运行的自主软件工程中进一步推动 Claude 的方法。

作者：Prithvi Rajasekaran，来自我们的 Labs 团队。

在过去的几个月里，我一直在研究两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在无需人工干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计技能和长时间运行编码 Agent harness上的努力，我和同事们通过提示工程和 harness 设计将 Claude 的性能大幅提升到基线之上——但两种方法最终都遇到了瓶颈。

为了突破，我寻找了在两个完全不同领域都行之有效的新颖 AI 工程方法：一个以主观品味为特征，另一个以可验证的正确性和可用性为特征。受生成对抗网络（GAN）的启发，我设计了一个包含生成器和评估器代理的多代理结构。构建一个能够可靠（且有品味）地对输出进行评分的评估器，意味着首先要开发一套标准，将“这个设计好吗？”这样的主观判断转化为具体的、可评分的术语。

接着，我将这些技术应用于长时间运行的自主编码，并从我们之前的 harness 工作中继承了两个经验：将构建过程分解为易于处理的小块，以及使用结构化工件在会话之间传递上下文。最终结果是一个三代理架构——规划器、生成器和评估器——能够在长达数小时的自主编码会话中生成丰富的全栈应用程序。

为什么简单实现无法胜任

我们之前已经证明，harness 设计对长时间运行代理编码的有效性有显著影响。在早期的一项实验中，我们使用一个初始化代理将产品需求分解为任务列表，然后使用一个编码 Agent 逐个功能地实现这些任务，并在会话之间传递工件以携带上下文。更广泛的开发者社区也得出了类似的见解，例如“ Ralph Wiggum”方法使用 Hook 或脚本来让代理保持在连续的迭代周期中。

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

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

这与压缩不同，压缩会将对话的早期部分就地总结，使得同一个代理可以在缩短的历史记录上继续运行。虽然压缩保持了连续性，但它没有给代理一个全新的开始，这意味着上下文焦虑可能仍然存在。重置提供了一个全新的开始，代价是交接工件必须包含足够的状态信息，以便下一个代理能够顺利地继续工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出强烈的上下文焦虑，仅靠压缩不足以支持强大的长时间任务性能，因此上下文重置成为 harness 设计的关键。这解决了核心问题，但增加了编排复杂性、Token 开销和每次 harness 运行的延迟。

第二个问题是我们之前没有解决过的：自我评估。当被要求评估自己产生的工作时，代理往往会自信地赞美这些工作——即使从人类观察者的角度来看，质量明显平庸。这个问题在设计等主观任务上尤为突出，因为这类任务没有像可验证软件测试那样的二元检查。一个布局是精致还是平庸，是一个判断问题，而代理在评估自己的工作时总是倾向于给出正面评价。

然而，即使在那些有可验证结果的任务上，代理有时也会表现出糟糕的判断力，妨碍其在完成任务过程中的表现。将执行工作的代理与判断工作的代理分离开来，被证明是解决这个问题的有力手段。这种分离本身并不能立即消除那种宽松倾向；评估器仍然是一个倾向于对 LLM 生成的内容持宽容态度的 LLM。但将独立的评估器调整为怀疑态度，远比让生成器批判自己的工作要容易处理得多，而且一旦有了这种外部反馈，生成器就有了具体可迭代的目标。

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

我从前端设计开始试验，因为自我评估问题在那里最为明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局，这些布局在技术上功能齐全，但在视觉上平淡无奇。

两个见解启发了我为前端设计构建的 harness。第一，虽然美学不能完全简化为一个分数——而且个人品味总会有所不同——但可以通过包含设计原则和偏好的评分标准来改进。“这个设计美吗？” 很难一致地回答，但 “这遵循了我们良好设计的原则吗？” 为 Claude 提供了具体的评分依据。第二，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，推动生成器产生更强的输出。

考虑到这一点，我编写了四个评分标准，并将其提供给了生成器和评估器代理的提示词中：

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

我着重强调了设计质量和原创性，相对弱化了工艺和功能性。Claude 在工艺和功能性方面默认已经得分不错，因为所需的技术能力通常是模型本身自然具备的。但在设计和原创性方面，Claude 经常产生充其量只能是平淡的输出。这些标准明确惩罚了高度通用的“AI 垃圾”模式，并且通过更重视设计和原创性，促使模型在美学上承担更多风险。

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

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

在多次运行中，评估器的评估在迭代中有所改善，然后趋于平稳，但仍留有提升空间。一些生成是逐步改进的。另一些则在迭代之间发生了急剧的美学转向。

评分标准的措辞以我未曾完全预料到的方式引导了生成器。加入诸如“最好的设计是博物馆级的”之类的短语，将设计推向了特定的视觉趋同，表明与标准相关的提示词直接塑造了输出的特性。

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

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

扩展到全栈编码

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

架构

在我们早期的长时间运行 harness 中，我们通过一个初始化代理、一个一次处理一个功能的编码 Agent 以及会话之间的上下文重置，解决了连贯的多会话编码问题。上下文重置是一个关键的解锁点：该 harness 使用了 Sonnet 4.5，它表现出前面提到的“上下文焦虑”倾向。创建一个在上下文重置之间也能良好运行的 harness 是让模型保持在任务上的关键。Opus 4.5 在很大程度上自行消除了这种行为，因此我能够完全从这个 harness 中移除上下文重置。代理们在整个构建过程中作为一个连续会话运行，Claude Agent SDK 的自动压缩功能处理了沿途的上下文增长。

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

规划器： 我们之前的长时间运行 harness 要求用户预先提供详细的规范说明。我想将这一步自动化，因此创建了一个规划器代理，它接收一个简单的 1-4 句提示，并将其扩展为完整的产品规范。我提示它在范围上要雄心勃勃，并专注于产品上下文和高层次的技术设计，而不是详细的技术实现。这种强调是出于担心：如果规划器试图预先指定细粒度的技术细节却出了错，那么规范中的错误会级联到下游的实现中。更明智的做法似乎是约束代理要生产哪些交付物，让它们在工作中自行找出路径。我还要求规划器寻找将 AI 功能融入产品规范的机会。（参见底部附录中的示例。）

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

评估器： 早期 harness 生成的应用程序看起来通常令人印象深刻，但当你实际尝试使用时，仍然存在真正的错误。为了捕捉这些错误，评估器使用 Playwright MCP 像用户一样点击操作正在运行的应用程序，测试 UI 功能、API 端点和数据库状态。然后它根据发现的错误以及一套基于前端实验标准（在此针对产品深度、功能性、视觉设计和代码质量进行了调整）的评分标准，对每个冲刺进行评分。每个标准都有一个硬阈值，如果任何一个低于该阈值，冲刺失败，并且生成器会收到关于出现问题的详细反馈。

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

通信通过文件处理：一个代理写入文件，另一个代理读取该文件并要么在该文件中回复，要么生成一个新文件供前一个代理读取。然后生成器根据商定的合同进行构建，然后将工作移交给 QA。这使工作忠实于规范，同时又不会过早地过度指定实现。

运行 Harness

对于这个 harness 的第一个版本，我使用了 Claude Opus 4.5，将用户提示同时运行在完整 harness 和单代理系统上以进行比较。我使用 Opus 4.5 是因为它是我开始这些实验时我们最好的编码模型。

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

创建一个 2D 复古游戏制作工具，功能包括关卡编辑器、精灵编辑器、实体行为以及可玩的测试模式。

下表显示了 harness 类型、运行时长以及总成本。

Harness 的成本是 20 多倍，但输出质量的差异是立竿见影的。

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

然而，当我点击操作时，问题开始浮现。布局浪费了空间，固定高度的面板使得大部分视口为空。工作流程僵硬。尝试填充关卡会提示我先创建精灵和实体，但 UI 中没有指引我进行该顺序的内容。更重要的是，实际的游戏是坏的。我的实体出现在屏幕上，但没有对输入做出响应。深入代码发现，实体定义与游戏运行时之间的连接断了，而且表面上没有任何迹象表明问题出在哪里。

初始界面

精灵编辑器

游戏运行中

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

该应用立即显示出比单代理运行更高的精致度和流畅性。画布使用了整个视口，面板大小合理，界面具有一致的视觉标识，遵循了规范中的设计方向。我在单代理运行中看到的一些笨拙之处仍然存在——工作流程仍然没有明确说明应该在尝试填充关卡之前构建精灵和实体，我不得不通过四处摸索来弄清楚。这更像是基础模型在产品直觉上的一个差距，而不是 harness 设计要解决的问题，尽管它确实表明在 harness 内部进行有针对性的迭代可能有助于进一步提高输出质量。

在编辑器中工作时，新运行相对于单代理的优势变得更加明显。精灵编辑器更丰富、功能更全面，拥有更干净的工具面板、更好的颜色选择器以及更可用的缩放控件。

因为我要求规划器将 AI 功能编织到其规范中，所以该应用还带有一个内置的 Claude 集成，让我可以通过提示来生成游戏的不同部分。这大大加快了工作流程。

初始界面：创建新游戏

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

使用内置 AI 功能生成关卡

使用内置 AI 功能生成关卡

运行我生成的游戏

最大的区别在于播放模式。我实际上能够移动我的实体并运行游戏。物理效果有一些粗糙的地方——我的角色跳上一个平台，但最后与平台重叠了，这在直觉上感觉不对——但核心功能是有效的，这是单代理运行未能做到的。在移动了一小会儿之后，我确实遇到了 AI 游戏关卡构建的一些限制。有一堵高墙我无法跳过，所以我被困住了。这表明有一些常识性的改进和边界情况是 harness 可以处理以进一步优化应用的。

阅读日志时，很明显评估器使实现与规范保持一致。每个冲刺，它都会遍历冲刺合同的测试标准，并通过 Playwright 操作用户正在运行的应用程序，对任何与预期行为不符的地方提交错误报告。合同是细粒度的——仅冲刺 3 就有 27 个标准涵盖了关卡编辑器——而评估器的发现足够具体，无需额外调查即可采取行动。下表显示了我们的评估器识别出的几个问题示例：

让评估器达到这个水平需要付出努力。开箱即用时，Claude 是一个糟糕的 QA 代理。在早期运行中，我看到它识别出了合理的问题，然后说服自己这些不是大问题，最终仍然批准了工作。它倾向于进行表面测试，而不是深入探查边界情况，因此更微妙的错误经常漏网。调优循环是：阅读评估器的日志，找到其判断与我个人判断存在分歧的例子，然后更新 QA 的提示以解决这些问题。经过几轮这样的开发循环后，评估器才以我认为合理的方式进行评分。即便如此，harness 的输出也显示了模型 QA 能力的局限：小的布局问题、某些地方感觉不直观的交互，以及在更深层嵌套功能中未被评估器充分测试的未被发现的错误。显然，通过进一步调优，还有更多验证空间可以挖掘。但与单代理运行（其中应用的核心功能根本无法工作）相比，提升是显而易见的。

对 Harness 进行迭代

第一组 harness 结果是令人鼓舞的，但也显得庞大、缓慢且昂贵。合乎逻辑的下一步是找到简化 harness 而不降低其性能的方法。这部分是常识，部分也是一个更普遍原则的体现：harness 中的每个组件都编码了一个关于模型自身无法做到什么的假设，而这些假设值得进行压力测试，既因为它们可能是错误的，也因为随着模型的改进，它们可能会很快过时。我们的博客文章构建有效代理将基本思想表述为 “找到尽可能最简单的解决方案，只有在需要时才增加复杂度” ，这是任何维护代理 harness 的人都会反复看到的模式。

在我第一次尝试简化时，我大幅削减了 harness，并尝试了一些创造性的新想法，但我无法复制原始 harness 的性能。而且，很难判断 harness 设计的哪些部分实际上是关键支撑，以及是以何种方式支撑的。基于这次经验，我转向了一种更系统的方法，一次移除一个组件，并审查它对最终结果的影响。

在我经历这些迭代周期时，我们还发布了 Opus 4.6，这进一步激励我们降低 harness 的复杂性。有充分的理由预期 4.6 需要的脚手架比 4.5 少。根据我们的发布博客：“[Opus 4.6] 能更仔细地规划，更长时间地维持代理任务，能在更大的代码库中更可靠地运作，并且拥有更好的代码审查和调试技能来捕捉自己的错误。” 它在长上下文检索方面也有显著改进。这些都是 harness 原本旨在补充的能力。

移除冲刺结构

我首先完全移除了冲刺结构。冲刺结构有助于将工作分解成块，以便模型连贯地工作。鉴于 Opus 4.6 的改进，有充分的理由相信该模型可以在没有这种分解的情况下原生地处理这个任务。

我保留了规划器和评估器，因为每一个都继续增加着明显的价值。没有规划器，生成器的范围会不足：给定原始提示，它会直接开始构建，而不先对其工作进行规范化，结果创建的应用功能不如规划器所做的丰富。

随着冲刺结构的移除，我将评估器移到运行结束时进行一次性的总体评估，而不是在每个冲刺后进行评分。由于模型能力更强，这改变了评估器在某些运行中关键支撑作用的程度，其有用性取决于任务相对于模型自身可靠完成的能力所处的位置。在 4.5 上，这个边界很近：我们的构建处于生成器单独能做好工作的边缘，评估器在整个构建中捕捉到了有意义的问题。在 4.6 上，模型的原始能力提高了，所以边界向外移动了。以前需要评估器检查才能连贯实现的任务，现在通常处于生成器自己就能很好处理的范围内，而对于这个范围内的任务，评估器就成了不必要的开销。但对于构建中仍然处于生成器能力边缘的部分，评估器继续提供着实际的提升。

实际影响是，评估器不是一成不变的“是或否”的决定。只有当任务超出了当前模型单独能可靠完成的范围时，它才值得付出成本。

除了结构简化之外，我还添加了提示词，以改进 harness 如何将 AI 功能构建到每个应用中，特别是让生成器构建一个适当的 Agent，该 Agent 可以通过工具驱动应用自身的功能。这需要真正的迭代，因为相关知识是最近才出现的，Claude 的训练数据覆盖得不够深入。但经过足够的调优，生成器能够正确地构建 Agent。

更新后 Harness 的结果

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

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

这次运行仍然漫长且昂贵，大约耗时 4 小时，Token 成本为 124 美元。

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

与之前的 harness 一样，规划器将一行提示扩展成了完整的规范。从日志中，我可以看到生成器模型很好地完成了应用规划和 Agent 设计、连接 Agent 并在移交给 QA 之前进行测试的工作。

话虽如此，QA 代理仍然抓住了真正的差距。在第一轮反馈中，它指出：

这是一个强大的应用，具有出色的设计保真度、可靠的 AI Agent 和良好的后端。主要的失败点是功能完整性——虽然应用看起来令人印象深刻，AI 集成也运行良好，但有多个核心 DAW 功能仅作为显示存在，没有交互深度：片段无法在时间线上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有视觉效果编辑器（EQ 曲线、压缩器仪表）。这些不是边界情况——它们是使 DAW 可用的核心交互，而规范明确要求了它们。

在第二轮反馈中，它再次发现了几个功能差距：

剩余差距：

• 音频录制仍然是存根（按钮可切换，但没有麦克风捕获）

• 未实现通过边缘拖动调整片段大小和片段切片

• 效果可视化是数字滑块，而不是图形化（无 EQ 曲线）

生成器在自行工作时仍然容易遗漏细节或将功能做成存根，而 QA 仍然在捕捉这些最后阶段的问题以供生成器修复方面增加了价值。

根据提示，我期望的是一个程序，我可以在其中创建旋律、和声和鼓模式，将它们编排成一首歌，并在途中获得一个集成的 Agent 的帮助。下面的视频展示了结果。

该应用远非专业的音乐制作程序，而且 Agent 的歌曲创作能力显然还有很多需要改进的地方。此外，Claude 实际上无法听到声音，这使得 QA 反馈循环在音乐品味方面效果较差。

但最终的应用具备了功能性音乐制作程序的全部核心部件：在浏览器中运行的可工作的编排视图、调音台和传输控制。除此之外，我能够完全通过提示组合出一个简短的歌曲片段：Agent 设置了速度和调性，铺设了旋律，构建了鼓轨，调整了调音台电平，并添加了混响。歌曲创作的核心原语已经存在，并且 Agent 能够自主驱动它们，使用工具从端到端创建一个简单的作品。你可以说它还没有达到完美的音准——但它正在接近。

下一步是什么

随着模型不断改进，我们大致可以预期它们能够工作更长时间，并处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随着时间的推移变得不那么重要，开发者可以等待下一个模型，看到某些问题自行解决。另一方面，模型越好，开发 harness 的空间就越大，这些 harness 可以实现超出模型基线能力的复杂任务。

考虑到这一点，这项工作中有几个经验值得借鉴。始终与你正在构建所针对的模型进行实验，阅读其在现实问题上的轨迹，并调整其性能以达到你的期望结果，这是一个好的实践。 在处理更复杂任务时，有时可以通过分解任务并将专门的代理应用于问题的每个方面来获得提升空间。当新模型推出时，通常最好是重新审视 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 协助撰写本文。

附录

规划器代理生成的计划示例。

RetroForge - 2D 复古游戏制作工具

概述
RetroForge 是一个基于网页的创意工作室，用于设计和构建 2D 复古风格视频游戏。它结合了经典 8 位和 16 位游戏美学的怀旧魅力与现代直观的编辑工具——使从业余创作者到独立开发者都能将他们的游戏想法变为现实，而无需编写传统代码。

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

RetroForge 的目标用户是热爱复古游戏美学但希望拥有现代便利性的创作者。无论是重现他们童年时代的平台游戏、RPG 或动作游戏，还是在复古限制内创造全新的体验，用户都可以快速进行原型设计，可视化地迭代，并与他人分享他们的创作。

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

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

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

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

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

...

• 原文链接： anthropic.com/engineerin...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～