＂AI流水线＂的幻觉:工具换了,流程没换

故事的开始：半天就崩了

周二中午，老K端着外卖往工位走。

经过小周桌子的时候，他停住了。小周没在吃午饭，也没在看手机，就那么盯着屏幕，一动不动。屏幕上是线框图文档，Markdown格式，编号排得很整齐。

老K把外卖搁在旁边桌上，拉了把椅子坐下。”走，吃饭去。”

小周没动。

过了几秒钟，他摘下耳机，揉了揉太阳穴。老K这才注意到他眼底下的黑眼圈——昨晚的会开到快十点，他回去又用AI跑了一版线框图，估计折腾到凌晨。

“老K，”小周开口了，声音有点哑，”我上午把两个主页面跑完了，下午还有三个。但是……”

他顿了一下，像是在组织语言。

“我觉得这个还是传统流程啊。”

老K没接话，等他说下去。

“就我一个人出需求，其他人等我的线框图往下做。所以我必须不能出问题。但有些业务逻辑我自己也不确定，我想找人讨论，可现在这个流程——”他指了指屏幕上的Git仓库，”我推上去的MD，没人看得过来。他们都在等我的最终版。”

老K盯着自己凉掉的外卖，没说话。

他想起昨晚那个会。

周一下班后，七点半，会议室。窗外阴天，空调开得太足，四个人围坐着，老K搓了搓手。

投影仪上摆着三份线框图文档。准确地说，是三份风格完全不同的文档。

小周那份，是他从设计工具里导出Token，喂给AI转成的Markdown。组件编号带着一串NODE_ID，看着像开发文档。

小林那份，是让AI根据老板的原始需求跑的模块定义。同一个页面，同一个功能，命名规则跟小周的完全对不上。

小陈那边又是另一套。她负责底层逻辑框架，自己用AI跑了一版，用词和描述方式跟前两人又不一样。

三份文档，三种规范，三种语言。

会议室安静了几秒钟。

“你们三个人的AI，是不是没商量过？”老K尽量让自己的语气不那么直接。

小林先开口了：”我这几个会话框各跑各的，没对过。”

小周也点头：”我也是，先把页面框架画出来，再让AI补充逻辑。它出来的东西跟我想的不一样，改了好几遍。”

小陈推了推眼镜：”我这边是底层架构，跟你们上面的页面定义本来就不是一个维度。但确实，没人告诉我你们的命名规范是什么——因为根本没有规范。”

老K站起来，走到白板前，拿起马克笔。

“三份规范，三种命名，三种逻辑。”他在白板上画了三个圆，互相不挨着，”如果你们各自往下做，最后开发拿到手的是三套完全不搭界的东西。合并的时候，不是修修补补的事——是推倒重来。”

他想了几秒钟，拍了板。

“线框图小周一个人搞。先把0到1跑通，规范统一了，再往下拆。”

小林看了小周一眼，没说话。

小周点了点头。老K后来跟我说，他依稀记得小周当时的眼神——不是不情愿，更像是”行吧，试试看”。

会开到快十点。散了。

现在，半天不到，小周坐在老K面前，说了一句让老K半天接不上话的话：

“老K，这个流程有问题。我一个人扛不住。”

犀利的观点：AI放大器悖论

老K后来跟我复盘的时候，说了句他自认为”有点疼”的话：

“我犯了一个错误——我把AI当成了电动螺丝刀。”

什么意思呢？给流水线上每个工位装了电动螺丝刀，拧螺丝确实快了三倍。但装配线的节奏没变，工位的顺序没变，质检的标准没变。你以为你升级了生产方式，其实你只是升级了工具。

AI是放大器。但它放大的是你现有的工作方式。如果你的协作方式本身就是低效的，AI放大的不是效率，是混乱。

以前，产品经理一个人写PRD，慢是慢，但规范天然统一——因为只有一个人在定义。

现在，每个人都配了AI，每个人都觉得自己可以定义需求。三个AI session，三套组件命名，三种状态描述，三种跳转逻辑。产出确实快了，但合并成本被严重低估了。

老K的解法是回归”一个人收敛”。线框图小周一个人搞，规范天然统一。

但小周半天就扛不住了。不是能力问题。一个人定义所有需求，就意味着他不能犯错，也意味着没有人能跟他深入讨论。 这跟传统产品经理独揽PRD有什么区别？只不过以前是人用脑子想，现在是人用AI跑。

工具升级了。权力结构没升级。

事实的演进：从”手工作坊”到”AI流水线”的需求生产史

老K那天中午没吃饭。走廊里碰到他的时候，他正靠在窗边发呆，手里攥着一根没点的烟。

“你说，这事儿是不是从来就没变过？”他没头没脑地来了一句。

回头看，团队”生产需求”的方式确实一直在变，但每次变完，瓶颈只是换了个地方待着。

第一阶段：手工作坊时代 (约2010年以前)

一个产品经理，一台电脑，一份Word文档。几十页的PRD，一个人写，所有人等着。

好处？规范统一——因为只有一支笔。坏处？瓶颈就在这支笔上。他写错了，全员跟着错。而且他跟谁讨论？跟老板，跟客户，就是不跟真正动手做的人讨论。

第二阶段：敏捷协作时代 (约2010 – 2023年)

Jira、飞书、Figma、蓝湖……工具上了一堆。需求评审会、站会、迭代计划会，一周好几个会。信息流动的速度确实提上去了，但有一个东西始终没变：“定义需求”这件事，还是一个人说了算。 设计师能提意见了，开发能挑毛病了，但最终拍板的还是产品经理。大家只是从”被动执行”变成了”带着意见的被动执行”。

第三阶段：AI辅助时代 (2024年至今，正在踩坑)

