接“造词圈子割韭菜”-从ABCD谈人工智能对软件开发的影响（1）-CSDN博客

本文链接：https://blog.csdn.net/rolt/article/details/145266914

前两天发了一个答疑视频《AI能做“需求分析”吗+警惕造词圈子割韭菜》，其实就是把之前写的同名文章转成了视频。

没想到，之前的文章点击量没多少，这个视频倒是引起了一些讨论，那干脆就多写一点吧。

（一）我平时用的AI工具

首先要说的是，我每天都用AI工作，所以不要说“潘老师是不是没用过，不了解它的威力”之类。

平时我用的工具的话，主要是这么三个：

我认为目前Claude是最好的。不太难的问题感受不深，但比较难的问题可以看出来Claude比ChatGPT要好。如果是简单的问题，就用免费的通义千问。

（二）建模工作流

给我发信息的或留言的同学，还是表现出一个问题：不了解软件开发需要做哪些思考。

题目和内容说的是“需求分析”（当然，这也是个模糊用语，视频和文章有说明），发过来信息却说到编码去了，而我在视频和文章里面都讲清楚了这个问题，可惜有的同学没有认真看。

所以，我们首先要了解一下软件开发需要做哪些思考。

还是看《软件方法》第1章：

软件开发的每一个迭代周期都需要依次思考这么几个事情：

A-业务建模（business modeling）——定位需要改进的目标组织以及该组织接下来最需要改进的问题。

B-需求（requirements）——描述为了改进组织的问题，待引入的信息系统必须具有的整体表现。

C-分析（analysis）——提炼为了满足功能需求，待引入的信息系统需要封装的核心域机制。

D-设计（design）——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。

在迭代周期中，如果要追求好的结果，按A→B→C→D的顺序来进行推理是必须的，而且各个开发团队一直都在这样做。我们来看几个场景：

开发团队甲，所有成员都认真学习《软件方法》和认真做题，引进了UML和建模工具EA，并按照书中的改进指南改进，最终得到很不错的结果。

开发团队甲的A→B→C→D很容易看出来。

开发团队乙，没听说过《软件方法》，也不用UML和EA，用的是技术总监自己归纳的一套“软件工程方法学”和符号，也还算行之有效。

开发团队乙的A→B→C→D也容易看出来，但形式上和开发团队甲不同。

开发团队丙，快乐拥抱挂着“敏捷”或“领域驱动设计”名头的伪创新。这些伪创新投资少，见效快，门槛低，产量大，仪式感十足。开发团队轻松愉快、热热闹闹地讨论和糊墙。

这里面有A→B→C→D吗？也许有一点，但很少，这些热闹只是装模作样。真正起作用的A→B→C→D推理，可能是在编码的时候在大脑里朦朦胧胧进行的，推理的质量可想而知。

开发团队丁，觉得既然ABC我都不会，我也不想装模作样，就一步到D，直接编码。

这种情况下，还有A→B→C→D吗？有的，和开发团队丙差不多，真正起作用的A→B→C→D推理，是在编码的时候在大脑里朦朦胧胧进行的，同样，推理的质量可想而知。幸好，省去了伪创新装模作样的成本。

开发团队戊的故事（纯杜撰，勿对号入座）看起来有点不一样。他们所在的公司赶上了风口，成了某个领域（例如预制菜）的互联网巨头。在开发和维护预制菜相关的项目时，开发团队戊的领导下觉得现在的前端框架Vue、React等还差点意思——更有可能是为了自己的简历积极主动地“觉得”Vue、React等还差点意思，于是搞了个内部项目，自研前端框架“闪电五连鞭”。过了几年，也许是风潮过了，也许是历史使命已经完成，预制菜市场冷却，反倒是“闪电五连鞭”框架误打误撞，受到全世界开发人员热捧，成为公司的生存支柱。

这里面有A→B→C→D吗？看起来像是颠倒了？

再看一个特别的，程序员张三自己做一个东西给自己用。张三只会用编码工具，也没学过UML或类似的知识。

张三这里面还有A→B→C→D的推理吗？

最后这两个，答案也是一样的，并没有什么特别，具体留到后文详述。

总之，每一个软件项目，只要不是故意摆烂，开发团队都会有A→B→C→D的推理过程——也许无意识、隐式地做，也许有意识、显式地做；也许推理过程严谨合理，也许推理过程漏洞百出；也许分成很多人来做，也许一个人做；推理产物的形式也许是UML模型，也许是其他……

就像一道复杂的数学填空题，答案是97/2023，如果考生能填对这个正确答案，他必然在考试过程中的某个时间点做了正确的推理。只要不是故意摆烂，即使是学渣，也会尝试着去推理。只不过相对于学霸的一击必中，学渣可能要反反复复“敏捷探索”多次才答对，甚至直到考试结束还没答对。

本书希望教给读者一种严谨和高效的推理方法。当然，要掌握它，需要付出辛勤和汗水。