本文来源公众号“阿里云开发者”，仅用于学术分享，侵权删，干货满满。

原文链接：https://mp.weixin.qq.com/s/PCQOiV5PgvkvuQqRsuMB6Q

• 业务场景：后端JAVA业务代码生成。

• AI解决方案概述：从系分出发，解析提取其中核心内容，并生成任务列表，再让AI工具结合提示词完成任务（生成代码）。

• 工具选择：IDEA CodeFuse插件 + CodeFuse IDE。

• 使用效果概述：目前已经覆盖门面层代码的生成和修改、持久层代码的生成和修改、业务逻辑层的代码生成。已经正式投产到三个项目迭代中，参与项目已经上线。在应用了AI Coding的三个项目中，编码阶段的人日投入平均减少了40%。

文章略长，分（上）、（中）和（下）三部分。

一、引言

在国际信贷业务系统建设过程中，技术团队始终面临双重考验：一方面需应对日益加速的需求迭代周期，满足严苛的代码质量规范与金融安全合规要求；另一方面，跨地域研发团队的协同效率与代码标准统一性，在传统开发模式下逐渐显现瓶颈。为突破效率制约、提升交付质量，我们积极探索人工智能辅助代码生成技术（AI Coding）的应用实践。本文基于国际信贷技术团队近期的实际项目经验，梳理AI辅助开发在金融级系统快速迭代场景中的实施要点并分享阶段性实践心得。

本文主要考虑使用结合CodeFuse及提示词，实现从系分到代码，提升JAVA开发同学的开发效率。

在叙述逻辑上，首先针对团队现状、开发内容以及对提示词的结构进行分析，再基于分析结果形成整体方案，然后根据实际案例评估效果，最后总结后续探索方向。

二、实现思路

本章节主要描述了对于AI Coding的目标制定、工具选择以及代码生成的思路，最后根据上述内容设计了一套基于CodeFuse + prompt 的AI Coding 操作流程。

2.1目标

本次使用AI Coding的目标，是打造一套通过CodeFuse 完成从系分到代码，再通过MCP Server接入系统知识库，检查代码规范及质量的标准研发流程。

目标	描述
研发提效	为开发同学减负，提高整体研发效能，做到减少编码阶段40%人日
设计即生产	系分即代码。从系分出发，直接生成JAVA代码
规范基因化	通过AI结合开发规范实现代码命名、层次、调用关系，减少人为代码风格不统一，从根源保证应用代码规范
开发者体验友好	打造直观易用的开发者体验，让工具成为得心应手的助手而非负担

2.2现状分析

当前对于推广团队所有人都使用AI工具还是存在一些难度的，主要在于以下几点：

1.普及难度：多数同学更喜欢使用IDEA开发JAVA代码，对于一个小几十人的团队，让每个人都一直根据最新调研内容不断更新工具来开发，很难普及。

2.操作难度：如果使用AI工具时，手工操作和写提示词的时间不亚于写代码的时间，并且后续准确度不高、人工检查修改的成本更高的话，那这的东西的普及就会变得更加困难。

3.AI信任度：部分同学对于AI生成代码仍无法信任，操作方式、产出结果需要为团队同学建立信任感，所以需要该工具的功能一致迭代且一直接入新的大模型，以防变成内部一次性产品。

2.2.1工具选择

今年3月，看到了很多CodeFuse IDEA插件的推广，使用感觉具备一些基础功能且会一直接入新的大模型。由此考虑从CodeFuse开始调研，除非出现其他比其优秀很多的插件外，不更换工具的使用。经过CodeFuse的多次迭代，我对除了所有工具都有的agent模式外的，其中三个功能非常喜欢：

a.文本绘图提取

CodeFuse IDE 对语雀文档中文本绘图（SVG图片）的读取及文字提取。

b.manual模式

CodeFuse IDEA插件的manual模式。

对于明确任务的执行速度更快且没有过多思考，十分节约时间。

c.自定义指令

CodeFuse IDEA插件的自定义指令。

