这篇回答的问题是：怎么给长时自主编程的 Agent 搭脚手架，让它跑完数小时的真实项目而不跑偏。

最值得拿走的是三件套：把干活的 Agent 与打分的 Agent 分离，因为模型自评天然偏宽容；用带硬阈值的「冲刺契约」在写代码前定义什么叫做完；让评估器通过 Playwright 实际走查运行中的应用，而不是给静态截图打分。最易误用的是把 harness 当固定资产——文中明示每个组件都编码了一条「模型做不到」的假设，模型一升级就要逐件拆解验证，把不再承重的部分删掉。

相比提示词技巧类内容，这篇把 Agent 工程推向了系统设计层：上下文焦虑、自评宽容、验收契约都是一线跑长任务才会暴露的问题。中文读者可对照交付场景：把验收标准前置成可测试契约的做法，与 FDE 面向客户的项目验收设计同构，值得直接借进国内团队流程。

给你现有的一个自动化流程列一份「组件-假设」清单，标出哪些部件在新模型下已经不再承重。

—— FDEChina编辑部 · 架构师视角

过去几个月，我一直在攻坚两个相互关联的问题：让 Claude 产出高质量的前端设计，以及让它在没有人工干预的情况下构建完整应用。这项工作源于我们更早的前端设计技能（frontend design skill）与长时运行编程 Agent harness——通过提示工程与 harness 设计，我和同事们曾把 Claude 的表现大幅抬到基线之上，但两者最终都撞上了天花板。

为了突破，我寻找能在两个迥然不同的领域都成立的新型 AI 工程方法——一个由主观品味定义，另一个由可验证的正确性与可用性定义。我从生成对抗网络（GAN）汲取灵感，设计了一个带生成器与评估器的多 Agent 结构。打造一个能可靠评分——并且有品味——的评估器，意味着先要发展出一套标准，把「这个设计好不好？」这类主观判断转化为具体、可打分的条目。

随后我把这些技巧迁移到长时自主编程上，沿用了早期 harness 工作的两条经验：把构建分解成可驾驭的块，以及用结构化产物（artifact）在会话之间交接上下文。最终成果是一个三 Agent 架构——规划器（planner）、生成器（generator）、评估器（evaluator）——在数小时的自主编码会话中产出了功能丰富的全栈应用。

为什么朴素的实现不够用

我们此前已经证明，harness 设计对长时 Agent 化编程的效果有实质影响。在更早的一次实验里，我们用一个初始化 Agent 把产品规格分解成任务清单，再用一个编码 Agent 一次实现一个功能，并在会话之间交接产物以延续上下文。更广的开发者社区也收敛到了类似洞见，比如「Ralph Wiggum」方法，用钩子或脚本让 Agent 保持在持续的迭代循环里。

但仍有一些问题顽固存在。面对更复杂的任务，Agent 随着时间推移仍容易脱轨。在拆解这个问题时，我们观察到这类任务执行中两种常见的失败模式。

第一种是：随着上下文窗口被填满，模型在冗长任务上会逐渐失去连贯性（参见我们的《上下文工程》一文）。一些模型还表现出「上下文焦虑（context anxiety）」——在接近它自认为的上下文极限时，开始过早收尾。上下文重置（context reset）——彻底清空上下文窗口、换一个全新的 Agent，再配合一份结构化交接物携带前一个 Agent 的状态与后续步骤——能同时解决这两个问题。

这不同于压缩（compaction）：压缩是把对话前段就地摘要，让同一个 Agent 带着缩短的历史继续干。压缩保留了连续性，却没有给 Agent 一张白纸，所以上下文焦虑仍可能残留。重置提供了干净状态，代价是交接产物必须携带足够的状态，让下一个 Agent 顺利接手。在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑强到仅靠压缩无法支撑强劲的长任务表现，于是上下文重置成了 harness 设计的必需品。这解决了核心问题，但给每次 harness 运行增加了编排复杂度、token 开销与延迟。

第二个问题我们此前未曾处理：自我评估。让 Agent 评价自己产出的工作时，它倾向于自信地夸赞——即便在人看来质量明显平平。这个问题在主观任务（如设计）上尤其突出，因为那里没有类似可验证软件测试这样的二元判据。一个布局「精致」还是「平庸」是主观判断，而 Agent 在给自己的作品打分时会稳定地偏向好评。

