欧式中文翻译腔的简单速查脚本

0-shuorenhua.md

两个版本：

• shuorenhua-llm.py 需要与 OpenAI API 兼容的 LLM 服务商
• shuorenhua.py 是非常简单的基于规则的脚本

以下的例子来自 https://github.com/ustclug/website/blob/209165ac073b905834f5a2740e7c49b179e3be5f/pages/_wiki/doc/howtoask.md?plain=1。

shuorenhua-llm.py

#!/usr/bin/env python3
# 从 LLM 生成脚本修改。
"""
本脚本用于分析一个包含中文文章内容的文件，
对每句话使用大语言模型（OpenAI API）检查是否存在欧式中文翻译腔问题，
如句子冗长、连接词堆砌、被动语态频繁等。要求大语言模型：
  - 如果句子没有问题，则不要回复任何内容；
  - 如果句子存在问题，则输出存在的问题及一句修改建议。
只有模型判断需要修正的句子会显示判断理由和建议。

请确保环境变量 OPENAI_API_KEY 已设置，且已安装 openai、mistune 等依赖库。
"""

import re
import sys
import time
import os
import mistune
import mistune.renderers
import mistune.renderers.markdown
import openai
from pathlib import Path
from tqdm import tqdm

# Siliconflow DeepSeek-V3 设置
BASE_URL = "https://api.siliconflow.com/v1"
MODEL = "Pro/deepseek-ai/DeepSeek-V3"

try:
    key = Path("key").read_text().strip()
except FileNotFoundError:
    key = os.getenv("OPENAI_API_KEY")

if not key:
    print("错误：未找到 key 文件，在环境变量中也未找到 OPENAI_API_KEY。")
    sys.exit(1)

openai_handle = openai.OpenAI(api_key=key, base_url=BASE_URL)


# 自定义渲染器，重写代码块渲染方法，使其返回空字符串（移除 Markdown 中的代码块）
class NoCodeRenderer(mistune.renderers.markdown.MarkdownRenderer):
    def block_code(self, code, info=None):
        return ""


def remove_markdown_code_blocks(markdown_text):
    """
    使用 mistune 库解析 Markdown 文本并移除其中的代码块。
    """
    markdown = mistune.create_markdown(renderer=NoCodeRenderer())
    return markdown(markdown_text)


def remove_markdown_links(text):
    """
    去掉 Markdown 格式的链接，仅保留链接文本。
    """
    pattern = r"\[([^\]]+)\]\([^)]+\)"
    return re.sub(pattern, r"\1", text)


def shorten_urls_in_text(text):
    """
    将文本中所有 URL 替换为统一的短链接，便于后续判断。
    """
    url_pattern = re.compile(r"https?://[^\s\)]+")
    return url_pattern.sub("https://example.com", text)


def judge_sentence(sentence):
    """
    使用 OpenAI ChatCompletion 接口对句子进行检查，判断是否存在欧式中文翻译腔问题。

    prompt 设计说明：
      - 系统角色：你是一位资深中文编辑和语言专家，专门关注中文句子的自然表达。
        请检查下面的句子是否存在“欧式中文翻译腔”现象（如句子冗长、逗号堆砌、被动语态频繁、连接词滥用等）。
        如果句子表达符合中文习惯，则请不要回复任何内容。
        如果存在问题，请先列出存在的主要问题（理由），然后给出一句修改建议，使句子更符合中文表达习惯。
        回复要求内容精炼、格式清楚。
      - 用户角色：提供待检查的句子。
    """
    system_msg = (
        "你是一位资深中文编辑和语言专家，专门关注中文句子的自然表达。"
        "请检查下列句子是否存在欧式中文翻译腔问题。此类问题可能包括："
        "句子冗长、逗号等标点使用过度、被动语态频繁、连接词堆砌或语序不符合中文表达习惯等。"
        "如果句子没有问题，请只回复「没有问题」四个字；如果存在问题，请先列出主要问题的原因，然后给出一句修改建议，"
        "使句子更符合中文的表达习惯，回复内容请保持精炼。"
    )
    user_msg = f"请检查下列句子：\n{sentence}"

    try:
        response = openai_handle.chat.completions.create(
            model=MODEL,
            messages=[
                {"role": "system", "content": system_msg},
                {"role": "user", "content": user_msg},
            ],
            temperature=0.2,
            max_tokens=100,
            timeout=10,
        )
        answer = response.choices[0].message.content.strip()
    except Exception as e:
        answer = f"调用 OpenAI API 时出错: {e}"
    return answer


def analyze_text(text):
    """
    预处理输入文本：移除代码块、链接及简化 URL，然后按中文标点和换行拆分为单句，
    针对每个包含汉字的句子调用 judge_sentence() 进行判断，
    如果模型反馈内容，则记录该句子 (句号序号, 句子, 模型回复内容)。
    """
    # 预处理：移除代码块，再处理链接和 URL
    text = remove_markdown_code_blocks(text)
    sentences = re.split(r"[。！？\n]", text)

    for i, sentence in enumerate(sentences):
        sentence = sentence.strip()
        if not sentence:
            continue
        # 如果句子中不包含汉字，直接跳过
        if not re.search(r"[\u4e00-\u9fff]", sentence):
            continue
        sentence = remove_markdown_links(sentence)
        sentence = shorten_urls_in_text(sentence)
        judgement = judge_sentence(sentence)
        # 如果回复为空或类似“不需要修正”的，则认为句子没问题，不输出
        if judgement and any(
            kw in judgement for kw in ["不需要修正", "不需要修改", "没有问题"]
        ):
            judgement = None
        yield (i + 1, sentence, judgement)
        # 1000 RPM
        time.sleep(0.001)  # 控制请求频率，避免过快触发 API 限制


def main():
    if len(sys.argv) != 2:
        print("用法: {} <文件路径>".format(sys.argv[0]))
        sys.exit(1)

    file_path = sys.argv[1]
    try:
        with open(file_path, "r", encoding="utf-8") as f:
            text = f.read()
    except Exception as e:
        print("读取文件 {} 时出错：{}".format(file_path, e))
        sys.exit(1)

    for idx, sentence, judgement in tqdm(analyze_text(text)):
        if not judgement:
            continue
        print("【第{}句】".format(idx))
        print(sentence)
        print("判断理由及修改建议：" + judgement)
        print("-" * 40)


if __name__ == "__main__":
    main()

shuorenhua.py

#!/usr/bin/env python3
# 从 LLM 生成脚本修改。
"""
本脚本用于分析一个包含中文文章内容的文件，
并尝试捕获可能体现“欧式中文翻译腔”特征的句子，
如句子过长、逗号使用频繁（提示从句堆砌）、被动语态（“被…”）及过多连接词使用等。
"""

import re
import sys
import mistune
import mistune.renderers
import mistune.renderers.markdown


# 自定义渲染器，重写代码块渲染方法，使其返回空字符串
class NoCodeRenderer(mistune.renderers.markdown.MarkdownRenderer):
    def block_code(self, code, info=None):
        # 无论 code 内容如何，都返回空，移除代码块
        return ""


