本文参与神灯创作者计划http://sd.jd.com/article/44990 - 前沿技术探索与应用赛道

1.存在的问题

1.研发产品新人上手难：系统存在知识壁垒，需求背景知识不了解，上线容易出问题，有些壁垒知识只能靠口述,效率极低，上线游链路不了解

2.资料散乱:各处资料散乱，虽然可能已经沉淀，但随着人员迭代，可能逐步丢失，造成公司重要资产损失

3.运维时间长:面向运维和研发需要日常答疑的时间长，占据开发的核心工作时间

4.研发新人对于历次变更不熟悉，或者系统交接存在风险

5.测试新人对于历次变更看不懂代码无法把控风险

6.产品对于之前的逻辑不熟悉，对于刚接手的系统不了解

8.大模型是否能够学会历次的需求变更?

9.大模型是否能够写出业务代码

2.解题思路

基于以上问题，从产研角度思考了对于产研角度对于大模型的日常应用的三个阶段并进行了实战

1.日常简单使用大模型，此处不再赘述，属于通识

2.大模型结合系统相关的知识库，用于解决日常运维以及产研变更或产研新人对于系统不熟悉的问题

3.大模型结合系统相关的知识库和代码，用于了解历史代码变更点，新需求依据TRD生成代码

3.结果

阶段1-成果

略-大模型使用通识

阶段2-成果

1.沉淀了适合于大模型基于系统纬度的最佳语料库模版，大模型会变，工具会变，沉淀的文章是核心资产

2.提问时可给出具体文档位置，确定来源，快速获得结果

3.通过制作一个系统维度的大模型，可以推动研发产品整理所有的文档沉淀

4.能够结合大模型能力给出衍生答案和具体例子

阶段3-成果

1.能够给出该代码库的历史变更检索

2.对于新人产品来说，能够给出该系统的所有变更需求的分析和总结

3.对于新人研发来说能够依据TRD写代码，修改即用

4.对于新人研发来说能够询问大模型获取类似需求的改动思路和改动点

4.大模型应用STAGE-1

此阶段不赘述，作为一个基本常识,能够运用基本的提示词对大模型提问一些常见的工作问题

5.大模型应用STAGE-2

5.1架构图

5.2 实践案例-DMS技术专家实践

5.2.1推荐语料库

示例文档添加 扩充文档作用 细化 给出具体范例

1.【必备】经典的需求TRD、ERD整理

ERD文档： 系统文档的梳理可以有助于模型快速熟悉系统，并且可以解释业务方面的知识

TRD文档： 模型可以结合TRD文档，可以从技术角度提出专业意见，并且对系统/技术知识进行解答

系统梳理文档： 可以从数据库设计/系统设计/系统业务功能分享等角度，对系统文档进行补充

1.【推荐】研发注意事项/常见问题:

技术专家可以结合常见问题的文档，给出专业的解释，并且结合历史案例，预防事故的发生。

例如：

（1）历史出现的白虎线上问题，避免线上问题的再次发生

（2）研发/产品整理的Q/A文档，协助产研快速定位并且解决问题

1.【必备】DMS系统PRD/DMS需求集

通过PRD文档，可以帮助模型理解业务，并且结合具体需求，对需求的特定问题进行解答

1.【必备】系统常见的坑合集

通过常见系统问题，例如上线前需要预热，redis共用一套风险，某些MQ流量大消费可能时常积压，

5.2.2推荐提示词(可迭代)

【实践】1.问题解答：为产品经理提供准确的信息和解答，处理他们关于门店工单或系统功能的问题，同时解决研发新人或非本系统研发人员的疑问。

2.方案指引：当研发人员对系统有疑问时，从系统层面详细解释问题，并提供解决方案。当产品团队需要业务知识支持时，协助他们进行解释，并为门店反馈的工单提供可行的解决方案。

3.系统的详细介绍：针对任何人提出的系统设计问题，结合ERD、TRD等文档，详细解释数据库设计、系统设计或业务流程设计，并通过可能的使用场景进行说明。

4.注意事项：在研发提出注意事项或建议时，结合研发注意事项中的问题和案例，以及历史真实问题，提供建议。当产品团队对某一场景有疑问时，结合常见问题和运营手册中的相关问题，给予专业回答。

5.2.3范例

6.大模型应用STAGE-3

6.1架构图

实现具体方案:通过将历史需求切割，让大模型学会针对于业务系统每一个需求是如何做的，就像我们当初初入职场时，mentor如何带领我们逐步做一个需求，另外对大模型补充业务知识，让其真正成为一个熟悉业务，并且会写代码的Agent，使用模型训练时，使用京东内部自研的言犀大模型,能够保障代码安全，和召回准确度

6.2实践案例

6.2.1历史变动检索

现在想要结合<交易历史需求变更>知识库 拼拼融合华冠改了什么 给出改动代码

6.2.2历史变更分析

现在想要结合<交易历史需求变更>知识库 总结拼拼融合华冠改动点 我是产品 看不懂代码 给出

6.2.2依据TRD写代码

类的全路径com.jd.xstore.settlement.center.biz.service.CommonSettlementFacadeSaasImpl#calculateTotalPrice

改造点PRD：

1）支持POS传入是否使用京豆，

2）查询积理会员系统获取京豆总数量和本单抵扣数量、转变比例，

3）根据京豆总数量和本单抵扣数量、转变比例，计算可抵扣金额，京豆总余（不使用也返回）

4）进行各资产试算

5）结果返回京豆可抵扣金额，本次抵扣数量，京豆总刷量、京豆总余额（不使用也返回）。

6.2.3做过的类似的需求设计

新增加一种SendPayParam 需要改动哪些 类型需求支持

7.未来优化点

1.比较依赖需求变动的coding库，如果新增需求较少，写出来的代码可能比较薄弱

2.强依赖与新增知识库和代码库的召回能力，依赖于合并记录和需求的绑定关系，如果未来对此进行强要求可以提升代码准确率