diff --git a/Gemfile b/Gemfile index 50b99d37e0..08d5b7d770 100644 --- a/Gemfile +++ b/Gemfile @@ -28,7 +28,7 @@ group :jekyll_plugins do gem 'jekyll-data' gem 'jekyll-environment-variables' gem 'jekyll-tidy' - gem 'jekyll-last-modified', '>= 1.0.3' + gem 'jekyll-last-modified', '>= 1.0.5' gem 'jekyll-assets' gem 'jekyll-archives', '>= 2.2.1' gem 'jekyll-paginate-v2', '>= 3.0.0' diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md index 25764dd9d7..94907da1c6 100644 --- a/pages/_wiki/doc/howtoask.md +++ b/pages/_wiki/doc/howtoask.md @@ -8,30 +8,30 @@ License: CC-BY-NC-SA 4.0 ## 为什么需要再写一份这样的指南 {#why-this-guide} -网上已经有一些关于如何提问的文档，例如： +网上已有一些关于如何提问的文档，例如： - 提问的智慧（[原文](http://www.catb.org/~esr/faqs/smart-questions.html)，[中文](/wiki/doc/smart-questions/)） - [别傻傻地提问](https://github.com/tangx/Stop-Ask-Questions-The-Stupid-Ways/blob/master/README.md) -本文不是这些文档的翻版。我们希望通过更加简洁、清晰、友好的语言，帮助同学们快速了解提问注意事项。 +本文希望通过更加简洁、清晰、友好的语言，帮助同学们快速了解提问注意事项。 -本文涉及到的真实例子会做匿名化处理。我们希望读者在遇到类似问题时，能够结合自己的实际情况进行思考，而不是机械地执行检查单。 +请不要把本文当作检查单，我们希望你在遇到类似问题时能够结合实际情况进行思考。 ## 提问之前 {#before-asking} -在求助他人之前，不妨先自己分析一下问题，这样既能问得更准确，节省他人时间，也能加深对问题的理解。 +在求助他人之前，可以先分析一下问题。这样既能问得更准确、节省他人的时间，也能加深对问题的理解。 -### 阅读已有的信息 {#read-existing-info} +### 读懂错误信息 {#read-existing-info} -多数错误伴随着错误信息（error message），这是解决问题的第一步。想要帮助你的人通常也需要这些信息，所以不妨自己先行阅读它们。一些基本的技巧包括： +多数错误伴随着错误信息（error message），想要帮助你的人通常也需要这些信息，解读这些信息是解决问题的第一步。一些基本的心得和技巧包括： -- 错误信息多为英文，不过无需担心，开发者通常不会使用太复杂的语法或词汇（不妨这样想：很多开发者的英文水平可能并不如你） +- 错误信息多为英文，不过无需担心，开发者通常不会使用太复杂的语法或词汇（很多开发者的英文水平可能并不如你） > 如果你实在克服不了语言障碍，不妨尝试使用 DeepL、Google Translate 等翻译软件，或者借助大语言模型来帮助理解错误信息。 -- 程序日志一般分为 info、warn（warning、W）、error（E）等级别。通常情况下，请优先关注**第一个出现的 error/warning** 信息，因为后续错误往往只是前面的延伸。 +- 程序日志一般分为 info、warn（warning、W）、error（E）等级别。通常情况下，请优先关注**第一个出现的 error/warning** 信息，因为后续错误往往只是前面的延续。 - > 有些程序前置的错误信息内容可能信息量较低，例如 `subprocess xxx returned error code xxx` 这类提示，只能表明某个进程出错了，但是不包含具体原因。直接搜索的话效果会很差，故需要定位并搜索最初发出的错误信息。 + > 有些程序较早出现的错误提示可能信息量较低。例如 `subprocess xxx returned error code xxx` 这类提示，只能表明某个进程出错了，但是不包含具体原因。直接搜索的话效果会很差，因此定位并搜索有效的错误信息十分重要。 -- 如果你不知道在哪里找到日志，那么建议先解决日志的问题，毕竟没有这些信息，其他人也只能摸着水晶球来猜测到底发生什么了。 +- 如果你不知道在哪里找到日志，那么请先解决这个问题。没有这些信息，其他人也只能摸着水晶球猜测到底发生什么了。 下面是这个过程中一些错误示范： @@ -45,11 +45,12 @@ License: CC-BY-NC-SA 4.0 user@hostname:~/桌面$ ``` - 可以看到，这里的输出已经给出很清晰的建议了，需要执行一下 `apt-get update` 命令。把这样的错误信息截图发到群里，也许是一件不太负责的事情。 + 可以看到，这里的日志已经给出很清晰的建议了，需要执行一下 `apt-get update` 命令。如果你没有仔细阅读就把这样的错误信息截图发到群里，那很坏了。 - 例 2：为什么我装不了 `pytorch` - 执行的命令与错误信息： +
+ 查看执行的命令与完整错误信息 ```console $ pip install pytorch @@ -81,9 +82,11 @@ License: CC-BY-NC-SA 4.0 [notice] To update, run: pip install --upgrade pip ``` +
+ 错误提示显示异常（exception）的内容是 `You tried to install "pytorch". The package named for PyTorch is "torch"`，说明要安装的软件包的名字是 `torch`，而非 `pytorch`，因此将命令从 `pip install pytorch` 改成 `pip install torch` 即可。 -- 反例：为什么我的程序编译不了 +- 例 3：为什么我的程序编译不了 ```console $ gcc myporgram.c @@ -91,17 +94,17 @@ License: CC-BY-NC-SA 4.0 compilation terminated. ``` - 可以看到，输出中报错信息明确了是 `No such file or directory`（没有对应的文件或文件夹），说明程序找不到指定的文件。仔细检查便可发现是命令里面把文件名敲错了。 + 可以看到，输出中的报错信息明确指出了 `No such file or directory`（没有对应的文件或文件夹），说明程序找不到指定的文件。仔细检查便可发现是命令里面把文件名敲错了。 -### 利用搜索引擎等工具 {#use-search-engine} +### 使用搜索引擎 {#use-search-engine} 尽管近几年大语言模型发展迅速，但是搜索引擎在解决问题方面仍然不可或缺。 #### 选择搜索引擎 {#choose-search-engine} -作为业界不成文的「共识」，对常用搜索引擎的排序是：谷歌 > 必应国际版 > 必应国内版 > 百度。可以都试试，根据自己的实际情况选择。 +对于通用搜索引擎，业界不成文的「共识」是：谷歌 > 必应国际版 > 必应国内版 > 百度。可以都尝试一遍再根据自己的实际情况选择。 -以下主要介绍通用搜索引擎的信息。在特定场景下，以下方式可能会更加合理： +在特定场景下，以下方式可能会更加合理： - 使用包含网页搜索功能的大语言模型（例如 [Deepseek 联网搜索](https://chat.deepseek.com)）直接询问 - 使用特定领域的搜索引擎，例如： @@ -110,28 +113,30 @@ License: CC-BY-NC-SA 4.0 - 使用 [Debian Code Search](https://codesearch.debian.net/) 查找 Debian 上所有软件包的源代码，也可用 [GitHub](https://github.com) 搜索其存放的公开代码 - 部分站点或服务会拒绝通用搜索引擎索引，需要使用其手机 App 或合作方网站搜索（例如微信公众号、小红书等） -#### 搜索相关项目的手册/FAQ 等信息 {#search-docs} +#### 查阅项目文档 {#search-docs} -在某些场景下，直接搜索对应项目的帮助文档、手册、FAQ 等是比搜索报错信息更好的选择。例如，在使用 Python 的 `argparse` 模块遇到问题时，最好先查阅手册寻找答案： +在某些场景下，搜索对应项目的帮助文档、手册、FAQ 等是比直接搜索报错信息更好的选择。例如，在使用 Python 的 `argparse` 模块遇到问题时，最好先查阅手册寻找答案： ```text python argparse ``` -在搜索这类关键字时，合格的搜索引擎应该能将相关手册等关键信息优先显示。当然，日积月累，你也会对这些手册的位置有一个大致的了解。作为参考，以下列举了一些手册与文档信息： +在搜索这类关键字时，合格的搜索引擎应该能优先显示相关手册等关键信息。作为参考，以下是一些常用手册与文档信息： - Linux 命令：`man 需要查询的命令` - Arch Linux：[Arch Wiki](https://wiki.archlinux.org/) - Python：[Python 官方文档](https://docs.python.org/3/) - C 与 C++：[cppreference](https://en.cppreference.com/w/) +当然，日积月累，你也会对手册的位置有所了解。 + #### 使用合适的查询 {#use-proper-query} 最简单的几个技巧： -- 去掉「为什么」之类的副词与「的」等助词（尽管现代搜索引擎通常会忽略这些内容） +- 去掉「为什么」之类的副词与「的」等助词，搜索信息密度最高的名词和动词（虽然现代搜索引擎通常会帮你优化） - 使用空格分割关键词 -- 去掉不具备普遍性的内容：例如用户名、文件名、变量名等不会影响问题的信息 +- 去掉不具备普遍性的内容，例如用户名、文件名、变量名等不影响问题的信息 - 善于使用搜索引擎的特殊功能。大部分搜索引擎都支持下述功能： - 搜索运算符：用半角双引号 `"关键词"` 可精确匹配内容，`+关键词` 表示必须包含该词，`-关键词` 则表示排除该词。 @@ -141,7 +146,7 @@ python argparse - `site:` 标识符：例如输入 `site:example.com Something`，就能让搜索引擎只在 `example.com` 这个网站内搜索。 - 当工具出现错误代码时，直接搜索 `工具名称 错误代码` 比搜索错误提示更有效。 -- 使用英语：支持多语言的工具（比如上文的 `apt`）在互联网上往往是英文内容比中文多。如果中文结果无法解决问题，不妨试试将工具语言切换回英文。 +- 使用英语：支持多语言的工具（比如上文的 `apt`）往往有更多的英文结果。如果中文搜索无法解决问题，不妨试试将工具语言切换回英文。 以这个问题为例： @@ -154,42 +159,42 @@ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Pe W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied) ``` -首先判断最重要的信息，进行调整： +首先判断并保留最重要的信息： ```text 为什么我运行 apt update 会输出这个：E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) ``` -接下来可以用上述简单策略来处理查询： +接着用上述策略来简化查询： ```text apt update 输出 E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) ``` -（连「输出」这两个字甚至也可以不要） +（甚至「输出」这两个字也可以去掉） -直接贴到任何搜索引擎，无论是必应、谷歌还是百度，都能找到对应的解决方法。 +最后直接贴到任何搜索引擎，无论是必应、谷歌还是百度，都能返回对应的解决方法。 #### 筛选结果 {#filter-results} 部分搜索引擎会在结果中返回广告，可以在浏览器中安装去广告扩展（例如 uBlock Origin）来屏蔽这些内容。 -有一小部分网站（大多出于商业目的）会不加选择地收集垃圾内容，甚至想方设法欺骗搜索引擎，使其误判为有效信息。这些网站被称为「内容农场」。这些网站提供的信息对解决问题没什么帮助。有关内容农场的特征等信息，可以阅读这篇「少数派」的文章：[清理「内容农场」，还你清爽的 Google 中文搜索体验](https://sspai.com/post/69407)。 +有一小部分网站（大多出于商业目的）会不加选择地收集垃圾内容，甚至想方设法欺骗搜索引擎，使其误判为有效信息。这些网站被称为「内容农场」。这些网站提供的信息对解决问题没什么帮助。如果想了解内容农场的特征等信息，可以阅读这篇「少数派」的文章：[清理「内容农场」，还你清爽的 Google 中文搜索体验](https://sspai.com/post/69407)。 -对于搜索得到的结果，目前普遍不成文的认识是：一些网站的内容质量（例如 CSDN）相对更低，中文结果的平均质量也不如英文（很遗憾，这也是更推荐使用英文搜索的原因之一）。在读者逐渐熟练使用搜索引擎后，应该能对不同质量的结果有一个更清晰的判断。 +目前对搜索结果不成文但普遍的认识是：一些网站（例如 CSDN）的内容质量相对更低，中文结果的平均质量也不如英文（很遗憾，这也是更推荐使用英文搜索的原因之一）。在你逐渐熟练使用搜索引擎后，应该能对不同质量的结果有一个更清晰的判断。 -### 其他信息 {#other-info} +### 询问大语言模型 {#ask-llm} -自 2023 年初大语言模型（GPT 等）逐渐普及以来，询问大语言模型已成为解决问题的有效途径，而且比真人更有耐心。不过这同样需要技巧，请参考本文「[附录：如何正确向大语言模型提问](#llm)」。 +自 2023 年初大语言模型（GPT 等）逐渐普及以来，向大语言模型求助已成为解决问题的一种途径。与真人交流相比，你通常可以更反复、细致地追问。不过这同样需要技巧，请参考本文「[附录：如何正确向大语言模型提问](#llm)」。 ## 提问时的注意事项 {#when-asking} -### 避免 X-Y 型问题 {#avoid-xy} +### 提出原问题 {#avoid-xy} -X-Y 型问题指代这类情况： +提问时经常出现的一种情况是只询问自己设想的方案，却没有说明原始目标。例如： 1. 你遇到了 X 问题，你认为用 Y 方法可以解决 X 问题 -2. 但是你遇到了阻碍，因此向别人提问关于 Y 的问题，而不告诉其他人最原本的 X 问题 +2. 但是你遇到了阻碍，因此向别人提问关于 Y 的问题，而不告诉其他人最初的 X 问题 3. 如果用 Y 方法解决 X 问题的思路本身便是错误的，那么这样的提问也是无效的 以下摘录了陈皓先生在他的博客中介绍 X-Y 型问题（[Web Archive](https://web.archive.org/web/20240309145853/https://coolshell.cn/articles/10804.html)）时的例子： @@ -221,24 +226,26 @@ X-Y 型问题指代这类情况： A2: 用 rsync 啊，你妹！ ``` -- 我们补充另一个真实的例子（经过大幅简化）： +另一个我们遇到的真实例子（已大幅简化）： - ```text - Q: 有没有人在导入的时候遇到 TypeError: Can't create an SSLContext object without an ssl module? 的报错？ - A1: 你编译的时候没加 ssl 模块吗 - Q: 加了，我看了 csdn 上的教程 [截图] - A2: 你这教程怎么把源代码目录移动到 /usr/lib 下面啊，换个教程吧 - A3: 等等，为什么你要自己编译 python？你在用什么发行版？ - Q: Ubuntu 20.04，我没找到 python3 在哪里 - A3: 20.04 不是自带的 Python 3.8 吗？这个不够用吗？ - Q: 不是，我直接跑 python 出来的是 python2 - A2: 装 python-is-python3 - A3: 20.04 源里面也有 3.9，可以直接 install python3.9 - ``` +```text +Q: 有没有人在导入的时候遇到 TypeError: Can't create an SSLContext object without an ssl module? 的报错？ +A1: 你编译的时候没加 ssl 模块吗 +Q: 加了，我看了 csdn 上的教程 [截图] +A2: 你这教程怎么把源代码目录移动到 /usr/lib 下面啊，换个教程吧 +A3: 等等，为什么你要自己编译 python？你在用什么发行版？ +Q: Ubuntu 20.04，我没找到 python3 在哪里 +A3: 20.04 不是自带的 Python 3.8 吗？这个不够用吗？ +Q: 不是，我直接跑 python 出来的是 python2 +A2: 装 python-is-python3 +A3: 20.04 源里面也有 3.9，可以直接 install python3.9 +``` + +### 直接提问 {#ask-directly} -### 直接提问，避免使用「在吗」/「有人吗」 {#ask-directly} +不要先问「在吗」「有人吗」，也不要问「有没有人懂 XX」，直接把问题说出来即可。 -在私聊中，直接提问比先只问「在吗」更高效。考虑这个虚构的例子： +在私聊中，直接提问比先问一句「在吗」高效得多。考虑这个虚构的例子： ```text A (8:00): 在吗？ @@ -254,23 +261,21 @@ A (8:00): Hi，我遇到了 XXXXXXX 错误，然后 YYYY 命令跑不了，怎 B (13:00): 这样，你应该 ZZZZZZZ ``` -群聊中也是如此，只是出于礼貌的话，额外“握手”一次反而显得浪费时间。 +群聊中也是如此，出于礼貌额外「握手」一次反而浪费时间。 -### 避免「有没有人懂」 {#justask} - -不要在群聊里面这样问： +在群聊里先问领域，也是类似的情况： ```text 有没有人懂 C++？有个问题想问问 ``` -原因如下： +这样问的问题在于： - C++ 是非常复杂的，没有多少人真的懂/精通 C++。对很多别的领域也是类似的。 - 就算真的有人懂，懂的人很可能也不想在群里显摆自己。不太懂的人就更没有兴趣看你的问题了。 -- 这类问题往往属于常识范畴，不精通相关领域的人也可以回答。 +- 具体问题未必需要精通整个领域才能回答，这样问会降低获得解答的可能性。 -一个改善后相对好一些的提问是： +一个相对好一些的问题是： ```text 我遇到了一个问题，我的 C++ 程序需要运行一个 CUDA kernel，我要怎么写 cmake 来编译这个 kernel 并且让我的程序调用？ @@ -278,22 +283,14 @@ B (13:00): 这样，你应该 ZZZZZZZ 相关论述可参考 [不要问有没有人，请直接问](https://fars.ee/~justask.html)。 -### 尽可能提供「最小可复现样例」 {#mre} - -**最小可复现样例**（Minimal reproducible example，MRE）是一段**完整、精简**的程序代码或者执行流程，**不包含与错误无关的部分**。这通常只包含出现问题的核心几行代码、命令、以及最小依赖项。你可以复制当前的工程，通过二分法逐步删除无关部分，并保留原有错误来制作 MRE。和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。 - -不妨换个角度思考：当提问者只提供一段冗长代码，包含大量第三方库和自定义结构体、类方法时，缺少这些关键信息会让回答者无从下手。提问者若直接提供全部代码，恐怕很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。 - -> MRE 的提供能平衡提问者和回答者的时间，虽然需要提问者花费更多准备时间和一定技巧，但有助于准确定位问题。 - -### 提供必要的问题描述与相关信息 {#provide-necessary-info} +### 提供必要的信息 {#provide-necessary-info} 需要说明的内容包括： - 具体问题是什么 - 引发问题的命令/代码 -- 报错信息（注：如上文所述，通常只有前几条报错信息是关键的，建议先从前面的有效报错开始提问） -- 自己尝试过用什么方法解决 +- 报错信息（如上文所述，通常只有前几条报错信息较为关键，可以从这些信息开始提问） +- 尝试过的解决方法 - 系统与软件的版本信息（例如，如果你想在一个主要讨论 Linux 的群里面问 Windows 下的问题，务必把这一点说清楚） 这是一个在 Linux 讨论群里的反例： @@ -316,7 +313,7 @@ A2: 要用 curl.exe 调用才行 如果提问者在一开始就说清楚自己在 Windows 下，那么这个问题可能会更快得到解决。 -报告错误时请直接提供原始输出，不要自行翻译。建议在开发者的语言（通常是英语）环境下复现错误，获得更准确的提示信息，帮助其他人定位你的问题。建议将错误信息复制后发送，而不是自己手动对着敲一遍；如果原文内容过长，可以参考下一节内容来使用 Pastebin 等工具分享完整文本。 +报告错误时请直接提供原始输出，不要自行翻译。建议在开发者的语言（通常是英语）环境下复现错误，这样提示信息更准确，也方便其他人定位问题；最好直接复制错误信息，而不是对着日志手动敲一遍；如果内容太长，可以参考[用合适的方式分享信息](#share-info)。 在 Linux 系统中，可以使用以下方法设置程序运行的语言： @@ -327,64 +324,207 @@ LC_ALL=en_US.UTF-8 你的命令 LC_ALL=zh_CN.UTF-8 你的命令 ``` -### 使用代码片段服务分享问题相关的代码与报错 {#use-pastebin} +再看一个信息不足的反例： -代码和报错信息如果太长，直接截图或贴到群聊里可能不太合适： +```text +我的 vulkan 程序在 wayland 下没有显示出来，托盘那里有程序的图标，怎么回事？ +``` -- 截图里的代码不方便他人直接使用，既难以 OCR 识别，也没人愿意手动转录。 -- 较长的信息直接发送会影响他人阅读前面内容，也不够美观（尤其在不支持代码块的 QQ、微信等聊天软件中） -- 某些聊天软件会把特殊字符自动转换成表情符号，使得文本难以阅读 +这个例子的问题在于： -虽然聊天等场景支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。部分网站提供了存储长文本的功能（注意一些网站可能无法直接访问）： +- 没有提供任何代码，要知道 Vulkan 画个三角形都要写一千多行代码 +- 环境信息不够详细：比如 Wayland 主要依赖混成器实现，建议说明具体使用的桌面环境，如 KDE；Vulkan 作为图形接口较为宽泛，最好补充相关图形库信息，例如是否使用了 GLFW 绘制窗口。 -- GitHub 对应 [GitHub Gist](https://gist.github.com/) -- GitLab 对应其 [Snippets](https://gitlab.com/dashboard/snippets) 功能 -- 独立的 Pastebin 类服务，例如 [Ubuntu pastebin](https://paste.ubuntu.com/)，[Pastebin.com](http://Pastebin.com) 等 +#### 提供「最小可复现样例」 {#mre} -科大校内的同学可以使用校内 GitLab（[超算中心](https://git.ustc.edu.cn/) 或 [LUG](https://git.lug.ustc.edu.cn/)）的 Snippets。 +**最小可复现样例**（Minimal reproducible example，MRE）是一段**完整、精简**的程序代码或者执行流程，**不包含与错误无关的部分**。这通常只包含出现问题的核心几行代码、命令、以及最小依赖项。你可以复制当前的工程，通过二分法逐步删除无关部分，并保留原有错误来制作 MRE。和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。 -一个反例是： +不妨换个角度思考：如果提问者提供的代码依赖第三方库、自定义结构体或类方法，却没有提供依赖信息和相关定义，回答者就很难复现问题。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。 -```text -我的 vulkan 程序在 wayland 下没有显示出来，托盘那里有程序的图标，怎么回事？ -``` +> 提供 MRE 能平衡提问者和回答者的时间。制作 MRE 虽然需要一些技巧和时间，但有助于准确定位问题。 -这个问题的反例原因在于： +### 用合适的方式分享信息 {#share-info} -- 没有提供任何代码，要知道 Vulkan 画个三角形都要写一千多行代码 -- 环境信息不够详细：比如 Wayland 主要依赖混成器实现，建议说明具体使用的桌面环境，如 KDE；Vulkan 作为图形接口较为宽泛，最好补充相关图形库信息，例如是否使用了 GLFW 绘制窗口。 +代码和报错信息如果太长，直接截图或者贴到群聊里可能不太合适： + +- 截图既难以用 OCR 识别，也没人愿意手动转录，不方便他人直接使用 +- 直接发送较长的信息会影响他人浏览之前的内容，也不便阅读（尤其在不支持代码块的 QQ、微信等聊天软件中） +- 某些聊天软件会把特殊字符自动转换成表情符号，使得文本更难以阅读 -### 避免拍屏 {#use-screenshots} +#### 使用在线剪贴板 {#use-pastebin} + +虽然聊天软件一般都支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。此时可以使用在线剪贴板（也叫 Pastebin，一些网站可能无法直接访问）： + +- GitHub 对应 [GitHub Gist](https://gist.github.com/) +- GitLab 对应其 [Snippets](https://gitlab.com/dashboard/snippets) 功能 +- 独立的 Pastebin 类服务，例如 [Ubuntu pastebin](https://paste.ubuntu.com/)（已结束服务），[Pastebin.com](https://pastebin.com/) 等 + +科大校内的同学可以使用校内 [GitLab](https://git.ustc.edu.cn/) 的 Snippets。 + +#### 避免拍屏 {#use-screenshots} 除非实在无法截图（例如系统启动阶段），否则不要拍屏，因为： -- 不美观 - 因为[莫尔纹](https://en.wikipedia.org/wiki/Moir%C3%A9_pattern)现象，字/图像可能会拍不清楚 - 其他人可能得歪着头才能看清内容 - 不利于其他人搜索类似问题 +- 不美观 -## 无人应答 {#if-no-answer} +## 其他咨询方式 {#if-no-answer} -没人回答问题不等于被无视。在群聊中，认真提问却无人回应，往往只是因为看到问题的人都不知道答案罢了。也要注意，群聊或论坛里的陌生人并没有义务回答你的问题。 +没人回答不等于问题被无视。在群聊中认真提问却无人回应，往往只是因为看到问题的人都不知道答案罢了。其次，群聊或论坛里的陌生人并没有义务回答你的问题。 -可以考虑从以下一些方式解决问题： +可以尝试通过以下方式求助： - 线下咨询。 - - Tip: [LUG 在西区与高新区的活动室](/wiki/lug/contact/#%E9%9D%A2%E5%AF%B9%E9%9D%A2%E4%BA%A4%E6%B5%81)，只要房间里有人就可以进来，来之前建议先在群里问一下 + - 见 [LUG 在西区与高新区的活动室](/wiki/lug/contact/#%E9%9D%A2%E5%AF%B9%E9%9D%A2%E4%BA%A4%E6%B5%81)，来之前建议先在群里问一下，只要房间里有人就可以进 - 向对应服务/软件的维护人员提交工单 - - Tip: 科大网络信息中心报修系统 + - 见科大网络信息中心报修系统 -## 附录：如何正确向大语言模型提问 {#llm} +## 附录：给回答者的建议 {#for-answerers} + +有效的回答由提问者和回答者共同完成，问题没有得到解决也未必都是提问者的责任。我们见过不少讨论变成了单方面的嘲讽或者相互争吵，也见过回答者甩下一个「提问的智慧」的链接就草草了事。 + +提问者很多时候是新手，不确定哪些信息是重要的，也可能不熟悉相关的术语；回答者同样可能误解提问者的意思，或者把个人的经历与习惯当作普遍结论。当然，回答者**不需要、也没有义务回答每个问题，在没有头绪的时候完全可以保持沉默**。但如果决定参与讨论，那么不妨实际推进问题的解决，而不是去审判提问者有没有资格提问。 + +好的回答不一定能立刻解决问题：澄清目标、给出可靠的依据、指出下一步，并且尊重提问者的合理选择，就已经能显著降低解决问题的难度。 + +### 尊重提问者 {#respect-questioners} + +绝大部分提问者不是来找茬的，也不是故意来浪费其他人的时间的。他们可能因为缺乏经验漏掉一些重要的信息，或者提出一些看起来无厘头的需求。**除非对方之前已经多次不提供足够信息、随意提问，否则请不要在一开始就假设对方的提问有问题**；即使如此，也建议直接不再回答，或者明确指出缺少哪些信息，而不是做没有建设性的回复。 + +作为对照： + +- 避免：「你连这个都不知道吗？」 + + 建议：「这里 A 和 B 可能会混淆，你用的是哪一种？」 + +- 避免：「看你这个问法，你根本不懂什么叫 XX。」 + + 建议：「我们对 XX 的定义可能不同，你更关心的是 XXXXX 还是 YYYYY？」 + +**应当避免的说法都在评价提问者本人，而不是在解决问题**，这样只会让交流气氛更加紧张。如果不愿继续投入时间，直接礼貌退出讨论即可。 + +群聊里也常出现拿问题开玩笑的情况。熟人之间的玩笑不一定带有恶意，但在问题尚未解决时，多人接连玩梗，提问者收到的其实是「你的需求很可笑」这种极不友好的信息： + +> Q: 怎样关闭某个桌面功能？ +> +> ………… +> +> A: 那建议卸载系统哦。 +> +> B: 卸载桌面也可以。 +> +> C: 干脆不要用图形界面。 + +**请不要对提问者开这种玩笑。** + +### 友好沟通、推进目标解决 {#friendly-to-goal} + +可以从三个方面理解一个问题：目标、已有方案，以及约束条件与偏好。这些信息起初往往并不明确，需要双方在交流中逐步澄清，排除不符合要求的方案。 + +询问提问者「为什么要做这件事」，可以发现潜在的 [X-Y 型问题](#avoid-xy)。例如： + +> Q: 我准备把某个 Linux 发行版作为工作环境，应该选择稳定版还是测试版？ +> +> A: 你主要需要用它完成什么工作？ +> +> Q: 我的工作依赖一款没有 Linux 版本的专业软件，本来准备通过兼容层运行。 -### 请先阅读正文内容，再阅读本部分 {#read-main-content-first} +到这里，实际的问题就不再是单纯的「稳定版和测试版哪个更好」，而是在「可靠完成工作」的约束下比较两者；脱离这个背景继续讨论软件包新旧，就不太妥当了。 -对人类有效的提问策略，大多对大语言模型（LLM）也有效。 +不过，问「为什么」也很容易滑向要求提问者「自证需求合理」，在提问者的偏好与你不同时尤其如此： + +> Q: 选择文本时会自动进入剪贴板，请问怎样关闭？ +> +> A: 它造成了什么问题？ +> +> Q: 这不符合我的使用习惯，我只想关闭它。 +> +> A: 我觉得这个功能很方便。为什么要关闭？ + +最后一句只是在质疑提问者的偏好：「某功能对某些人有用」并不能代替关闭它的方法。如果问题涉及提问者可能不了解的概念，比起在群里追问，或者要求对方读完一大篇 wiki 再来描述需求，给出链接加一句简单的说明通常更有效： + +> A: 这里其实有「鼠标选区」和普通剪贴板两套机制，可以先看看 ，你的意思是要关掉 PRIMARY 这个剪贴板，还是说选中的内容进入了 CLIPBOARD 这个剪贴板？ + +{% capture notice-url-frag %} +许多文档类站点在点击标题，或者标题旁边的标记（一般称为 anchor）的时候，都会在浏览器显示的 URL 后添加类似 `#some-thing` 的内容，这被称为「片段标识符」（Fragment Identifier）。**推荐在分享的 URL 中添加片段标识符，这样点击链接的人就能立刻跳到你希望他阅读的地方。** + +此外，Firefox、Chrome 等浏览器也都支持复制指向当前选中的文本的链接的功能，会在 URL 后添加类似 `#:~:text=xxxx` 的内容，支持的浏览器可以直接跳转到你选中的内容。 +{% endcapture %} + +
{{ notice-url-frag | markdownify }}
+ +**有用的回答需要让讨论向前推进。** 一种常见的问题是只讨论个人经历，却不说明它和当前问题有什么关系，比如「这不是挺方便吗」「别搞了」「我用了很多年，你参考不了」。相比之下，这样的回答是有效的： + +- 解决方法是…… +- 先看一下 XXX 的输出（来区分原因） +- 你的 XXX 软件版本是？（补充信息） +- 官方文档：…… +- 可以试一下 XXX 来验证是否正确 +- 如果 XXX 不可以的话，那么就试一下 YYY 替代方案 +- 我不知道，但是可以去 XXX 问一下 + +### 检查自己的误区 {#check-your-assumptions} + +回答者的经验既是优势，也可能是误区：**把经验和推测当作事实**，以及**默认提问者能像自己一样处理后果**。 + +第一种误区： + +> A: Linux 肯定不支持你这个软件啊！ +> +> Q: 啊？wine 呢？ +> +> A: 别想了，肯定不支持。 +> +> Q: 我以为 wine 能跑呢。 +> +> A: 我有几年没试过了，不过我不抱希望。 + +这里的问题在于没有**区分「事实」、「经验」和「推测」**。一种更好的回答： + +> A: 这个软件没有官方 Linux 支持，wine 上面前几年我没跑成功。即使目前可以跑，我也不建议拿它来正式做工作，有可能会有数据问题。 + +如果没有把握，退出讨论也是一种选择：承认自己不知道，通常比给出绝对结论更可靠。即使对答案没有把握，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。 + +第二种误区常出现在讨论风险的时候。对提问者来说，重要的不是回答者有多少年资历，而是哪些问题可能发生、如何发现，以及发生之后需要怎么处理： + +> 避免：我用了很多年，这些问题我都能处理，你参考不了。 +> +> 建议：我能接受使用测试版，是因为我能解决依赖冲突，也知道如何进入救援环境回退。如果你还不熟悉这些操作，可以先考虑：升级后一旦无法进入桌面或者用不了工作软件，你能否处理？ + +提问者有时候会想做一些危险的事情，此时同样需要说清楚风险在哪里、怎样安全地验证（如果可以），以及回退的方案： + +> 避免：不支持。如果和同事做出来的东西不一样，出了问题别来找我们。 +> +> 建议：即使能够通过兼容层启动，有些地方也可能存在兼容问题。如果需要正式交付，不建议在未经验证的情况下把它作为唯一环境。你可以保留原系统，先测试常用情况的导出结果是否正确，之后再决定哪些工作可以迁移。 + +### 不要直接复制粘贴大语言模型的回答 {#no-copy-paste-llm-answer} + +大语言模型是非常方便的工具，很多时候也是回答问题的高手。不过这不等于在其他人提问时，回答者可以直接复制粘贴大语言模型的回答给对方，考虑以下几点原因： + +- 如果只是把提问者的问题复制、粘贴给大语言模型，然后再把模型的回答复制、粘贴给对方，那么对方为什么不亲自去问大语言模型呢？ +- 大语言模型的回答很多时候比较冗长，并且风格很可能显得生硬（比如说被一些大语言模型滥用，经常被吐槽的「不是……而是……」），反而不便于阅读和理解。 +- 回答者不做核验的话，辨别模型是否产生幻觉（提供错误回答）的责任就不合理地转移到了其他人身上。 + +如果回答者核对确认了大语言模型的回答，并且明确标注来源，那么引用关键的一小部分一般来说是可以接受的，例如这样： + +> 我把你的问题问了 LLM，它说可能的原因是：XXXXXXXXX。我测试了对应的命令，看起来是可以使用的。 + +## 附录：如何正确向大语言模型提问 {#llm} + +对人类有效的提问策略，大多对大语言模型（LLM）也有效，因此建议先阅读本文的正文部分，再阅读这一节。 ### 提供足够的上下文信息 {#provide-context} -和向人类提问类似，提供足够的上下文信息可以更好帮助大语言模型理解问题，给出更好的回答。以刚才的例子为例。 +大语言模型只能看到你给出的信息，因此上下文是否充分，很大程度上决定了回答的质量。 -原始例子： +#### 对话式大语言模型 {#chatbot-context} + +向对话式大语言模型提问时，和向人类提问类似，也需要提供足够的上下文，帮助它理解问题。下面沿用前文在命令行中下载文件的例子。 + +
+查看原始提问与大语言模型的完整回答 ````text Human: 怎么在命令行里面下载一个 url？ @@ -466,6 +606,8 @@ sudo apt install wget 如果你告诉我你是用 Windows / Linux / macOS，我可以给你更具体的命令。 ```` +
+ 改进后的例子： ````text @@ -484,17 +626,65 @@ Invoke-WebRequest -Uri "https://example.com/file.zip" -OutFile "file.zip" - 环境是 Windows PowerShell - 希望 LLM 直接输出命令 -得到的结果就更加简洁，也更加符合用户需求，毕竟很多 Windows 用户的电脑里可能根本没有 wget 或 curl。 +得到的结果就更加简洁，也更加符合用户需求。 + +#### Agent {#agent-context} + +从 2025 年开始，以编程 Agent 为代表的 Agent 软件开始广泛应用（包括但不限于 Claude Code、Codex 等）。Agent 与传统的对话式大语言模型不同，它可以利用工具调用在你的电脑上读取和修改文件、执行命令、搜索信息等。当 Agent 在出现问题的环境中运行时，很多时候它能够自行获取到需要的上下文信息，但是它无法直接获取的信息，仍需要你补充（例如修改的目标、无法直接获取的环境信息等等）。 ### 提问语言 {#ask-language} -在大语言模型的训练语料中往往英文占比更高，因此用英文提问可能效果更好。国产的大语言模型可能可以缓解这个问题。 +在大语言模型发展的早期，使用英文提问相比中文可能会有更好的效果。不过，当前主流模型的中文能力已经足以处理大多数日常技术问题。因此目前的建议是： + +- 优先使用能够准确、流畅表达问题的语言。对本文读者来说一般是中文。 +- 错误信息、命令、专有名词等应保留原文，不要自行翻译。 + +根据模型分词器（Tokenizer）的不同，在表达相同的含义时，不同模型处理中文与英文的效率也不同。如果有降低使用成本的需求，需要自行测试。 ### 避免超长的对话 {#avoid-long-dialog} -大语言模型的工作模式很简单：每次用户发送消息时，LLM 都会从头分析内容，直到用户本次信息结束才开始生成。这带来了两个问题： +大语言模型在对话时，先前的消息通常仍会作为上下文提供给模型。目前模型服务商不少都配置了**缓存**，在对话追加内容时，前面的内容如果命中了缓存，就能大幅减小计算量，节约成本（具体机制取决于使用的产品）；如果没有命中的话，先前的消息就需要重新计算。不过仍然需要注意： -- 对于超长的对话，每一次继续对话都会浪费不少的钱。假设当前的对话前，LLM 分析了一个很长的网页，花费了一块钱，那么基于这段对话作为背景，**每次**发送一条消息，都会再花至少一块钱。 -- 相比于短文本，LLM 对长文本更容易产生「**幻觉**」，即输出与实际情况不相符的内容。 +- 大语言模型的上下文长度是有限制的。当内容量接近上下文长度上限时，服务可能停止接受新消息、丢弃较早的内容，或压缩已有内容后继续对话，具体取决于实现。如果重要的内容在这个过程中丢失，模型的表现可能会受到很大的影响。 +- 相比于短文本，LLM 对长文本更容易产生「**幻觉**」，即输出与实际情况不相符的内容。特别是在上下文中出现无关、过时、或者相互矛盾的信息时，这种现象会更加严重。 如果发现 LLM 工作异常，可以重启会话。重新开始后，更应该调整提问的策略。 + +### 核验回答 {#verify-answer} + +由于幻觉问题的存在，大语言模型可能会以自信的语气给出详细但错误的回答。如果不了解对应的领域，而贸然使用 LLM 的回答，就可能轻则浪费时间，重则带来严重的麻烦。对新手来说，我们有一些建议： + +- 根据环境的不同，LLM 可能无法访问互联网、了解最新信息。在提问前需要先确认。 +- 在提问时，明确要求 LLM 提供可以用于核验回答的来源信息。 +- 对代码类问题，可以根据 LLM 的建议制作 [MRE](#mre)，来验证结论的可靠性。 +- 对于可能导致数据丢失、设备损坏甚至人身伤害的操作，务必不要将 LLM 的回答作为唯一参考。 + +### 隐私问题 {#llm-privacy} + +使用大语言模型，特别是 Agent 的时候，如果正在处理非公开的信息，那么就需要尤其注意隐私问题。不同的大语言模型服务商有不同的隐私策略，在一些情况下可能会留存用户提供的信息用于训练新的模型，或者改进产品。你大概不会把自己的秘密告诉陌生人，但是在向大语言模型提问的时候，可能会不知不觉泄露相关的信息。因此，在提问的时候需要注意： + +- 使用大语言模型前，确认服务商的隐私策略、服务条款等内容。 +- 谨慎使用「中转站」类大模型服务，此类服务商可能会存储对话数据并出售给其他人。 +- 不要直接向模型提供密码、Cookie、私钥等敏感数据。 +- 可能包含个人信息的日志，以及未公开的代码等在提问时需要小心处理。 +- 在网页端删除对话不代表对应的信息就从服务商的服务器上立刻删除了。 + +如果对隐私问题极度敏感，那么可能必须要本地自建大模型服务，使用完全本地运行的工具处理信息。相关内容超出了本文的范畴。 + +### 小心执行大语言模型生成的命令 {#llm-command-security} + +大语言模型很多时候能给出可以运行的命令，并且看起来能够解决问题。但是这些命令不一定是安全的，也不一定是最佳的选择。例如在[上文](#chatbot-context)的例子里面，LLM 提供了跳过证书检查的命令： + +````text +如果是需要跳过 SSL 检查的网站，可以加上 `-k`： + +```bash +curl -k -O https://example.com/filename.zip +``` +```` + +但是这是不恰当的——用户的提问中并不包含 SSL 检查失败的场景，并且 LLM 也完全没有说明对应的风险（恶意的中间人可以将下载下来的文件替换为自己的）。尽管这条命令确实能跑，而且「大部分时候」都能用，但是能用不代表是正确的选择。 + +在一些更恶劣的情况下，执行 LLM 的命令会导致数据丢失。例如在[这个知乎问题中](https://www.zhihu.com/question/1974854700256944776)，LLM 生成的命令就意外删除了 800G 的数据。 + +因此，在执行 LLM 的命令之前，需要理解命令实际的功能。对 Agent 来说，不同 Agent 软件的隔离、命令批准等机制不同，即使命令没有出现批准提示，也不代表对应的命令绝对安全。在使用 Agent 前，需要确认 Agent 下 LLM 能够访问的数据范围，并在使用时检查其实际的修改操作，做到心中有数。