AI Native 产研实验 3/n：把流程上的"人"换成"AI"

上一篇说到我们找了个老项目的需求来试。试是试了，AI 跑出来的东西还行，但整个过程总觉得哪里不对，还是传统那套流程，只是每个环节塞了个 AI 进去。不够 native。

我和产品、后端开发在会议室坐下来，想从头捋一遍。我们在白板上画完整的开发流程，做完一件事会产生什么。开始画：需求文档、流程图、原型图、脑图、技术文档、代码、测试用例……一条清晰的链路逐渐成形。我之前聊过土木工程的类比，软件工程其实走的是同一条路——需求→设计→实现→交付，行业里十几年都是这么干的。我说了我的想法："最终还是软件工程。AI 没有改变这套流程的结构，它现在改变的是谁在干每一步。从人变成了 AI。"

画完链路以后，我们接着往下推：把每条连线打断，中间加个圈，写上到底是谁在干这件事。

产品开始在每个节点之间画圈。传统模式下，每个圈里都是人——产品写需求文档，产品画脑图和原型，技术做方案设计，开发写代码，测试写用例。但现在不一样了。架构师之前写的那个 Skill，已经能把需求文档转化成技术文档，AI 完成率大概 70%。AI 可以直接产出需求文档，完成率 80%以上，但需要产品 review 确认剩下那 20%。技术文档到代码这一步，Cursor 早就在干了，AI 完成率接近 100%，只是需要人最后 review。我问了一句："你有没有发现，从流程图、原型图和脑图出来，到需求文档，再到技术文档，再到代码这条链路——三个节点全变成了 AI？"

但是，每个节点都不是 100%。80%、70%、接近 90%……看着挺高，但剩下那 10%、20% 全得人来补。

说实话，看完这张图我挺兴奋的。但事情没这么简单。

程序员的时间被 AI 切成了各种小碎片。但碎片化真的是 AI 造成的吗？好像不是。AI 太快了，让 AI 写文档写代码只需要 10 分钟，等待的时候可以启动另一个任务。就像以前炒菜，一个灶炒一个菜，你专心炒完再炒下一个。现在有了 AI，炒一个菜 5 分钟，你为了不浪费时间，同时开了 5 个灶，在它们之间跑来跑去看火候、调味道、翻炒，得记住每个灶上炒的是什么菜，炒到什么程度了，下一步该加什么料。时间是省了，但你一直在切换，脑子一直在转。我现在看到就是这样，并行好几个项目，AI 这儿报个问题，那儿报个问题，来来回回他自己都迷了。

我之前说过一句话："我不想要把大家的时间都拆成一点一点的。就一会他写一点东西，我去确认一下，一会写一点东西，我去确认。"代码生成是快了，但效率真的高了吗？人是不是反而更累了？个人效率的天花板来得比想象中快，问题出在人在这种碎片化模式下先扛不住了。

那怎么办？

问题有没有可能出在人介入的方式上。现在的模式是：AI 干一点，人确认一点，AI 再干一点，人再确认一点。人的时间被切碎了。那如果换一种方式呢？不是让人在每个节点都介入，而是让 AI 把整条链路先跑完，人在最后集中确认？

未来最优雅的状态，一定是产品跟业务方聊完需求以后，把需求文档直接丢给 AI，AI 就全干完活了。 现在做不到，但可以往那个方向走。人出东西需要时间，AI 是秒出的。当链路上每个节点都有 AI，整条链路就能被压缩。产品和技术结对一个小时，产品把需求确认清楚，AI 从需求文档→技术文档→代码一路跑完，人在关键节点集中 review。之前产品花几天、技术花几天、开发两周的工作量，可能压缩到两天。

但这有个前提：产品、技术、测试得坐在一起。传统模式是产品做完传给技术，技术做完传给测试，每次传递都有等待时间和沟通成本。如果三个人坐在一起，当场把所有细节聊透，AI 才能一口气跑完。所以压缩的不只是时间，还有空间，把人聚在一起。

事实上，产品和后端开发已经坐在一起试了一次。4-5 个小时，改一遍让 AI 跑一遍，再改一遍再跑一遍，把一个老项目的需求从头到尾跑通了。过程中发现一个问题：平时做需求评审，大家看着原型图嘴上一说就明白了，但 AI 只能看你喂给它的东西，看不到画面就理解不了。所以我们试了三种图片输入方式——Pencil 手绘、单张截图、全部原型平铺成一张图。最后发现平铺效果最好，AI 能看到所有功能的全貌，理解得更准确。第一次跑虽然花了长时间，但大家都知道标准化以后会快得多。

回过头再看这张流程图，有个事儿有点不对劲。

在这整个链路里，技术在干什么？他好像啥也没干，他就陪着产品去开会，然后确认 AI 的产出有没有问题。真正在前面做事的是产品，找需求、画脑图、确认文档。当前产品:技术 = 1:3、1:4，但如果这条管线真的跑起来，未来可能只需要 1:1。这时候产品经理说了一句："一个懂技术的产品，在未来会非常厉害。"

但技术不是真的没事干，只是干的事变了。跑通的过程中我们发现，大需求 AI 容易丢逻辑，你把整个模块一股脑扔给它，它会漏掉分支。但怎么拆、用什么组件，现在看来还得靠技术判断。

再往下挖，还有一个更根本的瓶颈：知识库。代码规模很大，但 AI 不知道哪个需求该看哪些代码，技术得凭经验手动选文件。历史上这些映射关系从来没沉淀过——很多细节是嘴说的，从来不落纸面。但每跑完一个需求就多积累一层，这是个慢活儿，急不来。

但这些都还是对着流程图的推演和第一次尝试的经验。能不能真的跑起来，不知道。

流程画完的第二天，一个简单的需求直接扔进了这条管线。结果怎么样？下一篇说。

这是「AI Native 产研实验」系列的第三篇。接下来会继续记录实验的真实进展，不包装、不美化，写到哪算哪。

感兴趣的话，欢迎加个关注，后续更新不迷路。