《软件方法》全流程引领AI-第1章 ABCD工作流-01
对PlantUML们的评价-《软件方法》全流程引领AI-第1章 02
AI辅助的建模步骤-《软件方法》全流程引领AI-第1章 03
伪创新-《软件方法》全流程引领AI-第1章 04
山寨、染色和敏捷-《软件方法》全流程引领AI-第1章 05
圈子割裂历史和封闭引用-《软件方法》全流程引领AI-第1章 06
用口号代替方法-《软件方法》全流程引领AI-第1章 07
第1章 ABCD工作流
1.6. 伪创新的乐土：“互联网”
图1-43 林正英电影海报
有个巫医发明了一种治疗方法。他坦言，我这个方法对付癌症可能不太行，但对付感冒很管用噢！你不信，找个感冒患者来！
巫医让感冒患者躺在一张绘有八卦图案的方桌上，然后绕患者八八六十四圈，每一圈的唱词都不一样（看到没，他也是有一套方法的！），然后对患者说，回去该吃吃该喝喝，五天之内就好了！
果然，患者好了。巫医四处宣传他的革命性划时代感冒疗法，迅速收获大批粉丝。
真相是：对于感冒来说，喝白水、喝肥宅快乐水+姜、喝盐水、吃草药、吃合成药、巫医施法，无论哪一个，感冒患者要走的流程都差不多，因为它是靠自身免疫力来对抗病毒。
★严格来说，这些也不是完全没有“好处”。可以借机放松身材管理，痛饮肥宅快乐水；吃合成药可以缓解一些症状；巫医施法能带来心理安慰。
1.6.1 “互联网系统”
我们这里说的“互联网系统”，更严谨的说法是面向大众、用户量巨大的网络信息系统。
目前（2025年）很多信息系统所使用的技术栈、部署方式以及访问方式和“互联网系统”相似，例如某家制药企业内部使用的制药行业生产管理系统，但并非面向大众，用户量也不大，像这样的系统，不是我们这里说的“互联网系统”。
互联网浪潮到来之前，信息系统的竞争焦点是功能。
★我1997年硕士毕业，先到高校当了一年老师，然后才去软件公司做程序员。第一个参与开发的系统是酒店管理系统（实现：Visual Basic+SQL Server）。这样的系统用的人不多，服务器一台，每个部门放上一台客户端电脑就差不多了，但功能很多，入住、退房、收银、客房，餐饮、娱乐、财务、电话计费、各种报表，覆盖了酒店内部流程的方方面面。
互联网的兴起带来了这样的系统：系统功能很简单，开发系统时需要思考的核心域逻辑很少，但是通过互联网，系统可以让非常多的人使用。
早期的典型例子是1996年出现的hotmail（被微软收购后演变成今天的outlook.com），这是一个基于web的电子邮件系统，推出一年多时间就有1200万的用户。同一时期类似的系统还有ICQ（即时通信）、GeoCities（个人主页）等。
★注意，邮件系统也是有丰富逻辑的，包括标准化的协议（SMTP、POP3、IMAP、MIME……）、地址解析和路由、加密等等，但绝大多数这些逻辑已经被前人探索得很清楚，甚至有实际的可用组件提供，并不需要web电子邮件系统的开发人员从头思考和建模。
今天，典型的例子是微信、抖音、微博等，当然，它们用户量往往以亿甚至十亿计。
用户量的增加和功能的简单化是互相促成的。随着系统用户数量的增加，系统的功能往往会取各类用户想要的功能的“公约数”，想要添加点什么必须非常谨慎，不会为了小部分人的特别要求就为系统增加新功能。
例如，有微商希望微信提供“美化营销话术”的功能，能根据对方的工作性质、性格等美化要发过去的信息，让其更容易打动对方……张小龙肯定理都不理。当然，其他开发组织可以为这些特定人群开发相应的微信小程序，那是另外的系统了，用户量也不是微信的用户量。
反过来，功能简单的系统，如果用户量不大，就没有盈利的可能，也就养不起开发团队，不会出现后文所描述的伪创新危害。
你觉得现在的记事本用得不爽，于是自己写一个自己用，你爱怎么开发怎么开发。只不过，你以此为素材分享你的“敏捷开发经验”的时候，造成的影响很小。
如果你的记事本不小心碰到了哪个痛点，用户量大增，但模仿者也很快出现，这时就进入到比拼背景、人脉、资金的环节。拼不过，“先驱”成了“先烈”。拼得过，成了赢家，这时再分享你的“敏捷开发经验”，影响力就不一样了。
这样的“互联网系统”，如果说有什么“技术难度”，肯定不是功能的实现，而是用户量起来之后，如何保持性能不下降。起大作用的还是金钱——有没有足够的资金不断购买基础设施来支撑到打败竞争对手。
这个“技术难度”也不是竞争的关键因素。微信之前有米聊，后来者还有易信、来往……。微信的对手们之所以在竞争中落败，是因为它们做不出微信的功能吗？是因为它们的技术无法应对用户量的增长吗？
1.6.2 “敏捷”的乐土
很多开发人员进入了开发或维护这样的“互联网系统”的公司，我们就叫 “互联网公司”吧。这样的公司就成了很多打着“敏捷”旗号的“方法”（实际上也没啥方法，主打一个“干就是了”）的乐土。
经常有人和我说：潘老师，敏捷这一套做工厂管理系统之类的可能不太行，但不得不承认，做互联网很管用噢！
我还看到，互联网公司的开发人员霸占了各个技术大会的讲台，他们四处布道“互联网开发思维”、“敏捷开发思维”。经常有这样的场景：一个互联网公司的开发人员在台上讲他们怎么开发自家系统的，台下的听众一听，这TM不就是瞎搞，不就是以前常说的作坊式开发嘛！当然了，演讲者自称“敏捷试错”、“敏捷开发”。
可是，不服不行，人家公司上市了，而且现在开始盈利了！台下有做电力、税务之类软件的同学就开始反思了，人家“瞎搞（敏捷试错）”，这么成功，我们又什么规范，什么建模，一年辛辛苦苦就赚个辛苦钱，不行，要向他们学习，回去马上引进互联网思维和敏捷开发思维，把我们的研发流程互联网化、敏捷化！
有的公司真的这样搞了，结果搞出烂摊子来，后来又来找我，潘老师，我们还是得把建模这些东西重新捡起来。
首先，可以用“幸存者偏差”来解释。很多“瞎搞（敏捷试错）”的公司死掉了，没有“正在其中工作”的开发人员，更不用说在技术大会的讲台上布道了。
其次，即使对幸存者而言，它们在竞争中能够打败其他对手存活下来，并不是自家系统本身的能力比竞争对手系统的能力高出一截，而是其他因素导致的。布道者为了拔高自己的形象，有意无意把自己所在公司的成功和“瞎搞（敏捷试错）”联系起来（这一点，前面在谈到“伪创新”买家时已经说过），引导听众掉入“错误归因”的逻辑陷阱。
“瞎搞”是事实，“成功”也是事实，但不能把并存当作因果，得出结论“因为瞎搞，所以成功”、“只要瞎搞，就能成功”甚至“只有瞎搞，才能成功”。很可能该公司的背景、人脉以及烧的钱才是成功的原因，至于公司里的开发团队采用什么开发方法，是站着、坐着、躺着还是倒立着开发，无关紧要，但是布道者巧妙地把并存转成了因果。
有一天，张三喝酒喝得半醉去买彩票，结果一开奖，中奖两个亿。大家请张三上台介绍经验，张三如实描述“我那天喝酒喝得半醉去买彩票，就中大奖了”，于是台下听讲的彩民纷纷去喝个半醉然后买彩票，以为这样就能中大奖。可惜，没中奖的李四王五等人没资格上台布道（幸存者偏差），喝醉是事实，中大奖也是事实，但不能因此推导出因为喝醉所以中大奖（错误归因）。
张三之所以能中大奖，背后肯定有原因，只不过这个原因很复杂，属于“上帝算法”，人类目前还算不清楚（否则用来算一下明天双色球多好），所以常会归因到能观察或理解的事情上。“喝醉酒”是一个用于加深读者印象的极端例子，更常见的归因是张三“祖上积德”。
利物浦和曼城激烈搏杀，最终利物浦2:0曼城。为什么利物浦能赢球，原因是球员、技术、战术的问题，哪个环节做对了或者搞砸了，球队主教练斯洛特或瓜迪奥拉心里是清楚的，但这对某些球迷来说太复杂了。他们会从一些自己能理解的地方找原因，比如球员球衣的颜色，教练穿什么内裤，球员在更衣室里是站着开会还是坐着开会，球员是不是结对洗澡等等。
★类似互联网布道者这样的错误归因，在互联网之前的软件开发行业就已经有了。上个世纪，很多企业的信息化改进受到很大阻力，反对的声音说：我们企业那么多年一直这么干，不也一直在赚钱嘛。这就是把并存当成因果。
★“没有做信息化改进”和“赚钱”是并存的，但之所以赚钱，是因为背后的某些背景。了解改革开放初期历史的同学可能知道“双轨制”、“官倒”这些词，以前某些官员的亲戚办公司赚钱实在太容易了。如果这个权力带来的好处能一直很爽地吃下去，搞不搞信息化改进是无所谓的。之所以要改进，就是因为这个“红利”不能继续吃下去了。
可能有人会说“就算功能很简单，但要应付这么多用户，背后技术门槛也不低啊，要是没有很多技术大拿支撑，网站早就崩了”。
我们再拿醉汉张三中奖的故事来说。喝醉酒和中大奖是并存，但不是因果关系，这是前面所说的。我们再看另一个问题，张三中奖两个亿，必须纳4000万所得税，否则大奖就没收而且还要坐牢。假设有个有钱人李四，他看到张三先中两亿大奖然后纳税4000万，于是李四干脆就预交了4000万给税务局，然后再去买彩票。李四中奖两个亿的概率会大大提高吗？
纳税4000万是中奖两个亿的结果，不是中奖的原因。互联网公司的很多开发人员属于“纳税型”，是公司的成功带来了他，他却误以为自己带来了公司的成功——“没有我们，双11的时候网站就崩了”。
★如果觉得“纳税”不好听，可以说“保镖”。张三中奖两个亿，然后请保镖，保镖说“没有我，你能有这两个亿吗”。
1.6.3 “领域驱动设计”的乐土
--待续--