From 90246cf1edf2c1a718f54122663df17aaa59a2fb Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Sat, 29 Aug 2026 06:52:30 +0800
Subject: [PATCH 01/17] howtoask: Update #llm for 2026

---
 pages/_wiki/doc/howtoask.md | 61 +++++++++++++++++++++++++++++++++----
 1 file changed, 55 insertions(+), 6 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 25764dd9d7..cca2420384 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -382,7 +382,9 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 ### 提供足够的上下文信息 {#provide-context}
 
-和向人类提问类似，提供足够的上下文信息可以更好帮助大语言模型理解问题，给出更好的回答。以刚才的例子为例。
+#### 对话式大语言模型 {#chatbot-context}
+
+对传统的对话式大语言模型服务来说，和向人类提问类似，提供足够的上下文信息可以更好帮助大语言模型理解问题，给出更好的回答。以刚才的例子为例。
 
 原始例子：
 
@@ -484,17 +486,64 @@ 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 能够访问的数据范围，并在使用时检查其实际的修改操作，做到心中有数。

From 8c40226a1f6cfc2871191736e50587d961189189 Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Sat, 29 Aug 2026 08:22:22 +0800
Subject: [PATCH 02/17] howtoask: Add #for-answerers

---
 pages/_wiki/doc/howtoask.md | 147 ++++++++++++++++++++++++++++++++++++
 1 file changed, 147 insertions(+)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index cca2420384..479f1f1231 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -374,6 +374,153 @@ LC_ALL=zh_CN.UTF-8 你的命令
 - 向对应服务/软件的维护人员提交工单
   - Tip: 科大网络信息中心报修系统 <https://baoxiu.ustc.edu.cn/>
 
+## 附录：给回答者的建议 {#for-answerers}
+
+本文主要部分是给提问者阅读的，但是实际上，有效的回答是由提问者与回答者共同贡献的。有时候，问题没有妥善解决并非完全是提问者的问题。我们见到过很多回答者缺少耐心，让一些本可以友好、妥善解决的问题变成单方面的嘲讽，或者是互相争吵。我们也见到过很多回答者直接贴一个「提问的智慧」的链接（他们本人可能都没有完整阅读过！），就草草了事。
+
+提问者很多时候是新手，他们不确定有哪些东西是重要的、需要提供的，也可能不熟悉对应的术语；回答者也有可能会误解提问者的发言，或者把自己的经历与习惯当作普遍的结论。当然，这里的回答者不是扮演大学课程的助教的角色，**不需要、也没有义务回答每个问题，在没有头绪的时候也完全可以保持沉默**。不过，如果决定参与对问题的讨论的话，那么不妨实际推进问题的解决，而不是去审判提问者有没有资格、是不是老资历、个人偏好是否与你一致吧。
+
+以下介绍的内容，简单来讲遵守这样的原则：
+
+1. 好的回答不一定是立刻解决问题的回答。
+2. 能够澄清目标、提供可靠依据、指出下一步，并尊重提问者合理的选择，就已经能显著降低解决问题的难度。
+
+### 假定善意 {#good-faith}
+
+在绝大部分时候，提问者不是来找茬的，也不是来故意来浪费其他人的时间的。他们可能因为缺乏经验，在提问时会漏掉一些重要的信息，或者提出一些看起来无厘头的需求。**除非对方在之前已经有过多次不提供足够信息、随意提问的记录，否则请不要在一开始就假设对方提问存在问题**。
+
+作为对照：
+
+- 避免：「你连这个都不知道吗？」
+
+  建议：「这里 A 和 B 可能会混淆，你用的是哪一种？」
+
+- 避免：「看你这个问法，你根本不懂什么叫 XX。」
+
+  建议：「我们对 XX 的定义可能不同，你更关心的是 XXXXX 还是 YYYYY？」
+
+**这里避免的两个例子事实上都是在评价提问者本人，而不是在解决问题**。这样做只会让交流气氛更加紧张。如果不愿继续投入时间，直接礼貌退出讨论即可。
+
+### 正确地问「为什么」 {#ask-why-correctly}
+
+有时候你会发现无法理解提问者为什么要做他想要做的事情，这很正常。询问提问者为什么要做某件事，可以发现潜在的 [X-Y 型问题](#avoid-xy)，帮助回答者提供恰当有效的方案。但是回答者很容易掉入「要求提问者自证合理」的陷阱中而不自知，在讨论气氛被破坏之后可能也无法意识到自己的问题。
+
+有些情况下，提问者会提问两种方案的好坏，但是没有提供最终的目标，例如这样：
+
+> Q: 我准备把某个 Linux 发行版作为工作环境，应该选择稳定版还是测试版？
+
+后续的提问可能会是这样子：
+
+> A: 你主要需要用它完成什么工作？
+>
+> Q: 我的工作依赖一款没有 Linux 版本的专业软件，本来准备通过兼容层运行。
+
+从这里开始，实际的问题就不再是单纯的「稳定版和测试版哪个更好」，而是在「可靠完成工作」的约束下比较两者。通过后续的确认，可以进一步缩小范围，给出合理的结果。相反，如果脱离这个背景，继续讨论软件包新旧与否，就不是很妥当了。
+
+另一种情况是，提问者想做的事情和你的偏好完全不同，例如这个反例：
+
+> Q: 选择文本时会自动进入剪贴板，请问怎样关闭？
+>
+> A: 它造成了什么问题？
+>
+> Q: 这不符合我的使用习惯，我只想关闭它。
+>
+> A: 我觉得这个功能很方便。为什么要关闭？
+
+这里最后的对偏好的质疑对回答问题没有帮助——这可能解释了为什么对应的功能会存在，但是无法代替具体的关闭方法。一种可能更好的回答如下：
+
+> A: 这里可能涉及普通剪贴板、鼠标选区和剪贴板管理器。你是希望选择的内容完全不进入选区的剪贴板，还是希望剪贴板管理器不要把选区剪贴板同步到普通剪贴板上面？
+
+### 目标、方案与偏好 {#goal-method-pref}
+
+对一个问题的讨论可以分为三个部分，以上面的例子为例：
+
+- 提问者最终的目标，例如在 Linux 上完成某种正式工作，或者在选择文字时不要进入普通剪贴板。
+- 提问者考虑的方案，例如使用 Wine 运行专业软件，或者在桌面配置的某个地方关闭相关的设置。
+- 提问者的约束条件与偏好，例如文件必须可靠存储，与其他同事的方案兼容（约束条件），或者是单纯不喜欢某个功能（偏好）。
+
+所以对给出的问题，合适的回答思路：
+
+- 对第一个案例，首先验证提问者给出的方案是否能够满足正式工作。
+  - 对已有方案的质疑是 OK 的（「Wine 未必适合运行你的专业软件」）。但是不要替提问者修改目标（避免「你不应该用这个专业软件」）。
+- 对第二个案例，帮助定位到对应的配置项。而不是「这个功能很方便。为什么要关闭？」
+
+### 明确结论的依据 {#answer-with-bound}
+
+对下面这个例子：
+
+> A: Linux 肯定不支持你这个软件啊！
+>
+> Q: 啊？wine 呢？
+>
+> A: 别想了，肯定不支持。
+>
+> Q: 我以为 wine 能跑呢。
+>
+> A: 我有几年没试过了，不过我不抱希望。
+
+这里显著的矛盾就在于，回答者没有恰当**区分「事实」、「经验」和「推测」**。一种更好的回答：
+
+> A: 这个软件没有官方 Linux 支持，wine 上面前几年我没跑成功，即使目前可以跑，我也不建议拿它来正式做工作，有可能会有数据问题。
+
+如果无法肯定回答，那么退出也是一种选择。回答者不需要，也不可能知道所有问题的答案。承认自己不知道，通常比给出绝对结论更可靠。即使不能肯定回答，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。
+
+### 讨论方案的风险 {#risk}
+
+提问者有时候会想做一些危险的事情，此时回答者需要明确指出风险，并且让提问者知道风险在哪里、怎么安全验证（如果可以），以及回退的方案。一个指出风险，但是不够好的回答可能会是这样：
+
+> A: 不支持。如果和同事做出来的东西不一样，出了问题别来找我们。
+
+更好的参考回答：
+
+> A: 即使能够通过兼容层启动，有些地方也可能存在兼容问题。如果需要正式交付，不建议在未经验证的情况下把它作为唯一环境。你可以保留原系统，先测试常用情况的导出结果是否正确，之后再决定哪些工作可以迁移。
+
+### 推进下一步 {#next-step}
+
+有用的回答需要能够让讨论向前推进。一种常见的问题是只讨论个人经历，但是不说明自己的经历和当前问题有什么对应关系。没有意义的回答类似这样：
+
+- 这不是挺方便吗？
+- 别搞了
+- 我用了很多年，你参考不了。
+
+有效的回答类似于这样：
+
+- 解决方法是……
+- 先看一下 XXX 的输出（来区分原因）
+- 你的 XXX 软件版本是？（补充信息）
+- 官方文档：……
+- 可以试一下 XXX 来验证是否正确
+- 如果 XXX 不可以的话，那么就试一下 YYY 替代方案
+- 我不知道，但是可以去 XXX 问一下
+
+### 不要用资历代替解释 {#experience-is-not-explanation}
+
+经验可以帮助回答者识别风险，但是经验不是结论。对提问者来说，重要的不是回答者有多少年的资历，而是哪些问题可能发生、如何发现，以及发生后需要怎么处理。
+
+避免下面的回答：
+
+> A: 我用了很多年，这些问题我都能处理，你参考不了。
+
+建议的回答：
+
+> A: 我能接受使用测试版，是因为我可以处理依赖冲突、进入救援环境回退之类的操作。如果你暂时不熟悉这些操作，可以评估一下如果升级后暂时无法进入桌面或使用你的专业软件的话是否能接受。
+
+### 关于群聊与玩笑 {#group-joke}
+
+尽管熟人之间的玩笑不一定带有恶意，但在提问者的问题尚未解决时，多人围绕问题开玩笑的话，绝大部分情况下没有正面的作用。像下面这个有点恶劣的例子：
+
+> Q: 怎样关闭某个桌面功能？
+>
+> …………
+>
+> A: 那建议卸载系统哦。
+>
+> B: 卸载桌面也可以。
+>
+> C: 干脆不要用图形界面。
+
+当这些话连续出现的时候，提问者收到的其实是「你的需求很可笑」这种极度不友好的信息。这对解决问题没有帮助，反而会激化矛盾。
+
 ## 附录：如何正确向大语言模型提问 {#llm}
 
 ### 请先阅读正文内容，再阅读本部分 {#read-main-content-first}

From ca2cec85aaf19cdcfce0ee267b5f895f8793d33b Mon Sep 17 00:00:00 2001
From: Catoverflow <55503205+Catoverflow@users.noreply.github.com>
Date: Thu, 3 Sep 2026 00:31:45 -0500
Subject: [PATCH 03/17] fix gramma errors, rephrase sentences, simplify
 expressions

---
 pages/_wiki/doc/howtoask.md | 48 +++++++++++++++++++------------------
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 479f1f1231..3cfd77a98f 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}
 
