小研发团队有一种典型瓶颈：不是算力，不是账号，是技术核心那个人。策略他定、数据他备、结果他判，全队等他喂任务，他一请假，项目就停摆。这篇文章复盘我们自己团队的解法——把一件事拆进多个 session，再用一个总控按预定义流程调度并行，以及每个设计背后为什么必须这么做。
一、十个人的吞吐，为什么系于一个人的清醒小时数
一个十人量化团队的典型一周是这样的：技术负责人周一花半天把策略思路讲给两个研究员，周二等他们准备数据，周三数据出了问题他亲自下场修，周四回测结果要等他判读，周五所有人等他定下一周方向。五个人的实际产出，取决于他一个人那天还剩多少清醒的小时。
软件外包团队的结构完全同构。客户一改需求，只有技术负责人能判断影响面：哪些接口受牵连、测试要不要重跑、排期往后挪几天。全队的排期悬在他回复的那几条消息上，他在开会，整条线就排队。
这类团队真正的瓶颈从来不是设备，也不是 AI 账号，而是一个组织事实：所有关键判断都要过同一个人的脑子，所有任务都要经同一只手分发。他一天只有八小时，项目节奏就被物理地锁死在他的时间上。更累的是，他的时间里真正用于判断的部分其实不多，大量消耗在催人、等结果、同步信息这些事务性动作上。
我们自己的小团队早期也是这个形状。后来我们把解法做进了一款叫马良 Harness 的研发协作产品里，核心是两个概念：多 session，和总控。下面先讲原理，再讲实现。
二、一个会话塞三件事，为什么必然串台
先看旧的工作方式。一个研发项目里天然有好几条支线：以量化为例，是策略探索、数据准备、回测验证；以软件外包为例，是接口开发、联调、测试。过去这些事全挤在一个 AI 会话里——上午聊策略思路，中午让它顺手清洗数据，下午在同一串对话里跑回测。
这会产生两个必然的问题。
第一是上下文互相污染。大模型对"当前任务是什么"的判断完全来自上下文，而上下文窗口是有限的。三个任务的材料挤在一起，它开始遗漏早期约定，拿着准备数据的指令口吻去改策略代码，人不得不一遍遍往回拽。这部分返工，往往比它省下的时间还多。
第二是无法并行。会话只有一个，事情只能串行，一件没跑完，下一件只能等。三四个同事等同一份数据和同一个结论，等的人闲着，被等的人加班。
混乱还会沿着会话传染给接手的人。上下文最脏的时候，AI 给出的代码看似能跑，实则混着上一个任务的残留假设；同事基于它继续改，错误被一层层盖住，等联调才暴露，谁也说不清是哪一步引进去的。一个会话的边界失守，常常变成整条线的人一起返工。
有人试过用"多开几个浏览器窗口聊同一个项目"来解决，这只解决了表面问题：几个对话彼此不知道对方产出了什么，中间产物还是靠人复制粘贴搬运，和开一个会话没有本质区别。真正需要的是两件事同时成立：上下文彼此隔离，产出又能互相引用。马良点睛在自己团队里踩过这个坑之后，才把"上下文隔离 + 产物互通"做成了产品的底层设计。
三、多 session：每条支线一个干净上下文，在后台同时跑
这个工具的做法是把支线拆成多个 session。
策略探索在一个 session 里，背景、假设、文献讨论全是策略的上下文；数据准备在另一个里，对接的是数据源、清洗规则和更新节奏；回测验证再开一个，窗口、基准、风险指标自成体系。每件事都在自己干净的上下文里完成，任何一条线的结论出了问题，回去复盘只看这一条线。
拆开之后，并行才成为可能。这些 session 可以在后台同时执行：数据在后台拉取、清洗、校验，回测在另一个窗口挂着跑，人在前台继续打磨策略。机器在干活，AI 在干活，人只干人该干的那部分。例如，可以把满足依赖条件的任务安排在后台执行，待结果就绪后再集中审阅。
每条支线的试错也互不污染。在数据 session 里试过五种清洗方案、否掉四种，这段弯路不会搅乱策略 session 的讨论；回测 session 里留下的每一组参数和结论，可以被单独翻出来复查。
但拆开不等于老死不相往来——这是很多人做任务拆分时漏掉的半件事。需要共享的中间产物，比如清洗好的数据集、回测产出的报告，通过工作区路径互相引用：数据 session 把产物落在约定路径，回测 session 直接读取。各 session 的上下文边界仍然清晰，数据 session 不会因此掺进策略讨论，策略 session 也不必重复一遍清洗规则。分得开、又连得上，拆分才有意义。
四、总控：把"先做什么、什么算过关"从脑子里搬进流程定义
多 session 之上是总控，它解决的是"谁来派活"的问题。
你把一个想法提给总控——比如"这个因子组合，换三个市场窗口验证，数据更新到最新"——总控基于事先定义好的流程，自动调度各 session 配合：该准备数据的去拉新数据，该回测的配置三组窗口，该验证的做显著性检验，任务在后台并行铺开。人不用盯每一步；支线跑完，再点进任何一个 session 直接调整、追问、加验证，调完它自己接着跑。
关键在于"流程定义"这四个字。过去先做什么后做什么、什么结果算过关、异常往哪条支路走，全在技术核心一个人的脑子里，是他的私人手艺。现在这些经验被显性地写下来，成为团队共享的东西。比如把"数据更新到最新交易日、回测窗口不少于三组、夏普低于阈值自动转去做归因分析"写成规则，总控调度的每个 session 就有了过关标准和异常支路——它不是简单排队跑任务，而是按一个有经验的技术负责人的判断在跑。
成果同步也不再靠开会。任何一个 session 所在的工作区路径都可以复制给协作者：负责人早上看完回测结果，把路径发给风控同事，对方打开就是最新的数据和结论，直接在同一上下文里做复核；有异议，批注挂在对应位置，不用再拉一场对齐会。项目不再卡在"等老板抽空讲一遍"这个动作上。
这里值得回答一个常见质疑：这和给每个人配一个独立的 AI 助手有什么区别？区别是结构性的。十个孤立的助手加起来，依然是十个等着人喂的嘴，派活的负担一点没少；一个总控加一套定义清楚的流程，才是一支能自己往前跑的队伍——派活这个动作本身被自动化了。马良 Harness 从第一版起就把总控放在多 session 之上，而不是反过来，因为我们清楚：没有总控的多 session，只是把一个人堵在一个会话里，变成堵在十个会话里。
五、项目速度的决定项，从加班变成流程资产
旧模式下，项目速度取决于核心成员今天加不加班、状态好不好、愿不愿意带人。这些东西不可复制，人一走速度就塌。
这套机制里，项目速度取决于流程定义得清不清楚。而流程是可以沉淀、复用、持续改进的组织资产：第一个策略跑通时定义的流程，第二个策略改几个特征就能用；老员工写的流程，新员工照着就能发起一整套并行任务。团队的产能不再系于一个脑子，而是长在系统里。
新员工入职的场景最能说明这套机制。过去，任务怎么拆、结果怎么盯，往往要反复向负责人请教；现在打开总控里已有的项目，流程定义、各 session 分工、每一步的结果与批注都在，可以在负责人确认后沿用同类流程。人的经验第一次像代码一样被复用，而不是靠口传心授慢慢流失。
流程还能在项目之间复利。第一个项目踩过的坑——哪类数据要先校验、哪个环节必须人工复核、异常结果走哪条支路——沉淀在流程里，下一个同类项目直接继承再微调。团队接的项目越多，流程库越厚，新项目启动成本越低。过去这些经验存在核心成员脑子里，人一走即清零；现在它们留在系统里，成了团队真正的家底。
分工的本质没有变：维护流程、分发任务、盯并发、记进度，这些对人是巨大消耗的事，AI 做起来是不知疲倦的循环；人只在需要创造和拍板的节点出现，判断方向对不对、结果信不信、异常怎么处理。多 session 发起的请求还会自动流进多账号额度池，由空闲账号分担并发——减少忙闲不均造成的等待，达到原生上限时仍按规则排队。
你们团队里，项目卡住最常是因为哪一类事——是等技术负责人派活、等数据，还是等一个关键判断？
热门跟贴