长时应用开发 Harness：把生成与验收拆开

先说结论

长任务最危险的不是模型写得慢，而是做到后面失去目标，或自己验自己时过度乐观。把“要做什么”“怎么实现”“是否真的可用”分成独立角色，并在动手前写出可测试契约，能把模糊产品愿望变成可迭代反馈。

原文解决什么

文章同时处理两类难题：主观的前端品味，以及需要数小时完成的全栈应用。单 Agent 容易生成安全但平庸的界面，长跑时又会提前收尾、漏做核心交互。作者先用生成者与评估者循环改善设计，再扩展成规划者、生成者、评估者三角色架构。

核心机制

• 规划者把短需求扩成产品范围，但停在用户故事与高层设计，不预先猜死具体实现。
• 生成者和评估者先协商“完成契约”：这轮交付什么、如何操作、什么算通过。
• 评估者通过真实页面、API 和数据状态做 QA，并把具体失败反馈给生成者；它与作者上下文分离，更容易保持怀疑。
• 长任务是否需要 sprint、上下文重置或额外评估者，取决于当前模型的能力边界。模型升级后要删除不再承重的脚手架。

原文报告了多小时运行、较高 token 成本及若干质量对比，这些结果来自特定模型、提示与应用，本站没有独立复现。

和 Zero-to-AI 现有实践如何接上

Zero-to-AI 已经强调先写范围与验收、在 worktree 隔离实现、最后运行 npm run verify。可以进一步把“作者检查自己的文案”改成两阶段：第一轮只按契约写，第二轮从新上下文按读者路径检查链接、构建和页面呈现。对普通教程仓库，不必先搭三 Agent 平台。

一个低成本实验

输入： 一篇已有教程，以及一个明确的小改版目标，例如“增加一段可运行练习，但不改变导航”。

步骤：

1. 先写 4 条完成契约：读者输入、操作步骤、可见结果、不得改变项。
2. 让生成轮只修改目标文件，不做自我评分。
3. 新开干净会话作为评估轮，按契约逐条检查 diff、命令和页面。
4. 只把明确失败项退回生成轮，最多两次。

成功证据： 评估轮能指出可复现的失败位置；最终每条契约都有命令输出或页面操作证据，而不是一句“整体不错”。

停止线： 两轮后仍只是审美争论、没有可操作失败；此时停止自动循环，交给人确定品味或产品方向。

常见误区

• 角色越多越可靠：额外角色会增加成本、延迟和沟通损耗，只在真实边界外使用。
• 评估者天然客观：它也需要明确标准、反例和真实可操作环境。
• 用构建通过代替应用可用：静态构建无法证明交互、API 和数据状态正确。

原文与证据边界

文章中的设计分数、成本、时长和应用效果是作者实验报告，未由本站复现。本站可迁移的是角色分离、完成契约和原路径 QA；是否值得多 Agent，仍需用本地小实验比较单 Agent 基线。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。