对AI编程工程级实践思考-给老马车装V8动力引擎也只能散架

大家好，我是人月聊IT。今天接着聊AI编程方面话题。

今天接着跟大家聊AI编程。因为我最近半年到一年，一直关注的一个重点，怎么将AI编程从个人级上升到组织级的工程能力。但是最近经过跟相当多的朋友包括在内部的一些试点试用，还是发现AI编程要变成工程级组织级的能力，太难了。

因为很多时候我们仍然是按照传统的软件工程，传统的岗位角色分工，对原有的类似于需求设计前端后端各个岗位进行AI赋能。在这种方式下面，你想通过AI实现成倍的效率提升，基本上是不可能的。包括在昨天我跟朋友沟通的时候，也举了一个例子，就是这种模式好像就是一个老的马车，它装了一个V8的引擎，但是接着跑着跑着就只能是散架。

AI编程要变成组织级的能力，一定涉及到整个开发团队本身的组织形态的变革。 包括在前两个月，我们就看到一个例子，就是对于得物，他把整个前端开发团队裁掉了。很多时候大家觉得不太理解，就是认为即使AI编程发展的这么快，很多复杂的东西不是仍然是需要前端岗位角色人员介入才能够解决吗？

但是大家有没有想过一个道理：

只要你有前端开发团队，那很多时候就会变成了叫因人设岗。 那么一定就存在后端人员对前端人员的依赖。在这种情况下面，你就很难让一个人同时具备前后端拉通的能力。所以说很多时候裁掉前端开发团队，往往是倒逼或者是反逼整个开发团队内部能力的提升，或者是转型，这样你就更加容易理解他的这么一个意义。

包括最近我们团队接了一个小项目，我也是一直在思考这个问题。基本上整个团队也是用了最新最强的一些大模型，但是整个项目已经过去了很多周，发现一个最基本的最终的需求和客户都还没有完成完整的确认。我们的需求人员也仍然用了很多AI辅助工具啊，类似于用Figma，类似于用墨刀去做AI辅助做原型，类似于写需求文档。但是你把相关的需求文档原型做完，跟客户确认，客户有反馈意见，来来回回一轮就是两三天，这个效率完全跟不上节奏。

更好的方式应该是什么样的呢？就是统一牵头的这个负责人用AI编程工具快速的出可交付的AI原型。 而且这种时候类似于磨刀，类似于Figma这一些原型开发工具，我的理解也都不需要。我需要的是一套UI的界面设计规范。有了这套页面界面设计规范的辅助，类似于Claude Code，它可以快速的输出可交付的原型，拿着这个原型和客户去做确认。确认完了以后，快速地进入AI辅助开发的阶段。这样的话才能够提升跟客户沟通原型交付的一个效率。

第二个就是在整个AI大模型、AI编程快速的发展下面，以后的叫技术架构上面是前后端分离，但是开发不前后端分离。开发人员在AI辅助下面应该同时完成前端和后端的功能的开发。 一样的道理，我需要的就是一套UI界面原型设计规范。有了这套规范，有了完整的软件需求的定义，AI大模型完全可以完成相应的前后端功能的开发，这是第二个我想强调的关键点。

第三个关键点就是涉及到测试，测试也是一样的。你首先要实践的就是自动化的单元测试，或者叫接口测试。 这个事情当前的AI大模型完成没有任何一点问题。第二个就是我们讲的黑盒的测试。黑盒的测试，我把它分成两类，一类就叫端到端的流程的UAT测试，一类叫单个功能点的通过模拟人登录进去的界面级的功能黑盒测试。那么当前的情况来看，对于端到端的UAT测试还需要用户介入去做相应的功能验收，但是对于单个功能的黑盒测试，我们现在通过浏览器的自动化已经可以完完整整的完成。

好了，有了完整的原始的需求，软件的需求，整个的设计的模型有了，我最终开发完成的系统。那自然而然我仍然进一步可以发挥模型驱动。我后面的用户手册、操作手册包括相应的需求文档、设计文档，应该是全部自动化输出，不需要人再写。

这样才能够完成基本上一个完完整整的工程级的实践。 而且这个工程级的实践里面就是以一个核心人员为主，其他人员配合，其他配合的人员有可能是AI智能体机器人，也有可能是真正的人。但是一个人从头到尾全链路拉通，这样才是真正的能够提升工程级交付的效率。

否则，在AI大模型时代，你仍然分了这么多岗位角色。每个岗位角色虽然也都用AI大模型赋能，但是这一些岗位之间还存在大量的人和人之间的沟通交互。这一些沟通交互一定是大量地降低了工作的效率。

第二个点就是只要存在沟通交互，那你跟AI大模型的时候，它的上下文是不连贯的。比如说需求人员整理好了需求文档，你让大模型去做相应的后续的开发。大模型不知道你形成需求文档的前因后果来龙去脉，它又要去学习和理解一遍你整个的项目的背景、需求的背景。这样的话就致使上下文不连贯，导致了大模型本身也不能够充分发挥它应该有的能力。而真正核心的，当你一个人来主导全流程贯通的时候，这个才是我理解的最好的一种方式。

好了，今天的简单思考就到这里，再见。