-多数错误伴随着错误信息（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,7 +45,7 @@ License: CC-BY-NC-SA 4.0
   user@hostname:~/桌面$
   ```
 
-  可以看到，这里的输出已经给出很清晰的建议了，需要执行一下 `apt-get update` 命令。把这样的错误信息截图发到群里，也许是一件不太负责的事情。
+  可以看到，这里的日志已经给出很清晰的建议了，需要执行一下 `apt-get update` 命令。如果你没有仔细阅读就把这样的错误信息截图发到群里，那很坏了。
 
 - 例 2：为什么我装不了 `pytorch`
 
@@ -83,7 +83,7 @@ License: CC-BY-NC-SA 4.0
 
   错误提示显示异常（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
@@ -99,9 +99,9 @@ License: CC-BY-NC-SA 4.0
 
 #### 选择搜索引擎 {#choose-search-engine}
 
-作为业界不成文的「共识」，对常用搜索引擎的排序是：谷歌 > 必应国际版 > 必应国内版 > 百度。可以都试试，根据自己的实际情况选择。
+对于通用搜索引擎，业界不成文的「共识」是：谷歌 > 必应国际版 > 必应国内版 > 百度。可以都尝试一遍再根据自己的实际情况选择。
 
-以下主要介绍通用搜索引擎的信息。在特定场景下，以下方式可能会更加合理：
+在特定场景下，以下方式可能会更加合理：
 
 - 使用包含网页搜索功能的大语言模型（例如 [Deepseek 联网搜索](https://chat.deepseek.com)）直接询问
 - 使用特定领域的搜索引擎，例如：
@@ -112,26 +112,28 @@ License: CC-BY-NC-SA 4.0
 
 #### 搜索相关项目的手册/FAQ 等信息 {#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 +143,7 @@ python argparse
   - `site:` 标识符：例如输入 `site:example.com Something`，就能让搜索引擎只在 `example.com` 这个网站内搜索。
 
 - 当工具出现错误代码时，直接搜索 `工具名称 错误代码` 比搜索错误提示更有效。
-- 使用英语：支持多语言的工具（比如上文的 `apt`）在互联网上往往是英文内容比中文多。如果中文结果无法解决问题，不妨试试将工具语言切换回英文。
+- 使用英语：支持多语言的工具（比如上文的 `apt`）往往有更多的英文结果。如果中文搜索无法解决问题，不妨试试将工具语言切换回英文。
 
 以这个问题为例：
 
@@ -154,13 +156,13 @@ 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)
@@ -168,15 +170,15 @@ apt update 输出 E: Could not open lock file /var/lib/apt/lists/lock - open (13
 
 （连「输出」这两个字甚至也可以不要）
 
-直接贴到任何搜索引擎，无论是必应、谷歌还是百度，都能找到对应的解决方法。
+最后直接贴到任何搜索引擎，无论是必应、谷歌还是百度，都能返回对应的解决方法。
 
 #### 筛选结果 {#filter-results}
 
 部分搜索引擎会在结果中返回广告，可以在浏览器中安装去广告扩展（例如 uBlock Origin）来屏蔽这些内容。
 
-有一小部分网站（大多出于商业目的）会不加选择地收集垃圾内容，甚至想方设法欺骗搜索引擎，使其误判为有效信息。这些网站被称为「内容农场」。这些网站提供的信息对解决问题没什么帮助。有关内容农场的特征等信息，可以阅读这篇「少数派」的文章：[清理「内容农场」，还你清爽的 Google 中文搜索体验](https://sspai.com/post/69407)。
+有一小部分网站（大多出于商业目的）会不加选择地收集垃圾内容，甚至想方设法欺骗搜索引擎，使其误判为有效信息。这些网站被称为「内容农场」。这些网站提供的信息对解决问题没什么帮助。如果想了解内容农场的特征等信息，可以阅读这篇「少数派」的文章：[清理「内容农场」，还你清爽的 Google 中文搜索体验](https://sspai.com/post/69407)。
 
-对于搜索得到的结果，目前普遍不成文的认识是：一些网站的内容质量（例如 CSDN）相对更低，中文结果的平均质量也不如英文（很遗憾，这也是更推荐使用英文搜索的原因之一）。在读者逐渐熟练使用搜索引擎后，应该能对不同质量的结果有一个更清晰的判断。
+目前对搜索结果不成文但普遍的认识是：一些网站的内容质量（例如 CSDN）相对更低，中文结果的平均质量也不如英文（很遗憾，这也是更推荐使用英文搜索的原因之一）。在你逐渐熟练使用搜索引擎后，应该能对不同质量的结果有一个更清晰的判断。
 
 ### 其他信息 {#other-info}
 

From c10a98dff57293d9a6324caede6624a5154ce396 Mon Sep 17 00:00:00 2001
From: Catoverflow <55503205+Catoverflow@users.noreply.github.com>
Date: Thu, 3 Sep 2026 00:52:28 -0500
Subject: [PATCH 04/17] 2/4: fix gramma errors, rephrase sentences, simplify
 expressions

---
 pages/_wiki/doc/howtoask.md | 44 ++++++++++++++++++-------------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 3cfd77a98f..7433178714 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -186,9 +186,9 @@ apt update 输出 E: Could not open lock file /var/lib/apt/lists/lock - open (13
 
 ## 提问时的注意事项 {#when-asking}
 
-### 避免 X-Y 型问题 {#avoid-xy}
+### 提出原问题 {#avoid-xy}
 
-X-Y 型问题指代这类情况：
+很多时候询问衍生的问题（X-Y 型问题）不会带来太大的帮助。例如：
 
 1. 你遇到了 X 问题，你认为用 Y 方法可以解决 X 问题
 2. 但是你遇到了阻碍，因此向别人提问关于 Y 的问题，而不告诉其他人最原本的 X 问题
@@ -223,7 +223,7 @@ X-Y 型问题指代这类情况：
   A2: 用 rsync 啊，你妹！
   ```
 
-- 我们补充另一个真实的例子（经过大幅简化）：
+另一个我们遇到的真实例子（已大幅简化）：
 
   ```text
   Q: 有没有人在导入的时候遇到 TypeError: Can't create an SSLContext object without an ssl module? 的报错？
@@ -256,7 +256,7 @@ A (8:00): Hi，我遇到了 XXXXXXX 错误，然后 YYYY 命令跑不了，怎
 B (13:00): 这样，你应该 ZZZZZZZ
 ```
 
-群聊中也是如此，只是出于礼貌的话，额外“握手”一次反而显得浪费时间。
+群聊中也是如此，出于礼貌额外“握手”一次反而浪费时间。
 
 ### 避免「有没有人懂」 {#justask}
 
@@ -270,9 +270,9 @@ B (13:00): 这样，你应该 ZZZZZZZ
 
 - C++ 是非常复杂的，没有多少人真的懂/精通 C++。对很多别的领域也是类似的。
 - 就算真的有人懂，懂的人很可能也不想在群里显摆自己。不太懂的人就更没有兴趣看你的问题了。
-- 这类问题往往属于常识范畴，不精通相关领域的人也可以回答。
+- 这类问题往往属于常识范畴，不精通相关领域的人也可以回答，这样问会降低获得解答的可能性。
 
-一个改善后相对好一些的提问是：
+一个相对好一些的问题是：
 
 ```text
 我遇到了一个问题，我的 C++ 程序需要运行一个 CUDA kernel，我要怎么写 cmake 来编译这个 kernel 并且让我的程序调用？
@@ -284,9 +284,9 @@ B (13:00): 这样，你应该 ZZZZZZZ
 
 **最小可复现样例**（Minimal reproducible example，MRE）是一段**完整、精简**的程序代码或者执行流程，**不包含与错误无关的部分**。这通常只包含出现问题的核心几行代码、命令、以及最小依赖项。你可以复制当前的工程，通过二分法逐步删除无关部分，并保留原有错误来制作 MRE。和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。
 
-不妨换个角度思考：当提问者只提供一段冗长代码，包含大量第三方库和自定义结构体、类方法时，缺少这些关键信息会让回答者无从下手。提问者若直接提供全部代码，恐怕很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
+不妨换个角度思考：当提问者只提供一段冗长代码，包含大量第三方库和自定义结构体、类方法时，缺少这些关键信息会让回答者无从下手。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
 
-> MRE 的提供能平衡提问者和回答者的时间，虽然需要提问者花费更多准备时间和一定技巧，但有助于准确定位问题。
+> 提供 MRE 能平衡提问者和回答者的时间。MRE 虽然需要一些技巧和时间，但有助于准确定位问题。
 
 ### 提供必要的问题描述与相关信息 {#provide-necessary-info}
 
@@ -294,8 +294,8 @@ B (13:00): 这样，你应该 ZZZZZZZ
 
 - 具体问题是什么
 - 引发问题的命令/代码
-- 报错信息（注：如上文所述，通常只有前几条报错信息是关键的，建议先从前面的有效报错开始提问）
-- 自己尝试过用什么方法解决
+- 报错信息（如上文所述，通常只有前几条报错信息较为关键，可以从这些信息开始提问）
+- 尝试过的解决方法
 - 系统与软件的版本信息（例如，如果你想在一个主要讨论 Linux 的群里面问 Windows 下的问题，务必把这一点说清楚）
 
 这是一个在 Linux 讨论群里的反例：
@@ -318,7 +318,7 @@ A2: 要用 curl.exe 调用才行
 
 如果提问者在一开始就说清楚自己在 Windows 下，那么这个问题可能会更快得到解决。
 
-报告错误时请直接提供原始输出，不要自行翻译。建议在开发者的语言（通常是英语）环境下复现错误，获得更准确的提示信息，帮助其他人定位你的问题。建议将错误信息复制后发送，而不是自己手动对着敲一遍；如果原文内容过长，可以参考下一节内容来使用 Pastebin 等工具分享完整文本。
+报告错误时请直接提供原始输出，不要自行翻译。建议在开发者的语言（通常是英语）环境下复现错误，以获得更准确的提示信息并帮助其他人定位问题；最好直接复制错误信息，而不是对着日志手动敲一遍；如果原文内容太长，可以参考下一节内容来使用 Pastebin 等工具分享完整文本。
 
 在 Linux 系统中，可以使用以下方法设置程序运行的语言：
 
@@ -333,25 +333,25 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 代码和报错信息如果太长，直接截图或贴到群聊里可能不太合适：
 
-- 截图里的代码不方便他人直接使用，既难以 OCR 识别，也没人愿意手动转录。
-- 较长的信息直接发送会影响他人阅读前面内容，也不够美观（尤其在不支持代码块的 QQ、微信等聊天软件中）
-- 某些聊天软件会把特殊字符自动转换成表情符号，使得文本难以阅读
+- 截图既难以用 OCR 识别，也没人愿意手动转录，不方便他人直接使用
+- 直接发送较长的信息会影响他人浏览之前的内容，也不便阅读（尤其在不支持代码块的 QQ、微信等聊天软件中）
+- 某些聊天软件会把特殊字符自动转换成表情符号，使得文本更难以阅读
 
-虽然聊天等场景支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。部分网站提供了存储长文本的功能（注意一些网站可能无法直接访问）：
+虽然聊天等场景支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。此时可以使用部分网站的长文本存储功能（一些网站可能无法直接访问）：
 
 - 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) 等
+- 独立的 Pastebin 类服务，例如 <s>[Ubuntu pastebin](https://paste.ubuntu.com/)</s>（已结束服务），[Pastebin.com](http://Pastebin.com) 等
 
 科大校内的同学可以使用校内 GitLab（[超算中心](https://git.ustc.edu.cn/) 或 [LUG](https://git.lug.ustc.edu.cn/)）的 Snippets。
 
-一个反例是：
+反例：
 
 ```text
 我的 vulkan 程序在 wayland 下没有显示出来，托盘那里有程序的图标，怎么回事？
 ```
 
-这个问题的反例原因在于：
+这个例子的问题在于：
 
 - 没有提供任何代码，要知道 Vulkan 画个三角形都要写一千多行代码
 - 环境信息不够详细：比如 Wayland 主要依赖混成器实现，建议说明具体使用的桌面环境，如 KDE；Vulkan 作为图形接口较为宽泛，最好补充相关图形库信息，例如是否使用了 GLFW 绘制窗口。
@@ -360,21 +360,21 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 除非实在无法截图（例如系统启动阶段），否则不要拍屏，因为：
 
-- 不美观
 - 因为[莫尔纹](https://en.wikipedia.org/wiki/Moir%C3%A9_pattern)现象，字/图像可能会拍不清楚
 - 其他人可能得歪着头才能看清内容
 - 不利于其他人搜索类似问题
+- 不美观
 
 ## 无人应答 {#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: 科大网络信息中心报修系统 <https://baoxiu.ustc.edu.cn/>
+  - 见科大网络信息中心报修系统 <https://baoxiu.ustc.edu.cn/>
 
 ## 附录：给回答者的建议 {#for-answerers}
 

From 4ac1c21b0f58c705c756346eb9538f18488a6b67 Mon Sep 17 00:00:00 2001
From: "autofix-ci[bot]" <114827586+autofix-ci[bot]@users.noreply.github.com>
Date: Thu, 3 Sep 2026 05:53:01 +0000
Subject: [PATCH 05/17] [autofix.ci] apply automated fixes

---
 pages/_wiki/doc/howtoask.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 7433178714..a2421f51a4 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -225,18 +225,18 @@ apt update 输出 E: Could not open lock file /var/lib/apt/lists/lock - open (13
 
 另一个我们遇到的真实例子（已大幅简化）：
 
-  ```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}
 