减少每次生成测试时，复制一大堆文字的麻烦，复制一大堆文字再次输入的麻烦。

2.2.2生码范围及顺序

当前基于团队内部核心应用的代码架构来进行代码生成，针对此应用及多数JAVA业务系统的架构设计，个人认为对于部分强业务属性的JAVA应用，都是对外提供接口能力，这些接口能力是对下游等外部能力进行调用和流程串联编排，最后整合结果返回给上游。针对以上逻辑对一个JAVA应用的构成部分简单分为以下三个部分：门面层能力、外部能力以及业务逻辑。

下图为应用结构的简单图示：

manage层为该应用独特的整合业务逻辑的层级，与其他应用的Service、Processor等相似，这里主要体现该层为业务逻辑编排层。

其他层级结构暂不考虑，例如定时任务、灰度开关等变更次数少且比较定制的代码。

代码生成顺序为：首先根据接口文档生成门面层内容，再通过表结构设计将持久层内容以及DB服务层生成好，然后将剩余的外部能力代码准备好（例如一些下游client、缓存、消息等），最后生成业务逻辑串联所需外部能力，并衔接门面层对业务逻辑层的调用，将流程整体串联。

2.2.3流程设计

1.数据来源

读取系分提取其中核心/生码必备内容，包括接口定义全部内容、数据表结构以及流程图/时序图。在提取出所有内容后，会根据提取出的内容来生成代码生成任务，最后来进行代码生成。

2.操作流程

对于一个应用来讲，不同模块的代码结构都有自己规范和约束，使用一份通用的提示词来生成所有模块内容肯定是暂时无法实现的，所以这里一定是需要根据不同模块来开发不同的生码提示词，不同模块的提示词的结构和组成内容是不同的。

以本文为例，我将整体拆成了三个部分，所以我需要开发三个提示词来用于生成这三个模块的代码。

简单来讲，就是这样：

展开一点的话，是这样：

流程图增强会在后面提到

三、提示词设计思路

本章节主要描述了对于上章节中提到的各个提示词的开发思路以及具体内容。

其中包括了：系分任务拆分提示词、流程图内容增强提示词、门面层代码生成提示词、持久层代码生成提示词以及业务逻辑代码生成提示词。

3.1系分任务拆分

这块相对简单，主要是读取文档->检索到目标位置->内容提取->按照任务模版生成任务列表。

下面是使用系分任务拆分提示词时需要注意的点：

• 系分模版：系分内容提取需要制定系分模版，明确门面层接口定义、数据表结构以及每个接口的流程图的位置和标题。

• 变更类型：核心内容需要标注出当前内容为新增还是修改。

• 物料格式：内容提取提示词中需要包括每个模块的物料的提取描述、约束以及输出格式。将系分核心内容提取出。

• 任务格式：制定任务模版，让其在读取完物料内容后，根据已提取的物料内容的模块类别以及变更类型来生成任务列表。其中任务内容中，包括了任务需要引用物料区的哪些内容，以及任务执行的描述。

这里简单描述下提示词样例以及产出样例：

由于每个团队系分模版可能目录结构和内容都不同，所以这里仅做样例说明，使用时需要自行调整内部目录内容及约束。

接口内容提取提示词样例

# 接口清单## 3.4 对外接口设计检索当前章节下的所有内容，对其中的接口进行提取，再根据文档内容生成每个接口的以下信息：要求：- **禁止**遗漏接口数量- **禁止**遗漏接口内容- **强制**全量接口的全量接口信息都提取出来- **强制**当不同接口之间存在重复内容时，也要在每个接口的物料内容中，把重复内容的明细全量列举出来- **强制**将提取出来的内容按照以下‘输出模版’的格式写入到‘任务列表.md‘中
``` 输出模版### {接口名称}#### 接口信息- 接口描述：{接口描述}- 服务路径：{接口全限定类名}- 请求参数：{参数名称}  - 参数结构：  {转换为markdown表格}- 返回结果：{结果名称}   {转换为markdown表格}- 内部嵌套模型/二级模型{模型名称}{转换为markdown表格}```

