面向长时运行应用开发的 Harness 设计

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

在过去几个月里，我一直在研究两个相互关联的问题：如何让 Claude 生成高质量的前端设计，以及如何让它在无人干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计技能和长时间运行的编码智能体框架上的探索——我和同事通过提示工程与框架设计，将 Claude 的表现大幅提升至基线水平之上，但两者最终都遇到了瓶颈。

为了突破瓶颈，我寻找能够跨越两个截然不同领域的新型 AI 工程方法：一个以主观审美为核心，另一个以可验证的正确性和可用性为核心。受生成对抗网络（GAN）的启发，我设计了一种包含生成器与评估器智能体的多智能体架构。要构建一个能够可靠且有品位地评分的评估器，首先需要制定一套标准，将”这个设计好吗？”这样的主观判断转化为具体可评分的维度。

随后，我将这些技术应用于长时间自主编码，并沿用了早期框架工作的两条经验：将构建过程分解为可处理的块，以及使用结构化制品在会话之间传递上下文。最终成果是一个三智能体架构——规划器、生成器和评估器——能够在数小时的自主编码会话中生成功能丰富的全栈应用程序。

为什么朴素实现往往力不从心

我们此前已经证明，框架设计对长时间运行的智能体编码效果有着显著影响。在一项早期实验中，我们使用初始化智能体将产品规格分解为任务列表，并由编码智能体逐项实现，再通过制品在会话间传递上下文。更广泛的开发者社区也形成了类似共识，例如”Ralph Wiggum“方法使用钩子或脚本让智能体保持持续迭代。

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

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

这与压缩不同。压缩是对对话早期部分进行原地摘要，使同一智能体能够在缩短的历史记录上继续工作。压缩保留了连续性，但无法给智能体一个干净的起点，因此上下文焦虑仍可能持续。重置提供了干净的起点，代价是交接制品需要携带足够的状态，以便下一个智能体能够顺畅衔接。在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑足够强烈，仅靠压缩并不足以支撑强劲的长任务表现，因此上下文重置成为框架设计的关键。这解决了核心问题，但也为每次框架运行增加了编排复杂度、token 开销和延迟。

第二个问题此前尚未被我们解决，即自我评估。当被要求评估自己生成的工作时，智能体往往会自信地给予高度赞扬——即便在人类观察者看来，质量明显平庸。这一问题在设计等主观任务上尤为突出，因为这里没有类似可验证软件测试的二元检查。布局是否精致还是流于平庸，是一种判断，而智能体在评价自己的工作时几乎总是倾向于正面评价。

然而，即便在有可验证结果的任务上，智能体有时仍会表现出判断力不足，妨碍完成任务。将执行工作的智能体与评判工作的智能体分离，是解决这一问题的有力手段。这种分离本身并不能立即消除宽松评价的倾向——评估器仍然是一个倾向于对 LLM 生成的输出持宽容态度的 LLM。但将独立评估器调校为持怀疑态度，远比让生成器批判自身工作更加可行；一旦外部反馈存在，生成器便有了具体可迭代的依据。

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

我从前端设计入手进行实验，因为自我评估问题在这里最为突出。在没有任何干预的情况下，Claude 通常倾向于选择安全、可预期的布局——技术上可用，但视觉上平淡无奇。

两个洞察塑造了我为前端设计构建的框架。第一，虽然审美无法完全化约为分数——个人品味也始终存在差异——但可以通过编码了设计原则和偏好的评分标准来加以提升。”这个设计漂亮吗？”难以一致回答，但”这个设计是否符合我们的优质设计原则？”给了 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 生成的应用往往看起来令人印象深刻，但在实际使用时仍存在真实缺陷。为了捕获这些问题，评估器使用 Playwright MCP 像真实用户一样点击浏览运行中的应用，测试 UI 功能、API 端点和数据库状态。随后，它根据发现的缺陷以及一套参照前端实验标准改编的评估准则，对每个冲刺进行评分，这里的准则涵盖了产品深度、功能性、视觉设计和代码质量。每项准则都有硬性阈值，若任何一项低于阈值，该冲刺即为失败，生成器将收到关于问题所在的详细反馈。

在每个冲刺开始前，生成器和评估器会协商一份冲刺契约：在编写任何代码之前，就该工作块的”完成”定义达成一致。这一步骤的存在是因为产品规格是有意保持高层次的，我希望有一个步骤来弥合用户故事与可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案以确保生成器构建的是正确的东西。两者反复迭代直至达成一致。

通信通过文件进行：一个智能体写入文件，另一个智能体读取并在该文件内回应，或写入新文件供前一个智能体读取。生成器随后按照约定的契约进行构建，再将工作移交 QA。这保证了工作忠实于规格，同时避免过早过度指定实现细节。

运行 harness

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

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

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

