★ FEATURED ARTICLE 这阵子在做一个跨模块的内部工具重构事情本身不算复杂但正好赶上团队里人都扑在别的项目上我只能一个人扛。原来预期两周收工结果四天就结束了。不是我的能力突然暴涨而是我正在用的Claude Opus 4.6让我第一次真正体会到什么叫AI协作而不是AI问答。过去两年我几乎每天和各种AI模型打交道但大多数时候依然是我问一句、它答一句或者我写一段提示词、它吐一段结果。指望它独立推进一个任务往往走不了三步就断线上下文丢了、步骤对不上了、中途还得我去喂新的指令。而 Opus 4.6 这一版明显把重心从回答得更准确转向了协作得更完整。这篇文章想聊聊我拿到新版本之后围绕AI协作这个核心做的一系列实测和思考包括它和传统对话式AI的差异、我在真实项目里的协作流程、多智能体配合的几种玩法、以及我总结的一套协作能力评测方法。如果你也在考虑怎么把这类模型真正嵌进自己的工作流而不是继续停留在聊天层面这篇应该对你有用。1. 为什么协作成了这次升级的主角1.1 从你问我答到带着任务走完全程我刚开始接触AI的时候习惯把它当成一个更聪明的搜索引擎。问个技术问题、让它改段文案、让它解释一段代码这些都很好用。但一进入真实的项目场景问题就来了一个任务往往由几十个小步骤组成中间还有各种意外的依赖和变化单轮对话根本承接不住。过去我最常见的崩溃循环是这样的让AI帮我实现一个功能模块它给出第一版代码我跑测试报错把报错贴回去它改了结果引入新问题我再贴它再改……来回七八轮之后它会逐渐忘记最初的需求甚至开始自相矛盾。我经常要手动帮它总结我们目前已经完成了什么、剩下什么、别动哪段代码。Claude Opus 4.6 给我的第一个明显感受是它开始像一个带着任务走完全程的人了。你不只是给它一个即时的问题而是可以交给它一个目标、一段背景、几个约束条件然后它会自己拆解步骤、按顺序执行、在执行过程中维护一份心里有数的进度状态。任务做到一半被打断下一次接着做它还能记得之前做到哪儿了。这种感觉像什么就像你从一个记忆力只有三十秒、需要你说一句动一下的实习生换成一个能独当一面、会主动汇报进展的项目助理。后者才是协作前者只是广播指令。1.2 三个直接改变工作方式的细节观察深入用了一周之后我注意到有三个细节是真正拉开它和上一代模型差距的地方。第一个是连续任务记忆。长上下文窗口这一两年已经不稀奇了但装得下和用得起来是两回事。很多模型上下文一大检索关键信息就变得困难开头提到的需求到后面经常被遗忘。Opus 4.6 给我的感受是它不只是装得多而是记得住、找得回。我在一个跑了三天、跨了好几轮会话的项目里中途问它我们最初确定的接口命名规范是什么它能准确地把三天前的约定原样报出来还知道哪几个模块已经按这个规范改了。第二个是工具调用后的状态恢复。新版本的 Agent 能力明显更强了它能自己调用代码执行环境、读文件、查文档。但真正让我惊讶的是每次工具调用结束、回到对话里之后它能立刻接住自己刚才的进度不会说哦我看看刚才发生了什么这种话。就像一个人放下电话之后还记得电话之前自己在做什么。第三个是目标拆解和自我验收。它不再只给你一个答案而是学会先给出执行计划做完之后还会按事先定义的标准自检一遍告诉你这一步完成了验证结果是这么回事下一步我建议这么做。等于它自己给自己定了验收标准再对照标准检查。这在协作场景里太重要了——你不需要事事追问这个做完没有做得对不对它会主动交代。1.3 革命性飞跃到底飞在哪里很多人看到革命性飞跃这种说法会本能地怀疑参数大了跑分涨了又是在吹吧。我一开始也这么想。但用下来之后我开始觉得这一版的飞跃不在单点能力上而在于**单位时间内、人类参与度可控的情况下能完成的任务复杂度**。打个比方过去AI像是给你一把更快的手术刀但每台手术还是得你亲自主刀现在它更像是给你配了一个能独立完成大部分操作的手术团队你负责主刀、关键部位和最终判断。单位人的产出就不一样了尤其是那种一个人干但要多个职能的杂活比如既要写代码又要写文档还要做测试它全能接住。对我个人来说这个飞跃最直接的体现是原来需要我写2000字提示词、反复迭代两天才能搞定的事现在大概只需要一段300字的目标说明。剩下的执行细节、过程管理、异常处理它自己扛了很大一部分。2. 实测一个完整项目里它怎么陪我干完活2.1 项目背景为什么选这个任务做测试为了验证它到底有几分成色我特意选了一个不适合AI单独干、但又不至于太简单的任务给模拟项目X一个团队内部用的数据看板系统做一次技术重构和完整文档化。这个系统牵扯的东西有点杂前端有几个老页面、后端接口耦合得厉害、数据模型结构也不规范更要命的是没有一份像样的技术文档新来的同事接手全靠问。往常这种活儿起码要一个人干一到两周精力主要耗在读代码、猜意图、和以前的同事打听历史原因上。选它的原因是任务的复杂度够但又不涉及那种需要严格保密或者强业务决策的内容而且它天然包含代码、测试、文档、数据多个环节正好能考验AI的跨职能协作能力。我的角色是验收方和目标制定者它则是执行工程师。2.2 我给AI设定的协作协议正式开工之前我先跟它约定了协作规则。说实话这部分经验比模型本身的参数更重要——AI协作的效果一半取决于模型能力另一半取决于你怎么跟它对接。我的协议很简单就四条每次开工前它先把任务拆解成子步骤和里程碑发给我确认我说可以它才动。每完成一个里程碑它输出一段简短汇报做了什么、验证了什么、下一步打算怎么做。不写长篇大论控制在几百字以内。遇到失败先自己诊断、自己修复最多重试三次。三次还不行就把问题诊断候选方案交给我决策。所有关键性改动比如改数据表结构、动对外接口签名都要先经过我确认不能因为它觉得合理就直接改。这套协议的核心思路是我降低指挥频率它提高自主性但重大决策权和最终验收权始终在我手里。我只需要在关键节点介入而不是全程盯着。2.3 一次完整协作链路记录整个项目走下来最让我满意的一次协作是处理那个数据模型混乱的老模块。整个过程大致是这么走的第一步我给它描述了问题现状指定了涉及的表单和接口文件告诉它目标是把数据模型规范化同时保证现有功能不坏。它花了几分钟扫描完相关代码输出了一份重构方案还附带它识别出的三个有风险的历史设计决策。第二步我同意了方案里的主路线但对其中一个接口拆分的处理方式提出了异议要求它保持对外签名不变只在内部实现上解耦。它没有硬拗而是重新调整了子任务顺序把接口兼容层提前到第一个里程碑来做。第三步它开始动手改代码。过程中我发现它在跑测试时反复报一个和日期时区相关的错误它没有默默绕过而是自己翻了两层调用链找到根因是原先的测试数据写死了UTC偏移量。它顺手修了测试数据还在这个模块的文档里加了一条这里为什么不用北京时间固定值的说明。第四步整个模块重构完它主动跑了一遍全量回归测试把结果整理成一张对比表哪些用例耗时降了、哪些之前一直失败的用例现在能过了、哪些遗留问题需要后续版本处理。最后把交接文档也给我写了连这个模块如果以后要加新指标需要注意什么都写好了。整个过程我从头到尾就介入了两三次每次都是做决策不是做执行。你敢信这套流程放在两个月前我自己做的话大概需要两整天而且产出质量还不一定有这么齐整。2.4 翻车记录与我的干预方式当然这不是说它不会犯错。恰恰相反我这次专门盯了它的翻车过程因为协作型AI怎么犯错、怎么修复错误比它怎么顺利更值得研究。我遇到的最大一个坑是它会对某个老接口的依赖关系过度自信。有个内部工具库它两次假设那个库自带某个解析函数结果跑起来才发现这个函数的引入方式在我们项目里被覆盖过。第一次报错它自动改了实现第二次再报错它才开始怀疑自己的前提假设回头去查调用链。总算是修好了但这个过程确实消耗了两个回合。第二个翻车发生在文档撰写阶段。它在描述某个模块的设计权衡时隐含地加了一句这是为了兼容旧版数据的考虑。我一看就知道不对因为旧版数据已经在三个月前做过迁移这个兼容逻辑是给即将接入的新数据源预留的。它搞混了时间线。这倒是提醒我一个很重要的规律它对从代码里读出来的事实很可靠但对没有写进代码的项目历史容易想当然。我的干预方式是所有它写给外部读者看的内容交接文档、设计说明我都会快速通读一遍重点看那些它自己推断出来的背景描述而不是代码本身。代码出错很容易通过测试发现反而是看似合理但背景错误的文字描述是协作型AI容易埋雷的地方。讲完真实项目里的协作体验紧接着我想聊聊现在很多人都在尝试的多智能体协作——也就是让AI和AI之间直接配合干活而人只在边上做调度和决策。3. 多智能体协作让几个AI角色一起干活3.1 主从模式总控分发任务的团队架构以前用AI干活是一个人对一台机器现在多智能体协作意味着你手里可以有好几个AI角色每个角色负责一种职能然后让它们相互配合。最常见的架构是主从模式类似一个项目经理带着几个工程师。我在一个实验性项目里搭过这么一组配置一个总控AI负责理解目标、拆分任务、分发指令、汇集结果下面挂着几个执行AI分别负责编码、测试和写文档。总控AI不写具体代码只管理进度和检查交付物执行AI不关心全局规划只专注于自己被分配的那块活儿。这样分工的好处很明显上下文更干净。每个执行AI只需要维护自己那块任务的状态不会被整个项目的无关信息撑着总控AI则专门维护全局视图。实测下来多智能体架构在任务边界清晰的场景里比单个AI单打独斗要稳定得多尤其是长链路任务不太容易出现做到后面忘了前面需求的问题。3.2 会诊模式让AI互相质询找方案漏洞第二种我试验过的模式更有意思我管它叫会诊模式。做法是同一个高难度问题不交给一个AI单独回答而是让几个独立会话分别给出方案然后让它们互相审阅、互相质疑。比如我有一次处理一个数据迁移方案涉及停机时间评估和回滚策略。我给两个独立的AI会话发了同样的背景资料要求它们各自给出方案。等它们都交卷之后我再把方案A发给方案B的会话让它挑毛病、提反驳再把方案B发给方案A同样挑毛病。最后我拿到的不是一份方案而是一份方案交叉质询记录。这个方法特别适合那种看似完美但有隐藏盲区的场景。单个AI常常会在自己的推理闭环里保持自信但一旦被另一个会话指出它没考虑到的边界条件它往往会承认你说得对我没考虑到。当然我不建议用这个方式处理所有问题主要是成本翻倍只有当方案风险高、出错代价大的时候才值得做。3.3 配置多智能体时最容易翻车的四个点实验做了几轮我总结出几个关键教训如果你们要自己搭多智能体架构这几个点最好提前注意。上下文预算要提前分配。总控如果塞满了全局信息就没有空间留给新任务执行AI如果被塞了过多无关背景响应质量会下降。我的一般做法是总控保留全局摘要和当前进度执行AI只拿自己需要的任务细节。任务粒度不能太碎也不能太大。太碎了智能体之间频繁交接光传递损耗就吃掉大半效率太大了执行AI一次处理不了又退回单智能体的老路。我试下来一个子任务最好控制在一个执行AI连续工作10到20分钟能完成的量级。要有重试和熔断机制。子任务失败是重试、换方案、还是交给另一个智能体接手这套规则要在开始之前就定好不然会看到几个AI角色互相推诿的场面。必须保留人工仲裁席位。多智能体之间意见不一致的时候不能放任它们互相说服因为可能陷入无限循环。我一般规定两个智能体来回冲突超过两轮自动升级给我来拍板。以上这些结构、架构层面的东西聊完我再来分享一套更实操的内容——我到底是怎么评测一个AI的协作能力够不够格的。毕竟说得好听和真的好用是两码事。4. 协作能力量化评测六个检查项4.1 六个维度的评测表我先放一张我自己整理评测用的表后面再逐项展开讲。检查项测试方法合格标准任务交接时的上下文保留率让AI处理一个任务中途打断、隔一段时间再让它继续能准确说出已完成的步骤和下一步计划不需要重新喂背景工具执行后的状态复盘能力让AI调用外部工具如搜索、执行代码结束后问它刚才结果能用自己的话总结执行结果还能自然衔接原任务主动澄清与盲猜的比例下发一个有明显歧义的目标观察它的第一反应面对关键歧义会先提问而不是假装理解、硬做一个错误方向长链路任务中的记忆稳定性给它一个需要10步以上才能完成的任务在步骤间穿插无关信息能忽略干扰准确引用较早步骤中提到的约定不前后矛盾双向数据读写协作能力让它读取一份外部文档据此修改另一份交付物能准确提取文档中的关键约束并在交付物中完整落实失败恢复策略多样性故意让一个环节执行失败观察它后续处理至少能提供修复、改道、求助三种策略中的两种不重复试错4.2 每个检查项的具体测试方法任务交接时的上下文保留率这个检查项是我认为最基础、也最容易被忽略的。很多模型单轮对话力很强但一断就失忆。我的测试方法很粗暴给它一个稍微复杂的任务做到一半我故意隔两三个小时再回来不重复任何背景直接说继续吧。看它是不是一脸茫然。Opus 4.6在这个测试上说实话是目前我用过的模型里表现最好的之一它甚至会自己补一句根据我们之前确定的方案我接下来准备执行第三步。工具执行后的状态复盘能力考验的是模型对外部世界的感知密度。模型调用工具本质上就是伸手去碰真实世界碰完回来能不能清楚描述发生了什么决定了它能不能在真实环境里靠谱干活。我的测试方法是让它去读一个文件目录然后让它基于读到的内容修改另一份文件。如果它只是机械地说我读完了但对读到的内容毫无提炼协作感就大打折扣。主动澄清与盲猜的比例这是我在实际协作中最看重的一项。一个能干的协作者接到一个模糊指令时应当说出这里我需要确认一下而不是闷头开干。我实测过一个场景我故意下发一个没有指定输出格式的任务观察它是否主动问我你想要的是表格还是摘要。Opus 4.6大多数时候会主动追问而且追问的点往往是真正会影响产出的关键歧义。长链路任务中的记忆稳定性需要在任务中间穿插干扰。比如我让它处理一份文档中间突然问它一个和任务无关的问题再让它回到原任务。它如果能丝滑地哦对刚才我正改到第二章节结构说明它在工作记忆的保持上确实做了功夫。双向数据读写协作能力考验的是模型能不能把读进来的信息真正用到写出去的内容里。我常用的测试是给它一份技术规范文档再让它帮我把系统架构图转成文字说明看它会不会把规范里的关键技术约束转述清楚。只会复述原文档重要段落、不会主动深化应用的模型在这一项上会明显露怯。失败恢复策略多样性这一点是我踩过几次坑之后才加的。最早我遇到过那种撞了南墙不停下还要继续撞的模型非常崩溃。后来我测试的时候会故意给它一个不可能实现的需求比如让它用某个已被移除了API的库观察它是反复用同一种方法失败还是能切换思路。能说出这个方案A走不通我可以试试方案B或者换个思路用方案C实在不行我会来找你确认需求的才是真正适合做协作者的。评测完之后我再讲点更偏向管理层面的内容这套能力落到一个团队、一个工作流里到底该怎么排兵布阵。5. 把协作型AI真正嵌进团队流程5.1 岗位职责怎么重新划分很多人把AI引入工作流的做法是每个活都让AI干一遍试试结果发现有的活它干得好、有的活它干得烂整体体感混乱。我现在的建议是先把岗位职责重新划分而不是把活直接丢给AI。我比较推荐的三角色模型是这样的目标负责人人负责定义为什么做、做到什么程度算好以及最终拍板。这个角色不能交给AI。执行者AI负责怎么做、用什么工具、按什么步骤。包括代码实现、初稿撰写、数据分析、过程追踪。质检者人负责抽查AI的产出尤其是那些看起来合理但背景错误的部分。不一定全部检查但关键交付物必检。实际落地时我见过最顺滑的做法是在任务启动会上目标负责人花30分钟把背景、目标和验收标准说清楚之后AI进入执行状态目标负责人只在里程碑节点出现比如每天固定时间看一次进度报告而不是全程盯着。5.2 给AI写任务交接文档的模板提到这里我不得不强调一件事给AI的任务说明书不要写成提示词要写成交接文档。提示词是你临时起意的一句话交接文档是把一个任务完整交出去的标准材料。两者的效率差简直是一个天上一个地下。我平时用的任务交接文档模板是这样的你们可以直接抄走用任务背景这个任务为什么存在前置发生了什么相关文档链接。目标定义最终交付物是什么最好有可验证的标准。范围边界哪些事情必须做哪些事情明确不做。已知约束技术栈限制、合规要求、风格规范、历史包袱。可用资源可以访问哪些工具、数据、仓库、API。汇报形式多久汇报一次汇报用什么格式里程碑怎么定义。风险提示已知的坑、以前踩过的雷、需要重点注意的部分。我给个示例片段任务背景模拟项目X的数据看板系统已完成初步重构但技术文档缺失 新同事接手成本高。需要补齐一份开发、运维、使用三个视角都覆盖的文档。 目标定义交付docs/README.md包含系统架构说明、模块清单、 启动步骤、常见问题排查四大部分。 范围边界不修改任何源代码不新增功能只做文档撰写与整理。 已知约束文档中涉及的技术命名必须与代码保持一致不得简化 命令示例必须基于macOS环境。 可用资源代码仓库本地目录 /path/to/project数据库结构说明在 /docs/db_schema.md。 汇报形式完成文档大纲后先汇报一次确认结构后再逐模块填写。 风险提示之前有过一次文档把旧版兼容逻辑描述成新版预留逻辑的 错误这次涉及历史设计决策的说明必须对照git提交记录核实。把这样一份交接文档发给协作型AI它开工后的自主性会非常强。你也可以把文档里的风险提示部分当成一种经验传承——AI协作得好不好某种程度上取决于你有没有把自己的经验有效传递给它。5.3 成本与质量什么任务该放手什么任务要留人最后一个落地建议是关于成本与质量的平衡。我的经验法则很简单重复性、规则清晰、出错影响可控的任务可以全自动放手高不确定性、涉及对外承诺、出错代价大的任务必须保留人工在环。举例来说整理一份周报数据初稿可以全自动给对外客户的价格方案计算器加一个新计费规则就必须有人工复核因为一处算错影响的是合同金额。还有生成会议纪要的待办清单可以全自动基于这份纪要对外回复合作方就不适合全自动因为对外文本的语气、敏感度需要人判断。成本侧的量级估算我也分享一下。有人担心AI自主执行是不是很费钱。我的观察是确实会消耗更多token因为它在自主执行中会做更多工具调用和中间推理整体消耗可能比单轮问答高一个数量级。但是如果你的时间成本高于token成本大多数专业工作者的确如此这笔投入是划算的。一个需要我花8小时完成的中型任务让AI自主执行大概消耗对应的API费用外加我30分钟到1小时的检查和决策时间。 算下来时间和金钱上都是省了的。6. 协作型AI普及后哪些能力变得更稀缺6.1 会被压缩的技能和会被放大的技能用了Opus 4.6这个版本一个月我越来越确信一件事协作型AI普及之后有一批旧技能会迅速贬值但另一些软技能会变得前所未有地值钱。会贬值的技能包括各种工具的具体操作步骤毕竟问AI更快、更准基础代码片段的编写和排错AI一下子就写完了信息检索和初步整理它做得又快又好以及对标准化文本的模仿能力公文、通知、模板化文案。会被放大的技能则是定义问题、判断价值、把控责任、设计协作规则。你不会因为写代码快而变得稀缺但你会因为能准确判断这个功能到底该不该做、做到什么程度、风险在哪儿而变得值钱。AI什么都能执行但它依然需要一个真正懂得为什么要执行这个、不执行那个的人站在旁边下判断。另外还有一个被低估的能力校验AI产出的敏感度。就像我前面说过的AI会产出一大堆看起来合理但故事背景错误的内容这时候谁能快速抓住那个错误谁的价值就体现出来了。这种能力来自对业务本身的理解而不是对AI工具的理解。6.2 我对AI同事的最终判断说实话在真正体验到Claude Opus 4.6的协作能力之前我一度觉得AI替代人的叙事很夸张。但现在我改变了一点看法与其说它替代人不如说它正在替代执行这个动作。人类从执行中腾出来的注意力必须流向更上游的决策与创造。这套协作模式对我自己最大的改变是过去我很多精力都耗在完成任务本身现在我更多精力放在设计一个AI能帮我完成它的流程。所谓革命性的飞跃如果让我一句话总结那就是AI第一次从回答问题的工具变成了分担任务的协作者。工具是你用完之后放下的协作者是你需要与之对接、分工、磨合的。最后分享一个我个人的体会。在我把Opus 4.6引入日常工作的这段时间里我自己也养成了一套简单的协作守则凡是交给它的任务我先让它把目标拆解计划写出来给我确认凡是它给出的重大决策我要求它至少给两个可选的方案并说明取舍凡是它完成一个模块我让它顺手写一段交接记录方便我或者同事随时接手。这三条规则看上去简单但确实帮我避掉了不少后续麻烦。如果你也想从AI问答升级到AI协作我的建议是别一上来就搭复杂的多智能体架构先挑一个两周内要交付的小任务写一份任务交接文档设定几个里程碑认真体验一遍目标定义—自主执行—人工验收这个闭环。跑通一次你对什么叫AI协作的理解会比你看一百篇文章都深。
阅读完成 · 觉得有帮助？
