Theo：用迭代评审改善智能体生成的界面

Theo 回应了对 T3 Code 界面的批评。这个开源项目没有全职设计师，他也同意界面视觉和用户体验需要进一步打磨。

他询问编程智能体能否通过反复评估改善真实应用的设计。实验跨越多个模型和许多评审轮次，新界面的早期版本通过测试版开关提供。

项目始于一位用户对字体、圆角、图标和视觉层级的评论。Theo 将反馈交给智能体，要求它创建拉取请求、反复修改，并从一组模型评审那里获得高分。

他的评审技能把同一份任务交给多个模型，要求只读反馈和评分，再收集分歧与下一步建议。他之前用过类似方式评审代码，但没有将其用于主观的界面设计。

视觉质量与性能基准或测试通过不同，没有稳定的程序化分数。Theo 指出，同一模型多次看到相同截图也可能给出不同分数；这些评分是有噪声的判断，不是客观测量。

原始界面的初始评分约为十分之六。智能体修改后，评审分数上升。由于细微差别不易一眼看出，Theo 要求生成带标注的前后截图。

对比图突出显示了备用字体、标题层级、分支名截断、卡片圆角和行内代码样式的变化。评审组最终给到目标分数，但 Theo 自己与其他应用比较后仍不满意。

他开始新一轮评审，并加入 Claude Code 和 Codex 的截图作为参考产品。目标从单独改善 T3 Code 变为与这些界面比较。按他的说法，这次较长的运行接近十八小时。

新的上下文显著改变了评分：此前被评为九分的版本，在新比较中只比原版略好。Theo 认为这表明提示词、参考图片和上下文会影响主观评分。

他还观察到，未改变的参考截图在后续轮次中得分也上升了。这种不一致再次说明，不能把数字当作经过校准的测量值，尽管反馈仍可指导迭代。

为了控制用量，他最初只让一个模型评审，等其分数足够高后再请其他评审回来。修改改善了标签、字体与边框处理的一致性、侧边栏层级和浅色模式对比度。

Theo 将工作分叉到另一个 worktree，并把每个类别的目标提高到 9.5 分。智能体继续修改并寻求评审；第一个模型达到门槛后，另一位评审仍不同意。

他意识到一个可能的偏差来源：评审知道目标分数，而同一参考截图的分数又随时间变化。他考虑今后不让评审知道目标。

目标小幅提高后，又需要大约十轮。Theo 报告称，整个更广泛实验约有 17.6 小时的并行智能体运行时间，总成本估算接近 400 美元，但订阅模型的成本存在不确定性。

他后来将约 150 美元的额外优化运行从之前展示的工作中分离出来。这些估算是他对本次实验的核算，并不保证其他用户的订阅或 API 用量成本相同。

在后续运行中，他要求每项达到十分，并给出具体偏好：之前的结果太灰，需要恢复一些颜色。他更喜欢新结果的对比度、更醒目的图标和更清晰的合并按钮。

Theo 的经验是明确迭代过程：将新截图与旧版本和参考版本比较，识别问题，修改，再次评审。尽管有模型评分，他自己的视觉检查仍是评估的一部分。

随后他介绍一个更可直接衡量的 T3 Code MCP 工具描述优化。他收集模型调用错误工具或错误处理会话的例子，将其分类并制成评估集。

初次模型运行通过了约 88 个收集案例中的 60 个。智能体据此开发了更大的评估集。Theo 指出，讲述时这套评估尚未合并。

修改后分数有时会下降，从而帮助发现回归。他先要求智能体达到期望的测试结果，再大幅缩短工具描述，同时保持这些结果。

他报告说，最终描述占用的上下文显著减少，其中两种配置分别减少 52% 和 78%。他说这些修改已进入 nightly 构建，稳定版计划随后发布。

Theo 提醒，模型行为仍然具有非确定性。尽管如此，他认为智能体很适合分类历史失败和反复测试修改等繁琐工作；他说，手工完成会花更长时间。

最后，他鼓励工程师尽可能把问题表达为可衡量的目标，并据此迭代。界面示例展示了主观模型评审的潜力与局限；MCP 示例则使用了更具体的测试集。