评估 LLM 研究工具时，可以考察它能独立推进多长一段工作。写完一份因子实现之后，还要检查数据条件、提交计算、处理异常、比较结果。如果每一步都要停下来等研究员接手，整轮研究仍然被人的时间切成一小段一小段。
模型能力的提高，让更长任务的自动化成为可能，也对研究基础设施提出了新的要求。现有工具往往默认使用者是人：人知道某个字段怎么理解，知道结果应该去哪里找，也知道一个报错究竟意味着什么。让 LLM 进入研究流程，就得把这些隐含前提重新处理一遍。
下一阶段，团队之间的差距将越来越取决于是否完成这层改造：从围绕人的操作习惯组织工具，转向以 AI 为主要调用者设计研究基础设施。研究员更熟练地使用 AI 固然有帮助，但数据接口、计算系统和验证流程如果仍要靠人逐步衔接，提效就难以扩展。以 AI 为核心，指的是让模型能够连续推进边界清楚的研究任务；研究方向、验收标准和关键决策，仍由人负责。
让研究产能更多地依靠计算资源
LLM 现在值得重视，是因为它开始能够把理解任务、调用工具和根据反馈修正连在一起。研究员描述一个想法，模型形成候选，交给系统检查，再根据返回的问题调整。这个过程一旦接通，单次生成是否完美就不再是唯一的决定因素，系统能否帮助它发现错误、继续推进，同样重要。
一条由人逐项推动的研究流程，产能很容易受制于研究员同时能照看多少件事。数据准备、实现、计算、诊断，任何一步暂时没人处理，后面的工作就只能等待。给每个人配一个代码助手，确实能缩短实现时间，但这些等待仍然存在。
进一步的改变，是把常规步骤之间的交接也交给系统。满足条件的实验继续执行，能够识别的问题进入修正，超出既定范围的情况再交给人。研究员从反复启动任务，转向决定哪些问题值得启动、结果是否值得继续追问。同一段时间里，更多假设才有机会被认真检验。
这时，研究产能就有了一部分随计算资源扩张的空间。不过，底层计算必须跟上。模型持续产生候选，后端却只能慢慢排队，或者算完之后拿不到可用结果，研究速度仍然上不去。低成本的检查尽早做，昂贵的计算有序执行，结果及时回到下一轮研究，这些工作会直接影响一个想法多久才能得到反馈。
当研究员需要同时照看越来越多的 Agent 对话框，人工协调本身就可能成为瓶颈。反复出现、已有明确规则的判断，应当逐步交给系统处理。人的介入集中在例外和研究判断上，自动化才有继续扩展的余地。否则任务越多，研究员越像一个忙于转发消息的调度员。
AI friendly，要让模型少依赖人的临时解释
AI friendly 可以用一个实际标准来衡量：模型拿到一个研究任务以后，能否从系统里查到它需要的能力和约束，得到可信的反馈，并据此继续工作。
以候选生成与校验为例，模型先了解执行系统支持什么，再在这些能力范围内形成候选。候选交给实际执行系统校验，错误返回给模型，在有限次数内修正。这样，一些原来需要人复制报错、解释问题、重新提交的工作，就能在这个过程中完成。处理不了的情况仍然明确交给研究员。
这件事看起来只是少了几次操作，但它改变了协作方式。研究员不必为每一次尝试重新讲解整个环境，模型也有了判断下一步的依据。模型提出什么，执行系统是否接受，为什么没有接受，几者之间形成了可以检查的联系。
前提是系统给出的信息足够可靠。能力说明与实际行为必须一致，提前检查和真正执行也要遵守相同的规则。否则模型完全按照文档工作，仍然可能得到错误结果。这样的偏差靠多写几句提示词很难补回来，因为问题就存在于研究工具本身。
研究任务还需要有独立于对话的状态。一次会话结束，已经提交的计算和已经产生的结果不能跟着失去线索。模型重新接手时，应当能知道哪些工作完成了、哪些仍在等待、哪些结果存在缺口。任务管理和结果查询在这里的价值，是把一段被打断的研究重新接起来。
减少交接时必须由人补齐的信息，模型才能沿着已有工作继续。能力发现、真实校验、明确反馈和可查询的记录，都在为此提供条件，也构成了 AI friendly 的具体工程要求。
研究提速之后，验证要更早介入
当实验越来越容易发起，结果的检查很快就会成为另一处瓶颈。模型可以交回很多候选，研究员却没有同样多的时间逐一重建它们的来龙去脉。如果省下的实现时间全部花在事后排查上，研究效率并没有改善多少。
所以，验证需要随着研究过程一起发生。输入是否满足条件、结果是否完整、比较口径是否一致，这类有明确规则的问题，应尽量由系统检查。研究员收到结果时，这些基本事实应当已经清楚，剩下的精力才能用于判断假设、解释异常和设计下一轮实验。
量化研究还有一层更麻烦的问题：得到一份漂亮的回测，并不能说明研究过程可靠。一个结果经历了多少次尝试，哪些条件是在看到表现以后修改的，最后留下来的候选从怎样的筛选过程中产生，这些都会影响证据的分量。自动化把尝试变得更便宜，也让记录整个尝试过程变得更有必要。
实验开始前，可以先记录研究假设、比较条件，以及什么结果会削弱原来的判断。模型很擅长为已有结果组织解释，事后补上一段合理的叙述并不困难。先留下研究预期，才方便回来检查：实验究竟支持了原来的想法，还是解释在结果出现后发生了变化。
信息边界也需要单独考虑。尤其在历史研究中，即使模型没有直接访问某份留出的数据，也不能据此认定它的建议完全独立于事后信息；相关知识可能已经包含在它的训练材料中。因此，执行层面的检查通过之后，研究结论仍然需要独立检验。这部分不确定性，不能被一个“校验成功”的状态掩盖。
同样，多找几个 Agent 表示赞同，也不自动增加证据的独立性。相同的信息、假设和检查路径，可能只是把同一种错误重复几次。验证能力的扩张，要看系统能排除哪些错误、提供什么新增证据，以及哪些判断仍需保留给人。
模型会换，研究积累应该接得上
建设这套基础设施并不轻松。整理旧约定、统一工具行为、补齐检查，都会占用直接做研究的时间。这笔投入的回报，取决于这些工作能否在后续研究中被反复使用。
一项含义清楚、经过检查的计算能力，可以继续被新的研究调用。一次失败的实验，如果保留了当时的假设、条件和原因，也能帮助后续研究判断是否值得重做。某个异常曾经怎样被解释，某类数据在什么条件下不可靠，这些经验应当有地方可查。它们留在个人记忆或某次聊天里，下一次交接就又要从头补课。
例如，可以用 flake.nix 描述开发环境，将依赖个人记忆的环境配置显式记录下来。研究系统还要继续往前做，把环境、输入条件、实验版本和结果联系起来。固定软件环境只是其中一部分，真正需要留下的是结果产生的依据。
更换模型时，新的模型可以带来不同的想法和研究路径，但已有工具的含义、执行规则和历史记录应当能够继续使用。接入新模型仍然需要检查它的行为，却不必把整个研究环境重新搭一遍。模型越有能力，越应该能够用上这些积累，而不是让过去的投入失效。
模型升级本身不会替一个团队整理研究口径、保存过去失败的原因或建立可信的验收条件。这些工作必须在团队的研究环境里完成。做好之后，后续模型的进步才有机会持续转化为研究效率。
这笔投入可以放在完整的研究过程中评估：一个问题得到可靠反馈需要多久，要经过多少次人工接手，下一轮能直接复用多少已有工作。改造的目标，是让值得研究的问题更快进入检验，并为研究员保留认真判断结果的时间。