11天，三家都上了/goal：Qoder 1.0 是我最推荐你亲自试一次的智能体自主开发平台。

4 月 27 日，我写过一篇文章。

题目大概是，GPT-5.5 + Codex 如何跑一整夜，编程的下一步，不是辅助编程，是可托管执行单元。

当时我真正想聊的，其实不是某一个模型有多聪明。我更在意的是，AI 编程这件事的重心正在变。

你开始不只问它会不会写。

你会问，它能不能连续知道自己在干嘛。它失败后会不会自己修。它跑几个小时以后，能不能给你一个你敢验收的结果。它更像一个可托管执行单元。

比较有意思的是，那篇文章发出去没几天，这条线突然变得非常明显。

4 月 30 日，Codex 上了 /goal。

5 月 7 日，Hermes Agent v0.13.0 上了 enforced goal completion with /goal。

5 月 11 日，Claude Code 2.1.139 也上了 /goal，可以设置完成条件，让 Claude 跨多轮持续工作，直到满足目标。

差不多 11 天。

三家（还有一些其他的Cli，忘记名字了），同一个命令。同一种方向。

当然，不同产品的实现细节不一样。

Codex 的 /goal 更像持久线程目标，背后有 active、paused、budgetLimited、complete 这类状态。

Hermes 强调 Kanban、多 Agent orchestration，以及 enforced goal completion。

Claude Code 的 /goal 则和 Agent View 一起出现，让你能看到正在运行、等你处理、已经完成的会话，还能显示时间、轮次、token 数。

但它们共同说明一件事。

AI 编程工具正在从「你和它聊天」，往「你把一件工作托管给它」移动。

三家 /goal / 长任务功能对照表：

这也是我这次开始认真看 Qoder 的原因。https://qoder.com/ （继字节Trae 、腾讯CodeBuddy后，阿里刚刚发布了自家的AI IDE：Qoder，登陆即送Pro。）

Qoder 迎来1.0 版本重大升级：Qoder 是一款智能体编程平台，其中的子产品 Qoder IDE 和市面上主流 AI IDE 同赛道。Qoder 从 0.x 迈入 1.0，是一次产品重新定义。

Qoder 1.0 围绕"放手"重新组织 AI 编程的工作方式：用多任务工作区承载任务流，用专属 AI 团队推进不同类型的工作，用工程知识引擎支撑 Agent 的判断与交付。开发者从"盯着 AI 写代码"转向"定义目标、审查结果、做关键决策"。

Quest 从一个「模式」升级为全新独立视图。告别传统 IDE 界面，指挥交付就像开会派活一样自然。

Quest 全新视图，任务有状态、有进展、有产物，开发者不需要一直盯着 Agent 的每一步输出，而是像管理研发任务一样，快速判断当前应该介入哪里。

我对 Qoder 1.0 进行了长时间的实践，两天消耗了一个Pro账号所有的积分。

下文会有四个测试，我使用的是 GLM 5.1 模型 或 Qoder Auto模式，每个任务少则 20 分钟，多则 40分钟，都有完整从0到1的记录。总体感觉，非常适合安排团队 Agent 的干活、长任务的审阅审与介入，而且交互体验做得很好。

并且Agent能力方面也很强；用上Qoder 1.0 的这一套 Agent Harness，让国产的这些模型也表现出了不俗的效果。

如果只是拼模型能力，今天你强一点，明天别人强一点，这个变化太快了。

但如果从「可托管执行单元」这个角度看，Qoder 让我比较有感觉的地方，不是它又多了一个聊天框。

它是把这个长任务执行过程，做成了一个能看的东西。

Quest 模式下多Agent的工作速览（实时画布、产物、方便审阅介入）：

一键切换到 Quest 全新视图：

一个 Quest（左侧栏） 是一个任务单元（可并行）。下面我标注了它的整体页面

左栏导航管理、中栏会话流、右栏产物区：

左边能看到任务列表。中间能看它怎么推进。右边能看到知识、记忆、产物。