def remove_markdown_code_blocks(markdown_text):
    """
    使用 mistune 库解析 Markdown 文本并移除其中的代码块（可处理任意数量的反引号）。
    返回内容为 HTML 格式，不包含代码块内容。
    """
    markdown = mistune.create_markdown(renderer=NoCodeRenderer())
    return markdown(markdown_text)


def remove_markdown_links(text):
    """
    将 Markdown 格式的链接从文本中去掉，仅保留链接文本。
    例如：[百度](https://www.baidu.com) 会被转换为 “百度”。
    """
    # 匹配形如 [链接文本](链接地址) 的 Markdown 格式链接，并替换为链接文本
    pattern = r"\[([^\]]+)\]\([^)]+\)"
    return re.sub(pattern, r"\1", text)


def shorten_urls_in_text(text):
    """
    将文本中所有以 http 或 https 开头的 URL 替换为固定的短链接 "https://example.com"，
    不调用外部服务，仅为句子复杂性等检查提供统一的短链接。
    """
    url_pattern = re.compile(r"https?://[^\s\)]+")
    return url_pattern.sub("https://example.com", text)


def analyze_text(text):
    # 设定启发式阈值
    long_sentence_threshold = 80  # 觉得超过80字符可以认为句子较长
    comma_threshold = 3  # 如果一个句子中“，”出现次数超过3次，则考虑结构过于复杂

    # 被动语态的初步判断：检测“被”字后连续若干汉字（提示可能为被动结构）
    passive_regex = re.compile(r"被[\u4e00-\u9fff]{1,3}")

    # 常见逻辑关联词，翻译腔中常频繁出现
    connectives = [
        "综上所述",
        "因此",
        "然而",
        "另外",
        "首先",
        "其次",
        "最后",
        "通过",
        "根据",
        "从而",
    ]

    # Markdown 预处理
    text = remove_markdown_code_blocks(text)

    # 按中文句号、感叹号、问号拆分句子
    sentences = re.split(r"[。！？\n]", text)
    features_found = []

    for i, sentence in enumerate(sentences):
        sentence = sentence.strip()
        if not sentence:
            continue
        # 后处理
        sentence = remove_markdown_links(sentence)
        sentence = shorten_urls_in_text(sentence)

        sentence_features = []

        # 1. 检查句子长度是否过长
        if len(sentence) >= long_sentence_threshold:
            sentence_features.append("长句 (≥{}字符)".format(long_sentence_threshold))

        # 2. 检查逗号数量，如果过多提示可能为从句堆砌
        comma_count = sentence.count("，")
        if comma_count > comma_threshold:
            sentence_features.append("逗号较多 ({}个)".format(comma_count))

        # 3. 检查被动语态（简单检测“被”）
        if passive_regex.search(sentence):
            sentence_features.append("疑似被动语态")

        # 4. 检查连接词的使用情况
        found_connectives = [word for word in connectives if word in sentence]
        if len(found_connectives) >= 2:
            sentence_features.append(
                "连接词堆砌 (" + "，".join(found_connectives) + ")"
            )

        if sentence_features:
            features_found.append((i + 1, sentence, sentence_features))

    return features_found


def main():
    if len(sys.argv) != 2:
        print("用法: {} <文件路径>".format(sys.argv[0]))
        sys.exit(1)

    file_path = sys.argv[1]
    try:
        with open(file_path, "r", encoding="utf-8") as f:
            text = f.read()
    except Exception as e:
        print("读取文件 {} 时出错：{}".format(file_path, e))
        sys.exit(1)

    results = analyze_text(text)
    if not results:
        print("未检测到明显的欧式中文翻译腔特征。")
    else:
        print("检测到以下可能的欧式中文翻译腔特征：\n")
        for idx, sentence, features in results:
            print("【第{}句】".format(idx))
            print(sentence)
            print("特征：" + " | ".join(features))
            print("-" * 40)


if __name__ == "__main__":
    main()

z-example.llm

【第16句】
本文不是这些文档的翻版，我们希望通过简洁清晰、更为友好的语言，来快速帮助同学们了解与提问相关的注意事项
判断理由及修改建议：主要问题：
1. "本文不是这些文档的翻版"表述生硬
2. "通过...来..."结构过于欧化
3. "与提问相关的注意事项"表述冗长

修改建议：
本文并非简单复制这些文档，而是用更简洁友好的语言，帮助同学们快速了解提问注意事项。
----------------------------------------
【第19句】
本文涉及到的真实例子会做匿名化处理，并且我们希望读者在遇到类似问题时，能够结合自己的实际情况进行思考，而不是机械地执行检查单
判断理由及修改建议：主要问题：
1. 被动语态使用频繁（"会做匿名化处理"）
2. 连接词堆砌（"并且"）
3. 句子结构冗长

修改建议：
本文中的真实案例将进行匿名处理，希望读者遇到类似问题时能结合实际思考，而非机械执行检查单。
----------------------------------------
【第24句】
在求助他人之前，不妨先尝试自己对问题进行一点初步的分析，这会有助于你问出正确的问题、节省他人的时间，并且也能帮助你更好地理解问题
判断理由及修改建议：主要问题：
1. "这会有助于你问出正确的问题"表达生硬
2. "并且也能帮助你更好地理解问题"连接词使用不够自然

修改建议：
在求助他人之前，不妨先自己分析一下问题，这样既能问得更准确，节省他人时间，也能加深对问题的理解。
----------------------------------------
【第29句】
多数错误伴随着错误信息（error message），这是解决问题的第一步，想要帮助你的人通常也希望你提供这些内容，所以不妨自己先行阅读这些内容，一些基本的技巧包括：
判断理由及修改建议：主要问题原因：
1. 句子结构松散，逗号使用过多
2. "这是解决问题的第一步"与前后文逻辑关系不明确
3. "一些基本的技巧包括"与前面内容衔接生硬

修改建议：
大多数错误都会伴随错误提示信息，这是解决问题的关键线索。建议先自行阅读这些提示内容，因为帮助者通常也需要这些信息。以下是几个基本技巧：
----------------------------------------
【第31句】
- 错误信息大多都是英语，不过无需担心，没有开发者会在这里使用特别复杂的语法、单词等（不妨这样想：很多开发者的英文水平可能并不如你）
判断理由及修改建议：主要问题原因：
1. "错误信息大多都是英语"可以更简洁
2. "没有开发者会在这里使用特别复杂的语法、单词等"句式冗长
3. 括号内表述可以更自然

修改建议：
错误信息多为英文，但不用担心，开发者通常不会使用太复杂的语法或词汇（很多开发者的英文水平可能还不如你）。
----------------------------------------
【第33句】
> 如果你实在克服不了语言障碍，不妨尝试使用翻译软件（例如 DeepL、Google Translate、甚至大语言模型等）来帮助你理解错误信息
判断理由及修改建议：主要问题：
1. 括号内列举内容过长，影响阅读流畅性
2. "甚至"一词使用略显生硬

