需求变代码，这条路被压短了
上周看到 OpenAI 发的一篇案例，主角是一家叫 Braintrust 的公司。
Braintrust 是做 AI 应用评测和线上监控的——你把一个 AI 产品丢到生产环境里，它帮你看这个产品的输出质量是不是在漂移，有没有在某些 case 上悄悄退步。Notion、Vercel、Replit 这些公司都在用它。
案例说的是他们怎么用 Codex 处理客户需求。
具体操作是这样的：有客户在 Slack 上发一条功能要求 → 工程师把这条消息复制粘贴进 Codex → 十分钟后，一个 preview branch 出来了 → 拿给客户看。
我读完停了一会儿。
不是因为"哇，AI 真的来了"那种感叹。是因为这件事描述的，不像是工具的进步——更像是工作流里某根东西断掉了。
先说"断掉了什么"。
传统软件团队有一个几乎所有人都认为理所当然的流程：客户提需求 → 有人整理、分析、排优先级 → 写 spec → 进排期 → 工程师开始写代码 → 测试 → 上线。这中间短则两周，长则两个月。
这个流程里有个关键角色：翻译需求的人。
可能叫 PM，可能叫方案经理，可能叫业务分析师，可能就是一个能同时跟客户说人话又能跟工程师说代码的人。他的工作，说好听点叫"把模糊的业务意图变成清晰的技术需求"，说实话就是做从自然语言到系统逻辑的翻译。
Braintrust 的工程师把一条 Slack 消息粘进 Codex，十分钟拿出来给客户看——这个翻译步骤，去哪了？
Codex 把的是哪段时间？
是开发时间。从"我们决定做这个功能"到"一个能跑起来的 demo 出来"，这段时间被压缩到了十分钟。
但在这之前和之后，省了什么？
之前的：需求要不要做？值不值得做？这个需求背后的客户场景是什么？做了之后跟现有功能会不会打架？——这些判断，没有被压缩。Braintrust CEO Ankur Goyal 说的是"跟客户实时迭代"，不是"不需要跟客户对话了"。
之后的：这段代码对不对？上线会不会出问题？如果出了问题谁来背？——也没有被压缩。
所以 Codex 压缩的，本质上是"打字时间"。是工程师把需求翻译成代码、让机器跑起来的那段机械执行时间。
这段时间被压短，意义是真实的——以前要排期等两周才能给客户看的东西，现在十分钟就能给他看。这个变化对产品迭代的速度，影响是实质性的。但它改变的是速度，不是判断。
那判断在哪呢？
Braintrust 的案例里有一个细节我没在大多数转发里看到人提：是工程师在做这件事，不是 PM，不是客服。
这件事以前做不了，原因不是工程师不想，是工程师写出 demo 太贵了——时间成本太高，不值得为一个"也许不做"的功能动手。
现在成本降到了十分钟，工程师可以在客户说完需求的同一个电话里直接演示。
这其实不是新东西。硅谷里有一套叫 forward-deployed engineer 的打法——派一个工程师驻在客户那边，客户有需求直接当场做，不走产品流程。Palantir 最有名，很多企业软件公司也在学。
Codex 做的，是把这个打法里最贵的部分（工程师现场写代码）变便宜了。
但有一件事，这个打法从来没有改变过，Codex 也没改变：
谁决定这十分钟产出的东西值不值得上线？
这不是在说代码质量——那是另一个层面的问题，而且越来越多的测试本身也在被自动化。
是在说：这个功能上线了，符不符合产品方向？有没有在某个 edge case 上给客户挖坑？一个月后这个需求变了，维护这段代码的人知道为什么当初这么写吗？
这些判断，不在 Codex 里，不在 Slack 消息里，也不会因为代码生成的速度变快而自动变得清晰。
Braintrust 用 Codex 这件事，我读完觉得最值得拆的不是"AI 多厉害"，是这个工作流假设了一件事：工程师本人有足够的业务判断力，知道哪个客户需求值得这十分钟，哪个演示出来是在给自己挖坑。
这个假设在 Braintrust 可能成立——它是一家技术基因极强的公司，工程师直接面对客户本来就是他们的文化。
但如果你拿这套流程套在一个传统企业软件团队上，那个被"压缩"的翻译步骤，藏着的不只是时间，还有对需求合理性的把关。
软件团队里有一个持续多年的讨论：PM 的价值在哪里？
有人说 PM 是需求管理，有人说 PM 是用户研究，有人说 PM 是利益协调。但我见过最值钱的 PM 做的事其实只有一件：帮工程师把客户说的话翻译成"这个做了有没有意义"的判断。
这件事一直很贵——因为它要求你既懂产品又懂业务又懂工程，同时还能在客户的情绪表达里分清什么是真需求什么是一时痛点。
Codex 压缩了从"判断完毕"到"代码出来"的时间。
但"判断"本身，仍然是人的瓶颈。
那个 Slack 消息，粘进 Codex 之前，谁在看它？谁在判断它值不值得粘进去？
Braintrust 的案例里还有一个数字：一个月内，团队里一半的人转到了 Codex 工作流。
这个速度，让我想到的不是效率提升，是这件事对团队结构的实验速度有多快。以前要观察一个新工作流对团队的影响，至少要跑一个季度。现在一个月就能做出一半团队的规模结论。
这可能才是 Codex 类工具更隐蔽的影响——不是替代某个角色，是让团队能以更快的速度发现自己需要什么样的人。
需求翻译的人，还需要吗？
我猜还需要，但需要的地方变了。不再是"把需求变成技术语言"，而是"在十分钟 demo 出来之前，判断这个需求值不值得演示"。
前者，Codex 已经能做很大一部分。后者，暂时还没有工具能做。
暂时。