chatgpt测试

我让ChatGPT写一段Python脚本，用来批量重命名下载文件夹里那些乱码文件名。它给了我一段带os.rename的代码，逻辑清晰，还贴心地加了异常处理。但有个问题——我文件夹里混着中文、日文和韩文文件名，它默认用utf-8编码处理，结果日文假名直接变成了问号。

这不是它第一次在编码问题上翻车。上次让它解析一个CSV文件，它写了pd.read_csv('data.csv')，没指定encoding参数。我本地文件是GBK编码的，跑起来直接报UnicodeDecodeError。它倒是很礼貌地道歉，然后补了一句“建议您使用UTF-8编码保存文件”。废话，我当然知道UTF-8好，可数据是别人给的，我能怎么办。

但你不能说它笨。我换个方式问：“如果文件编码不确定，怎么自动检测？”它立刻给出了chardet库的方案，还提醒我chardet.detect()对短文本准确率不高，建议配合try-except做多编码回退。这个回答有实战经验的味道，不是从教科书里抄的。

真正让我意外的是上周的测试。我故意给它一段有逻辑漏洞的代码——一个递归函数，没有终止条件。它读完说：“这个函数在输入为负数时会无限递归。”我愣了一下，因为我构造的测试用例里，负数确实会触发无限循环，但正常输入是正整数。它没被“正常输入”带偏，直接点出了边界问题。这比很多初级程序员强。

不过别高兴太早。同一个递归函数，我换了个问法：“这段代码有什么潜在风险？”它回答：“可能导致栈溢出。”——就这一句，没有具体场景，没有修复建议。换个问法，输出质量天差地别。

我做过一个粗糙的对比测试。同样问“Python怎么合并两个字典”，中文提问它给{ **d1, **d2}和d1.update(d2)，顺带提了Python 3.9的|操作符。英文提问，它多给了一个collections.ChainMap的方案，还对比了内存和性能差异。同一个模型，不同语言，知识密度不一样。这算不算一种语言偏见？我觉得算。

还有一次我让它解释GIL。它说“全局解释器锁让同一时刻只有一个线程执行Python字节码”。没错。但我追问“那为什么numpy能多线程加速”，它开始含糊其辞，说“因为numpy释放了GIL”。我再问“具体在哪些操作释放”，它给了几个例子但不够全。我查了CPython源码，发现numpy在ufunc计算和部分线性代数操作里释放GIL，但并非所有。ChatGPT的回答方向对，细节经不起深挖。

这让我想起一个做安全的朋友。他用ChatGPT生成了一段SQL注入的测试载荷，拿去测自己的WAF。ChatGPT给了' OR '1'='1这种经典款。朋友说：“这玩意儿连脚本小子都骗不过。”他换了个问法：“生成一段能绕过mod_security规则942100的SQL注入载荷。”ChatGPT拒绝了，说“我不能协助攻击行为”。朋友笑了：“它知道规则编号，但选择不回答。”

所以ChatGPT的测试结论是什么？它像一个知识面极广但缺乏实战经验的实习生。你问它概念，它答得漂亮；你让它处理真实世界的脏数据、边界条件、性能陷阱，它经常掉链子。它的回答质量高度依赖你的提问方式——你给它的上下文越具体，它越靠谱；你问得笼统，它就给你一堆正确的废话。

我现在的用法很简单：把它当高级搜索引擎加代码补全。它给的代码，我逐行读，改编码、加边界检查、替换掉那些“理论上正确”但实际跑不通的部分。它节省了我查文档的时间，但没节省我思考的时间。这大概就是现阶段最诚实的评价——好用，但别全信。