从Harness、Loop联想到敏捷的拼积木折飞机

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

这两年，和AI相关的造词层出不穷，还喜欢在后面带个Engineering。

一开始是Prompt Engineering，然后是Context Engineering、Harness Engineering、Loop Engineering。

在这些造词出现之前，这些做法已经存在。只不过某些人擅长造词，擅长宣传，就把这个变成他的了。

不过，本文的主题并不是像批评领域驱动设计伪创新一样批评这些造词，而是“过程”和“方法”的区别。

这些Engineering当然有用，它们奔着让AI能够稳定输出而去。但是有一点，它们仅和“过程”有关，并不涉及“方法”。

甚至于，它们和软件开发实际上并没有特定的关系。虽然很多是软件开发人员咣当咣当在那里闹得很欢，但它们也可以用在别的领域，例如近期的这些论文：

材料科学

生物制药（抗体设计）

联想到前些年的某些“敏捷开发”培训。一帮软件开发人员在那里拼积木、折飞机，还有搬气球。

你说有用没用呢，当然是有用的。问题是，这些东西跟软件开发没有特定的关系。

“敏捷开发”培训可以用来培训软件开发人员、也可以用来培训美发师、保险推销员以及微商：

这有啥问题吗？

问题在于一个通用的培训（打鸡血），却打着“软件开发技术”的名头出现，挤占了“软件开发技术”培训的份额。培训了这个，就没有更多的时间和金钱去给软件开发人员培训软件需求技能、软件设计技能——显然，我是“受害者”之一。

*****歪楼*****

你别说，这样的“敏捷开发”培训有时候更让开发人员觉得“受用!”。就像让所有学生投票“数学退出中考高考”，你猜支持的人多还是反对的人多？

有一些开发人员就是不想学习需求和设计技能，不想认真思考，就想搞人际关系。

这些人中，其中一部分是无意识抵触，另外一部分人则是有意为之，虽然他知道，学习需求和设计技能对自己有好处，但是他更知道自己不擅长这个，即使学习也可能拼不过其他更擅长的人，所以最优策略：把这口锅给砸了，逼其他人走自己所擅长的赛道。

*****歪楼结束*****

普遍适用的东西，不能成为核心竞争力。

前些年，敏捷布道师经常喊“软件开发的关键是人！”。

对吗？当然对，你好厉害哦，这么深奥的道理都懂。

问题是，难道别的行业的关键就不是人吗？这个跟软件开发没有特定关系。

这些东西可以搞，但如果软件开发人员以为搞这些就够了，不去学习软件开发方法学，或者被这些东西占据了大量的时间，再没有余力去学习软件开发方法学，那就有问题了。

AI时代的各种Engineering也有类似问题，要警惕。

更多细节：

一个人的软件工程-《软件方法》全流程引领AI

umlchina.com/url/aiuml.html