然而，即便在有可验证结果的任务上，Agent 有时也会表现出糟糕的判断，拖累任务完成的质量。把「干活的 Agent」和「打分的 Agent」分开，被证明是解决此问题的有力杠杆。这种分离本身并不能立刻消除宽容倾向——评估器仍是一个倾向于善待 LLM 产出的 LLM。但把一个独立评估器调教得挑剔，远比让生成器批评自己的作品容易得多；而一旦外部反馈存在，生成器就有了可以具体迭代的靶子。

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

我从前端设计开始实验，因为自我评估问题在这里最刺眼。缺乏任何干预时，Claude 通常会滑向安全、可预测的布局——技术上能用，视觉上毫无记忆点。

两个洞见塑造了我为前端设计打造的 harness。第一，美学无法被完全约化成分数——个体品味永远各异——但可以借助编码了设计原则与偏好的评分标准来改进。「这个设计美吗？」难以稳定回答，但「这是否遵循了我们对好设计的原则？」给了 Claude 具体的打分依据。第二，把前端生成与前端评分分离，我们就能造出一个把生成器推向更强输出的反馈回路。

带着这两点，我写了四条评分标准，同时写进生成器与评估器的提示里：

  • 设计质量：设计是否像一个连贯的整体，而不是零件的堆砌？这里的强表现意味着色彩、字体、布局、图像等细节共同营造出独特的气质与身份。
  • 原创性：有没有自定义决策的证据，还是模板布局、库默认值和 AI 生成的套路？人类设计师应当能识别出有意的创作选择。未经改造的现成组件——或「白卡片上盖紫色渐变」这类 AI 生成的标志性痕迹——在此不合格。
  • 工艺（craft）：技术执行——字体层级、间距一致性、色彩和谐度、对比度。这是能力检查而非创造力检查。多数像样的实现默认就能过关；不及格意味着基本功垮了。
  • 功能性：独立于美学的可用性。用户能否理解界面是干什么的、找到主操作、不靠猜就完成任务？

我把设计质量与原创性的权重放在工艺与功能性之上。Claude 默认在工艺与功能性上得分就不错，所需的技术能力模型信手拈来；但在设计与原创性上，Claude 的产出常常乏善可陈。这些标准明确惩罚高度同质化的「AI slop」模式，并通过加大设计与原创性的权重，推动模型进行更多美学冒险。

我用带详细分数拆解的少样本示例（few-shot）校准评估器。这确保了评估器的判断与我的偏好对齐，也减少了跨迭代的分数漂移。

我基于 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 的自动压缩处理过程中的上下文增长。

在这项工作中，我在原 harness 的地基上搭了一个三 Agent 系统，每个 Agent 对准我在此前运行中观察到的某个具体短板。系统包含以下 Agent 角色：

  • 规划器：此前的长时 harness 要求用户预先提供详细规格。我想把这一步自动化，于是造了一个规划器 Agent，把一条 1-4 句话的简单提示扩写成完整的产品规格。我提示它对范围保持雄心，并聚焦产品语境与高层技术设计，而非细粒度的技术实现。这样强调是担心：如果规划器试图预先指定颗粒度极细的技术细节并出了错，规格里的错误会级联进下游实现。更聪明的做法是约束「要交付什么」，让 Agent 在干活时自己找路。我还请规划器在产品规格中寻找织入 AI 功能的机会。（示例见文末附录。）
  • 生成器：早期 harness「一次一个功能」的思路对范围管理行之有效，我在这里沿用类似模式，指示生成器以冲刺（sprint）方式工作，从规格中一次领取一个功能。每个冲刺用 React、Vite、FastAPI 与 SQLite（后来是 PostgreSQL）的技术栈实现应用，生成器被要求在每个冲刺结束时先自评，再交接给 QA。它也有 git 做版本控制。
  • 评估器：早期 harness 产出的应用常常看着惊艳，但你真去用就会发现实打实的 bug。为了抓住这些，评估器用 Playwright MCP 像用户一样在运行中的应用里点击走查，测试 UI 功能、API 端点和数据库状态。然后它对照自己发现的 bug 和一组参照前端实验改造的标准给每个冲刺打分，覆盖产品深度、功能性、视觉设计与代码质量。每条标准都有硬性阈值，任何一条低于阈值，该冲刺即判失败，生成器会收到关于问题所在的详细反馈。