From d6ba65702ca69b58e03e4ac158bfc7b9bbfa0c87 Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Sun, 6 Sep 2026 07:10:45 +0800
Subject: [PATCH 06/17] howtoask: Add #no-copy-paste-llm-answer

---
 pages/_wiki/doc/howtoask.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index a2421f51a4..af559c88b9 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -523,6 +523,18 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 当这些话连续出现的时候，提问者收到的其实是「你的需求很可笑」这种极度不友好的信息。这对解决问题没有帮助，反而会激化矛盾。
 
+### 不要直接复制粘贴大语言模型的回答 {#no-copy-paste-llm-answer}
+
+大语言模型是非常方便的工具，很多时候也是回答问题的高手。不过这不等于在其他人提问时，回答者可以直接复制粘贴大语言模型的回答给对方，考虑以下几点原因：
+
+- 如果只是把提问者的问题复制、粘贴给大语言模型，然后再把模型的回答复制、粘贴给对方，那么对方为什么不自己亲自去问大语言模型呢？
+- 大语言模型的回答很多时候比较冗长，并且风格很可能不像人类正常写作（比如说被一些大语言模型滥用，经常被吐槽的「不是……而是……」），反而不便于阅读和理解。
+- 回答者不做核验的话，辨别模型是否产生幻觉（提供错误回答）的责任就不合理地转移到了其他人身上。
+
+如果回答者核对确认了大语言模型的回答，并且明确标注来源，那么引用关键的一小部分一般来说是可以接受的，例如这样：
+
+> 你的问题我问 LLM，可能的原因是：XXXXXXXXX。我测试了对应的命令，看起来是可以使用的。
+
 ## 附录：如何正确向大语言模型提问 {#llm}
 
 ### 请先阅读正文内容，再阅读本部分 {#read-main-content-first}

From 84ffc224c31bf7ed6d866a20c573375794bd3a08 Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Wed, 9 Sep 2026 01:38:38 +0800
Subject: [PATCH 07/17] =?UTF-8?q?howtoask:=20=E6=94=B9=E5=96=84=E4=B8=AD?=
 =?UTF-8?q?=E6=96=87=E5=86=99=E4=BD=9C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 pages/_wiki/doc/howtoask.md | 72 ++++++++++++++++++-------------------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index af559c88b9..efba8cc125 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -29,7 +29,7 @@ License: CC-BY-NC-SA 4.0
   > 如果你实在克服不了语言障碍，不妨尝试使用 DeepL、Google Translate 等翻译软件，或者借助大语言模型来帮助理解错误信息。
 - 程序日志一般分为 info、warn（warning、W）、error（E）等级别。通常情况下，请优先关注**第一个出现的 error/warning** 信息，因为后续错误往往只是前面的延续。
 
-  > 有些程序前置的错误信息内容可能信息量较低。例如 `subprocess xxx returned error code xxx` 这类提示，只能表明某个进程出错了，但是不包含具体原因。直接搜索的话效果会很差，因此定位并搜索有效的错误信息十分重要。
+  > 有些程序较早出现的错误提示可能信息量较低。例如 `subprocess xxx returned error code xxx` 这类提示，只能表明某个进程出错了，但是不包含具体原因。直接搜索的话效果会很差，因此定位并搜索有效的错误信息十分重要。
 
 - 如果你不知道在哪里找到日志，那么请先解决这个问题。没有这些信息，其他人也只能摸着水晶球猜测到底发生什么了。
 
@@ -91,7 +91,7 @@ License: CC-BY-NC-SA 4.0
   compilation terminated.
   ```
 
-  可以看到，输出中报错信息明确了是 `No such file or directory`（没有对应的文件或文件夹），说明程序找不到指定的文件。仔细检查便可发现是命令里面把文件名敲错了。
+  可以看到，输出中的报错信息明确指出了 `No such file or directory`（没有对应的文件或文件夹），说明程序找不到指定的文件。仔细检查便可发现是命令里面把文件名敲错了。
 
 ### 利用搜索引擎等工具 {#use-search-engine}
 
@@ -168,7 +168,7 @@ W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13:
 apt update 输出 E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
 ```
 
-（连「输出」这两个字甚至也可以不要）
+（甚至「输出」这两个字也可以去掉）
 
 最后直接贴到任何搜索引擎，无论是必应、谷歌还是百度，都能返回对应的解决方法。
 
