先看证据
瓶颈不只在分析，也在工具供给
OpenAI 于 2026 年 10 月发布的案例介绍中，Benefit Street Partners（BSP）的投资组合经理 Anant Kumar 用 Codex 辅助搭建内部工具。BSP 是一家信贷投资管理机构，工具面向两类工作：比较不同商业开发公司对同一笔贷款的估值，以及分析信贷协议。它们没有替团队作出是否投资的决定，而是介入尽调和投资委员会追问中的信息整理与分析环节。
案例里的旧流程有两道不同的等待。要做一个能与同事共享的数据仪表盘，Kumar 过去需要找有软件经验的人搭网站、导入数据；一轮投资委员会意见则可能要数天甚至数周才能处理完。Kumar 称，现在分析师通常能在一天内完成一轮反馈，也常能在会议中回答跟进问题。这些是当事人的描述，材料没有提供独立测量或对照组。
BSP 对效率提升的解释也值得留意：公司称新增能力用于在相同时间内增加承保审查的容量和严谨度，而不是多做交易。换句话说，目标不是单纯提高交易吞吐量，而是让团队在既有交易节奏中处理更多信息、回应更多问题。对技术负责人而言，这比“AI 替代某项岗位”的叙事更具体，也更能指向工具实际嵌入的工作位置。
从使用工具到由专家搭工具
BDC 估值追踪器是专家自建工具这一变化最直观的例子。它利用商业开发公司提交给美国证券交易委员会（SEC）的公开文件，帮助团队比较不同持有方对同一笔贷款给出的估值。Kumar 用 AI 起草代码，并让 Codex 做代码审查，完成了过去需要软件开发人员协助才能做出的内部仪表盘。
开发时间有两个口径，不能混为一谈。Kumar 估计，追踪器首版约用一天完成；之后添加功能、调整界面，累计开发时间约为 10 至 12 小时。这个数字说明从问题到可用原型的门槛下降了，但它没有单独说明公开文件的数据抽取、估值口径的理解和统一、或工具长期维护分别花了多少时间。
这一区分对工程管理有实际意义。领域专家能够快速做出原型，可以让团队更早判断某个重复工作是否值得产品化，也能减少需求描述与业务现场之间的来回翻译。但“能生成代码”不等于已解决数据质量、权限管理、异常处理和持续维护。案例没有交代追踪器在这些方面的具体设计，因此它更适合作为原型开发能力的证据，而不是生产级系统成熟度的证明。
二十分钟只是协议分析的第一轮
另一项工具处理的是更长、更依赖条款判断的材料。信贷协议通常有 300 页或更多，投资者需要找出可能把价值从贷款方转移出去的条款。BSP 汇集律所关于风险条款的备忘录作为参考，上传协议后，工具约 20 分钟生成一份初步分析。Kumar 将它形容为组织内部的“第二大脑”，但这个说法描述的是辅助作用，不是独立判断权。
初筛之后仍有一小时或更久的人工复审。因而，20 分钟不能写成“完成一份协议审阅所需时间”，更不能等同于作出投资决定的时间。工具先压缩了从长文档中整理出候选风险信息的环节，随后仍要由人检查输出、结合交易背景理解条款，并作出最终投资判断。材料明确表示，最终投资决定由人作出。
工具归属也需要说清。案例称 Kumar 使用 Codex 做代码审查，协议分析器后来由 GPT‑6 Astra 重构，并已上线公司自建门户。材料没有说协议分析本身全部由 Codex 执行，也没有说明重构具体改变了哪些能力。把编码辅助、分析工具和底层模型混成一个“Codex 自动审合同”的故事，会掩盖实际系统里不同环节的分工。
扩展审查能力之前，先补上验证
案例支持的结论有明确边界：一些内部工作变快了，专家也能更直接地把重复需求做成工具。它没有提供协议分析器的错误率、漏判率、样本规模或独立准确率评估，也没有比较工具上线前后的成本。Kumar 表示信息更多后团队对决策更有信心，这是对工作体验的说明，不能据此推出信贷判断质量提高或风险下降。
交易周期也没有提供可用作效果对照的平均值。材料只说一笔交易通常历时数天到数周，具体尽调轮次会随交易时间而变。委员会反馈能在一天内处理，是 Kumar 对当前流程的描述，不代表每笔交易都缩短了同样时长。技术负责人应把“提速”拆成可核验的环节指标，而不是把一个案例中的时间数字外推成总体收益。
若要在类似环境中采用这类方法，稳妥的起点是挑选重复、边界相对清楚的任务，让领域专家先做内部原型，同时保留人工复核，并记录输出被接受、修改或推翻的情况。工具部署在公司自建门户，并不足以证明协议数据保护、访问权限、审计留痕和合规安排已经完善，案例也没有披露这些细节。只有质量验证与治理责任都说清楚后，团队才有依据考虑扩大使用，或迈向持续承保；目前可执行的判断是用工具增加审查容量，而不是用速度替代准确性证明。