能生成应用，不等于能交付应用
当任务跨越多小时、涉及主观体验时，生成者与评估者必须分工，并先把“完成”协商成可验证的契约。
文章目录
让一个 Agent 用一句话生成应用，通常不难。难的是打开它之后，用户能否完成任务，页面是否有明确取舍，关键流程是否真的跑通。前者是生成能力，后者才是交付能力。
Harness design for long-running application development 提供了一个有价值的分工：planner 负责扩展意图，generator 负责实施，evaluator 独立检查结果。它解决的并非“多 Agent 更酷”，而是生成者不适合给自己当裁判。
原文不是停在架构图，而是跑了对照#
在前端实验中，Anthropic 让生成 Agent 产出页面，再让 evaluator 用浏览器工具实际操作、截图、按明确标准写批评。每次生成会经历 5 到 15 轮“生成—评估—修复”，一轮完整运行可持续到约四小时。作者观察到，评分总体会上升，但并不总是线性：有时中间版本比最后版本更符合偏好，后期也更容易因追求高分而增加实现复杂度。
他们随后把模式迁移到完整应用：planner 将一两句话的需求扩成产品规格；generator 按 sprint 实现；evaluator 用浏览器验证 UI、API 和数据库状态。文中同一个复古游戏编辑器任务里，单 Agent 版本运行 20 分钟、成本 9 美元；完整 harness 运行 6 小时、成本 200 美元。后者显著更完整，但也绝不意味着“多 Agent 总是更划算”。这个对照的价值是把成本、时长和质量放到同一张决策桌上。
自评为什么不够可靠#
一个完成工作的 Agent 往往知道自己做了哪些选择，也容易把“我完成了计划”误判为“用户得到了价值”。在界面和产品体验这类主观任务中，这个偏差更强：页面可以无报错，却依然像模板、浪费空间、让人找不到下一步。
因此，交付需要把两个角色拆开：
| 角色 | 它的责任 | 它不应该拥有的最终权力 |
|---|---|---|
| Planner | 将问题拆成范围、风险、里程碑 | 直接宣布功能完成 |
| Generator | 每次完成一个小的、可审查的改动 | 对自己作品给出最终评分 |
| Evaluator | 依据预设标准操作产品、指出缺口 | 静默重写作品并掩盖问题 |
| Human owner | 处理目标冲突与高风险取舍 | 逐行替 Agent 点击 |
独立 evaluator 也不天然客观；它仍可能宽容或偏好某种风格。关键是让它的标准可见、可校准、可被人挑战。
先把审美判断变成可讨论的标准#
“这个设计好不好”无法完全自动化，却可以被拆成更具体的问题。原文给出的设计质量、原创性、工艺和功能性四个维度，启发我把产品验收写成一张评分卡：
| 维度 | 要问的问题 | 可观察证据 |
|---|---|---|
| 任务清晰度 | 用户知道下一步做什么吗 | 首次任务完成率、迷失点 |
| 设计一致性 | 排版、间距、色彩是否服务于同一层级 | 截图审查、组件偏差 |
| 差异化 | 是否只是组件库默认拼接 | 关键视觉与交互的理由 |
| 功能正确性 | 主路径与异常路径都可用吗 | 端到端测试、实际操作记录 |
评分卡不是为了制造一个“美学总分”，而是迫使团队将反馈变成能引发下一轮动作的证据。
Sprint contract 是 Agent 交付的最小单元#
最实用的机制并不是更长的总计划，而是每个 sprint 开始前由 generator 与 evaluator 写清一份契约：这次做什么、不做什么、用什么证据证明完成、什么结果算失败。
例如“增加导出功能”过于模糊；“用户可导出当前筛选结果为 CSV，空结果会解释原因，下载文件字段与筛选一致，端到端用例覆盖三种筛选状态”才有可测试的边界。
契约让高层产品意图落到一个可以被验证的切片，也避免 Agent 为了看起来完成而偷偷扩张范围。
评估标准必须能区分“可运行”和“值得交付”#
原文在设计实验里使用四类标准：设计质量、原创性、工艺和功能性，并刻意把前两项权重放得更高，因为模型在工艺与功能上往往已经不差，却容易生成安全、模板化的界面。这个取舍很有启发性：评分器不只是发现 bug，它还把团队真正的偏好变成 generator 能据此迭代的反馈。
但这里有边界。审美无法被一个总分客观地消灭；evaluator 也会被示例、措辞和训练偏好塑形。因此评分应至少保留逐项理由、截图和可复现操作，而不是只保存“82 分”。当人工与 evaluator 持续在某个维度分歧时，问题可能不是模型不好，而是标准本身还没有被定义清楚。
反馈循环要有转向条件#
生成—评估—修复不是无限循环。每轮都应该记录：问题属于功能、体验、数据还是约束冲突；分数是提升还是停滞；继续细修是否还值得。
我会设置三个退出条件：
- 核心任务和风险门槛已通过，停止“为了更高分”继续加复杂度；
- 连续两轮没有改善，回到方案层而不是继续微调；
- 出现无法由 Agent 解决的产品取舍，升级给负责人。
这避免系统在局部指标上越做越漂亮，却偏离了原始用户任务。
用数据判断这套循环是否值得#
需要看的不是“跑了几轮”，而是：一次通过验收的功能比例、每轮反馈后缺陷的消失率、人工发现的漏检率、从需求到可用版本的时间，以及每个验证通过结果的总成本。
如果 evaluator 让返工下降，却使交付周期和成本失控，它需要被重设，而不是被神化。
来源与边界#
- 三角色架构、设计评价维度与 sprint contract 的事实来源是 Anthropic 的 Harness design for long-running application development。
- 本文的评分卡、退出条件和指标是我的产品设计建议，不是原文的通用结论。