下表展示了 harness 类型、运行时长和总费用。

该 harness 的成本超出了 20 倍，但输出质量的差异立竿见影。

我期望的是一个可以构建关卡及其组件（精灵、实体、瓦片布局）后点击播放来实际游玩关卡的界面。我首先打开了单智能体运行的输出，初始应用看起来符合这些预期。

然而，随着我的点击浏览，问题开始浮现。布局浪费了空间，固定高度的面板让大部分视口空空如也。工作流程僵硬。尝试为关卡填充内容时会提示我先创建精灵和实体，但 UI 中没有任何引导提示这一顺序。更关键的是，实际游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入代码后发现，实体定义与游戏运行时之间的连接是断裂的，且表面上没有任何迹象指示问题所在。

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

该应用立刻展现出比单智能体运行更多的打磨感和流畅度。画布占满了整个视口，面板尺寸合理，界面具有与规格中设计方向一致的统一视觉标识。我在单智能体运行中看到的一些笨拙之处确实仍然存在——工作流程依然没有明确提示应先构建精灵和实体再填充关卡，我不得不自己摸索。这体现了基础模型在产品直觉上的不足，而非 harness 本身设计要解决的问题，尽管这确实表明了一个可以在 harness 内部进行针对性迭代以进一步提升输出质量的切入点。

浏览各个编辑器的过程中，新运行相对于单智能体运行的优势愈发明显。精灵编辑器更加丰富、功能更加完整，工具面板更整洁，颜色选择器更好用，缩放控件更易用。

由于我要求规划器将 AI 功能融入规格，应用还内置了 Claude 集成，让我可以通过提示生成游戏的不同部分，这大幅加快了工作流程。

最大的差异在于游玩模式。我实际上能够移动我的实体并玩这个游戏了。物理引擎有些粗糙——我的角色跳上平台后与其发生了重叠，感觉直觉上不对——但核心功能是可用的，而这正是单智能体运行所未能做到的。移动了一段时间后，我确实遇到了 AI 关卡构建的一些局限性。有一堵很高的墙我无法跳过去，导致我被卡住了。这表明 harness 还可以处理一些常识性改进和边缘情况，以进一步完善应用。

查阅日志后，评估器在每个冲刺中都将实现与规格保持一致，这一点显而易见。它逐条检查冲刺契约的测试准则，通过 Playwright 操作运行中的应用，对任何偏离预期行为的地方提交缺陷报告。契约内容非常细化——仅第 3 个冲刺就有 27 条覆盖关卡编辑器的准则——评估器的发现足够具体，无需额外调查即可直接采取行动。下表列举了评估器识别出的若干问题示例：

让评估器达到这一水准着实费了一番功夫。开箱即用的 Claude 是一个糟糕的 QA 代理。在早期运行中，我亲眼看到它识别出合理的问题，然后又说服自己觉得问题不严重，最终还是通过了审核。它还倾向于进行浅层测试，而非深入探查边界情况，因此一些更隐蔽的 bug 往往会漏网。调优的过程是：阅读评估器的日志，找出其判断与我存在分歧的案例，然后更新 QA 提示词来解决这些问题。经过几轮这样的开发迭代，评估器的评分方式才达到我认为合理的水平。即便如此，harness 的输出依然暴露了模型 QA 能力的局限：细小的布局问题、某些交互在操作上不够直觉友好，以及在评估器未充分测试到的深层嵌套功能中尚未发现的 bug。通过进一步调优，显然还有更大的验证空间可以挖掘。但与单独运行相比——彼时应用的核心功能根本无法正常工作——这次的提升是显而易见的。

迭代优化 harness

第一批 harness 结果令人鼓舞，但它也显得臃肿、缓慢且成本高昂。合乎逻辑的下一步是在不降低性能的前提下简化 harness。这部分源于常识，部分则源于一个更普遍的原则：harness 中的每个组件都编码了一个关于模型独立完成任务能力的假设，而这些假设值得反复检验——既因为它们可能本就有误，也因为随着模型的改进，它们可能很快就会过时。我们的博客文章 Building Effective Agents 将这一底层思想概括为”找到尽可能简单的解决方案，只在必要时才增加复杂度”，这一模式在任何维护代理 harness 的人的工作中都会反复出现。

在我第一次简化尝试中，我大幅削减了 harness，并尝试了一些新颖的思路，但始终无法复现原版的性能表现。与此同时，harness 设计中哪些部分真正是关键所在、又以何种方式发挥作用，也变得难以判断。基于这段经历，我转向了更系统的方法：每次只移除一个组件，并观察其对最终结果的影响。

