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