任务提取提示词样例

## 第二步：生成任务列表1. 在app/全流程内容/目录下创建Todo_Task_list.md并按照以下结构提取文档内容：2. 生成持久层任务，参考下面的持久层能力文本生成持久层能力任务。3. 生成门面层任务...
```markdown 持久层能力# 持久层能力遍历物料文档"数据表清单"章节，为每个数据表生成以下内容：## 任务{n} ：创建{表名称}持久层### 物料引用> Todo_Task_List.md#数据表清单#{表名称}### 任务内容根据物料引用的内容，读取到相关物料内容，并按照app/全流程内容/持久层代码生成提示词.md中的内容生成代码，不要新增内容，也不要省略内容。```

产出结果案例

!!!!**以下内容为提取结果的举例，其中表结构信息为AI虚拟构造，此处仅为表现提取后文本格式**!!!!
# 数据表清单## user| 字段名       | 数据类型 | 长度 | 约束                   | 默认值   | 说明                ||-------------|---------|-----|------------------------|---------|--------------------|| id          | BIGINT  | -   | PRIMARY KEY, AUTO_INCREMENT   | -| 用户唯一ID          || username    | VARCHAR | 50  | UNIQUE, NOT NULL              | -| 用户名（唯一）       || password    | CHAR    | 64  | NOT NULL                      | -| SHA-256加密的密码   || email       | VARCHAR | 100 | NOT NULL                      | -| 邮箱地址            || age         | INT     | -   | CHECK (age >= 0)              | NULL | 年龄（0-255）   || gender      | ENUM    | -   | -                             | 'unknown' | 性别      || created_at  | DATETIME| -   | NOT NULL        | CURRENT_TIMESTAMP  | 账户创建时间     || balance     | DECIMAL | 10,2| NOT NULL        | 0.00               | 账户余额        || last_login  | TIMESTAMP| -  | -               | NULL               | 最后登录时间    |
# 接口清单## 用户流程接口### 用户创建#### 接口信息- 接口描述：用户创建- 服务路径：com.xxx.appname.facade.api.user.UserFacade#userCreate- 请求参数：UserCreateRequest  - 参数结构：  | 参数名 | 参数描述 | 数据类型 | 是否必填 | 长度 | 备注 ||-------|---------|---------|--------|------|------|| username | 用户名   | String | 是    | 64  |      || password | 密码    | Strin g | 是    |    |       || age      | 年龄    | int    | 是     |    |       || gender   | 性别    | String | 是    |    |    || UserCertModel| 用户信息模型  | String | 是    |  |    |
- 返回结果：UserCreateResult| 参数名 | 参数描述 | 数据类型 | 是否必填 | 长度 | 备注 ||-------|---------|---------|--------|-----|-----|| status| 状态    | String   | 是     |      |      |
#### 内部嵌套模型 UserCertModel| 参数名 | 参数描述 | 数据类型 | 是否必填 | 长度 | 备注 ||-------|----------|----------|----------|------|------|| certType | 证件类型 | String | 是 |  |  || certName | 证件名称 | String | 是 |  |  || certNo | 证件ID | String | 是 | 64 |  || certValidDate | 身份证有效期 | String | 是 | 128 |  || certNation | 身份证民族 | String | 是 | 32 |  || certAddress | 身份证地址 | String | 是 | 1024 |  || email | 客户电子邮件 | String | 否 |  |  || birthDate | 出生日期 | String | 否 |  |  || nationality | 客户国籍 | String | 否 |  |  || certDocumentNo | 证件号 | String | 否 |  |  |
# 任务列表
## 持久层能力
### 任务1：创建user持久层#### 物料引用> Todo_Task_List.md#数据表清单#user#### 任务内容根据物料引用的内容，读取到相关物料内容，并按照app/全流程内容/持久层代码生成提示词.md中的内容生成代码，不要新增内容，也不要省略内容。
## 任务3：实现初审申请往报接口### 物料引用> 包含：> - 接口信息：初审申请往报> - 接口定义：com.xxx.appname.facade.api.user.UserFacade#userCreate> - 请求/响应结构：UserCreateRequest/UserCreateResult> - 内部嵌套模型：UserCertModel> - 执行流程描述：无
### 任务内容根据物料引用的内容，读取app/最新版汇报内容/接口层代码生成提示词.md，将其中接口定义按照要求生成相关全量代码。