在这些迭代周期进行的同时，我们也发布了 Opus 4.6，这进一步促使我去降低 harness 的复杂度。有充分理由相信，4.6 所需的脚手架比 4.5 更少。正如我们的发布博客所言：”[Opus 4.6] 规划更周密，能更持久地维持代理任务，在大型代码库中运行更可靠，并具备更强的代码审查和调试能力，能够发现自身的错误。”它在长上下文检索方面也有了大幅提升。而这些，恰恰都是 harness 此前被构建来弥补的能力短板。

移除 sprint 构造

我首先彻底移除了 sprint 构造。sprint 结构原本有助于将工作分解为若干块，让模型能够有条不紊地推进。考虑到 Opus 4.6 的能力提升，有充分理由相信模型可以原生应对这项工作，无需这种人为分解。

我保留了规划器和评估器，因为两者仍然能带来显而易见的价值。若没有规划器，生成器会低估工作范围：面对原始提示词，它会直接开始构建，而不先制定规格说明，最终产出的应用功能丰富程度不及有规划器时的结果。

移除 sprint 构造后，我将评估器改为在整个运行结束后进行单次评审，而非逐个 sprint 打分。由于模型能力大幅提升，评估器的重要程度因任务而异，取决于任务相对于模型独立处理能力的位置。在 4.5 上，这条边界很近：我们的构建任务处于生成器独立完成的边缘地带，评估器在整个构建过程中都能发现有实质意义的问题。在 4.6 上，模型的原始能力提升了，边界向外移动。那些过去需要评估器介入才能实现连贯的任务，如今往往在生成器的独立处理范围之内，对于这类任务，评估器就成了不必要的开销。但对于仍处于生成器能力边缘的那部分构建内容，评估器依然能带来真实的提升。

实际含义是：评估器并非一个固定的是否决策。当任务超出当前模型独立可靠完成的范围时，它才值得付出成本。

在结构简化的同时，我还增加了提示词调优，以改进 harness 在每个应用中构建 AI 功能的方式——具体而言，是让生成器构建一个真正的代理，通过工具驱动应用自身的功能。这经过了不少迭代，因为相关知识足够新颖，Claude 的训练数据对此覆盖有限。但经过充分调优，生成器已能正确构建代理。

更新后 harness 的结果

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

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

这次运行耗时仍然较长、成本较高，约 4 小时，token 费用约 124 美元。

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

与之前的 harness 一样，规划器将这条单行提示词扩展为完整的规格说明。从日志来看，生成器模型在规划应用和代理设计、接入代理以及在交付给 QA 前进行自测方面，都表现出色。

尽管如此，QA 代理仍然发现了真实的缺陷。在第一轮反馈中，它指出：

这是一个出色的应用，设计还原度高，AI 代理表现扎实，后端质量良好。主要的失败点在于功能完整性——尽管应用外观令人印象深刻，AI 集成运行良好，但几个核心 DAW 功能仅停留在展示层面，缺乏可交互的深度：片段无法在时间轴上拖拽/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（均衡器曲线、压缩器仪表）。这些不是边缘情况——它们是让 DAW 真正可用的核心交互，而规格说明中明确要求了这些功能。

在第二轮反馈中，它再次发现了若干功能缺口：

仍存在的缺口：

• 录音功能仍仅为存根（按钮可切换，但无麦克风捕获）

• 通过边缘拖拽调整片段大小和片段分割功能未实现

• 效果可视化为数字滑块，而非图形化（无均衡器曲线）

生成器放任自流时仍然容易遗漏细节或将功能做成存根，QA 在捕获这些最后一公里的问题、供生成器修复方面依然贡献了实质价值。

基于提示词，我期待得到一个能够创作旋律、和声与鼓点，将其编排成歌曲，并借助内置代理提供帮助的程序。以下视频展示了最终成果。

这款应用距离专业音乐制作软件还相去甚远，代理的歌曲创作能力显然还有很大的提升空间。此外，Claude 实际上无法”听见”，这使得 QA 反馈循环在音乐品味方面的效果大打折扣。

但最终的应用具备了一个功能性音乐制作程序的全部核心要素：可运行于浏览器的编排视图、混音器和传输控制。更进一步，我完全通过提示词编排出了一段简短的歌曲片段：代理设定了曲速和调性，铺陈了主旋律，构建了鼓轨，调整了混音电平，并添加了混响。歌曲创作的核心基础元素已悉数就位，代理能够自主驱动这些功能，借助工具从头到尾完成一段简单的制作。或许可以说，它尚未达到完美的音高——但正在稳步前进。

未来展望

随着模型持续进步，我们大致可以预期它们能够处理更长时间、更复杂的任务。在某些情况下，这意味着围绕模型的脚手架会随着时间推移变得不那么重要，开发者可以等待下一个模型，看某些问题自然解决。另一方面，模型越强大，开发能够完成超出模型基线能力的复杂任务的 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 像素）
调色板选择
所有关联的精灵、瓦片集、关卡和实体定义

...