Sherwin Wu 讲清楚了：未来 12 到 24 个月，AI builder 该怎么押注

今天这期我们聊一个很适合 AI builder 听的访谈。Sherwin Wu 是 OpenAI 平台工程负责人，这期不是在讲遥远愿景，而是在讲未来 12 到 24 个月，做产品和工程的人到底该把力气放在哪，尤其是怎么把 AI 真正接进日常工作，也顺手看清楚它会怎么改变团队分工。

我很喜欢这种内容，因为它不在聊 AGI 大词，而是在聊真实工作流。你会听到的不是模型会不会突然变神，而是团队已经怎么用 Codex、怎么 review、怎么把上下文接进流程，听完会很容易对号入座。

公开摘要里最关键的一点，是 AI 已经不是工程团队里的试验品了，而是默认工作流的一部分。OpenAI 内部大约百分之九十五的工程师每天都在用 Codex，所有 PR 也都会经过 Codex review，这说明它已经从辅助工具变成流程组件了。

这个信号很强。它说明问题不再是要不要用 AI，而是你有没有把 AI 嵌进完整链路。只做代码补全，和让它参与理解需求、写代码、看 review、修问题，这两个层级完全不一样，差的不是功能，是工作方式。

还有一个很有意思的量化结论，公开总结里提到，高频使用 AI 的工程师，会比低频使用者开出更多 PR，量级大概能到多出 70% 左右。换句话说，AI 在放大熟练者的杠杆，也会直接影响团队的节奏和产出密度。

所以团队里的差距会被放大。以前差距主要来自经验和判断，现在还要加上你会不会把 AI 组织成自己的生产力系统。会用的人，不只是快一点，而是整条产线都更顺，协作也会更轻。

这也解释了为什么 Sherwin 说工程师越来越像 tech lead，加上一点 agent 调度员。你不再只是逐行写代码，而是在拆任务、给上下文、看结果、收失败、再推进，像在带一支看不见的小队，管理和协作的重心也在变化。

这个角色变化对 builder 很重要，因为它会影响你怎么设计产品和团队。如果你的系统只能服务一个单点写代码动作，那它很快就会被更好的模型吞掉。但如果你做的是整个工作流，价值会更稳，也更像真正的基础设施。

这里最容易踩坑的，其实不是模型能力不够，而是团队自己的知识没有结构化。文档缺、规范散、约定都在脑子里，agent 即使很强，也只能在碎片信息里乱猜，尤其是那些只存在于口头传承里的经验。

对，我觉得这句话特别适合做知识库项目的判断标准。知识库不是锦上添花，它是让 AI 真正可用的前提。没有统一文档，没有清晰约束，没有可回放的历史，agent 的成功率就会很飘，结果也很难稳定复用。

你可以把它理解成，很多 agent 失败，不是因为它不会想，而是因为它不知道该依什么来做。对于 builder 来说，真正该补的不是花哨提示词，而是上下文、文档、评估和流程，先把这些底座搭起来。

这也是为什么我们总在说 skills 文件、规范说明、例子库、评估集，这些看起来都很朴素，但其实是 AI 时代的基础设施。谁把这些整理得更好，谁就更容易把模型变成稳定系统，而不是偶尔灵光一下的演示。

Sherwin 还有一个很值得记住的提醒，就是模型会吃掉你的脚手架。这个判断不是说不要做产品，而是别围绕今天模型的短板，堆一层特别脆的临时方案。今天能用，不代表明天还值钱。

没错。短期 workaround 往往会在模型一升级后突然失效。更聪明的做法，是去押注那些不管模型怎么变，都还需要的东西，比如工作流编排、权限、审计、知识沉淀、评估体系，这些才更接近长期价值。

如果把这期内容翻成 builder 语言，我会说，未来 12 到 24 个月最值得押注的，不是单点 demo，而是高杠杆流程。像 AI coding、业务流程自动化、agent orchestration，都是更长期的方向，也更像平台能力，能一层层积累，对想做产品的人来说，参考价值也更直接。

这几个方向有个共同点，它们都不是一次性的功能，而是会不断积累数据、流程和组织记忆。也就是说，模型越强，它们越值钱，而不是越做越空，越做越像底层能力。

还有一层我觉得很关键，很多团队会把 AI 接到最前面，但没接到最后一公里。结果它能写草稿，却没法参与验收、回放和复盘，这样就很难真正形成复利，后面也不容易和团队动作对齐。

所以如果你在做知识库，别只盯着内容多少，要盯着它能不能被流程调用。能不能在 review 里被引用，能不能在讨论里被追问，能不能在失败后被更新，这些更重要。

所以你做产品时要问自己一个问题，等模型再强一截，你这层东西还值不值钱。如果答案只是今天还能补漏洞，那风险就很大。如果答案是它承接了流程、数据和协作，那就更稳，也更值得继续投入，后面还能继续长出来。

这个判断对小团队尤其重要。小团队最怕的是把全部精力花在跟当前模型缺陷搏斗，最后做出来一层很重的壳。壳是会变旧的，真正能留下来的，是流程和资产，尤其是可复用的那部分，也最值得慢慢沉淀。

如果你现在就在做团队内部工具，我会建议先从一个高频流程下手，比如代码 review、需求拆解、issue triage、知识检索，挑一个最痛的环节，把 AI 接进去，先拿最痛的一步验证收益，顺手看它能不能把链路跑顺。

接进去之后，不要只看它能不能跑通，还要把失败样例也记下来。哪些地方它会误解上下文，哪些地方需要人工兜底，哪些内容必须进入知识库，这些都会决定下一轮效果，也决定能不能持续迭代，最后变成团队习惯。

还有一个很实用的动作，是把团队里的隐性经验显性化。老工程师脑子里的约定、边界条件、踩过的坑，最好都能变成文档、例子和可执行规范，不然 agent 永远学不扎实，也很难自己补齐，很多边界会漏掉，也更难复用。

对，知识库不是把文件堆起来就完了，它要能被检索、被引用、被评估，最好还能回放。这样 AI 才不是在瞎猜，而是在一个有边界的系统里工作，也更像团队资产，而不是散乱文件夹。

如果你是独立 builder，我觉得最现实的第一步，不是上来就做一个超级 agent，而是先把自己工作里最重复的三件事拿出来，看哪一件最适合半自动化。只要能先省下一点点心力，就已经很值得，哪怕先从一个任务开始，也足够验证方向，之后再慢慢扩。

然后你就会很清楚地看到，真正让效率起飞的，往往不是模型那一下，而是你有没有把输入、约束、输出格式和复盘机制先搭好。底层搭得越稳，上面才越能跑得快，也更能控制风险。

说到底，这期最值钱的不是某个神奇技巧，而是一个判断框架。AI 不是装饰品，是真正要进入工作流的生产力部件。框架比灵感更重要，也比一次性的 demo 更重要。

而且它会先放大强者，再放大组织差异。你越早把知识、流程和评估做扎实，后面越容易吃到模型升级的红利，也越不容易被下一轮变化甩开，组织记忆会慢慢累起来。

所以如果只记一句话，我会选这句，不要围绕今天模型的短板造脆脚手架，要围绕未来模型会更强这个事实，去设计你的工作流。别把自己绑死在短期补丁上，长期看通常不划算。

对 builder 来说，这就是最朴素也最重要的押注。先把 AI 接进真实流程，再把上下文、文档和评估变成团队资产，剩下的才是继续扩张。这样做，才更像长期路线，也更适合持续迭代和复制到更多流程。