当前位置:首页>python>python项目教学——deepseek-plus(3):疯狂处理报错和bug的一天

python项目教学——deepseek-plus(3):疯狂处理报错和bug的一天

  • 2026-10-11 06:55:29
python项目教学——deepseek-plus(3):疯狂处理报错和bug的一天
很抱歉昨天没有写文章,昨天专心写代码。把set_settings这些函数重写了一下,然后新增了一个Conversation类,负责所有和对话相关的部分。但有了Conversation类后,整个项目就可以运行了。然后我开始编写测试样例,然后大面积的崩溃报错……大部分的报错都发生在set_settings,Conversation。要是当时写完后顺便写几个测试样例就好了
今天啥也不干,专注修bug和加测试样例。这篇文章也不会有多少源代码,不过大家放心,这个软件做完或我做不下去的时候,一定会全部开源的。这篇文章会非常无聊,因为全都是修bug日志,不断处理报错和bug,但如果你想了解程序员debug的一天,这篇文章可能会让你理解深一点
修bug日志:
1,test_1 
没通过,34行的assert错了。set_settings分支1的逻辑有问题
实际在用api_call函数时,也遇到了这么个问题
  File "C:\Users\HP\Desktop\mqc\九年级\Python\deepseek\conversation.py", line 59, in __api_call    result = api_call(msgs,             ^^^^^^^^^^^^^^  File "C:\Users\HP\Desktop\mqc\九年级\Python\deepseek\main.py", line 37, in api_call    response = CLIENT.chat.completions.create(               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...  File "C:\Users\HP\AppData\Local\Programs\Python\Python312\Lib\site-packages\openai\_base_client.py", line 1148, in request    raise self._make_status_error_from_response(err.response) from Noneopenai.BadRequestError: Error code: 400 - {'error': {'message': 'Failed to deserialize the JSON body into the target type: temperature: invalid type: string "1.2", expected f32 at line 1 column 165', 'type': 'invalid_request_error', 'param': None, 'code': 'invalid_request_error'}}
根据报错,这个json怎么解析出一个字符串呢……
手动打开json文件查看,发现json文件也有问题,json文件内部存储所有东西都使用字符串存储的。行吧,前面欠的债现在还
我的打算是重写写入逻辑。因为我明确会写入json的代码只有set_settings
要写入的“特殊”数据类型一共就三种,布尔,小数,整数,暴力枚举就行了
好的,程序正常运行。下个样例
接下来test2,来了个诡异的错误
为啥说他诡异?因为目录下就有这个文件
我是用os.startfile来打开的,来上网搜搜这个函数
他是支持相对路径的啊?那没办法了,删掉原有的文件,然后开pdb,在打开文件的前一行进入调试模式。在调试模式看看能不能找到线索吧
额……删了文件后直接进入创建配置模式了。不管了,先测测创建配置有没有问题吧
我恨gbk编码
还好这次的报错很明确,就是编码问题。而且看起来是test文件内部的问题,那这就没大事,重新测一次就行了
OK,创建配置的问题到不大。然后把这次生成的配置删掉,换一个标准配置,然后重新测试
最终,我发现这个东西支持相对路径
但没有任何跨平台的兼容性。我传正斜杠,它给windowsAPI还真传正斜杠。。。open函数就支持正斜杠windows上自动转换反斜杠,怎么到这里就不支持了?
行,这么个难以言说的bug就结束了,解决办法简单到要命:
能正常打开文件了现在,但是断言又出错了
没办法,继续breakpoint调试。这次在出错的断言前面设置断点
modified_config是我们的预期,发现result(即set_settings的返回值)和预期不一致。发生在temperature的类型。
来,看源代码
回看一两天前自己写的逻辑想骂人。101行的if分支无论如何都会触发128行的return,导致无法触发询问是否打开配置文件检查的对话。
然后158行只应该发生在else分支里面,因为只有else分支里面有old_settings,但由于前面的if分支自己有返回语句,所以放在else分支外面竟然没出问题
碰到这种问题,还能说什么好啊。重构
把dump_to_json函数改为会返回正确的字典
然后重写这两段逻辑,让返回值的命名都变成config_data,合用一个return
接下来的TODO:
1,重新测试test1,防止引入新bug
2,测试创建配置时是否能打开文件检查
现在先不做,先再跑一遍test2
test2通过
重新测试test1
???pdb里不是还能跑吗?
最后面的那个char 0哦懂了。pdb里的json.load操作把文件读写光标移到末尾去了……删掉调试器就行了
test1通过
接下来测试创建配置时是否能打开文件检查
可以打开,test3一遍过
test4里忘加as f了……再次自己吓自己。都做好test1~3再次重试的准备了
过!爽!
接下来就开始(小规模)用户测试了。我将亲自创建一个对话test,自己来多次和deepseek聊天,体验指令,同时测试bug。现在是十二点十分,先吃午饭去了,再见
好的,又回来了
发现第一个bug:已有配置但不加载
面对这种难以定位的bug,我选择直接在chat_loop顶部加一个breakpoint()
我代码逻辑没问题啊?怎么回事?
哦,原来对话的前面多加了个空格。。。怪不得识别不到。
解决
继续测试。。。
最后一张截图里,含有两个问题
第一个,输入cmd://change之后,即使选择未保存,需要取消,也会输出“已经修改完成了”,令人心头一紧(虽然并没有抹掉聊天记录)
第二个,又来了,斜杠的问题
逐个修复
好了,重新运行,再测试
又来了,编码问题。我恨gbk*2
改好了,继续测
发现bug :load指令无效。开始修
原来就是忘加case "load":self.load()了……实际的处理方法都写完了。继续测
又来bug了,在copy的时候,配置文件名处理不正常
少加了个f,无语了
好了,继续测试。这次测试没发现什么bug,也就意味着,我们今天的改bug文章,终于要结束啦!
(不过这次的测试挺好玩的,大家看看。下面的例子生动形象说明了手动改对话能达到的戏剧性)
我们的程序潜力无限啊瞒天过海骗AI

最新文章

随机文章