修改建议：
如果你实在克服不了语言障碍，可以尝试使用DeepL、Google Translate等翻译软件，或者借助大语言模型来理解错误信息。
----------------------------------------
【第36句】
- 程序日志一般分为 info、warn（有时写成 warning、W）、error（E）等级别，通常情况下，请关注**第一个出现的 error/warning** 信息，后续错误往往只是前面的延伸
判断理由及修改建议：主要问题：
1. 括号内的补充说明打断了句子流畅性
2. 英文缩写和中文混杂使用不够自然

修改建议：
程序日志通常分为info、warn（即warning或W）、error（即E）等几个级别，一般情况下，请优先关注第一个出现的error或warning信息，因为后续错误往往是前者的延伸。
----------------------------------------
【第39句】
> 例外的是，有些程序在最前面的错误信息内容可能信息量较低，例如 `subprocess xxx returned error code xxx` 这类信息只能知道某个进程出错了，但是错误原因没有表现出来，搜索效果会很差，故需要找到错误最初发出的地方并搜索最初发出的错误信息
判断理由及修改建议：主要问题：
1. 句子过长，包含多个信息点，导致结构松散
2. "故需要找到错误最初发出的地方"表达不够简洁
3. "错误原因没有表现出来"被动语态不够自然

修改建议：
有些程序的前置错误信息可能信息量不足，比如`subprocess xxx returned error code xxx`这类提示，只能表明进程出错却无法显示具体原因，搜索效果不佳，因此需要定位并搜索最初的错误信息。
----------------------------------------
【第42句】
- 如果你不知道在哪里找到日志，那么建议是还是先解决日志的问题，毕竟没有这些信息，其他人也只能摸着水晶球来猜测到底发生什么了
判断理由及修改建议：主要问题：  
1. 连接词堆砌（"如果...那么...毕竟..."），显得句子冗长不自然。  
2. "建议是还是"表达冗余。  

修改建议：  
建议先解决日志问题，没有这些信息，其他人只能靠猜测。
----------------------------------------
【第45句】
下面是这个过程中一些错误示范：
判断理由及修改建议：主要问题：
1. "下面是"的表述过于直白，不符合中文习惯
2. "错误示范"搭配不够自然

修改建议：
这个过程中有一些常见的错误做法：
----------------------------------------
【第49句】
对应提问的截图中的错误信息节选：
判断理由及修改建议：主要问题：
1. "对应提问的截图中的"结构过于冗长
2. "错误信息节选"表述不够自然

修改建议：
提问截图中的错误信息片段
----------------------------------------
【第51句】
可以看到，这里的输出已经给出很清晰的建议了，需要执行一下 `apt-get update` 命令
判断理由及修改建议：主要问题：
1. "可以看到"这种表达略显生硬
2. 被动语态使用不够自然

修改建议：
输出已给出清晰建议，需要执行`apt-get update`命令。
----------------------------------------
【第52句】
把这样的错误信息截图发到群里，也许是一件不太负责的事情
判断理由及修改建议：主要问题：
1. "把...发到群里"结构稍显生硬
2. "也许是一件不太负责的事情"表达不够自然

修改建议：
在群里转发这样的错误信息截图，可能不太负责任。
----------------------------------------
【第59句】
可以看到，异常（exception）的内容是 `You tried to install "pytorch". The package named for PyTorch is "torch"`，意思是，要安装的东西的名字应该是 `torch` 而不是 `pytorch`，所以解决方法就是跑的命令从 `pip install pytorch` 改成 `pip install torch`
判断理由及修改建议：主要问题：
1. 句子结构松散，逗号使用过多
2. 括号内英文术语可以更自然地融入中文
3. 部分表达可以更简洁

修改建议：
错误提示显示异常内容为`You tried to install "pytorch". The package named for PyTorch is "torch"`，说明正确的安装包名应为`torch`而非`pytorch`，只需将命令从`pip install pytorch`改为`
----------------------------------------
【第64句】
可以看到，输出中报错信息明确了是 `No such file or directory`（没有对应的文件或文件夹），代表给的文件程序找不到
判断理由及修改建议：主要问题：
1. 括号内的解释打断了句子流畅性
2. "代表给的文件程序找不到"表达不够自然

修改建议：
可以看到，输出报错信息显示"没有对应的文件或文件夹"，说明程序找不到指定的文件。
----------------------------------------
【第70句】
尽管近几年大语言模型发展迅速，但是搜索引擎在解决问题上仍然有着不可或缺的作用
判断理由及修改建议：主要问题：
1. "尽管...但是..."连接词使用稍显生硬
2. "在解决问题上"介词结构不够自然

修改建议：
近几年大语言模型发展迅速，但搜索引擎在解决问题方面仍不可或缺。
----------------------------------------
【第79句】
以下主要介绍通用搜索引擎的信息
判断理由及修改建议：主要问题：  
1. 语序不符合中文习惯，主语后置  
2. 被动表达不自然  

修改建议：  
本文主要介绍通用搜索引擎的相关信息
----------------------------------------
【第80句】
当然对于某些问题，以下方式可能会更加合理：
判断理由及修改建议：主要问题：
1. 句子开头使用"当然"显得生硬
2. "对于某些问题"的表述不够自然
3. 冒号使用不当

修改建议：
有些问题可以这样处理：
----------------------------------------
【第82句】
- 使用包含网页搜索功能的大语言模型（例如 Deepseek 联网搜索）直接询问
判断理由及修改建议：主要问题：
1. 括号内解释过长，影响阅读流畅性
2. 专业术语直接插入，不符合中文表达习惯

修改建议：
使用支持联网搜索的大语言模型（如Deepseek）直接查询
----------------------------------------
【第86句】
- 使用 Debian Code Search 搜索 Debian 这个 Linux 发行版中所有软件包的源代码，使用 GitHub 搜索查询 GitHub 上的所有公开代码
判断理由及修改建议：主要问题：  
1. 句子冗长，连接词堆砌  
2. 重复使用「搜索」显得啰嗦  

修改建议：  
用 Debian Code Search 查找 Debian 所有软件包的源代码，用 GitHub 搜索查询公开代码。
----------------------------------------
【第87句】
- 部分站点或服务会选择拒绝被通用搜索引擎索引，需要使用其手机 App 或合作方网站搜索（例如微信公众号、小红书等）
判断理由及修改建议：主要问题：
1. 被动语态使用不当（"被通用搜索引擎索引"）
2. 括号内容与主句衔接不够自然

修改建议：
部分站点或服务会拒绝通用搜索引擎索引，必须通过其手机App或合作方网站（如微信公众号、小红书等）才能搜索到。
----------------------------------------
【第92句】
例如，如果我在使用 Python 的 `argparse` 模块时遇到了问题，可能最好的方式是先查找其手册信息，在手册中寻找需要的内容：
判断理由及修改建议：主要问题：
1. 句子结构过于冗长，包含多个分句
2. 标点使用不够简洁

修改建议：
使用Python的`argparse`模块遇到问题时，最好先查阅手册寻找答案。
----------------------------------------
【第94句】
对于一个合格的搜索引擎，这样的搜索关键字足以将其对应的手册等关键信息排在结果最前面
判断理由及修改建议：主要问题：  
1. 句子冗长，结构复杂  
2. 被动语态使用不当（"将其对应的手册等关键信息排在结果最前面"）  

修改建议：  
合格的搜索引擎应该能将这类搜索关键字的相关手册等关键信息优先显示。
----------------------------------------
【第101句】
- 去掉「为什么」之类的副词与「的」之类的助词（尽管现代搜索引擎一般会默认忽略这些内容）
判断理由及修改建议：主要问题：
1. 括号内容过长，打断了主句的流畅性
2. "之类的"重复使用显得啰嗦

修改建议：
去掉「为什么」等副词和「的」等助词（现代搜索引擎通常会忽略这些内容）
----------------------------------------
【第105句】
- 去掉不具备普遍性的内容：例如用户名、文件名、变量名等不会影响问题发生与否的信息
判断理由及修改建议：主要问题的原因：
1. 句子结构过于复杂，使用了多个连接词
2. 被动语态使用频繁
3. 标点使用不够简洁

修改建议：
去掉不具普遍性的内容，如用户名、文件名等不影响问题的信息。
----------------------------------------
【第107句】
- 善于使用搜索引擎的特殊功能，大部分搜索引擎都支持下述功能：
判断理由及修改建议：主要问题：
1. 句子结构松散，前后部分逻辑连接不够紧密
2. "都支持下述功能"表达生硬

修改建议：
善于使用搜索引擎的特殊功能，这些功能包括：
----------------------------------------
【第109句】
- Search operator：例如使用双引号 `"Something"` 可以要求结果中必须含有被双引号（注意是半角双引号 `"` ）括起的内容，使用加号 `+Something` 开头可以强制搜索结果必须包含指定的单词，而使用减号 `-Something` 开头就是排除对应的单词
判断理由及修改建议：主要问题：
1. 句子冗长，包含多个并列信息
2. 技术说明过于密集，阅读负担重
3. 括号嵌套使用影响流畅性

