原文：Harness design for long-running application development
作者：Prithvi Rajasekaran（Anthropic Labs 团队成员）
发布日期：2026年3月24日
Harness 设计是智能体编码前沿性能的关键。以下是我们如何推动 Claude 在前端设计和长时自主软件工程方面取得突破的方法。
在过去几个月里，我一直在研究两个相互关联的问题：如何让 Claude 产出高质量的前端设计，以及如何让它在没有人工干预的情况下构建完整的应用程序。这项工作源于我们之前在前端设计技能和长时运行编码智能体 harness上的努力，我和我的同事们通过提示工程和 harness 设计显著提升了 Claude 的性能——但两者最终都遇到了瓶颈。
为了突破瓶颈，我寻找了在两个截然不同的领域都能适用的新型 AI 工程方法：一个由主观品味定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GANs）的启发，我设计了一个包含生成器和评估器智能体的多智能体结构。构建一个能够可靠且有品味地评分输出的评估器，意味着首先要开发一套标准，将”这个设计好吗？“这样的主观判断转化为具体、可评分的术语。
随后，我将这些技术应用于长时自主编码，借鉴了之前 harness 工作的两个经验：将构建任务分解为可处理的小块，以及使用结构化产物在不同会话之间传递上下文。最终形成了一个三智能体架构——规划器、生成器和评估器——能够在数小时的自主编码会话中产出丰富的全栈应用程序。
为什么朴素实现会失败
我们之前已经证明，harness 设计对长时运行智能体编码的有效性有重大影响。在早期的实验中，我们使用初始化智能体将产品规格分解为任务列表，然后由编码智能体逐个实现功能，再通过产物传递上下文以跨会话延续工作。更广泛的开发者社区也得出了类似的见解，比如使用”Ralph Wiggum“方法，通过钩子或脚本让智能体保持持续迭代循环。
但有些问题依然存在。对于更复杂的任务，智能体仍然倾向于随着时间的推移而偏离轨道。在分解这个问题时，我们观察到智能体执行此类任务时的两种常见失败模式。
首先是随着上下文窗口填满，模型倾向于在长任务上失去连贯性（参见我们关于上下文工程的文章）。一些模型还表现出”上下文焦虑”，即当它们接近自认为的上下文限制时，会提前开始收尾工作。上下文重置——完全清空上下文窗口并启动一个新的智能体，结合结构化的交接来传递前一个智能体的状态和下一步任务——可以解决这两个问题。
这与压缩不同，压缩是将对话的早期部分就地总结，以便同一个智能体可以在缩短的历史记录上继续工作。虽然压缩保持了连续性，但它没有给智能体一个干净的起点，这意味着上下文焦虑仍然可能存在。重置提供了一个干净的起点，代价是交接产物必须包含足够的状态，让下一个智能体能够干净地接手工作。在我们早期的测试中，我们发现 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 次迭代，每次迭代通常推动生成器朝着更独特的方向发展，以响应评估器的评论。由于评估器是主动导航页面，而不是对静态截图评分，每个周期都需要实际的挂钟时间。完整运行可能长达四个小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好，则完善当前方向；如果方法不起作用，则转向完全不同的美学。
在多次运行中，评估器的评估在达到平稳之前随着迭代而改善，仍有改进空间。一些生成是渐进式完善的。另一些在迭代之间发生了剧烈的美学转变。
标准的措辞以我没有完全预料到的方式引导了生成器。包含诸如”最好的设计具有博物馆品质”之类的短语，推动设计朝着特定的视觉趋同方向发展，这表明与标准相关的提示直接塑造了输出的特征。
虽然分数通常随着迭代而提高，但模式并不总是干净的线性关系。后期的实现往往整体更好，但我经常看到我更喜欢中间迭代而不是最后一个的情况。实现复杂性也往往随着轮次增加，生成器为了响应评估器的反馈而寻求更雄心勃勃的解决方案。即使在第一次迭代中，输出也比完全没有提示的基线明显更好，这表明标准和相关语言本身在评估器反馈导致进一步改进之前，就将模型从通用默认值中引导出来。
在一个值得注意的例子中，我提示模型为一个荷兰艺术博物馆创建一个网站。到第九次迭代时，它已经为一个虚构的博物馆生成了一个干净的深色主题落地页。页面在视觉上很精致，但大致符合我的预期。然后，在第十个周期，它完全放弃了这种方法，将网站重新想象为一种空间体验：一个带有 CSS 透视渲染的棋盘地板的 3D 房间，艺术品以自由形式的位置挂在墙上，以及基于门的画廊房间之间的导航，而不是滚动或点击。这是我以前从未在单次生成中见过的那种创造性飞跃。
扩展到全栈编码
掌握了这些发现后，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和 QA 扮演着与设计评估器相同的结构角色。
架构
在我们早期的长时运行 harness中，我们通过初始化智能体、一次处理一个功能的编码智能体，以及会话之间的上下文重置，解决了连贯的多会话编码问题。上下文重置是一个关键的解锁：harness 使用了 Sonnet 4.5，它表现出前面提到的”上下文焦虑”倾向。创建一个在上下文重置中表现良好的 harness 是让模型保持任务状态的关键。Opus 4.5 基本上自己消除了这种行为，所以我能够完全从这个 harness 中删除上下文重置。智能体在整个构建过程中作为一个连续会话运行，Claude Agent SDK 的自动压缩处理沿途的上下文增长。
对于这项工作，我在原始 harness 的基础上构建了一个三智能体系统，每个智能体解决我在之前运行中观察到的特定差距。系统包含以下智能体角色：
规划器：我们之前的长时运行 harness 要求用户预先提供详细的规格。我想自动化这一步，所以创建了一个规划器智能体，它接收一个简单的 1-4 句提示，并将其扩展为完整的产品规格。我提示它在范围上要雄心勃勃，专注于产品上下文和高级技术设计，而不是详细的技术实现。这种强调是因为担心如果规划器试图预先指定细粒度的技术细节并出错，规格中的错误会级联到下游实现。约束智能体要交付的产出，让它们在工作中找出路径，似乎更明智。我还要求规划器在规格中寻找机会编织 AI 功能。（示例见底部的附录。）
生成器：早期 harness 中一次处理一个功能的方法在范围管理方面效果很好。我在这里应用了类似的模型，指示生成器以冲刺方式工作，从规格中逐个挑选功能。每个冲刺使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）技术栈实现应用程序，生成器被指示在每个冲刺结束时自我评估其工作，然后再交接给 QA。它还有 git 进行版本控制。
评估器：早期 harness 的应用程序通常看起来很令人印象深刻，但当你实际尝试使用时仍然有真正的 bug。为了捕捉这些问题，评估器使用 Playwright MCP 像用户一样点击运行中的应用程序，测试 UI 功能、API 端点和数据库状态。然后它根据发现的 bug 和一套以前端实验为模型的标准对每个冲刺进行评分，这里改编为涵盖产品深度、功能性、视觉设计和代码质量。每个标准都有一个硬阈值，如果任何一个低于阈值，冲刺就失败，生成器会得到关于出了什么问题的详细反馈。在每个冲刺之前，生成器和评估器协商一个冲刺合同：在任何代码编写之前就”完成”的样子达成一致。这存在是因为产品规格是有意高层次的，我想要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提议它将构建什么以及如何验证成功，评估器审查该提议以确保生成器在构建正确的东西。两者迭代直到达成一致。
通信通过文件处理：一个智能体写入文件，另一个智能体读取它，并在该文件内响应或用新文件响应，前一个智能体轮流读取。然后生成器根据商定的合同进行构建，再将工作交接给 QA。这使得工作忠实于规格，而不会过早过度指定实现。
运行 harness
对于 harness 的第一个版本，我使用 Claude Opus 4.5，针对完整 harness 和单智能体系统运行用户提示进行比较。我使用 Opus 4.5 是因为这是我开始这些实验时最好的编码模型。
我编写了以下提示来生成一个复古视频游戏制作器：
创建一个具有关卡编辑器、精灵编辑器、实体行为和可玩测试模式等功能的 2D 复古游戏制作器。
下表显示了 harness 类型、运行时长和总成本：
| Harness | Duration | Cost |
|---|---|---|
| Solo | 20 min | $9 |
| Full harness | 6 hr | $200 |
harness 的成本高出 20 多倍，但输出质量的差异立竿见影。
我期望一个界面，可以在其中构建关卡及其组成部分（精灵、实体、瓦片布局），然后点击播放来实际玩关卡。我首先打开单独运行的输出，初始应用程序似乎符合这些预期。
然而，当我点击浏览时，问题开始出现。布局浪费了空间，固定高度的面板让大部分视口空着。工作流程很僵硬。尝试填充关卡提示我首先创建精灵和实体，但 UI 中没有任何东西引导我走向这个顺序。更重要的是，实际游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入代码发现实体定义和游戏运行时之间的连接断了，没有表面迹象表明问题在哪里。
评估完单独运行后，我将注意力转向 harness 运行。这次运行从相同的单句提示开始，但规划器步骤将该提示扩展为分布在十个冲刺中的 16 个功能规格。它远远超出了单独运行尝试的范围。除了核心编辑器和游戏模式外，规格还要求精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成器和关卡设计师，以及带有可分享链接的游戏导出。我让规划器访问我们的前端设计技能，它阅读并用作规格的一部分为应用程序创建视觉设计语言。对于每个冲刺，生成器和评估器协商一个合同，定义冲刺的具体实现细节，以及将测试以验证完成度的可测试行为。
该应用程序立即显示出比单独运行更多的精致和流畅。画布使用了完整的视口，面板大小合理，界面具有一致的视觉识别，符合规格中的设计方向。我在单独运行中看到的一些笨拙仍然存在——工作流程仍然没有明确说明你应该在尝试填充关卡之前先构建精灵和实体，我不得不通过摸索来弄清楚。这读起来像是基础模型产品直觉的差距，而不是 harness 旨在解决的问题，尽管它确实表明 harness 内部有针对性的迭代可以帮助进一步提高输出质量。
在编辑器中工作，新运行相比单独运行的优势变得更加明显。精灵编辑器更丰富、功能更齐全，有更干净的工具调色板、更好的颜色选择器和更可用的缩放控制。
因为我要求规划器在其规格中编织 AI 功能，该应用程序还带有内置的 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加快了工作流程。
最大的差异在游戏模式中。我实际上能够移动我的实体并玩游戏。物理有一些粗糙的边缘——我的角色跳到一个平台上，但最终与它重叠，这在直觉上感觉不对——但核心功能是有效的，而单独运行没有做到这一点。移动了一会儿后，我确实遇到了 AI 游戏关卡构建的一些限制。有一堵大墙我无法跳过去，所以我被困住了。这表明 harness 可以处理一些常识性改进和边缘情况，以进一步完善应用程序。
阅读日志，很明显评估器使实现与规格保持一致。每个冲刺，它都会遍历冲刺合同的测试标准，并通过 Playwright 运行应用程序，针对任何偏离预期行为的问题提交 bug。合同是细粒度的——仅冲刺 3 就有 27 个涵盖关卡编辑器的标准——评估器的发现足够具体，无需额外调查就可以采取行动。下表显示了我们评估器识别的几个问题示例：
| Contract criterion | Evaluator finding |
|---|---|
| Rectangle fill tool allows click-drag to fill a rectangular area with selected tile | FAIL — Tool only places tiles at drag start/end points instead of filling the region. fillRectangle function exists but isn’t triggered properly on mouseUp. |
| User can select and delete placed entity spawn points | FAIL — Delete key handler at LevelEditor.tsx:892 requires both selection and selectedEntityId to be set, but clicking an entity only sets selectedEntityId. Condition should be selection || (selectedEntityId && activeLayer === 'entity'). |
| User can reorder animation frames via API | FAIL — PUT /frames/reorder route defined after /{frame_id} routes. FastAPI matches ‘reorder’ as a frame_id integer and returns 422: “unable to parse string as an integer.” |
让评估器达到这个水平需要下功夫。开箱即用，Claude 是一个糟糕的 QA 智能体。在早期运行中，我看到它识别出合理的问题，然后说服自己决定它们不是什么大问题，无论如何都批准工作。它还倾向于表面测试，而不是探测边缘情况，所以更微妙的 bug 经常溜走。调整循环是阅读评估器的日志，找到其判断与我分歧的例子，并更新 QA 的提示以解决这些问题。经过几轮这样的开发循环，评估器才以我认为合理的方式进行评分。即便如此，harness 输出显示了模型 QA 能力的极限：小布局问题、在某些地方感觉不直观的交互，以及评估器没有充分测试的更深层嵌套功能中未发现的 bug。显然，通过进一步调整还可以捕获更多的验证空间。但与单独运行相比，其中应用程序的核心功能根本无法工作，提升是显而易见的。
迭代 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 功能构建到每个应用程序中，特别是让生成器构建一个可以通过工具驱动应用程序自身功能的适当智能体。这花了真正的迭代，因为相关知识足够新，Claude 的训练数据覆盖得很薄。但经过足够的调整，生成器正确地构建了智能体。
更新 harness 的结果
为了测试更新后的 harness，我使用以下提示生成了一个数字音频工作站（DAW），一个用于作曲、录音和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。
运行仍然漫长且昂贵，大约 4 小时和 124 美元的 token 成本。
大部分时间都花在了构建器上，它连贯地运行了超过两个小时，而没有 Opus 4.5 需要的冲刺分解。
| Agent & Phase | Duration | Cost |
|---|---|---|
| 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 |
与之前的 harness 一样，规划器将单行提示扩展为完整规格。从日志中，我可以看到生成器模型在规划应用程序和智能体设计、连接智能体以及在交接给 QA 之前测试它方面做得很好。
也就是说，QA 智能体仍然捕捉到了真正的差距。在第一轮反馈中，它指出：
这是一个具有出色设计保真度、可靠 AI 智能体和良好后端的强大应用程序。主要的失败点是功能完整性——虽然应用程序看起来令人印象深刻，AI 集成工作良好，但几个核心 DAW 功能只是显示而没有交互深度：剪辑不能在时间线上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有视觉效果编辑器（EQ 曲线、压缩器表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，规格明确要求它们。
在第二轮反馈中，它再次捕捉到几个功能性差距：
剩余差距：- 音频录制仍然是仅存根（按钮切换但没有麦克风捕获）- 剪辑边缘拖动调整大小和剪辑分割未实现 - 效果可视化是数字滑块，不是图形化的（没有 EQ 曲线）
当放任自流时，生成器仍然容易遗漏细节或存根功能，QA 在捕捉这些最后一公里问题方面仍然增加了价值，供生成器修复。
基于提示，我期望一个可以创建旋律、和声和鼓点模式，将它们编排成歌曲，并在整个过程中从集成智能体获得帮助的程序。下面的视频显示了结果。
该应用程序远非专业的音乐制作程序，智能体的歌曲创作技能显然还有很多工作要做。此外，Claude 实际上听不到，这使得 QA 反馈循环在音乐品味方面的效果降低。
但最终应用程序拥有一个功能性音乐制作程序的所有核心部分：浏览器中运行的编曲视图、混音器和传输。除此之外，我完全通过提示拼凑了一个短歌曲片段：智能体设置了速度和调性，铺设了旋律，构建了鼓点轨道，调整了混音器电平，并添加了混响。歌曲创作的核心原语已经存在，智能体可以自主驱动它们，使用工具从头到尾创建一个简单的制作。你可以说它还不完美——但它正在接近。
未来展望
随着模型不断改进，我们可以大致期望它们能够工作更长时间，处理更复杂的任务。在某些情况下，这意味着随着时间的推移，围绕模型的脚手架变得不那么重要，开发者可以等待下一个模型，看着某些问题自行解决。另一方面，模型越好，开发能够实现超越基线模型能力的复杂任务的 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 是一个基于 Web 的创意工作室，用于设计和构建 2D 复古风格视频游戏。它将经典 8 位和 16 位游戏美学的怀旧魅力与现代、直观的编辑工具相结合——使从爱好者创作者到独立开发者的任何人都能够在不编写传统代码的情况下将他们的游戏创意变为现实。
该平台提供四个集成的创意模块：基于瓦片的关卡编辑器用于设计游戏世界，像素艺术精灵编辑器用于制作视觉资产，可视化实体行为系统用于定义游戏逻辑，以及即时可玩测试模式用于实时游戏测试。通过在整个过程中编织 AI 辅助（由 Claude 提供支持），RetroForge 加速了创意过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。
RetroForge 针对热爱复古游戏美学但想要现代便利的创作者。无论是重现他们童年时代的平台游戏、RPG 或动作游戏，还是在复古约束内发明全新的体验，用户都可以快速原型化、视觉迭代并与他人分享他们的创作。
功能
1. 项目仪表板与管理
项目仪表板是 RetroForge 中所有创意工作的基地。用户需要一种清晰、有组织的方式来管理他们的游戏项目——创建新项目、返回进行中的工作，并一目了然地了解每个项目包含的内容。
用户故事：作为用户，我想要：
- 创建一个带有名称和描述的新游戏项目，以便我可以开始设计我的游戏
- 将所有现有项目显示为视觉卡片，显示项目名称、最后修改日期和缩略图预览，以便我可以快速找到并继续我的工作
- 打开任何项目进入完整的游戏编辑器工作区，以便我可以处理我的游戏
- 删除我不再需要的项目，带有确认对话框以防止意外，以便我可以保持工作区整洁
（计划继续，详细说明所有 16 个功能…）