最近打算开发用于软件工程的LLM和Agent用于工作流，又看了一些软件工程的书。

目前的原则是，人不能深刻理解的东西，也不要依赖于LLM去实现，因为这样将导致失控。而tob业务客户关心的是对AI算法能力的控制。

因为本人是算法出身，所以也算是通过复习学习到了一些东西，整理一下给大家分享。

学到的两个知识点，就是1何为抽象？2为什么把问题分解可能让情况变好？

1 何为抽象？

经常有一个常见的例子就是

“

依赖倒置原则（Dependency Inversion Principle, DIP）

”

上文中ShoppingCart依赖的interface是一个抽象，抽象到底是什么，它提供的“功能”就是，就是支付。我们忽略支付的具体实现方式，这里抽象就是一个“名”。“名”就是一种抽象，它是一种简化。在认知的角度，喊一个人的名字，大脑中会出现一个人音容笑貌。一个人的长相，他给你带来了什么，组成他的身体的所有分子，他脑子里的信念、习惯，这都是具体给你带来的实现方式。而现在，“名”就是仅仅是一个名字，是一个填到表格里的字符串，或者需要在其后打对钩表示签到的东西。

这就是抽象，就是对事物的整体（不限于认知意义上、物理意义上、和环境交互意义上的）做删除和剥离。剥离后留下的一部分东西，真正需要的，在这里就是payment支付功能的interface了。而它的实现，就由更复杂的代码来完成（来implement）。

依赖于抽象就是依赖于具体的事物的某一个方面。

其实这个例子可以方便的帮助我们理解何为抽象，何为接口。那么其实，例子也是一种抽象，因为它以偏概全，以后我们遇到本质上相同的模式，都可以用这个例子去套，看在那种情况下，什么是Shoppingcart，什么是payment。以偏概全有错吗？它降低了认知的负荷。同时使得认知过程更精确，更有目的性，删掉了不必要的部分，也就是implementation中和Shoppingcart的不直接相关的细节。

2 为什么需要分解？

这里直接引用那本《软件工程实践者的研究方法》这本书的说法。解决问题，假设需要认知任务h1和h2。h1和h2同时去解决消耗的认知资源，就大于h1单独解决+h2单独解决的资源以及单独解决后组合的资源。

这很容易理解，举一个例子，比如看到一个新闻，你可能觉得很震惊，这个过程消耗脑力。但是反过来你可以去考虑，这个新闻不是真的，然后又平复了震惊。这里就分成了两个步骤，首先又第一反应，其次有第二反应（思考，快与慢）。如果强行合并，那么每次你就要同时判定新闻真假同时针对内容作反应，如果你的脑子是一个大模型，这个输入的提示词长度就很长，或者我们的脑子其实就很“累”。这里需要注意的是上面提到的单独解决后组合的资源。这一点非常重要，整合本身也是消耗资源的。

3 净室软件工程

这个是高精度的软件工程研发方法（航天、医疗、军工领域的精确度可靠性等质量指标很高的软件工程开发方法），这个其中的方法论，我也是准备引入到大模型的方法中。

“严格的开发环境： 净室软件工程要求在受控的环境中进行软件开发，这个环境应该尽可能地减少外部干扰和潜在的错误源。这包括对开发人员的工作空间、工具和过程的严格控制。