1python之小程序回复消息问题处理
- 2026-03-20 16:18:50
写在前面的话
未来可期。昨天是周日，一周工作六天，周日在家陪陪老婆孩子。我昨天故意啥也没搞，决定放空一下，上一周神经太紧张了，主要是做好抖哥项目的同时，搞点头条号运营，一堆事，软件各种问题，最后能发了，平台各种限制，播放量为0，搞的身心疲惫，一直到昨天晚上，想通了，当个事干就行，比刷视频娱乐强，这是一条出路，走好了补贴下生活，走不好，生活也能继续，不要抱太高希望，但既然有这个想法，就细水长流的搞，万一成了呢。成功从来不是一蹴而就的，需要经过各种艰难险阻，如果不想费这个脑子，出大力就行了呗，送外卖，跑快递，不需要绞尽脑汁想办法，但又累又脏，还挣不到钱。所以，什么事都是相辅相成的，平常心看待就好，加油！
[291]-------底部有张生活照片
【关键词】python、小程序、ragflow、回复消息
一、ragflow小程序相关（一级）
1.回复消息有问题（二级）
描述：现在小程序接口，回复消息，格式有问题，看下原因。
开工：
第一步：查原因（三级）
20250124周五时间段：09:33-09:40
20250124周五时间段：09:40-10:00
先看下意图识别，看有没有问题，通过打断点，知道了api/completion2有问题，处理一下。
先在ragflow上跑下测试用例，如下：
图1a-1
注：这个直接取就行，因为获取方式改了。再跑一下。还有就是这个函数的传参改了，也要优化一下。
修改代码如下：
图1a-2
注：这样改一下就可以了。接下来，代码合并到测试上。
第二步：测试（三级）
测试还可以
2.代码合并到测试上（二级）
描述：需要把ragflow及chat_sev的代码合并到test分支上，以后，先在测试上开发，没问题，再发布到master分支上。
开工：
第一步：合并ragflow(三级)
20250124周五时间段：11:27-11:40在云效上搞一下，完成，测试还可以。
第二步：合并chat_sev到测试分支（三级）
20250124周五时间段：11:37-11:40这个先不建测试分支，用到了再说。
3.ragflow基本情况问询优化（二级）
描述：现在用户提问一个问题，大模型应该问基本情况，而不是直接给出答案。
开工：
第一步：提示词（三级）
20250124周五时间段：11:44-12:40
20250124周五时间段：12:14-12:20
20250124周五时间段：14:46-15:00
应该优化下提示词，先测下multi_chat方法，用测试用例搞一下。看能不能优化一下提示词，使基本情况没问完之前，不输出答案。
修改如下：
图1a-3
注：跑下试试，看看效果。
第二步：基础问询（三级）
20250125周六时间段：00:53-01:00跑一下，看看效果，效果如下：
图1a-4
注：这个回答有点傻，不能把基础问题已问完给出来，应该根据历史聊天，把用户已回答的过滤掉。接下来，修改两方面，一是提示词，二是例子。
先修改例子。
a.修改例子（四级）
20250125周六时间段：00:53-01:00修改例子如下：
图1a-5
注：这样才是正常的，接下来，修改下提示词。
b.修改提示词（四级）
20250125周六时间段：01:12-01:20
20250127周一时间段：00:58-01:00
修改下提示词，免得它傻傻的回答，修改如下：
图1a-6
注：这样修改之后，再次提问试试看，看效果会不会发生变化。
这个需要改变一下，就是要把流式输出，改为非流式的，因为要判断是不是问完，再决定发送不发送给前端。所以，先修改下代码，修改如下：
图1a-7
注：运行一下，看看效果，理论上应该是两次。
c.非流式传输（四级）
20250127周一时间段：01:27-01:40运行结果，如下图所示，截图如下：
图1a-8
注：看效果，非流式传输没起作用，排查下原因。刚才搞错了，测试在线上测的，造成了误解，现在明确，确实是一次输出的，所以，加个判断，如果基础问题已问完，直接让专家进行诊断给意见。
d.跳转专家诊断(四级)
20250127周一时间段：01:50-02:00
20250127周一时间段：02:07-02:20
就是没问完基础问题，继续问，问完，就跳转专家诊断，修改下代码，如下：
def common_request(conversation_id:str,dia,messages:list,question:str,req:list):
'''
通用回答：没办法识别意图，分科的回答和通用回答都返回
'''
try:
res_res_chat = chat_no_increase(dia, messages, True, **req)
for ans in res_res_chat:
all_answer = ans
# log.info(f"doctor_specialist_request---all_answer: {all_answer}")
log.info(f"doctor_specialist_request---ans: {ans}")
yield "data:" + json.dumps({"retcode": 0, "retmsg": "", "data": ans},
ensure_ascii=False) + "\n\n"
except Exception as e:
# #log.debug(f"error {e}")
log.error(f"An error occurred: {traceback.format_exc()}")
yield "data:" + json.dumps({"retcode": 500, "retmsg": str(e),
"data": {"answer": "**ERROR_completion**: " + str(traceback.format_exc()), "reference": []}},
ensure_ascii=False) + "\n\n"
yield "data:" + json.dumps({"retcode": 666, "retmsg": "", "data": True}, ensure_ascii=False) + "\n\n"
messages[-1]['content'] = question
messages.append({"id":get_uuid() ,"role": "assistant", "content": all_answer['answer']})
ConversationService.update_by_id(conversation_id, {"message":messages})
注：写一个通用回答方法，避免代码重复，里面是用流式返回的，并且可以更改提示词。调用截图如下：
图1a-9
注：接下来，运行一下，看看效果。测试效果如下：
图1a-10
注：这个不对，因为这个是新会话，上来就没问基本问题，直接给答案。研究一下，错在哪里了。
e.直接给答案（四级）
20250127周一时间段：02:41-03:00
20250127周一时间段：03:15-03:20
这个有问题啊，为啥直接给答案，哪个地方判断不对，研究一下，看看问题出现在哪个地方。
研究了一下，发现少写一行，截图如下：
图1a-11
注：这个组装的问题没替换，所以，没有达到预期的效果。改了，再跑一遍，看看效果，效果截图如下：
图1a-12
注：这样就可以了，能给出问题，接下来，看下问题问完之后，会不会给出专家诊断。
f.专家诊断及问完标识（四级）
20250127周一时间段：03:32-03:40
20250127周一时间段：03:44-04:00
上线看一下吧，本地卡死了，是不是本地服务器不行，卡住了呢。代码上线，上线之后，效果是一样的，需要排查一下。
二、生活照片
拍摄于2025年7月8日，22:53:45，给大宝在房子门口拍的，当时大宝七岁七个月。我想了一下，我肯定有我的优势，学历是研究生，并且做了十年后端编程，对网上软件拆解，最起码比送外卖的没接触过编程的好多了吧。但缺点也很明显，就是像陈咬金一样，耐不住性子，卡卡三板斧下去，不出结果就不想搞了，粗枝大叶，不注重细节。相比之下，朋友老公就好多了，人家做了十几年大厂测试工程师，性格比较细腻，昨天和他交流，他能冷静的和我分析，为什么平台限流，怎么规避，我觉得很专业，分析的很好，让我受益良多。多交流是有帮助的，我把我拆解的软件源码发给他了，他也给我指出需要再优化哪些点，我觉得挺好的，现在是一个合作共赢的社会，小范围抱团研究能大幅度减少试错时间，未来还是很光明的，加油！
图1c-1
《本文完》