这里任务中主要包括两部分：物料引用内容和任务执行描述。其中物料引用内容为执行本次任务需要引用哪些物料区的路径。

3.2门面层代码

门面层内容中主要包括接口定义及实现、出入参数及二级模型的定义。

在当前应用中，变更类型无非定义新接口/修改原内容，然后在接口实现里面facade的实现类，facade实现类内容因为每个接口的实现都是套用服务模版然后调用下游，所以所有接口的门面层的结构差不多，比较模版化。

对于这种每次生成的结果需要保持一定格式的，增加一些输出格式模版或者参考案例，有助于提升结果准确度。尤其对于这种接口定义类的代码生成，效果尤为明显。

下面还是对提示词的具体组成。对于多数提示词而言，角色定义、核心职责、规则以及任务指令是常用内容，代码路径说明是对于代码生成所增加的额外的定制内容，这里重要的点在于代码案例参考，在案例中添加符合规范的代码结构、命名风格等内容，使在生成的源头上就是符合系统风格的代码。

当然，这里提示词虽然说明了优势和痛点解决，只是说在一定程度上能够保证质量和解决一些问题，而不是说100%的能够达到预期效果。大模型丢失内容是比较常见的事情，结果会出现随机性。

3.3持久层代码

外部能力包括DB、下游提供包后的client、msg等其他内容。

主要实现DB操作的代码生成。该部分在本应用结构也比较清晰，从Service到Repo再到Mapper，也比较模版化。其他部分不同应用间差异过大，且过于定制化，暂不考虑生成。

持久层代码代码生成的提示词的思路是与门面层代码生成的提示词相似，组成结构也比较相似。但是不同点在于，我们通过表结构生成了DO类后，是需要基于表结构生成SQL以及Mapper、Repo、Service方法的。包括增删改查以及一些其他新增的方法。这里只做了基础CRUD的方法生成，自定义方法可以参考门面层代码生成。

唯一的区别是在案例中添加了基础的CRUD方法，然后让每次生成代码的时候，都让大模型参考已有案例结构，也生成该表的除了Service、Repo、Mapper以及实现类/xml，还有model、DO及其转换类外的基础CRUD的方法。

3.4业务逻辑代码

根据上面的描述，我将代码分为了三层。因为门面层代码以及持久层相关代码是比较模版化的，让大模型读取提示词然后在根据接口文档/表结构来生成模版化的代码是可行的。重点是如何通过时序图来生成代码？翻阅了一下目前团队内外的系分文档中的时序图，发现质量参差不齐，多数都是使用白话进行描述，少有很严格的规范，这就对业务逻辑生成增加了很大的难度。

参考学习了一些案例，发现很多业务逻辑生成案例中，对于逻辑的描述都是无比详细的，甚至连import什么包都要把全限定类名手写到提示词或者流程图里面。个人觉得不妥，引发了几个思考：

1.AI Coding的使用是为了什么，方便开发同学提效，还是仅仅为了把代码生成出来证明AI可行？每次写代码前写很多详细的定制内容是否降效？

2.过于详细的提示词是否是限制了大模型的能力？

3.是否应该抽象出对于该应用的应用/模块提示词，让其可以拆分系分后，让不同模块的内容使用该模块的提示词，直接生成出代码，而无需每次需求都人工介入专为系分写很多定制提示词或业务流程描述。

针对以上几点，认为应该往以下方向发展：

1.尽量减少AI Coding对原研发流程的侵入，减少系分阶段对AI Coding所需内容的准备时间。

2.部分写提示词会花费很多时间的内容，选择使用大模型能力推理或者人工完成。

