rt，打算开一个Claude跟codex的20x，可惜我目前的交互方式都是人工copy文档给两个AI，想问问有什么方法可以让Claude code 跟 codex互相交互呢？而且有没有佬友可以分享下自己平时使用协作下来的时候感觉他们各自擅长什么？谢谢啦 4 个帖子 - 4 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 我开源了一个智能体框架AgentClaw (详情见AgentClaw：一个既能辅助办公，又能为你搭建智能体的个人助手与智能体框架) 最近给它新加了一个功能：可以多人在同一会话中使用智能体或聊天。 GitHub 仓库： GitHub - Negai-ai/AgentClaw: AgentClaw turns one-sentence ideas into reusable Claw capabilities. Build less boilerplate with declarative workflows, computer browser code file control, MCP, Skills, memory, knowledge bases, tracing, scheduling, and API/MCP publishing. · GitHub 基于框架我部署了一个海龟汤智能体，欢迎各位佬体验。 链接 ： AgentClaw Admin 模型用的gpt5.4，大概还有400刀的余额，后续要是有有意思的智能体我也会挂到上面。 2 个帖子 - 1 位参与者 阅读完整话题
作为一名在读博士生，我在日常是如何与 AI 协作的？——ai-collab-playbook > 公开版本 / Public edition: 2026-06-08 cnfjlhj/ai-collab-playbook github版本~ -— 前言 我是一名人工智能方向的在读博士生，大概在 ChatGPT 出来以后还是 GPT-3.5 的时候就比较重度使用 AI 以及 AI 工具了。几年下来，AI 已经渗透到我工作和学习很多环节，有一些心得想分享一下~ 当同事，不当工具（我认为至少未来几年，应该是人机协作的时代） 现在回头看，我觉得过去很多所谓“会用电脑”，其实有相当一部分是在给机器当翻译。人脑子里明明只有一个目标，落到电脑上，却总要拆成一堆很零碎的动作。很多时候事情本身并没有多么复杂，感觉复杂是因为旧系统根本听不懂你的意图，只能逼着你先把目标嚼碎，再翻译成它能执行的步骤。 比如做 SQL 查询，你脑子里明明只是想看一个简单的业务趋势，但因为系统听不懂，你不得不花一个小时去嵌套三层 LEFT JOIN、对齐 GROUP BY 的聚合字段，小心翼翼地用机器听得懂的语法去和数据库交互。 这也是为什么我现在越来越自然地把 AI 当同事，而不只是当工具。 > 本文的主线很简单：AI 入口要贴近任务，Agent 流程要能被复盘，人仍然掌握问题表述与验收标准。 贯穿全文的几个方法论 - 元提示词思维：让 AI 写操纵 AI 的 Prompt，人做微调 - 苏格拉底追问：让 AI 从多角度逼问自己，把模糊的想法变清晰 - 多模型协作：不同任务用不同模型，也可以让不同模型协作完成复杂任务（后文会在各个场景展开） - 经验沉淀：把流程固化为 `Skill`（Code Agent 中的术语），越用越好，越用越快 -— 一、日常使用：AI 作为随身顾问 ### 让 AI 入口离任务更近 我最近很久没有认真使用网页端 ChatGPT 了，重新打开以后发现，各家模型的网页端和应用端其实都变化挺大。在 API/token 变得紧张以后，我反而重新意识到：并不是所有任务都值得拉起本地 Agent、走 API、配一套完整工作流。很多轻量、一次性的小活，比如临时总结、改写、问一个不需要项目上下文的问题，直接交给网页端 ChatGPT 的 Agent 模式就够了。它不一定是最“工程化”的方案，但对这类任务来说，入口短、成本低、上下文负担小，反而是更合适的选择。 应用侧也是类似的逻辑。我现在还会用 `豆包` 的划词工具栏功能，它能在电脑全局划词唤醒。最方便的是可以自定义划词动作，比如我写了一个“概念解释器”，划词后直接给出学术概念的通俗解释，省掉了打开浏览器、复制、粘贴、重新描述问题这一整串动作。 另外，`豆包浏览器` 的网页翻译、页面总结、针对当前网页提问这些功能也挺实用。它的价值不一定在于模型能力一定最强，而在于它离当前网页足够近：我不用把内容搬到另一个窗口，也不用重新组织上下文，直接在当前页面处理就行。 所以我现在会更刻意地按任务重量选择 AI 入口：轻量任务交给网页端或应用端，项目级任务再交给本地 Agent。日常使用 AI 时，最重要的不是把每件事都接入最强模型，而是尽量降低使用 AI 的摩擦力。入口越贴近工作流，越容易形成高频使用；用得越自然，AI 的价值才越容易被挖出来。（大家如果有更好用的应用侧工具，也可以留言推荐~） 通过 IM 软件远程调用 Agent 可以通过类似 `cc-connect`、`happy` 这样的应用远程调用现有的本地 Coding Agent（Claude Code、Codex），也可以直接使用类似 `OpenClaw`、`Hermes`、`cowork` 的成品。 我认为 IM 是最低摩擦的派活入口，可以随时把任务抛出去；远端机器是 Agent 的工作台，它可以下载、转写、分析、跑代码、生成 PDF、发回结果。 但最吸引我的还是可持续培养性：让 Agent 记得你的偏好、知道你的项目结构、沉淀 `skill/workflow`，逐渐变成“熟悉我的同事”。 最近我主要是拿他们当咨询类的推送助手，以及提醒我吃饭、睡觉、写日记之类的 chatbot。我会给它我的日记访问权限，让它每天去读我近期的日记，以及往年当天的日记，用来督促我继续写日记。和我一起聊我的零散碎碎念，帮我整理我的知识wiki… -— 二、科研 这里给大家安利一下我现在比较稳定的一条科研工作流：调研 → 筛选 → 精读 → 整合，核心目标不是让 AI 替我读完，而是让它帮我把文献网络、论文细节和个人理解接起来。 科研文献阅读 我把文献阅读分成四个阶段：调研→筛选→精读→整合。 阶段一：课题调研 我主要用 OpenAI 的 Deep Research 以及 GPT-Pro 做课题调研和可行性分析。我会要求 AI 不仅提供最新文献，还必须包含该领域的开山之作，之后再让 Agent 按照个人偏好去构建 `wiki`。 阶段二：文献网络分析（Literature Network Analysis） 找到几篇感兴趣的论文以后（也就是先找到锚点论文），借助 Paper Connect 等工具，可视化文献间的引用关系，快速判断研究热度与技术脉络。（这些数据也应该同步导出给 Agent） 与 Agent 沟通调研结果，搞清楚这些文献之间的逻辑关系，最终自动下载感兴趣的相关论文以供后续引用或精读。 > 如果某篇论文的引用网络图非常庞大，说明这个方向已经很"卷"了。反之，可能还是蓝海。 阶段三：确定精读 → 逐篇攻克 下载论文到相关文件夹以后，我会先和 Agent 讨论一下当下研究已经推进到了什么地步，再确定阅读顺序，去除无关或暂时不感兴趣的论文。整个过程要逐步扩充整理 `wiki`。 精读环节，我会用两个模型配合： - Gemini 负责宏观视角：从动机 → 数学建模 → 实验 → 结论 → 评述五个角度分析一篇论文，生成 HTML 文件（这个格式也方便写周报，比较美观，可以截图放进去）。最近我发现我的gemini变傻到极致，突然这个任务也做不好了。如果大家用gemini也有这样的感觉的话，我觉得可以在粗读的时候看alpharxiv的blog模式。 - GPT 负责更细致的补充：在 Gemini 打好的 HTML 基础上继续修改和补充细节，亦或者直接让 GPT 根据模板生成 HTML 文件，同时对照原文分屏快速阅读。具体样子可以参考我的博客：[FormalEvolve Cheat-Sheet]( FormalEvolve 论文精读 )。 > 这个流程对应的 `paper2html` Skill 我也放进了这个仓库的公开 skill 包里，适合把论文 PDF / arXiv / OpenReview / LaTeX source 转成中文 HTML 精读页。 阶段四：知识整合 精读讨论清楚了以后，带着完整上下文让 Codex 调用 GPT-Image-2 生成信息图（一般一篇论文一张足矣），再带着个人理解与这张图做交叉验证，最终存档。 在执行这些过程时，通过 Agent 的 `Skill` 打通各个环节，提升速度，带来复利。 -— 关于科研绘图 科研绘图的三个类别 科研绘图分为三类。明白这些术语，可以更好地操纵模型绘图： - 插图（Illustrations）：阐述论文核心思想的示意图 - Teaser 图：在学术界，通常指为一篇论文制作的高度浓缩、引人注目的视觉摘要，常见于顶级期刊的封面（Cover）或亮点介绍（Highlight） - Poster（海报）：学术海报，用于在会议上展示研究成果，要求信息密度高、逻辑清晰且视觉吸引力强 策略：让 AI 写操纵 AI 的 Prompt 我发现让模型去生成 Prompt 的水平远超我自己，尤其是科研绘图方面。让我自己描述，我几乎完全描述不清楚。 我会先让大语言模型理解我的论文内容，然后由它来创造和优化用于生成图像的详细 Prompt。具体来说： 1. 把论文/想法丢给 AI，先问它在内容布局、配色、字体三个维度上如何规划 2. 可以主动指定大风格，比如 Nature / Science 风格 3. 一个很有效的技巧是使用参考图：把日常积累的优秀插图丢给 AI，让它分析风格，再基于你的论文内容生成新图像。 目前我还是把 AI 作为草图助手。出了草图以后，我会尽可能让 Agent 帮我做成 slides 或 HTML，再由我自己微调。AI 绘图需要大量迭代和多次尝试。目前 AI 最适合的角色，还是创意激发和草图设计助手；所有生成结果，尤其是涉及数据和逻辑的部分，依然必须经过严格的人工审核与修正。（严肃！） 谈谈最近的 GPT-Image-2 文字回答可以解释概念，但图像可以把层级、关系、流程、对比、因果、空间结构一次性摊开。GPT-Image-2 这类模型的价值，不只是“画得像”，而是能把前面讨论出来的上下文转成可检查、可讨论、可迭代的视觉对象。 与此前的 `nanobanana` 类似，当前 image model 正在从 image generation 迈向 visual intelligence：模型不仅仅根据提示生成图片，还需要理解上下文、规划版式、保持多图一致性、执行对话式修改，并将丰富上下文转成可视化产物。 GPT-Image-2 生成图片的“自然感”能够达到“以假乱真”的水平，这也要求我们提高评价标准，从更细致的内容层面进行检查。（如根据上下文生成科研绘图，应根据自身理解与其进行交叉验证比较）我们已经正式迈入了“有图未必有真相”、“图片内容不再可靠”的时代。未来我们很难通过肉眼以极短的时间判断出来一张高真实度的图片是否可信，可能需要仔细检查细节一致性、逻辑关系、来源链路与发布主体，而不是只看“看起来像真的”。 最近我真的在看到可能任何一张社交媒体传播的图片，我都会怀疑是不是 AI 生成的（特别是在这样一个魔幻的时代，看到很多很多可能不太符合正常逻辑的事情发生） -— 关于科研写作 让 AI 多审几遍 现在 AI 审稿越来越严重，尤其是在 AI 领域。论文构思好以后，起稿阶段就可以先用相关的论文润色 Skill 辅助打稿。有了相对完整的草稿以后，建议多用专业的审稿 Agent 来审。我目前主要用 `paperreview` 和 `cspaper` 这两个网站，前者好像可以无限用，后者每个月有免费次数；另外我也做了一个可以给 Code Agent 调用的 `paperreview` Skill，放在 GitHub 仓库里了。拿到审稿意见以后，再和 AI 讨论哪里需要修改。在给导师看论文之前，先多迭代几轮，把一些潜在的小问题尽量提前解决掉。 另外，其实这样写出来的论文也更容易被 AI 认可；如果审稿人本身也在用 AI 审稿，可能会更容易给不错的分数。 和 AI 一起写，可以，但前提是它真的理解对了 一定一定一定要确保 AI 对内容的理解是正确的。一旦理解错了，后面越写越多，越写越偏，非常危险！ 沉淀不同领域的写作 Skill 不同领域的论文，写作风格是不太一样的。 有的领域注重严谨推导；有的领域看重叙事铺垫；有的领域对实验细节特别敏感。 所以与其每次都去重新教 AI “这类论文应该怎么写”，不如先拿通用的科研写作 Skill 作为底子，然后喂本领域你认可的参考论文，慢慢沉淀出一个更适合你自己领域的写作 Skill。 这个 Skill 不需要多复杂，但它最好是： - 知道你这个领域常见的论文结构 - 知道你偏好的写作风格 - 知道哪些地方要展开，哪些地方不能废话 - 知道你对实验、图表、相关工作、贡献总结的习惯要求 如果看到读起来特别舒服的高质量论文，也记得让 Code Agent 去学习一下。 三、Code Agent 使用指南 工具演变 我最先接触 Code Agent 的是 Cursor，后面逐步进化到 Claude Code 与 Codex 这些。现在构思的时候是 Claude Code、Codex、Gemini CLI 以及 OpenCode 四个一起用，通过 Claude-Code-Bridge（也就是常说的 CCB）。构思清楚以后交给 GPT 模型开 `xhigh` 模式，一步一步严格执行。通常就是睡一觉的功夫问题就解决好了。 心流状态：人和 Agent 都要减少摩擦 频繁使用 Coding Agent 以后，我反而发现自己有时候更难进入所谓的“心流状态”。原因不是 Agent 不够强，而是 Agent 介入以后，人的工作方式会被改变。GUI 来回点、鼠标切窗口、到处 `cd`、临时查命令、等 ChatGPT 解释一大段过程，这些动作单独看都不大，但叠在一起就会不断打断注意力。最后表面上是在高效使用 AI，实际上人一直在被迫切换上下文，给人带来一层“上下文税”。 人和 Agent 最好是能待在一个连续的操作回路里：搜索、打开、查看、处理、验证，尽量不要中途跳出当前现场。对人来说，CLI、快捷键和模糊搜索很重要。比如用 `fzf` 快速找历史命令或文件，用 `yazi` 在终端里浏览目录，在 macOS 上用 `open -a Preview` 直接打开 PDF 或图片。它们解决的不是“炫技”的问题，而是减少从思考到操作之间的阻力。少一次鼠标切换，少一次窗口跳转，人就更容易保持连续性。 对 Agent 也是一样。Agent 的能力不只取决于模型本身，也取决于它会不会选对工具。搜索代码时应该优先用 `rg` 或 `rg --files`，处理结构化数据时应该用 `jq`，临时 Python 依赖可以用 `uv run --with`，音视频处理应该想到 `ffmpeg`，图片处理应该想到 `magick`，PDF/LaTeX 相关任务应该知道 `poppler`、`xelatex` 这些工具。工具选错了，模型再聪明也会慢、会错、会做出很笨的方案。 所以我现在会特别注意 review Agent 的过程。重点看它用了什么工具，有没有过早退而求其次，有没有忽略 GPU、远程机器或专用工具，有没有明明存在更快路径却用慢方案硬跑。比如做 Whisper 转录时，如果本来可以走 Apple Silicon / Metal / MLX 加速，却退回 CPU 跑半小时，这就不是“慢一点而已”，而是工作流规则没有写清楚，模型也没有 get 到。我们遇到这种情况，比如一次发现 `rg` 比普通搜索更适合项目级代码检索，就不只是自己记住，而是写进 `AGENTS.md` 或 Skill。一次发现 `uv run --with` 很适合临时 Python 依赖，也写进规则。这样下次 Agent 不需要重新“猜”，而是默认走更合理的路径。 我觉得有两件事特别重要： 1. 先走最佳实践，不要一开始就退而求其次。 如果正确路径连续尝试几次仍然不可行，再有意识地 fallback，并说明为什么 fallback。 2. 人必须理解基本概念和原理，才有能力 review Agent 的自动过程。 不懂工具链、不懂任务本身的约束，就很难看出来 Agent 是真的做对了，还是只是把话说圆了。 所以 Code Agent 的“心流状态”，不是完全放手让它自己跑。更准确地说，是人把任务意图、工具选择和验收标准都约束清楚，人减少无意义操作，Agent 减少无效试错。让 Agent 在正确的轨道里高速推进。 复杂需求的处理流程 简单需求就不展开了。说说复杂需求怎么做（参考刘小排的经验）： 把模糊的想法逐渐写清楚 事实上我的很多个想法都是极其模糊的，可能我想的一两句话背后有十几个决策点需要关注。具体做法是：我会先把一开始的需求同时发给四个 AI，让它们用自己的话术整理需求，然后向我提问；这里推荐一个不错的 skill，叫做 `grill-me`。接着我不断回答各个 AI 提出的问题，AI 继续追问。这个过程要让 AI 多输出可视化的 ASCII 原型图，加深自己的理解。不断让 Claude 模型去整理各个会话的内容（Claude 的模型说得容易懂），迭代直到所有 AI 都认为当前的方案已经没有问题，或者问题可以忽略不计，最终交给 GPT 模型通过 `/goal` 模式完成即可。 各个模型特点 - GPT / Codex：比较严谨。GPT-5.5 相比 GPT-5.4 有了很大的改进，特别是在语言表达上（少了很多口癖，说话没那么令人反感了 hhh，但是貌似没有找回以前第一次用 GPT-5.2 那种感觉）。 - Claude（Opus 4.8）：表达能力强，速度快，工具调用各个能力都很优秀，但价格比较贵，不能随心所欲地用。虽然大家感觉都不如 Opus 4.6，但是至少相对 Opus 4.7 来说还是有进步的。 - Gemini：前端能力很不错，很适合用来发散思维，有很丰富的世界知识，有时候聊方案的时候会有意想不到的效果。 - Grok：搜索能力很优秀，在审查上应该也是最松的，还有 NSFW 模式。推荐 `grok-search` 这个 MCP 搭配其他 Code Agent 使用。 推荐的使用方法论 1. 多使用元 Prompt 或 Skill——比如造 Skill 的 Skill，把常用的工作流模板化。 2. 不会的多问 Agent——很多东西 Agent 可以给你讲懂，并且最终落实做出来可以用。就不断迭代积累经验。 3. 多向社区学习——参考他人的经验，不断完善自己的工作流，让自己的 AI 越用越方便，让自己更擅长与 AI 协作。 -— 四、多回顾，最好定期复盘 Skill 不是越多越好 Skill / MCP 不是见一个就安一个。 我原先就是这样，遇到一个看起来不错的 Skill，就想让我的 Code Agent 给装上。最近回头复盘才发现，自己这里已经堆了很多做同一件事的 Skill。给同样的输入，有时候模型选 A，有时候选 B，有时候选 C，结果并不稳定。毕竟模型在选 Skill 的时候，很多时候只能先看 `description`。 OpenAI 和 Anthropic 都在官方文档里提到过，相关工具最好尽量收敛一些。当工具数量太多、同类能力重叠、边界又写得不清楚时，模型更容易选错、犹豫、变慢，甚至被长输出拖垮上下文。 所以我现在会定期回头复盘自己的 Skill 和 MCP，看它们到底有没有真正给我带来增量，我到底有没有长期用到它们。如果一个 Skill 只是“当时看起来很厉害”，但后来几乎不用，或者和别的 Skill 做的是同一件事，那我就倾向于把它关掉，甚至直接删掉。相反，如果我发现一个东西自己反复在用，而且确实好用，我就会继续往里看，搞清楚它到底为什么好用，再决定要不要把它沉淀成自己更稳定的一套东西。 另外，其实现在很多网上公开的 Skill，都是遇到需求以后直接让模型写出来的，而不是“尝试 → 错误 → 修改 → 沉淀”的产物，质量未必足够好。装好以后最好自己测一下，看看“用这个 Skill”和“不用这个 Skill”之间到底有没有差别；这件事也可以交给 Code Agent 自己做。 这只是其中一个例子。和 AI 协作不是不断往系统里加东西，有时候做减法更有用：留下有用的，去掉噪声。 警惕“效率幻觉” 不知道大家有没有这种感觉：每天用 AI 写代码的时候，产出看起来很多，推进也很快，但等真正沉下心回顾时，却很难说清楚自己到底做了什么，甚至有时候连当时为什么要那样做都不一定想得起来。 某种程度上，AI 把“做”的门槛压得很低，于是人很容易在需求还没想清楚的时候就先开做。想着“这个功能先 vibe 一下再说”，结果写着写着，需求开始漂，方向盘也交了出去。你没有想清楚，它也不会替你想清楚，它只会更快地把一个模糊的东西做出来。 如果只是一味把 AI 当替身，让它一路写、一路改、一路带着你走，那本来应该由自己完成的理解、判断和取舍，也会一起被外包出去。最后得到的，可能不是更强的能力，而是一种“虚假生产力”。 对我来说，一个很重要的边界就是：我是否还能清晰地主导“问题表述”和“验收标准”。如果这两样开始模糊，那就很危险了。如果你自己都还不知道想要什么，就先别急着干。否则可能后面看起来还在推进，但推进的东西到底对不对，自己其实已经没那么确定了。 我对抗“效率幻觉”大概有两步。 第一步，是把决策可视化。 我会尽量把自己思考的东西打出来，输入到幕布里，再转成思维导图去看。这里最关键的不是工具，而是要自己动手，尽量不要复制粘贴。AI 可以辅助，但这一步我更希望是我自己在输入、在整理、在重新组织。因为只有这样，我才能确认这些内容真的是我自己想清楚的，而不是只是看 AI 说得很顺，就默认它是对的。 某种意义上，这一步对我来说是 100% 的“人在回路”。它会在物理层面强制我把思考重新接回来，同时也能保证持续专注，因为这件事没法并行，也没法偷懒。 第二步，是主动抽离。 抽离对我来说，不只是休息一下，而是一个避免局部最优、避免反刍、恢复元认知的过程。 因为和 AI 协作久了以后，很容易出现一种情况：对话越来越顺，内容越来越连贯，于是人会慢慢产生一种“我们正在前进”的感觉。问题在于，这种流畅感本身就会削弱人的警惕性。清醒的时候，你还会不断追问：这一步的依据是什么？风险在哪里？但到了后期，尤其是累的时候，人更容易接受那些“语言上讲得通”的东西，于是决策权就会默默让渡出去。 而且这种让渡通常不是一下子发生的，它更像是一个渐变的滑坡。 所以我的做法会更偏物理一些。比如我坐在电脑前工作一段时间以后，会刻意离开电脑，站起来走一走，喝点水，强制把自己从当前状态里抽出来。我的大脑并没有停止，只是像经历了一次重启。然后我再回来重新看：我们现在到底进展到了什么地步？如果我要给别人汇报进展，我会怎么汇报？我们现在做的这件事，真的是对的吗？ 对我来说，这一步很重要。因为很多时候，所谓“效率幻觉”不是你做得不够多，而是你已经做了很多，但你开始说不清自己到底为什么这么做了。 -— ## 五、AI时代生存（学习）指南 学会主动降噪 这是一个什么时代呢？因为我有每天听播客、看最新动态的习惯，很容易会有一些错觉：好像每天都有新模型、新工具、新 Agent 发布，感觉世界每天都在被重写。 变化当然是真的，焦虑也不是空穴来风，很多岗位裁员是真的，岗位收缩是真的，很多公司也确实把 AI、效率、组织重构这些话术和 headcount 变化绑在一起。但越是在这个时候，越不能被噪声牵着走，把所有信息都理解成“全完了，过一阵子就全部都失业了”。 同时，要明白很多信息本身也带着浮夸、博眼球的成分。不要失真地理解现实，不要被节奏带跑，焦虑地过日子，焦虑既不解决问题，也伤身。 主变量是人 目前，AI 可以辅助探索、生成、执行。但是不能替代你对问题表述、验收标准、必要取舍和决策的主导权。这应该要成为共识。 变化是真的，所以不能躺平；起码在现在这个阶段，大家能用到的 AI，无论是 GPT、Claude、Gemini，还是国内的 GLM、DeepSeek、Kimi、MiniMax 等等，差距没有大到离谱的程度。（当然，能用最好的还是用最好的） 更大的区别还是在于用 AI 的人。同样的一个模型，不同的人用出来的效果是不一样的。小学生和数学家用同一个 AI 去做数学，最后发挥出来的力量肯定是不一样的。所以说，这个时代，要学习。 如果把“人是主变量”这件事再画得更直接一点，大概就是下面这个样子。 不能只会用 AI 如果你完全不懂你现在让 AI 做的事情，那你几乎是无法判断和分辨好坏的，也是无法做到经验累积的，你只能做一个搬运工。而这样长期下去，过度依赖 AI 而不学习会导致能力萎缩，最终个人能力可能逐渐倒退至完全被 AI 的能力所 cover，这是很可怕的一件事情。 如果你发现 AI 在跑，你只是盯着控制台发呆，刷手机，最后再把结果原样拿来用，或许该警惕了。 学什么，怎么学 学什么呢？去学概念、原理、表达、审美、判断。 决定能不能进入一个领域的概念与原理的知识是不会太多的。抓住这些主干，你就能够更快进入这个领域的 space，知道它的大致边界、结构和内在关系。 所以不要碎片化地去追热点，什么火去学什么，可能这样学到的只是表象。应该要去学概念，学原理。建立起自己的地图，知道自己在哪，知道哪些概念是主干，哪些是枝叶。然后让 AI 帮你逐步展开、解释、练习。 这是一个非常适合学习的时代。我个人深切感受到了，很多过去晦涩难懂的知识，现在都可以让 AI 用你能理解的话解释；也可以扮演导师的角色拷打你，可以用苏格拉底式的问答逼你去把问题想得更深一点。 人机关系 有关人机关系，我想到的最差的关系是：自己不思考，只会搬运 AI 的答案。 最理想的路线是：自己有知识基础，有判断力，知道什么是好的，知道自己想要什么，然后让 AI 去帮你探索、生成、执行。 推荐的一些材料 如果你暂时找不到意义，不知道这样飞速发展的时代应该做什么，感到焦虑和迷茫，那么去学习吧。如果暂时不知道学什么，或者想从 coding agent 这条线入门，我推荐几个对我来说帮助比较大的材料： - Learn ClaudeCode / `shareAI-lab/learn-claude-code` 适合从 0 到 1 理解 agent harness。 - Auto-claude-code-research-in-sleep / ARIS 的 skills 适合做学术研究，尤其是如果将 coding agent 与学术研究结合。 - `obra/superpowers` 适合看一套完整的 agentic skills framework 和软件工程方法论。 -— 六、对于我来说，不得不思考的一些问题 当未来 AI 产品与我们生活方方面面紧密结合时，会发生什么？ 我现在也会警惕另一件事：人和 AI 协作久了以后，不一定只是效率更高了，也可能是在慢慢学会用 AI 听得懂的方式去表达自己。目标可能会变得更结构化，更 AI friendly，原本那些模糊、犹豫的东西是不是会慢慢变少？短期看，是沟通成本变低，执行变快，效率变高了；但反过来看，是不是也意味着我们也正在一点点变成一个更容易被系统理解、也更容易被系统预测的人呢？ 另外，这种变化不是单向的，AI 会通过我的历史行为学习我，而我也会通过和 AI 协作的反馈学会怎么更快地得到结果。久而久之，就可能形成一种闭环：我越来越习惯某种提问方式、某种表达风格，而 AI 也会越来越顺着我。可这就是问题，它这样做太容易让人觉得“这就是我的想法”了，实际上可能是一种坍缩。看似是 AI 和人共同进化，实际上有可能只是你变简单了。 4 个帖子 - 4 位参与者 阅读完整话题
和 Claude 协作设计的 rust 风格程序语言 Abrase ，用它写了这个视听/游戏引擎 Posara ，trailer 里所有音乐和视觉元素都是用它写的。 https://github.com/KHN190/Posara
和 Claude 协作设计的 rust 风格程序语言 Abrase ，用它写了这个视听/游戏引擎 Posara ，trailer 里所有音乐和视觉元素都是用它写的。 https://github.com/KHN190/Posara
和 Claude 协作设计的 rust 风格程序语言 Abrase ，用它写了这个视听/游戏引擎 Posara ，trailer 里所有音乐和视觉元素都是用它写的。 https://github.com/KHN190/Posara
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 https://github.com/LumenStorm/OrisonSpace Orison Space 是一款面向小说创作者的 AI 小说工作台，主要专注于内容创作上，想解决在创作过程中管理混乱、工具分散的问题。 我们把项目管理、章节写作、世界观设定、角色设定、素材库、AI Agent 协作这些功能都整合到了一个桌面应用里，希望大家从灵感记录、大纲设计、正文创作，再到图片素材生成，都能在一个统一的流程下完成，这样就不用来回切换工具了。 项目也支持本地文件管理、版本记录、AI 润色等功能。不过说实话，现在这个项目还远远谈不上完善，很多功能都还在持续打磨的过程中，体验上肯定还有不少问题。 也是闭门造车三个月了，所以这次在L站发布开源推广，也是真心想听听佬友的意见和建议。无论是功能、交互体验，还是创作流程上的问题，都欢迎各位评论与反馈。 （此为测试生成小说） 一些题外话 首先我知道，关于AI小说生成已经有相当多开源项目和闭源产品了。但我在写自己构想的SF小说时，却发现那些软件/skills是对网文投稿的特化生产，有着过于繁重的框架与skills，并不能够辅助自己创作。 随后我想到：既然coding与writing都是输出文本的过程，为什么不直接做一个IDE呢？IDE可是足够成熟的标准生产工具；为什么不模仿coding agent做一个writing agent，在这个agent下进行vibe-writing呢？这决定了项目的架构基础：模仿IDE风格，随后我与志同道合的好友Saki一起进行了agent的架构选型、研发调优、交互改善。 既然是创作，那肯定是人来主导， 人在回路式的agent交互。 三月以来，迭代到发布版为止，我们构思了多种方案，最终决定将agent的自由度调高，让用户导入skills来支持对多种题材和风格，这样才能提升agent。 当然，我们之后也会制作一套比较泛用与部分题材特化的skills，这个项目刚刚起步，距离我想象的完全形态还有漫长的距离，慢慢来吧------ 5 个帖子 - 2 位参与者 阅读完整话题
IT之家 6 月 6 日消息，科技媒体 testingcatalog 昨日（6 月 5 日）发布博文， 报道称微软已向 Frontier 项目组织开放 Scout 桌面应用，主打“常驻在线”办公协作。 Scout 类似于“龙虾”OpenClaw，是微软首个 Autopilot 智能体，核心特点是在 Microsoft 365 生态里持续待命，执行用户提出的各种需求。 根据曝光的截图，Scout 已支持 Windows 10、Windows 11 和 macOS 平台。用户登录工作账号后，进入一个较熟悉的聊天界面。 界面内可以选择模型，目前覆盖 OpenAI 与 Anthropic 的多款模型，用户还可为智能体设定“个性”。 自动化方面，Scout 不只处理日程类任务，还支持用户搭建多步骤工作流，把类似 Zapier 的编排能力直接放进桌面应用中。微软还为其加入无头浏览器模式，从而在后台更快执行部分任务。 功能扩展层面，Scout 提供集成能力与技能层，能结合本地文件、生成演示文稿、辅助编写代码。IT之家附上相关截图如下：
不是很理解多agetn协作是怎么搞的，如果是一个接着一个搞的话为什么不用一个呢，怎么搞成那种同一时间agent一起干，快速完成，而不是等上一个完成才开始，如果佬们有啥agent的知识分享，感谢各位佬们 4 个帖子 - 4 位参与者 阅读完整话题
介绍 我认为这个项目主要有这几个亮点： 目前，我们在 chatgpt 、claude 上的历史对话大多都是沉寂的，但其实每个对话历史就是一个已经有上下文的 ai 智能体，本项目它们之间彼此感知，相互通讯。 实现也很简单:call 工具往另一个 agent 的消息记录里 push 一条消息,然后立即返回——不等它跑完,所以不会阻塞你自己这边的对话。对方在后台执行,跑完后,系统把它的结果作为一条新消息投回调用方的消息里,并自动唤醒调用方接着处理。所以整个调用是异步的。 再然后，我们用树形结构把这些智能体组织起来，这样你可以有组织地有层级地放置这些智能体，每个智能体都可以感受到自己的环境信息、指导文件、技能。 截图： 地址： https://github.com/realuckyang/Arbor
最近和朋友和同事在开发的时候总是会聊到 AI 和人的协作中人在其中承担的角色问题，而且发现不同的专业线的意见基本上差异也挺大，身边搞算法的反而更激进，软件的同事更加希望自己要参与到代码审核中，所以来看看大家的意见： 软件工程手段保证输入输出符合预期就行 还是要人看一下核心代码 不管了，随便AI 怎么写，出问题了再看 其他 点击以查看投票。 1 个帖子 - 1 位参与者 阅读完整话题
譬如我手头上有 cc,codex,opencode,agy 。都接入了不同的模型。那么在同一个任务上，为了增强效率和准确性，有必要让它们协作起来吗。 我现在是这么用的，cc 做 primary agent ，让它干活的时候自己去调用 codex, opencode, agy 做并行任务，去 review 等等。然后 cc 做总的汇总和 review 。 这种用法算不算比较笨的一种。
譬如我手头上有 cc,codex,opencode,agy 。都接入了不同的模型。那么在同一个任务上，为了增强效率和准确性，有必要让它们协作起来吗。 我现在是这么用的，cc 做 primary agent ，让它干活的时候自己去调用 codex, opencode, agy 做并行任务，去 review 等等。然后 cc 做总的汇总和 review 。 这种用法算不算比较笨的一种。
譬如我手头上有 cc,codex,opencode,agy 。都接入了不同的模型。那么在同一个任务上，为了增强效率和准确性，有必要让它们协作起来吗。 我现在是这么用的，cc 做 primary agent ，让它干活的时候自己去调用 codex, opencode, agy 做并行任务，去 review 等等。然后 cc 做总的汇总和 review 。 这种用法算不算比较笨的一种。
譬如我手头上有 cc,codex,opencode,agy 。都接入了不同的模型。那么在同一个任务上，为了增强效率和准确性，有必要让它们协作起来吗。 我现在是这么用的，cc 做 primary agent ，让它干活的时候自己去调用 codex, opencode, agy 做并行任务，去 review 等等。然后 cc 做总的汇总和 review 。 这种用法算不算比较笨的一种。
譬如我手头上有 cc,codex,opencode,agy 。都接入了不同的模型。那么在同一个任务上，为了增强效率和准确性，有必要让它们协作起来吗。 我现在是这么用的，cc 做 primary agent ，让它干活的时候自己去调用 codex, opencode, agy 做并行任务，去 review 等等。然后 cc 做总的汇总和 review 。 这种用法算不算比较笨的一种。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 目前项目已支持对话和文档编写、协作，文档内对话支持获取上下文对话。抽了多次终于抽出一个舒服点的配色了。最后，欢迎大家使用和提意见。 项目地址 已添加L站友链。 github.com GitHub - haohaoxue-site/SamePage-AI: 同页AI 同页AI 项目截图 后续规划（画饼） 本地文档：在线文档虽好，但本地文档更安全 Agent 优化：目前还缺乏记忆和多 Agent 的交互 RSS：增加一些获取信息的方式，比自行构建知识库更方便一些 1 个帖子 - 1 位参与者 阅读完整话题
我签到了多个公益站，也买了几个中转站，每次用的时候都开个codex，在ccswitch点启用之后，切换到下一个，再开一个codex，自己拆分任务告诉它们该做什么，这样用着太麻烦了，我感觉自己是原始人 有可以填入多个供应商，同时让多方模型来给我做事的工具吗 比如一个最聪明的来拆任务，给出确定计划让下面模型去实施，自己再做检查 1 个帖子 - 1 位参与者 阅读完整话题
大家好，我开源了 gojaja ，中文名是：过家家。 一个本地多 AI Agent 协作的 CLI 工具，支持跨 Cursor / Claude Code / Codex 等客户端调用。 核心特性 实时看板 + RFC + 收件箱 全部以文件落盘，无远程服务端，数据完全在本地 适用场景 多任务分工协作 多角色头脑风暴 圆桌讨论 & 拍板决策 事件审计 推荐玩法 用一两个顶级模型带队，再配上一群普通模型，低成本实现高效协作。 本地启动 watch 看板，然后使用隧道穿透内网，就能在手机上远程指挥你的 agent 大军了 我自己是将这套工具用来搭建 ai 开发团队。但是这套东西不仅限于组建开发团队，理论上所有类型的组织都可以实现，期待能看到非 coding 场景的应用效果。 如果觉得有点意思，求个 Star 👉 Github gojaja
大家好，分享一下 FlowUs 团队正在做的新产品 Kollab ( https://kollab.im)。 Kollab 是什么？ 一个面向团队的 AI 原生工作空间。简单来说，就是把 AI Agents 直接拉进团队的日常工作流里，和人一起协作完成任务。 跟 FlowUs 、Notion 一样，能够创建多个工作空间。产品布局和主流 Agent 产品类似。 目前能做什么？ 文本生成、图片生成、视频生成、3D 内容生成、音频生成 支持接入 Notion 、Linear 、Figma 、Slack 、GitHub 、Google Drive 等常用工具 在 Slack / 飞书 / Telegram 里直接通过 Bot 调用 AI Agent 团队共享的项目和 Skill ，AI 可以检索和引用历史决策与文档 Kollab 正在做的事 目前在重点打造内容创作的 workflow ，把图片、视频、3D 、音频这些能力串联起来，让团队能在一个工作空间里完成从素材收集、到加工处理、到产出的全流程，直接分发到各个社交媒体。 未来会针对其他高频的工作场景，做深入优化。 欢迎试用和反馈： https://kollab.im/