最直观的一处变化
一位长期跟踪工程实践的科技作者在 9 月 16 日发布了一篇实地探访记录，去了 OpenAI 总部，与七位工程负责人和工程师聊了公司现在怎么运转。名单里有应用基础设施的工程副总裁、ChatGPT 的工程负责人、桌面端负责人、核心智能体团队负责人，以及两位一线工程师。
他给出的最直观印象不是模型有多大，而是屏幕上没有集成开发环境。
变化的时间点被反复提到：今年 1 月之前，Codex 还是一个「有也不错」的工具；此后用量一路上升，同期集成开发环境的使用率持续下滑。到最近几个月，桌面端团队负责人的说法是，一切都变成了编码智能体——不管你的产出物是不是可见的代码，最终都是由智能体写出来的。
这条记录之所以值得认真读，是因为它来自一次访问加七个实名受访者，而不是产品发布会的转述。同时它也需要打折来读，因为它是一家公司对自己工作方式的描述。
没有强制，非工程岗自己搬过去了
探访里最超出预期的一条是关于非工程岗位的使用。
财务、招聘、法务这些与写代码无关的团队，在四个月里从接近零的使用走到 90% 的周度使用，而且公司说没有自上而下的强制要求。更值得琢磨的是过程：在界面还会把代码明晃晃摆在屏幕上、对非工程用户并不友好的阶段，这些人已经达到了约 40% 的使用率。推动他们迁移的不是易用性，而是能完成更长、更复杂的任务。到了 4 月与 5 月之间，使用率从 60% 跳到 90%，负责人的归因是挽具在长任务上变得更好了。
他还有一个反直觉的观察：人们会在一个会话里连续干好几天，而擅长处理长任务反而让人减少并行——因为长任务型的智能体会自己分出子智能体，人需要打理的面反而变小了。这个观察如果成立，它推翻的是「智能体普及之后人会同时管更多事」的常见预期。
配套的一个做法是上下文工程被当成了文件系统决策。公司把所有文档搬进源码目录，让智能体能直接读到；新人的入职指引里写着可以先去问智能体，因为它掌握的上下文比任何一个人都多。
一条流水线与两个回到生产的闭环
这套流程被内部称为软件工厂。把它按顺序拆开是六段：人定义目标与期望结果；智能体自己去取上下文，来源包括代码仓库、即时通讯、文档系统、数据平台、监控平台与内部日志；智能体实现并自我验证；构建、测试与持续集成由智能体负责跑到全绿为止，性能挽具会把有风险的改送去对照实验；代码评审由多个领域专家型智能体并行完成；最后每个改动配一个智能体，自己读代码、找到功能开关、定义成功与失败信号、搭一张自己的监控看板，再盯着它。
其中两处设计特别值得单独说。
一处是风险分级路由。低风险改动交给自动批准智能体，走的是不设人工卡点的路；高风险改动会叠加更多智能体评审，并强制人工介入。合规升级本身也做了自动化。这套设计的逻辑是把人从「审所有东西」挪到「审该审的东西」，代价是对风险分级的准确性高度依赖——分级错了，人就审不到该审的那部分。
另一处是两个闭环的分工。一个叫 Perf Factory，扫告警、去重、定位真实的性能回退、给出修复建议，等于把优化工作从部署之后继续往前推。另一个叫 Sevbot，负责事故：收集上下文、判断可能的缓解方案，但明确不执行任何动作，只在频道里回答问题。团队的说法是希望有朝一日常规的夜间事故不用叫醒人，但值班目前还没取消。
越靠近生产，智能体的权限越往回收——这条界线是有意画的，也是整篇记录里最值得国内团队照抄的一条。
几组数字
探访里给出一组内部系统的数字：持续集成的负载在六个月内增长约十倍，而这种量级通常需要两到三年才会出现。基础设施负责人的说法是，每个月都会撞上一个新的基础设施瓶颈——刚觉得容量够了，模型解锁了一项新能力，瓶颈就挪走了。
公开渠道还能补上一组来自公司经济研究的数字：截至 5 月，抽样的用户中有 80.6% 至少发起过一次被估算为可替代三十分钟以上人工的请求，70.2% 超过一小时，25.6% 超过八小时。公司在内部周度产出 token 中，来自 Codex 的占比为 99.8%。自 2025 年 8 月以来，非开发者个人用户增长约 137 倍，组织内的非开发者用户增长约 189 倍；业务部门的日常工作里，超过四分之一是编码或工程类任务。
这几组数字来自不同渠道与不同时间窗口，只能说明量级方向，不适合互相除算。其中「十倍负载」是对内部系统的描述，不是公开监测数据。
瓶颈转移到了别处
一个有意思的细节是瓶颈的位置。当代码的产出速度以分钟计时，打包上架却仍要等商店审核几个小时到几天，迭代节奏就被卡在最后一百米。受访的工程负责人提到，软件几分钟就能写出来，却要等好几天才能到用户手机上，这个矛盾越来越难解释。移动应用商店的审核机制自 2008 年以来基本没变。
另一个被反复提到的词是挽具效率，也就是运行智能体的那套基础设施本身的效率。整篇记录里最该带走的一句话是：挽具效率在软件工厂里是关键的。这句话的含义是，模型是固定的，能改变的差距在上下文供给、反馈回路与工具编排上。
同一周里还有一条方向相反的公开动作：一家知名创业孵化器开源了它自己公司运转所依赖的多智能体挽具，并把底层模型做成可替换的。两家机构押的是同一个层的不同一侧——一边把挽具标准化、让模型可换；一边深度依赖单一挽具、把模型固定下来。谁的选择更耐久，目前还没有答案。
岗位与责任的两个问题
七位受访者都提到同一件事：工程专业分工在变模糊，判断力与主动性变得比具体技能更重要，过去被认为「不可能完成」的重写与迁移，现在一两个工程师加上智能体就能做成。公司还把领域专家——比如做幻灯片设计的、做财务报告的——嵌进了工程团队，理由是模型在这些领域的品味超过开发者，而开发者无法判断产出的好坏，只能由真正的专家来定义什么算好。
但有两件事这套叙述没有回答。
一是责任归属。当低风险改动由智能体自动批准、事故智能体只建议不执行，责任链条在制度上还留在人这一侧。可如果人已经不再逐条看改动，「谁应该为结果负责」就变成一个组织问题，而不是技术问题。这套体系目前靠的是风险分级，而风险分级本身也需要有人定期校准。
二是单点依赖。整家公司跑在一套挽具上，挽具的一次小故障会被同事先于自动告警发现——受访者把这当成一个细节讲出来，它反映的其实是集中度。效率提升与集中度上升在这里是同一件事的两面。
可以带走的四条
其一，把上下文供给当成工程问题处理，而不是当成提示词技巧。文档进源码、日志与数据平台可读，这些是基础设施动作。
其二，按风险分级决定人工卡点，而不是一律卡或一律放。分级标准要写下来，并定期回看。
其三，让面向生产的智能体停在「建议」而不是「执行」。这条边界在效率上是有代价的，但它把不可逆性挡在了外面。
其四，衡量挽具效率，而不是只换更强的模型。同样的模型在不同挽具下的表现差距，往往大于换模型的差距。
需要标注的边界
其一，这是单一来源的实地探访，受访者全部来自同一家公司，描述的是这家公司自己的做法。
其二，涉及内部系统的数字来自受访者的口头描述，未提供监测口径与原始数据。
其三，经济研究的数字来自公司公开材料，抽样方式与「可替代人工时长」的估算方法会影响结论，引用时需要注明来源与口径。
其四，这家公司的工程密度、任务结构与多数企业差别很大，这套流水线的可迁移性需要在自己团队里验证，不能整体照搬。
其五，探访中提到的部分细节，例如某个具体系统的内部代号与长期目标，属于描述性内容，尚未见官方单独发布说明。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。