AI来了。理论上，每个人都能让AI帮自己”定义需求”。设计师可以用AI跑线框图，工程师可以用AI跑系统框架，前端甚至可以拿AI参与需求讨论。

但”所有人都能定义”，在实践中变成了”所有人的定义都不一样”。

老K面前出现了两条路：

• 收敛派
  
  ：一个人负责一个完整环节，AI加速他的产出，其他人基于这份产出往下走。本质是传统流水线，只不过螺丝刀换成了电动的。
• 演化派
  
  ：所有人参与需求定义，各自的AI产出不一样没关系。规范不是某个人拍出来的，是在冲突中长出来的。

老K选了收敛派。小周半天就证明了它的代价：一个人不能出错，也没有人能帮他想。

那演化派呢？老K之前试过了——三个AI跑出三套规范，合并的时候差点打起来。

但老K后来想明白了一件事：演化派的问题不是”方向错了”，而是”没有给它配对的工具”。 你让三个人并行定义需求，却用开会和微信群来同步信息——这不是演化派的问题，这是信息传递工具配不上工作方式。

结论：别用电动螺丝刀的思路来用AI

老K那天下午没开会。

他坐在工位上，打开电脑，做了一件他之前在开发团队里一直在做、但没想过要推广到产品团队的事。

他把工作流切到了Git上。

不是让产品团队学写代码。是让所有人——产品、设计、算法——都把AI产出的MD文档往Git仓库里推。每次有新产出，commit，push。一天推好几次。做了什么，想了什么，跑出来什么方案，全部变成MD文件，全部进Git。

“为什么要这么搞？”小林在群里问。

老K回了一段话，大概意思是——

“第一，信息传递的速度。你们现在做了什么，其他人不知道。等开会才知道，信息已经滞后了。Git上的commit是实时的。你推了，别人拉了，他就知道你在做什么。不用等会议，不用等微信群有人想起来转发。”

“第二，冲突驱动规范。你们每个人拉一个分支，各跑各的。合并的时候，Git会告诉你哪里冲突了。冲突了就是规范不一致——命名不一样、描述方式不一样、逻辑对不上。冲突不是坏事，冲突就是发现规范的时机。发现一处，定一条规范，写进公共的约束文档里。再跑，再冲突，再补规范。”

“第三，AI互搏。你用AI跑出来一个方案，不要自己在那看觉得OK就完了。开一个新的AI会话，让它站在另一个角色去审你这个方案——站在运营的角度、站在用户的角度、站在前端开发的角度。两个AI互相挑毛病，比你自己检查靠谱得多。这不是额外工作量，这本来就应该做。”

小陈在底下回了一句：”那前端开发那边呢？他们也要看我们的MD？”

老K说：”对。他们拉了你的MD，可以让他们的AI先读一遍，看看跟自己强相关的东西。发现了问题，直接在Git上留评论。不需要等你拉他开会。他带着他的AI来审你的方案，你带着你的AI来审他的。这不是开会评审——这是你带着你的AI agent来评审。”

小周看着群里的消息，没说话。过了一会儿，他默默地把自己上午跑的那两个页面的线框图，整理成MD，commit，push了。

十分钟后，小林的AI agent在小周的提交下面留了一条评论：某个跳转逻辑跟她负责的模块对不上。小周看了一眼，确实是他没想到的。他改了一版，重新push。

又过了五分钟，小陈也推了自己的底层逻辑框架。小周拉下来一看，发现她的用户状态定义跟自己线框图里的角色设定冲突了。他在Git上留了评论，小陈回了她的理由，两个人在线上对了两轮，最终统一了描述方式。

第一条规范就这么长出来了。

老K后来跟我说：”你看，这就是演化派的样子。不是先定规范再干活，是干了再说。干了，冲突了，规范就从冲突里冒出来了。但前提是——你得有一套让信息高速流转的工具。Git就是这个工具。commit就是你的信息传递，merge conflict就是你的规范发现机制，code review就是你的AI互搏战场。”

我问他：”那以后还需要开两小时的会吗？”

他想了一下：”会还是要开。但不是开’信息同步会’——你信息都推到Git上了，有什么好同步的？开的是’决策会’。信息到位了，方案碰撞了，规范也长出来了，最后需要拍板的几个点，碰一下就行。十五分钟，顶多半小时。”

他拍了张Git仓库截图发到工作群里——小周、小林、小陈三个分支，互相merge了两轮，公共规范文档里多了六条约束。下面有人回了句：”这比昨晚两小时的会高效多了。”

老K没回消息。他盯着屏幕看了一会儿，自言自语了一句。

“装备升级了，脑子也得跟上啊。”

正如《易经》所言：”穷则变，变则通，通则久。“

工具变了，流程得跟着变。流程变了，人的角色也得跟着变。规范不是某个人拍出来的，是在一次次commit、merge、conflict、review里长出来的。AI给了每个人一把更锋利的刀，但怎么切、切什么、谁跟谁一起切——这些”人”的问题，AI帮不了你。

能帮你的，只有一套让信息高速流转、让冲突自动浮现、让每个人都能参与定义的机制。

我是 哇塞君。

我相信所有复杂的管理问题，背后都有一个更优的解。如果你也在自己的”铁匠铺”里面对着”天外陨铁”发愁，或许我们可以聊聊彼此锻造”匕首”的故事。

参考资料 (References & Further Reading)

• [1]
  
   Womack, J. P., Jones, D. T., & Roos, D. (1990). The Machine That Changed the World. Free Press. （精益生产与流水线效率的对比研究）
• [2]
  
   Edward T. Hall. (1976). Beyond Culture. Anchor Books. （关于组织文化与工具变革的关系）