每个冲刺开始前，生成器与评估器要协商一份「冲刺契约（sprint contract）」：在写任何代码之前，先就这一块工作「什么叫做完」达成一致。它存在的原因是产品规格有意保持高层，我需要一步来弥合用户故事与可测试实现之间的鸿沟。生成器提出它要建什么、如何验证成功，评估器审这份提案，确保生成器在建正确的东西。两者迭代直到达成一致。

通信通过文件进行：一个 Agent 写一个文件，另一个 Agent 读取后在该文件内或用新文件回应，前一个 Agent 再读取。生成器随后按商定的契约构建，再把工作交给 QA。这让工作忠于规格，又不过早过度指定实现。

运行这个 harness

在这个 harness 的第一版里，我用了 Claude Opus 4.5，把同一条用户提示分别跑完整 harness 和单 Agent 系统做对比。选 Opus 4.5 是因为它是我开始这些实验时我们最强的编程模型。

我写了下面这条提示来生成一个复古像素游戏制作器：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 运行的产出，初始应用看起来符合预期。

然而随着我点击深入，问题开始浮现。布局浪费空间，固定高度的面板让视口大部分空着。工作流很僵硬：想填充关卡时，它提示我先创建精灵和实体，但 UI 里没有任何东西引导我走这个顺序。更要命的是，游戏本身是坏的。我的实体出现在屏幕上，但对输入毫无响应。深挖代码后发现，实体定义与游戏运行时之间的接线断了，而表面上完全看不出断在哪。

评完单 Agent 运行，我把注意力转向 harness 运行。它同样从那句一句话提示出发，但规划步骤把提示扩写成了一份横跨十个冲刺、16 个功能的规格，远超单 Agent 运行的尝试范围。除了核心编辑器与游玩模式，规格还包括精灵动画系统、行为模板、音效与音乐、一个 AI 辅助的精灵生成器与关卡设计器，以及带分享链接的游戏导出。我给规划器开放了我们的前端设计技能，它读取后为应用创造了一套视觉设计语言作为规格的一部分。每个冲刺，生成器与评估器协商出一份契约，定义该冲刺的具体实现细节与用于验证完成的可测试行为。

这个应用立刻显出比单 Agent 运行更多的打磨与顺滑。画布铺满视口、面板尺寸合理、界面有一套贯穿始终的视觉身份，与规格中的设计方向一致。单 Agent 运行里的一些笨拙仍然存在——工作流依然没有明示「先建精灵和实体、再填充关卡」，我得自己摸索出来。这更像基座模型产品直觉的缺口，而非 harness 设计要解决的问题，不过它确实指出了一处可以在 harness 内做定向迭代、进一步提升产出质量的地方。

深入各个编辑器，新运行相对单 Agent 的优势愈发明显。精灵编辑器更丰富、功能更全：更干净的工具面板、更好用的取色器、更顺手的缩放控制。

因为我要求规划器在规格里织入 AI 功能，应用还自带了一个内置的 Claude 集成，让我可以用提示生成游戏的各个部分。这显著加快了工作流。

最大的差异在游玩模式。我真的能操控我的实体、真正玩上这个游戏。物理有些毛边——我的角色跳上平台后与平台重叠，直觉上不对——但核心机制能跑，这是单 Agent 运行没能做到的。玩了一阵后，我也撞上了 AI 搭关卡的一些局限：有一堵很高的墙我跳不过去，于是卡关。这提示还有一些常识性改进与边界情况，是 harness 可以继续打磨的。

翻阅日志可以清楚看到，评估器把实现一直按在规格上。每个冲刺，它逐条走查冲刺契约的测试标准，通过 Playwright 演练运行中的应用，对任何偏离预期行为的地方提交 bug。契约非常细——单是 Sprint 3 就有 27 条标准覆盖关卡编辑器——评估器的发现具体到无需额外调查即可动手。下表是评估器发现的几个问题示例：