修改建议：
搜索运算符的用法示例：用半角双引号`"关键词"`可精确匹配内容，`+关键词`表示必须包含该词，`-关键词`则表示排除该词。
----------------------------------------
【第115句】
- `site:` 标识符：例如 `site:example.com Something` 可以限制搜索引擎只在 `example.com` 这个网站内搜索
判断理由及修改建议：主要问题：
1. 被动语态使用频繁（"可以限制搜索引擎"）
2. 标点符号使用不规范（英文引号与中文混用）

修改建议：
使用"site:"标识符时，比如输入"site:example.com Something"，就能让搜索引擎只在example.com网站内查找内容。
----------------------------------------
【第119句】
- 如果你的工具给出了任何的错误代码：搜索 `工具名称 错误代码` 比搜索错误的文本提示有效得多
判断理由及修改建议：主要问题：
1. 被动语态使用不当（"给出了"）
2. 连接词堆砌（"如果...比..."结构不够自然）

修改建议：
当工具出现错误代码时，直接搜索"工具名称 错误代码"比搜索错误提示更有效。
----------------------------------------
【第122句】
- 使用英语：支持多语言的工具（比如上文的 `apt`），在互联网上往往是英文内容比中文多，如果中文结果并不能解决问题，不妨试试讲这些工具的语言先调整回英文
判断理由及修改建议：主要问题：  
1. 句子冗长，逗号使用过多  
2. "不妨试试讲这些工具的语言先调整回英文" 表达生硬  

修改建议：  
支持多语言的工具（比如 `apt`）在互联网上英文内容通常比中文多。如果中文结果无法解决问题，可以尝试将工具语言切换回英文。
----------------------------------------
【第125句】
作为一个例子，对于下面这个「问题」：
判断理由及修改建议：主要问题：
1. 句子结构过于欧化，使用了"作为一个例子"这样的直译表达
2. 引号使用不够自然

修改建议：
以这个问题为例：
----------------------------------------
【第127句】
首先判断（最）重要的信息，并且调整：
判断理由及修改建议：句子问题分析：
1. 使用了括号插入说明，不符合中文流畅表达习惯
2. "并且"连接词使用生硬
3. 整体句式偏欧化

修改建议：
先判断最重要的信息，再进行调整
----------------------------------------
【第129句】
然后使用上面的简单策略处理查询：
判断理由及修改建议：主要问题：
1. "然后使用上面的简单策略处理查询"是典型的欧式中文语序，不符合中文表达习惯
2. 缺少主语，显得生硬

修改建议：
接下来可以用上述简单策略来处理查询
----------------------------------------
【第131句】
（「输出」这两个字甚至也可以不要）
判断理由及修改建议：主要问题：括号内的内容表达不够自然，且括号使用不符合中文习惯。

修改建议：连"输出"这两个字也可以省略。
----------------------------------------
【第133句】
直接贴到任何搜索引擎（必应/谷歌），甚至百度给出的结果都是对应的解决方法
判断理由及修改建议：主要问题原因：
1. 括号使用不符合中文习惯
2. "给出的结果都是对应的解决方法"表达不够自然

修改建议：
直接贴到任何搜索引擎，无论是必应、谷歌还是百度，都能找到对应的解决方法。
----------------------------------------
【第138句】
部分搜索引擎可能会在结果中返回广告，可以考虑为自己的浏览器安装去广告扩展（例如 uBlock Origin）来排除这一部分内容
判断理由及修改建议：主要问题：
1. 被动语态使用（"可能会在结果中返回广告"）
2. 句式不够简洁

修改建议：
有些搜索引擎会在搜索结果中显示广告，可以安装去广告插件（如uBlock Origin）来屏蔽这些内容。
----------------------------------------
【第141句】
有一小部分网站（大多出于商业目的）会不加选择地收集垃圾内容，并且不择手段让搜索引擎相信它们包含有效的信息
判断理由及修改建议：主要问题：
1. 括号使用不符合中文习惯
2. "并且"连接词使用生硬
3. "让搜索引擎相信"表达不够自然

修改建议：
少数网站（主要是商业网站）会不加选择地收集垃圾内容，甚至想方设法欺骗搜索引擎，使其误判为有效信息。
----------------------------------------
【第143句】
对于解决你的问题而言，这些网站提供的信息量几乎为 0
判断理由及修改建议：主要问题：
1. "对于解决你的问题而言"过于冗长，不符合中文简洁表达习惯
2. "几乎为0"的表述过于书面化

