咱们把板凳搬过来，让ChatGPT试试在Fluent里面写UDF，专门给机器人准备了个“送分题”，就是让入口速度随y坐标线性变化，公式就是v等于2y加3。先把场景搭好，板凳、ChatGPT还有Fluent UDF手册都摆上，就把需求发过去。 结果ChatGPT秒回了一段代码，看起来挺“专业”的，可仔细一看问题还真不少。第一个宏用对了，细节全错了。清单上摆着：F_CENTROID宏本来只有两个参数，结果写成了三个；获取y坐标的方式完全不对，导致编译直接报错。人工第一步：删掉那个多余的参数，再把y数组的索引从1改成0。因为数组是从0开始的嘛。 第二次输出：数组索引算是对了，可宏还是用错了。修正之后：加了个real x[ND_ND]，这ND_ND是坐标维度数，会自动替换成2或3维。但问题又出来了：F_CENTROID的用法还是错误的，应该把结果存回x数组里，而不是直接读取；坐标数组x在宏里被当成普通变量用了。 第三次输出：终于能编译了。这次修正后：DEFINE_PROFILE这个函数定义没有错了；用F_CENTROID(x[0], x[1], x[2], f, t)把坐标存回数组里了；y取x[1]；速度公式也没错了；最后把速度写回边界profile数组里。 现在这段代码能在Fluent里干净编译并运行了。入口速度按v等于2y加3线性分布出来了。不过全程得搞三次修正才行。要没有专业背景的人来判断这些错误，确实挺难的。 总结一下：这事儿挺好玩的，但远没到解放生产力的地步。 UDF涉及到Fluent内部的宏、坐标系统、边界循环这些细节专业人士都得仔细看才能找出错在哪。同一轮对话里ChatGPT能持续“学习”，退出后新开会话又得从头开始。整段代码没有注释也挺麻烦的。国内用户被限流了数据贡献微乎其微所以其实它也算不上什么武器。 我倒是觉得可以把它当成免费算力和持续学习的工具来用。希望国内团队赶紧推出本土化的UDF助手吧，让专业人士少写那些重复的脚手架代码，把时间精力都花在物理模型创新上才好。