这是一个系列的开头。我要讲我们大约两个月前在 Prolog 的科技团队里启动的这场转型：它为什么开始，什么正在做对，什么代价高昂。这不是台上的理论。是我们亲历的东西。
我决定写下来，理由很简单：当我去找该怎么做时，找到的是大量的观点，却很少有真正身处过程之中的人的实录。如果这篇文章能成为另一个动手建造的人可以依靠的地方，那就值了。
一切从一份不适开始。
我看到了什么
三月，我和我的合伙人 Jean 去了德州的 SXSW，那是世界上最大的创新展会之一。我回来时变了，那份不适没有消退。不是我在台上看到的东西。是我看到那些公司已经在实践里做的东西。
回来后，我一头扎进那些真正在用 AI 建造的人的技术内容里。不是 Instagram 和 LinkedIn 上那种温吞的内容。是深的那种，来自亲自动手、并把所学发表出来的人。我一个接一个地撞见那些真正改变了工作方式的公司的案例。这个差别既微妙又巨大：它们不是“开始用 AI”，它们把 AI 放到了中心。
而且没法把它当成台上的炒作打发掉。这是工业规模的采用：大公司、小公司，所有人都朝同一个地方走。让我印象很深的一件事是一个简单的数字：财富 100 强里每 10 家就有 9 家已经采用了 Copilot。但真正要紧的数据不是采用率。是收益的大小。只把 AI 塞进旧流程的人，报出来的是多 10%、20% 的生产力。围绕它重建的人，报出来的是倍数：5 倍、10 倍。这些案例我会在接下来的文章里一个一个展开。眼下，要紧的是它们共有的那个转折。
放在一旁用 vs. 放到中心
这个区分看着小，却是它决定了一切。
用 AI，是在一旁打开一个工具，照旧走原来的流程。流程还是那个流程，岗位还是那些岗位，评审还是那套评审。AI 只是多出来的一个标签页，每个人各自和它周旋。收益出现在边缘。
放到中心，是围绕它重新设计流程。你假定 AI 会建造大部分工作，并据此重做流程、岗位和评审。上下文不再死在一次对话里，而变成共享的。收益是另一个量级，因为这不是同样的工作变快了。是工作在改变形态。
同样的工作，AI 的两个位置
AI 放在一旁 vs. AI 放到中心
AI 待在旁边的一个标签页里。流程、角色和评审都照旧。每个人各自摸索，各走各的路。
+10–20% 的边际收益。瓶颈还在原地。流程、角色和评审都被重建，让 AI 成为动手构建的那一方。上下文共享，不会在一次对话里消失。
另一个量级 的收益。不是多 10%，而是工作本身在变。当我想通这一点，要问的问题就不再是“我们采用哪个工具”，而变成“在我们的工作方式里，有什么是为一个没有 AI 的世界设计的”。于是我开始向内看。
诊断：各自为战
三月底，甚至在我们迁到 Claude 之前，我和 Prolog 产品、设计、工程的人坐下来，问了一个简单的问题：你日常怎么用 AI？哪里好，哪里卡，你在运营里看到什么瓶颈。
我听到的东西击中了我。
每个人用一个工具。一个用 Copilot，一个用 Claude，一个把什么都丢进 Prolog 内部的 AI。而比工具零散更糟的是上下文零散：一个人和 AI 对话时搭起来的东西，就死在那里，随他而去。比如维护团队，在 Prolog 的 AI 里搭了一份不错的材料，带着那个产品的规则。可那东西传不到轮胎团队，而轮胎团队需要同一类上下文，只能从零开始。
有一件事一直留在我脑子里。开发者们在回避用 AI 去评审大的 PR，怕在一周结束前把额度烧光。想想这多荒唐：一个人得在两件事之间选，要么用 AI 做完自己承诺要交付的任务，要么把同样的额度花在评审同事那个巨大的 PR 上。它变成了对一项稀缺资源的争夺。于是没人愿意接别人的 review。
团队里有人用一句话总结，那句话我再也甩不掉：
我们用 AI 生产，却不用 AI 评审。
每个人各自为战，按自己的方式，用手头凑合的工具。对一个人管用的，没有变成另一个人的配方。没有标准，没有共同的地方。
而这不只是用法，是结构
我看得越多，越清楚这没法只靠教会所有人“用得更好”来解决。用法只是症状。底下的结构才是没准备好的那个。冒出了三个窟窿。
第一，上下文散落各处。一块在 Notion，一块在 Drive，一块在 Jira、在 Figma、在 Fathom。没有单一的真相来源。于是每次和 AI 的新对话都得从零解释一切，因为它需要的信息散在五个地方，却在任何一个地方都没被整理过。我们在 token、在 request、在时间上付出代价，只为重新拼起某个角落里早就存在的上下文。
第二，人是那团胶水。产品的某个人用 AI 生成一份 spec，传到一个文档里，把链接发给下一个人，后者拿过来丢进自己的 AI 项目。AI 出现在两端，从不在中间：它产出一块，一个人用手把结果搬到下一个工具，另一个 AI 又从头开始。流程仍然是人的。
第三，架构。我们用十年搭起来的底子，是为一个瓶颈是人、不是 AI 的世界造的。它在一些地方缠成一团，有些部分没有测试，而这恰恰卡住了 AI 本可以带来的快速变化。这不是谁的道德缺陷。这是十年间那些一路管用到现在的决定的累积。AI 只是把它摊到了台面上。
而且必须说清楚：这不是团队的缺陷，也不是 Prolog 的缺陷。这是任何一家把 AI 贴在旧工作方式之上的公司都会遇到的。每一家有十年历史的公司，都带着一套一路管用到现在的做法。AI 给它打上一束聚光灯。而改变它的责任在我。
为什么要重建一切，而不只是工程
第一个诱惑是在工程里解决。这说得通，那是 AI 最快扎根、也是我们已经起步的地方。但陷阱正藏在那里。
如果一个部门以 AI 的速度前进，而旁边那个还是人的速度，那我什么都没加速。我只是把瓶颈挪了个位置。
想想整条流程。如果工程开始以小时为单位交付，而产品还要几周才能写完 spec，那现在拖住队伍的就是产品。把产品和工程都解决了，可验证还靠手工？那就卡在验证上。而且这不止于科技：如果我们上线了很多东西，而市场没法以同样的节奏对外宣布，瓶颈就跑到了市场。加速某一段，并不能解开这场堵车。只是把它推到下一段。
加速一段并不会清空队列
瓶颈只是换个位置
我只加速了工程
我加速了产品和工程
你加速的每一段都会点燃下一段。堵车不会消失，只是换个位置。
所以，四月底，我们开始重建整个科技。产品、设计、数据、质量。不只是工程。如果 AI 要放到中心，它就放到整条流程的中心，而不是某一块的中心。
接下来会有什么
在接下来的文章里，我会把这里的每个部分展开。什么是“harness”，那个让 AI 真正出活、而不只是交付零散片段的基础设施。当 AI 成为动手建造的一方、人变成指挥和评审的一方时，每个岗位的工作怎么变。以及为什么当有东西出问题时，对的问题不再是“我现在该做什么”，而变成“上下文里缺了什么，才能让这事不再发生”。
这场转型正在进行，有对也有错。两样我都会在这里讲，随它发生。这不是配方。是我们正在亲历的东西。如果它能给同样在建造的人当一张地图，那就更好了。