修改建议：
这些网站提供的信息对你解决问题没什么帮助。
----------------------------------------
【第147句】
对于搜索得到的结果，目前普遍（同样不成文）的认识是：一些网站的内容质量（例如 CSDN）普遍比其他的更低，中文结果的平均质量比英文结果低（很遗憾，这也是更推荐使用英文搜索的原因之一）
判断理由及修改建议：主要问题：
1. 括号使用过多，打断了句子流畅性
2. 表达方式过于书面化，不够自然

修改建议：
目前普遍认为，像CSDN这类网站的内容质量相对较低，而且中文搜索结果的平均质量也不如英文，这也是更推荐使用英文搜索的原因之一。
----------------------------------------
【第153句】
自 2023 年初，随着大语言模型（GPT 等）的逐渐普及，询问大语言模型也是很有效的解决问题的途径（并且比真人更有耐心）
判断理由及修改建议：主要问题：
1. 括号使用不符合中文表达习惯
2. 句子结构松散，缺乏连贯性

修改建议：
自2023年初大语言模型（如GPT）逐渐普及以来，询问大语言模型已成为解决问题的有效途径，而且比真人更有耐心。
----------------------------------------
【第161句】
X-Y 型问题指代这类情况：你遇到了 X 问题，你认为用 Y 方法可以解决 X 问题，但是遇到了阻碍，因此向别人提问关于 Y 的问题，而不告诉其他人最原本的 X 问题
判断理由及修改建议：主要问题：
1. 句子结构过于复杂，使用了过多的解释性插入语
2. 标点使用过多，导致阅读节奏不连贯
3. 表达方式不够简洁直接

修改建议：
X-Y型问题是指：当你遇到X问题想用Y方法解决却受阻时，只向别人询问Y问题而不说明原本的X问题。
----------------------------------------
【第165句】
以下摘录了陈皓先生在他的博客中介绍 X-Y 型问题（Web Archive）时提及的例子：
判断理由及修改建议：主要问题：
1. 句子结构过于冗长，包含多层嵌套信息
2. "提及的例子"这样的表达不够自然

修改建议：
陈皓先生在其博客中介绍X-Y型问题时，曾举过这样一个例子（Web Archive）：
----------------------------------------
【第175句】
### 避免「在吗」/「有人吗」 {#ask-directly}
判断理由及修改建议：主要问题的原因：
1. 使用了不符合中文表达习惯的标点符号（花括号）
2. 标题式表达不够自然

修改建议：
### 请直接提问，避免使用"在吗"或"有人吗"
----------------------------------------
【第177句】
在私聊中，直接提问比先只问「在吗」是更好、效率更高的选择，考虑这样一个（虚构的）例子：
判断理由及修改建议：主要问题：
1. 句子结构冗长，包含多个分句
2. "是更好、效率更高的选择"表达不够简洁
3. "考虑这样一个（虚构的）例子"句式不够自然

修改建议：
私聊时直接提问比先问"在吗"更高效。比如这个例子：
----------------------------------------
【第181句】
群聊中也是如此，因为“礼貌”问题而额外“握手”一次可能显得有些浪费时间
判断理由及修改建议：主要问题：
1. 句子结构略显欧化，连接词使用不够自然
2. "因为...而..."的因果关系表达不够简洁

修改建议：
群聊中额外"握手"一次可能显得浪费时间，毕竟只是出于礼貌。
----------------------------------------
【第193句】
- 就算真的有人懂，懂的人很可能也不想在群里（通过回答这样的问题）夸耀自己很懂
判断理由及修改建议：主要问题：
1. 括号使用不符合中文表达习惯
2. "通过回答这样的问题"显得冗长

修改建议：
就算真的有人懂，懂的人很可能也不想在群里显摆自己。
----------------------------------------
【第194句】
而不太懂的人就更没有兴趣看你的问题了
判断理由及修改建议：主要问题：
1. 句子结构略显生硬，不符合中文口语化表达习惯
2. "而不太懂的人"这个表达不够自然

修改建议：
不懂的人就更没兴趣看你的问题了
----------------------------------------
【第196句】
- 很多时候对应的问题即使是不精通相关领域的人也可以回答，对应的问题可能是某种常识
判断理由及修改建议：主要问题：
1. "对应的问题"重复使用，显得啰嗦
2. "即使是不精通相关领域的人也可以回答"句式欧化
3. "可能是某种常识"表述不够自然

修改建议：
这类问题往往属于常识范畴，外行人也能够回答。
----------------------------------------
【第206句】
**最小可复现样例**（Minimal reproducible example，MRE）一般是一段**完整**的程序代码或者执行流程，**不包含与错误无关的部分**
判断理由及修改建议：主要问题：
1. 括号内英文缩写解释显得突兀
2. 两个"**"强调部分破坏了中文流畅性

修改建议：
最小可复现样例（简称MRE）应当是一段完整且精简的程序代码或执行流程，仅保留与错误相关的必要部分。
----------------------------------------
【第207句】
这通常只包含出现问题的核心几行代码/命令、以及最小的依赖
判断理由及修改建议：主要问题：
1. "这通常只包含"的表述略显生硬
2. "/"符号不符合中文标点规范
3. "以及"连接词使用不够自然

修改建议：
通常只需包含出问题的核心代码和最小依赖项。
----------------------------------------
【第208句】
为了制作这样的样例，你可以复制一份当前的工程，并不断二分，在保留原有错误的情况下，逐渐删去与问题无关的部分
判断理由及修改建议：主要问题原因：
1. 句子结构过于冗长，使用了多个逗号分隔动作
2. "在保留原有错误的情况下"这个状语位置不够自然
3. "逐渐删去与问题无关的部分"表达不够简洁

修改建议：
你可以复制当前工程，通过二分法逐步删除无关部分，同时保留原有错误来制作样例。
----------------------------------------
【第209句】
和上面自行阅读错误信息的过程类似，在这之中你可能自己就能发现问题
判断理由及修改建议：主要问题：
1. "在这之中"过于书面化，不符合口语表达习惯
2. "可能自己就能发现问题"语序不够自然

修改建议：
和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。
----------------------------------------
【第212句】
提供 MRE 的原因可以反过来考虑，如果提问者只提供了一段很长、包含很多第三方库、自己的结构体/类方法的代码，在缺少这些信息的情况下，回答者几乎无从下手
判断理由及修改建议：主要问题：
1. 句子结构过于复杂，包含多个条件从句
2. "可以反过来考虑"表达不够自然
3. "在缺少这些信息的情况下"句式欧化

修改建议：
不妨换个角度思考：当提问者只提供一段冗长代码，包含大量第三方库和自定义结构体/类方法时，缺少这些关键信息会让回答者无从下手。
----------------------------------------
【第213句】
如果此时提问者转而尝试把相关的代码都提供出来，我想很少会有人愿意自愿帮助别人调试几百行的代码，更不要提配置一致的、非常复杂的环境
判断理由及修改建议：主要问题：
1. 句子过长，结构复杂
2. "如果此时提问者转而尝试把相关的代码都提供出来"表达不够简洁
3. "配置一致的、非常复杂的环境"定语过长