契约标准 评估器发现
矩形填充工具支持点击拖拽，用选定瓦片填充矩形区域 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.”

让评估器达到这个水准花了不少功夫。开箱即用的 Claude 是个糟糕的 QA Agent。早期运行中，我看着它识别出真问题，然后自己说服自己「这不算大事」，照样批准通过。它还倾向于浅尝辄止地测试，不去探边界情况，于是更隐蔽的 bug 常常漏网。调教循环是：读评估器的日志，找出它的判断与我不一致的地方，更新 QA 提示来修正这些问题。经过几轮这样的开发循环，评估器的打分才达到我觉得合理的程度。即便如此，harness 产出依然暴露了模型 QA 能力的边界：小的布局问题、一些交互不够直觉、以及评估器未充分走查的深层嵌套功能里未发现的 bug。显然还有验证余量可以靠进一步调教挖掘。但对比单 Agent 运行——应用的核心功能干脆不能跑——提升是显而易见的。

迭代这个 harness

第一组 harness 结果令人鼓舞，但也笨重、缓慢、昂贵。顺理成章的下一步，是在不损伤性能的前提下简化 harness。这一半是常识，一半源自一条更普遍的原则：harness 中的每个组件都编码了一条「模型自己做不到某事」的假设，这些假设值得反复压力测试——既因为它们可能本来就错了，也因为随着模型进步它们会迅速过时。我们的博客文章《Building Effective Agents》把这个底层思想表述为「找到尽可能简单的方案，只在需要时增加复杂度」，对任何维护 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）——一个用于作曲、录音与混音的音乐制作程序：Build a fully featured DAW in the browser using the Web Audio API.

这轮运行依然漫长昂贵：约 4 小时、124 美元的 token 成本。

大部分时间花在构建者身上——它在没有 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 以完成超出模型基线能力的复杂任务的空间反而越大。

基于这一点，有几条值得带走的经验。拿你正在构建所用的模型做实验、阅读它在真实问题上的 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 对本文成稿的帮助。

附录

规划器 Agent 生成的规格示例（原文此处即为节选）：

RetroForge —— 2D 复古游戏制作器

概述：RetroForge 是一个基于网页的创作工作室，用于设计与构建 2D 复古风格的电子游戏。它把经典 8-bit 与 16-bit 游戏美学的怀旧魅力与现代、直观的编辑工具结合在一起——让从爱好者到独立开发者的任何人，都能不写传统代码就把游戏点子变成现实。

平台提供四个集成的创作模块：用于设计游戏世界的瓦片关卡编辑器、用于制作视觉资产的像素画精灵编辑器、用于定义游戏逻辑的可视化实体行为系统，以及用于实时试玩的即时可玩测试模式。通过全程织入 AI 辅助（由 Claude 驱动），RetroForge 加速创作过程——帮助用户通过自然语言交互生成精灵、设计关卡、配置行为。

功能 1：项目仪表盘与管理——项目仪表盘是 RetroForge 中所有创作工作的主基地。用户需要一种清晰、有条理的方式来管理游戏项目：新建项目、回到进行中的作品、一眼看清每个项目包含什么。
用户故事：作为用户，我希望：
– 创建一个带名称与描述的新游戏项目，以便开始设计我的游戏
– 所有现有项目以可视化卡片展示，含项目名、最近修改日期与缩略图预览，便于快速找到并继续我的作品
– 打开任意项目，进入完整的游戏编辑器工作区
– 删除不再需要的项目，带确认对话框以防误触
– 复制现有项目作为新游戏的起点，复用此前的成果
项目数据模型：每个项目包含项目元数据（名称、描述、创建/修改时间戳）、画布设置（分辨率：如 256×224、320×240 或 160×144）、瓦片尺寸配置（8×8、16×16 或 32×32 像素）、调色板选择，以及全部关联的精灵、瓦片集、关卡与实体定义。……

延伸阅读：关于 Agent 系统设计与 AI 工程方法，参见站内 Agent 主题、AI Coding 主题、FDE 项目生命周期 与 实践指南。

本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。