长周期应用开发的 Harness 设计
过去几个月里，我一直致力于解决两个相互关联的问题：让 Claude 产出高质量的前端设计，以及让它在无人干预的情况下构建完整的应用程序。这项工作源于我们此前在前端设计技能和长时运行的编码智能体框架上的努力，我和同事们通过提示工程和框架设计，将 Claude 的表现提升到远超基线的水平——但两者最终都遇到了瓶颈。
为了突破瓶颈，我寻找了新颖的 AI 工程方法，这些方法要在两个截然不同的领域中都行得通：一个由主观品味定义，另一个则由可验证的正确性和可用性定义。受生成对抗网络（GAN）的启发，我设计了一个包含生成器和评估器智能体的多智能体结构。要构建一个能可靠且有品味地对输出进行评分的评估器，首先需要开发一套标准，将“这个设计好吗？”这样的主观判断转化为具体、可分级的术语。
随后，我将这些技术应用于长时自主编码，并从我们早期的框架工作中借鉴了两条经验：将构建过程分解为可处理的块，以及使用结构化产物在会话之间传递上下文。最终成果是一个三智能体架构——规划器、生成器和评估器——它能在长达数小时的自主编码会话中产出丰富的全栈应用程序。
为什么朴素的实现方式效果不佳
我们此前已经展示过，框架设计对长时运行的智能体编码效果有重大影响。在早期的实验中，我们使用一个初始化智能体将产品规格分解为任务列表，然后由一个编码智能体逐个功能地实现这些任务，最后交接产物以在会话间传递上下文。更广泛的开发者社区也得出了类似的见解，比如“Ralph Wiggum”方法，它使用钩子或脚本让智能体保持在持续迭代的循环中。
但一些问题依然存在。对于更复杂的任务，智能体仍会随着时间推移而偏离正轨。在剖析这个问题时，我们观察到智能体执行此类任务时常见的两种失败模式。
第一种是，随着上下文窗口被填满，模型在长任务中往往会失去连贯性（参见我们关于上下文工程的文章）。有些模型还会表现出“上下文焦虑”，即当它们接近自认为的上下文上限时，会开始过早地收尾工作。上下文重置——完全清空上下文窗口并启动一个全新的智能体，同时配合结构化的交接来传递前一个智能体的状态和后续步骤——可以同时解决这两个问题。
这与压缩不同，压缩是在原地对对话的早期部分进行总结，以便同一个智能体可以在缩短的历史记录上继续工作。虽然压缩保留了连续性，但它并没有给智能体一个全新的开始，这意味着上下文焦虑仍然可能持续存在。重置提供了一个全新的开始，代价是交接工件必须包含足够的状态，以便下一个智能体能够顺利接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出的上下文焦虑非常强烈，以至于仅靠压缩不足以实现强大的长任务性能，因此上下文重置对于框架设计变得至关重要。这解决了核心问题，但增加了每次框架运行的编排复杂性、令牌开销和延迟。
第二个问题是我们之前没有涉及的，即自我评估。当被要求评估自己产出的工作时，智能体往往会自信地赞扬这项工作——即使在人类观察者看来，质量显然很平庸。这个问题在设计等主观任务中尤为突出，因为这类任务没有类似可验证软件测试那样的二元检查。一个布局是否感觉精致还是普通是一个判断问题，而智能体在给自己的工作打分时总是倾向于给出正面评价。
然而，即使在确实有可验证结果的任务中，智能体有时仍会表现出糟糕的判断力，从而阻碍其完成任务。将执行工作的智能体与评判工作的智能体分开，被证明是解决这个问题的一个有力手段。这种分离本身并不能立即消除这种宽松倾向；评估者仍然是一个倾向于对 LLM 生成的输出慷慨的 LLM。但事实证明，将一个独立的评估者调整为持怀疑态度，远比让生成者对自己的工作进行批判要容易得多，而且一旦有了这种外部反馈，生成者就有了具体的迭代依据。
前端设计：让主观质量可评分
我首先在前端设计上进行了实验，因为自我评估问题在这里最为明显。在没有任何干预的情况下，Claude 通常倾向于安全、可预测的布局，这些布局在技术上是可用的，但在视觉上并不出众。
有两个见解塑造了我为前端设计构建的框架。首先，虽然美学无法完全归结为一个分数——个人品味总是会有所不同——但可以通过编码设计原则和偏好的评分标准来改进它们。"这个设计美吗？"很难一致地回答，但"这是否遵循了我们优秀设计的原则？"则给了 Claude 一些具体的评分依据。其次，通过将前端生成与前端评分分开，我们可以创建一个反馈循环，推动生成者产出更强大的结果。
考虑到这一点，我编写了四个评分标准，并将它们提供给生成者和评估者智能体的提示词中：
- 设计质量：设计是否感觉是一个连贯的整体，而不是各部分的堆砌？这方面的优秀作品意味着颜色、排版、布局、图像和其他细节结合在一起，创造出独特的氛围和特色。
- 原创性：是否有定制决策的证据，还是这只是模板布局、库默认设置和 AI 生成的模式？人类设计师应该能识别出深思熟虑的创意选择。未经修改的库存组件——或 AI 生成的明显迹象，如白色卡片上的紫色渐变——在这里都不合格。
- 工艺：技术执行：字体层级、间距一致性、色彩协调、对比度。这是一项能力检查，而非创意检查。大多数合理的实现在这里默认就能通过；失败意味着基本功有问题。
- 功能性：独立于美学的可用性。用户能否理解界面的功能、找到主要操作，并在无需猜测的情况下完成任务？
我将设计质量和原创性置于工艺和功能性之上。Claude 在工艺和功能性方面默认得分就很高，因为所需的技术能力对模型来说往往自然而然。但在设计和原创性方面，Claude 产出的内容往往充其量只是平淡无奇。标准明确惩罚高度通用的“AI 垃圾”模式，通过加大设计和原创性的权重，促使模型进行更多美学上的冒险。
我使用带有详细评分分解的少样本示例对评估器进行了校准。这确保了评估器的判断与我的偏好一致，并减少了跨迭代的评分漂移。
我基于 Claude Agent SDK 构建了这个循环，使编排保持简单。生成器代理首先根据用户提示创建一个 HTML/CSS/JS 前端。我将 Playwright MCP 提供给评估器，使其能够在对每个标准评分并撰写详细评论之前，直接与实时页面交互。在实践中，评估器会自行导航页面，截图并仔细研究实现，然后给出评估。该反馈作为下一次迭代的输入回流给生成器。每次生成我运行 5 到 15 次迭代，每次迭代通常会根据评估器的评论将生成器推向更具特色的方向。由于评估器是主动导航页面，而不是对静态截图评分，每个周期都需要实际的墙钟时间。完整运行最长可达四小时。我还指示生成器在每次评估后做出策略性决定：如果分数趋势良好，则完善当前方向；如果方法不起作用，则转向完全不同的美学。
在多次运行中，评估器的评估在迭代中有所改善，随后趋于平稳，但仍有提升空间。有些生成是逐步完善的，有些则在迭代之间出现了急剧的美学转向。
标准的措辞以我未曾完全预料的方式引导了生成器。包含“最好的设计是博物馆级的”这样的短语，将设计推向了特定的视觉趋同，这表明与标准相关的提示直接塑造了输出的特征。
尽管分数通常随迭代而提高，但模式并不总是清晰的线性。后期的实现整体上往往更好，但我经常遇到更喜欢中间某次迭代而非最后一次的情况。实现的复杂性也倾向于逐轮增加，生成器为了回应评估器的反馈而追求更雄心勃勃的方案。即使在第一次迭代中，输出也明显优于完全没有提示的基线，这表明标准及其相关语言本身就在任何评估器反馈带来进一步完善之前，就将模型从通用默认值中引导了出来。
在一个引人注目的例子中，我提示模型为一家荷兰艺术博物馆创建网站。到第九次迭代时，它已经为一个虚构的博物馆生成了一个简洁的深色主题着色页。这个页面视觉上很精致，但基本上符合我的预期。然后，在第十次循环中，它完全抛弃了这种方法，将网站重新构想为一种空间体验：一个用 CSS 透视渲染的棋盘格地板的 3D 房间，艺术品以自由形式的位置悬挂在墙上，以及基于门口的画廊房间之间的导航，而不是滚动或点击。这是那种我以前从未在单次生成中见过的创造性飞跃。
扩展到全栈编码
掌握了这些发现后，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然映射到软件开发生命周期，其中代码审查和 QA 承担着与设计评估器相同的结构性角色。
架构
在我们早期的 long-running harness 中，我们已经通过一个初始化代理、一个每次处理一个功能的编码代理以及会话之间的上下文重置，实现了连贯的多会话编码。上下文重置是一个关键的突破：该 harness 使用 Sonnet 4.5，它表现出前文提到的“上下文焦虑”倾向。创建一个能在上下文重置下良好运行的 harness 是让模型保持任务专注的关键。Opus 4.5 基本上自行消除了这种行为，因此我能够完全从这个 harness 中去掉上下文重置。代理在整个构建过程中作为一次连续会话运行，由 Claude Agent SDK 的自动压缩功能在过程中处理上下文增长。
在这项工作中，我在原始 harness 的基础上构建了一个三代理系统，每个代理针对我在之前运行中观察到的一个特定缺口。该系统包含以下代理角色：
Planner：我们之前的 long-running harness 要求用户预先提供详细的规格说明。我想自动化这一步骤，因此创建了一个 planner 代理，它接受一个简单的 1-4 句提示，并将其扩展为完整的产品规格说明。我提示它在范围上要有雄心，并专注于产品上下文和高层技术设计，而不是详细的技术实现。这种强调是出于这样的担忧：如果 planner 试图预先指定细粒度的技术细节并弄错了，规格说明中的错误就会级联到下游实现中。似乎更明智的做法是限制代理在要产出的交付物上，让它们在工作过程中自行摸索路径。我还要求 planner 寻找机会将 AI 功能融入产品规格说明中。（参见底部附录中的示例。）
Generator：早期 harness 中一次一个功能的方法在范围管理上效果很好。我在这里应用了类似的模型，指示 generator 以冲刺（sprint）方式工作，每次从规格说明中选取一个功能。每个冲刺使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）技术栈实现应用，并指示 generator 在每个冲刺结束时、移交给 QA 之前对自己的工作进行自我评估。它还使用 git 进行版本控制。
评估器：早期框架生成的应用程序往往看起来很惊艳，但当你真正尝试使用时，仍存在真实的 bug。为了捕捉这些问题，评估器使用 Playwright MCP，像真实用户那样点击运行中的应用程序，测试 UI 功能、API 端点和数据库状态。随后，它根据发现的 bug 以及一套基于前端实验建模的准则对每个冲刺进行评分，这些准则在此处经过调整，涵盖产品深度、功能、视觉设计和代码质量。每条准则都有一个硬性阈值，只要有一条低于阈值，该冲刺即告失败，生成器会收到关于问题所在的详细反馈。
在每个冲刺开始前，生成器和评估器会协商一份冲刺契约：在编写任何代码之前，就该工作块的“完成”定义达成一致。之所以设置这一环节，是因为产品规格有意保持在较高层次，我希望有一个步骤来弥合用户故事与可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案，以确保生成器构建的是正确的东西。双方反复迭代，直至达成一致。
通信通过文件进行：一个智能体写入文件，另一个智能体读取它，并在同一文件内或通过新文件作出回复，前一个智能体随后会读取该文件。然后，生成器按照商定的契约进行构建，再将工作移交给 QA。这样既保证了工作忠实于规格，又避免过早地对实现进行过度规定。
运行框架
对于这个框架的第一个版本，我使用了 Claude Opus 4.5，将用户提示分别在完整框架和单智能体系统上运行以进行对比。我之所以使用 Opus 4.5，是因为在我开始这些实验时，它是我们最好的编码模型。
我编写了以下提示来生成一个复古电子游戏制作器：
创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为以及可玩的测试模式。
下表显示了框架类型、运行时长和总成本。
该框架的成本高出 20 多倍，但输出质量的差异立竿见影。
我期望的是一个界面，我可以在其中构建关卡及其组成部分（精灵、实体、瓦片布局），然后点击播放来实际游玩该关卡。我首先打开单智能体运行的输出，最初的应用程序似乎符合这些预期。
然而，当我点击浏览时，问题开始显现。布局浪费了空间，固定高度的面板使视口的大部分区域空置。工作流程很僵硬。尝试填充关卡时，系统提示我先创建精灵和实体，但界面上没有任何东西引导我遵循这一顺序。更重要的是，实际的游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入研究代码后发现，实体定义与游戏运行时之间的连接是断开的，而且表面上看不出问题出在哪里。
在评估完单次运行后，我将注意力转向了框架运行。这次运行同样从同一句一句话提示开始，但规划器步骤将该提示扩展为一份跨越十个冲刺的16项功能规格。它远远超出了单次运行的尝试范围。除了核心编辑器和游玩模式外，该规格还要求实现精灵动画系统、行为模板、音效和音乐、AI辅助的精灵生成器和关卡设计器，以及带有可分享链接的游戏导出功能。我让规划器访问了我们的前端设计技能，它阅读了该技能，并将其用于在规格中为应用创建视觉设计语言。对于每个冲刺，生成器和评估器会协商一份契约，定义该冲刺的具体实现细节，以及用于验证完成情况的可测试行为。
该应用立刻展现出比单次运行更高的精致度和流畅度。画布占满了整个视口，面板尺寸合理，界面具有统一的视觉标识，与规格中的设计方向保持一致。我在单次运行中看到的一些笨拙之处依然存在——工作流仍然没有明确指出你应该先构建精灵和实体，然后再尝试填充关卡，我是通过四处摸索才弄明白的。这被视为基础模型产品直觉的不足，而非框架旨在解决的问题，尽管它确实表明，在框架内进行有针对性的迭代可以进一步提高输出质量。
在使用各个编辑器的过程中，新运行相对于单次运行的优势变得更加明显。精灵编辑器更加丰富、功能更完善，拥有更整洁的工具面板、更好的颜色选择器以及更实用的缩放控件。
由于我要求规划器将AI功能融入其规格中，该应用还内置了Claude集成，让我可以通过提示词生成游戏的不同部分。这显著加快了工作流。
最大的差异在于游玩模式。我实际上能够移动我的实体并游玩游戏。物理效果有些粗糙——我的角色跳到了平台上，但最终与平台重叠了，这在直觉上感觉不对——但核心功能是有效的，而单次运行未能做到这一点。在四处移动了一段时间后，我确实遇到了AI在游戏关卡构建方面的一些局限。有一堵大墙我无法跳过去，因此我被困住了。这表明框架可以处理一些常识性改进和边缘情况，以进一步完善应用。
通读日志后，很明显评估器使实现与规格保持一致。每个冲刺，它都会遍历冲刺契约的测试标准，并通过Playwright操作运行中的应用程序，针对任何偏离预期行为的问题提交缺陷报告。这些契约非常细致——仅冲刺3就有27项涵盖关卡编辑器的标准——而且评估器的发现足够具体，无需额外调查即可采取行动。下表列出了我们的评估器发现的几个问题示例：
让评估器达到这种水平费了不少功夫。开箱即用的 Claude 是个糟糕的 QA 代理。在早期运行中，我看到它识别出真实存在的问题，然后又说服自己认为这些问题无关紧要，照样通过了工作。它还倾向于进行表面测试，而不是深入探究边界情况，因此更隐蔽的 bug 经常漏网。调优循环是阅读评估器的日志，找出其判断与我产生分歧的案例，然后更新 QA 的提示词来解决这些问题。经过几轮这样的开发循环，评估器才以我认为合理的方式进行评分。即便如此，测试框架的输出仍暴露了模型 QA 能力的局限：细小的布局问题、某些地方感觉不直观的交互，以及评估器未彻底测试的更深层嵌套功能中尚未发现的 bug。显然还有进一步调优以提升验证水平的空间。但与单次运行相比——那次运行中应用的核心功能根本无法工作——提升是显而易见的。
迭代测试框架
第一批测试框架的结果令人鼓舞，但它也笨重、缓慢且昂贵。合乎逻辑的下一步是找到简化测试框架的方法，同时不降低其性能。这部分是常识，部分源于一个更普遍的原则：测试框架中的每个组件都编码了一个关于模型自身无法完成什么的假设，而这些假设值得进行压力测试，既因为它们可能是错误的，也因为随着模型改进它们可能很快过时。我们的博文 Building Effective Agents 将这一核心思想表述为“找到最简单的可行方案，只在必要时增加复杂度”，对于任何维护代理测试框架的人来说，这都是一个反复出现的模式。
在我第一次尝试简化时，我大幅削减了测试框架，并尝试了一些新颖的创意想法，但无法复制原始框架的性能。而且也很难分辨测试框架设计中哪些部分真正起着承重作用，以及它们以何种方式起作用。基于这次经验，我转向了更有条理的方法，一次移除一个组件，并审查它对最终结果的影响。
在经历这些迭代周期的同时，我们还发布了 Opus 4.6，这进一步激发了降低测试框架复杂度的动力。有充分理由预期 4.6 比 4.5 需要更少的脚手架。根据我们的发布博客：“[Opus 4.6] 规划更周密，能更持久地执行代理任务，在更大的代码库中运行更可靠，并且拥有更好的代码审查和调试技能来捕捉自身的错误。”它在长上下文检索方面也有显著改进。这些都是测试框架原本旨在补充的能力。
移除冲刺（sprint）结构
我首先完全移除了冲刺结构。冲刺结构曾帮助将工作分解成块，让模型能够连贯地工作。鉴于 Opus 4.6 的改进，有充分理由相信模型可以原生地处理这项工作，而无需这种分解。
我保留了规划器和评估器，因为它们各自仍在持续提供明显的价值。没有规划器，生成器的范围界定不足：给定原始提示词，它会在未先规划工作的情况下直接开始构建，最终创建出的应用功能不如规划器生成的丰富。
移除 sprint 构建后，我将评估器改为在运行结束时进行单次评估，而不是按每个 sprint 打分。由于模型能力大幅提升，这改变了评估器对某些运行的支撑作用，其有用性取决于任务相对于模型自身可靠能力所处的位置。在 4.5 上，这个边界很接近：我们的构建处于生成器单独能够良好完成的边缘，评估器在整个构建过程中捕捉到了有意义的问题。在 4.6 上，模型的原始能力提升了，因此边界向外移动。过去需要评估器检查才能连贯实现的任务，现在往往处于生成器自身能够良好处理的范围内，对于这个边界内的任务，评估器变成了不必要的开销。但对于构建中仍处于生成器能力边缘的部分，评估器继续提供了真正的提升。
实际意义在于，评估器不是一个固定的是否启用的决定。当任务超出当前模型单独可靠完成的范围时，它的成本是值得的。
除了结构上的简化，我还添加了提示词来改进框架将 AI 功能构建到每个应用中的方式，具体来说是让生成器构建一个合适的代理，能够通过工具驱动应用自身的功能。这需要真正的迭代，因为相关知识太新，Claude 的训练数据对此覆盖很薄。但经过足够的调整，生成器能够正确构建代理。
更新后框架的结果
为了测试更新后的框架，我使用以下提示词生成了一个数字音频工作站（DAW），一个用于作曲、录音和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。
这次运行仍然漫长且昂贵，大约 4 小时，代币成本为 124 美元。
大部分时间花在了构建器上，它在没有 Opus 4.5 所需的 sprint 分解的情况下，连贯运行了两个多小时。
与之前的框架一样，规划器将一行提示词扩展为完整的规格。从日志中，我可以看到生成器模型在规划应用和代理设计、连接代理以及在移交给 QA 之前进行测试方面做得很好。
话虽如此，QA 代理仍然捕捉到了真实的差距。在第一轮反馈中，它指出：
这是一个强大的应用，具有出色的设计保真度、扎实的 AI 代理和良好的后端。主要失败点是功能完整性——虽然应用看起来令人印象深刻且 AI 集成运行良好，但几个核心 DAW 功能仅是显示性的，缺乏交互深度：片段无法在时间轴上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化的效果编辑器（EQ 曲线、压缩器表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，规格中明确要求了这些功能。
在第二轮反馈中，它再次捕捉到了几个功能差距：
剩余差距：
- 音频录制仍然只是占位（按钮可切换但没有麦克风捕获）
- 通过边缘拖动调整片段大小和片段分割未实现
- 效果可视化是数字滑块，而非图形化（没有 EQ 曲线）
当放任自流时，生成器仍然容易遗漏细节或用占位功能敷衍，而 QA 在捕捉这些最后一公里的问题供生成器修复方面仍然增加了价值。
根据提示，我原本期望的是一个可以创建旋律、和声和鼓点模式，将它们编排成一首歌曲，并在过程中获得集成智能体帮助的程序。下面的视频展示了最终结果。
该应用远非专业音乐制作程序，智能体的歌曲创作能力显然还有很大提升空间。此外，Claude 实际上听不见声音，这使得在音乐品味方面的质量保证反馈循环效果打了折扣。
但最终的应用具备了功能性音乐制作程序的所有核心组件：在浏览器中运行的可用编排视图、混音器和走带控制。除此之外，我完全通过提示词就拼凑出了一段简短的歌曲片段：智能体设置了速度和调式，铺陈了旋律，构建了鼓轨，调整了混音器电平，并添加了混响。歌曲创作的核心原语都已具备，智能体可以自主驱动它们，使用工具从头到尾完成一个简单的制作。你可以说它还不够完美——但它正在接近。
下一步
随着模型不断改进，我们可以大致预期它们能够持续工作更长时间，并处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随时间推移变得不那么重要，开发者可以等待下一个模型，看着某些问题自行解决。另一方面，模型越好，就越有空间去开发能够实现超出模型基线能力的复杂任务的运行框架（harness）。
考虑到这一点，这项工作有几条经验值得延续。始终值得做的实践是：针对你正在构建的模型进行实验，阅读它在真实问题上的追踪记录，并调整其性能以达到你期望的结果。在处理更复杂的任务时，通过分解任务并将专门的智能体应用于问题的各个方面，有时能带来额外的提升空间。而当新模型发布时，通常值得重新审视运行框架，剥离那些对性能不再起支撑作用的部分，并添加新的部分以实现以前可能无法达到的更大能力。
通过这项工作，我的信念是：有趣的运行框架组合空间并不会随着模型的改进而缩小。相反，它在移动，而 AI 工程师的有趣工作就是不断寻找下一个新颖的组合。
附录
由规划智能体生成的示例计划。
RetroForge - 2D Retro Game Maker
Overview
RetroForge is a web-based creative studio for designing and building 2D retro-style video games. It combines the nostalgic charm of classic 8-bit and 16-bit game aesthetics with modern, intuitive editing tools—enabling anyone from hobbyist creators to indie developers to bring their game ideas to life without writing traditional code.
The platform provides four integrated creative modules: a tile-based Level Editor for designing game worlds, a pixel-art Sprite Editor for crafting visual assets, a visual Entity Behavior system for defining game logic, and an instant Playable Test Mode for real-time gameplay testing. By weaving AI assistance throughout (powered by Claude), RetroForge accelerates the creative process—helping users generate sprites, design levels, and configure behaviors through natural language interaction.
RetroForge targets creators who love retro gaming aesthetics but want modern conveniences. Whether recreating the platformers, RPGs, or action games of their childhood, or inventing entirely new experiences within retro constraints, users can prototype rapidly, iterate visually, and share their creations with others.
Features
1. Project Dashboard & Management
The Project Dashboard is the home base for all creative work in RetroForge. Users need a clear, organized way to manage their game projects—creating new ones, returning to works-in-progress, and understanding what each project contains at a glance.
User Stories: As a user, I want to:
- Create a new game project with a name and description, so that I can begin designing my game
- See all my existing projects displayed as visual cards showing the project name, last modified date, and a thumbnail preview, so that I can quickly find and continue my work
- Open any project to enter the full game editor workspace, so that I can work on my game
- Delete projects I no longer need, with a confirmation dialog to prevent accidents, so that I can keep my workspace organized
- Duplicate an existing project as a starting point for a new game, so that I can reuse my previous work
Project Data Model: Each project contains:
Project metadata (name, description, created/modified timestamps)
Canvas settings (resolution: e.g., 256x224, 320x240, or 160x144)
Tile size configuration (8x8, 16x16, or 32x32 pixels)
Color palette selection
All associated sprites, tilesets, levels, and entity definitions
...