[本体 FDE]一个人的软件工程-《软件方法》全流程引领AI-第19期

批评幼稚的想法（202609新感受）

这段时间很多同学和我交流本体建模、FDE。关于这方面内容，我之前发过文章和视频：

*《二十四年前在UMLChina谈本体论-James Odell》

*《 [视频]再谈本体论、文科生和DDD圈子》

不客气地说，从交流的话语中判断，其中一些同学属于我严厉批评过的：

潜意识里就没有打算把一个东西扎扎实实学会，还通过不断“追求新技术”来掩盖——不是我怕辛苦，而是我刚学了一点，它就过时了，新技术又来了。

即使是我的学员，我也批评过类似情形：

如果认真把《软件方法》看一看，把题做到75%正确，也不至于10年甚至20年没有进步，隔一段时间就来问我“潘老师，你觉得最近***提出的***怎么样”。

类图或ER图画得不合格，正确的业务流程和需求不知道怎么表达，靠谱的需求调研不知道怎么做，就指望靠学一下“本体建模”、“FDE”弯道超车？

所以，我不会专门开“本体建模”、“FDE”的课程（可以出门左转找敏捷圈子和DDD圈子，他们给足情绪价值），但本期开始增加“本体建模和FDE祛魅”的内容。

很多开发人员在说，自己已经在“深度使用AI”了，觉得自己变强了。

甚至有人炮制“敏捷”言论割韭菜，说试错成本降低了，不需要方法学了，敏捷（无脑）试错就行！

这样的想法是很幼稚的。其实本人反而变得更弱了，却有“变强”的错觉，全然忘了，竞争对手也同样在“深度使用AI”。

不是AI和人竞争，是AI大背景下人和人的竞争！

（1）编码的失控

AI在实现环节表现是最好的，Vibe就行，但是，如果没有把控住C-分析的环节，随着系统需求的增加，AI的各种修补、拼凑变得越来越笨拙，最终不可收拾。

近期热炒的Palantir和本体，虽然是商业炒作，但也凸显了“C-分析”工作流的重要性。

（2）需求还是拍脑袋

再做一个“贪吃蛇”并不能卖钱。

随着实现的门槛降低，需求的竞争变得更激烈。你所构思的系统必须要比竞争对手给客户带来更深刻的改进。

以往的“我这个系统虽然没什么创新点，但沉淀了不少劳动，总能值点钱吧”已经失效了。

这就需要“A-业务建模”和“B-需求”工作流的技能。

（3）对ABCD无知，Spec、Skill、Harness也没用

一开始是Vibe Coding，后来又说要Spec-Driven，然后又热炒Skill、Harness，也只是在形式上做文章。内容呢？

很多人（包括伪创新圈子以及伪创新Fans心目中的国外“大神”）不了解A-业务建模、B-需求、C-分析、D-设计在内容上的区别以及其中的推导过程，谈论Spec的时候，根本不知道自己在谈什么，这和之前这些人谈论UML时一模一样。

内容以前是怎么来的，现在还是怎么来的。以前是拍脑袋，现在还是拍脑袋。以前是想到什么写什么，边界跳来跳去，现在还是想到什么写什么，边界跳来跳去。

缺少方法学的知识，Spec越来越像伪代码，其实就是重复之前非常受伪创新买家和卖家欢迎的“敏捷实践”，拍脑袋编码，然后从代码出发，需要的时候“补文档”。《软件方法》第1章严厉批评了这样的思维颠倒。

幸运/不幸 的是，这部分内容不但人类目前没有研究透，而且AI也没有形成通识，甚至还有被伪创新污染的趋势！有方法学思想的人来引领AI，至关重要。

本课程和你探讨：

*怎样用AI帮你思考目标组织

*怎样用AI帮你改进业务流程，推导出目标系统好卖的需求

*怎样用AI帮你寻找涉众利益

*怎样用AI帮你检查需求规约内容是否符合涉众利益

*本体建模和FDE祛魅

*怎样在AI辅助下生成分析模型（类、状态机）

*把控分析模型，为AI定下锚点，使“Vibe Coding”、“Spec-Driven”始终保持可控

*怎样用AI从分析模型生成可直接使用的软件

*UMLChina的方法学智能工具Fagao

一个人可以干大事

如果你不能强大到能严谨地引领AI，你得到的结果很难打败你的竞争对手。

本课程重点放在AI辅助上，学员在上课前需要有《软件方法》的基本知识，可以通过以下方式之一达到：

*（推荐）已购买和学习番号为UML-001的视频，即“软件需求设计建模方法学全程实例剖析”知识讲解视频（https://umlchina.com/url/video.html）

*之前上过“软件需求设计建模方法学全程实例剖析”公开课（目前知识讲解部分已经改为视频UML-001）

*已认真阅读《软件方法》书（https://umlchina.com/url/softmeth.html）或者“软件需求设计建模方法学全程实例剖析”训练的幻灯片（https://umlchina.com/training/slide.html）。