正文
"Is this design beautiful?" is hard to answer consistently, but "does this follow our principles for good design?" gives Claude something concrete to grade against.
Grading criteria example
Given to both the generator and evaluator Prompt example
- Design quality: Does the design feel like a coherent whole rather than a collection of parts? Strong work here means the colors, typography, layout, imagery, and other details combine to create a distinct mood and identity.
- Originality: Is there evidence of custom decisions, or is this template layouts, library defaults, and AI-generated patterns? A human designer should recognize deliberate creative choices. Unmodified stock components—or telltale signs of AI generation like purple gradients over white cards—fail here.
- Craft: Technical execution: typography hierarchy, spacing consistency, color harmony, contrast ratios. This is a competence check rather than a creativity check. Most reasonable implementations do fine here by default; failing means broken fundamentals.
- Functionality: Usability independent of aesthetics. Can users understand what the interface does, find primary actions, and complete tasks without guessing?
要给Evaluator few-shot examples，便于模型学会明确的评判标准 calibrated the evaluator using few-shot examples with detailed score breakdowns.
Evaluator 常需要给Playwright MCP，让它能够操作界面
Evaluator的评分prompt很重要
评分标准里的文字，不只是评估规则，也会变成generator的设计方向。 比如 prompt 里写了：
the best designs are museum quality
意思是“最好的设计应该有博物馆级别的品质”。
这个短语会让模型偏向某种审美：
高级感艺术感克制展览感大留白精致排版强视觉氛围
久而久之，不同任务的输出可能都往这种风格靠拢。这就是文中说的 visual convergence，可以理解为“视觉收敛”。
Iterations也不是越多越好，到后面Implementation complexity会提高，generator 会 reaching for more ambitious solutions in response to the evaluator’s feedback
3个架构
Planner
Planner 的 prompt 应该遵循这些原则：
1. 从短需求扩展成完整产品规格
Planner 的输入通常只是 1–4 句话，输出应该是一份较完整的 product spec。
它要补全：
产品目标
目标用户
核心场景
主要功能
用户流程
高层架构
验收标准
2. 重点定义“做什么”，不要过度规定“怎么做”
Planner 应该约束交付物，而不是写死实现细节。
应该写：
用户可以创建、编辑、删除项目。
系统需要保存项目状态。
需要提供可测试的核心工作流。
不应该写：
创建 ProjectCard.tsx。
数据库必须有 name、created_at、updated_at 三个字段。
第一个 API 路由必须叫 /api/projects/create。
核心原则：
Planner defines deliverables, Generator decides implementation.
3. Scope 要有野心，但不能失控
Planner 不应该只规划一个 toy demo，而要把产品扩展到“像一个真实应用”。
但也不能无限加功能。
合适的方向是：
覆盖核心用户流程
补足必要功能模块
加入能体现产品完整度的高级功能
避免无关功能膨胀
4. 保持high level technical design
如果 Planner 提前写了错误的技术细节，Generator 可能会照着错方案实现，导致后面全错。
所以 Planner 应该保持在高层抽象：
概念级数据模型
高层技术设计
模块职责
验收行为
而不是低层实现：
具体文件结构
具体函数名
具体数据库字段
复杂算法细节
5. 给出清晰的验收标准
Planner 的输出要能被 Evaluator 测试。
例如不要只写：
实现一个好用的编辑器。
要写成：
用户可以创建新项目。
用户可以打开已有项目。
用户可以编辑内容并保存。
刷新页面后项目数据仍然存在。
这样 Generator 知道要做什么，Evaluator 也知道怎么测。
7. 输出结构要稳定，方便下游读取
Planner prompt 最好要求固定格式，例如：
1. Product Overview
2. Target Users
3. Core Workflows
4. Feature Modules
5. High-level Architecture
6. Conceptual Data Model
7. AI Features
8. Acceptance Criteria
9. Non-goals / Constraints
结构稳定，后面的 Generator 和 Evaluator 才容易引用。
Generator
按 spec 工作，不自行发明无关功能 一次只做一个 feature / sprint 每轮明确目标、实现范围和验收标准 完成后自我检查 提交前确保应用能运行 使用 git 保存稳定状态 把结果交给 Evaluator 测试
可以有PROJECT_STATE.md 追踪进度 完整 spec 说明总目标； PROJECT_STATE.md 说明做到哪里； QA_REPORT.md 说明哪里没过； git 记录代码历史。
Evaluator
Evaluator要有Playwright MCP能够操作界面。 并且每一个评分标准要有hard threshold 例如：
Product depth >= 7
Functionality >= 8
Visual design >= 7
Code quality >= 7
只要有一项低于阈值，这个 sprint 就失败。
在generator实际写代码之前， Generator和Evaluator会就当前的sprint讨论 sprint contract: agreeing on what "done" looked like for that chunk of work before any code was written. 定义完成标准
一般用文件沟通，generator先开始
Generator 写 SPRINT_CONTRACT.md
Evaluator 写 CONTRACT_REVIEW.md
Generator 修改 SPRINT_CONTRACT.md
Evaluator 标记 Approved
Generator 开始实现
Sprint contract的criteria 需要很细致，能够 specific enough to act on without extra investigation.
Iterate
Evaluator 容易太过宽容，Evaluator的prompt是需要不断迭代的
tuning loop 是怎么做的
作者的调优流程是：
读取 Evaluator 日志↓找出它判断不符合作者标准的地方↓修改 QA prompt↓重新跑↓继续观察日志
也就是说，不是一次写好 Evaluator prompt，而是像调测试策略一样迭代。
比如发现 Evaluator 太宽容，就加规则：
如果核心功能缺失，不允许 Pass。如果发现 bug，不要自我淡化。任何违反 acceptance criteria 的行为都必须记录为 FAIL。
发现它测试太浅，就加规则：
必须测试边界情况。必须测试刷新后的持久化。必须测试错误输入。必须验证 API 和数据库状态。
Iterating on the harness
重要原则
一个 harness 里的每个设计，其实都隐含一个判断：
模型自己做不好某件事，所以我要加一个组件帮它。
例如：
Planner：假设模型直接从短 prompt 开发会 under-scope。
Evaluator：假设模型无法可靠自我评估。
Sprint：假设模型无法一次处理完整大任务。
Context reset：假设模型长上下文会跑偏。
Playwright QA：假设只读代码无法发现运行时 bug。
所以组件不是越多越好。每加一个组件，都要问：
这个假设现在还成立吗？
当前模型还需要这个脚手架吗？
它带来的质量提升是否超过成本？
另一个重要原则
先找最简单可行方案，只在必要时增加复杂度。
放到 Agent harness 里，就是：
能用单 Agent 解决，就不要上多 Agent。
能用一次 QA 解决，就不要每个 sprint 都 QA。
能用 prompt 约束解决，就不要加复杂 orchestration。
能用模型原生能力解决，就不要保留旧脚手架。
复杂度必须有明确收益，否则就是负担。
Removing the sprint construct
Harness里面的组件不是永远必要，也不是永远没用。 取决于任务难度或者模型能力的提升 不同的组件都可能可以被删除
重要原则
The practical implication is that the evaluator is not a fixed yes-or-no decision. It is worth the cost when the task sits beyond what the current model does reliably solo.
一些重要原则
It is always good practice to experiment with the model you're building against, read its traces on realistic problems, and tune its performance to achieve your desired outcomes. When working on more complex tasks, there is sometimes headroom from decomposing the task and applying specialized agents to each aspect of the problem. And when a new model lands, it is generally good practice to re-examine a harness, stripping away pieces that are no longer load-bearing to performance and adding new pieces to achieve greater capability that may not have been possible before.