大家好，我叫钟杰，是个做了 4 年的前端工程师，我所在的公司是做低代码的，低代码行业基本都在尝试引入 AI 智能体，通过训练存量客户所搭建的应用数据，来帮助后续客户快速上手产品。大概流程就是：提出类似于“我要搭建一个生鲜市场的出入库管理系统”，之后系统会创建好一个相对完整的表单应用。然后客户在半成品上基于自己的需求，去进行调整。

在 ai 工具出现以前，客户搭建自己的应用是通过内置模板 + 帮助文档，在和公司客户成功团队的帮助下，基于自己的需求，搭建匹配业务的应用，这也是大部分 SAAS 和 低代码工具的运营模式。企业希望通过 AI 工具的引入，借此降低公司客户成功团队和客户之间的沟通时间于成本。从而服务于更多的客户来赚取更多的利润。也许是因为近两年对于各类 AI 的营销，都是以降本增效为卖点，再加上公司的盈利能力在不断下降，公司将 AI 看作了提升人效比的银弹，企图通过粗暴地替代某一个环节，来降低整体的成本。

引入工具但不引入标准

对于工具的盲目崇拜，其实在 ai 工具出现以前，就已经大量存在了。比如

1. “死文档式”记录：引入敏捷开发的站会、看板，却不构造通用语言，依旧以开发 90%、开发了一半这种模凌两可的沟通方式。所有的业务知识记录在类似于语雀的外部文档中，随着人员的流动，我们很难追溯已有的逻辑。最后的沟通就变成了“按照线上来”，“线上咋样，不知道啊”。所谓的拆解，工时预估，也不再具有参考意义。
2. 只磨刀不砍柴：质量监测工具(SonarQube，test covery，sentry) 的根本作用在于减少人工发现代码问题的成本，但是发现问题后呢？”测试覆盖率不足是否有制定要求？“，“代码重构前是否有覆盖安全网？”。最终陷入工具越舔越多，质量越来越差的境地。
3. 重复地造轮子：代码的第三方依赖中，往往存在这功能类似的不同外部依赖包，以及不少不知道在什么背景下开发，完全照抄外部依赖的 kpi 代码。完全缺少对依赖引入的审核流程。

软件开发：获取、学习并传递知识

%% 应该查找《活文档》，《知识管理》 %%

在《知识创造公司》中指出，“知识创造是一个动态的过程，涉及到隐性知识到显性知识的转化。组织需要建立一个能够促进这种转化的环境”。正如在软件开发中，开发者需要深入理解用户需求（隐性知识），设计出高效、可靠的解决方案（显性知识）。另外，在《知识管理：理论与实践》中强调“知识管理的核心在于如何有效地获取、存储、传递和应用知识。组织需要建立有效的沟通机制和平台，促进知识的流动和共享”。对于程序员来说，其实就是写的代码是否可读，下一个人维护的人是能否理解。所谓的引入 AI，无非是把知识的传递对象，变为一台机器罢了。作为程序员，我们要做的依旧是获取、学习并传递知识的过程。

有约束的知识，才能有效传递

在日常开发中，我们经常会遇到外部依赖库更新导致接口变更的情况。这种变更不仅增加了项目维护的工作量，还可能引发更深层次的问题。如果仅仅是API层面的变更，我们只需花费时间和精力进行代码修改和验证。然而，有时依赖库的更新不仅仅是接口的变更，甚至改变了预期的行为，即所谓的“break change”。这种情况下，我们不仅需要调整代码，还可能需要重新审视和修改业务逻辑，这无疑增加了项目的复杂性和风险。

依赖库的用户越多，其更新影响范围就越广。依赖库的设计者和使用者之间实际上建立了一种“契约”，尽管这种契约没有纸面合同来约束双方。因此，依赖库的设计者在更新时需要谨慎，尽量避免破坏性变更，以减少对使用者的影响。

回到业务代码的设计，我们的代码终究是为了实现功能，让企业能够使用功能来赚到钱。我们设计的API首先需要清晰地表达业务功能。这时有的人可能会说，如果公司不大，人也不多，抬头不见低头见的，直接平时喊一声问一下不就好了。殊不知，公司倒闭的种子，在这时就已埋下。那么在业务代码设计中，技术之间的契约如何规定呢？谜底就在谜面上，想想业务的变更是由谁提出的，是客户。而客户会和企业签订合同，合同就是最好的契约。可以说，我们系统中的每一个功能，在背后都有一个或者多个的合同/客户，一旦这个功能不可使用或者出现违反合同内容的变更，那么带来的便是退款、产品形象损失，甚至是不得不打官司的地步。

从业务出发，构建业务强相关的模型

从贫血模型与充血模型

现在有一个常见的描述：用户的订单列表。如果是领域驱动设计（DDD）来描述的话，就是用户是订单的聚合根（Aggregate Root）。

这里补充一些概念，在领域驱动设计（DDD）中，聚合（Aggregate）是一组相关对象的集合，被视为一个整体单元，用于确保业务规则和一致性。聚合根（Aggregate Root）是聚合中的一个对象，通过它来访问整个聚合。

看不懂上面领域驱动设计的概念也没关系，我们可以回顾一下平时访问购物软件。有一个废话般的逻辑：“如果不登陆拿到用户信息，就无法读取到订单列表”。为了表达用户的订单列表，我们需要同时使用用户和订阅两个概念。因为一旦脱离订单，用户只能单纯地表示用户的个人信息；而脱离了用户，订单也就只能表示单个的订单信息。只有两者放在一起，才能表达我们需要的含义：用户的订单列表。

在我们的概念里，与业务概念对应的不仅仅是单个对象。通过关联关系连接的一组对象，也可以表示业务概念，而一部分业务逻辑也只对这样的一组对象起效（比如多选订单并删除，只对一组订单列表有效）。但是在所有的关联关系中，聚合是最重要的一类。它表明了通过聚合关系连接在一起的对象，从概念上讲是一个整体。

1. 贫血模型（Anemic Model）

在贫血模型中，领域对象（如 User 和 Order）通常只包含数据，而不包含行为。业务逻辑通常被提取到服务层（Service Layer）中。

贫血模型的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// 贫血模型的 User 类
public class User {
    private Long id;
    private String name;
    private List<Order> orders;

    // Getters and Setters
}

// 贫血模型的 Order 类
public class Order {
    private Long id;
    private String productName;
    private BigDecimal price;

    // Getters and Setters
}

// 服务层，包含业务逻辑
public class OrderService {
    public List<Order> getUserOrders(User user) {
        return user.getOrders();
    }

    public void addOrderToUser(User user, Order order) {
        user.getOrders().add(order);
    }
}

在这个例子中，User 和 Order 类只包含数据（属性），而没有行为（方法）。所有的业务逻辑都被放在了 OrderService 中。

2. 充血模型（Rich Model）

在充血模型中，领域对象不仅包含数据，还包含行为。业务逻辑被封装在领域对象内部，使得对象更加自治和内聚。

充血模型的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// 充血模型的 User 类
public class User {
    private Long id;
    private String name;
    private List<Order> orders = new ArrayList<>();

    // Getters and Setters

    public List<Order> getOrders() {
        return Collections.unmodifiableList(orders);
    }

    public void addOrder(Order order) {
        orders.add(order);
    }
}

// 充血模型的 Order 类
public class Order {
    private Long id;
    private String productName;
    private BigDecimal price;

    // Getters and Setters
}

在这个例子中，User 类不仅包含数据（属性），还包含行为（方法），如 getOrders() 和 addOrder()。业务逻辑被封装在 User 类内部，使得 User 对象更加自治和内聚。