大模型的思维方式和辅助领域建模。

xiaowenz / 2023-07-20

因为我一直在用类似的Prompt做事儿，正好参考

https://twitter.com/barret_china/status/1681850425983791104?s=12&t=90piq2L2KKHG1sqvpHgJYg

的样例，增加一些解释，我的理解和案例测试。

这是要干啥

在面对大模型进行复杂任务拆解或者需要链式思考的时候，含糊的规则描述会让模型倾向于反馈最简单而中庸的答案，无法达到我们预期的让模型替代部分固定的思考范式的目的。

因此，比较有效的办法是除了明确的思考链路外，提供更详细的样例来规定输出的内容，格式，压迫模型按照即有的不可被省略的逻辑进行计算。

也就是说，除了任务的目标外，碳基人类需要先把复杂任务拆解为明确的子任务，并设计好任务之间的逻辑关系，中间产出的信息等关键路径。

目前的模型无法帮你完成你原本自己都不会的任务。目前的AI远不是全能的神，只是一个智商很高但知识很弱的助手。

你不能告诉模型「请帮我对XXXX功能进行领域建模」，这样模型的产出虽然也能大差不差的有很多关键信息，但往往距离你可以直接继续接手的状态还挺远的。

如：

Me:

请帮我对用户抽奖功能进行领域建模

Claude+

用户抽奖功能的领域建模如下:

用户(User)

用户名

抽奖次数

抽奖池(PrizePool)

id

奖品名称

奖品数量

中奖记录(WinningRecord)

用户名称

中奖奖品名称

中奖时间

主要流程:

用户登录系统后,获得相应的抽奖次数

用户使用抽奖次数,进行抽奖

系统从抽奖池中随机选择仍有剩余奖品的奖品,并颁发给用户

生成用户的中奖记录

说明:

用户通过用户名登录系统后,系统查询用户的剩余抽奖次数

用户每次抽奖会消耗1次抽奖机会

抽奖池中保存所有可供用户抽奖的奖品信息和剩余数量

每次中奖后,对应奖品的剩余数量会减1,同时生成中奖记录

用户抽奖后,系统需校验抽奖池中对应奖品是否仍有库存,否则不能抽到该奖品

以上就是我对用户抽奖功能的领域建模,希望能够帮助到你。如果有疑问,欢迎随时与我交流。

以下是相对更明确和完善的Prompt和测试案例，比较一下也许能帮助您更好的理解模型的思维方式，更好的让他帮助你。

Prompt

这是一个领域模型建设问题的拆解思路，步骤如下：

1. 问题分析，当你看到 “DDD:” 开头的问题时，对问题进行分析和梳理，找到领域中的实体、属性、关系和行为进行建模，创建领域模型，并用文字绘制出实体之间的关系图
2. 针对第一步中的建模内容和关系图进行分析和梳理，跟对比最初始的问题，找到更优解，循环第一步，直到建模达到优良的水平
3. 根据第二步的结果，输出 Model 层和 Service 层的代码，并枚举需要用到的 Restful 请求范例
4. 对问题和分析过程进行总结，重点描述以上解法中的难点和重点

例如：

"""
DDD: 实现一个抽奖模块

### 问题分析

实体：抽奖活动、参与者、奖品
属性：
  - 抽奖活动：{}
  - 参与者：{}
  - 奖品：{}
关系：
  - 抽奖活动和参与者的关系：{}
  - 抽奖活动和奖品的关系:：{}

###  领域建模

通过文字使用UML类图将上面的实体、属性和关系表达出来: {}

### 编写代码

根据上述 UML，将对应的 Model 和 Service 层，使用 基于Java和SpringBoot 代码编写出来: {}

### Restful 接口

将所有的接口以如下形式展示出来，params 和 result 使用 json 描述：

```
GET /api/prize
params: {}
result: {}
```

### 总结

{}

"""

样例

最后

目前的Claude2和ChatGPT4都能有比较理想的结果，意味着在这类明确的推理场景下，达到大模型们「可用」的能力门槛的参与者，越来越多了。