右边的这些任务进展，不同的任务有不同的 agent 负责，随时可以点进去查看详情下面还有实时的产物，以及引用的记忆可以查看，这些都为你的介入、审阅、判断提供了方便：

有 Summary。有 Changed Files。有 Progress。有 Artifacts。

这件事对我挺戳的。因为我不是只看 AI 最后说了什么。

我更想知道，这件事是怎么发生的。

它做了哪些步骤。它什么时候卡住。它怎么验证。它交付了什么。我什么时候该介入。我什么时候只需要看产物。

我这次没有跑那种标准演示任务。我拿它做了几件自己真的需要的事：

第一件，README 最佳实践研究。

这个任务看起来不传统。

它不是加一个登录按钮，也不是改一个接口。

但我觉得它特别真实。

因为如果你要做开源项目，要做产品，要把自己的工具发布出去，README 怎么写，官网怎么写，第一屏怎么让人信任，这些都不是边角料。

我让 Qoder 去研究 README 最佳实践。

点击 export模式 + spec ，输入提示

然后会有一个询问交互，帮你明确任务方向的。

接着，Agent 写 spec ，这是为了写一个任务计划文件，

为了跑长任务，需要有目标、每个 Task，每个Task包含一些工具、动作、指导和产出，这些明确的定义。

这对于长跑任务多 Agent 的执行非常有必要。Qoder的每次执行之前都会生成一个spec，你还可以和他聊天修改。

然后你就会看到多个 agent 开始并行执行，并且有画布小卡片展示。

整个团队Agent执行过程通过画布卡片实时展示，你可以看到每个团队成员担任怎样的角色，做了哪些工作，中间栏还有一个比较好看的可视化看板。总体，这块设设计做得非常赞。

全过程如下，可以看到，观感交互体验非常不错，这应该是目前最好的子Agent、Goal 呈现方式了：

它最后给我的不是一份空泛模板。

它对标了 13 个 GitHub 高星项目，又看了一堆行业文章和社区讨论，整理出一份我现在真的能拿来用的研究报告。

里面有首屏怎么写，Quickstart 怎么设计，Badges 怎么放，GIF 和截图什么时候需要。

我看到那个结果的时候，第一反应是，行，这玩意对我是真有用。

如果我自己去做同样的研究，当然也能做。

但我要找项目、看 README、总结规律、再写成一份能指导我后续工作的文档，这个时间成本不低。

现在它可以变成一个 Quest。

我把输入给它，它去跑研究，跑完把产物摆在那儿。

我再去验收，可以看到最终输出的效果非常具有指导意义，因为都是根据真实存在的最佳实践，并且交叉验证研究得来的（只进行了长截图了其中几个章节）：

我可以说，这份报告做得比任何模型的 Deep Research 更有价值

还有些章节给我推荐了具体往这方面走的 Readme 最佳实践 产品，有些有创意的产品比较打开思路；总体而言，整份报告写的让我感觉非常有价值。而且使用的是国内模型，便做到了这个程度。

这里还有个小细节。它能做成这样，不是因为我只扔了一句「帮我研究 README」。

我提示词输入的是一套研究类任务的经验和文件（根据我长时间研究各类主题的经验，自己写的一套 skills）。所以我给它的不是一句愿望。

我给的是一个能让它进入状态的输入。

这也再次说明，长任务不是许愿。你不能只写「帮我做好」。

你要给它上下文、边界、参考材料、验收方向。

最近 X 上很多人也在说这个点。/goal 最强，但大部分人用错了。

他们写「别犯错」。然后开始祈祷。更靠谱的写法，是写 GOAL、CONTEXT、CONSTRAINTS、DONE WHEN、VERIFY、OUTPUT、STOP RULES。

这和我这次用 Qoder 的体感是对上的。

第二件事，是 Supabase + Stripe + Auth。

这个就更像标准工程任务了。

从零搭一个 Next.js App Router 项目，接 Supabase Auth，接 Stripe 订阅支付，做 RLS 权限控制，再跑 E2E 验证。