修改建议：
提问者若直接提供全部代码，恐怕很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
----------------------------------------
【第216句】
> 提供 MRE 是一种平衡提问者和回答者时间的方法，可能需要提问者花费更多的时间来准备，也需要一定的技巧，但是能帮助双方都更定位问题
判断理由及修改建议：主要问题：
1. 句子结构松散，连接词过多（"可能...也...但是..."）
2. "帮助双方都更定位问题"表述不自然

修改建议：
MRE的提供能平衡双方时间，虽然需要提问者花费更多准备时间和一定技巧，但有助于准确定位问题。
----------------------------------------
【第221句】
必要的描述与信息可能包括：
判断理由及修改建议：主要问题：
1. 句子结构过于欧化，使用了"可能包括"这样的被动表达
2. "必要的描述与信息"这样的搭配不够自然

修改建议：
需要说明的内容可能包括：
----------------------------------------
【第225句】
- 报错信息（注：如上文所述，通常只有前面显示的报错信息是关键的，故可以尝试先从前一条/几条有效的报错信息开始提问）
判断理由及修改建议：主要问题：
1. 括号内解释过长，打断了句子流畅性
2. "故可以尝试"的表述过于书面化

修改建议：
报错信息（通常只有前几条是关键信息，建议先从前面的有效报错开始提问）
----------------------------------------
【第229句】
以下展示一个在以 Linux 讨论为主的群聊中的反例：
判断理由及修改建议：主要问题：
1. "以下展示一个"是典型的欧式中文结构，不符合中文表达习惯
2. "以...为主"的句式过于正式，与日常表达不符

修改建议：
这是一个Linux讨论群里常见的反面例子：
----------------------------------------
【第234句】
在向他人报告错误信息时，务必直接提供原始输出，而不要使用自行翻译的版本
判断理由及修改建议：主要问题：  
- 句子结构稍显生硬，带有翻译腔  

修改建议：  
报告错误时请直接提供原始输出，不要自行翻译。
----------------------------------------
【第235句】
在有条件的情况下，建议在软件开发者自己熟悉的语言（许多时候是英语）环境下复现错误，以便得到表述准确的提示信息，帮助其他人定位你的问题
判断理由及修改建议：主要问题：
1. 句子结构过于复杂，包含多层嵌套
2. "以便得到表述准确的提示信息"表达不够自然
3. "帮助其他人定位你的问题"语序不够简洁

修改建议：
建议在熟悉的语言环境（通常是英语）下复现错误，这样能获得更准确的提示信息，方便他人定位问题。
----------------------------------------
【第236句】
建议将错误信息复制后发送，而不是自己手动对着敲一遍；如果原文内容过长，可以参考下一节内容来使用 Pastebin 等工具分享完整文本
判断理由及修改建议：主要问题：
1. 句子结构冗长，使用了多个分号连接不同情况
2. "建议将...而不是..."的对比结构不够简洁
3. "可以参考下一节内容来使用"表达不够自然

修改建议：
建议复制错误信息发送，不要手动输入；若内容过长，可参考下一节使用Pastebin等工具分享完整文本。
----------------------------------------
【第239句】
对于 Linux，可以使用以下方法指定程序运行的语言：
判断理由及修改建议：主要问题：
1. "对于 Linux" 这种介词结构开头不符合中文表达习惯
2. "指定程序运行的语言" 被动语态明显

修改建议：
在 Linux 系统中，可以用以下方法设置程序运行语言：
----------------------------------------
【第241句】
### 使用 Snippet/Gist/Pastebin 类型服务放问题相关的代码与报错 {#use-pastebin}
判断理由及修改建议：主要问题：
1. 标题过长，不符合中文标题简洁的习惯
2. 使用了英文标点符号（#）
3. 被动语态（"放问题相关的代码"）

修改建议：
### 使用代码片段服务提交问题代码和报错
----------------------------------------
【第243句】
代码和报错信息可能会非常长，此时截图或者直接文本贴到群聊里面可能不是一个合适的选择：
判断理由及修改建议：主要问题：
1. 句子结构冗长，包含多个分句
2. "可能"重复使用
3. "不是一个合适的选择"表达不够自然

修改建议：
代码和报错信息如果太长，直接截图或贴到群聊里可能不太合适。
----------------------------------------
【第245句】
- 截图，特别是代码，如果其他人想跑你的代码，OCR 可能会有问题，而且也没有人会想自己人肉 OCR
判断理由及修改建议：主要问题：  
1. 句子结构松散，逗号使用过多导致表达不够连贯  
2. "OCR可能会有问题"被动语态不够自然  
3. "自己人肉OCR"表述不符合中文习惯  

修改建议：  
截图里的代码不方便他人直接使用，既难以OCR识别，也没人愿意手动转录。
----------------------------------------
【第247句】
- 对于比较长的信息，直接发送会影响其他人阅读前面的信息，并且不美观（特别是不支持代码块样式的聊天软件，例如 QQ/微信）
判断理由及修改建议：主要问题：
1. 句子结构松散，使用"并且"连接两个并列关系不够紧密
2. 括号内的补充说明过长，影响主句流畅性

修改建议：
较长的信息直接发送会影响他人阅读前面内容，也不够美观（尤其在不支持代码块的QQ/微信等聊天软件中）。
----------------------------------------
【第248句】
- 某些聊天软件会转义特殊字符到表情符号，使得文本难以阅读
判断理由及修改建议：主要问题：
1. "转义特殊字符到表情符号"表述不够自然
2. "使得"连接词使用略显生硬

修改建议：
某些聊天软件会把特殊字符自动转换成表情符号，导致文本难以阅读。
----------------------------------------
【第250句】
尽管诸如聊天等场景下可以上传文件，在一些场合直接上传文件可能会不受欢迎（例如群聊的管理员可能不希望群共享文件里面都是乱七八糟的代码）
判断理由及修改建议：主要问题：
1. 括号内解释过长，打断了句子流畅性
2. "可能会不受欢迎"表达不够自然

修改建议：
虽然聊天等场景支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。
----------------------------------------
【第251句】
一些网站提供了存储长文本的功能（注意一些网站可能无法直接访问）：
判断理由及修改建议：主要问题：
1. 括号内的补充说明打断了句子流畅性
2. "可能无法直接访问"表达不够自然

修改建议：
部分网站提供长文本存储功能，但有些可能需要特殊访问方式。
----------------------------------------
【第255句】
- 独立的 Pastebin 类型服务，例如 Ubuntu pastebin，Pastebin.com 等
判断理由及修改建议：主要问题：
1. "类型服务"这种表达不够自然
2. 列举方式过于直译

修改建议：
- 独立的Pastebin类服务，如Ubuntu pastebin、Pastebin.com等
----------------------------------------
【第257句】
对于科大校内的同学，可以使用校内 GitLab（超算中心 或 LUG）的 Snippets
判断理由及修改建议：主要问题：
1. 括号使用不符合中文习惯
2. 机构名称缩写未加说明

