绿了也不算过：阿里云用 Qoder 让 Computer Use 自己验证到能过夜

绿了也不算过：阿里云用 Qoder 让 Computer Use 自己验证到能过夜

阿里云社区在 2026 年 8 月 6 日写了 Computer Use 是怎么做出来的。Qoder 是阿里的 AI 编码与 Agent 桌面产品。Computer Use 让 AI 看屏幕、点击、输入、拖拽，并在后台继续干活，而且不抢用户的前台。副题写的是 Goal Mode、自验证、回归护栏，以及数百小时无人值守迭代。全文讲的是验收、测试、记忆和回归怎么连成环，不是功能清单。

三道难处，质量只能看行为

实际有三道约束。技术缺口：要用 Swift 和 macOS 原生 API，团队里没有人熟悉 macOS 开发，作者本人完全不会 Swift。范围大、人少：Computer Use 覆盖语义 UI 树、截图、进程间通信、权限、签名、动作回放和一整套系统能力。问题不是能不能做出来，而是怎么用 Qoder 把工程产出放大。质量门槛高：这不是演示，要能进真实 Agent 工作流，任何一维短板都会立刻露出来。

由此得到一条硬约束：不能靠读代码判断质量，只能靠观察行为。作者不知道代码对不对，但能判断工具有没有真的操作了电脑。策略是先定义正确结果长什么样，再让 AI 证明自己达到了。

人一停，系统就停

第一版流程很传统：人写需求，Agent 写代码，人手动跑测试、看结果、再给反馈。每次对话从零开始，要重讲上下文、怎么测、哪些方向已经失败。Agent 也许能干活，但没有持久记忆时，每一轮都像换了一个新人。瓶颈在人。人的注意力有限而且不连续。人一停，系统就停。要继续迭代，系统必须能自己跑。

同一张证书，一条命令，再进入 Goal Mode

Computer Use 依赖系统权限。每次构建必须用同一张证书签名，否则 macOS 会把它当成新应用，之前授予的屏幕录制和辅助功能权限作废。他们把从源码构建、稳定签名、启动到测试的整条路径包成一条命令。Agent 不用懂签名细节，只要有一条能得到行为有效安装包的可靠路径。

能跑一次还不够。普通对话是一问一答，任务结束就停。做工具常常要很多轮才收敛：编译失败、测试失败、某个应用里行为不对，或者一处修复在别处造成回退。如果每一轮都要人重新启动，效率就垮了。

他们用了 Qoder Goal Mode。给人一个目标，例如「实现点击工具并通过端到端测试」。Agent 朝这个目标继续做：实现、测试、修失败、再试，直到成功，或者明确需要人做决定。它不再跑一次就停，而是循环到目标收敛。

三层验证：调用不抛异常不算完成

Agent 能自己跑之后，新问题马上出现。例子是实现点击工具。它跑完测试并报告成功，人工复查时按钮并没有被点到。测试只检查调用不抛异常，不检查按钮状态是否变化。测试是绿的，真实行为是错的。

问题不是没有测试，而是测试太弱。如果只覆盖最顺的路径，Agent 可以写出一个什么都不做的实现，测试仍然通过。规则改成：没有通过真实且充分的验证，改动就不算完成。

验证分三层：

1. 单测：校验单块逻辑。
2. 功能测试：Agent 自己建一个测试应用，把工具端到端跑一遍，证明它在真实界面上有效。
3. 评测集：用标准场景看整个系统有没有回退。

关键是测试由 Agent 自己生成。要实现点击工具，就必须做出一个真能被点击的应用，并证明可见状态变了。文中的例子覆盖文本框、按钮、滑杆、滚动、嵌套视图、列表等界面元素。这类应用有很多个，各自对应不同场景。从单功能测试到完整工作流验收，要证明的不是工具调用返回成功，而是最终效果被从多个角度核过。

已修过的问题必须变成持久用例