任务安排如下：

登录，Dashboard，定价页，点击订阅，跳转 Stripe Checkout，填测试卡，支付成功，回到 Dashboard。

注册、登录、进行支付订阅后的完整状态：

全流程验证通过：

这条链路听起来很普通。

但真做过的人都知道，这里面随便一个环境变量、回调地址、webhook、RLS 策略，都可能卡住。

这次也没有一把过。

中间有数据库和存储连接问题，也有 Stripe 的 priceId 环境变量问题。

更有意思的是，原本我打算自己注册账号去测。

后来自动化测试时，Supabase 登录验证那块因为邮件验证和频繁测试被卡住了。

我自己每次填账号也烦。

于是我让它直接往数据库里注入一个测试账号，让它自己完成登录，再去订阅。

然后它一边自动化控制浏览器，一边发现错误，一边改代码，最后把链路跑通。

以前做这种浏览器测试，经常是你先让它写代码，再让它自测，再让它打开浏览器，再告诉它点哪里，再把报错贴回来。

现在这件事越来越像一个完整回路。

它写。它跑。它打开浏览器。它填表。它撞错。它回去改。它再测。

人当然还要看。人当然还要判断。但人的位置变了。

以前我像一个随时准备接管键盘的人。现在我更像一个在旁边看验收结果的人。

这件事挺让人兴奋，也挺让人有危机感。如果很多执行单元都能越来越独立，我们剩下来的价值是什么？

我现在的答案不在更快敲代码上。我更在意的是，定义任务、组织输入、判断结果。

你要知道自己真正想要什么。你要知道什么结果才算好。

你要知道什么时候该让它继续跑，什么时候该打断，什么时候该换一个角度。

而在判断结果，检查AI 写出漏洞代码方面，专业的程序员还是有优势的。

第三件事，是 Superpowers + YC 这套专家团配置。

Superpowers 、gstacxk 这两个 skills 应该许多人了解，我纯粹是想让这两个 skills 分家分成两个 agent，再配上其他的 UI 、审查 agent 组一个团队。

我让它配置一个产品开发专家团。

里面有 product-lead，有 superpowers-engineer，有 growth-expert，有 design-expert，有 qa-reviewer。

名字只是外壳，里面塞进去的是不同方法论。

Product Lead 负责追问需求真实性、用户、MVP、未来适配。 Superpowers Engineer 负责计划优先、TDD、完成前验证。 Growth Expert 负责市场和增长视角。 Design Expert 负责审美和体验。 QA Reviewer 负责测试分层和发布把关。

这里面让我觉得省事的，不只是它创建了几个 agent 文件。

更关键的是，它后面还让测试工程师 Chris 去验证这些配置。它会检查 YAML frontmatter，检查中文提示词，检查每个 agent 有没有对应方法论，检查 skills 是否安装完整。

最后给出一个验证报告。这事如果我自己做，当然也能做。

但我很可能会偷懒。我会觉得差不多吧，能跑就行。而它真的把这件事当成一个工程任务去验。

这里我也有保留。

我现在还不确定 Qoder 这些子 Agent 之间到底能不能像我理想中那样互相沟通。

Claude Code 的 team 子 Agent 可以互相沟通，协作感会更强。

Codex 子 Agent 也没有互相沟通。

对于Claude Code 的team团队功能， 社区里有一些 Dashboard 项目是用来做可视化的，但我试过效果比较一般，还有 bug，本来我前面是在试着去优化的。。

而Qoder 现在这个可视化效果确实很好，看起来像一个团队真的在那儿干活。

这点我不想吹过头。

至少从这次体验看，它把任务拆解、角色分配、产物展示这几件事做得非常直观。

而且这个界面本身，对展示和验收都很重要。

你不只是看 AI 最后说了什么。

你能看到这件事发生过。

有任务。有角色。有状态。有验证。有产物。