修改建议：
科大同学可使用校内GitLab（包括超算中心或Linux用户组）的Snippets功能。
----------------------------------------
【第262句】
这个问题作为反例的原因是：
判断理由及修改建议：主要问题：
1. 句子结构过于欧化，使用了"作为...的原因是"这样的被动表达
2. 表述不够简洁直接

修改建议：
这个问题的反例原因在于
----------------------------------------
【第264句】
- 没有提供任何代码，要知道 Vulkan 画个三角形都要写一千多行代码
判断理由及修改建议：主要问题：  
1. 前半句被动语态生硬（「没有提供」隐含被动）  
2. 后半句「要知道」的转折关系不自然  

修改建议：  
「连代码都没给，Vulkan 画个三角形都得写一千多行。」  

（说明：改为主动语态，用「连...都」替代转折词，删除冗余表达）
----------------------------------------
【第265句】
- 环境信息不够详细：例如 Wayland 很大程度取决于混成器，因此需要提供更详细的信息（例如使用的桌面环境是 KDE 等）；Vulkan 也是一个比较宽泛的概念，提供更多与图形库有关的信息会有帮助（例如使用了 GLFW 绘制窗口）
判断理由及修改建议：主要问题：
1. 括号使用过多，打断了句子流畅性
2. "很大程度取决于"等表达稍显生硬

修改建议：
环境信息不够详细：比如Wayland主要依赖混成器实现，建议说明具体使用的桌面环境如KDE；Vulkan作为图形接口较为宽泛，最好补充相关图形库信息，例如是否使用GLFW绘制窗口。
----------------------------------------
【第269句】
除非实在无法截图（例如，系统启动阶段），否则不要拍屏，因为：
判断理由及修改建议：主要问题：
1. "因为："后面缺少具体解释，显得突兀
2. "拍屏"一词不够规范

修改建议：
除非无法截图（如系统启动阶段），否则请勿使用拍照方式记录屏幕内容。
----------------------------------------
【第272句】
- 字/图像可能会拍不清楚，这种现象被称为「莫尔纹」
判断理由及修改建议：主要问题：
1. 被动语态使用不自然（"被称为"）
2. 专业术语解释方式不够通俗

修改建议：
字/图像可能会拍不清楚，这就是「莫尔纹」现象。
----------------------------------------
【第273句】
- 其他人可能需要扭脖子才能正确看到内容
判断理由及修改建议：主要问题：  
1. 被动语态（「被看到」的隐含表达）  
2. 动词结构生硬（「扭脖子才能正确看到」不符合中文动作连贯性）  

修改建议：  
其他人得歪着头才能看清内容
----------------------------------------
【第274句】
- 不便于以后遇到同样问题的人搜索
判断理由及修改建议：主要问题：
1. "不便于"的表述略显生硬，不够口语化
2. "以后遇到同样问题的人"结构稍显冗长

修改建议：
- 不利于其他人搜索类似问题
----------------------------------------
【第276句】
## 如果没有人回答 {#if-no-answer}
判断理由及修改建议：主要问题：
1. 使用了欧式中文的被动语态结构"如果没有人回答"
2. 缺少上下文，显得不够自然

修改建议：
若无人应答
----------------------------------------
【第278句】
没有人回答问题 ≠ 被无视，在群聊中，如果认真提问却没有人回答，更有可能发生的事情是：看到问题的人完全不知道如何解决，仅此而已
判断理由及修改建议：主要问题：
1. 被动语态使用不当（"被无视"）
2. 连接词使用生硬（"更有可能发生的事情是"）
3. 句式结构欧化

修改建议：
没人回答问题不等于被无视。在群聊中，认真提问却无人回应，往往只是因为看到问题的人都不知道答案罢了。
----------------------------------------
【第279句】
同时也需要注意，群聊中（或者论坛中）的其他与你素不相识的人也没有必须回答问题的义务
判断理由及修改建议：主要问题：  
1. 括号使用不符合中文书面表达习惯  
2. "必须...的义务"搭配生硬  

修改建议：  
也要注意，群聊或论坛里的陌生人并没有义务回答你的问题。
----------------------------------------
【第282句】
可以考虑从以下一些方式解决问题：
判断理由及修改建议：主要问题：
1. "可以考虑从以下一些方式解决问题"句式生硬，带有明显的翻译腔
2. "以下一些"搭配不当

修改建议：
可以考虑用以下几种方式解决问题
----------------------------------------
【第286句】
- Tip: LUG 在西区与高新区的活动室，只要房间里有人就可以进来（可以来之前在群里问一下）
判断理由及修改建议：主要问题：
1. 括号使用不符合中文习惯
2. 表达不够简洁

修改建议：
西区和高新区的LUG活动室只要有人就可以使用，来之前建议先在群里确认一下。
----------------------------------------
【第292句】
### 阅读本部分前，先阅读正文内容 {#read-main-content-first}
判断理由及修改建议：主要问题：
1. 语序不符合中文表达习惯，中文通常将条件或前提放在前面
2. 标点使用不规范，中文一般不使用大括号作为注释符号

修改建议：
请先阅读正文内容，再阅读本部分
----------------------------------------
【第299句】
和向人类提问类似，提供足够的上下文信息可以更好帮助大语言模型理解问题，满足用户需求，作出更好的回答
判断理由及修改建议：主要问题：
1. 句子结构过于冗长，多个动词短语并列
2. "可以更好帮助"的表达不够自然

修改建议：
提供足够的上下文信息能帮助大语言模型更准确地理解问题，从而给出更好的回答。
----------------------------------------
【第300句】
以上文提及的一个例子为例
判断理由及修改建议：主要问题：
1. "以上文提及的一个例子为例"过于冗长，不符合中文简洁表达习惯
2. "提及"和"为例"重复表达

修改建议：
以刚才的例子为例
----------------------------------------
【第307句】
可以发现，相比原始版本，这里添加了以下信息：
判断理由及修改建议：主要问题：
1. "可以发现"作为开头显得生硬，不符合中文自然表达习惯
2. "相比原始版本"语序不够自然

修改建议：
这里相比原始版本增加了以下信息：
----------------------------------------
【第312句】
得到的结果就更加简洁，也更加符合用户需求（用户的 Windows 环境里面可能根本没有 wget 或者 curl）
判断理由及修改建议：主要问题：
1. 括号内的补充说明打断了句子流畅性
2. "用户的 Windows 环境"表达略显生硬

修改建议：
这样得到的结果更加简洁，也更符合用户需求，毕竟很多用户的电脑里可能根本没有wget或curl。
----------------------------------------
【第317句】
由于大语言模型的训练语料很多时候英文的数据量远大于中文，因此使用英文提问得到的结果质量可能比中文提问更好
判断理由及修改建议：主要问题：  
1. 句子冗长，连接词堆砌（"由于...因此..."结构生硬）  
2. "数据量远大于中文"表述不自然  