3.针对应用架构和系分内容，开发多个提示词。让每个提示词专门针对系分某一块内容来直接生成带有系统规范的代码。

下面针对以上三个方向，针对业务逻辑代码有了以下几个处理方式：

3.4.1流程图增强

为解决AI无法明确要做什么以及不知道代码引用来源、以及减少系分阶段绘制详细流程图的时间，考虑首先对白话版流程图进行翻译增强，将白话文流程图转化成中文伪代码。这种方式可以使流程图中涵盖更多关于应用内代码结构的信息，从而在生成代码是可以直接将中文伪代码转化成JAVA代码，或者能够通过流程描述知道自己要去哪里检索引用的代码。

目前团队内部使用的流程图都是语雀自带的PlantUML语法文本绘图。

随便找了个流程图举个例子，这类使用PlantUML语法的流程图中会包括一些简单的语法包括if-else、loop等，并且也会有‘->’这类调用关系，以及这类调用关系的描述。

以下图片案例为大模型生成：

这里就会发现一个问题：流程图过于白话，大模型很难直接了解如何生成代码，例如：

语义模糊：‘查询用户名’ -- 去哪个表查询？用户名具体是哪个字段？用什么查？AI无法明确知道要做什么，以及来源是哪里。

描述省略：‘模型赋值’-- 很多模型字段多，几十个字段赋值都要写在流程图或者提示词里面？并且精准的说明来源，在实操落地上面来看不现实，人工成本过高，高速迭代的模式下无法实现。

根据流程图将左侧的这些文本，转化成代码能够读懂的中文伪代码，供agent结合提示词来进行代码生成。

对于伪代码生成，主要分为以下几步：

• step 1 ：定位流程起止位置，提取目标流程

根据PlantUML中的语法，对每个“上游指向当前应用为开始，当前应用返回结果给上游为截止”，提取其中流程作为内容的输入。

如果把所有流程的流程图画在一起了需要此步骤进行拆分，如果一个接口一个流程图则无需这个步骤。

• step 2：图形语法解析，转译图形语言

整理匹配规则，将流程图中的PlantUML语法进行匹配，转化为java语法的伪代码，作为代码转化第一步，主要是拆分出if-else、嵌套方法等，完成初步映射。

对于PlantUML的语法转成java语法相对简单，无非alt转if-else，loop转for循环。

• step 3：逻辑步骤解析，生成中文代码

流程图中的每一步的结构都是“调用方 -> 被调用方”， 调用方都是我们开发的当前应用，需要根据被调用方 + 后面的中文描述，来选择生成内容。类似分支/漏斗规则，将中文描述通过描述进行模糊匹配，然后来生成伪代码，所以此处需要设置匹配代码规则。

这一步是整体最重要的一步，因为它决定了最终代码生成的准确性。这里制定匹配规则，来对流程图中的每一步进行规则匹配。匹配到规则的流程，会转化成伪代码，对于没有匹配到规则的流程，则会增加一些帮助引导大模型推理的描述。

这就引发了两个问题：1. 如何制定匹配规则？2. 如何增加引导大模型的描述。

1.如何制定匹配规则？

对于业务流程中的规则匹配，首先需要总结当前应用在业务流程中，会涉及哪些操作（即ava常用语法和外部能力调用），在当前应用中，我总结了大约十几种，包括：网关调用、DB调用、转化类调用、SPI调用、内部组件调用、类内方法调用、日志打印、异常捕获、断言检查、字段定义、模型赋值、基础java语法（if-else、switch）等。并对其中的网关调用、DB调用、日志打印、断言检查、SPI调用、模型组装进行了匹配规则制定。

主要思路是，根据流程图的内容来匹配调用场景，根据不同的场景去代码里面检索相关内容，然后将其中内容经过一次增强后，添加到新流程图中，使得新流程图是包含准确代码引用的伪代码。

2.如何增加引导大模型的描述