@@ -178,20 +178,20 @@ apt update 输出 E: Could not open lock file /var/lib/apt/lists/lock - open (13
 
 有一小部分网站（大多出于商业目的）会不加选择地收集垃圾内容，甚至想方设法欺骗搜索引擎，使其误判为有效信息。这些网站被称为「内容农场」。这些网站提供的信息对解决问题没什么帮助。如果想了解内容农场的特征等信息，可以阅读这篇「少数派」的文章：[清理「内容农场」，还你清爽的 Google 中文搜索体验](https://sspai.com/post/69407)。
 
-目前对搜索结果不成文但普遍的认识是：一些网站的内容质量（例如 CSDN）相对更低，中文结果的平均质量也不如英文（很遗憾，这也是更推荐使用英文搜索的原因之一）。在你逐渐熟练使用搜索引擎后，应该能对不同质量的结果有一个更清晰的判断。
+目前对搜索结果不成文但普遍的认识是：一些网站（例如 CSDN）的内容质量相对更低，中文结果的平均质量也不如英文（很遗憾，这也是更推荐使用英文搜索的原因之一）。在你逐渐熟练使用搜索引擎后，应该能对不同质量的结果有一个更清晰的判断。
 
 ### 其他信息 {#other-info}
 
-自 2023 年初大语言模型（GPT 等）逐渐普及以来，询问大语言模型已成为解决问题的有效途径，而且比真人更有耐心。不过这同样需要技巧，请参考本文「[附录：如何正确向大语言模型提问](#llm)」。
+自 2023 年初大语言模型（GPT 等）逐渐普及以来，向大语言模型求助已成为解决问题的一种途径。与真人交流相比，你通常可以更反复、细致地追问。不过这同样需要技巧，请参考本文「[附录：如何正确向大语言模型提问](#llm)」。
 
 ## 提问时的注意事项 {#when-asking}
 
 ### 提出原问题 {#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)）时的例子：
@@ -270,7 +270,7 @@ B (13:00): 这样，你应该 ZZZZZZZ
 
 - C++ 是非常复杂的，没有多少人真的懂/精通 C++。对很多别的领域也是类似的。
 - 就算真的有人懂，懂的人很可能也不想在群里显摆自己。不太懂的人就更没有兴趣看你的问题了。
-- 这类问题往往属于常识范畴，不精通相关领域的人也可以回答，这样问会降低获得解答的可能性。
+- 具体问题未必需要精通整个领域才能回答，这样问会降低获得解答的可能性。
 
 一个相对好一些的问题是：
 
@@ -284,9 +284,9 @@ B (13:00): 这样，你应该 ZZZZZZZ
 
 **最小可复现样例**（Minimal reproducible example，MRE）是一段**完整、精简**的程序代码或者执行流程，**不包含与错误无关的部分**。这通常只包含出现问题的核心几行代码、命令、以及最小依赖项。你可以复制当前的工程，通过二分法逐步删除无关部分，并保留原有错误来制作 MRE。和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。
 
-不妨换个角度思考：当提问者只提供一段冗长代码，包含大量第三方库和自定义结构体、类方法时，缺少这些关键信息会让回答者无从下手。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
+不妨换个角度思考：当提问者只提供一段冗长代码，且如果代码依赖第三方库、自定义结构体或类方法，却没有提供依赖信息和相关定义，回答者就很难复现问题。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
 
-> 提供 MRE 能平衡提问者和回答者的时间。MRE 虽然需要一些技巧和时间，但有助于准确定位问题。
+> 提供 MRE 能平衡提问者和回答者的时间。制作 MRE 虽然需要一些技巧和时间，但有助于准确定位问题。
 
 ### 提供必要的问题描述与相关信息 {#provide-necessary-info}
 
@@ -337,7 +337,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 - 直接发送较长的信息会影响他人浏览之前的内容，也不便阅读（尤其在不支持代码块的 QQ、微信等聊天软件中）
 - 某些聊天软件会把特殊字符自动转换成表情符号，使得文本更难以阅读
 
-虽然聊天等场景支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。此时可以使用部分网站的长文本存储功能（一些网站可能无法直接访问）：
+虽然聊天软件一般都支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。此时可以使用部分网站的长文本存储功能（一些网站可能无法直接访问）：
 
 - GitHub 对应 [GitHub Gist](https://gist.github.com/)
 - GitLab 对应其 [Snippets](https://gitlab.com/dashboard/snippets) 功能
@@ -369,7 +369,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 没人回答不等于问题被无视。在群聊中认真提问却无人回应，往往只是因为看到问题的人都不知道答案罢了。其次，群聊或论坛里的陌生人并没有义务回答你的问题。
 
-可以考虑从以下一些方式解决问题：
+可以尝试通过以下方式求助：
 
 - 线下咨询。
   - 见[LUG 在西区与高新区的活动室](/wiki/lug/contact/#%E9%9D%A2%E5%AF%B9%E9%9D%A2%E4%BA%A4%E6%B5%81)，来之前建议先在群里问一下，只要房间里有人就可以进
@@ -378,9 +378,9 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 ## 附录：给回答者的建议 {#for-answerers}
 
-本文主要部分是给提问者阅读的，但是实际上，有效的回答是由提问者与回答者共同贡献的。有时候，问题没有妥善解决并非完全是提问者的问题。我们见到过很多回答者缺少耐心，让一些本可以友好、妥善解决的问题变成单方面的嘲讽，或者是互相争吵。我们也见到过很多回答者直接贴一个「提问的智慧」的链接（他们本人可能都没有完整阅读过！），就草草了事。
+本文主要部分是给提问者阅读的，但是实际上，有效的回答是由提问者与回答者共同贡献的。有时候，问题没有妥善解决并非完全是提问者的问题。我们见到过很多回答者缺少耐心，让原本可以友好开展的讨论变成单方面的嘲讽或相互争吵。我们也见到过很多回答者直接贴一个「提问的智慧」的链接，就草草了事。
 
-提问者很多时候是新手，他们不确定有哪些东西是重要的、需要提供的，也可能不熟悉对应的术语；回答者也有可能会误解提问者的发言，或者把自己的经历与习惯当作普遍的结论。当然，这里的回答者不是扮演大学课程的助教的角色，**不需要、也没有义务回答每个问题，在没有头绪的时候也完全可以保持沉默**。不过，如果决定参与对问题的讨论的话，那么不妨实际推进问题的解决，而不是去审判提问者有没有资格、是不是老资历、个人偏好是否与你一致吧。
+提问者很多时候是新手，他们不确定有哪些东西是重要的、需要提供的，也可能不熟悉对应的术语；回答者也有可能会误解提问者的发言，或者把自己的经历与习惯当作普遍的结论。当然，这里的回答者**不需要、也没有义务回答每个问题，在没有头绪的时候也完全可以保持沉默**。不过，如果决定参与对问题的讨论的话，那么不妨实际推进问题的解决，而不是去审判提问者有没有资格、是不是老资历、个人偏好是否与你一致吧。
 
 以下介绍的内容，简单来讲遵守这样的原则：
 
@@ -389,7 +389,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 ### 假定善意 {#good-faith}
 
-在绝大部分时候，提问者不是来找茬的，也不是来故意来浪费其他人的时间的。他们可能因为缺乏经验，在提问时会漏掉一些重要的信息，或者提出一些看起来无厘头的需求。**除非对方在之前已经有过多次不提供足够信息、随意提问的记录，否则请不要在一开始就假设对方提问存在问题**。
+在绝大部分时候，提问者不是来找茬的，也不是故意来浪费其他人的时间的。他们可能因为缺乏经验，在提问时会漏掉一些重要的信息，或者提出一些看起来无厘头的需求。**除非对方在之前已经有过多次不提供足够信息、随意提问的记录，否则请不要在一开始就假设对方提问存在问题**。即使如此，也建议直接不再回答，或者明确指出对方提问的问题，要求对方补充细节，而不是做没有建设性的回复。
 
 作为对照：
 
@@ -401,13 +401,13 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
   建议：「我们对 XX 的定义可能不同，你更关心的是 XXXXX 还是 YYYYY？」
 
-**这里避免的两个例子事实上都是在评价提问者本人，而不是在解决问题**。这样做只会让交流气氛更加紧张。如果不愿继续投入时间，直接礼貌退出讨论即可。
+**上面两种应避免的说法都在评价提问者本人，而不是在解决问题**。这样做只会让交流气氛更加紧张。如果不愿继续投入时间，直接礼貌退出讨论即可。
 
 ### 正确地问「为什么」 {#ask-why-correctly}
 
-有时候你会发现无法理解提问者为什么要做他想要做的事情，这很正常。询问提问者为什么要做某件事，可以发现潜在的 [X-Y 型问题](#avoid-xy)，帮助回答者提供恰当有效的方案。但是回答者很容易掉入「要求提问者自证合理」的陷阱中而不自知，在讨论气氛被破坏之后可能也无法意识到自己的问题。
+有时候你会发现不理解提问者为什么有这样的需求，这很正常。询问提问者为什么要做某件事，可以发现潜在的 [X-Y 型问题](#avoid-xy)，帮助回答者提供恰当有效的方案。但是回答者很容易掉入「要求提问者自证合理」的陷阱中而不自知，在讨论气氛被破坏之后可能也无法意识到自己的问题。
 
-有些情况下，提问者会提问两种方案的好坏，但是没有提供最终的目标，例如这样：
+有些情况下，提问者会询问两种方案孰优孰劣，却没有说明最终想实现什么目标，例如这样：
 
 > Q: 我准备把某个 Linux 发行版作为工作环境，应该选择稳定版还是测试版？
 
@@ -429,21 +429,21 @@ LC_ALL=zh_CN.UTF-8 你的命令
 >
 > A: 我觉得这个功能很方便。为什么要关闭？
 
-这里最后的对偏好的质疑对回答问题没有帮助——这可能解释了为什么对应的功能会存在，但是无法代替具体的关闭方法。一种可能更好的回答如下：
+最后一句只是在质疑提问者的偏好，无助于解决问题。「某功能对某些人有用」这一点并不能代替关闭它的方法。一种可能更好的回答如下：
 
 > A: 这里可能涉及普通剪贴板、鼠标选区和剪贴板管理器。你是希望选择的内容完全不进入选区的剪贴板，还是希望剪贴板管理器不要把选区剪贴板同步到普通剪贴板上面？
 
 ### 目标、方案与偏好 {#goal-method-pref}
 
-对一个问题的讨论可以分为三个部分，以上面的例子为例：
+对一个问题的讨论可以分为三个方面，以上面的例子为例：
 
-- 提问者最终的目标，例如在 Linux 上完成某种正式工作，或者在选择文字时不要进入普通剪贴板。
+- 提问者最终的目标，例如在 Linux 上完成某种正式工作，或者不让选中的文字自动进入普通剪贴板。
 - 提问者考虑的方案，例如使用 Wine 运行专业软件，或者在桌面配置的某个地方关闭相关的设置。
 - 提问者的约束条件与偏好，例如文件必须可靠存储，与其他同事的方案兼容（约束条件），或者是单纯不喜欢某个功能（偏好）。
 
-所以对给出的问题，合适的回答思路：
+所以针对上面两个案例，可以这样回答：
 
-- 对第一个案例，首先验证提问者给出的方案是否能够满足正式工作。
+- 对第一个案例，首先验证提问者给出的方案是否能够满足正式工作的要求。
   - 对已有方案的质疑是 OK 的（「Wine 未必适合运行你的专业软件」）。但是不要替提问者修改目标（避免「你不应该用这个专业软件」）。
 - 对第二个案例，帮助定位到对应的配置项。而不是「这个功能很方便。为什么要关闭？」
 
@@ -465,7 +465,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 > A: 这个软件没有官方 Linux 支持，wine 上面前几年我没跑成功，即使目前可以跑，我也不建议拿它来正式做工作，有可能会有数据问题。
 
-如果无法肯定回答，那么退出也是一种选择。回答者不需要，也不可能知道所有问题的答案。承认自己不知道，通常比给出绝对结论更可靠。即使不能肯定回答，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。
+如果无法回答，那么退出也是一种选择。回答者不需要，也不可能知道所有问题的答案。承认自己不知道，通常比给出绝对结论更可靠。即使对答案没有把握，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。
 
 ### 讨论方案的风险 {#risk}
 
@@ -505,7 +505,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 建议的回答：
 
-> A: 我能接受使用测试版，是因为我可以处理依赖冲突、进入救援环境回退之类的操作。如果你暂时不熟悉这些操作，可以评估一下如果升级后暂时无法进入桌面或使用你的专业软件的话是否能接受。
+> A: 我能接受使用测试版，是因为我能解决依赖冲突，也知道如何进入救援环境回退。如果你还不熟悉这些操作，可以先考虑：升级后一旦无法进入桌面或使用工作软件，你能否处理？
 
 ### 关于群聊与玩笑 {#group-joke}
 
@@ -527,13 +527,13 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 大语言模型是非常方便的工具，很多时候也是回答问题的高手。不过这不等于在其他人提问时，回答者可以直接复制粘贴大语言模型的回答给对方，考虑以下几点原因：
 
-- 如果只是把提问者的问题复制、粘贴给大语言模型，然后再把模型的回答复制、粘贴给对方，那么对方为什么不自己亲自去问大语言模型呢？
-- 大语言模型的回答很多时候比较冗长，并且风格很可能不像人类正常写作（比如说被一些大语言模型滥用，经常被吐槽的「不是……而是……」），反而不便于阅读和理解。
+- 如果只是把提问者的问题复制、粘贴给大语言模型，然后再把模型的回答复制、粘贴给对方，那么对方为什么不亲自去问大语言模型呢？
+- 大语言模型的回答很多时候比较冗长，并且风格很可能显得生硬（比如说被一些大语言模型滥用，经常被吐槽的「不是……而是……」），反而不便于阅读和理解。
 - 回答者不做核验的话，辨别模型是否产生幻觉（提供错误回答）的责任就不合理地转移到了其他人身上。
 
 如果回答者核对确认了大语言模型的回答，并且明确标注来源，那么引用关键的一小部分一般来说是可以接受的，例如这样：
 
-> 你的问题我问 LLM，可能的原因是：XXXXXXXXX。我测试了对应的命令，看起来是可以使用的。
+> 我把你的问题问了 LLM，它说可能的原因是：XXXXXXXXX。我测试了对应的命令，看起来是可以使用的。
 
 ## 附录：如何正确向大语言模型提问 {#llm}
 
@@ -545,7 +545,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 #### 对话式大语言模型 {#chatbot-context}
 
-对传统的对话式大语言模型服务来说，和向人类提问类似，提供足够的上下文信息可以更好帮助大语言模型理解问题，给出更好的回答。以刚才的例子为例。
+向对话式大语言模型提问时，和向人类提问类似，也需要提供足够的上下文，帮助它理解问题。以本文出现的例子为例。
 
 原始例子：
 
@@ -651,29 +651,29 @@ Invoke-WebRequest -Uri "https://example.com/file.zip" -OutFile "file.zip"
 
 #### Agent {#agent-context}
 
-从 2025 年开始，以编程 Agent 为代表的 Agent 软件开始广泛应用（包括但不限于 Claude Code、Codex 等）。Agent 与传统的对话式大语言模型不同，它可以利用工具调用在你的电脑上读取和修改文件、执行命令、搜索信息等。当 Agent 运行在出现问题的场合下时，很多时候它能够自行获取到需要的上下文信息，但是其无法直接获得的信息仍然需要告知（例如修改的目标、无法直接获取的环境信息等等）。
+从 2025 年开始，以编程 Agent 为代表的 Agent 软件开始广泛应用（包括但不限于 Claude Code、Codex 等）。Agent 与传统的对话式大语言模型不同，它可以利用工具调用在你的电脑上读取和修改文件、执行命令、搜索信息等。当 Agent 在出现问题的环境中运行时，很多时候它能够自行获取到需要的上下文信息，但是它无法直接获取的信息，仍需要你补充（例如修改的目标、无法直接获取的环境信息等等）。
 
 ### 提问语言 {#ask-language}
 
 在大语言模型发展的早期，使用英文提问相比中文可能会有更好的效果。不过，当前主流模型的中文能力已经足以处理大多数日常技术问题。因此目前的建议是：
 
 - 优先使用能够准确、流畅表达问题的语言。对本文读者来说一般是中文。
-- 对诸如错误信息、命令、专有名词等保留原文即可，不要自行翻译。
+- 错误信息、命令、专有名词等应保留原文，不要自行翻译。
 
-根据模型分词器（Tokenizer）的不同，在表达相同的含义时，不同模型处理中文与英文的效率也不同。如果有压缩成本的需求，需要自行测试。
+根据模型分词器（Tokenizer）的不同，在表达相同的含义时，不同模型处理中文与英文的效率也不同。如果有降低使用成本的需求，需要自行测试。
 
 ### 避免超长的对话 {#avoid-long-dialog}
 
 大语言模型在对话时，先前的消息通常仍会作为上下文提供给模型。目前模型服务商不少都配置了**缓存**，在对话追加内容时，前面的内容如果命中了缓存，就能大幅减小计算量，节约成本（具体机制取决于使用的产品）；如果没有命中的话，先前的消息就需要重新计算。不过仍然需要注意：
 
-- 大语言模型的上下文长度是有限制的。当内容量接近上下文长度时，根据使用的实现不同，可能会无法再继续使用、最早的内容被丢弃、或者已有的内容经过「压缩」后填入新的对话继续。如果重要的内容在这个过程中丢失，模型的表现可能会受到很大的影响。
+- 大语言模型的上下文长度是有限制的。当内容量接近上下文长度上限时，服务可能停止接受新消息、丢弃较早的内容，或压缩已有内容后继续对话，具体取决于实现。如果重要的内容在这个过程中丢失，模型的表现可能会受到很大的影响。
 - 相比于短文本，LLM 对长文本更容易产生「**幻觉**」，即输出与实际情况不相符的内容。特别是在上下文中出现无关、过时、或者相互矛盾的信息时，这种现象会更加严重。
 
 如果发现 LLM 工作异常，可以重启会话。重新开始后，更应该调整提问的策略。
 
 ### 核验回答 {#verify-answer}
 
-由于幻觉问题的存在，大语言模型可能会充满自信地、详细地回答不正确的内容。如果不了解对应的领域，而贸然使用 LLM 的回答，就可能轻则浪费时间，重则带来严重的麻烦。对新手来说，我们有一些建议：
+由于幻觉问题的存在，大语言模型可能会以自信的语气给出详细但错误的回答。如果不了解对应的领域，而贸然使用 LLM 的回答，就可能轻则浪费时间，重则带来严重的麻烦。对新手来说，我们有一些建议：
 
 - 根据环境的不同，LLM 可能无法访问互联网、了解最新信息。在提问前需要先确认。
 - 在提问时，明确要求 LLM 提供可以用于核验回答的来源信息。
@@ -682,7 +682,7 @@ Invoke-WebRequest -Uri "https://example.com/file.zip" -OutFile "file.zip"
 
 ### 隐私问题 {#llm-privacy}
 
-使用大语言模型，特别是 Agent 的时候，如果正在处理非公开的信息，那么就需要尤其注意隐私问题。不同的大语言模型服务商有不同的隐私策略，在一些情况下可能会留存用户提供的信息用于训练新的模型，或者改进产品。你大概率不会向陌生人告诉你的秘密，但是在向大语言模型提问的时候，可能会不知不觉泄露相关的信息。因此，在提问的时候需要注意：
+使用大语言模型，特别是 Agent 的时候，如果正在处理非公开的信息，那么就需要尤其注意隐私问题。不同的大语言模型服务商有不同的隐私策略，在一些情况下可能会留存用户提供的信息用于训练新的模型，或者改进产品。你大概不会把自己的秘密告诉陌生人，但是在向大语言模型提问的时候，可能会不知不觉泄露相关的信息。因此，在提问的时候需要注意：
 
 - 使用大语言模型前，确认服务商的隐私策略、服务条款等内容。
 - 不要直接向模型提供密码、Cookie、私钥等敏感数据。
@@ -705,6 +705,6 @@ curl -k -O https://example.com/filename.zip
 
 但是这是不恰当的——用户的提问中并不包含 SSL 检查失败的场景，并且 LLM 也完全没有说明对应的风险（恶意的中间人可以将下载下来的文件替换为自己的）。尽管这条命令确实能跑，而且「大部分时候」都能用，但是能用不代表是正确的选择。
 
-在一些更恶劣的情况下，执行 LLM 的命令会导致数据丢失。例如在[这个知乎问题中](https://www.zhihu.com/question/1974854700256944776)，LLM 生成的命令就非预期删除了 800G 的内容。
+在一些更恶劣的情况下，执行 LLM 的命令会导致数据丢失。例如在[这个知乎问题中](https://www.zhihu.com/question/1974854700256944776)，LLM 生成的命令就意外删除了 800G 的数据。
 
 因此，在执行 LLM 的命令之前，需要理解命令实际的功能。对 Agent 来说，不同 Agent 软件的隔离、命令批准等机制不同，即使命令没有出现批准提示，也不代表对应的命令绝对安全。在使用 Agent 前，需要确认 Agent 下 LLM 能够访问的数据范围，并在使用时检查其实际的修改操作，做到心中有数。

From db12dd60e2c6621c6ee9eb7a914847d1dca929fe Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Wed, 9 Sep 2026 02:11:05 +0800
Subject: [PATCH 08/17] howtoask: refactor "for-answerers"

---
 pages/_wiki/doc/howtoask.md | 102 +++++++++++++++---------------------
 1 file changed, 42 insertions(+), 60 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index efba8cc125..9a1e760e08 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -284,7 +284,7 @@ B (13:00): 这样，你应该 ZZZZZZZ
 
 **最小可复现样例**（Minimal reproducible example，MRE）是一段**完整、精简**的程序代码或者执行流程，**不包含与错误无关的部分**。这通常只包含出现问题的核心几行代码、命令、以及最小依赖项。你可以复制当前的工程，通过二分法逐步删除无关部分，并保留原有错误来制作 MRE。和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。
 
-不妨换个角度思考：当提问者只提供一段冗长代码，且如果代码依赖第三方库、自定义结构体或类方法，却没有提供依赖信息和相关定义，回答者就很难复现问题。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
+不妨换个角度思考：如果提问者提供的代码依赖第三方库、自定义结构体或类方法，却没有提供依赖信息和相关定义，回答者就很难复现问题。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
 
 > 提供 MRE 能平衡提问者和回答者的时间。制作 MRE 虽然需要一些技巧和时间，但有助于准确定位问题。
 
@@ -387,7 +387,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 1. 好的回答不一定是立刻解决问题的回答。
 2. 能够澄清目标、提供可靠依据、指出下一步，并尊重提问者合理的选择，就已经能显著降低解决问题的难度。
 
-### 假定善意 {#good-faith}
+### 尊重提问者 {#respect-questioners}
 
 在绝大部分时候，提问者不是来找茬的，也不是故意来浪费其他人的时间的。他们可能因为缺乏经验，在提问时会漏掉一些重要的信息，或者提出一些看起来无厘头的需求。**除非对方在之前已经有过多次不提供足够信息、随意提问的记录，否则请不要在一开始就假设对方提问存在问题**。即使如此，也建议直接不再回答，或者明确指出对方提问的问题，要求对方补充细节，而不是做没有建设性的回复。
 
@@ -403,7 +403,23 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 **上面两种应避免的说法都在评价提问者本人，而不是在解决问题**。这样做只会让交流气氛更加紧张。如果不愿继续投入时间，直接礼貌退出讨论即可。
 
-### 正确地问「为什么」 {#ask-why-correctly}
+另外在群聊中，可能会出现回答时开玩笑的情况。尽管熟人之间的玩笑不一定带有恶意，但在提问者的问题尚未解决时，多人围绕问题开玩笑的话，绝大部分情况下没有正面的作用。像下面这个有点恶劣的例子：
+
+> Q: 怎样关闭某个桌面功能？
+>
+> …………
+>
+> A: 那建议卸载系统哦。
+>
+> B: 卸载桌面也可以。
+>
+> C: 干脆不要用图形界面。
+
+当这些话连续出现的时候，提问者收到的其实是「你的需求很可笑」这种极度不友好的信息。这对解决问题没有帮助，反而会激化矛盾。**请不要对提问者开这种玩笑**。
+
+### 澄清目标，推进解决 {#move-to-goal}
+
+可以从三个方面理解提问：目标、已有方案，以及约束条件与偏好。这些信息起初可能并不明确，需要双方通过交流加以澄清，排除不符合要求的方案，推进问题解决。
 
 有时候你会发现不理解提问者为什么有这样的需求，这很正常。询问提问者为什么要做某件事，可以发现潜在的 [X-Y 型问题](#avoid-xy)，帮助回答者提供恰当有效的方案。但是回答者很容易掉入「要求提问者自证合理」的陷阱中而不自知，在讨论气氛被破坏之后可能也无法意识到自己的问题。
 
@@ -431,23 +447,27 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 最后一句只是在质疑提问者的偏好，无助于解决问题。「某功能对某些人有用」这一点并不能代替关闭它的方法。一种可能更好的回答如下：
 
-> A: 这里可能涉及普通剪贴板、鼠标选区和剪贴板管理器。你是希望选择的内容完全不进入选区的剪贴板，还是希望剪贴板管理器不要把选区剪贴板同步到普通剪贴板上面？
+> A: 你是说，选中文字后 Ctrl+V 粘贴的内容也会跟着变吗？
 
-### 目标、方案与偏好 {#goal-method-pref}
+然后再根据对方的回答补充解释或者文档链接等。如果对方是新手，不建议在回答时引入太多的概念，或者直接要求对方阅读完超长的 wiki 再描述需求。
 
-对一个问题的讨论可以分为三个方面，以上面的例子为例：
+有用的回答需要能够让讨论向前推进。一种常见的问题是只讨论个人经历，但是不说明自己的经历和当前问题有什么对应关系。没有意义的回答类似这样：
 
-- 提问者最终的目标，例如在 Linux 上完成某种正式工作，或者不让选中的文字自动进入普通剪贴板。
-- 提问者考虑的方案，例如使用 Wine 运行专业软件，或者在桌面配置的某个地方关闭相关的设置。
-- 提问者的约束条件与偏好，例如文件必须可靠存储，与其他同事的方案兼容（约束条件），或者是单纯不喜欢某个功能（偏好）。
+- 这不是挺方便吗？
+- 别搞了
+- 我用了很多年，你参考不了。
 
-所以针对上面两个案例，可以这样回答：
+有效的回答类似于这样：
 
-- 对第一个案例，首先验证提问者给出的方案是否能够满足正式工作的要求。
-  - 对已有方案的质疑是 OK 的（「Wine 未必适合运行你的专业软件」）。但是不要替提问者修改目标（避免「你不应该用这个专业软件」）。
-- 对第二个案例，帮助定位到对应的配置项。而不是「这个功能很方便。为什么要关闭？」
+- 解决方法是……
+- 先看一下 XXX 的输出（来区分原因）
+- 你的 XXX 软件版本是？（补充信息）
+- 官方文档：……
+- 可以试一下 XXX 来验证是否正确
+- 如果 XXX 不可以的话，那么就试一下 YYY 替代方案
+- 我不知道，但是可以去 XXX 问一下
 
-### 明确结论的依据 {#answer-with-bound}
+### 说明依据与风险 {#evidence-and-risk}
 
 对下面这个例子：
 
@@ -465,39 +485,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 > A: 这个软件没有官方 Linux 支持，wine 上面前几年我没跑成功，即使目前可以跑，我也不建议拿它来正式做工作，有可能会有数据问题。
 
-如果无法回答，那么退出也是一种选择。回答者不需要，也不可能知道所有问题的答案。承认自己不知道，通常比给出绝对结论更可靠。即使对答案没有把握，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。
-
-### 讨论方案的风险 {#risk}
-
-提问者有时候会想做一些危险的事情，此时回答者需要明确指出风险，并且让提问者知道风险在哪里、怎么安全验证（如果可以），以及回退的方案。一个指出风险，但是不够好的回答可能会是这样：
-
-> A: 不支持。如果和同事做出来的东西不一样，出了问题别来找我们。
-
-更好的参考回答：
-
-> A: 即使能够通过兼容层启动，有些地方也可能存在兼容问题。如果需要正式交付，不建议在未经验证的情况下把它作为唯一环境。你可以保留原系统，先测试常用情况的导出结果是否正确，之后再决定哪些工作可以迁移。
-
-### 推进下一步 {#next-step}
-
-有用的回答需要能够让讨论向前推进。一种常见的问题是只讨论个人经历，但是不说明自己的经历和当前问题有什么对应关系。没有意义的回答类似这样：
-
-- 这不是挺方便吗？
-- 别搞了
-- 我用了很多年，你参考不了。
-
-有效的回答类似于这样：
-
-- 解决方法是……
-- 先看一下 XXX 的输出（来区分原因）
-- 你的 XXX 软件版本是？（补充信息）
-- 官方文档：……
-- 可以试一下 XXX 来验证是否正确
-- 如果 XXX 不可以的话，那么就试一下 YYY 替代方案
-- 我不知道，但是可以去 XXX 问一下
-
-### 不要用资历代替解释 {#experience-is-not-explanation}
-
-经验可以帮助回答者识别风险，但是经验不是结论。对提问者来说，重要的不是回答者有多少年的资历，而是哪些问题可能发生、如何发现，以及发生后需要怎么处理。
+尽管经验可以帮助回答者识别风险，但是经验不是结论。对提问者来说，重要的不是回答者有多少年的资历，而是哪些问题可能发生、如何发现，以及发生后需要怎么处理。
 
 避免下面的回答：
 
@@ -507,21 +495,15 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 > A: 我能接受使用测试版，是因为我能解决依赖冲突，也知道如何进入救援环境回退。如果你还不熟悉这些操作，可以先考虑：升级后一旦无法进入桌面或使用工作软件，你能否处理？
 
-### 关于群聊与玩笑 {#group-joke}
+如果无法回答，那么退出也是一种选择。回答者不需要，也不可能知道所有问题的答案。承认自己不知道，通常比给出绝对结论更可靠。即使对答案没有把握，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。
 
-尽管熟人之间的玩笑不一定带有恶意，但在提问者的问题尚未解决时，多人围绕问题开玩笑的话，绝大部分情况下没有正面的作用。像下面这个有点恶劣的例子：
+另外，提问者有时候会想做一些危险的事情，此时回答者需要明确指出风险，并且让提问者知道风险在哪里、怎么安全验证（如果可以），以及回退的方案。一个指出风险，但是不够好的回答可能会是这样：
 
-> Q: 怎样关闭某个桌面功能？
->
-> …………
->
-> A: 那建议卸载系统哦。
->
-> B: 卸载桌面也可以。
->
-> C: 干脆不要用图形界面。
+> A: 不支持。如果和同事做出来的东西不一样，出了问题别来找我们。
+
+更好的参考回答：
 
-当这些话连续出现的时候，提问者收到的其实是「你的需求很可笑」这种极度不友好的信息。这对解决问题没有帮助，反而会激化矛盾。
+> A: 即使能够通过兼容层启动，有些地方也可能存在兼容问题。如果需要正式交付，不建议在未经验证的情况下把它作为唯一环境。你可以保留原系统，先测试常用情况的导出结果是否正确，之后再决定哪些工作可以迁移。
 
 ### 不要直接复制粘贴大语言模型的回答 {#no-copy-paste-llm-answer}
 
@@ -545,7 +527,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 #### 对话式大语言模型 {#chatbot-context}
 
-向对话式大语言模型提问时，和向人类提问类似，也需要提供足够的上下文，帮助它理解问题。以本文出现的例子为例。
+向对话式大语言模型提问时，和向人类提问类似，也需要提供足够的上下文，帮助它理解问题。下面沿用前文在命令行中下载文件的例子。
 
 原始例子：
 

From 1065dacaf5126eb226bda851f116cb6b6ec2668b Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Wed, 9 Sep 2026 02:15:32 +0800
Subject: [PATCH 09/17] =?UTF-8?q?howtoask:=20=E6=8A=98=E5=8F=A0=E9=95=BF?=
 =?UTF-8?q?=E4=BE=8B=E5=AD=90?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 pages/_wiki/doc/howtoask.md | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 9a1e760e08..d34f679d43 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -49,7 +49,8 @@ License: CC-BY-NC-SA 4.0
 
 - 例 2：为什么我装不了 `pytorch`
 
-  执行的命令与错误信息：
+  <details markdown="1">
+  <summary>查看执行的命令与完整错误信息</summary>
 
   ```console
   $ pip install pytorch
@@ -81,6 +82,8 @@ License: CC-BY-NC-SA 4.0
   [notice] To update, run: pip install --upgrade pip
   ```
 
+  </details>
+
   错误提示显示异常（exception）的内容是 `You tried to install "pytorch". The package named for PyTorch is "torch"`，说明要安装的软件包的名字是 `torch`，而非 `pytorch`，因此将命令从 `pip install pytorch` 改成 `pip install torch` 即可。
 
 - 例 3：为什么我的程序编译不了
@@ -529,7 +532,8 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 向对话式大语言模型提问时，和向人类提问类似，也需要提供足够的上下文，帮助它理解问题。下面沿用前文在命令行中下载文件的例子。
 
-原始例子：
+<details markdown="1">
+<summary>查看原始提问与大语言模型的完整回答</summary>
 
 ````text
 Human: 怎么在命令行里面下载一个 url？
@@ -611,6 +615,8 @@ sudo apt install wget
 如果你告诉我你是用 Windows / Linux / macOS，我可以给你更具体的命令。
 ````
 
+</details>
+
 改进后的例子：
 
 ````text

From 4fd5d81c951bb5d9e23a62796c7b834916ed2564 Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Wed, 9 Sep 2026 02:24:01 +0800
Subject: [PATCH 10/17] howtoask: space

---
 pages/_wiki/doc/howtoask.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index d34f679d43..dbecd70ed7 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -375,7 +375,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 可以尝试通过以下方式求助：
 
 - 线下咨询。
-  - 见[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)，来之前建议先在群里问一下，只要房间里有人就可以进
 - 向对应服务/软件的维护人员提交工单
   - 见科大网络信息中心报修系统 <https://baoxiu.ustc.edu.cn/>
 

From df6baca193633e67b73914febaf5abb20e757ff1 Mon Sep 17 00:00:00 2001
From: Catoverflow <55503205+Catoverflow@users.noreply.github.com>
Date: Tue, 8 Sep 2026 18:41:50 -0500
Subject: [PATCH 11/17] =?UTF-8?q?howtoask:=20=E9=87=8D=E6=96=B0=E6=95=B4?=
 =?UTF-8?q?=E7=90=86=E3=80=8C=E7=BB=99=E5=9B=9E=E7=AD=94=E8=80=85=E7=9A=84?=
 =?UTF-8?q?=E5=BB=BA=E8=AE=AE=E3=80=8D?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

合并重复的小节：「澄清目标，推进解决」改为「循循善诱」，
「说明依据与风险」改为「检查自己的误区」，风险讨论并入其中的
第二类误区。压缩导语，统一反例/建议的排版，去掉重复出现的例子。

剪贴板的正面示范改为给出链接加简单说明，而不是在群聊里追问概念。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvEbFWbpQYtwB2V6SvQWUf
---
 pages/_wiki/doc/howtoask.md | 81 ++++++++++++++-----------------------
 1 file changed, 31 insertions(+), 50 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index dbecd70ed7..e1a3d0344f 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -381,18 +381,15 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 ## 附录：给回答者的建议 {#for-answerers}
 
-本文主要部分是给提问者阅读的，但是实际上，有效的回答是由提问者与回答者共同贡献的。有时候，问题没有妥善解决并非完全是提问者的问题。我们见到过很多回答者缺少耐心，让原本可以友好开展的讨论变成单方面的嘲讽或相互争吵。我们也见到过很多回答者直接贴一个「提问的智慧」的链接，就草草了事。
+有效的回答由提问者和回答者共同完成，问题没有得到解决也未必都是提问者的责任。我们见过不少讨论变成了单方面的嘲讽或者相互争吵，也见过回答者甩下一个「提问的智慧」的链接就草草了事。
 
-提问者很多时候是新手，他们不确定有哪些东西是重要的、需要提供的，也可能不熟悉对应的术语；回答者也有可能会误解提问者的发言，或者把自己的经历与习惯当作普遍的结论。当然，这里的回答者**不需要、也没有义务回答每个问题，在没有头绪的时候也完全可以保持沉默**。不过，如果决定参与对问题的讨论的话，那么不妨实际推进问题的解决，而不是去审判提问者有没有资格、是不是老资历、个人偏好是否与你一致吧。
+提问者很多时候是新手，不确定哪些信息是重要的，也可能不熟悉相关的术语；回答者同样可能误解提问者的意思，或者把个人的经历与习惯当作普遍结论。当然，回答者**不需要、也没有义务回答每个问题，在没有头绪的时候完全可以保持沉默**。但如果决定参与讨论，那么不妨实际推进问题的解决，而不是去审判提问者有没有资格提问。
 
-以下介绍的内容，简单来讲遵守这样的原则：
-
-1. 好的回答不一定是立刻解决问题的回答。
-2. 能够澄清目标、提供可靠依据、指出下一步，并尊重提问者合理的选择，就已经能显著降低解决问题的难度。
+好的回答不一定能立刻解决问题：澄清目标、给出可靠的依据、指出下一步，并且尊重提问者的合理选择，就已经能显著降低解决问题的难度。
 
 ### 尊重提问者 {#respect-questioners}
 
-在绝大部分时候，提问者不是来找茬的，也不是故意来浪费其他人的时间的。他们可能因为缺乏经验，在提问时会漏掉一些重要的信息，或者提出一些看起来无厘头的需求。**除非对方在之前已经有过多次不提供足够信息、随意提问的记录，否则请不要在一开始就假设对方提问存在问题**。即使如此，也建议直接不再回答，或者明确指出对方提问的问题，要求对方补充细节，而不是做没有建设性的回复。
+绝大部分提问者不是来找茬的，也不是故意来浪费其他人的时间的。他们可能因为缺乏经验漏掉一些重要的信息，或者提出一些看起来无厘头的需求。**除非对方之前已经多次不提供足够信息、随意提问，否则请不要在一开始就假设对方的提问有问题**；即使如此，也建议直接不再回答，或者明确指出缺少哪些信息，而不是做没有建设性的回复。
 
 作为对照：
 
@@ -404,9 +401,9 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
   建议：「我们对 XX 的定义可能不同，你更关心的是 XXXXX 还是 YYYYY？」
 
-**上面两种应避免的说法都在评价提问者本人，而不是在解决问题**。这样做只会让交流气氛更加紧张。如果不愿继续投入时间，直接礼貌退出讨论即可。
+**应当避免的说法都在评价提问者本人，而不是在解决问题**，这样只会让交流气氛更加紧张。如果不愿继续投入时间，直接礼貌退出讨论即可。
 
-另外在群聊中，可能会出现回答时开玩笑的情况。尽管熟人之间的玩笑不一定带有恶意，但在提问者的问题尚未解决时，多人围绕问题开玩笑的话，绝大部分情况下没有正面的作用。像下面这个有点恶劣的例子：
+群聊里也常出现拿问题开玩笑的情况。熟人之间的玩笑不一定带有恶意，但在问题尚未解决时，多人接连玩梗，提问者收到的其实是「你的需求很可笑」这种极不友好的信息：
 
 > Q: 怎样关闭某个桌面功能？
 >
@@ -418,27 +415,23 @@ LC_ALL=zh_CN.UTF-8 你的命令
 >
 > C: 干脆不要用图形界面。
 
-当这些话连续出现的时候，提问者收到的其实是「你的需求很可笑」这种极度不友好的信息。这对解决问题没有帮助，反而会激化矛盾。**请不要对提问者开这种玩笑**。
-
-### 澄清目标，推进解决 {#move-to-goal}
+**请不要对提问者开这种玩笑。**
 
-可以从三个方面理解提问：目标、已有方案，以及约束条件与偏好。这些信息起初可能并不明确，需要双方通过交流加以澄清，排除不符合要求的方案，推进问题解决。
+### 循循善诱 {#guide-patiently}
 
-有时候你会发现不理解提问者为什么有这样的需求，这很正常。询问提问者为什么要做某件事，可以发现潜在的 [X-Y 型问题](#avoid-xy)，帮助回答者提供恰当有效的方案。但是回答者很容易掉入「要求提问者自证合理」的陷阱中而不自知，在讨论气氛被破坏之后可能也无法意识到自己的问题。
+可以从三个方面理解一个问题：目标、已有方案，以及约束条件与偏好。这些信息起初往往并不明确，需要双方在交流中逐步澄清，排除不符合要求的方案。
 
-有些情况下，提问者会询问两种方案孰优孰劣，却没有说明最终想实现什么目标，例如这样：
+询问提问者「为什么要做这件事」，可以发现潜在的 [X-Y 型问题](#avoid-xy)。例如：
 
 > Q: 我准备把某个 Linux 发行版作为工作环境，应该选择稳定版还是测试版？
-
-后续的提问可能会是这样子：
-
+>
 > A: 你主要需要用它完成什么工作？
 >
 > Q: 我的工作依赖一款没有 Linux 版本的专业软件，本来准备通过兼容层运行。
 
-从这里开始，实际的问题就不再是单纯的「稳定版和测试版哪个更好」，而是在「可靠完成工作」的约束下比较两者。通过后续的确认，可以进一步缩小范围，给出合理的结果。相反，如果脱离这个背景，继续讨论软件包新旧与否，就不是很妥当了。
+到这里，实际的问题就不再是单纯的「稳定版和测试版哪个更好」，而是在「可靠完成工作」的约束下比较两者；脱离这个背景继续讨论软件包新旧，就不太妥当了。
 
-另一种情况是，提问者想做的事情和你的偏好完全不同，例如这个反例：
+不过，问「为什么」也很容易滑向要求提问者「自证需求合理」，在提问者的偏好与你不同时尤其如此：
 
 > Q: 选择文本时会自动进入剪贴板，请问怎样关闭？
 >
@@ -448,19 +441,11 @@ LC_ALL=zh_CN.UTF-8 你的命令
 >
 > A: 我觉得这个功能很方便。为什么要关闭？
 
-最后一句只是在质疑提问者的偏好，无助于解决问题。「某功能对某些人有用」这一点并不能代替关闭它的方法。一种可能更好的回答如下：
-
-> A: 你是说，选中文字后 Ctrl+V 粘贴的内容也会跟着变吗？
-
-然后再根据对方的回答补充解释或者文档链接等。如果对方是新手，不建议在回答时引入太多的概念，或者直接要求对方阅读完超长的 wiki 再描述需求。
-
-有用的回答需要能够让讨论向前推进。一种常见的问题是只讨论个人经历，但是不说明自己的经历和当前问题有什么对应关系。没有意义的回答类似这样：
+最后一句只是在质疑提问者的偏好：「某功能对某些人有用」并不能代替关闭它的方法。如果问题涉及提问者可能不了解的概念，比起在群里追问，或者要求对方读完一大篇 wiki 再来描述需求，给出链接加一句简单的说明通常更有效：
 
-- 这不是挺方便吗？
-- 别搞了
-- 我用了很多年，你参考不了。
+> A: 这里其实有「鼠标选区」和普通剪贴板两套机制，可以先看看 [ArchWiki 的介绍](https://wiki.archlinux.org/title/Clipboard)，再说说你想关掉的是哪一个？
 
-有效的回答类似于这样：
+**有用的回答需要让讨论向前推进。** 一种常见的问题是只讨论个人经历，却不说明它和当前问题有什么关系，比如「这不是挺方便吗」「别搞了」「我用了很多年，你参考不了」。相比之下，这样的回答是有效的：
 
 - 解决方法是……
 - 先看一下 XXX 的输出（来区分原因）
@@ -470,9 +455,11 @@ LC_ALL=zh_CN.UTF-8 你的命令
 - 如果 XXX 不可以的话，那么就试一下 YYY 替代方案
 - 我不知道，但是可以去 XXX 问一下
 
-### 说明依据与风险 {#evidence-and-risk}
+### 检查自己的误区 {#check-your-assumptions}
 
-对下面这个例子：
+回答者的经验既是优势，也可能是误区：**把经验和推测当作事实**，以及**默认提问者能像自己一样处理后果**。
+
+第一种误区：
 
 > A: Linux 肯定不支持你这个软件啊！
 >
@@ -484,29 +471,23 @@ LC_ALL=zh_CN.UTF-8 你的命令
 >
 > A: 我有几年没试过了，不过我不抱希望。
 
-这里显著的矛盾就在于，回答者没有恰当**区分「事实」、「经验」和「推测」**。一种更好的回答：
-
-> A: 这个软件没有官方 Linux 支持，wine 上面前几年我没跑成功，即使目前可以跑，我也不建议拿它来正式做工作，有可能会有数据问题。
-
-尽管经验可以帮助回答者识别风险，但是经验不是结论。对提问者来说，重要的不是回答者有多少年的资历，而是哪些问题可能发生、如何发现，以及发生后需要怎么处理。
-
-避免下面的回答：
+这里的问题在于没有**区分「事实」、「经验」和「推测」**。一种更好的回答：
 
-> A: 我用了很多年，这些问题我都能处理，你参考不了。
+> A: 这个软件没有官方 Linux 支持，wine 上面前几年我没跑成功。即使目前可以跑，我也不建议拿它来正式做工作，有可能会有数据问题。
 
-建议的回答：
+如果没有把握，退出讨论也是一种选择：承认自己不知道，通常比给出绝对结论更可靠。即使对答案没有把握，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。
 
-> A: 我能接受使用测试版，是因为我能解决依赖冲突，也知道如何进入救援环境回退。如果你还不熟悉这些操作，可以先考虑：升级后一旦无法进入桌面或使用工作软件，你能否处理？
+第二种误区常出现在讨论风险的时候。对提问者来说，重要的不是回答者有多少年资历，而是哪些问题可能发生、如何发现，以及发生之后需要怎么处理：
 
-如果无法回答，那么退出也是一种选择。回答者不需要，也不可能知道所有问题的答案。承认自己不知道，通常比给出绝对结论更可靠。即使对答案没有把握，解释相关概念、指出需要确认的信息或者推荐合适的资料，都可能帮助提问者继续调查。
-
-另外，提问者有时候会想做一些危险的事情，此时回答者需要明确指出风险，并且让提问者知道风险在哪里、怎么安全验证（如果可以），以及回退的方案。一个指出风险，但是不够好的回答可能会是这样：
-
-> A: 不支持。如果和同事做出来的东西不一样，出了问题别来找我们。
+> 避免：我用了很多年，这些问题我都能处理，你参考不了。
+>
+> 建议：我能接受使用测试版，是因为我能解决依赖冲突，也知道如何进入救援环境回退。如果你还不熟悉这些操作，可以先考虑：升级后一旦无法进入桌面或者用不了工作软件，你能否处理？
 
-更好的参考回答：
+提问者有时候会想做一些危险的事情，此时同样需要说清楚风险在哪里、怎样安全地验证（如果可以），以及回退的方案：
 
-> A: 即使能够通过兼容层启动，有些地方也可能存在兼容问题。如果需要正式交付，不建议在未经验证的情况下把它作为唯一环境。你可以保留原系统，先测试常用情况的导出结果是否正确，之后再决定哪些工作可以迁移。
+> 避免：不支持。如果和同事做出来的东西不一样，出了问题别来找我们。
+>
+> 建议：即使能够通过兼容层启动，有些地方也可能存在兼容问题。如果需要正式交付，不建议在未经验证的情况下把它作为唯一环境。你可以保留原系统，先测试常用情况的导出结果是否正确，之后再决定哪些工作可以迁移。
 
 ### 不要直接复制粘贴大语言模型的回答 {#no-copy-paste-llm-answer}
 

From 9b185652d357c291a7461d1bb32d6dff232f2d80 Mon Sep 17 00:00:00 2001
From: Catoverflow <55503205+Catoverflow@users.noreply.github.com>
Date: Tue, 8 Sep 2026 18:49:37 -0500
Subject: [PATCH 12/17] =?UTF-8?q?howtoask:=20=E9=87=8D=E6=96=B0=E6=95=B4?=
 =?UTF-8?q?=E7=90=86=E3=80=8C=E6=8F=90=E9=97=AE=E6=97=B6=E7=9A=84=E6=B3=A8?=
 =?UTF-8?q?=E6=84=8F=E4=BA=8B=E9=A1=B9=E3=80=8D?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

合并「避免『有没有人懂』」到「直接提问」；把「最小可复现样例」
移到「提供必要的信息」下面，把「避免拍屏」移到分享信息一节下面，
信息不足的 vulkan 反例也随之移到「提供必要的信息」。

小标题改得更简洁：「使用代码片段服务分享问题相关的代码与报错」
改为「用合适的方式分享信息」（在线剪贴板作为其子节），「无人应答」
改为「其他咨询方式」。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvEbFWbpQYtwB2V6SvQWUf
---
 pages/_wiki/doc/howtoask.md | 70 +++++++++++++++++++------------------
 1 file changed, 36 insertions(+), 34 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index e1a3d0344f..0e9997c1bd 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -183,7 +183,7 @@ apt update 输出 E: Could not open lock file /var/lib/apt/lists/lock - open (13
 
 目前对搜索结果不成文但普遍的认识是：一些网站（例如 CSDN）的内容质量相对更低，中文结果的平均质量也不如英文（很遗憾，这也是更推荐使用英文搜索的原因之一）。在你逐渐熟练使用搜索引擎后，应该能对不同质量的结果有一个更清晰的判断。
 
-### 其他信息 {#other-info}
+### 询问大语言模型 {#ask-llm}
 
 自 2023 年初大语言模型（GPT 等）逐渐普及以来，向大语言模型求助已成为解决问题的一种途径。与真人交流相比，你通常可以更反复、细致地追问。不过这同样需要技巧，请参考本文「[附录：如何正确向大语言模型提问](#llm)」。
 
@@ -241,9 +241,11 @@ A2: 装 python-is-python3
 A3: 20.04 源里面也有 3.9，可以直接 install python3.9
 ```
 
-### 直接提问，避免使用「在吗」/「有人吗」 {#ask-directly}
+### 直接提问 {#ask-directly}
 
-在私聊中，直接提问比先只问「在吗」更高效。考虑这个虚构的例子：
+不要先问「在吗」「有人吗」，也不要问「有没有人懂 XX」，直接把问题说出来即可。
+
+在私聊中，直接提问比先问一句「在吗」高效得多。考虑这个虚构的例子：
 
 ```text
 A (8:00): 在吗？
@@ -259,17 +261,15 @@ A (8:00): Hi，我遇到了 XXXXXXX 错误，然后 YYYY 命令跑不了，怎
 B (13:00): 这样，你应该 ZZZZZZZ
 ```
 
-群聊中也是如此，出于礼貌额外“握手”一次反而浪费时间。
-
-### 避免「有没有人懂」 {#justask}
+群聊中也是如此，出于礼貌额外「握手」一次反而浪费时间。
 
-不要在群聊里面这样问：
+在群聊里先问领域，也是类似的情况：
 
 ```text
 有没有人懂 C++？有个问题想问问
 ```
 
-原因如下：
+这样问的问题在于：
 
 - C++ 是非常复杂的，没有多少人真的懂/精通 C++。对很多别的领域也是类似的。
 - 就算真的有人懂，懂的人很可能也不想在群里显摆自己。不太懂的人就更没有兴趣看你的问题了。
@@ -283,15 +283,7 @@ B (13:00): 这样，你应该 ZZZZZZZ
 
 相关论述可参考 [不要问有没有人，请直接问](https://fars.ee/~justask.html)。
 
-### 尽可能提供「最小可复现样例」 {#mre}
-
-**最小可复现样例**（Minimal reproducible example，MRE）是一段**完整、精简**的程序代码或者执行流程，**不包含与错误无关的部分**。这通常只包含出现问题的核心几行代码、命令、以及最小依赖项。你可以复制当前的工程，通过二分法逐步删除无关部分，并保留原有错误来制作 MRE。和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。
-
-不妨换个角度思考：如果提问者提供的代码依赖第三方库、自定义结构体或类方法，却没有提供依赖信息和相关定义，回答者就很难复现问题。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
-
-> 提供 MRE 能平衡提问者和回答者的时间。制作 MRE 虽然需要一些技巧和时间，但有助于准确定位问题。
-
-### 提供必要的问题描述与相关信息 {#provide-necessary-info}
+### 提供必要的信息 {#provide-necessary-info}
 
 需要说明的内容包括：
 
@@ -321,7 +313,7 @@ A2: 要用 curl.exe 调用才行
 
 如果提问者在一开始就说清楚自己在 Windows 下，那么这个问题可能会更快得到解决。
 
-报告错误时请直接提供原始输出，不要自行翻译。建议在开发者的语言（通常是英语）环境下复现错误，以获得更准确的提示信息并帮助其他人定位问题；最好直接复制错误信息，而不是对着日志手动敲一遍；如果原文内容太长，可以参考下一节内容来使用 Pastebin 等工具分享完整文本。
+报告错误时请直接提供原始输出，不要自行翻译。建议在开发者的语言（通常是英语）环境下复现错误，这样提示信息更准确，也方便其他人定位问题；最好直接复制错误信息，而不是对着日志手动敲一遍；如果内容太长，可以参考[用合适的方式分享信息](#share-info)。
 
 在 Linux 系统中，可以使用以下方法设置程序运行的语言：
 
@@ -332,15 +324,36 @@ LC_ALL=en_US.UTF-8 你的命令
 LC_ALL=zh_CN.UTF-8 你的命令
 ```
 
-### 使用代码片段服务分享问题相关的代码与报错 {#use-pastebin}
+再看一个信息不足的反例：
 
-代码和报错信息如果太长，直接截图或贴到群聊里可能不太合适：
+```text
+我的 vulkan 程序在 wayland 下没有显示出来，托盘那里有程序的图标，怎么回事？
+```
+
+这个例子的问题在于：
+
+- 没有提供任何代码，要知道 Vulkan 画个三角形都要写一千多行代码
+- 环境信息不够详细：比如 Wayland 主要依赖混成器实现，建议说明具体使用的桌面环境，如 KDE；Vulkan 作为图形接口较为宽泛，最好补充相关图形库信息，例如是否使用了 GLFW 绘制窗口。
+
+#### 提供「最小可复现样例」 {#mre}
+
+**最小可复现样例**（Minimal reproducible example，MRE）是一段**完整、精简**的程序代码或者执行流程，**不包含与错误无关的部分**。这通常只包含出现问题的核心几行代码、命令、以及最小依赖项。你可以复制当前的工程，通过二分法逐步删除无关部分，并保留原有错误来制作 MRE。和上面自行阅读错误信息的过程类似，你自己可能就会发现其中的问题。
+
+不妨换个角度思考：如果提问者提供的代码依赖第三方库、自定义结构体或类方法，却没有提供依赖信息和相关定义，回答者就很难复现问题。此外，哪怕有全部代码，恐怕也很少有人愿意帮忙调试几百行的程序，更不用说配置复杂的运行环境了。
+
+> 提供 MRE 能平衡提问者和回答者的时间。制作 MRE 虽然需要一些技巧和时间，但有助于准确定位问题。
+
+### 用合适的方式分享信息 {#share-info}
+
+代码和报错信息如果太长，直接截图或者贴到群聊里可能不太合适：
 
 - 截图既难以用 OCR 识别，也没人愿意手动转录，不方便他人直接使用
 - 直接发送较长的信息会影响他人浏览之前的内容，也不便阅读（尤其在不支持代码块的 QQ、微信等聊天软件中）
 - 某些聊天软件会把特殊字符自动转换成表情符号，使得文本更难以阅读
 
-虽然聊天软件一般都支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。此时可以使用部分网站的长文本存储功能（一些网站可能无法直接访问）：
+#### 使用在线剪贴板 {#use-pastebin}
+
+虽然聊天软件一般都支持上传文件，但在某些场合（如群聊）直接上传文件可能不太合适，管理员通常不希望群共享里堆满杂乱代码。此时可以使用在线剪贴板（也叫 Pastebin，一些网站可能无法直接访问）：
 
 - GitHub 对应 [GitHub Gist](https://gist.github.com/)
 - GitLab 对应其 [Snippets](https://gitlab.com/dashboard/snippets) 功能
@@ -348,18 +361,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 科大校内的同学可以使用校内 GitLab（[超算中心](https://git.ustc.edu.cn/) 或 [LUG](https://git.lug.ustc.edu.cn/)）的 Snippets。
 
-反例：
-
-```text
-我的 vulkan 程序在 wayland 下没有显示出来，托盘那里有程序的图标，怎么回事？
-```
-
-这个例子的问题在于：
-
-- 没有提供任何代码，要知道 Vulkan 画个三角形都要写一千多行代码
-- 环境信息不够详细：比如 Wayland 主要依赖混成器实现，建议说明具体使用的桌面环境，如 KDE；Vulkan 作为图形接口较为宽泛，最好补充相关图形库信息，例如是否使用了 GLFW 绘制窗口。
-
-### 避免拍屏 {#use-screenshots}
+#### 避免拍屏 {#use-screenshots}
 
 除非实在无法截图（例如系统启动阶段），否则不要拍屏，因为：
 
@@ -368,7 +370,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 - 不利于其他人搜索类似问题
 - 不美观
 
-## 无人应答 {#if-no-answer}
+## 其他咨询方式 {#if-no-answer}
 
 没人回答不等于问题被无视。在群聊中认真提问却无人回应，往往只是因为看到问题的人都不知道答案罢了。其次，群聊或论坛里的陌生人并没有义务回答你的问题。
 

From 37d300325156e8cda35161eb97126789d7a280ac Mon Sep 17 00:00:00 2001
From: Catoverflow <55503205+Catoverflow@users.noreply.github.com>
Date: Tue, 8 Sep 2026 18:50:47 -0500
Subject: [PATCH 13/17] =?UTF-8?q?howtoask:=20=E9=80=9A=E8=AF=BB=E4=BF=AE?=
 =?UTF-8?q?=E8=AE=A2=E5=B0=8F=E6=A0=87=E9=A2=98=E4=B8=8E=E4=B8=AA=E5=88=AB?=
 =?UTF-8?q?=E8=A1=A8=E8=BE=BE?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

「阅读已有的信息」改为「读懂错误信息」，「利用搜索引擎等工具」改为
「使用搜索引擎」，「搜索相关项目的手册/FAQ 等信息」改为「优先查阅项目文档」。

大语言模型附录去掉只有一句话的「请先阅读正文内容，再阅读本部分」一节，
并入开头；给「提供足够的上下文信息」补一句导语。

修正 Pastebin.com 的链接（http 且带大写域名）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvEbFWbpQYtwB2V6SvQWUf
---
 pages/_wiki/doc/howtoask.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 0e9997c1bd..b9e3355b1d 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -21,7 +21,7 @@ License: CC-BY-NC-SA 4.0
 
 在求助他人之前，可以先分析一下问题。这样既能问得更准确、节省他人的时间，也能加深对问题的理解。
 
-### 阅读已有的信息 {#read-existing-info}
+### 读懂错误信息 {#read-existing-info}
 
 多数错误伴随着错误信息（error message），想要帮助你的人通常也需要这些信息，解读这些信息是解决问题的第一步。一些基本的心得和技巧包括：
 
@@ -96,7 +96,7 @@ License: CC-BY-NC-SA 4.0
 
   可以看到，输出中的报错信息明确指出了 `No such file or directory`（没有对应的文件或文件夹），说明程序找不到指定的文件。仔细检查便可发现是命令里面把文件名敲错了。
 
-### 利用搜索引擎等工具 {#use-search-engine}
+### 使用搜索引擎 {#use-search-engine}
 
 尽管近几年大语言模型发展迅速，但是搜索引擎在解决问题方面仍然不可或缺。
 
@@ -113,7 +113,7 @@ 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` 模块遇到问题时，最好先查阅手册寻找答案：
 
@@ -357,7 +357,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 - GitHub 对应 [GitHub Gist](https://gist.github.com/)
 - GitLab 对应其 [Snippets](https://gitlab.com/dashboard/snippets) 功能
-- 独立的 Pastebin 类服务，例如 <s>[Ubuntu pastebin](https://paste.ubuntu.com/)</s>（已结束服务），[Pastebin.com](http://Pastebin.com) 等
+- 独立的 Pastebin 类服务，例如 <s>[Ubuntu pastebin](https://paste.ubuntu.com/)</s>（已结束服务），[Pastebin.com](https://pastebin.com/) 等
 
 科大校内的同学可以使用校内 GitLab（[超算中心](https://git.ustc.edu.cn/) 或 [LUG](https://git.lug.ustc.edu.cn/)）的 Snippets。
 
@@ -505,12 +505,12 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 ## 附录：如何正确向大语言模型提问 {#llm}
 
-### 请先阅读正文内容，再阅读本部分 {#read-main-content-first}
-
-对人类有效的提问策略，大多对大语言模型（LLM）也有效。
+对人类有效的提问策略，大多对大语言模型（LLM）也有效，因此建议先阅读本文的正文部分，再阅读这一节。
 
 ### 提供足够的上下文信息 {#provide-context}
 
+大语言模型只能看到你给出的信息，因此上下文是否充分，很大程度上决定了回答的质量。
+
 #### 对话式大语言模型 {#chatbot-context}
 
 向对话式大语言模型提问时，和向人类提问类似，也需要提供足够的上下文，帮助它理解问题。下面沿用前文在命令行中下载文件的例子。

From decb3b30e10cf6f1361d0f6f398e28891fd30a72 Mon Sep 17 00:00:00 2001
From: iBug <git@ibugone.com>
Date: Wed, 9 Sep 2026 11:29:10 +0800
Subject: [PATCH 14/17] Fix Cloudflare Pages build failure

---
 Gemfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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'

From 86cc57975f2091fe3b61abe0016f9566158c0f19 Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Fri, 11 Sep 2026 21:28:14 +0800
Subject: [PATCH 15/17] =?UTF-8?q?howtoask:=20Add=20a=20warning=20about=20L?=
 =?UTF-8?q?LM=20=E4=B8=AD=E8=BD=AC=E7=AB=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 pages/_wiki/doc/howtoask.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index b9e3355b1d..1fb565d6b6 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -656,6 +656,7 @@ Invoke-WebRequest -Uri "https://example.com/file.zip" -OutFile "file.zip"
 使用大语言模型，特别是 Agent 的时候，如果正在处理非公开的信息，那么就需要尤其注意隐私问题。不同的大语言模型服务商有不同的隐私策略，在一些情况下可能会留存用户提供的信息用于训练新的模型，或者改进产品。你大概不会把自己的秘密告诉陌生人，但是在向大语言模型提问的时候，可能会不知不觉泄露相关的信息。因此，在提问的时候需要注意：
 
 - 使用大语言模型前，确认服务商的隐私策略、服务条款等内容。
+- 谨慎使用「中转站」类大模型服务，此类服务商可能会存储对话数据并出售给其他人。
 - 不要直接向模型提供密码、Cookie、私钥等敏感数据。
 - 可能包含个人信息的日志，以及未公开的代码等在提问时需要小心处理。
 - 在网页端删除对话不代表对应的信息就从服务商的服务器上立刻删除了。

From 42563d5b054d1e3b7f6cb800e2f2d24900c3c0af Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Sat, 12 Sep 2026 04:40:44 +0800
Subject: [PATCH 16/17] =?UTF-8?q?howtoask:=20=E4=BF=AE=E6=94=B9=E6=A0=87?=
 =?UTF-8?q?=E9=A2=98=EF=BC=9B=E5=85=B3=E4=BA=8E=E7=89=87=E6=AE=B5=E6=A0=87?=
 =?UTF-8?q?=E8=AF=86=E7=AC=A6?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 pages/_wiki/doc/howtoask.md | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 1fb565d6b6..2dbbe953eb 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -419,7 +419,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 **请不要对提问者开这种玩笑。**
 
-### 循循善诱 {#guide-patiently}
+### 友好沟通、推进目标解决 {#friendly-to-goal}
 
 可以从三个方面理解一个问题：目标、已有方案，以及约束条件与偏好。这些信息起初往往并不明确，需要双方在交流中逐步澄清，排除不符合要求的方案。
 
@@ -445,7 +445,15 @@ LC_ALL=zh_CN.UTF-8 你的命令
 
 最后一句只是在质疑提问者的偏好：「某功能对某些人有用」并不能代替关闭它的方法。如果问题涉及提问者可能不了解的概念，比起在群里追问，或者要求对方读完一大篇 wiki 再来描述需求，给出链接加一句简单的说明通常更有效：
 
-> A: 这里其实有「鼠标选区」和普通剪贴板两套机制，可以先看看 [ArchWiki 的介绍](https://wiki.archlinux.org/title/Clipboard)，再说说你想关掉的是哪一个？
+> A: 这里其实有「鼠标选区」和普通剪贴板两套机制，可以先看看 <https://wiki.archlinux.org/title/Clipboard#Selections>，你的意思是要关掉 PRIMARY 这个剪贴板，还是说选中的内容进入了 CLIPBOARD 这个剪贴板？
+
+{% capture notice-url-frag %}
+许多文档类站点在点击标题，或者标题旁边的标记（一般称为 anchor）的时候，都会在浏览器显示的 URL 后添加类似 `#some-thing` 的内容，这被称为「片段标识符」（Fragment Identifier）。**推荐在分享的 URL 中添加片段标识符，这样点击链接的人就能立刻跳到你希望他阅读的地方。**
+
+此外，Firefox、Chrome 等浏览器也都支持复制指向当前选中的文本的链接的功能，会在 URL 后添加类似 `#:~:text=xxxx` 的内容，支持的浏览器可以直接跳转到你选中的内容。
+{% endcapture %}
+
+<div class="notice--info">{{ notice-url-frag | markdownify }}</div>
 
 **有用的回答需要让讨论向前推进。** 一种常见的问题是只讨论个人经历，却不说明它和当前问题有什么关系，比如「这不是挺方便吗」「别搞了」「我用了很多年，你参考不了」。相比之下，这样的回答是有效的：
 

From 9c35496fa7458d2568c22a35777077cae1182684 Mon Sep 17 00:00:00 2001
From: taoky <me@taoky.moe>
Date: Sat, 12 Sep 2026 04:53:17 +0800
Subject: [PATCH 17/17] howtoask: Going to retire lug gitlab

---
 pages/_wiki/doc/howtoask.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pages/_wiki/doc/howtoask.md b/pages/_wiki/doc/howtoask.md
index 2dbbe953eb..94907da1c6 100644
--- a/pages/_wiki/doc/howtoask.md
+++ b/pages/_wiki/doc/howtoask.md
@@ -359,7 +359,7 @@ LC_ALL=zh_CN.UTF-8 你的命令
 - GitLab 对应其 [Snippets](https://gitlab.com/dashboard/snippets) 功能
 - 独立的 Pastebin 类服务，例如 <s>[Ubuntu pastebin](https://paste.ubuntu.com/)</s>（已结束服务），[Pastebin.com](https://pastebin.com/) 等
 
-科大校内的同学可以使用校内 GitLab（[超算中心](https://git.ustc.edu.cn/) 或 [LUG](https://git.lug.ustc.edu.cn/)）的 Snippets。
+科大校内的同学可以使用校内 [GitLab](https://git.ustc.edu.cn/) 的 Snippets。
 
 #### 避免拍屏 {#use-screenshots}