比如你使用Codex 5.5开到最大模式，巴拉巴拉思考研究一大堆，最后输出来的总结性结论可能就是一点，中间的那些东西我们能参与的程度会少许多。

第四件事，是工具链还原与验证。

这个案例更像我的真实刚需。

我以前手动搭过一套工具链。

包括网络研究、各种搜索 skills、MCP、环境变量、浏览器相关工具、登录态保持这些东西。

自己装一遍，真的烦。

换一台电脑，能不能让 Qoder 读懂我上次做了什么，然后自动把同样的工具链还原出来？

不要我再手动复制 JSON。不要我再到处跑命令。不要我再凭记忆找哪个 key 放哪里。

这个任务里有一个小插曲。

我一开始问它，为什么资源包里明明有很多 skills，最后搞出来的却那么少。

它检查之后发现，原来那些 skills 没有注册到 Qoder 能调用的位置。

于是它澄清问题，制定迁移计划，把 skills 安装到全局目录，再验证哪些可用、哪些缺 API key、哪些只是依赖问题。

最后它告诉我，24 个情报研究 skills 已经复制到全局目录，结构完整，SKILL.md 抽查正常，node_modules 依赖也验证过。

这个案例可能没有 Supabase + Stripe 那么容易讲。

但它很能说明 Qoder 对我有什么用。

我不是让它凭空创造一个新功能。

我是让它读懂一段过去发生过的配置经验，然后在新环境里复刻出来。

而且这个复制任务其实挺复杂。

如果工具链没配好，就没有前面那个 README 最佳实践研究。

因为你根本搜不到足够好的东西，也没法把研究流程跑完整。

这也是为什么我对 Qoder 的 Knowledge 和 Memory 比较敏感。

我看到它的知识中心和记忆面板时，第一反应是，这玩意如果真的能持续积累，会很适合长线工作，打开 Knowledge 面板，展示自动生成的知识（架构 / 规范 / 技术栈）：

写代码是长线工作。做产品是长线工作。做内容也是长线工作。

你不应该每次都重新解释自己是谁，项目是什么，偏好是什么，过去踩过什么坑。

所以回头看这次 Qoder，我最想写的不是它功能有多少。

也不是它能不能打败谁。我更想说，它把一个趋势做得更可见了。

AI 编程正在从「助手」往「执行单元」走。执行单元要能长时间工作。

要能自己验证。要能保留状态。要能让人介入。要能交出你看得懂的产物。

Codex /goal、Hermes /goal、Claude Code /goal 都在补「让 agent 一直朝目标跑」这件事。

Qoder 的 Quest、Experts、Knowledge、Summary、Artifacts，则把这件事做成了一种更具体的产品形态。

你能看到它在跑。你能看到它怎么分工。你能看到它交付了什么。

你也能在中间决定，要不要介入。这就是我最喜欢它的地方。

这次，我确实看到了一个产品形态。它不是一句「AI 会自己写代码」。它更像是一个开发控制台。你把任务放进去。它拆解、执行、验证、沉淀。你在合适的时候介入。最后看产物。

这就是我之前那篇文章里说的可托管执行单元，长出来的一种样子。

以前我只能从 Codex changelog、长跑案例、开源 workflow layer 里推这个方向。

现在我在 Qoder 里，看到了一个更直观的界面。

所以如果你问我，Qoder 最值得看的点是什么。

我会说，不是它又做了一个 AI IDE。

是它把「长任务到底怎么被托管、被观察、被验收」这件事，做得更像一个产品了。

这个方向，我觉得值得继续看。

总之，Qoder 绝对值得尝试。

下载 Qoder 1.0，右上角切换 Quest ，Quest On, Hands off。全新的 Quest

它有两种订阅方式，一种是官方，就是最低的二十美元每月（社区版免费账号也可以获取2周试用），另外就是可以使用自己的 GLM 、阿里云百炼等国内各种的 coding plan 套餐：

下载：qoder.com/download

既然看到这了，觉得有帮助得话，随手点赞支持一下。