对于一些无法描述清晰的内容，例如‘模型组装’、‘字段赋值’，都需要给大模型一个明确的步骤，使其能够按照步骤来推理，保证方向正确。

• step 4 ：整合全部内容，形成完整流程

补充任务所需其他内容，包括任务模版中需要体现的代码修改的位置、路径、具体方法等。形成一个可以执行由大模型执行来生成代码的任务内容。

例子：DB操作流程图转化提示词

DB调用流程转化案例

# 3.2.2 开始解析引用关系，检索所有结构为‘userApp->>xxx'以及‘xxx-->>userApp‘的流程，根据xxx的值，进行分析。## 2. **DB调用**### 2.1 生成要求    当流程中出现‘userApp->>DB: xxxx’流程，代表此处进行了userApp对于DB的某张表的增删改查操作，你需要按照以下步骤进行分析组装伪代码。（1）在转换DB调用时：  - **强制**使用实际存在的Service接口文件  - **强制**使用文件中实际存在的方法名  - **禁止**使用推测或翻译的方法名（2）强制验证转化结果，转换完成后，必须：  - 验证所有提及的类名是否存在于工程目录  - 验证所有方法名是否存在于对应的Service接口中  - 如发现不匹配，必须在输出中明确标注"未找到准确匹配，使用了最接近的方法：xxx"   ### 2.2 转化流程   案例分析如下，可按照案例分析来匹配到的流程。   （1）将‘xxx'中的描述，翻译成英文，然后读取工程目录下com.xxx.userapp.module.core.domainservice中的所以java文件，根据英文描述匹配看是否有匹配文件。   （2）如果有匹配项，再根据‘xxx’中的描述，翻译成中文，然后根据描述进行分词，解析出业务属性、操作类型、入参数。   （3）根据业务属性翻译为英文，并检索语义匹配的服务，并选中其文件。   （4）然后根据中涉及的参数以及想要执行的动作（新增/插入/查询/删除/更新）来模糊匹配是否存在可以直接使用的方法。   （5）如果有可以直接使用的方法，则参考输出模版以下案例，将其构造成含有伪代码的描述。    输出模版：    ‘userApp->>DB: 使用@Autowired注入{匹配到的服务名称}的bean，然后调用{匹配到的服务}下的{匹配到方法名称}方法，如参数可以从方法上下文中找到，出参数为以方法的返回结果类型构造的一个新对象‘。   ### 2.3 转化案例      以一个简单描述来举例，如果文本描述为‘userApp->>DB: 根据用户id，查询用户信息’。   （1）流程描述分词为->根据/用户id/查询/用户信息。   （2）其中’用户id‘，表示为调用DB服务的入参数；‘查询’表示操作类型；‘用户’代表业务属性。   （3）首先根据业务属性，翻译为User/UserInfo等服务名称。   （4）在com.xxx.userapp.module.core.domainservice下匹配到了UserService。   （5）操作类型为查询，所以要匹配domainservice下匹配到了UserService中的query或者select为前缀的方法。   （6）“根据用户id”，代表查询条件为用户id，翻译为userId。   （7）根据（5）和（6）匹配到了UserService下的queryByUserId方法。   （8）将‘userApp->>DB: 根据用户id，查询用户信息’，转化为‘userApp->>DB: 使用@Autowired注入UserService的bean，然后调用UserService下的queryByUserId方法，如参数可以从方法上下文中找到，出参数为以方法的返回结果类型构造的一个新对象‘。

根据以上方法，能够将“userApp->>DB: 根据用户id，查询用户信息“，转化为：”userApp->DB: 使用@Autowired注入UserService的bean，然后调用UserService下的queryByUserId方法，如参数可以从方法上下文中找到，出参数为以方法的返回结果类型构造的一个新对象“。使得大模型生成代码跟具有依据，也更加准确。

例子：模型组装流程图转化提示词

模型组装

## 6. **模型组装**

