我用 Codex 的时候，经常会同时开着几个任务。这样的用法已经持续很长一段时间，我以前没有特别想过，只是觉得一个任务反正也要等，多开一个能省些时间。
最近写两份需求文档时，我又像平常一样开了两个任务。一个还在处理，我先去看另一个已经返回的内容，讨论完再切回来。来回几次以后，我突然注意到，Codex 可以同时处理两份文档，我却没有在同时思考两份需求。
看第一份时，我需要回到它的业务背景里，想起前面已经讨论到哪里，为什么要这样写。再看第二份，又要换回另一套上下文。两项任务确实在同时进行，到了需要判断的地方，我还是只能一项一项地处理。
过去我只是把这当成一种节省等待时间的方法。那天来回切了几次，我开始想，Agent 同时运行的时候，人到底在同时做什么？
Agent 让几条工作线异步推进
没有 AI 的时候，我也会同时负责多个项目。产品经理很少能把一件事从头做到尾，再开始下一件。一个项目在等研发反馈，另一个还在确认需求，手上可能还有已经进入验收的事情。
不过，以前这些项目之间通常有不少等待。别人晚一点回复，会议第二天再开，设计稿下午才给。几项工作虽然同时存在，反馈落到我这里的时间往往是错开的，我可以在一段时间里先处理其中一项。
现在，任务发给 Agent 以后，它不需要我一直盯着也可以继续处理。我去看另一份文档，前一个任务并不会停下来。原本隔着半天甚至一天才会返回的内容，可能在同一个小时里陆续出现。
我不会因为某个任务刚有了结果，就马上停下手里的事情去看。如果我正在读一份需求，脑子里刚把前后的关系理清楚，这时跳到另一份，回来还得重新想一遍。新结果先放在那里没有关系，等当前这部分处理到一个可以停下来的位置，我再切过去。
我把这种工作状态暂时叫作「多线程共创」。它和开了多少个窗口没有直接关系。把一项任务交给 Agent 继续处理时，我需要记得它前面讨论过什么；结果回来以后，我还会继续看、继续改。碰到需要做决定的地方，其他任务即使已经有了新结果，也可以先放在那里，等我把眼前的问题处理完再说。
我没有为此设计一套很复杂的记录方法。大多数时候，切换任务前后的上下文还是靠脑子记。只有当我和 AI 已经讨论了很长一段，形成了比较完整、之后还要继续使用的结论，我才会让它写进文档，作为备忘。文档可以帮我少翻一些对话，但它代替不了我对前面逻辑的理解。
多线程共创，本身也是学习
把一项工作完整地交给 AI，当然很省心。格式转换、批量整理，或者目标已经非常清楚、结果也容易检查的任务，我也会直接让它做完。并不是每件事都需要人一直参与。
需求文档很难一直这样处理。我经常是在写的过程中才发现，最开始以为已经说清楚的地方，其实还有一些问题没有考虑到。AI 把内容展开以后，我可能会发现某个方案放到实际流程里并不合适，或者原来的需求本身还需要调整。这个时候，文档写完不代表工作已经完成，我得先回到问题本身，再决定后面怎么改。
我自己做软件和游戏的时候，也经常是在过程中才会发现一些之前没有想到的问题。AI 有时候能很快给我资料和方案，但是这些资料和方案到底合不合适、适不适用，有没有要调整的地方，还是得实际做的时候才能发现其中的一些问题。
我说的这种共创也不局限在产品经理的工作里。我平时写文章、做软件和游戏，或者学习一个陌生领域，很多时候都不是先把一切想明白，再让 AI 按照确定的方案执行。我通常只有一个大致目标，实际做到某一步，才会发现前面漏掉的东西。我比较在意的其实是 build，是创造的过程。
AI 在这个过程中会带来很多我原本不知道的资料和思路。我会先试着理解，再放进正在做的事情里。实际做下去以后，如果发现方案并不适用，就回到前面调整。有时候，原来只是想解决一个局部问题，查着查着却发现最开始的目标也要改。这些变化很难只靠等待最后一版获得。
如果我只把任务发出去等结果，拿到的也许是一份没有明显错误的成品，但我不一定知道它为什么这样处理，放到实际项目里又需要怎么调整。AI 替我省掉了中间过程，我也就没有经历那段学习。
哈佛商学院、MIT Sloan 等机构的几位研究者，观察了 244 名 BCG 顾问使用 GPT-4 完成同一项模拟商业决策任务的过程。任务结束后，研究者根据顾问实际使用 AI 的方式，归纳出了三种做法。
一部分顾问会和 AI 反复讨论，让它参与解决问题的整个过程。另一部分顾问自己保留分析框架，只在资料、方法或文字调整等具体环节使用 AI。还有一些顾问把大部分分析过程交了出去，用很少的几次交互等待一份完整答案。
研究者记录到，自己保留分析框架的顾问加强了原有的专业能力，持续和 AI 共同分析问题的顾问积累了更多与生成式 AI 协作的能力。主要等待完整答案的人，在这两类能力上都没有出现相同的变化。
这项研究目前还没有作为期刊论文正式发表，公开的是供讨论的工作论文。三种使用方式也不是研究者事先安排好的实验组。任务结束后，研究者才按照顾问实际怎样使用 AI 进行归类。因此，它能说明使用方式和能力变化之间存在联系，还不能据此判断因果。
我读完以后，会想到自己使用 Codex 时的区别。目标明确、结果容易检查的任务，我愿意直接等答案。碰到需要创造的工作，我会让 AI 自己处理一段，再回来和它继续讨论。这种方式没有完全托管省心，我得花时间理解和修改，但也正是在这个过程中，我会接触新的知识，原来的想法也可能跟着变化。
几项这样的工作同时进行以后，我会反复回到不同的任务里，看看 AI 这次给出了什么，原来的想法有没有要调整的地方，然后继续做下去。对我来说，参与这个创造过程本身很重要，多线程处理能力也就会直接影响我能不能同时把几件事做好。
产品经理可能更适应这种工作方式
产品经理平时就在几项没有结束的事情之间切换。做得久了，会更熟悉这种节奏，但经验本身还不够。一个产品经理如果想把工作做好，本身就需要比较强的逻辑思维能力。设计一项需求时，我需要先弄清它要解决的问题，再把方案放回现有产品和实际业务中去看。有时候一个局部方案单独看没有问题，和原来的规则放在一起，才会发现前后的逻辑对不上。
认知心理学里有一个概念叫「问题状态」。研究者用它描述人在处理复杂问题时暂时保留的中间信息，例如事情进行到了哪一步，当前结论依赖什么，接下来还要验证什么。实验发现，当两项任务都要求人持续保留这种状态时，它们之间的干扰会明显增加。
实验里描述的这种干扰，我在切换 Codex 任务时也能感觉到。页面重新打开并不难，难的是重新回到当时的思考里。如果上一项任务还没有想清楚，它也会继续占着一部分注意力。这也是我不会在每个任务返回时马上切过去的原因。
长期面对多个项目，并不会自动让一个人擅长多线程。前面的逻辑没有理清，切换得再快也可能继续沿着错误方向处理。我觉得产品经理有一定优势，是因为这个岗位本来就要求人恢复上下文，检查一项方案与现有产品、业务规则之间的关系。这是我从自己的工作经验出发做的判断，目前还没有跨职业研究能证明产品经理确实比其他职业更擅长处理这种多线程工作。
多线程也不是越多越好。2015 年，几位研究者分析了意大利一家企业研发部门的项目团队。他们统计团队成员还同时参加了多少其他团队，再把这种多团队参与程度和当前团队的绩效放在一起比较。结果呈现出倒 U 型关系：参与程度很低或很高时，团队绩效都相对较低，中间一段的表现更好。这项研究讨论的是团队绩效，不能直接用来计算一个人该开几个 Agent，不过那条曲线给了我一个参照。并发增加到一定程度以后，切换、理解和检查结果所花的精力也可能抵消一部分原来获得的效率。
我把一个人在某类任务中能够从并行获得收益，同时还可以保持理解和判断质量的范围，称为「有效并发区间」。这是我自己的说法，论文里没有这个术语。熟悉的任务可以同时处理得多一些，换到陌生领域，AI 给出的资料需要逐项核实，数量不多也可能花掉很多精力。
以后，把任务交给 AI 会变得很普遍，结果也会回来得更快。等我回到某项任务时，能不能想起前面为什么这样做，还有哪些问题没有解决，会直接影响我接下来能不能继续判断。
每个人能同时维持多少条任务线，都有自己的范围。具体是几条，没有那么重要。多线程共创也不要求人在同一时间思考几件事。几件事可以同时进行，到了需要判断的地方，我还能想起这项任务在解决什么问题，前面做过哪些判断，然后继续处理。我觉得这种能力会成为个人核心竞争力的一部分。