修改建议：  
大语言模型的训练语料中英文占比更高，用英文提问可能效果更好。
----------------------------------------
【第323句】
大语言模型的工作模式简单来讲是：每次用户发送消息时，LLM 都会从最开头开始分析内容，到用户本次发送的信息结束后再开始生成
判断理由及修改建议：主要问题：
1. 句子结构过于冗长，使用了过多的连接词和标点符号
2. "到...再开始"的句式不够简洁

修改建议：
大语言模型的工作模式很简单：每次用户发送消息时，LLM都会从头分析内容，直到用户本次信息结束才开始生成。
----------------------------------------
【第324句】
这样带来了两个问题：
判断理由及修改建议：主要问题：  
1. 句式生硬，带有翻译腔  

修改建议：  
这带来了两个问题：
----------------------------------------
【第326句】
- 对于超长的对话，每一次继续对话都会浪费不少的钱——假设当前的对话前，大语言模型分析了一个很长的网页，花费了一块钱，那么基于这段对话作为背景，**每次**发送一条消息，都会再花至少一块钱
判断理由及修改建议：主要问题原因：
1. 句子结构过于复杂，使用了过多的连接词和解释性内容
2. 破折号使用不当，打断了句子流畅性
3. 表达不够简洁直接

修改建议：
超长对话会持续消耗费用。例如，当模型分析了一个价值1元的长网页后，每次发送新消息都会再花费至少1元。
----------------------------------------
【第328句】
- 相比于短文本，LLM 对长文本更容易产生「**幻觉**」，即更容易输出与实际情况不相符的内容
判断理由及修改建议：主要问题：
1. 连接词"相比于"使用稍显生硬
2. 括号解释部分打断了句子流畅性

修改建议：
LLM处理长文本时更容易出现"幻觉"现象，即产生与事实不符的内容。
----------------------------------------
【第331句】
如果你发现 LLM 在某种情况下工作不正常，可以要求其重新开始接受输入（抛弃之前的内容）或重新开始会话
判断理由及修改建议：主要问题原因：
1. "可以要求其重新开始接受输入（抛弃之前的内容）"表述冗长，不符合中文简洁表达习惯
2. 括号使用不够自然

修改建议：
如果发现LLM工作异常，可以要求它重新开始输入或重启会话。
----------------------------------------

z-example.simple

检测到以下可能的欧式中文翻译腔特征：

【第29句】
多数错误伴随着错误信息（error message），这是解决问题的第一步，想要帮助你的人通常也希望你提供这些内容，所以不妨自己先行阅读这些内容，一些基本的技巧包括：
特征：长句 (≥80字符) | 逗号较多 (4个)
----------------------------------------
【第36句】
- 程序日志一般分为 info、warn（有时写成 warning、W）、error（E）等级别，通常情况下，请关注**第一个出现的 error/warning** 信息，后续错误往往只是前面的延伸
特征：长句 (≥80字符)
----------------------------------------
【第39句】
> 例外的是，有些程序在最前面的错误信息内容可能信息量较低，例如 `subprocess xxx returned error code xxx` 这类信息只能知道某个进程出错了，但是错误原因没有表现出来，搜索效果会很差，故需要找到错误最初发出的地方并搜索最初发出的错误信息
特征：长句 (≥80字符) | 逗号较多 (5个)
----------------------------------------
【第59句】
可以看到，异常（exception）的内容是 `You tried to install "pytorch". The package named for PyTorch is "torch"`，意思是，要安装的东西的名字应该是 `torch` 而不是 `pytorch`，所以解决方法就是跑的命令从 `pip install pytorch` 改成 `pip install torch`
特征：长句 (≥80字符) | 逗号较多 (4个)
----------------------------------------
【第86句】
- 使用 Debian Code Search 搜索 Debian 这个 Linux 发行版中所有软件包的源代码，使用 GitHub 搜索查询 GitHub 上的所有公开代码
特征：长句 (≥80字符)
----------------------------------------
【第87句】
- 部分站点或服务会选择拒绝被通用搜索引擎索引，需要使用其手机 App 或合作方网站搜索（例如微信公众号、小红书等）
特征：疑似被动语态
----------------------------------------
【第109句】
- Search operator：例如使用双引号 `"Something"` 可以要求结果中必须含有被双引号（注意是半角双引号 `"` ）括起的内容，使用加号 `+Something` 开头可以强制搜索结果必须包含指定的单词，而使用减号 `-Something` 开头就是排除对应的单词
特征：长句 (≥80字符) | 疑似被动语态
----------------------------------------
【第142句】
这些网站被称为「内容农场」
特征：疑似被动语态
----------------------------------------
【第147句】
对于搜索得到的结果，目前普遍（同样不成文）的认识是：一些网站的内容质量（例如 CSDN）普遍比其他的更低，中文结果的平均质量比英文结果低（很遗憾，这也是更推荐使用英文搜索的原因之一）
特征：长句 (≥80字符)
----------------------------------------
【第161句】
X-Y 型问题指代这类情况：你遇到了 X 问题，你认为用 Y 方法可以解决 X 问题，但是遇到了阻碍，因此向别人提问关于 Y 的问题，而不告诉其他人最原本的 X 问题
特征：长句 (≥80字符) | 逗号较多 (4个)
----------------------------------------
【第206句】
**最小可复现样例**（Minimal reproducible example，MRE）一般是一段**完整**的程序代码或者执行流程，**不包含与错误无关的部分**
特征：长句 (≥80字符)
----------------------------------------
【第208句】
为了制作这样的样例，你可以复制一份当前的工程，并不断二分，在保留原有错误的情况下，逐渐删去与问题无关的部分
特征：逗号较多 (4个)
----------------------------------------
【第245句】
- 截图，特别是代码，如果其他人想跑你的代码，OCR 可能会有问题，而且也没有人会想自己人肉 OCR
特征：逗号较多 (4个)
----------------------------------------
【第265句】
- 环境信息不够详细：例如 Wayland 很大程度取决于混成器，因此需要提供更详细的信息（例如使用的桌面环境是 KDE 等）；Vulkan 也是一个比较宽泛的概念，提供更多与图形库有关的信息会有帮助（例如使用了 GLFW 绘制窗口）
特征：长句 (≥80字符)
----------------------------------------
【第272句】
- 字/图像可能会拍不清楚，这种现象被称为「莫尔纹」
特征：疑似被动语态
----------------------------------------
【第278句】
没有人回答问题 ≠ 被无视，在群聊中，如果认真提问却没有人回答，更有可能发生的事情是：看到问题的人完全不知道如何解决，仅此而已
特征：逗号较多 (4个) | 疑似被动语态
----------------------------------------
【第326句】
- 对于超长的对话，每一次继续对话都会浪费不少的钱——假设当前的对话前，大语言模型分析了一个很长的网页，花费了一块钱，那么基于这段对话作为背景，**每次**发送一条消息，都会再花至少一块钱
特征：长句 (≥80字符) | 逗号较多 (6个)
----------------------------------------