### 6.1 生成要求   如果出现：‘userApp->>userApp: 组装/构造xxx模型，并赋值‘ 这类进行模型组装操作时，按照以下流程进行转化增强
### 6.2 输出结果案例   按照以下流程进行内容映射  （1）将‘xxx'中的描述，翻译成英文，然后读取工程目录下com.xxx.userapp.module.core.model中的所以java文件，根据英文描述匹配看是否有匹配文件。  （2）如果有匹配项，则获取被匹配项的全限定类名，例如：‘com.xxx.userapp.module.core.model.domain.UserCreateModel’  （3）按照以下格式构造最终结果：‘userApp->userApp: 组装/构造xxx模型，根据被匹配项的全限定类名{被匹配项全限定类名}，使用import 导入包。然后根据全限定类名读取此模型中所有字段，定义对象，最后通过代码生成规则和推理增强结合此模型中的字段，结合上下文中出现的其他模型及字段内容，进行模型字段赋值。

3.4.2推理引导

业务逻辑主要包含了java基础语法和外部能力的串联，定制化高，是最难攻克的一块，不过在流程图阶段，已经为生成结果的准确度已经做了一层提升，这里只需要做一些约束和推理引导，让最终结果变更更加准确。

对于部分业务逻辑，例如外部能力方法调用、定义一个某某对象，以及一些基础java语法（if-else、for循环）是通过流程图语法或者人为描述直白的了解其含义，并且流程步骤与代码有着一一映射关系。但是对于参数传递、参数赋值，很难逐字逐句的绘制在流程图中。考虑不为流程图绘制增加负担，以及考虑更好的使用大模型的能力，打算使用大模型的推理能力来生成流程图中的一些‘难以明确说明的步骤’。

当然，大模型进行代码生成时应该也有一些预制的代码推理能力，常用AI生成代码的同学应该遇到过因为约束过少或者流程描述不清的场景，会出现大模型生成很多乱七八糟的预期外的内容。为了防止它推理的不对、多了或者少了，所以我们要对其推理进行约束和限制，以及使用提示词进行推理方向的引导。在将流程图转化成伪代码后，一定会存在部分流程无法转化，例如含糊的表达了‘模型组装’以及‘字段赋值’，所以打算在一些无法通过白话简单精准的描述出来的步骤，让大模型去推理。

个人理解这种方式类似于一个小型RAG模式？

这里思路上比较抽象，以参数组装为例，如果我们组装一个结果对象作为当前方法的返回，这个结果对象的每个参数值都是由这个方法里面的一些外部能力调用的结果，所以这时就需要引导它执行以下步骤：

• 首先定义结果对象，对结果对象中的所有字段进行赋值列举。

• 阅读当前生成的所有代码，对调用下游获得的结果模型进行逐一读取。

• 将结果模型的所有字段对下游结果模型中的字段进行命名匹配，获取字段赋值来源。

• 对于无法获取来源的字段/类型类别字段/状态类型字段，检索当前工程的枚举/常量，根据命名匹配是否有可使用枚举/常量。

• 对于最后还是无法获取到来源的字段，检索整个文件的内容，看是否有类似字段/其他字段的赋值方式学习，最后进行赋值。

• 对于最后还找不到赋值的进行标注，最后人工添加。

这套流程看似只是一个流水似的引导描述，但是其实对于参数组装赋值这类操作，如果不约束不引导的话，它每次生成的结果都不一样，随机性很大。并且对于一些字段还可能出现“对不存在的字段赋值”，“对存在的字段赋不存在的值”。对我来讲大模型的生码的底层逻辑过于黑盒，仅凭不加引导和约束的推理，无法保证准确定。所以使用此类方法，整理业务逻辑中包含的场景，并为其制定推理思路，最后生成代码。

3.4.3以模块维度拆分提示词

这部分就是将不同的模块采用不同的提示词，来让每个地方的提示词更加聚焦。

这个是整体思路，不过多赘述。

3.4.4业务逻辑生成整体思路

​​​​​​​​​​​​​​THE END !

文章结束，感谢阅读。您的点赞，收藏，评论是我继续更新的动力。大家有推荐的公众号可以评论区留言，共同学习，一起进步。