验证能证明当前改动有效，挡不住另一类失败。假设周一修了「点击按钮有时会抢走前台焦点」。周三 Agent 优化另一个功能，无意改了相关逻辑，旧问题回来了，但当前任务的测试范围看不到它。

做法是：每一个已修复的问题都变成持久用例，在以后每一轮自动检查。开发中发现的缺陷进回归集，真实用户反馈也进。例如「在这个应用里点击没有生效」，要变成可重复场景，永久留在回归集里。已经发生过的问题不能只留在人的记忆里。

记忆放在文件里，不塞进提示词

两个真实失败说明跨轮没有记忆。第一，已经规定每次构建必须用稳定签名证书。后一轮新的 Agent 看到一个临时本地签名脚本，直接拿来用，权限弹窗又回来了，因为它不知道先前的约束。第二，上一轮试过把 scroll 换成系统级 API，发现在部分应用里不稳定，已经回滚。这个「试过且失败」的结论没有写下来，下一轮又提出同一方案，绕了同一段路。

把全部知识塞进提示词也不行。上下文窗口不够大，人手工解释也总会漏。他们把记忆放在文件系统，分成两层：项目记忆存放架构、约束、研究结论这类稳定知识；回顾笔记存放每一轮的动态知识，包括改了什么、还剩什么、下一轮从哪里开始。

目录是：

• docs/specs/：需求和验收标准
• docs/architecture/：架构和核心约束
• docs/implementation/：关键实现模块笔记
• docs/research/：技术调研和决策理由
• docs/plans/：下一阶段迭代计划
• docs/retrospectives/：每轮回顾、未关闭问题和风险
• docs/evidence/：测试结果和行为验证记录
• docs/test-cases/：测试场景的来源、覆盖和历史

每一轮开始时，Agent 读项目记忆和上一轮回顾。结束时写回去。

白天定目标，夜里自己跑

合在一起是一条环：目标，实现，验证，回顾，再进入下一个目标。每一轮不再从零开始，而是从上一轮已经学到的东西开始。

人不需要实时盯着。白天人定下一个目标和验收标准，并复查上一轮结果。夜里 Agent 自动做实现、测试、评测和回顾。早上人读一份证据清单：过了什么、失败了什么、需要什么决定。

数百小时是真的，图上的数字没有写出来

这套系统连续迭代了数百小时，其中大量是无人值守的过夜。原文说下面两张图是真实评测数据。页面正文没有给出图上的分数、样本量、坐标或统计口径，所以不能把「数百小时」写成一份带数字的成绩单。

回到原来的问题：一个不会 Swift 的人要交付生产级原生 macOS 软件。最后做成了。原因不是单纯因为 AI 强，而是围绕验收、测试、记忆和回归搭了一套系统，AI 在里面自己跑、自己验证、自己积累。人的角色从「写代码并盯着执行」，变成「定标准、设计验证、选方向」。文中把这称为 Loop Engineering，并写明这是已经在 Qoder 里用过的做法。技术栈不再是主要障碍，真正的杠杆是定义目标和验证结果。

文末还提到 Qoder Desktop 已有 Goal Mode 和 Spec，最新版本升级了 UltraPlan 和 UltraReview，并配 Computer Use、Browser Use。这些是产品能力，不是这次评测的分数，不能和数百小时放在同一张成绩单里。

读的时候只保留原文给得出的边界：同一证书签名是权限不丢的前提；测试只检查不抛异常会被判为不够；回归集同时收开发缺陷和用户反馈；跨轮结论必须写进文件，不能只靠提示词；运行时长是数百小时，图表上的具体数字没有公开。

出处：阿里云，Alibaba Cloud Community，How We Used Qoder to Let an Agent Iterate on Itself: Computer Use as an Example，2026-08-06，https://www.alibabacloud.com/blog/how-we-used-qoder-to-let-an-agent-iterate-on-itself-computer-use-as-an-example_603432