长时间应用开发的 Harness 设计
译自 Harness design for long-running application development · www.anthropic.com
作者：Prithvi Rajasekaran，Anthropic Labs 团队成员。
过去几个月，我一直在攻克两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在无人干预的情况下构建完整应用。这项工作源于我们早期在 frontend design skill 和长时间运行 coding agent harness 上的探索——通过 prompt 工程和 harness 设计，我们把 Claude 的表现拉到了远高于基线的水平，但两个方向最终都碰了天花板。
为了突破瓶颈，我开始寻找能同时覆盖两个截然不同领域的新 AI 工程方法：一个领域靠主观品味说话，另一个靠可验证的正确性和可用性。受生成对抗网络（GAN）的启发，我设计了一个由生成器和评估器 agent 组成的多 agent 结构。要让评估器可靠、有品味地打分，首先需要建立一套评判标准，把”这个设计好不好？“这类主观判断转化成可以打分的具体维度。
随后，我把这套方法迁移到长时间自主 coding 场景，沿用了早期 harness 工作中总结的两个经验：把构建过程拆分成可操作的小块，以及用结构化的 artifact 在 session 之间传递上下文。最终形成了一套三 agent 架构——planner、generator、evaluator——能够在数小时的自主 coding session 中产出功能丰富的全栈应用。
为什么朴素实现行不通
我们已经多次证明，harness 设计对长时间 agentic coding 的效果有显著影响。在早期的实验中，我们用一个初始化 agent 把产品 spec 拆解成任务列表，再用一个 coding agent 逐功能实现，session 之间靠 artifact 传递上下文。更广泛的开发者社区也得出了类似结论，比如”Ralph Wiggum”方法就是用 hook 或脚本让 agent 保持持续迭代。
但有些问题一直没解决。对于更复杂的任务，agent 还是会随时间失控。在拆解这个问题的过程中，我们观察到两种常见的失败模式。
第一个是模型在长任务中随着 context window 填满而逐渐失去连贯性（详见我们关于 context engineering 的文章）。有些模型还会出现”context 焦虑”——当它们认为自己快触到 context 上限时，会提前收尾。Context reset（完全清空 context window，启动全新 agent，配合结构化的 handoff 传递前一个 agent 的状态和后续步骤）能同时解决这两个问题。
这和 compaction 不同——compaction 是把对话历史早期部分就地压缩，让同一个 agent 继续跑缩短后的历史。Compaction 保留了连续性，但不给 agent 一个干净的开始，所以 context 焦虑依然存在。Reset 提供了干净的起点，代价是 handoff artifact 需要包含足够的状态让下一个 agent 顺利接手。在早期测试中，Claude Sonnet 4.5 的 context 焦虑问题严重到单靠 compaction 不够，context reset 因此成了 harness 设计的核心。这解决了根本问题，但也带来了编排复杂度、token 开销和每次运行的延迟。
第二个问题是自我评估。让 agent 评价自己产出的东西时，它们往往会自信地给出好评——即便在人看来质量明显平庸。这个问题在设计这类主观任务上尤为突出，因为没有等价于可验证软件测试的二元判断标准。一个布局是否精致或流于平庸是一个判断题，而 agent 在给自己的作品打分时几乎总是偏向正面。
不过即便是有可验证结果的任务，agent 在执行过程中有时也会表现出阻碍进展的糟糕判断。把做事的 agent 和评判的 agent 分开，被证明是解决这个问题的有力手段。光分开并不能立刻消除这种宽松倾向——评估器本身也是 LLM，天生倾向于对 LLM 产出宽容。但把评估器单独调优、让它保持怀疑态度，远比让生成器对自己的作品保持批判眼光容易得多。而且一旦有了外部反馈，生成器就有了具体的改进目标。
前端设计：把主观质量变成可打分的维度
我从前端设计开始实验，因为自我评估问题在这里最为明显。没有任何干预时，Claude 倾向于生成安全、可预期的布局——技术上能用，但视觉上毫无亮点。
设计这套前端设计 harness 有两个关键洞察。第一，虽然审美无法完全化约为分数，个人口味也永远存在差异，但可以用编码了设计原则和偏好的评判标准来提升它。“这个设计美吗？“很难一致回答，但”这个设计符合我们的好设计原则吗？“给了 Claude 具体的评判依据。第二，把前端生成和前端评分分开，可以构建出一个驱动生成器走向更强输出的反馈循环。
基于此，我写了四个评判标准，同时给生成器和评估器 agent 用：
- 设计质量：设计是否像一个整体，而不是零件的堆砌？出色的作品意味着颜色、字体、布局、图像等细节组合在一起，形成独特的氛围和身份认同。
- 原创性：能否看出自定义决策，还是清一色模板布局、库默认值和 AI 生成套路？人类设计师应该能认出刻意的创意选择。未经修改的库组件，或者 AI 生成的典型特征（比如白色卡片上铺紫色渐变）都是扣分项。
- 工艺：技术执行层面：字体层级、间距一致性、色彩和谐度、对比度。这是能力检查，不是创意检查。大多数合理实现默认能过；挂科意味着基础功能性问题。
- 功能性：独立于审美的可用性。用户能否理解界面的用途，找到主要操作，在不靠猜测的情况下完成任务？
我把设计质量和原创性的权重放得比工艺和功能性更高。Claude 在工艺和功能性上本来就表现不错，所需的技术能力对模型来说是自然的。但在设计和原创性上，Claude 的产出往往最多算平庸。这些标准明确惩罚了高度模板化的”AI 糊弄”模式，通过加大设计和原创性的权重，推动模型敢于承担更多审美风险。
我用 few-shot 样例加详细评分细项来校准评估器，确保它的判断与我的偏好对齐，并减少多次迭代间的分数漂移。
整套循环基于 Claude Agent SDK 构建，编排相对直接。生成器 agent 先根据用户 prompt 创建 HTML/CSS/JS 前端，评估器拿到 Playwright MCP，可以直接与运行中的页面交互，在给每个维度打分、写详细批评前先自行浏览页面。实践中，评估器会自主在页面上操作，截图反复研究实现细节，再给出评分。这份反馈会作为下一次迭代的输入传回生成器。每次生成跑 5 到 15 轮迭代，随着生成器响应评估器的批评，通常会朝着越来越有辨识度的方向演进。因为评估器是真实浏览页面而不是对静态截图打分，每个周期都需要实打实的时间。完整运行最长可达四小时。我还让生成器在每次评估后做一个策略决策：如果分数趋势良好就精炼当前方向，如果路子走不通就彻底切换美学风格。
多次运行中，评估器的打分在迭代中持续提升，然后趋于平台期，且始终还有上升空间。有些生成逐步精炼，有些则在迭代间出现剧烈的美学转向。
评判标准的措辞引导了生成器走向一些我没有完全预料到的方向。加入”最好的设计是博物馆级别”这样的表述后，设计呈现出特定的视觉收敛趋势，说明与标准相关联的 prompting 语言直接塑造了输出的风格。
虽然分数总体上随迭代提升，但并不总是线性的。后期实现作为整体往往更好，但我经常发现自己更偏爱某个中间迭代而不是最后一版。实现复杂度也随着轮次增加，生成器会响应评估器的反馈去尝试更大胆的方案。即便在第一次迭代，产出就已明显优于没有任何 prompting 的基线，说明标准本身和关联的语言就已经在把模型从通用默认值上推开，之后的评估器反馈再进一步推动迭代精炼。
有一个值得记录的案例：我让模型创建一个荷兰艺术博物馆的网站。到第九次迭代，它生成了一个干净的深色调博物馆着陆页，视觉上很精致，但基本符合我的预期。然后在第十轮，它完全推翻了这个方向，把网站重新构想成一个空间体验：一个用 CSS 透视法渲染的 3D 房间，棋盘格地面，艺术品自由悬挂在墙上，用门道导航在展馆房间之间穿行，而不是滚动或点击。这种创意跳跃是我之前从未在单次生成中见过的。
扩展到全栈 coding
有了这些发现，我把这套受 GAN 启发的模式应用到全栈开发。生成器-评估器循环天然对应软件开发生命周期——代码审查和 QA 在结构上扮演着和设计评估器相同的角色。
架构
在早期的长时间运行 harness 中，我们用初始化 agent、逐功能工作的 coding agent、以及 session 间的 context reset 解决了多 session 连贯 coding 的问题。Context reset 是关键突破：那套 harness 用的是 Sonnet 4.5，它的”context 焦虑”倾向前面提过。设计一套能在 context reset 间保持良好运转的 harness，是让模型保持专注的关键。Opus 4.5 基本上自己消除了这个行为，所以这套 harness 里我可以完全去掉 context reset。所有 agent 在整个构建过程中作为一个连续 session 运行，Claude Agent SDK 的自动 compaction 处理上下文增长。
在原有 harness 基础上，我搭建了一个三 agent 系统，每个 agent 针对我在之前运行中观察到的特定薄弱环节：
Planner：之前的长时间运行 harness 要求用户预先提供详细 spec。我想把这个步骤自动化，于是创建了一个 planner agent，接收一段 1-4 句话的 prompt，展开成完整的产品 spec。我提示它要有雄心壮志，同时聚焦于产品背景和高层技术设计，而不是详细的技术实现。这样做的原因是：如果 planner 试图预先指定细粒度的技术细节并搞错了，spec 里的错误会层层传导到下游实现。约束 agent 要交付什么成果，让它们自己在过程中找到路径，似乎更明智。我还让 planner 在产品 spec 中寻找机会融入 AI 功能。（附录有示例。）
Generator：早期 harness 里一次实现一个功能的方式在范围管理上效果不错。我在这里延续了类似的思路，让 generator 按 sprint 工作，每次从 spec 中取一个功能。每个 sprint 使用 React、Vite、FastAPI 和 SQLite（后来换成 PostgreSQL）栈来实现应用，generator 被要求在每个 sprint 结束时自我评估，然后移交给 QA。它还有 git 做版本控制。
Evaluator：早期 harness 的应用通常看起来很亮眼，但真正使用时还是会暴露真实 bug。为了捕获这些问题，evaluator 使用 Playwright MCP 像真实用户一样点遍运行中的应用，测试 UI 功能、API 端点和数据库状态。然后对每个 sprint 按照它发现的 bug 以及一套类似前端实验的标准打分——这里的标准适配到了产品深度、功能性、视觉设计和代码质量。每个标准都有硬性阈值，任何一项低于阈值，该 sprint 就失败，generator 会收到详细的反馈说明出了什么问题。
每个 sprint 开始前，generator 和 evaluator 会协商一份 sprint 合约：在写任何代码之前先就这块工作”完成”意味着什么达成共识。这样做是因为产品 spec 是刻意写得比较高层的，我想要一个步骤来弥合用户故事和可测试实现之间的差距。Generator 提出它要构建什么、如何验证成功，evaluator 审查这个提案，确保 generator 在做正确的事。两者来回迭代直到达成一致。
Agent 之间通过文件通信：一个 agent 写一个文件，另一个读取并在该文件中回应，或者写一个新文件让前者读取。Generator 再基于约定好的合约开始构建，然后移交给 QA。这样既保证了工作忠于 spec，又避免了过早细化实现细节。
运行 harness
第一版 harness 我用的是 Claude Opus 4.5，对同样的用户 prompt 分别跑完整 harness 和单 agent 系统做对比。Opus 4.5 是我开始这些实验时最好的 coding 模型。
我用以下 prompt 生成了一个复古游戏制作工具：
Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.
下表列出了 harness 类型、运行时长和总成本：
| Harness | 时长 | 费用 |
|---|---|---|
| 单 agent | 20 分钟 | $9 |
| 完整 harness | 6 小时 | $200 |
Harness 贵了 20 倍以上，但输出质量的差距一目了然。
我预期的是一个可以搭建关卡和组件（精灵、实体、地砖布局）然后点击播放实际进行游戏的界面。先打开单 agent 的产出，初始界面看起来符合预期。
但越点越发现问题。布局空间浪费严重，固定高度的面板让大部分视口空着。操作流程很僵硬——尝试填充关卡时提示要先创建精灵和实体，但界面上没有任何引导。更要命的是，游戏本身坏了。实体出现在屏幕上，但没有任何东西响应输入。看代码才发现实体定义和游戏运行时之间的连接坏掉了，而界面上没有任何提示。
评估完单 agent 的结果，我转向 harness 的运行结果。这次从同一句话 prompt 出发，但 planner 步骤把它展开成了横跨十个 sprint 的 16 个功能 spec，远超单 agent 的尝试范围。除了核心编辑器和游玩模式，spec 还包括精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及带分享链接的游戏导出。我给了 planner 我们 frontend design skill 的访问权限，它读取后作为 spec 的一部分为应用创建了一套视觉设计语言。每个 sprint，generator 和 evaluator 会协商一份合约，定义该 sprint 的具体实现细节，以及用来验证完成的可测试行为。
应用立刻显示出比单 agent 更多的打磨痕迹：canvas 铺满整个视口，面板大小合理，界面有一致的视觉身份，对应 spec 中的设计方向。单 agent 版本的一些笨拙之处依然存在——工作流程仍然没有提示用户应该先创建精灵和实体再填充关卡，我还是靠摸索才搞清楚。这看起来是底层模型产品直觉的不足，而不是 harness 设计应该解决的问题，不过确实指出了一个可以在 harness 内部有针对性迭代来进一步提升输出质量的地方。
浏览各个编辑器时，新版相对单 agent 的优势越来越明显。精灵编辑器更丰富、功能更完整，工具面板更干净，颜色选择器更好用，缩放控件更易用。
因为我让 planner 在 spec 里融入 AI 功能，应用内置了一个 Claude 集成，可以通过提示词生成游戏的各个部分，大幅加快了工作流程。
最大的差别在游玩模式。我真的可以移动实体、玩游戏了。物理引擎有些粗糙——角色跳上平台后会和它重叠，感觉不对——但核心功能是通的，单 agent 版本做不到这点。移动了一会儿后，AI 关卡构建确实有些局限：有一堵大墙跳不过去，就卡住了。这说明 harness 还有一些常识性改进和边界情况需要处理。
看日志会发现，evaluator 在持续把实现拉回 spec 的轨道。每个 sprint，它会逐项遍历 sprint 合约的测试标准，用 Playwright 操作运行中的应用，对任何偏离预期行为的地方提交 bug。合约非常细——仅 Sprint 3 就有 27 条覆盖关卡编辑器的标准，evaluator 的发现足够具体，不需要额外调查就能直接上手修复。下表列出了 evaluator 发现的几个问题示例：
| 合约标准 | Evaluator 发现 |
|---|---|
| 矩形填充工具支持点击拖拽，用所选地砖填充矩形区域 | FAIL — 工具只在拖拽起点/终点放置地砖，没有填充整个区域。fillRectangle 函数存在但在 mouseUp 时没有正确触发。 |
| 用户可以选择并删除已放置的实体生成点 | FAIL — LevelEditor.tsx:892 的 Delete 键处理器要求同时设置 selection 和 selectedEntityId，但点击实体只会设置 selectedEntityId。条件应改为 selection || (selectedEntityId && activeLayer === 'entity')。 |
| 用户可以通过 API 重新排序动画帧 | FAIL — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 把 reorder 匹配为整数 frame_id 并返回 422：“unable to parse string as an integer”。 |
让 evaluator 达到这个水平需要下功夫。开箱即用的 Claude 是个糟糕的 QA agent。在早期运行中，我看它发现了合理的问题，然后说服自己这不是什么大事，批准了工作。它测试也倾向于浮于表面，不会深挖边界情况，所以更隐蔽的 bug 经常漏网。调优的方法是读 evaluator 的日志，找到它的判断与我的判断有分歧的地方，然后更新 QA 的 prompt 来解决这些问题。经过好几轮开发循环，evaluator 的评判才达到我认为合理的水平。即便如此，harness 产出依然体现了模型 QA 能力的极限：小的布局问题、一些交互感觉不够直觉，以及 evaluator 没有深入测试的嵌套更深功能里的未发现 bug。显然还有更多验证空间可以靠进一步调优来挖掘。但和单 agent 版本（核心功能直接坏掉）相比，提升是显而易见的。
迭代 harness
第一批 harness 结果令人鼓舞，但它又臃肿、又慢、又贵。合理的下一步是找到在不降低性能的前提下简化 harness 的方法。这部分是常识，部分来自一个更普遍的原则：harness 里的每个组件都编码了一个关于模型独立能力边界的假设，这些假设值得压力测试——既因为它们可能本来就是错的，也因为随着模型改进，它们可能迅速过时。我们的博文 Building Effective Agents 把这个底层思路表述为”找到尽可能简单的解决方案，只在必要时增加复杂度”——这个模式在维护 agent harness 的人中反复出现。
第一次简化尝试，我激进地把 harness 砍了回去，试了几个新想法，但无法复现原版的表现。而且很难分辨 harness 设计里哪些部分真的是承重墙，以哪种方式承重。基于这段经历，我转向更系统的方法：每次只去掉一个组件，观察对最终结果的影响。
在这些迭代周期进行的同时，我们也发布了 Opus 4.6，这进一步推动了降低 harness 复杂度的动力。有充分理由预期 4.6 比 4.5 需要更少的脚手架。从我们的发布博文中可以看到：“[Opus 4.6] 计划更周全，能持续更长时间的 agentic 任务，在更大规模的代码库里运行更可靠，代码审查和 debug 能力更强，能更好地发现自己的错误。“它在长 context 检索上也大幅提升。这些恰好都是 harness 此前为了弥补而搭建的能力。
去掉 sprint 结构
我先尝试完全去掉 sprint 结构。Sprint 机制帮助把工作分解成模型可以连贯操作的小块。鉴于 Opus 4.6 的改进，有充分理由相信模型可以原生处理这项工作，不需要这种分解。
Planner 和 evaluator 我都保留了，因为它们各自依然明显在贡献价值。没有 planner，generator 会低估范围：拿到原始 prompt 就开始构建，不先 spec 出工作内容，最终产出的应用功能比 planner 扩展后的版本少得多。
去掉 sprint 结构后，我把 evaluator 改为在整个运行结束时做单次评估，而不是每个 sprint 打一次分。由于模型能力更强，evaluator 对于某些运行的重要性也发生了变化，取决于任务在模型独立能力边界上的位置。在 4.5 上，这条边界很近：我们的构建处于 generator 独立能做好的边缘，evaluator 能在整个构建过程中发现有实质意义的问题。在 4.6 上，模型的原始能力提升了，边界也向外移动。以前需要 evaluator 把关才能实现连贯的任务，现在 generator 经常能独立处理好，对于这些任务边界内的部分，evaluator 就变成了不必要的开销。但对于依然处在 generator 能力边缘的构建部分，evaluator 依然能带来真实提升。
实际含义是：evaluator 不是一个固定的是或否的决策。当任务处于当前模型独立能可靠完成的能力边界之外时，它才值得付出成本。
在结构简化的同时，我还加了 prompting 来改善 harness 把 AI 功能融入每个应用的方式——具体是让 generator 构建一个真正的 agent，通过工具驱动应用自身的功能。这需要相当的迭代，因为相关知识足够新，Claude 的训练数据覆盖很薄。但经过足够多的调优，generator 已经能正确构建 agent 了。
更新后 harness 的结果
为了测试更新后的 harness，我用下面这个 prompt 生成了一个数字音频工作站（DAW），即用于编曲、录音和混音的音乐制作程序：
Build a fully featured DAW in the browser using the Web Audio API.
这次运行依然耗时且昂贵，约 4 小时，token 成本 $124。
大部分时间花在了 builder 上，它连贯运行了超过两小时，不再需要 Opus 4.5 那种 sprint 分解。
| Agent & 阶段 | 时长 | 费用 |
|---|---|---|
| Planner | 4.7 分钟 | $0.46 |
| Build（第 1 轮） | 2 小时 7 分钟 | $71.08 |
| QA（第 1 轮） | 8.8 分钟 | $3.24 |
| Build（第 2 轮） | 1 小时 2 分钟 | $36.89 |
| QA（第 2 轮） | 6.8 分钟 | $3.09 |
| Build（第 3 轮） | 10.9 分钟 | $5.88 |
| QA（第 3 轮） | 9.6 分钟 | $4.06 |
| V2 Harness 合计 | 3 小时 50 分钟 | $124.70 |
和之前一样，planner 把一行 prompt 展开成完整 spec。从日志看，generator 在规划应用和 agent 设计、接入 agent、移交 QA 前自测等方面表现不错。
但 QA agent 依然抓到了真实的问题。第一轮反馈中，它写道：
这是一个很强的应用，设计还原度好，AI agent 扎实，后端也不错。主要失分点在功能完整性——虽然应用看起来令人印象深刻，AI 集成效果也好，但几个核心 DAW 功能只是展示用，缺乏交互深度：clip 无法在时间轴上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（均衡器曲线、压缩器仪表）。这些不是边缘情况——它们是让 DAW 真正可用的核心交互，而且 spec 明确要求了这些功能。
第二轮反馈中，它再次发现了几个功能缺口：
剩余问题：
- 录音功能依然只是 stub（按钮可以切换，但没有麦克风捕获）
- 未实现 clip 边缘拖拽调整大小和 clip 分割
- 效果可视化是数字滑块，不是图形化的（没有均衡器曲线）
Generator 靠自己还是会漏掉细节或 stub 掉功能，QA 在发现这些最后一公里问题、让 generator 修复上依然在贡献价值。
基于 prompt，我预期是一个可以创作旋律、和声、鼓点，编排成一首歌，并在集成 agent 帮助下完成制作的程序。
应用距离专业音乐制作软件还很远，agent 的编曲能力显然还有很大提升空间。而且 Claude 实际上听不到声音，这让 QA 反馈循环在音乐品味层面效果大打折扣。
但最终的应用具备了功能性音乐制作程序的所有核心组件：一个在浏览器中运行的可用编排视图、调音台和传输控制器。更进一步，我能够完全通过 prompting 拼出一小段歌曲：agent 设置了速度和调性，铺了旋律，构建了鼓轨，调整了调音台电平，加了混响。歌曲创作的核心原语都在，agent 可以自主驱动这些原语，用工具从头到尾完成一个简单的制作。也许说它还不够完美——但确实走在正确的路上。
接下来怎么走
随着模型持续改进，我们大致可以预期它们能处理更长时间、更复杂的任务。在某些情况下，这意味着围绕模型的脚手架会随时间变得越来越不重要，开发者可以等下一个模型出来，看某些问题是否自然而然地解决了。另一方面，模型越强，用 harness 实现远超模型基线能力的复杂任务的空间也就越大。
基于此，这项工作有几个值得带走的教训。始终值得花时间用你正在构建的模型做实验，读它在真实问题上的 trace，调优它的表现以达到你想要的结果。处理更复杂的任务时，有时可以通过拆解任务、对每个方面应用专门的 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 在文章写作上的帮助。
附录
Planner agent 生成的示例规划：
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
...