OpenAI刚发ChatGPT Space，国内版就震撼上线！

新智元报道 就在今天，OpenAI 在刚刚结束的 DevDay 2026 上，又扔出了一记重磅：ChatGPT Space——一个让团队成员、ChatGPT 以及常驻 AI 智能体 Dots 共同工作的共享空间。 页面可以实时协作编辑，文件、聊天记录和项目上下文都住在同一个「房间」里，AI 不再只是个人私聊对象，而是真正能参与团队讨论、更新文档、分派任务的「同事」。 无独有偶，国内版的ChatGPT Space，这不就来了！ 最近在杭州云栖大会上，阿里智能体平台Qoder直接扔出神器——正式上线「项目」）（Projects）和「讨论」(Discussion)功能，并且同步放出自定义智能体与智能体团队！ 这一次，它不再只是个人效率神器，而是真正实现了「人与Agent共同工作」，让 AI 真正融入团队的工作流中。 用AI写代码， 团队协作为什么这么难 最近，Cursor被SpaceX收入麾下，Claude Code在终端里一路狂飙，Devin Desktop把自主Agent塞进IDE。然而，虽然每个人都在用AI写代码，但为什么整个团队推进项目的速度并没有显著变快？ 原因就在于，当 AI 落地到真实的团队协作场景中，遇到了一个巨大的瓶颈：上下文断裂。 最常见的协作方式是这样的：团队围绕一项需求，在飞书、钉钉群或线下会议里唇枪舌剑形成一套方案。讨论结束后，每个人回到自己的工位，从会议纪要里扒拉出跟自己相关的部分，加上自己的理解，重新整理成提示词，再喂给自己的 Agent。 Agent 吐出代码或测试结果后，你又得把这些产物复制粘贴回工作群里，向其他人解释「我的 Agent 刚才做了什么」。如果需求变了，对不起，上述流程重来一遍。 有调查显示：在日常研发工作中，有效的工作时间只有39%，而其他的时间都用在「搬运信息」上了。你以为你在指挥 AI，其实你已经变成了穿梭在会议室、文档、终端和各种 Agent 之间的「人形 API」，干着搬运上下文的体力活。 有没有一种办法，让人类不用再当 AI 的搬运工？ 下面，让我们通过实测看看，Qoder 是如何重塑组织协作的。 告别「人形API」， 让讨论与上下文回归任务本身 这一次，Qoder给出的解法是：造一个共享的工作空间，把人类、文档、代码和AI，全部关在同一个「房间」里。 真实的研发从来都不是「输入Prompt，然后AI生成代码」这么轻松。它不是一个简单的线性过程，而是充满了漫长的拉扯、讨论、推翻和重构。 Qoder「项目」与「讨论」实测：让协作发生在工作现场 为了验证这套逻辑到底好不好用，我们模拟了一个真实的、令人头秃的业务场景。 周五下午4点，客服团队炸锅了。系统出现了偶发的重复扣款Bug，因为客户端超时重试，导致同一笔订单发了两次请求。 团队需要在下班前拿出「支付链路幂等性改造」方案，并且实现落地。 在过去，这需要拉一个紧急线上会议，有人记纪要，有人建Jira，然后再去分头问AI。 现在，我们看看在Qoder里是怎么行云流水般解决的。 第一步：用「项目」建立「作战指挥室」 之前，我们已经完成了整个项目，迁移到Qoder后，立马针对这次的链路改造创建了N个issue，然后从这个issue发起讨论。 项目名称： 支付链路可靠性改造（防重复扣款） 项目目标： 彻底解决客户端重试导致的重复扣款问题，给出幂等方案并落地。 这个「项目」绝不是简单的看板。它最大的价值，就是「全局上下文记忆」。 以往拉人进群，你要把代码仓库地址、报错日志重新发一遍。 现在，只要把同事和专属Agent拉进这个项目，他们瞬间就拥有了所有的背景知识。 所有沉淀的文件、历史决策，对人机双方都是透明的。 接着，我把这个大目标拆分成了三个 Issue。 1.排查重复扣款具体日志链 2.评审幂等方案（核心） 3.补充异常边界回归用例 第二步：用「讨论」开启人机圆桌会议 最硬核的部分来了。接下来，我们直接从「评审幂等方案」这个Issue发起讨论。 这样，我（项目负责）、后端老韩、测试小王就进入了讨论界面。 关键是，我还顺手拉进来了团队之前配置好的「Qoder架构师Agent」。 在「讨论」里，我们三个人类——我（项目负责）、后端老韩、测试老李，先围绕需求展开了讨论。 我抛出议题：「支付请求的幂等方案评审，客户端重试导致重复请求。」 测试老李马上补充：「注意，最近客诉有三个异常订单，网络闪断重连的场景必须考虑进去，并发量极高。」 后端老韩分析：「目前订单表没有做全局防重，只有业务流水号，我个人建议用 Redis 加分布式锁，但担心极端情况下的数据一致性。」 就在我们三个人类充分碰撞、把业务背景和风险点都理清楚之后，我顺手 @ 了一下群里的Qoder架构师Agent。 「@Qoder架构师Agent 请根据老韩和老李的信息，结合当前代码库，比较基于 Redis 防重 Token 和基于数据库唯一索引两种方案的风险，给出最佳实践。本次只分析，不改代码。」 然后，Qoder架构师Agent登场了！ 它直接读取了老韩的文字附件，并且结合了项目关联的代码仓库。 思考了7分钟后，它给出了深度回复。 在这个过程中，如果我对Agent的某句话有疑问，可以直接点击这条消息的 「回复」 进行追问。 第三步：一键沉淀「关键消息」，告别扯皮 三个人类看了 Agent 的报告，一致决定采用「数据库+Redis混合方案」。 以往群里可能会发一句「按方案二执行」，过几天就忘了细节。但在 Qoder 里，我直接选中这条结论，点击「标为关键消息」。 这些被标记的关键结论会自动反哺回原先的 Issue 中，更新工作进度，并作为后续 Agent 执行代码编写时的绝对依据。整个过程无比清爽。这一步操作，就像直接盖棺定论了。 右侧的「关键消息」标签页会集中展示这些结论。最绝的是，这些结论会自动反哺回原先的 Issue 中，自动更新工作进度！ 试用下来，实际的体感就是，Qoder的「讨论」彻底干掉了「聊天工具+任务软件+AI对话框」的三分天下。 它让讨论、决策和执行，在一个工作上下文中完成了闭环，整个工作流无比清爽。 自定义Agent与团队：让人类把控，让AI跑腿 为了测试更复杂的跨部门协作，我们将场景顺延到了这次重复扣款事件的「灾后重建」上。 虽然底层防重复扣款的 Bug 马上要按方案修好了，但客服团队还面临一个棘手的问题：怎么处理昨天已经发生重复扣款的几百个异常订单？ 于是，我们在同一个「项目」下新建了「开发异常订单批量退款工具」的 Issue，并把业务侧的运营小美、前端大强也拉进了当前的讨论组。 在「讨论」里，业务需求直接由运营小美发起。 前端大强和后端老韩立刻跟进，基于刚才确定的底层架构，进行技术层面的把控与防雷。 当这三个人类在讨论中，把业务诉求和技术安全边界完全界定清楚，并一键标记为「关键信息」后，运营直接 @ 了项目中预先配置好的「全栈研发 Agent Team」的后端Agent和前端Agent。 接下来，人类只需喝杯咖啡，看着智能体团队在刚刚确认的、连贯且无损的上下文中，分工协作把活干完。 在这个场景中，业务方提需求，程序员做技术把控与风险兜底，智能体团队负责搬砖写代码。 无需拉会、无需写厚厚的 PRD、无需在各个工具间复制