我还没见过这个问题导致麻烦，但我觉得最好还是清理一下：
你将获得一段文本，你的任务是检测该文本的语言（区域设置），并以特定的 JSON 格式返回。
…
你的回复必须是一个语言代码，且不能包含其他任何内容。请勿在回复中添加引号或其他任何字符。
1 个赞
我在我尝试过的特定模型中确认了这一点；它并非总是失败，但在处理特定文本时确实会出现问题。
我会尝试你的调整方案。感谢分享！
1 个赞
我发现它容易把非语言类的地区设置搞混。举个例子，我说西班牙语，住在墨西哥城（墨西哥），使用墨西哥比索（Mex$），并且习惯用逗号作为小数点分隔符。
我们现在正在试用类似这样的提示词：
你将收到一段文本，你的任务是确定其语言。
要完成此任务，请遵循以下步骤：
1. 仔细阅读并分析提供的文本。
2. 根据文本的特征（如词汇、语法和句子结构）确定其语言。
3. 不要使用文本中的链接或编程代码来检测地区设置。
4. 识别所检测语言对应的语言代码。
以下是一些常用语言代码供参考：
- 英语：en
- 西班牙语：es
- 法语：fr
- 德语：de
- 意大利语：it
- 巴西葡萄牙语：pt-BR
- 俄语：ru
- 简体中文：zh-CN
- 日语：ja
- 韩语：ko
如果语言不在上述列表中，请使用相应的 IETF 语言标签代码。
5. 避免使用 `und`，并优先使用 `en` 而非地区变体 `en-US` 或 `en-GB`。
重要提示：仅基于提供的文本进行分析。不要使用任何外部信息，也不要对文本的来源或背景做出假设。不要被地名或语言名称所迷惑；这里关注的是文本本身的语言，而不是文本所谈论的内容。
你的回复必须是一个语言代码，且不能包含其他内容。不要用引号或其他字符包裹你的回复。
关于最后一行的背景信息，请参见这里。其目的是避免 LLM 在响应中使用它在指令中发现的引号或反引号。
之前发生的情况是，一些 LLM 对此理解得过于字面化：
5. 避免使用 `und`，除非文本明确指示地区变体，否则优先使用 `en` 而非 `en-US` 或 `en-GB`。
两个示例场景：
输入："Can you tell me what '私の世界で一番好きな食べ物はちらし丼です' means?"
输出："en"
并返回了
"en"
或
`en`
而不是
en
1 个赞
是的，我理解最后一句。与它矛盾的是第一句：
以特定的 JSON 格式返回它。
我还怀疑，你在谈论“地区”和“位置”时，对 locale（语言区域）和 region（地区）的强调可能会引起混淆。