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