一位不懂 Swift 的工程师交付了 macOS 智能体

Qoder 全新的 Computer Use 能力让 AI 能够操作真实的桌面：查看屏幕、点击按钮、键入文字、拖拽对象，并在后台持续运行。构建它的工程师读不懂它生成的代码，因为他不了解 Swift。这个细节藏在团队发布于阿里云社区的建设日志中，比功能本身更有意思。

一篇描述该项目的文章直言不讳：“我不知道代码是否正确，但我能判断工具是否正确操作了电脑。”一个人，不懂 Swift，却要交付生产级的原生 macOS 软件。唯一可行的“完成”定义就是行为。

一位工程师，不懂 Swift，以及一个替你点击的桌面工具

Computer Use 听起来很简单，直到你把“点击按钮”所需的条件写下来。动作必须真正生效；动作后的状态必须可读取；工具还不能抢占前台，因为一个每次行动都把焦点从用户身上夺走的智能体，没人会用第二次。建设日志将这三项列为项目的三个具体挑战。

他们由此得出了自己的硬性约束。工程师无法通过阅读代码来判断质量，于是他便通过观察行为来判断。策略变成了：先定义正确的结果是什么样，再让 AI 证明它达到了该结果，而不是指望代码看起来正确。本刊此前曾指出，桌面智能体的真正瓶颈是技能覆盖，而不是模型。这篇帖子正是下一个瓶颈的案例研究：一旦智能体能够行动，你如何知道它真的做到了？

最初的工作流程是大家熟悉的那种：写下需求，让 Agent 编写代码，手动运行测试，检查结果，给出反馈。如果你用过 AI 编程助手，你会认出这部分：每次对话都从零开始，上下文必须重新陈述，而 Agent 会忘记哪些方向已经失败过。瓶颈在人。注意力是有限且不连续的。人一停，系统就停。

从请求, 响应到能彻夜运行的循环

第一步是构建一条 Agent 可以独立完成的流水线。Computer Use 依赖系统权限，而每次构建都必须使用同一证书签名，否则 macOS 会将其视为新应用，并使已授予的“屏幕录制”和“辅助功能”权限失效。团队将整条路径, , 从源码构建、稳定签名到启动和测试, , 封装进一条命令。Agent 无需理解签名，它只需要一条通往有效安装包的可靠路径。

只运行一次是不够的。普通的 Agent 对话是请求, 响应式的：任务结束，Agent 就停下。构建工具需要很多轮，因为编译会失败、测试会失败、某个应用里的行为不对，或者一个修复破坏了别处的东西。Qoder 的答案是目标模式（Goal Mode）。给 Agent 一个目标，比如“实现点击工具并通过端到端测试”，它就会持续工作, , 实现、测试、修复、重试, , 直到收敛，或明确需要人来决策。

那个全绿却证明不了任何东西的测试

独立运行的能力暴露出一个新的失败。在被要求实现点击工具时，Agent 运行了测试并报告成功。但手动检查显示，按钮从未被点击过。测试只验证了调用没有抛出异常，从未检查按钮状态是否发生变化。测试全绿，行为却是错的。

问题不在缺少测试，而在于测试太弱。如果测试只覆盖最顺利的路径，Agent 就能写一个什么都不做的实现，照样通过。新规则是：任何改动，只有通过真实且充分的验证，才算完成。团队描述了一套三层验证方案，其中重点强调的一层是让 Agent 自己生成测试。实现点击工具，意味着要构建一个真正可以被点击的小应用，并证明可见状态发生了变化。帖子里展示了一个这样的 Agent 生成的测试应用，覆盖文本框、按钮、滑块、滚动、嵌套视图、列表及其他 UI 元素；针对不同场景，团队还构建了许多类似的应用。

周一的修复，周三又回来了

验证证明当前改动有效，但它不能防止回归。假设周一的修复让点击不再抢占前台焦点；周三的优化碰了相关逻辑，旧 bug 重新出现，却没人注意到，因为它不在当前任务的测试范围内。

团队的回应很直接：每个已修复的问题都会成为一个持久化的测试用例，在后续每一轮中自动检查。开发过程中发现的 bug 会进入回归测试套件，真实用户反馈也是如此。像“在这个应用里点击不起作用”这样的报告，会变成一个可复现的场景，并永久加入回归集合。已经发生过的问题不应该只存在于人的记忆里，它们应该变成自动化检查。

这篇文章列举了两个真实失败，它们有一个共同的根源：Agent 在轮次之间没有记忆。把所有知识都塞进提示词行不通，因为上下文窗口不够大，而且手动说明总会漏掉一些东西。团队的解决方案是把记忆保存在文件系统中，分为两层。项目记忆保存稳定知识：架构、约束、研究结论。回顾笔记保存每一轮中发生了什么变化、还剩下什么、下一轮应该从哪里开始。

docs/ 目录就是记忆的布局：

docs/
├── specs/              需求与验收标准
├── architecture/       架构与核心约束
├── implementation/     关键实现模块的说明
├── research/           技术研究与决策依据
├── plans/              下一阶段迭代计划
├── retrospectives/     每轮回顾、未决问题与风险
├── evidence/           测试结果与行为验证记录
└── test-cases/         测试场景的源码、覆盖范围与历史

每一轮开始时，Agent 会读取项目记忆和上一轮的回顾笔记；结束时，它会把内容写回去。完整的循环是：目标（Goal），然后是实现（Implementation）、验证（Verification）、回顾（Retrospective），再进入下一个目标。从此，没有哪一轮还要从零开始。

循环工程，以及被移开的障碍

团队报告说，他们进行了数百小时的持续迭代，其中包括长时间无人值守的夜间工作，评估图表也随帖子一同发布。最初的问题, , 一个读不懂 Swift 的人交付生产级原生 macOS 软件, , 解决了。团队认为，这并非因为 AI 本身有多强大，而是因为 AI 周围有一套系统：验收标准、测试、记忆、回归。在这套系统内部，AI 能够自己运行、验证并积累知识。

人的角色从编写代码、盯着执行，转变为定义标准、设计验证和选择方向。“循环工程”（Loop Engineering）这个词最近很流行，团队表示，他们在这个标签里认出了自己的实践。如果循环运转良好，工程师就不再需要成为某个特定技术栈的专家才能交付生产级软件。技术栈不再是主要障碍，重要的是定义目标并验证结果的能力。

Qoder Desktop 已经包含目标模式（Goal Mode）和规格（Spec）能力，最新版本还升级了 UltraPlan 和 UltraReview。Computer Use、Browser Use 这类通用验证工具，意在帮助团队构建自己的自主迭代系统。帖子里最不动声色的论断，恰恰最值得细品：工程师不再需要深入了解某个技术栈，才能用它交付生产级软件。技术栈从来就不是真正的障碍，验证才是。