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